MrConfusion
Very Active Member
- Joined
- Apr 11, 2013
- Messages
- 331
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.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.
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.