Menu
▾
▴
mactel-linux-devel
|
[Mactel-linux-devel] Missing keys in
kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch ?
From: Jerome F. <jf...@gm...> - 2008-05-29 07:21:07
|
Hello,
In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
keys seem to be missing in the array "apple_keyboard_fn_keys":
{ KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
{ KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
Without these two lines, it's not possible for me on my macbook pro
4.1 to adjust the light of the keyboard with pommed, but with them, it
works fine.
I'm also wondering : Is there any plan to integrate your patches to
the mainstream linux kernel ?
|
|
From: Ludwig 'K. N. <lu...@no...> - 2008-05-30 05:40:36
|
Jerome Flesch a écrit :
> Hello,
Hi,
>
> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
> keys seem to be missing in the array "apple_keyboard_fn_keys":
> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>
> Without these two lines, it's not possible for me on my macbook pro
> 4.1 to adjust the light of the keyboard with pommed, but with them, it
> works fine.
Indeed, I just recompile with those two lines above and it works, thanx
a lot :) BTW, do you know what KEY_CYCLEWINDOWS (F3) and KEY_CONFIG (F4)
refer to ? pommed returns "KBD: inhibit clear 0x08 -> 0x00" for both of
them, which have no result on keyboard backlight.
>
> I'm also wondering : Is there any plan to integrate your patches to
> the mainstream linux kernel ?
Regards,
--
Ludwig 'Kn' Noujarret
lu...@no...
|
|
From: Jerome F. <jf...@gm...> - 2008-05-30 05:51:15
|
> Hi,
>
> Jerome Flesch wrote:
>>
>> Hello,
>>
>> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
>> keys seem to be missing in the array "apple_keyboard_fn_keys":
>> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
>> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>>
>> Without these two lines, it's not possible for me on my macbook pro
>> 4.1 to adjust the light of the keyboard with pommed, but with them, it
>> works fine.
>
>
> It would be great if you could test if the problem still happens on
> 2.6.25.x, and port it if necessary (I quickly tried, but it is not trival,
> as some files changed quite importantly in the kernel)
>
Ok, I will try it as soon as I have time for it (probably tomorrow or Saturday).
>> I'm also wondering : Is there any plan to integrate your patches to
>> the mainstream linux kernel ?
>
> - applesmc*: My responsability, but I'm lacking time to get them integrated
> (and some need disk-protect*)
> - appletouch*: Sven Anders
> - disk-protect* + export-lookup_dev.patch: Elias Oltmanns (from hdaps) and
> me (some exports to be able to park the head from my driver)
> - sigmatel_*: Maybe I should send them upstream, but to be honest I'm not
> sure these are absolutely necessary, or if you should set your model using a
> kernel parameters.
>
> So basically there are 2 patches I could send upstream relatively easily:
> applesmc-retry-when-accessing-keys.patch
> applesmc-remove-debugging-messages.patch
> (the 2nd one fixing a problem occuring when the 1st one is used IIRC)...
>
> I'll get that done, when I have time...
>
Actually, even if I don't know much about the process of development
of the kernel, I have a good knowledge in C programming (Unix and
embedded), so, if you feel I could help you, just ask :)
> Best regards,
>
> Nicolas
>
|
|
From: Jerome F. <jf...@gm...> - 2008-05-30 05:56:41
|
>> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
>> keys seem to be missing in the array "apple_keyboard_fn_keys":
>> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
>> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>>
>> Without these two lines, it's not possible for me on my macbook pro
>> 4.1 to adjust the light of the keyboard with pommed, but with them, it
>> works fine.
>
> Indeed, I just recompile with those two lines above and it works, thanx a
> lot :) BTW, do you know what KEY_CYCLEWINDOWS (F3) and KEY_CONFIG (F4) refer
> to ? pommed returns "KBD: inhibit clear 0x08 -> 0x00" for both of them,
> which have no result on keyboard backlight.
>
Pommed doesn't handle these keys. And I think it makes sense since
this way it let you map them to whatever you want. I think
KEY_CYCLEWINDOWS correspond to the Compiz-fusion plugin "Scale", and
KEY_CONFIG is probably supposed to be mapped to launch
gnome-control-center or kcontrol (actually I'm too lazy to reboot
under MacOSX to check :)
|
|
From: Ludwig 'K. N. <lu...@no...> - 2008-05-30 06:34:18
|
Jerome Flesch a écrit :
>>> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
>>> keys seem to be missing in the array "apple_keyboard_fn_keys":
>>> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
>>> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>>>
>>> Without these two lines, it's not possible for me on my macbook pro
>>> 4.1 to adjust the light of the keyboard with pommed, but with them, it
>>> works fine.
>> Indeed, I just recompile with those two lines above and it works, thanx a
>> lot :) BTW, do you know what KEY_CYCLEWINDOWS (F3) and KEY_CONFIG (F4) refer
>> to ? pommed returns "KBD: inhibit clear 0x08 -> 0x00" for both of them,
>> which have no result on keyboard backlight.
>>
> Pommed doesn't handle these keys. And I think it makes sense since
> this way it let you map them to whatever you want. I think
> KEY_CYCLEWINDOWS correspond to the Compiz-fusion plugin "Scale", and
> KEY_CONFIG is probably supposed to be mapped to launch
> gnome-control-center or kcontrol (actually I'm too lazy to reboot
> under MacOSX to check :)
OK, since it's confirmed pommed don't use them, I just mapped them
respectively to XF86RotateWindows and XF86MyComputer in my .Xmodmap
Thanx,
--
Ludwig 'Kn' Noujarret
lu...@no...
|
|
From: Jerome F. <jf...@gm...> - 2008-06-02 03:00:08
Attachments:
hid-apple.patch
|
>> Hello,
>>
>> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
>> keys seem to be missing in the array "apple_keyboard_fn_keys":
>> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
>> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>>
>> Without these two lines, it's not possible for me on my macbook pro
>> 4.1 to adjust the light of the keyboard with pommed, but with them, it
>> works fine.
>
>
> It would be great if you could test if the problem still happens on
> 2.6.25.x, and port it if necessary (I quickly tried, but it is not trival,
> as some files changed quite importantly in the kernel)
>
Done. I had to port the patch for the 2.6.24 to the 2.6.25.4 (some
part of the 2.6.24 patch were already included mainstream ?). I've
joined the patch to this mail.
The problem with the two keys is confirmed and solved in this patch.
I prefered to not add another "#define APPLE_QUIRK" as done in the
2.6.24 patch because the 2.6.25 seems to include a lot more quirks and
almost all the bits of the 32bits integer contaning the list of quirk
to apply are used now. Moreover, the word "powerbook" has been
replaced in many places by "apple", so adding another quirk name using
the word "apple" would have been confusing :/
Instead, I did like it seems to be done in the mainstream 2.6.25.4 :
Look if the product ID is between 0x220 and 0x300 to know if it's a
powerbook keyboard or another apple keyboard. According to the list of
apple keyboards in drivers/hid/usbhid/hid-quirks.c, it should be fine.
Hm, just two other things:
- Why is there no 'apply' script in
mactel/kernel/mactel-patches-2.6.25 like in
mactel/kernel/mactel-patches-2.6.24 ? It makes these patches much
easier to use for non-dev people.
- Also, can you integrate my two-lines fix to the patch for the kernel
2.6.24 please? I had a problem with the kernel 2.6.25 older than the
2.6.25.4 (bug in the SATA driver), and I have the feeling that the
kernel 2.6.24 can still be useful for some people.
|
|
From: Jerome F. <jf...@gm...> - 2008-06-02 07:58:05
|
> On Sun, 2008-06-01 at 20:00 -0700, Jerome Flesch wrote:
>> >>
>> >> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
>> >> keys seem to be missing in the array "apple_keyboard_fn_keys":
>> >> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
>> >> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>> >>
>> >> Without these two lines, it's not possible for me on my macbook pro
>> >> 4.1 to adjust the light of the keyboard with pommed, but with them, it
>> >> works fine.
>> >
>> >
>> > It would be great if you could test if the problem still happens on
>> > 2.6.25.x, and port it if necessary (I quickly tried, but it is not trival,
>> > as some files changed quite importantly in the kernel)
>> >
>> Done. I had to port the patch for the 2.6.24 to the 2.6.25.4 (some
>> part of the 2.6.24 patch were already included mainstream ?).
>
> Yeah, I pushed that via the hid tree for external Aluminum USB
> keyboards.
>
>> I've joined the patch to this mail.
>>
>> The problem with the two keys is confirmed and solved in this patch.
>>
>> I prefered to not add another "#define APPLE_QUIRK" as done in the
>> 2.6.24 patch because the 2.6.25 seems to include a lot more quirks and
>> almost all the bits of the 32bits integer contaning the list of quirk
>> to apply are used now. Moreover, the word "powerbook" has been
>> replaced in many places by "apple", so adding another quirk name using
>> the word "apple" would have been confusing :/
>> Instead, I did like it seems to be done in the mainstream 2.6.25.4 :
>> Look if the product ID is between 0x220 and 0x300 to know if it's a
>> powerbook keyboard or another apple keyboard. According to the list of
>> apple keyboards in drivers/hid/usbhid/hid-quirks.c, it should be fine.
>
> 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
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.
My quick look on Google images also showed me some macbooks pro
(probably first generation) having the powerbook layout (
http://www.notebookreview.com/assets/15839.jpg ). But none of them
having one similar-but-different to mine.
> I'm CC'ing Michael Hanselmann, who's done most of the work on this
> stuff. I think his plan was to add a new field to the quirks struct so a
> single quirk can use several different tables. Michael, have you
> submitted any of that yet?
>
|
|
From: Jerome F. <jf...@gm...> - 2008-06-02 08:27:55
|
>> > 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 ? I know you said that a better way of
making all these quirks is in process, but in the meantime, I still
think that enforcing consistency across all Apple keyboards is the
better solution. Moreover, people using external apple keyboards will
still be able to map Fn-F5 Fn-F6 to something else (including F5/F6),
but MacBook Pro users need these keys to be mapped to the control of
the keyboard backlights because these key codes are hard-coded in
pommed. Actually, even if they weren't, they would have to map F5/F6
to be coherent with the drawing on their keyboard, probably
conflicting with many other use of F5/F6.
|
|
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 ?
|
|
From: Jerome F. <jf...@gm...> - 2008-06-02 17:44:03
|
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 ?
|
|
From: Jerome F. <jf...@gm...> - 2008-06-08 06:51:02
Attachments:
hid-apple.patch
|
>> >>> >> > 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 ...). |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X