THE Fn-key

[bzar]

B-ZaR: What was your original use case for this?

Mapping wiimote input from the kernel driver to something more palatable for emulators. Also wanted something to show the amount of wiimotes connected so I made the wiimotes application graphical (they don't need to be). Inputty is like a runtime for CLI/GUI applications that can read evdev devices, create uinput devices and make GUIs for configuring how the two interact.

EDIT: Oh, and there's a thread, too.

EDIT2: OH. Now I remember. It wasn't the wiimote thing; it was faking pyra controls to help with development. So easy to forget since I've mostly used it for the wiimote thing so far

 

[MrConfusion]

Update: Did the console map utility, it works, produced map works, BUT the oddity I mentioned earlier can now also be replicated in bash:

In my keylayout Fn-H is [. So obviously and naturally (in my point of view ;-) Shift-Fn-H is {.

Shift-H produces capital H, Shift up and you get lowercase h again.

Fn-H produces [, Fn up and you got lowercase h again.

And now the kicker:

Shift-Fn-H produces {, but Fn, Shift up aaaand you keep getting {{{{{{{{{ until you press and release Shift again. Clearly a lock of some kind then.

And I just tested with my desktop: No, this is not a Pandora specific thing, it's a feature. Chances are stickying the keys this way is even documented somewhere. As it is, it makes console work highly unpractical. If this is not configurable, I'm not so sure this approach is worth the effort anymore. I haven't checked the kernel code yet, but if this recides in something like the vt keyboard driver... well: darn.

 

[_wb_]

Maybe shift and fn have no action assigned at bitfield-position shift+fn? Because then there would be no way to get out of shift+fn...

 

[MrConfusion]

/me thinks, blinks, checks keymap generated by the script, utters words not suitable for this family friendly board and makes a mental note to fix the script generating the ruddy thing tonight.

Thanks _wb_, I'm sure that's the issue and you saved me lots of time for sure...

 

[MrConfusion]

Yep, console seemed to work OK last night with the latest map. Thanks again for the headsup _wb_!

I will test more once I've hacked Fn out of the kernel. But first X11. I'll make Fn an AltGr for this purpose, because Xmodmap only supports 4 syms/key to my knowledge?

Should not be a problem: if a real AltGr is later needed, xkb can do it, problem is I got 0 past experience of xkb and the one quick glance I just took left me feeling more confused than ever, which is plenty confused indeed.

In fact, the way I see it, X would not be a problem in any case, because a small custom device driver for that is far easier to maintain than a kernel module would be.

But like I said: I'm sure PyraMod+AltGr can be implemented in an xkb map, it just takes the right guru-of-xkb to hack that together...

I assume the Pandora never had it's own proper xkb map?

 

[bzar]

As far as I know, xkb/xmodmap mapping only affects the keys X clients see. You mentioned loadkeys before. I haven't delved into custom loadkeys keymaps, but do those affect the keys any userspace program sees? Point being: can we move Fn out of the driver using those? I'd very much like it if we could have a userspace tool for switching between userspace-Fn (works like a software modifier) and kernel-fn (works like a hardware modifier).

 

[_wb_]

As far as I know, xkb/xmodmap mapping only affects the keys X clients see. You mentioned loadkeys before. I haven't delved into custom loadkeys keymaps, but do those affect the keys any userspace program sees? Point being: can we move Fn out of the driver using those? I'd very much like it if we could have a userspace tool for switching between userspace-Fn (works like a software modifier) and kernel-fn (works like a hardware modifier).

I think this is exactly what MrConfusion is doing.

Also, xkb/xmodmap "only affecting X clients" is good enough for most practical purposes, provided that SDL will listen to X keyboard events and not to some lower level stuff like omapfb on the Pandora. Regardless of the hardware/software Fn discussion, I think it would be a good idea to let SDL behave that way, because it is annoying for remappers that their remapped keys don't work in omapfb SDL applications.

 

[Neelix]

Does loadkeys itself not effect X applications then?

- Neelix

 

[_wb_]

Does loadkeys itself not effect X applications then?

- Neelix

I think it does, that is, it should be the basis from which xkb/xmodmap starts.

 

[MrConfusion]

Does loadkeys itself not effect X applications then?

- Neelix

I think it does, that is, it should be the basis from which xkb/xmodmap starts.

It used to, but my understanding is that hasn't been done (at least by default) since Xorg and xkb came along. Back in the gaudy olden days of XFree86 it was even documented that X tries to build a map based on the kernel map and I remember that was the behaviour some years ago.

But the Pandora X config sets X to read evdev inputs anyway, I suspect those, at the latest, disable any smartstuff X might want to attempt - it has no i/o ties to the VT in that sense anymore? So I assume the Pyra will also do the same eventually...

As a practical test: I leave X, load keymap, start X --> nope, no changes in map.

I do not do extra xmodmapping that would affect, but of course my xorg.conf might explicitly override stuff.

As it is, to my best understanding: Loadkeys is for ("text mode") VT, xkb/xmodmap handle X.

That's also why I wondered how much use VT even gets. I'm pretty sure many people are just happy to not ever see the VT, but on the other hand at least personally I need support for it, because I have (practically) full device encryption and I need to input the passwords for /usr & co before processes start running all over the places...

I must admit: After thinking this through, I'm not so sure I'd take this monstermappingroute for myself... in purely emulation terms having more actual scancodes makes things easier - if porting is affected too much, would I bother porting? Depends...

I would not modify the original twl and/or gpio drivers, though... simply to  avoid touching stuff existing in mainline kernel made by others when avoidable. An extra Pyra specific module perhaps? I don't know.

But no matter: I still intend to see how this current approach pans out on the Pandora.

Unfortunately I did not have time yesturday and I'm unlikely to have any today either...

 

[WizardStan]

How does this "loadkeys" work with wayland? Is there anything in wayland that would be useful for this? Since it seems like it's coming eventually maybe anyway, possibly by the time the Pyra is available, it may be worth investigating.

 

[MrConfusion]

OK. I know Wayland exists. Yay.

But from my perspective it's Way Way Out There and pretty much also Someone-Else's-Land until the first actual software I absolutely need starts requiring it.

But having said that, my gut feeling that Wayland would borrow something like input drivers from X (I would, why reinvent the wheel?) seems to be correct according to wikipedia:

"XKB is also used by Wayland compositors and kmscon."

Of course, how xkb inits itself may vary, someone running Wayland can test whether kernel keymap changes reflect in Wayland when minimal config for keyboards is defined...