THE Fn-key


MrConfusion

Very Active Member
Joined
Apr 11, 2013
Messages
331
EDIT: Fn keys can not be easily remapped if Fn is implemented as hardware- or driver level modifier as it usually is. It should not me used as a name for a software modifier.
I pulled this to a new topic from a keyboard thread, because this is not exactly related to layout. Besides, since the Pyra is still far away I'm more academically than practically interested in this.

By now the developers already surely know whether the Fn-key is hardware or not - is it just a key like any other, or a very strange electrical concoction of pure hackery genius?

Simply looking at the typical chips decoding keyboards I am strongly assuming Fn is just a plain-old-regular-joe-key and thus easily switchable with, say, the letter B.

And in theory, it was in the Pandora too.

In practice, when I wanted to remap the Pandora keyboard, I found a bit of a mess...

First of all: Fn itself. It's status is tracked by the kernel (up, down, lock) and if down, every key is interpreted differently. I think this might also be doable via loadkeys, which needs to be used in any case to get the weird layout working sufficiently for you to be able to write even simple daily stuff like finds with grep.

But if you need loadkeys anyway, then why not do it all there, why the kernel hack? To make loadkeys "script" cleaner?

How has this been planned in the pyra? If still undecided, I'll place my vote: have it done in one place only, loadkeys. It's a big thing for someone who wants to mod - no need to patch the kernel! I definitely do not enjoy compiling kernels and rebooting to test whether the code works!!!

(If there is a valid reason for doing this in two places, then I apologize for not figuring the reason out myself...)

Second: In Pandora ALT, CTRL, A, B, X, Y, directionpad and Pandora-key were actually behind a different driver and different piece of code. This is visible all the way up to the user: /dev/input/input5 is keypadstuff, /dev/input/input0 is keyboard. So? No big deal unless I want to have Fn-right as End and Fn-left as home... which, incidentally I did.

Will this also be done on the Pyra? Directionpad etc. not being part of the "main keyboard"? If so, that is another reason not to decode Fn in the kernel, because I ended up creating some pretty hacky variables to pass  the Fn status to that other driver... In retrospect I now regret I simply didn't take out the whole Fn-kernel thing and just try implementing all of this with loadkeys. Had I done this I could now say for sure whether or not it worked out...

How much of the input device structure will the Pyra inherit? Is there a place/post where I could have checked the current plans myself?

I've probably misunderstood or remember something wrong (it's several months since I touched the kernel and the main job was done even earlier...), correct me as neccessary.
 
The thing you need to keep in mind about the Pandora is that when it was released there wasn't a lot of existing work on something like it. Angstrom was used for the kernel and packages and from that a full OS was kind of cobbled together. The original system was hacked together by two or three people who were "paid" with prototypes so they could test the work they were doing. Furthermore, when they were given the prototypes the Pandora was only "two months" away from shipping, so they had to quickly throw it together. With nothing to base it on and very time limited this resulted in a lot of understandable hacks.

Of course the Pandora then went on a year long vacation, but the damage had already been done.

What's different this time around is that we do have a more stable base to work with, more opportunities to test the work, more people (even if they aren't kernel developers there's at least a rapport among the group and we can vet ideas with each other, as you're doing here), and we have a lot more time to do it right.

In retrospect I now regret I simply didn't take out the whole Fn-kernel thing and just try implementing all of this with loadkeys.
It's not too late. If you can get that in place on the Pandora, prove it works without breaking too much, it can probably serve as the base for the Pyra's keyboard driver.
As I recall (and this was 7 years ago so my memory is extremely fuzzy) the split between keyboard and gamekeys was intentionally, and well intentioned, on the grounds that they were meant to be two different things. That's not how it turned out, obviously, and years later it was an unfortunate decision, but there's not much incentive to fix something that works, even if it isn't optimal.
 
Having every key/button as part of one single input device (including game buttons, shoulder buttons, and if possible even the lid-close-sensor) makes a lot of sense to me.

Implementing everything using loadkeys also makes sense to me. On my laptop, man keymaps tells me it can deal with 9 different modifiers:

"The  keyboard driver  supports  9  modifiers. These modifiers are labeled (completely arbitrarily) Shift, AltGr, Control, Alt, ShiftL, ShiftR,  CtrlL,  CtrlR and  CapsShift.   Each  of  these modifiers has an associated weight of power of two [...]"

How would we implement a Pyra-specific modifier with this (or Pandora's Fn for that matter)? Hack loadkeys to support an additional modifier? Or reuse one of those last 5, since it's probably safe to assume that people are not going to want to let their left and right Shift and Ctrl do different things.
 
It's not too late. If you can get that in place on the Pandora, prove it works without breaking too much, it can probably serve as the base for the Pyra's keyboard driver.
I was going to bluntly say I'm not going to test it because it's too much work for something I already perfected, but on second thought maybe I will, I'll just shortcut a bit first to prototype and the effort isn't that big...

However: is my assumption about Fn sending scancodes in Pyra correct? If not, there's no point in testing to begin with...

Though I was purely a lurker for very many years I do remember the background as "shown" on the forums both during and after the events. I realize some oddities might spring from there. I'm more used to finding a HW constraint behind oddities, though, so that is why I always start from there...
 
is my assumption about Fn sending scancodes in Pyra correct?
God I hope so. Otherwise it'd be a broken design from the start and one of those things EvilDragon would have needed to be completely upfront about when he made the keyboard thread: it puts a lot of restrictions on what can be done.As far as I know it'll be identical to the Pandora: just another key at the hardware level. It's up to the kernel driver to know how to interpret that key.
 
is my assumption about Fn sending scancodes in Pyra correct?
God I hope so. Otherwise it'd be a broken design from the start and one of those things EvilDragon would have needed to be completely upfront about when he made the keyboard thread: it puts a lot of restrictions on what can be done.
As far as I know it'll be identical to the Pandora: just another key at the hardware level. It's up to the kernel driver to know how to interpret that key.
Sorry, but I hope not, like on the Pandora, I prefer to have a Fn key not visible by apps / games.

But we need 4 shoulder buttons that are visible by apps of course...
 
There's a number of question marks about the technical details of how the keyboard will work. Personally I still want to know the layout of the keyboard matrix. Whether any of the keys directly trigger interrupts would also be good to know.

I do think it fair to assume that every key on the keyboard will either be part of a keyboard matrix or on an individual gpio just like with the pandora. Given that ED has given no indication that there is a set location for a hardware modifier I'd suggest working on the assumption that every key in the matrix looks the same to the kernel, and all modifiers (even faux hardware modifiers like fn) need to be implemented in software, be that the keyboard driver or in userspace.

While it makes sense to include the gaming buttons in the keyboard driver, I'd also recommend creating a single "joystick" driver that also covers both nubs and all the gaming buttons.

It also occurs to me that if one of the shoulder buttons will be a faux hardware modifier that such a joystick driver might be one way to also make it useful as gaming button without worrying about whether it generates a keyboard scancode.

- Neelix
 
Good idea. It may even make sense to have all keys of the full keyboard as 'buttons' of this 'joystick'.
 
Sorry, but I hope not, like on the Pandora, I prefer to have a Fn key not visible by apps / games.
The Fn isn't visible on the Pandora but it still produces a scan code, the kernel driver just discards it.Just curious, why are you against having it visible? What is lost by allowing it? As near as I can tell there's no benefit, it just becomes another key which software will ignore unless it is specifically looking for it.
 
Having every key/button as part of one single input device (including game buttons, shoulder buttons, and if possible even the lid-close-sensor) makes a lot of sense to me.

Implementing everything using loadkeys also makes sense to me. On my laptop, man keymaps tells me it can deal with 9 different modifiers:

"The  keyboard driver  supports  9  modifiers. These modifiers are labeled (completely arbitrarily) Shift, AltGr, Control, Alt, ShiftL, ShiftR,  CtrlL,  CtrlR and  CapsShift.   Each  of  these modifiers has an associated weight of power of two [...]"

How would we implement a Pyra-specific modifier with this (or Pandora's Fn for that matter)? Hack loadkeys to support an additional modifier? Or reuse one of those last 5, since it's probably safe to assume that people are not going to want to let their left and right Shift and Ctrl do different things.
Let's consider these individually in a bit less arbitrary order.

CapsShift - On a standard keyboard, this controls the CapsLock. General consensus seems to be to exclude it from keyboard mappings. Maybe we need to consider including it in case an application requires it for something?

ShiftL - Left shift button. Should be present and paired with a (left) Fn/Meta key.

ShiftR - Left shift button. Should be present and paired with a (right) Fn/Meta key.

Shift - Assuming this calls a different code from ShiftL and ShiftR, may be able to be hijacked as a Fn/Meta key?

Alt - Left Alt button. Should be present and paired with a (left) CtrlL key.

AltGr - Right Alt button. Should be present and paired with a (right) CtrlR key.

CtrlL - Left Ctrl button. Should be present and paired with a (left) Alt key.

CtrlR - Right Ctrl button. Should be present and paired with a (right) Alt/AltGr key.

Control - Assuming this calls a different code from CtrlL and CtrlR, may be able to be hijacked as a Fn/Meta key?

So, is there any reason to NOT hijack/map 'Shift' and 'Control' as the 'LeftFn' and 'RightFn' respectively? In theory that would give us the level of control we need over the keyboard actions.

Note, left and right make it easier to distinguish the pairs. In practice whatever is on the left shoulder would take the 'left' version and it's corresponding 'right' version would be in the keymat. Whatever is on the right shoulder would take the 'right' version and it's corresponding 'left' version would be on the keymat.

Just a note - the 'Left Fn' and the 'Right Fn' need to produce 2 different codes so that the shoulder buttons can be used in games WHILE the Fn on the keyboard still works properly.
 
Last edited by a moderator:
Sorry, but I hope not, like on the Pandora, I prefer to have a Fn key not visible by apps / games.
The Fn isn't visible on the Pandora but it still produces a scan code, the kernel driver just discards it.Just curious, why are you against having it visible? What is lost by allowing it? As near as I can tell there's no benefit, it just becomes another key which software will ignore unless it is specifically looking for it.
Not seeing it from software has a definite downside to it, because its less flexible.
 
I see you've pondered this a bit further, I was going to write more detailed info, but my family found me... ;-).

Having every key/button as part of one single input device (including game buttons, shoulder buttons, and if possible even the lid-close-sensor) makes a lot of sense to me.

Implementing everything using loadkeys also makes sense to me. On my laptop, man keymaps tells me it can deal with 9 different modifiers:

"The  keyboard driver  supports  9  modifiers. These modifiers are labeled (completely arbitrarily) Shift, AltGr, Control, Alt, ShiftL, ShiftR,  CtrlL,  CtrlR and  CapsShift.   Each  of  these modifiers has an associated weight of power of two [...]"

How would we implement a Pyra-specific modifier with this (or Pandora's Fn for that matter)? Hack loadkeys to support an additional modifier? Or reuse one of those last 5, since it's probably safe to assume that people are not going to want to let their left and right Shift and Ctrl do different things.
I bolded the points that hold the answer to the pressing question. I must warn you I might be totally in the wrong here and in that case this whole thread is only worth closing - if it's not like I assume, then we're done here:

Do dumpkeys on almost any device and you soon realize that the widest bitfield is actually the first four bits, or, to be more specific, 12. In plain english, the first four modifiers are the only ones ever used. For example, in my pandora dumpkeys starts with:

keymaps 0-2,4-5,8,12

Which means (if I figured this right) that only:

PlainPress, Shift(1), AltGr(2), AltGr+Shift(3), Control(4), Control+Shift(5), Alt(8) and Alt+Control(12) are ever mapped.

As for naming, it's not the order that is arbitrary (in case you thought so, Grench), it really is the naming, IMO it would have been better to name the rest simply Mod5,6,7,8,9. Had this been Microsoft they would have used the general purpose word "reserved".

This means we got plenty to play with - 5 Fn keys. This in theory, the practice might prove very, very different:

1. The naming might have made people do some decisions that mess up the possibility to use these mods for this (theoretical problem).

2. Any app that directly reads the keyboard (i.e. scancodes from /dev devices) will be confused. This sounds bad, but at least so far to my experience it means: X11 and SDL. Problem is I only use the three emus I've mentioned in other threads explaining my env, so I make a really, totally no good test subject.

There are two absolute downsides to this (dare I say it...) hack (assuming it even works):

1. Three places of implemetation that I know of: loadkeys for terminal (most people never use it!), xmodmap for X (same map must be written for a totally separate system!), SDL (can be avoided by hooking it to X11 instead of event interface).

2. The absolute, unconditional need to do loadkeys early on during init, if terminal needs to be used for anything at all, like inputting a password with non-letters.

3. Standard PC appearance? Baaaaah! From that point of view this is a complete atrocity - you now literally lack most of the scancodes a PC keyboad can produce. But if all you ever use is X and XEvents I'm not sure that matters.

The payoffs:

1. Clean kernel. I know I should check since it is easy to see whether it has been merged, but... I suspect the current solution is not mergeable to mainline kernel (whether Pyra devs even want to merge with it, I don't know).

2. Absolute, total modifiablility without touching the kernel. Well, this would have saved me a lot of time, but then again, for most this is irrelevant anyways.

There was something more I was thinking of saying but The Family wants me again...

Edit: Ah, this was it: Fn can have two scancodes, you just set both to the arbitrarily named CtrlR mod, no problem.
 
Last edited by a moderator:
I suppose we could use loadkeys and xmodmap, perhaps auto-generate one of them from the other (or both from a common config file). I think it makes a lot of sense to let SDL hook to X11 for input: wouldn't that also mean you can alt-tab out of full-screen SDL applications, have media player shortcuts that are noticed all the time, and so on? I think the only reason why the Pandora SDL is so independent of X is because on a low memory budget you might want to run SDL applications without X taking up memory, and also perhaps because X uses only 16 bit color for some reason. But I assume that those reasons are probably not worth the trouble anymore on the Pyra.

My main concern is: what happens if you attach an external keyboard through USB or bluetooth? Will it behave correctly?
 
The way I see an FN-key is powertoggles, and all the things there arent dedicated buttons for. Hacks basically.

FN for powertoggles, mediabuttons, and F-keys exists on keyboards in the wild. If thats in error i dont know.

For laptops its mediabuttons and powertoggles, not F-keys. Thats the main area where FN keys are used, atleast to my knowledge.

It would be very nice if it could be used to reinstate default behavior should the user have a need to use dedicated typing-letters on the full keyboard area.

I see a benefit of being able to powertoggle before X starts. I imagine this is what the benefit of a interrupt/hardware level FN can do as opposed to a software one.

That is however not as important in my view. There could be things im missing, but I prefer the flexibility of having it be just another definable button like the rest.
 
Last edited by a moderator:
As for SDL: one of the first things I fixed was SDL running fullscreen... and I did modify keycapturing and such too, come to think of it. I play games that need manuals and having the PDFs easily switchable to was essential! If you do not use omapfb(, instead force it to x11) in SDL you can get a pretty accurate view of how SDL works when capturing Xevents instead of kernel ones.

But this USB keyboard thing... Answer is I dunno, but I'll make a guess:

We also need to map the standard keycodes that do not exist on Pyra (actually Linux kernel should do that with reasonable results for us as long as we don't VoidSymbol them in our map), scancodes not sent by Pyra keyboard would be a nonissue. The rest - in theory no issues, but there is interaction: pressing Fn down on Pyra kbd would enable you to input special symbols from your desktop keyboard. This is just logical guessing, though, it could also burn down your house ;-).

Neelix,

I think you answered my other question: the "gaming controls area" was probably separated from the main keyboard to have individual interrupts for gaming keys! A valid reason. Another oddity answered.... And I think the Pyra should follow this convention.

Oh and about a "generic joystick driver"... Funny you should mention... :-D.

Configuring the inputs on the fly definitely needs some thought: I don't know anything about Saxxon as I stopped using it very quickly, but I think you might find some changes I made to SDL interesting:

By default up.down,left,right is keyboard. Hit [your ALT/Start, my WMControl]+0 - bang, it's a genuine SDL joystick and a green indicator in my (always visible) status bar lights up.

By default left nub is fast mouse, right slow one. Hit WMControl+Backspace and left turns to SDL Joystick and right is medium mouse, mode indicator lights up again.

Being able to do these in-game was essential and/or convenient for many computer games using both mouse, joystick and keyboard...

I actually originally faked two joysticks just so I could switch "ports" in Vice and UAE on the fly, but the keycombos for that were too much for me so I removed that and continued using the regular UIs...

Something like this would be even cleaner when done via /proc, so it's not dependent on SDL... yet another "doh, why didn't I put it there" moment just occured to me...
 
Are individual interrupts for gaming keys actually any better than just have them as regular keyboard input? I can see how it could theoretically make a difference measured in microseconds, but wouldn't most games have response times measured in milliseconds anyway?
 
Are individual interrupts for gaming keys actually any better than just have them as regular keyboard input? I can see how it could theoretically make a difference measured in microseconds, but wouldn't most games have response times measured in milliseconds anyway?
Ah, I see what your problem is, just sit on this chair for a minute:

POUR - SUPERGLUE - ON - HEAD

PUT - PROPELLERHAT - ON - SUPERGLUE

TURN - SWITCH

There? All sorted now?-)

Seriously: No it makes no difference, in fact games controllers were moved over to USB ages ago and both latency and jitter in that are so lousy that for example many keyboard players couldn't accept it until CoreDuo days with both CPU grunt and a very evolved USB controller... in fact naysayers still exist.

These days game controllers are often on bluetooth radio (/me cries out in pain).

The problem is no-one notices, not even me (/me cries out in frustration)

So despite all the great venting times we had on the boards about the deficiencies of these approaches, the blasted approaches work and that's it then...

However, there's always this: until I decided to create a totally custom keymap this arrangement did not cause any problems either. It could be beneficial occasionally: it also affects priorities of processing (though I don't know enough of the platform to say whether that makes any difference or has been put to use). By that time I suspect the game is stuttering anyway, though.

But it feels kinda cool.

Anyway, this was purely academic also because you don't "hook" interrupts with software and the Pyra mainboard is already designed! So whatever is, is already and we'll work with that.
 
I thought of a third option and found that someone had though of it before me (though he implemented it in userspace):

http://users.softlab.ece.ntua.gr/~thkala/projects/evmapd/evmapd.html



A daemon that reads /dev/input/eventX, modifies data, then makes it available via uinput.

If the direct scancode --> keycode conversion proves messy, this is yet another option provided it doesn't introduce too much lag.

This evmapd-implementation is not usable as-is for the Pandora, I think, but then again it is a perfect starting point if it is needed. And can be made very configurable.

(I was actually looking into a scancode--> scancode kernel level conversion possibility, though... I was interested to see whether some project had produced a module.)

Purely out of curiosity I also finally checked the twl4030_keypad driver which turned out as expected.

I'll start on the actual testing as soon as time (i.e. The Family) permits some proper concentration.
 
Heh, sounds like my inputty doodad, though probably with less overhead (since inputty may go through javascript depending on configuration and Qt internals). The downside is you can only make more input visible doing that, not hide anything that's already been readable from /dev/input/eventX. So while you can't make "x" do "y" you can make it do "x" and "y".
 
B-ZaR: What was your original use case for this?

Update on how things fared last night...

I tested the loadkeys option for just about half an hour-hour after the kids had gone to sleep. It still looks like it works, I'll know for sure enough after a couple of days or so: 

1. Switched my RightShift to mod callled ShiftL --> pressing it down no longer works "Shifty" meaning, no capitals, nothing. Talk about a confusing naming convention!

2. Added a set of symbols to some keys for the weight 16 (ShifL weight) --> RightShift now works like the Fn for those keys. Theory proven right.

3. Started writing a little utility to generate the whole keymap quickly, too lazy to not automate it :).

Once done I'll test some common terminal utilities like editors and pine.

I did notice one oddity while testing already, but I'm not sure it matters: The ShiftL modifier stays down in showkey-utility when pressed once. I haven't checked the showkey source to see where this oddity springs from. But it is not important assuming it doesn't happen in Vi&Co. It definitely doesn't happen in the shell (bash, for me). I don't think this feature of loadkeys is commonly used so I expected some oddities. There are not that many utilities even Pandora/Pyra "hacks" would use in the pure (no X) text console, though, are there? So as long as your common editors used for Xorg.conf and such work, we should be fine? Most mobile devices have no keyboard so being able to operate on a text console could even be seen as a bonus...

Next up: After the console map is finished, do the same for xmodmap (should be no worries there-that thing's got even more mods to use). That one might also turn into a loadkeys --> xmodmap utility for this specific purpose.

At that point I'll dump that all here, because it'll be easy and nondestructice for someone to test that in the default Pandora OS with default keylayout (Instead of Slackware and my custom US101-compatible keymap). Just choose a key to use as Fn for testing. In fact that can be toyed with on a desktop even.

Then once X works safely I'll make myself an alternate kernel by taking the twlkeyb-driver from mainline kernel and making the neccessary changes to the Pandora keyboard description, thus eradicating the default Fn hack. I'll share those changes here too for those interested.

But alternate it has to be - I can't test this as properly as I'd hope to: there are issues in my setup doing this, because... well... "I done the nasty with me kernal" so no loadkeys script can do everything I've done and some of that code resides in the files I'll restore to their original state.

Everything is solvable, but since I already put a lot of effort to making things the way I want them doing this again with different base assumptions purely as a PoC is a bit much. That's what I meant originally by saying "it's too late" in a message above. For the Pyra, of course not, for this particular little Pandora, it is.

Testing the new kernel changes and maps in Saxxon woud also be a bit of a pain for me... My flash has no saxxon, I'd have to run it from SD...

Finally, if time permits (which I doubt), I could check the situation with SDL - for normal Pandoras, trivial... but my version has (dirty) changes which assume (filthy) hacks to be in place in Xlib... Starting to get a picture? So, SDL would also have to be alternate, quick-test version, like the kernel.
 
Back
Top