It's the keyboard layout.

[WizardStan]

This means it is impossible to distinguish those two keys (e.g. shoulder shift and right keyboard shift). This also means it becomes possible to have 'impossible' sequences of key events, e.g. two [R_SHIFT DOWN] events following one another without a [R_SHIFT RELEASED] in between, which will cause some software to get confused.

If you make both keyboard shifts the same then we do two things: minimize the chance of both keys being pressed at the same time; and minimize the impact if they are. The confusion that applications could experience is thinking the key is not pressed anymore even though one of them still is. When they're on the keyboard, your use case could lead to "I pressed both shifts, released one, and now I'm hitting a letter but it's only giving me a lower case. Boo" while if one is keyboard and one is shoulder you get "I was keeping my shield up with the L trigger and accidentally hit the keyboard shift with my thumb and now my ship is explodey". If the first happens it can be written off as a fluke. If the latter happens it will be judged extremely harshly. You don't mess with a gamers buttons.

 

[_wb_]

This means it is impossible to distinguish those two keys (e.g. shoulder shift and right keyboard shift). This also means it becomes possible to have 'impossible' sequences of key events, e.g. two [R_SHIFT DOWN] events following one another without a [R_SHIFT RELEASED] in between, which will cause some software to get confused.

If you make both keyboard shifts the same then we do two things: minimize the chance of both keys being pressed at the same time; and minimize the impact if they are. The confusion that applications could experience is thinking the key is not pressed anymore even though one of them still is. When they're on the keyboard, your use case could lead to "I pressed both shifts, released one, and now I'm hitting a letter but it's only giving me a lower case. Boo" while if one is keyboard and one is shoulder you get "I was keeping my shield up with the L trigger and accidentally hit the keyboard shift with my thumb and now my ship is explodey". If the first happens it can be written off as a fluke. If the latter happens it will be judged extremely harshly. You don't mess with a gamers buttons.

I agree with that logic. Still, it's a pity if you can't distinguish the two keyboard shifts. Although the Pyra has more game buttons than the Pandora (two more shoulders, two more action buttons), it still could be the case that not every game action can be mapped to game buttons. In that case, the keyboard keys can be useful extra keys. In particular, the keys at the edges are good candidates for additional game actions, since they are easy to find. Not being able to distinguish the two keyboard shifts would mean that they can only be mapped to the same thing, so you lose one "good" key.

Also if two keyboard Shift keys are considered useful, why not two keyboard Meta/Fn/AltGr keys? After all, by the same logic, it would be hard to produce Meta/Fn/AltGr combos with keys that are on the same side as the modifier.

My position remains the same: I want exactly one keyboard modifier and one shoulder modifier of each. The shoulder modifiers are the most efficient mechanism, but if for whatever reason you don't want to use them, there's still the keyboard modifier. You can make the keyboard modifiers sticky, that should help with same-side combos. We should provide easy configuration options to make keyboard modifiers sticky. But there's no reason to waste a perfectly fine key on a third Shift key.

 

[bzar]

So basically you would map all the Meta-keys to do exactly the same as the Fn-keys (so you can also use the shoulder button). But what happens then if you want to use F-keys in a game that also uses the shoulder buttons? How does this solve any problem?


To me, being able to input F-keys and punctuation symbols with just one thumb press per key/symbol (that is, using shoulder modifier(s)) would be a very important advantage of the Pyra keyboard compared to the Pandora one, and since we have four shoulder buttons, it should be possible. So all the labels you have as Fn labels, would have to be also mapped as Meta-combos. But then why still have Fn? Yes, I understand the difference between Fn+5 (which would send a low-level F5 event) and Meta+5 (which would be seen as a Meta event and a 5 event, and xkb or something like that would translate that to F5), but this will just confuse everyone if you do it like this. Either Meta or Fn feels redundant here. Of course you could use them in different ways to, e.g. Meta+O is Ö while Fn+O is [{, but then you lose the shoulder button method for one of them.


If you only have Meta, it should still be possible to let R_Meta (the shoulder button) do something else than L_Meta (the keyboard Meta) in those rare cases when you have an application that uses both L2 and the F-keys or punctuation symbols. You can still use Super or one of the Alt keys if you need more layers of symbols. I really don't think it's a good idea to have both Fn and Meta, it creates more problems than what it solves.

Optionally, yes. Not by default. It's an option for someone who wants to input all the characters in Fn-combinations using a shoulder button.  F-keys in that game would be used with Fn. Meta is not intended to be used as a secondary Fn. Meta is used for user-mapped keys. If you want to map all the Fn stuff behind meta that's your use case. By default I think it should map to US International AltGr mapping.

I understand the issue of sometimes needing to use Fn- though by mapping most of the Fn keys through Meta fixes most of these -but it's just an artifact of the priorities in this layout. I have not found a way to please all these concerns at the same time: full compatibility (has every key a US International keyboard has as far as software is concerned), game button independence and shoulder button modifiers. Since full compatibility is the main feature of this layout, I won't compromise it for any other. To achieve that, a Fn key is required. Because people, like me, will want symbols not on US International layout on their keyboard, I have a second primary feature of a user-mappable modifier. That's Meta.

Oh, and I noticed since there's so much nice space on the letters for Fn combinations, I'll put the sysrq/pause/prtscr there and repurpose the top button fn combos for their original purpose (HW keys). Also had space for one more primary key, which for now I made an "airplane mode" key. It should probably have a confirmation dialog

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

This is fun

 

[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.