Re: [Mactel-linux-devel] Missing keys in kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch ?

[Jerome F. <jf...@gm...>]

2008/6/2 Jerome Flesch <jf...@gm...>:
>>> >> > The way you're doing it:
>>> >> >
>>> >> >>  static struct hidinput_key_translation apple_fn_keys[] = {
>>> >> >>         { KEY_BACKSPACE, KEY_DELETE },
>>> >> >>         { KEY_F1,       KEY_BRIGHTNESSDOWN, APPLE_FLAG_FKEY },
>>> >> >>         { KEY_F2,       KEY_BRIGHTNESSUP,   APPLE_FLAG_FKEY },
>>> >> >>         { KEY_F3,       KEY_FN_F5,          APPLE_FLAG_FKEY }, /*
>>> >> >> Exposé */
>>> >> >>         { KEY_F4,       KEY_FN_F4,          APPLE_FLAG_FKEY }, /*
>>> >> >> Dashboard */
>>> >> >> +        { KEY_F5,      KEY_KBDILLUMDOWN,   APPLE_FLAG_FKEY },
>>> >> >> +        { KEY_F6,      KEY_KBDILLUMUP,     APPLE_FLAG_FKEY },
>>> >> >>         { KEY_F7,       KEY_PREVIOUSSONG,   APPLE_FLAG_FKEY },
>>> >> >>         { KEY_F8,       KEY_PLAYPAUSE,      APPLE_FLAG_FKEY },
>>> >> >>         { KEY_F9,       KEY_NEXTSONG,       APPLE_FLAG_FKEY },
>>> >> >
>>> >> > breaks keyboards without these special keys, e.g. external USB
>>> >> > keyboards. Also, I think some MacBook Pros have/had a different layout
>>> >> > of the special keys, though you may already account for that.
>>> >> >
>>> >> I had a quick look and on Google images, and the only similar layout
>>> >> but different for these 2 keys that I can find is the one of the alu
>>> >> wireless keyboard of Apple:
>>> >> http://www.thomann.de/fr/prod_bdb_AR_119224.html?image=0&sid=c0c7390b59f0507d18fadbba8776c7b8
>>> >
>>> > Same for the USB aluminum keyboard.
>>> >
>>> >> But these two keys seem to be mapped to nothing in fact. So, imho,
>>> >> mapping these two keys to keyboard brightness control, even if it's
>>> >> not applicable to these keyboard, still makes sense to me : It keeps
>>> >> the layout consistent (having to press Fn to get the Fx keys except
>>> >> for F5 and F6 is weird), and should no other side effect on these
>>> >> keyboards.
>>> >
>>> > I disagree; as there's no special function engraved on these keys, they
>>> > should always generate F5/6.
>>> >
>>> So, we should prevent macbook users from using their keyboard
>>> backlights to allow people using other apple keyboards to use F5/F6
>>> with or without the Fn key ?
>>
>> Of course not (where did you get that idea?). They should just use a
>> different table.
>>
> Ok, but then, how do you suggest to make the difference between the
> keyboards needing the macbook table and the others ? The easiest
> solution would be to define another quirk. But as I said, the integer
> used to store the list of quirks to use is almost full (see
> include/linux/hid.h) which makes it, imo, a not-lasting-enough
> solution (If we go this way, I have the feeling we will have to find
> another way at the next kernel release). The other solution would be
> to hardcore some products id drivers/hid/hid-input.c using a macro,
> which is, still imo, kind of dirty (I did it in my patch because it's
> already done currently in the code of the mainstream kernel).
> So, what do you think we should do precisely ?
>
Hmm .... actually, I just thought of something pretty stupid/simple:
add another field to the structure
drivers/hid/usbhid/hid-quirks.c:hid_blacklist. As a temporary
solution, it should be fine. Does anyone know any possible side effect
of adding a field to this structure ?