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

[Jerome F. <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 ?
>
> Not me (ask the hid developers maybe? :), but yeah, basically the
> quicker'n'dirtier way is to extend the existing device ID test for
> selecting the table, and the cleaner way would be to add a field to some
> quirk struct where the table pointer can be stored.
>
Here is a "quirk & dirty" patch for the kernel 2.6.25.4. For the keys
F5/F6, it should only affect Apple Wellspring 2 keyboards (the one I
have) : I've simply used another bit in the integer storing what
quirks to use (2 bits left ...).