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

Michael Biebl mbiebl at gmail.com
Sun Nov 2 17:32:10 PST 2008


2008/11/3 Matthew Garrett <mjg59 at srcf.ucam.org>:
> 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.

Ok, this explanation does make a lot more sense.
Thanks a lot for the pointer.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


More information about the hal mailing list