Current Keyboard Layout

[Caine]

The left/right shift,alt,ctrl labels are just there to indicate correspondence to a normal keyboard, right?

I don't think we should actually label them as left or right. The important part is that there are two of them and that they are different

(and thus have different actions mapped to them).

 

[_wb_]

The left/right shift,alt,ctrl labels are just there to indicate correspondence to a normal keyboard, right?


I don't think we should actually label them as left or right. The important part is that there are two of them and that they are different


(and thus have different actions mapped to them).

I agree that we should not actually label them with "left" or "right". But they should be mapped in some way, and since software can distinguish left modifiers from right modifiers and show names like L_SHIFT, R_SHIFT in configuration dialogs for user-defined remapping etc, it is nice if they are mapped in a somewhat logical way.

By putting the Right/Rear version of all modifiers on the shoulder buttons, it is relatively easy to remember which one is which. It is also nice if the Left modifiers can actually physically be located to the left of the corresponding Right modifier, or at least not to its right.

 

[Saber]

For the second part where you ignorantly called the fictional layout I posted above stupid because Left Shift with Right Shift are reversed on the keyboard, it's because with two Right Shifts you can't remap one without affecting the other, so by placing Left Shift on the right hand side the buyer is given the option to remap the Left Shift to another key of their choosing(Pause, Print Screen, a localized vowel, or whatever). Understand now?

No, that still makes no sense (to me), but then so does most of these keyboard threads, so carry on anyway... I'll retreat to my hole, and watch for ED's final layout

Today is supposedly when the farcical keyboard poll is posted, but we can assume ED's collaborative layout will win it(because an earned reputation overcomes everything it seems), but I'll explain my reasoning to some of you one last time and then leave it for history. First about the two Shift keys again.

A full size PC keyboard has two Shifts. Some people don't use the shoulder button Shift key for typing. Some people don't want two keyboard Shift keys regardless of how they benefit those people who don't use the Shoulder Shift. They see two keyboard Shift keys as wasteful(to them).

I have in my 7.0b layout two Right Shift keys on the left side of the Pyra with one on the L1 shoulder trigger and the other below Tab. I'm told you can't remap one Right Shift without influencing the other Right Shift, so I moved the real Left Shift, the only one we have, over to the right side of the Pyra. The reason for this is so now any user who dislikes having two keyboard Shift keys can reassign this real Left Shift to the desired key they want it to be, like say ø or å or even / and ?, or if so inclined they can leave it untouched and keep it for Shifting letters when typing. There it is.

Blatantly pitching my unofficial proposal

I'm convinced 7.0b is a very viable layout for Pyra users. It has three of the main diacritics(Acute, Grave and Circumflex), all the German umlauted vowels, the important symbols like _ - + = { [ ] } \ | and others on the correct side and not playing second fiddle to unimportant filler keys like € or °, Insert and Delete both as standalones without requiring modifiers, Backspace in it's proper location, an Escape key as primary and not buried under Fn + q or Fn + Tab, and logical placement of key backlighting controls(opposite side from keyboard Fn for those who don't use the Shoulder modifiers). We also don't need to move ( ) too. 

With four small key rows now instead of three(as on the Pandora), In case it flew over some of your heads, I also designed it, loosely speaking, so each half row is by a specific "theme": umlauts, diacritics, braces, mathematical, punctuation and misc. This should help minimize searching for a needed symbol. 7.0b again:

http://i.imgur.com/aCja1yR.png

Spoiler

Oh well, I tried. 

 

[pmprog]

(because an earned reputation overcomes everything it seems)

Don't know if this was directed at me - I don't know, but I won't participate in the polls anyway. However, consider that ED will ultimately have the decision regardless of any poll, and what he decides will go on the Pyra. Ultimately, everyone's choice is accept the layout, try and ignore the print and remap the keys in software, or ignore the Pyra as a device with an unusable keyboard.
Regarding your layout, I actually quite like it, except for L.Shift and R.Shift. Ignore the shoulder button - I get that, and that's not a problem. I don't care if you just label them "Shift" or not, if you leave them like that, if a game says "Press Left Shift", you're going to hit the shift key on the left - which is not L.Shift.

Ignore the Pyra specifics and ergonomics about the keyboard and consider if you bought a USB keyboard where the left shift was on the right and vice versa, would you really trust the manufacturer who can't tell left from right?

 

[Saber]

Forgot to mention about having two identical Right Shift keys and the issues with pressing both of them at the same time(even though they are not likely to be under normal usage). I'd assume it would be dealt with the same as the Spacebar since that has two pads under it that are contacted together by the long "bridge" button over them, but one of them is "nulled out" through software. Similarly, when both Right Shifts are tapped erroneously, the "bridge" here in this situation is the left index finger on shoulder shift and the span from it to the left thumb which is on the keyboard Shift. This same "nulling out" theoretically could be done with one of these two Shifts(probably the keyboard one goes black). Pressing both of them still gives us this Right Shift, I think.   

 

[ible]

i think the point is to make it easy for software-writers to say "R" buttons are on the shoulders, "L" buttons are on the keyboard. there's ambiguity because start/select (ctrl/alt) on the keyboard are in the center. there's no C_Shift, so it's better to designate shoulders as one type and keyboard as another, in order to get one of each. it may make it harder for the user in e.g. ported or closed-source software, where the user can map the game keys as desired, and then wonder what L-shift is compared to R-shift. (Though, you do know which button you press when making the mapping, though quick-time events may be harder...) For homebrew software, it's easy to say R1,R2, L1,L2, or keyboard shift, etc. so the user doesn't have to remember.

It's a convention, admittedly.

 

[Saber]

(because an earned reputation overcomes everything it seems)

Don't know if this was directed at me - I don't know, but I won't participate in the polls anyway. However, consider that ED will ultimately have the decision regardless of any poll, and what he decides will go on the Pyra. Ultimately, everyone's choice is accept the layout, try and ignore the print and remap the keys in software, or ignore the Pyra as a device with an unusable keyboard.

Regarding your layout, I actually quite like it, except for L.Shift and R.Shift. Ignore the shoulder button - I get that, and that's not a problem. I don't care if you just label them "Shift" or not, if you leave them like that, if a game says "Press Left Shift", you're going to hit the shift key on the left - which is not L.Shift.


Ignore the Pyra specifics and ergonomics about the keyboard and consider if you bought a USB keyboard where the left shift was on the right and vice versa, would you really trust the manufacturer who can't tell left from right?

It wasn't necessarily directed all at you. I'm trying to get ED to see more than I think he is. Trying to help him. 

I'm not familiar with all the pnd's for the Pandora, but Right Shift on that device wasn't even remotely positioned on the right was it? People from what I know of it didn't have problems with the fact it was switched did they, usb keyboard or not? 

i think the point is to make it easy for software-writers to say "R" buttons are on the shoulders, "L" buttons are on the keyboard. there's ambiguity because start/select (ctrl/alt) on the keyboard are in the center. there's no C_Shift, so it's better to designate shoulders as one type and keyboard as another, in order to get one of each. it may make it harder for the user in e.g. ported or closed-source software, where the user can map the game keys as desired, and then wonder what L-shift is compared to R-shift. (Though, you do know which button you press when making the mapping, though quick-time events may be harder...) For homebrew software, it's easy to say R1,R2, L1,L2, or keyboard shift, etc. so the user doesn't have to remember.


It's a convention, admittedly.

Most users won't care about any of that. It's when you dig deeper that you have to put on your goggles and learn. Both Shifts on the keyboard will say Shift, and most won't care which is Left or Right as long as it produces capital letters.  B)

 

[Neelix]

I'd assume it would be dealt with the same as the Spacebar since that has two pads under it that are contacted together by the long "bridge" button over them, but one of them is "nulled out" through software.

Except that it doesn't work that way. The physical pads under the space bar are electrically connected, so no matter which side of it you press the CPU will always get the same signal, there is no 'nulling out' of one of two different signals.

-Neelix

 

[TrashyMG]

I'd assume it would be dealt with the same as the Spacebar since that has two pads under it that are contacted together by the long "bridge" button over them, but one of them is "nulled out" through software.

Except that it doesn't work that way. The physical pads under the space bar are electrically connected, so no matter which side of it you press the CPU will always get the same signal, there is no 'nulling out' of one of two different signals.


-Neelix

So far what I gleamed from the early peek of the keyboard schematic, They're two seperate entities to the TCA8418 keypad IC, both keys have a unique row/column in the matrix. In the device tree setup they're just being mapped to the same function/keycode ( spacebar ).

 

[Saber]

8.0: http://i.imgur.com/wWLfwPx.png

• Key Backlighting now uses the Shift keys. Maybe put Print Screen and Pause under Fn here.
• Escape is over to the top left. I'll admit I sort of like that better.

Spoiler

Summary:

• Screen and Key Backlight leveling on two buttons for precision adjustments.
• Requested Wifi and 4G/BT toggle present. If people find this undesirable, we could label it the "ANY" key for remaps. 
• Super “Pyra” button is without a Shift or Fn value and thus can be used as a modifier. Could be combined with Alt for Magic SysRq commands.
• Insert and Delete are primary and aptly labeled on smaller action buttons as + and -.
• Backspace and Enter are without Shift or Fn values and can be utilized under all key tiers.
• German umlauts in a row with ü and ö on corresponding vowels for easy pinpointing. ß is close by as well. 
• Dead key diacritics Circumflex, Grave, and Acute are also in one row unhidden at Fn + h, j, and k, respectively.
• Caps Lock is at anticipated location. May be repurposed, like much of the layout, at user’s volition.
• Escape is at top left key. 

Editor for this layout is here and a list of Compose key sequences can be found here.

 

[Alperoot]

When is the poll?

 

[Grench]

I'd assume it would be dealt with the same as the Spacebar since that has two pads under it that are contacted together by the long "bridge" button over them, but one of them is "nulled out" through software.

Except that it doesn't work that way. The physical pads under the space bar are electrically connected, so no matter which side of it you press the CPU will always get the same signal, there is no 'nulling out' of one of two different signals.

-Neelix

So far what I gleamed from the early peek of the keyboard schematic, They're two seperate entities to the TCA8418 keypad IC, both keys have a unique row/column in the matrix. In the device tree setup they're just being mapped to the same function/keycode ( spacebar ).

Assuming that proves to be true, I wonder how many of us will modify our key mats to split the space bar. Good - another key to use. Bad - an intrusion point for dust and gunk. With just a simple razor slice through the space bar key, though, the intrusion shouldn't be too bad...

 

[TrashyMG]

Assuming that proves to be true, I wonder how many of us will modify our key mats to split the space bar.

Here is a little more detail I posted a while ago in another thread.

http://boards.openpandora.org/topic/17881-its-the-keyboard-layout/?p=386245/URL] 

 

[Xcl4m4t10n]

When is the poll?

^