Current Keyboard Layout


So - do people still hate using the Fn layer of the left game pad (Pyra arrow key equivalent) as screen and keyboard brightness controls?  Or is that OK now?
I like it as a solution until it starts interfering with what I am doing.  As ck said, shoulders+dpad will cause problems, and this is not an unreasonable combination in a game, so it is probably better to not do it.  All of our options are going away, so we'll probably end up with either brightness + and - as 2 keys, or a combo, if you can convince ED.  Someone come up with something different that hasn't been thought of.
 
Last edited by a moderator:
So - do people still hate using the Fn layer of the left game pad (Pyra arrow key equivalent) as screen and keyboard brightness controls?  Or is that OK now?
I like it as a solution until it starts interfering with what I am doing.  As ck said, shoulders+dpad will cause problems, and this is not an unreasonable combination in a game, so it is probably better to not do it.  All of our options are going away, so we'll probably end up with either brightness + and - as 2 keys, or a combo, if you can convince ED.  Someone come up with something different that hasn't been thought of.
I like how on chromebooks/macs the arrow keys act as home/end and pgup and pgdown with the FN button... however I'm not playing games on the arrow keys of these devices. On a gaming geared device I don't see it as the best situation, especially when some are talking about Fn modifiers on shoulder buttons that can be accidentally hit during a tense moment in a game or what not.
 
Last edited by a moderator:
How bad would it be if Fn was NOT on a shoulder button? Are there no alternatives (like MENU)?
 
Please keep Fn on the shoulders. There are people like me who will try to increase the workflow by using shoulder buttons outside of games.
 
Why the need to reinvent things. AltGr guys, AltGr. People know how to use it, its meant to do what it does.

F-keys with shoulders is an abysmal issue over being able to type for more people, with more functionality.

Thats before you start considering all the problems it creates.
 
I don't believe splitting the alternate symbols on the default layout between multiple modifiers is really going to solve anything.   And even if we would do that, I would then want both those modifiers on the shoulder buttons, as it makes it a lot easier to chord the required modifier(s) with any given keyboard key than if the modifiers are only available on the keyboard. 

I would actually prefer to use Fn/meta/sym/whatever for all symbols and keep right alt as right alt,  (as opposed to enabling alt-gr) so as not to lose the advantage of having both the symbol layer modifier and Alt available on shoulders.   That would mean I could (for example) press Alt-F4  on Fn with the left index finger, Alt with the right index finger, and 4(if that's where F4 ends up) with the left thumb.   Much easier that way than switching to a one handed grip. trying to do multiple finger acrobatics with one hand while holding the unit with the other to key the combo, then switching back to a two handed grip. 

-Neelix
 
Symbols are on two modifers anyhow, you are just not lumping thirdlevelshift and alternate graphics in with Fn. Meaning you can actually do thirdlevelshift, and alternate graphics, like on a real keyboard.

And yes, with Ctrl Alt and Shift AltGr on shoulders you are getting both shift type modifiers.

R alt is something only found on US keyboards, putting symbols that belong on other buttons on letters has just as little to do with that as anything else.

There are many ways to technically have more Alts and AltGrs. L and R alt is two, out of two needed alts, but there was two of that anyhow.

 With the keycode being different for the two AltGrs you could pass the same Thirdlevelshift and hope, which is not as good.

The best way however is to set it up with something entirely different and unencumbered like BTN_MODE 0x13c. Which all things considered is far less of a hack than having two Fns, that mostly do things Fn should not do, and where the things it should, doesn't work, along with a number of other things that are problematic and limiting.
 
Last edited by a moderator:
Symbols are on two modifers anyhow, you are just not lumping thirdlevelshift and alternate graphics in with Fn. Meaning you can actually do thirdlevelshift, and alternate graphics, like on a real keyboard.

And yes, with Ctrl Alt and Shift AltGr on shoulders you are getting both shift type modifiers.


R alt is something only found on US keyboards, putting symbols that belong on other buttons on letters has just as little to do with that as anything else.


There are many ways to technically have more Alts and AltGrs. L and R alt is two, out of two needed alts, but there was two of that anyhow.

 With the keycode being different for the two AltGrs you could pass the same Thirdlevelshift and hope, which is not as good.

The best way however is to set it up with something entirely different and unencumbered like BTN_MODE 0x13c. Which all things considered is far less of a hack than having two Fns, that mostly do things Fn should not do, and where the things it should, doesn't work, along with a number of other things that are problematic and limiting.
And...  Sorry to be blunt, but you have just shown, again, that despite using an AltGr based keyboard in your daily life, you don't actually understand how it works.

I need a keyboard map for use in this example.  The statements, however, should be applicable to any of the keyboard maps made.

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

Any AltGr keyboard requires a given number of base keys.  Think the unshifted-unFn top level layer of the keyboard in front of you now - regardless of which kind or flavor it is.  Those are the base keys.  Press the 4 key and it receives 4.  For the purposes of this discussion, 4 is the base key.

Shift does not modify the base keys - those are still present, but the computer receives two signals to 'use' them.  The base key Rshift is held down and the base key 4 is pressed which signals as $.

Fn works somewhat differently.  Instead of returning a modifier of Fn is being held and 4 was pressed, Fn actually tells the computer, "I have two base keyboard maps and I am activating the second set of base keys."  With Fn enabled on the above (or any) layout, the Fn layer symbol is returned as a raw base level symbol - in this case it is €.  Not, "Fn is being held and 4 was pressed', but € as if € was a base letter all it's own.

In this way, Fn expands (doubles) the number of 'base' keys present on the keyboard by creating a 2nd 'Fn layer' virtual keyboard.

AltGr works just like shift.  It -requires- base keys in the keyboard definition to all exist in order to have a base key to modify.  The computer doesn't see the base key, but sees that 'I am in AltGr active mode and AltGr + 4 is pressed.'  If the base key that AltGr is expecting is on the Fn layer, that is OK as the Fn layer is seen as a different keyboard.

The Pyra does not have enough physical keys to give a complete base key set for any standard keyboard definition.  AltGr simply will not have enough base targets to function without a Fn layer/logic present.

To make things a step more difficult, all of the broken symbol pairs create a set of quasi-base keys that aren't actually base keys - they're something of our own invention.  If the keyboard definition used in Debian is US English, the AltGr version of that keyboard would be US International.  US International under AltGr expects it to look just like this - with ALL of those base keys present AND no additional base keys beyond those:

http://www.starr.net/is/type/intlchart.html

Remember, Fn creates a 2nd logical set of base keys.  This is VERY useful if you want to use AltGr mode on a Pyra, because the Pyra itself does not have enough physical keys for all of the base keys needed.  It MUST use a Fn layer keyboard logic in order for those additional 'base keys' to exist.

Now, I also mentioned symbol pairs above.  Symbols mapped OFF of their base, i.e. giving { it's own key on the Fn layer instead of it being shift+[ results in a base key being present that AltGr won't recognize as one of it's modifiable bases.  It may not be a big deal that AltGr+Fn+{ does nothing.  But that does not escape the reality that AltGr+Shift+key IS a very true reality.

Look at the US International standard keyboard again.  Look closely at the 4 key.

http://www.starr.net/is/type/intlchart.html

You will notice that it has 4 markings on the US International Standard AltGr layout.

normal 4 = 4

Shift + 4 = $

AltGr + 4 = ¤

AltGr+Shift+4 = £

That type of usage of two modifiers to create 4 symbol outputs per key is going to look very familiar to many of you.  Every additional modifier key doubles the number of results a given non-modifier key can return.  In the case of the Pyra, each key can produce values with any combination of held presses of LShift, Rshift, LCtrl, RCtrl, LAlt, RAlt(AltGr), LFn, RFn, LSuper, RSuper(LidSwitch).  That means every non modifier key has 1 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 = 2^10 = 1024 potential logical combinations/outcomes PER non modifier key.

So, to summarize, AltGr ONLY exists when it is activated.  When AltGr is activated, the RIGHT Alt key changes definition to AltGr.  AltGr works JUST LIKE SHIFT does and the computer sees a series of co-events during it's use.  "AltGr is being held and 4 is being pressed, that resolves to ¤."  Additionally, it is true that if, "AltGr is being held AND Shift is being held and 4 is being pressed, that resolves to £."

Fn works entirely differently from AltGr and Allows a full 2nd keyboard 'base map' (Hardware based or software driver based) which Shift and AltGr can further use as a base map to give conditional output.  Fn simply doubles the number of non-modifier base keys available.

I hope that helps your understanding of how and why Fn and AltGr are not only different but how each necessarily must function differently from the other.  

AltGr and Shift both require a base key to operate on.  Fn creates additional base keys.
 
Last edited by a moderator:
Phew, okay, I read through A LOT of suggestions, thought my own stuff about them, and modified the keyboard layout again.

Here you go:

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

So, why did I put what where?

Well, the F-Keys make more sense on the numbers in my opinion as well. That's why I moved them there.

I added _wb_'s layout to include french stuff roughly where they expect them (I guess those symbols will also be useful for Spanish users, etc.).

I also switched to his "DosBox-Cheat"-Keyboard, as all keys can still be reached comfortably in normal usage as well.

ESC has been moved to Tab (not to Q, even though Q sounds more plausible), simply because I like how easy it is on the Pandora to blindly find ESC (first key on the left).

Additionally, I can't think of any confirmation where Tab and ESC needs to be used at the same time.

Please correct me when I'm wrong here :)

I also changed the names of the modifiers to reflect the actual keys (as far as I know, "Fn" is no standard modifier key on a keyboard).

Note: This is JUST so we know while designing what key it is, we can still use Fn printed on the keyboard if this is easier to understand for normal users (most of them probably don't know what META means).

META and SUPER should be configured in the layout to have EXACTLY same effect on the keys.

But as they are two different keys in reality, games and software can use them as different keys and some power users can also change the layout so that the SUPER key has other symboles as the META key, if they like.

The Menu button should open the Menu on the desktop (which makes sense ;) ) and I also put INS there for a reason:

When you are in the terminal, SHIFT + INS and CTRL + INS can easily be pressed, as you can easily press two buttons beneath each other with one thumb.

Sooo.... what do you think?

Did I miss something?

I hope I haven't forgotton a letter or symbol...?
 
I don't like the idea of conflating super and meta like that,  as they are different modifiers.  Each symbol would need to be mapped twice, and it would significantly reduce the potential usefulness of including both.

-Neelix
 
I don't like the idea of conflating super and meta like that,  as they are different modifiers.  Each symbol would need to be mapped twice, and it would significantly reduce the potential usefulness of including both.

-Neelix
Eh? So you'd like to lose one more modifier, simply because you don't like them being mapped twice (which you don't even need to do, as it will be the default in our OS)...?

Did I miss something?
Is the - key on the right a GPIO connected to a hardware interrupt? Because if not SysRq is useless.
Ah, it NEEDS to be a hardware interrupt?

Well, thinking about that makes sense, right... so one thing to fix here.
 
Where are backspace and delete?  I am guessing they are the 2 small unmarked gaming buttons.

The Super/Meta problem is that it makes difficult for those that use them as different keys since they are only on either a shoulder (so the shoulder key must be used, so no access if not in the hands) or on the keyboard (so no shoulder access, and it is harder to get that layer of symbols on the right hand side where the Meta key is located with just a thumb).

The Menu key is typically the right click menu, which can be accessed by clicking the left nub.  I personally feel that Super is a better option where you have Menu, but this will probably cause problems for Insert.  I will try to think of a way to move everything around.
 
K and L seem to have the same character produced with meta.

Edit:  Will meta be sticky?
 
Last edited by a moderator:
Ah, it NEEDS to be a hardware interrupt?

Well, thinking about that makes sense, right... so one thing to fix here.
Yeah, unfortunately. That's the whole point, that no matter what the system is stuck doing, even if the CPU is running 100% or the kernel itself crashes, you can hit the switch and it jumps immediately to a known good location to execute whatever the request is.You can still put it on an Fn layer, the "base key" would still trigger the interrupt but the interrupt would then check to see if the Fn key is also being pressed (directly, via GPIO reading) and return immediately if it isn't.

For safety you can go one step further, like you need to hold all four shoulder buttons when pressing the SysRq, and then whatever you press next is the magic command to execute. But that's some specifics we don't need to work out now, the important thing is that whatever button it goes on needs to be an interrupt.
 
Where are backspace and delete?  I am guessing they are the 2 small unmarked gaming buttons.
Yep, those are the normal symbols for those two.

The Super/Meta problem is that it makes difficult for those that use them as different keys since they are only on either a shoulder (so the shoulder key must be used, so no access if not in the hands) or on the keyboard (so no shoulder access, and it is harder to get that layer of symbols on the right hand side where the Meta key is located with just a thumb).
Well, yes, but it's optional.

Usually, Super and Meta are the same here, unless someone decides to change the keyboard layout.

So your concern is only an issue if someone actually DOES that (and uses keys that are hard to use in that case).

Instead, you want the same modifier on both buttons, which doesn't change anything for the default setup, but takes away the ability to actually USE them as two different modifier keys.

The Menu key is typically the right click menu, which can be accessed by clicking the left nub.  I personally feel that Super is a better option where you have Menu, but this will probably cause problems for Insert.  I will try to think of a way to move everything around.
Can a modifier key easily used for a menu function on XFCE / KDE / Gnome / whatever?

I wanted to keep ALL modifier keys as modifier keys, not misuse them for such functions.

And the Menu button does not necessarily have to be mapped to right click - this can be changed with the default setup.

Having it as right click doesn't make sense anyways, as the left nub is not far away.
 
 


The Super/Meta problem is that it makes difficult for those that use them as different keys since they are only on either a shoulder (so the shoulder key must be used, so no access if not in the hands) or on the keyboard (so no shoulder access, and it is harder to get that layer of symbols on the right hand side where the Meta key is located with just a thumb).
Well, yes, but it's optional.
Usually, Super and Meta are the same here, unless someone decides to change the keyboard layout.

So your concern is only an issue if someone actually DOES that (and uses keys that are hard to use in that case).
Instead, you want the same modifier on both buttons, which doesn't change anything for the default setup, but takes away the ability to actually USE them as two different modifier keys.
What you suggest works afaik.  I think some of us prefer being able to have Super where you have Menu since we can do more with it.  I regularly use Super on most of my computers.  I don't know if Menu can be used the same way (probably can, never thought to try).  I don't fully understand your reasons since it is different from my way of looking at it (I can fully use both Meta and Super on the keyboard section), so I will leave that alone for now.  

Are you open to possibly moving Super off the shoulder?

The Menu key is typically the right click menu, which can be accessed by clicking the left nub.  I personally feel that Super is a better option where you have Menu, but this will probably cause problems for Insert.  I will try to think of a way to move everything around.
Can a modifier key easily used for a menu function on XFCE / KDE / Gnome / whatever?
I wanted to keep ALL modifier keys as modifier keys, not misuse them for such functions.

And the Menu button does not necessarily have to be mapped to right click - this can be changed with the default setup.
Having it as right click doesn't make sense anyways, as the left nub is not far away.
I don't know about all of them.  For KDE there is ksuperkey that uses Super to open the menu, and remain as a modifier (I don't use this).  There are probably better ways.

What you said about the Menu button/right click is exactly what I was concerned with.  As long as it isn't just the right click menu it doesn't seem like a waste.

If SysRq won't be useable then we can use that for something else, maybe Backspace (what are the problems associated with this?).  I suspect some people may not like having Meta sticky by default to access this since it will open up Esc and other keys to more accidental presses, but making it sticky should be an option in settings.  Since there will also be a shoulder button to get that layer it shouldn't be a problem.  Insert can be put back on the gaming button, which means nothing else on the Menu key, which can be turned back into Super.  Or it can remain Menu/Ins and we have an open button.

Did I miss discussions about the Usr key?  If it is set by the user I guess I can make that Super.
 
Is the key below the key below the A gaming button the delete key? I'm just unfamilar with the symbol, what  is it?

Well, it is as ED already said.

Did I miss something?
Is the - key on the right a GPIO connected to a hardware interrupt? Because if not SysRq is useless.
Maybe it's a stupid question, but isn't usally every keypress a hardware interrupt? Otherwise CPU time would be wasted for polling the keyboard over and over and over again.
 
Last edited by a moderator:
Ah, it NEEDS to be a hardware interrupt?


Well, thinking about that makes sense, right... so one thing to fix here.
Yeah, unfortunately. That's the whole point, that no matter what the system is stuck doing, even if the CPU is running 100% or the kernel itself crashes, you can hit the switch and it jumps immediately to a known good location to execute whatever the request is.
You can still put it on an Fn layer, the "base key" would still trigger the interrupt but the interrupt would then check to see if the Fn key is also being pressed (directly, via GPIO reading) and return immediately if it isn't.


For safety you can go one step further, like you need to hold all four shoulder buttons when pressing the SysRq, and then whatever you press next is the magic command to execute. But that's some specifics we don't need to work out now, the important thing is that whatever button it goes on needs to be an interrupt.
Then why have I used magic sysrq fine on a USB keyboard?


EDIT: And make sure this feature works:

106.jpg
 
Last edited by a moderator:
Back
Top