It's the keyboard layout.

[codifies]

...erm Left and right are two different keys and in many engines / OS key maps they have distinct key codes (usually with symbols like L_SHIFT and R_SHIFT or similar)

However in every keyboard I've tried holding either/and/or both shift keys keeps the keyboard shifted. You can hold down the left shift then the right then release the left shift, while all the time getting shifted keys, I can't see any reason why this shouldn't be the case with the Pyra and if its not with the Pandora (I never tried) then its a bug!

 

[WizardStan]

...erm Left and right are two different keys and in many engines / OS key maps they have distinct key codes (usually with symbols like L_SHIFT and R_SHIFT or similar)

However in every keyboard I've tried holding either/and/or both shift keys keeps the keyboard shifted. You can hold down the left shift then the right then release the left shift, while all the time getting shifted keys, I can't see any reason why this shouldn't be the case with the Pyra and if its not with the Pandora (I never tried) then its a bug!

You are misunderstanding, sorry.You are absolutely correct, if there are only two shifts then you have an L_SHIFT, an R_SHIFT, and pressing either one doesn't affect the other. You can press them both, release one, and the other is still recognized. This is how the Pandora works, no problem.

The current debate stems from EvilDragon once requesting that there be two shifts on the keyboard, one on either side, and some good arguments in favour of that setup: combined with the shoulder shift you now have three shift keys, but only two key codes. How do you represent three keys with only two key codes? Either you invent a new keycode, and software may need to be changed to support it, or you double up the key codes. Both solutions come with their own problems. The statements being made are assuming we go with doubling up the keycodes, either both keyboard shift keys are L_SHIFT and the shoulder is R_SHIFT (or vice versa) or the keyboard gets L_SHIFT and R_SHIFT, and the shoulder also gets L_SHIFT (or R_SHIFT).

This solution introduces its own problem when pressing the doubled up key: you press one, it sends a KEY_DOWN event, you press the other and send another KEY_DOWN event (which is most likely ignored), you then release one and process a KEY_UP event; now the application, because it doesn't expect to receive multiple KEY_DOWN and KEY_UP events for a single key, thinks the key has been released even though one of them is still being held. This is arguably a bug but more accurately an unfortunate consequence of the system, there's no solution for it other than documentation.

 

[codifies]

...erm Left and right are two different keys and in many engines / OS key maps they have distinct key codes (usually with symbols like L_SHIFT and R_SHIFT or similar)


However in every keyboard I've tried holding either/and/or both shift keys keeps the keyboard shifted. You can hold down the left shift then the right then release the left shift, while all the time getting shifted keys, I can't see any reason why this shouldn't be the case with the Pyra and if its not with the Pandora (I never tried) then its a bug!

You are misunderstanding, sorry.
You are absolutely correct, if there are only two shifts then you have an L_SHIFT, an R_SHIFT, and pressing either one doesn't affect the other. You can press them both, release one, and the other is still recognized. This is how the Pandora works, no problem.


The current debate stems from EvilDragon once requesting that there be two shifts on the keyboard, one on either side, and some good arguments in favour of that setup: combined with the shoulder shift you now have three shift keys, but only two key codes. How do you represent three keys with only two key codes? Either you invent a new keycode, and software may need to be changed to support it, or you double up the key codes. Both solutions come with their own problems. The statements being made are assuming we go with doubling up the keycodes, either both keyboard shift keys are L_SHIFT and the shoulder is R_SHIFT (or vice versa) or the keyboard gets L_SHIFT and R_SHIFT, and the shoulder also gets L_SHIFT (or R_SHIFT).


This solution introduces its own problem when pressing the doubled up key: you press one, it sends a KEY_DOWN event, you press the other and send another KEY_DOWN event (which is most likely ignored), you then release one and process a KEY_UP event; now the application, because it doesn't expect to receive multiple KEY_DOWN and KEY_UP events for a single key, thinks the key has been released even though one of them is still being held. This is arguably a bug but more accurately an unfortunate consequence of the system, there's no solution for it other than documentation.

The simple answer would be don't use gaming controls to do keyboard functions!

The X11 protocol makes it very difficult to intercept key events globally (you could then track the two different physical keys and send a key up only when both actually were up) This is a consequence of the server/client history of Xorg...

This would leave the only practical option to do this within the X11 keyboard driver for the keyboard, this is fraught with issues because you'd have no guaranteed way for an application to actually tell the difference between one key and another

There is one way to do it - but I can see it breaking things and being a PITA later

basically the X11 driver would send the right shift key UP/DOWN events based on keyboard and shoulder button shift OR'd and it would also send shoulder button events for the key code assigned to the shoulder button ie key up/down regardless of the state of the keyboard shift

This would mean a game for example would always know what the shoulder button was doing, a keyboard using app (for text) would see shift at the right time

BUT

a game assuming it could use the right shift raw key code could get confused by the right shoulder button

In any case the unholy kludge of a hack would need to be easily configured / turned off (or on) by a novice user....

 

[bzar]

Well, any Fn or other driver-level hack will need some sort of hackery to function to be fair. As long as it can be done in the input driver (not X11 driver, the device driver that makes stuff in /dev/input) and works consistently it's probably OK. Confusing, but OK.

 

[WizardStan]

The simple answer would be don't use gaming controls to do keyboard functions!

That's a bad solution. I and many others make significant use of the gaming-controls-as-keyboard-keys in regular use. I'd argue it's become a major selling point and to remove it would be met with a lot of criticism.

basically the X11 driver would send the right shift key UP/DOWN events based on keyboard and shoulder button shift OR'd and it would also send shoulder button events for the key code assigned to the shoulder button ie key up/down regardless of the state of the keyboard shift

Or leave the shoulder button by itself and have the keyboard's left and right shift share a code which the driver handles the way you suggest: unless someone writes a game that for some reason really needs to know the status of either shift on the keyboard it'll just work. And I can't think of a scenario where they would need that to happen but accept that someone might want it, in which case you just have to document the problem, that both shifts share a key code and you can't independently figure out which is being pressed.

 

[codifies]

The only thing coming from the kernel (/dev/input) should be a unique code for each physical key and what event (UP or DOWN) putting any "intelligence" at that level would defiantly bite people in delicate places later...

Personally I think any kind of "intelligence" in a X11 driver to sometimes force 3 keys into the function of 2 and sometimes not, is a bad idea...

The should only ever be two physical shift keys - put both on the keyboard if you must, but expect pain sooner or later if you expect 3 keys to sometimes do the job of 2 

having two keys you cant tell apart is also a bad idea....

 

[_wb_]

Despite what ED may have said, I see no reason to have three shifts. We can make keyboard shift optionally sticky to solve the same-side-thumb-chording issue. There is no reason to sacrifice a keyboard key and cause implementation issues just for a convenience thing that only applies to shoulder-modifier-refusers and which is better solved in a different way anyway.

 

[Grench]

There IS a keyboard layout option that:

1.  Does not require any sticky keys.

2.  Does not require any shoulder modifiers (shoulders can then be mapped to whatever you desire).

3.  Has no left/right side disadvantages to chord+keypress combinations.

4.  Is -REAL- AltGr compatible (Turn on an AltGr language keyboard definition and the right Alt becomes AltGr).

5.  Is DosBox and QEMU compliant (key pairs retained)

6.  Has easily understood diacritics AND a dedicated 4-function media key.

7.  Has true left shift, right shift, left control, right control, left alt, right alt (AltGr if needed), left Fn and right Fn while freeing up the shoulders for mouse buttons or whatever else the user fancies - including over mapping modifiers.

8.  Key locations are relatively close to where an end user would expect them to be.

9.  Top level comma , and period . and [ and ] and ' and ` keys.

10.  Dedicated top level Esc key.

11.  All keys and levels of modifiers are chord capable by either thumb, including Fn+shift, Fn+alt, Fn+Ctrl, etc...

12.  Has the advantage of being able to lock both the number pad and the F1-F12 buttons to the foreground for games.

Right now it doesn't stand much of a chance in hell since it relies on a centered space bar.  However, I think it CAN meet all of our needs and want to haves.  It is built from the ground up for functionality.

http://www.keyboard-layout-editor.com/#/layouts/3909b1ca9e87a590a89d24608b7a5de9

 

OK, so some think it's ugly.  IMHO it's so ugly it's cute...

 

[codifies]

Four! keys that are duplicated - surely there are not enough keys to be wasting keys on a duplicate - let alone four of them!

 

[comradekingu]

The more different layouts I see without shift in the bottom left the more I think it needs to be there but I just can't exactly say why? Would it make it more convenient? Or it it purely because that's where I've seen it on every "normal" keyboard and my subconscious is failing to realise that this *isn't* a normal situation ...

Here, here and  here you can see it explained. It is not more efficient. Actually less so since you waste a key (compared to having it left only) And teach yourself bad habits by using it.

When you understand the reasoning you will see it the opposite way.

There are many of those changes in my layout.

Nothing is placed by accident or simply "there". If you think something looks weird, feel free to ask and ill explain.

 

[_wb_]

There IS a keyboard layout option that:

1.  Does not require any sticky keys.

2.  Does not require any shoulder modifiers (shoulders can then be mapped to whatever you desire).

3.  Has no left/right side disadvantages to chord+keypress combinations.

4.  Is -REAL- AltGr compatible (Turn on an AltGr language keyboard definition and the right Alt becomes AltGr).

5.  Is DosBox and QEMU compliant (key pairs retained)

6.  Has easily understood diacritics AND a dedicated 4-function media key.

7.  Has true left shift, right shift, left control, right control, left alt, right alt (AltGr if needed), left Fn and right Fn while freeing up the shoulders for mouse buttons or whatever else the user fancies - including over mapping modifiers.

8.  Key locations are relatively close to where an end user would expect them to be.

9.  Top level comma , and period . and [ and ] and ' and ` keys.

10.  Dedicated top level Esc key.

11.  All keys and levels of modifiers are chord capable by either thumb, including Fn+shift, Fn+alt, Fn+Ctrl, etc...

12.  Has the advantage of being able to lock both the number pad and the F1-F12 buttons to the foreground for games.

Right now it doesn't stand much of a chance in hell since it relies on a centered space bar.  However, I think it CAN meet all of our needs and want to haves.  It is built from the ground up for functionality.

http://www.keyboard-layout-editor.com/#/layouts/3909b1ca9e87a590a89d24608b7a5de9

 

OK, so some think it's ugly.  IMHO it's so ugly it's cute...

Yes, it is very ugly cute. But it does not have dedicated number keys (so in that respect it is worse than the Pandora), and you say it does not require shoulder modifiers, but I say it does not allow shoulder modifiers.

It was a nice exercise in out-of-the-box thinking, but let's give it a honorable death and move it to the annals of these glorious boards, please

 

[codifies]

The more different layouts I see without shift in the bottom left the more I think it needs to be there but I just can't exactly say why? Would it make it more convenient? Or it it purely because that's where I've seen it on every "normal" keyboard and my subconscious is failing to realise that this *isn't* a normal situation ...

Here, here and  here you can see it explained. It is not more efficient. If you understand the reasoning you will see it the opposite way.

I understand, but respectfully do not agree  -  you cite yourself three times, espousing a point of view based around your own personal use case.

 

[Grench]

There IS a keyboard layout option that:

1.  Does not require any sticky keys.

2.  Does not require any shoulder modifiers (shoulders can then be mapped to whatever you desire).

3.  Has no left/right side disadvantages to chord+keypress combinations.

4.  Is -REAL- AltGr compatible (Turn on an AltGr language keyboard definition and the right Alt becomes AltGr).

5.  Is DosBox and QEMU compliant (key pairs retained)

6.  Has easily understood diacritics AND a dedicated 4-function media key.

7.  Has true left shift, right shift, left control, right control, left alt, right alt (AltGr if needed), left Fn and right Fn while freeing up the shoulders for mouse buttons or whatever else the user fancies - including over mapping modifiers.

8.  Key locations are relatively close to where an end user would expect them to be.

9.  Top level comma , and period . and [ and ] and ' and ` keys.

10.  Dedicated top level Esc key.

11.  All keys and levels of modifiers are chord capable by either thumb, including Fn+shift, Fn+alt, Fn+Ctrl, etc...

12.  Has the advantage of being able to lock both the number pad and the F1-F12 buttons to the foreground for games.

Right now it doesn't stand much of a chance in hell since it relies on a centered space bar.  However, I think it CAN meet all of our needs and want to haves.  It is built from the ground up for functionality.

http://www.keyboard-layout-editor.com/#/layouts/3909b1ca9e87a590a89d24608b7a5de9

 

OK, so some think it's ugly.  IMHO it's so ugly it's cute...

Yes, it is very ugly cute. But it does not have dedicated number keys (so in that respect it is worse than the Pandora), and you say it does not require shoulder modifiers, but I say it does not allow shoulder modifiers.

It was a nice exercise in out-of-the-box thinking, but let's give it a honorable death and move it to the annals of these glorious boards, please

Sure it allows them.  In the mapping tool they would appear as mouse2 buttons 1-4.  You could map one or more to your keyboard modifiers and rely on the mouse1 button 1 (right nub) and mouse1 button 2 (left nub).

You're right, though, it is dead on delivery with the "space bar IS on the right" issue.  However, I mostly posted it up at this point in the above conversation to show that what people are asking for - non-duplication of singular buttons, ambidextrous modifiers and DosBox and non-English support and everything IS possible if we're willing to take a step sideways so we're no longer IN the box.

The above discussion shouldn't be around IF it's possible, because we know that it is.  The discussion should be more around which direction we want to compromise since SOME compromise is needed.

Now, since we know that we must do some compromise, shoulder button modifiers may be in, but we would like to trade-off some of that compromise by having the modifier pairs from the shoulder buttons on opposite sides of the lower keyboard so that the needed chording (YES chording IS needed) can be done with either hand while button-pressing with the thumb from the opposing hand.

Another compromise is in some people wanting a dedicated number row on top.  Accommodating this desire with wanting a contiguous set of F1-F12 keys results in another set of wants taken into account.

That is where this one comes in:

http://www.keyboard-layout-editor.com/#/layouts/b863ac229b0af4b0f46d5e73ca3104b8

Note that the shoulder button modifier pairs are reflected in the opposite lower corner of the main keyboard, allowing for both shoulder modifiers AND easily found/reachable keyboard modifiers.  The vast majority of the other requirements are met, but there is 'clutter', but that 'clutter' allows easier non-English use while retaining the other needs.

 

[comradekingu]

The more different layouts I see without shift in the bottom left the more I think it needs to be there but I just can't exactly say why? Would it make it more convenient? Or it it purely because that's where I've seen it on every "normal" keyboard and my subconscious is failing to realise that this *isn't* a normal situation ...

Here, here and  here you can see it explained. It is not more efficient. If you understand the reasoning you will see it the opposite way.

I understand, but respectfully do not agree  -  you cite yourself three times, espousing a point of view based around your own personal use case.

I thought i accounted for all possible combinations, thus transcending my own use-case.

Feel free to provide details of a use-case when it makes sense to have left side shift. Lets for case of argument assume everything else is as efficient as possible.

Grench: I like the "standard" space. Though it means reduced layout, so one step forward, one step back for me.

 

[_wb_]

Grench: Why do shoulder modifiers have to be on the other side from the keyboard modifiers? It is perfectly possible to do, say, Shift+A on the Pandora using L1 as Shift, so why would that be different on the Pyra? Also for chording: it is perfectly possible to do L1+R1+something on the Pandora (I use it e.g. for Ctrl-Shift-C/V, to copy/paste stuff in a terminal window), and I expect all shoulder button combinations on the Pyra to be possible as well.

 

[Saber]

Updated.

• New presentation format. Yay.
• Every punctuation symbol which is normally paired up on a regular keyboard has it's shifted value under AltGr + Shift.
• In addition to the standard Grave symbol, a dead Grave key has also been thrown in under AltGr + n(I explain how we can differentiate between the two under "Notes" below).

Understand that I filled in the AltGr + Shift values using parts of the U.S. AltGr layout and the German layout. I think I made some decent and somewhat indelible choices(I realize most users probably won't need interpunct, or en and em dash, or even micro). Remember also that as far as I know, these fourth level symbols under AltGr + Shift will most likely not be on the actual keys. 

Pyra Keyboard Layouts(Second Update April 21st 2015):

With Shift + AltGr values: http://www.keyboard-layout-editor.com/#/layouts/7c6cdf68494706754cd11c81e1071b66

Spoiler

With Shift + AltGr values(except on the F-keys): http://www.keyboard-layout-editor.com/#/layouts/c8dffc8aa605c2aa97cc53fa987402e9

Spoiler

Without Shift + AltGr values: http://www.keyboard-layout-editor.com/#/layouts/cef808bc3533b47c452af911258f2794

Spoiler

Notes

• 4G toggle at Shift + WiFi can be HDMI-Out on Wifi-only Pyra’s.
• Controls for Key Backlighting, USB, and 4G may be unlabeled.
• Shift + AltGr values will not be labeled.
• Start, Select, and Menu might not have secondary printing on them.
• The Menu key should display the word "Menu" not the symbol.
• Dead Grave and Dead Acute could be labeled like the diacritics on this keyboard.
• For a dedicated Escape key, Menu and Escape could swap positions.
• Hard reset could be Menu + Power + L1 shoulder(use R1 for hard shutdown).
• Forced restart can be Menu + Power.
• Kill tasks manager may be Backspace + Power(or hold Menu for five seconds).
• A list of Compose key sequences can be found here.

Previous April 9th layouts:

Spoiler

• v1(Original from ED's first post): Consolidated and Unconsolidated
  
• v2(Revision): Consolidated and Unconsolidated
• v3(v2 with imagined centered spacebar): Consolidated and Unconsolidated

 

[Grench]

Grench: Why do shoulder modifiers have to be on the other side from the keyboard modifiers? It is perfectly possible to do, say, Shift+A on the Pandora using L1 as Shift, so why would that be different on the Pyra? Also for chording: it is perfectly possible to do L1+R1+something on the Pandora (I use it e.g. for Ctrl-Shift-C/V, to copy/paste stuff in a terminal window), and I expect all shoulder button combinations on the Pyra to be possible as well.

For balance between hands.  I.e. if I'm concentrating on making my left hand hit a shift button, then it's likely my right thumb going for the character.  If my right hand is hitting a shift button, then it's my left thumb going for the character.

My expectation is that if we're going to have modifiers on the shoulders (ala Pandora) and somewhere on the keyboard, then we should move modifiers OFF of the freekin' center column where it requires a vulcan death grip to get to them.  This should help new users AND users who prefer to type without using the shoulders.  (I thought I was the only one until EvilDragon stated he uses it this way too.)

It should make the ergonomics better, typing faster and preserve shoulder & shoulder-less use while placing all modifiers where they're easy to get to by one hand or the other (unlike piling them into the column between the nubs).  It should also make -finding- the modifiers easier for new users.  There is a ctrl and an alt key in one of the zones where they're used to finding ctrl and alt.

There may be argument for swapping sides on my layout for both pairs of modifiers on both the keyboard and the shoulders.  I.e. do a left/right swap so shift and Fn are on the left side of the keyboard, but then I would want to put the shoulder shift and Fn on the right shoulder.  Fn and shift should be paired as they need to be easily chorded for ANY of these keyboards to work properly.

 

[comradekingu]

Look at that in the broader aspect of whats happening when you put the whole sequence into something.

QWERTY is left biased in english, so balancing things other things to 50/50 also is  a question of looking at the bigger picture.

If you want to make typing faster you need the full layout in half the cases.

Typing is really key to making a good keyboard, granted modifier-placement comes at a good second.

Try something on new users before assuming, it is really different from the world of assumptions.

 

[ible]

Since English is left-balanced, it is also kinda nice to put ,. over on the right (and for other reasons, including quick hitting space after them).

I've reduced a layout to no more than three prints per key, which I think helps make the layout look a bit less cluttered:

http://www.keyboard-layout-editor.com/#/layouts/4b09aa1d8ac88b44c0f81a6c4a048a27

Again, balance for coding (combinations such as , :Enter, +=, -=, /=, <=, >= are pretty quick and typically use the same modifier), and I've managed to put - on spacebar, since that is a very commonly used key.  Despite having to press two modifiers for some of the symbols, you can button mash using your left thumb Meta and shift.

 

[codifies]

Oh for a layout that had the control keyboard actually on the keyboard! Rather useful when doing maintenance via SSH on various systems...