From: Jerome F. <jf...@gm...> - 2008-06-02 17:14:12
|
>> >> > 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 ? |