It's the keyboard layout.

[comradekingu]

buttoncluster+2 arent keys in the sense that they are buttons. Putting - and + here as + and - just meddles together things that are functionally and keyboard-wise seperated.

The reason why they cant be there as key-buttons, is because if you use them as game buttons, you lose the ability to use them as - and +.

You may want to type - in a game, and many games use - and + nativly. Whereas insert and delete is useless in a game, same with pageup, pagedown, home and end.

The reason why printing insert and delete as + and - doesnt work, is because people may think they are actual buttons, since + and - is close to that area on keyboards.̈́'

The best ive been able to do about it is: 

View attachment 11115

 

[Saber]

Then you have the problem of accidentally meta+q-ing.  Shoulder-operation of anything is not obvious.

Lets say you want to write a big Q, and mistake shift for meta, when they are on the same side shoulders.

Thats the end of your application, and the start of a bad relationship with the keyboard.

There's a bunch of coulds that may happen with the keyboard. Probably a rarer one there comradekingu, but they'll always be something to tradeoff. Not to toot my own horn here, but this is why we should quell our overreliance on the shoulder buttons, as I've done in my proposals v2(revision) and v3(ignore the lowest row's centered spacebar for a moment as it pertains to this discussion), and why two Shift keys and maybe two AltGr keys(as shown with v3) on the keyboard might be a good plan.

Shoulders as backups ideally, at least where Shift and AltGr values are concerned. Tab as one of the smaller face buttons(the lower one like I have it in my other v3 layout in my sig) and Escape where Menu is(with Menu on AltGr + Spacebar). These are some options to ponder.  

Three shift keys (two on the keyboard, one as a shoulder button) is problematic. Three Fn/Meta keys is problematic for the same reason. Modifiers come in pairs, and that's what standard software expects: L_SHIFT and R_SHIFT, L_ALT and R_ALT, L_CTRL and R_CTRL, L_META and R_META. They do not come in triplets. So if you want to have three shift keys, there are only two options:

1. invent a new keycode (say, S_SHIFT, for Shoulder Shift), and configure xkb etc to make it behave exactly like a Shift key. The problem is that lots of software will not recognize it (because it is not a standard key), so it will be hard to map game functions to it etc.
2. map two different physical keys to the same keycode, e.g. left keyboard shift to L_SHIFT, right keyboard shift to R_SHIFT, shoulder shift also to R_SHIFT. 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.

Also, we have a keyboard with less keys than a normal full keyboard, so if you ask me, it makes no sense to make it have more redundant duplicate keys.

Shoulder modifiers are not just a "backup option", they will be the main modifiers for most users. ED is a notable exception. Shoulder buttons are an extremely nice mechanism to implement modifier keys, it is arguably more efficient than how it is done on a normal keyboard, so it is definitely something we should optimize for. Although I agree that there should be a backup option in case you can't easily use the shoulder buttons (like when the Pyra is sitting on a table).

We'll see how it ends up. This might be another getting worked up over nothing situation which tends to happen often around here. There will be two keyboard Shift keys even if both of them must be Left Shift(like you suggested before, remember). 

 

[comradekingu]

From what i understand. You can have left and right alt, and AltGr is different from right alt, even though i cant remember havent seen any keyboard with all 3.

Still not aware of there being a difference between shifts, so for all intents and purposes it can be two instances of the same key.  It worked on the pandora, thats the extent of my knowledge.

 

[_wb_]

From what i understand. You can have left and right alt, and AltGr is different from right alt, even though i cant remember havent seen any keyboard with all 3.

Still not aware of there being a difference between shifts, so for all intents and purposes it can be two instances of the same key.  It worked on the pandora, thats the extent of my knowledge.

Left and Right Shift are different keys, and that's how they are distinguished. That's why you can use the shoulder buttons (one of which is RShift) in PNDManager to navigate between tabs, while still being able to use keyboard Shift  (which is LShift) to enter capital letters when you're writing a comment.

 

[_wb_]

Here's another variant, avoiding Meta+Shift for punctuation symbols, and moving Ins/Del to the action buttons:

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

Obviously more letters get Meta-labels now, but vowels and C N S are still free of Meta-labels so the default mapping could include Ä € Ö Ü ç ñ ß, with some spare room at W, T, Y, I.

Regarding Insert and Delete vs + and -, is there something I miss when it comes to the utility of Delete and, especially, Insert? - deserves to be a dedicated button much more than Insert, and + somewhat more than Delete, judging from my own use on a full PC keyboard. Your placement (previously) of + and - on the action buttons seems, to me, to be a major benefit.

I agree, which is why in my main proposal (http://www.keyboard-layout-editor.com/#/layouts/e1b05961a2c31a6b89288597b9642ae6) I still have (numpad) + and - on the action buttons. I even have this covered:

The reason why they cant be there as key-buttons, is because if you use them as game buttons, you lose the ability to use them as - and +.

You may want to type - in a game, and many games use - and + nativly. Whereas insert and delete is useless in a game, same with pageup, pagedown, home and end.

In my main proposal, you still have the regular - and + at Meta+M and Shift+Meta+Space. Applications and games can tell the difference between regular + - and numpad + -, so there's no issue.

Also, you can turn that argument in either direction: you say that Ins and Del are useless in a game, but I can very well imagine that there are games where you use Ins and Del, maybe to reorganize an inventory or something.

 

[ible]

There will be two keyboard Shift keys even if both of them must be Left Shift(like you suggested before, remember). 

If that really is a constraint, along with the "Only hardware keys for the top buttons", I would do something along the lines of this guy:

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

I don't have a strong preference for the location of the diacritic keys, so I don't mind them being shuffled around, but I'd want everything else fixed .

I designed the layout to do well for coding/mathematical things.

 

[oxym]

This is not going to get much love, I predict. Still, here's my take:

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

It's basically US-International layout with AltGr changed to Meta to avoid three Alt keys. I didn't put any labels for Meta+Letter since I think those could be defaulted to US International altgr combos but be freely reassignable. The main feature is probably the dreaded driver-level modifier Fn, that makes it possible to actually have every key on the keyboard from the software perspective, even if it's behind Fn. As far as I can tell, all shift-combos should be correct as well.

(EDIT: Tried adding numpad keys for completeness, but the site says the layout became too large. Oh well.)

I have a question: how to produce keys like: [ ] ` ' = ;

Pressing Fn + shift produces caps lock

Pressing Fn + meta produces compose

Should a combo consist of caps lock and a letter?

 

[codifies]

@_wb_ re: http://www.keyboard-layout-editor.com/#/layouts/0ae20c3670099feed1b2d636a2b9eeb1


Just a thought as shift is going to be used more often than meta (yes?) Would it not be better on the edge of the keyboard (ie swapped with meta)

 

[bzar]

I have a question: how to produce keys like: [ ] ` ' = ;


Pressing Fn + shift produces caps lock


Pressing Fn + meta produces compose


Should a combo consist of caps lock and a letter?

By doing Shift-Fn, not Fn-Shift. If you consider this from the driver's point of view it makes perfect sense. I have considered taking the Fn-combinations out of the modifier buttons to get rid of this issue, though they are very conveniently placed in their current location. OTOH caps lock is already shift-shift, and compose could live elsewhere.

EDIT: Shift-shift caps lock is a bit bad though, since it's not actually 100% compatible with US International. Maybe I'll just put caps lock and compose on some non-modifier keys with Fn.

 

[_wb_]

@_wb_ re: http://www.keyboard-layout-editor.com/#/layouts/0ae20c3670099feed1b2d636a2b9eeb1


Just a thought as shift is going to be used more often than meta (yes?) Would it not be better on the edge of the keyboard (ie swapped with meta)

Yes, that makes sense I guess. Not sure if Shift is actually going to be used more often than Meta, I suppose it depends on the use pattern. I'm also not sure if the edge keys are really much easier to press than the penultimate keys. But obviously you can easily modify my proposal to swap Meta and Shift, and if other people also think that it would be better, I'll change my 'official' proposal accordingly.

I personally don't care much about the keyboard Shift and Meta since I would use the shoulder buttons all of the time.

Meanwhile, here is another variant of the above: http://www.keyboard-layout-editor.com/#/layouts/7b64346876b1c5a3a051ae8a7c9b0a7e

I'm a bit torn between layouts that have { } : ? as shifted [ ] ; / like on a normal keyboard, and layouts which have them separately, like on the Pandora. Avoiding Meta+Shift combinations is slightly more efficient, but it comes at the price of having more pre-defined Meta+letter combinations, and less out-of-the-box compatibility with DOSBox/Qemu etc. With an easily mashable keyboard Meta+Shift combo, and hopefully an easy to perform L1+L2 shoulder Meta+Shift combo, I think the efficiency difference might be small enough to still prefer layouts where { is Shift+[ etc, but I'm not completely convinced in either direction.

 

[codifies]

How would you press control C if placed on a desk?

 

[Wally]

How would you press control C if placed on a desk?

You plug in a keyboard.

 

[codifies]

How would you press control C if placed on a desk?

You plug in a keyboard.

defeatist !

 

[_wb_]

How would you press control C if placed on a desk?

SELECT+C. Like on the Pandora, START and SELECT are L_Alt and L_Ctrl respectively.

Also, I expect that at least one pair of shoulder buttons should actually still be usable, albeit somewhat inconveniently, when the Pyra is placed on a desk.

 

[bzar]

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

Updated, moved caps lock and compose away from modifiers to remove confusion regarding modifier pressing order. Now modifiers can be pressed in any order before the modified key for thje same result.

I considered swapping Fn/Meta and comma/period to be more in line with pandora, but decided having Fn on the opposite side of the most used Fn-modified keys is more important. Moving only one of comma/period would also be weird.

For shoulder button modifier people all the Fn-modified keys can also be mapped to Meta-combos, so you'll get the best of both worlds

 

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

 

[_wb_]

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

Updated, moved caps lock and compose away from modifiers to remove confusion regarding modifier pressing order. Now modifiers can be pressed in any order before the modified key for thje same result.

I considered swapping Fn/Meta and comma/period to be more in line with pandora, but decided having Fn on the opposite side of the most used Fn-modified keys is more important. Moving only one of comma/period would also be weird.

For shoulder button modifier people all the Fn-modified keys can also be mapped to Meta-combos, so you'll get the best of both worlds

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.

 

[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