Messages in this thread | | | From | Ryan Lortie <> | Subject | Re: [patch] Re: "Internet Keyboard" support for Linux | Date | Sat, 11 Dec 1999 06:41:14 +0000 |
| |
> Yes, but as I said in my previous note: I think you should consider > using keycode instead of scancode.
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/
| |