Ok.. I agree with you that using keycodes is most deffinately a cleaner
solution. In theory. That being said, we have a serious shortage of available
keycodes. My keyboard contains 18 "internet" keys. There is no contiguous
area in the ununsed keycodes that is that large. We need a better solution.
I'm not totally sure about how the current system works, so I don't want to
propose any radical new ideas just yet. I'm also not sure how userspace
applications (like loadkeys) would be affected if we expanded the keycode space
to say, 32k.
Unless we plan to make some major modifications here, I don't think it is very
feasible to use keycodes.
> There are lots of advantages: No need to parse scancode sequences both in
> the kernel and in your module. Added flexibility - if your module eats
> certain keycodes then you can make any key act on that module by a
> change in keymap. Added usability: others with a keyboard that produces
> different scancodes can still use your module.
As for parsing sequences, it is really easy. I just flag when a 0xe0 was the
last scancode in, and then if the next code is one of the special keys, I put
it in the buffer and the application retreives it. Admittedly, this is kinda a
kludge when the kernel is already doing it.
As for flexibility, this is a module. Modules can have command-line
parameters. The settings can be given by the user here. Just as easy as using
loadkeys (and it doesn't require you have the kbd package installed)
> A cleaner kernel source: as soon as this hook is present we can throw out
> all mention of SYSRQ from all kernel code, and have SYSRQ treatment
> just as an example module that uses this hook.
This is a good point. As I said above, the ideal solution is to redesign the
entire keycode handling system. However, I'm not convinced this is going to
happen. At this point, using keycodes is just too limiting.
To anyone who knows alot about this:
Can you please reply with information on the feasability of expanding the
keycode space? I agree with Andries that not having to parse the scancodes
twice would be really nice. Perhaps the upper ranges of of keycodes could be
for use with keyboard addons and fancy features, and the lower ranges(less than
256) would be just passed to userland, as it is now.
Ryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/