Current Keyboard Layout


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.
There are usally two different super keys on a standard keyboard: Super_L and Super_R. So one could be a modifier and the other could bring up the menu. (Well, I have them configured on my desktop to do differnt things, so yes, it is very possible)

Maybe you could move MENU or INSERT to META+DEL, and put SUPER_L there. SUPER_L would be no modifier, but just brings up the menu. Then the other Super Key would be SUPER_R, which you can configure as a modifier.

INSERT on META+DEL would make sense in some way, but as you had your reasons to put it where it is now, how about you put MENU on META+DEL?
 
Last edited by a moderator:
Ahh, you can use Super as normal key as well? Didn't know that, thanks for the info. I thought modifiers can mostly only be used in combination with other modifiers (I don't know if you can assign a hotkey to simply ALT without any additional key presses in KDE, e.g.)


Then I've got no problem moving it to the "Pandora"-Button.


What would you put on the shoulder though? Is there a Meta-R as well?


Or should it create the same keycode as the Meta on the bottom right?


About sticky keys:


Not sure we should use Sticky keys on something like shoulder buttons... wouldn't that heavily affect games?
 
What would you put on the shoulder though? Is there a Meta-R as well? Or should it create the same keycode as the Meta on the bottom right?
Hi, i think there are Meta_L and Meta_R : https://wiki.ubuntuusers.de/xmodmap#Spezielle-Signale
Or, since it is Linux we're talking about here, rather refer to:

/usr/include/linux/input.h

from row 200ish onwards... or use Find to look for KEY_ESC (which is scancode 1).

Most (but not all) from that point onwards are free game.

Aside from the regular 0-9, a-z and selected punctuation (i.e. US layout ones) you have lots of "interesting" "free" stuff starting from code 113 onwards. Some familiar-from-PC ones are scattered also after that point (keypad comma, for example).

Note: you cannot find, for example "Super" from these.

No need - if you're a total nutcase you can make code 30 (KEY_A) super and code 151 (KEY_MSDOS) an A with loadkeys or xmodmap:).

X has (talking of xmodmap here...) 8 modkeys. Call 5 of them what you want: super, meta, mommy. For X they are shift, lock, control, Mod1-5.

run

xmodmap -pm to see your bindings.

Again: (almost) any code (key) can be almost any mod depending on whether you're on a PC or DEC X terminal...

xmodmap limits configurability of mod combos. xkb, to my understanding, does not and has even more mods. But using xkb at this level means xmodmap must never be invoked for obvious reasons. I wish to study xkb soonish, but time has been too restricted - it is ocean deep :-(.

Linux console oneups X when it comes to mods: 9 mods, all named, but in truth linux distros never use other than the first 4: Shift, AltGr, Control and Alt. The rest, though named "dangerous sounding" are actually just Mod1-5 like in X. There is a big difference to xmodmap, though: no restricctions to mod combos. Also Linux inherits a lot of "codes" from VT100 in which the "code" is not a "code", but a control string... something to keep in mind...

Since some punctuation is planned to be typable with only Fn-modifier, input.h does not have a dedicated code to some symbols. So it will be a bit of a "faked" solution in any case.

For example, in the Pandora, the keycode that generates @ is KEY_Fsomethingoranother, because there is no KEY_@ in input.h.

It could just as well have been KEY_MAIL. There is some danger in using those "multimedia" keys for characters - if some X window manager bypasses X completely when reading input and assumes KEY_MAIL should launch Thunderbird, then Thunderbird is go every time you press @. But that is really a nonissue, because you have to build a product with some assumptions and must assume every Jack and Jill's own WM cannot be supported out of the box!

If you were building a Windows box things would be totally, very. utterly hard in this respect!

So, what does all this mean:

check /usr/include/linux/input.h

Keycodes that are not instantly familiar are basically free game to call what you wish:

KEY_COFFEE --> powerswitch

KEY_HOMEPAGE --> SUPER_L

KEY_MENU --> SUPER_R

240 something keycodes, some reserved, some should be treated as reserved (not having KEY_A produce an A by default is just dumb!) but most are what you want to make of them!

At the end of the day they are all just a bunch of integers, right?-)
 
Then why have I used magic sysrq fine on a USB keyboard?
Your PC has a bios, the bios reads the keyboard and triggers the interrupt, same as it always has regardless of whether its PS/2 or USB.
Otherwise CPU time would be wasted for polling the keyboard over and over and over again.
It's been a long, long time since I had to think about this stuff at all but I'm pretty sure this is still correct.The keyboard has its own CPU and memory which buffer keys as you press them and sends a signal to the PC saying that data is ready. The PC then accepts the signal and asks the keyboard to send the buffered keypresses. On a desktop the BIOS handles the data ready signal and triggers a software interrupt in the OS. It also handles the SysRq key and triggers a different interrupt if it is activated.

The Pandora/Pyra doesn't have a BIOS, and the keyboard matrix is (to the best of my knowledge) just a bunch of GPIOs, meaning there isn't a separate CPU for the keyboard, so the only way to get the data is to poll for it, same as what the keyboard CPU would have been doing.

But that's not to worry, it's a trivial amount of CPU. What's a few hundred instructions to a system that can execute millions and billions of instructions per second?
 
K and L seem to have the same character produced with meta.
Seen that as well. If there's free space, we should add " ë ", " ä " or " ¨ ".

What about putting ESC on Pause or PrtScr ? This would still quite be on the upper left corner, plus it could become a dedicated key. I'm no Linux expert, is Pause a heavily used key ?

Maybe we could put SysRq on USR1, make USR1 its modified key, and put USR2 on the modified " - ". Maybe we should also move F11 to that place, and put USR2 on the modified " P ".

And as I said before, I'd rather we change the shoulder positions :

R1 = R-Ctrl and R2 = AltGr. This way L1 and R1 would be the main keyboard functions, L2 and R2 the side characters selectors, L1 and L2 the main character modifiers.
 
Last edited by a moderator:
We can have L_Meta and R_Meta, L_Super and R_Super. Those are four different keys, they can in theory give 2^4 different layers (if you want to, you could let L_modifier do something else than R_modifier).

I would put the "Fn" layer on Meta, with L_Meta on the keyboard and R_Meta on the shoulder button (like I said, power users can make them different if they want to, but the default would automatically be that they do the same thing).

I would map the MainMenu key (not to be confused with the ContextMenu key) to L_Super; this is the default anyway in most desktop environments (note that you can still use L_Super as a modifier, it can be combined). I would put it in the same location as the Pandora button (below START/L_Alt and SELECT/L_Ctrl), and label it with a Pyra logo. We could let the lid be the R_Super key (lid closed = R_Super held down, lid open = R_Super released). This makes it super easy (no pun intended) for applications to detect lid events and lid status. E.g. if you want the shoulder buttons to do something else when the lid is closed (e.g. media buttons), then you just define shortcuts of the form Super+[shoulder button], and then you can access the media buttons directly when the lid is closed (since R_Super is automatically held down when the lid is closed), or as a combo (L_Super + [shoulder button]) when the lid is open.
 
So I'm looking at the current proposed layout, and im thinking there is a discrepancy between the goal of working for everyone, and the results it delivers.

For any language not using A-Z it doesn't work as well as English does.

For English users, there are foreign symbols, which considering they are largely monolingual, is unfortunate. And there are less familiar keys on the right side [ { } ]

For German users extra provisions are also made, but its not in the right orientation compared to a german layout, also its ö ü ü.. missing the ä

Its probably to get French closer to almost where it should be, but in my opinion both of those fail at even being a subpar way to write, on account of cancelling each-other out.

For French, on the part of their layout that isn't skewed, its not on the right buttons, it should be numbers. And considering its a one button+another button affair anyway, that is worse.

So all in all its forgetting how half of the audience types, and annoying the remainder. No typewriter or keyboard has ever gotten away with the former. JIT ANSI and ISO keyboards are for language compatible on the functional level.

For the people functional typing cant be incorporated for, on the current proposed layout, there is no language layer, leaving out greater europe, or anyone willing to type in this manner by doing some changes to it.

Efficiency is made worse by moving , and . to the opposite side of enter and shift. When that is where space is, it seems like a given , and . should be there, lest we forget , and . actually belong on the right.

Being able to find backspace, especially with that symbol, is both strange when you know about it, and something that fails when you dont.

Novices are lost when Fn, or Meta deals with symbols, this could have been directly familiar to half the audience with AltGr, instead its reminiscent of a bad feature of mobile keyboards, and none of the real ones.

For advanced users, the alternate graphics are gone. I don't think all of that is better typing of F-keys. Especially considering there are accidental things to be had, the latest is if you want to alt+tab out of a game, you forget which shoulder is which and Fn+(tab)esc.

For nobody symbols on letters is more familar, yes, even the ones used to mobile devices too.

And for everyone, it looks cluttered. Who are we left with to benefit when this should fit everyone?

Esc is inefficient since if you use keyboard only (like i imagine most people type, (similar to a pandora where they were shoulders were similarly unmarked) or at least they do when its on a bench) ties up both thumbs at the worst positions.

Having tab a little better positioned compared to a normal keyboard turns out to be slightly more familiar, but is the one button that should be on the opposite side of something, namely dpad. On a regular desktop keyboard one hand can do arrowkeys, and the other can do tab. With the tab bottom left, albeit not as elegant, you can palm it with the base of your thumb and still use the thumb for tabulator, then have the other available for backspace. Quite nice for cleaning up code or similar.

Select Start is in the wrong correct orientation.  (i should proofread more closely)

There are a bunch of other things like Fn mediakeys, shift+combos and altGr+combos etc to consider losing too.

I know a lot of these are accepted as legacy solutions, not noticed as drawbacks to a lot of people, but still here we are, with the demographic most likely to be in favour of them, talking about other people.

In terms of design, thats a poster saying Bidoofs only, party at 9.

Test it on those other people, on its own or agaisnt this, if you want to piggieback on my research. In my opinion and experience pandoralayout, and especially the current proposed one, works for some people who it is not worse for to incorporate more people. And as clearly as it can be put, the current proposed layout is broken right now for those people.

There is a huge market for keyboards on mobile devices these days, TOHKBD, which is for a relatively old and obscure phone, did so with a keyboard alone.

Catering to the people who buy them, with different layouts, for a smaller project, could never have been done without having more keys than A-Z. Keymats pay for themselves, twice over.
 
Last edited by a moderator:
German ä is missing (I guess it belongs where there is one ü too much) and the § is missing, but Id say its used rare enough to not put it on the keyboard. nvm Im blind

I like how we come to an end, and I like the layout.
 
Last edited by a moderator:
Yes, for germans it might be easier to mime this orientation by putting

 ü

ö ä

on

 o

k l

and then the à on j

EDIT: But it could be confusing, when the umlaut on "o" is not ö

EDIT2: The alternative is to arrange them in äöü, like they are in the alphabet.
 
Last edited by a moderator:
Does my Pandora have a BIOS too? I've used magic sysrq on my pandora. :p
No, in that case it'll be handled by the kernel; if the keyboard driver crashes for any reason your SysRq key will stop working.
Exactly. This is how it has worked all the way since the PC AT. Any magic is done by the OS and it has no dedicated hardware interrupt. Some ancient BIOS:es handles the key in some way. However, the BIOS is not active once the CPU is switched into protected mode and can only be reached by the OS intentionally dropping back to real mode, or by switching to v8086 mode.
 
Thanks for making some nice changes, ED!  much improved, IMO.

commenting on this one:

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

super should not be on the shoulder buttons, but another "Meta" should be there instead.  I like _wb_'s idea of putting Super on the bottom middle button in the gaming cluster, and using lid-close/open as another Super.

there are two u umlauts, which seems redundant, but i suspect one of them is supposed to be a umlaut.

i also would argue for Ctrl on R1 (swapping with Alt), since I suspect to need that more often than I need Alt, so it makes more sense as the primary.  (it then also makes sense that both secondary shoulder buttons yield different key-codes in general when hitting things; L2 for meta, R2 for altGr.)
 
Last edited by a moderator:
Not sure we should use Sticky keys on something like shoulder buttons... wouldn't that heavily affect games?
I don't know if they can be made sticky individually to prevent any issues on shoulders.  When I look at my settings in KDE all modifiers are either sticky or not, with seemingly no difference between between L and R modifiers, or Super, Alt, Ctrl, Shift, Meta (which I don't think I even have on my keyboard), etc.  Just one setting for all of them.

It appears to be a setting that is included with the DE, and can be off by default.  I don't know how difficult it would be to have L and R treated differently.  If you don't feel like messing with it I think those of us that care can turn it on in our settings, however it might help access some of the Meta characters.
 
Last edited by a moderator:
Exactly. This is how it has worked all the way since the PC AT. Any magic is done by the OS and it has no dedicated hardware interrupt. Some ancient BIOS:es handles the key in some way. However, the BIOS is not active once the CPU is switched into protected mode and can only be reached by the OS intentionally dropping back to real mode, or by switching to v8086 mode.
Are you sure about that? Everything I was ever taught about it was that it drove an interrupt from the BIOS. That was the whole point, it was an emergency point that could be activated no matter what the CPU was doing or what was going on with the OS.If that's not the case anymore, and hasn't been for a long time, that would explain why I could never get it to work when my kernel would go tits up which is literally the only time I have ever needed it which, honestly, defeats the purpose in my mind.

But regardless, if it hasn't been an interrupt for a long time, and it seems like that's the case, then ED's layout is just fine in that respect, it can go wherever and hope the keyboard driver is bug free.
 
My comments on http://www.keyboard-layout-editor.com/#/layouts/f53c18fa0b129a840b5e9bebe7362da7 :

  • Shoulder buttons: Keep L1=RShift and change L2=RMeta, R1=RCtrl, R2=RAlt   [reason: Pandora has R1=RCtrl, and it makes more sense to use Meta for Fn, L_Meta and R_Meta can still be distinguished]
  • Change Menu/Ins to LSuper, without Fn function. Move Ins to Fn+dash (instead of SysRq)
  • SysRq does not need to be labeled imo, since it's a feature that is only used by people who know how to rtfm.
  • Backtick/Tilde could be on Fn+BH so the shift-pair pattern is preserved. ú is not important, maybe you meant ù which is used in the French word "où" ("where", and that's the only French word it is used in) but that is also not important enough to deserve a label imo, it can be formed with grave+u. § can move from Fn+H to Fn+W, which brings it somewhat closer to its German keyboard location.
  • ` on Fn+R can be kept as a dead grave (as opposed to the backtick key), which is useful for ù in French and also òì in Italian (à and è are already covered)
  • ´ on Fn+T as a dead acute is useful from Spanish and many other languages, but for French é is enough.
  • However, for French a dead circumflex is needed (for âêîôû).
  • Suggested fix: make Fn+R dead acute, Fn+T dead circumflex, and have no labeled dead grave. Those who need dead grave, can either use Shift+backtick for that (Fn+Shift+H if you followed my proposal above), or make backtick behave as dead grave by default (since backtick is not very important anyway).
  • the öüü at Fn+JKL is obviously a mistake, it could be changed to äöü on Fn+JKL. Another option is üöä on Fn+JNM and ß on Fn+U (this puts the extra German letters in the normal relative positions), moving ° to Fn+K and CapsLock on Fn+L (close to Shift, "L" for "Lock").

Here's a modified version:

http://www.keyboard-layout-editor.com/#/layouts/6cba5957453accdc87e90713d2aa5f35
 
Back
Top