[PATCH 1/6] use embedded input_local.h instead of system linux/input.h

Matthew Garrett mjg59 at srcf.ucam.org
Sun Nov 2 17:21:01 PST 2008


On Mon, Nov 03, 2008 at 02:07:32AM +0100, Michael Biebl wrote:

> Yeah, and this thight coupling actually would be a pita, as then hal
> would dictate what kernel can be used (or vice versa).
> Say, your distro decides to go with 2.6.27 for you next release, then
> you'd have to pick a hal release which supports that version in
> local_input.h or you have to start patching local_input.h. That would
> we a major headache.

Look at input-keyboard.c. There's a static array of keycodes. To add 
support for a new kernel keycode or switch it's already necessary to 
edit the code. Using the system header means adding #ifdefs around any 
code defined after an arbitrary point in time. A new hal release is 
needed in any case - not shipping the keycode definitions means that 
distributions have to upload it twice (once when it's first released, 
and once when the distribution gets the updated kernel headers). It's 
clearly more work.

Building hal with a newer set of keycodes doesn't prevent it from 
working with older kernels.
-- 
Matthew Garrett | mjg59 at srcf.ucam.org


More information about the hal mailing list