Current Keyboard Layout

[FaeMinx]

Darn it. This device was almost perfect... Now we are stuck with something that will be pretty good in most cases, but frustrating or almost impossible in others. I forsee numerous issues cropping up in the years to come.


I was so looking forward to a 'non-crippled' experience with the Pyra.


The real shame is that the Pyra might last indefinitely...


And here my thoughts are already turning to a successor (which may never come), where we do it right and have a REAL hardware modifier key.


Darn it darn it darn it!

 

[comradekingu]

Fn/Meta behavior: The two Fn keys are two different keys with two different needs - but one common behavior. The shoulder Fn needs to create a unique keycode to the OS so that the OS can re-map it to something not Fn-like for games. The keyboard Fn must always perform as Fn. BOTH Fn keys need to behave to the OS as if they were a HARDWARE Fn - i.e. NOT generate just a key code, but instead they must fundamentally change the behavior of the other key pressed. Yes, this can happen at the driver level, but it must happen prior to the OS map.

Will most likely not happen, as we like to stick with mainline kernel and as notaz already pointed out, such hardware key is not allowed.


That's why the layout I was working with works WITHOUT a hardware key.

Fn+Shift is not an option, it is and must be a rule: Every physical key on the keyboard (other than Lshift, Rshift, LFn, RFn, LCtrl, RCtrl, LAlt, RAlt) must have 4 'mappings' or 'layers', even if they are not explicit in the printing on the keys. It is easiest to think of the keyboard as TWO physical keyboards.

And the reason for that is...?


As far as I can see, everything works fine with Shift and one modifier.

If Fn is a single button doing both what is on a normal German laptop keyboard AltGr and Fn, then you cant both do shift+altGr and Shift+Fn.

You could, but then you would have Shift+Fn doing one thing, and Fn+Shift doing another, which is about as confusing as having Fn do something it never does. Calling it meta, or MetaFn is to a great deal of people another way of saying ? or ?.

If you cant explain it simply, you havent kept it simple enough.

 

[Grench]

If Fn is a single button doing both what is on a normal German laptop keyboard AltGr and Fn, then you cant both do shift+altGr and Shift+Fn.

You could, but then you would have Shift+Fn doing one thing, and Fn+Shift doing another, which is about as confusing as having Fn do something it never does. Calling it meta, or MetaFn is to a great deal of people another way of saying ? or ?.

Actually, a single keyboard CAN have both a Fn and an AltGr. Fn+AltGr+Shift+key IS a logical key press. But then, many of us have explained the difference between Fn and AltGr and how the RightAlt key IS AltGr, it just has to be 'activated' and how any keyboard that maintains all of the US Standard root keys (the UnShifted, symbols as a root keys on either the normal or Fn layer CAN support the US Standard AltGr extension if someone chooses to 'turn it on'.
At the same time, we have also created an extended base layout that -should- completely eliminate the need for AltGr for more than 95% of likely users by directly supporting English, German, French, Spanish and many other languages -without- activating AltGr - and leaving it simply as RightAlt.

If you cant explain it simply, you havent kept it simple enough.

So sayeth the dude who's keyboard layout requires a multi-page manual since it lacks markings for actual key activity.

 

[EvilDragon]

 

[moxie]

I said before that I trust ED to have common sense. I see that my trust is well placed.

 

[Urben]

The disambiguation between Fn and LeftClick would be resolved by waiting for the next event: if it's a mouse movement event, then it's a left click (dragging), if it's a keypress, it's the modifier.

Right Alt is often called AltGr and it can be used for another layer of symbols, e.g. by selecting the US-International keyboard layout.

Okay makes sense, could actually work.

Since the nubs might be quite limited in clicking as far as I can read here, Mouse Buttons on the Shoulders don't seem to be the worst idea. I'm for it!

EDIT: On the other hand, since mouse movement and clicking don't use the same nub dragging is perfectly possible. I just wonder how you right-click if the mouse isnt centered.

I actually dont know how it works at the Pandora. Is the mouse jumping back to the middle of the screen once the nub is centered again?

 

[WizardStan]

BTW: QEMU shouldn't have this issue

It does. It was patched for the Pandora.

I'm trying to figure out, though, if Fn isn't really a code-layer-switching 2nd keyboard definition Fn, then how in the world can we have F1-F12 on the Fn layer? Doesn't that make combinations like Shift+F3 impossible?

When pressing shift+fn+E the keyboard driver will produce a shift, an Fn (most likely the Meta keycode, or something like that), and an E. It'll be further down the line, at the X server or in SDL, that translates the "FN+E" into F4. Anything that doesn't use SDL or the X framebuffer will need to be modified. Hopefully there is not that many of them but I wouldn't be surprised if this caused a problem.Fortunately it's a problem that would be fairly easy to fix if it became a particularly difficult nuisance. Unfortunately we'd be unable to keep the keyboard driver in mainline which would cause its own problems, problems we're having with the Pandora. So yeah, problems no matter what we do.

 

[bzar]

but that the DRIVER needs to treat it as one

Which, as Notaz explained, cannot happen if we're to stick with mainline. It's unfortunate but it's going to have to be a 100% software mod and we'll have to have a modified X server and SDL and hope that's enough.

When where did he state/explain this? I must have missed it - sorry.


I'm trying to figure out, though, if Fn isn't really a code-layer-switching 2nd keyboard definition Fn, then how in the world can we have F1-F12 on the Fn layer? Doesn't that make combinations like Shift+F3 impossible?


If it isn't going to interfere with inputting Shift+F6 with F6 on the Fn layer and similar - then how is it going to care that:


Normal N = n


Shifted N = N


Fn N = ñ


Fn+Shift+ N = Ñ


Either all 4 'layers' exist or they don't. Either my n&ñ mapping works or shift+F5 doesn't (and consequently would require F1-F12 on the 'top' layer).

It can still be done with a userspace daemon that captures the actual evdev keyboard and presents a virtual uinput one. Tested something like this with inputty recently.

That said, it's a bit of a dirty hack.

 

[MrConfusion]

Anything that doesn't use SDL or the X framebuffer will need to be modified. Hopefully there is not that many of them but I wouldn't be surprised if this caused a problem.
Fortunately it's a problem that would be fairly easy to fix if it became a particularly difficult nuisance. Unfortunately we'd be unable to keep the keyboard driver in mainline which would cause its own problems, problems we're having with the Pandora. So yeah, problems no matter what we do.

You make it sound so dark and doomed: I strongly suspect there is no problem to begin with - X software which reads keycodes directly would have and has been spotted on the Pandora already.

To my understanding they've all been SDL based. And that can almost be interpreted as a self-inflicted problem in the Pandora - the issue would not have even bleeped on the radar if SDL had been hooked to Xinput. Might have been a latency thing or a "this was done on GP2X so why not here too"-thing. Whatever thing it was it can be rethought in the Pyra.

It was on my todo list to prototype bypassing the Pandora kernel hacks on the Pandora (some old thread somewhere), but unfortunately I ran out of energy midrun. And I guess it's time I admit to myself I won't be returning to that task...

The conclusions I got to were:

• Linux text console is not an issue, a simple loadkeys makes the kernel hack redundant.
• If "no weird stuff" is your mantra then keeping AltGr will require XKBD, xmodmap won't cut it as you can only turn AltGr to an Fn (which works fine, as long as you don't need AltGr as AltGr). XKBD adds the expressiveness of linux keymapper - more configurable modkeys.
• Due to the complexity of XKBD and some features I've embedded into SDL (switches), a lower level uinput redirector/input collector would have been preferable for me. I know of two already, B-ZaRs seems to be the more robust base to build from.

So IMO at least on the Pandora B-ZaRs inputty or something similar would be preferable for X: it could collect all the input devices into a single uinput, and do any neccessary transformations. The only downside that might exist is latency and I think that would have been a nonissue even on the Pandora - when the CPU is maxed the gaming experience will suffer anyway... At least personally I'd have to suffer from some dismal latency to find the convenience "not worth it".

Note that "transformations" is not neccessarily just keyboard Fn ones: think of stuff like turning the arrow keys, shoulders, action buttons, nubs into a standard (indistinguishable for X) joystick <--> mouse <--> button <--> whatevers with a keyboard shortcut - in all apps.

 

[_wb_]

Here is my proposal:

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

I added the MENU key at Meta/Fn+Enter.

€ would be at ¤ (Meta+D) by default, but if you want to have £ or ¥ instead, that can also be done. Or if you want it really general, then ¤ can act as a "dead currency" key which produces all currency symbols you can imagine if you follow it with some other letter (e.g. ¤E would be €, ¤L or ¤P would be £, ¤Y would be ¥, and so on).

All the dead diacritics (acute, grave, circumflex, caron, umlaut, double acute, cedilla, ogonek, dot, macron, stroke) are available in a totally non-obtrusive way: if you don't need them, you don't have to know about them. No dotted circles.

German and French get the precomposed letters äöüß and éèàç labeled, so they don't have to know about dead diacritics.

 

[thatgui]

Here is my proposal:

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

I do not favour the "Hardware" key, Grench and others may say its easy to code, but I am still convinced that no one will eventually make or even maintain it (why should it be different then with the Pandora?). I don't need the full functionality (no need for HDMI, USB, etc) but the wireless devices should be there, even if its just like on my thinkpad > one button that just toggles through the various combinations of WifI,Bluetooth and MobileData.

 

[_wb_]

I volunteer to code the hardware button menu, if that's what you are worried about.

 

[thatgui]

I volunteer to code the hardware button menu, if that's what you are worried about.

Are you volunterring for mainting it too (for x maybe even xx years) and are you guaranteeing that it will work in all "conditions" (x-Environment, during direct frame buffer access and every scenario other people than me, that actually know what they are talking about, can think of) ?

 

[txus]

Ok, summarizing, there are 2 possibilities:


- 100% mainline kernel, several software has to be patched and/or,


best-case scenario, applied a custom configuration (X, SDL, whatever


Wayland environments use, console, ...): unexpected behaviours expected,


several patches/configs(/daemons?) have to be maintained


- non-standard out-of-tree driver for (let's not forget) non-standard


device, 100% compatibility with pretty much everything: own kernel (or just


driver?) has to be maintained


I would almost always say KISS wins. Even if the extra stuff could


eventually be mainlined, a custom kernel will probably have to be


maintained anyway for some time and the best example of that is the


letux-kernel, formerly gta04-kernel, which has been putting LOTS of effort


in going mainline. Even if it is not the case, having just the one driver


out of the mainline kernel, even if it is as critical as the keyboard, is


IMO a small prize to pay to have a 100% upstream-compatible device which


can use unmodified Debian repos, and less work than being FORCED to


maintaining a whole software collection in a repo (not talking about the


custom applications people WANT to put in a repo with Pyra optimizations).


I think this statement from Arch Linux is something to keep in mind:


"[Arch] strives to keep its packages as close to the original upstream


software as possible. Patches are applied only when necessary to ensure an


application compiles and runs correctly with the other packages installed


on an up-to-date Arch system."


And even more: I don't know how strict the kernel maintainers are, but


maybe, with enough justification, and doing stuff like always presenting it


above the code in comments, they could make an exception.

 

[ible]

Here is my proposal:

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

I added the MENU key at Meta/Fn+Enter.

€ would be at ¤ (Meta+D) by default, but if you want to have £ or ¥ instead, that can also be done. Or if you want it really general, then ¤ can act as a "dead currency" key which produces all currency symbols you can imagine if you follow it with some other letter (e.g. ¤E would be €, ¤L or ¤P would be £, ¤Y would be ¥, and so on).

All the dead diacritics (acute, grave, circumflex, caron, umlaut, double acute, cedilla, ogonek, dot, macron, stroke) are available in a totally non-obtrusive way: if you don't need them, you don't have to know about them. No dotted circles.

German and French get the precomposed letters äöüß and éèàç labeled, so they don't have to know about dead diacritics.

I would exceedingly prefer this over what is in the OP.  A lot more functional (international-wise and more), and it's easier to see where things are.  You can easily move ,< .> over to the left if Pandora-styles is desired.

I would still like to see backspace off the gamebutton cluster:

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

but here I've duplicated +, though the keycodes can be different (or the one on P could go to MENU if desired), and it breaks _wb_'s macron meta'ing.

I'm afraid ED won't like it, however, because it doesn't have the section sign or degree symbol.

 

[EvilDragon]

BTW: QEMU shouldn't have this issue

It does. It was patched for the Pandora.

Well, since a patch already exist, it's no issue for QEMU anymore.

So what other software besides DosBox is there?

Any examples?

I'm trying to figure out, though, if Fn isn't really a code-layer-switching 2nd keyboard definition Fn, then how in the world can we have F1-F12 on the Fn layer? Doesn't that make combinations like Shift+F3 impossible?

When pressing shift+fn+E the keyboard driver will produce a shift, an Fn (most likely the Meta keycode, or something like that), and an E. It'll be further down the line, at the X server or in SDL, that translates the "FN+E" into F4. Anything that doesn't use SDL or the X framebuffer will need to be modified. Hopefully there is not that many of them but I wouldn't be surprised if this caused a problem.Fortunately it's a problem that would be fairly easy to fix if it became a particularly difficult nuisance. Unfortunately we'd be unable to keep the keyboard driver in mainline which would cause its own problems, problems we're having with the Pandora. So yeah, problems no matter what we do.

The normal shell terminal should work with loadkeys:

http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-15.html

So the only affected programs would be those that do not use X, SDL or the console as input.

AND need keyboard input (not just some action buttons for playing games)

Seriously, does anyone know of such a program?

 

[WizardStan]

Seriously, does anyone know of such a program?

I have done exactly zero research into how any program gets its keyboard input. Even most of the stuff on the repo I'm not aware of what they use: most are pressumably SDL, but some are going to be working with X and drawing on the framebuffer. Given that everything "just works" and there's been no need to investigate, asking if anyone knows of such a program is a poor argument because no one has ever been expected to know. This isn't a problem that we've had to worry about, so long as everything worked no one cared.The only ways to know is to check the code of every single one, or make the change and see what breaks. I can make an assumption that the number of problems will be low, it may even be zero in the end, but you can't assume it will definitely be zero, we need to be aware of the potential for problems and prepared to deal with them. If it turns out to be a small problem, with only one or two things needing to be changed (or even better, zero would be perfect) (or find alternatives that don't need to be changed) then we can stick with mainline. But if there's hundreds of useful applications that are suddenly broken and would need changes would you be prepared to reconsider, and just make a custom keyboard driver even if it no longer fits into mainline?

Actually yes, I do know one, that crappy overlay menu I demoed worked directly with the keyboard input. It would break, in theory. In practice it wouldn't because it didn't use any Fn keys, but if it had they wouldn't work.

 

[EvilDragon]

Well, I'm using Linux since years on all my PCs.

ALL programs I'm using either use the german keyboard layout I've setup in X11 or in the console. If they do that, they can't be using raw keycodes.

Different keyboard layouts are very common, so I really doubt you'll find many programs that doesn't make use of them.

DosBox is understandable and usually no issue, as you can set up the keyboard layout in DOS itself.

So DosBox has a reason to behave the way it does.

But any other normal game, app, etc.?

I don't see any reason for that.

 

[WizardStan]

If they do that, they can't be using raw keycodes.

Yes, maybe. Probably. But guaranteed? Have you investigated the code for every single application you've used and can say with 100% certainty that it won't break? I haven't. I can't.The only way to know for sure that things won't be a problem is to try it. And we can hope that everything will be fine, but I think it's foolish to just assume that everything will definitely work and not have even the beginnings of plan in place just in case.

 

[EvilDragon]

If they do that, they can't be using raw keycodes.

Yes, maybe. Probably. But guaranteed? Have you investigated the code for every single application you've used and can say with 100% certainty that it won't break? I haven't. I can't.The only way to know for sure that things won't be a problem is to try it. And we can hope that everything will be fine, but I think it's foolish to just assume that everything will definitely work and not have even the beginnings of plan in place just in case.

I know that every single application works with my german keyboard layout. That shows it's not using raw keycodes and won't break.