Phil Endecott wrote:
I have the bluetooth version of the Apple aluminium keyboard and I'm
having trouble getting it to work right.
I'm running 2.6.25 and I can see that it has some quirks for these
keyboards that should do some of the things that I want.
(Specifically, HID_QUIRK_APPLE_ISO_KEYBOARD and
HID_QUIRK_APPLE_HAS_FN.) But it looks as if they're keyed on the USB
vendor/product IDs, which presumably don't match my bluetooth device.
Can someone please explain how input quirks should be applied to
bluetooth devices?
I believe I've worked this out now. In summary, this entry:
/* Apple Bluetooth alu ISO keyboard */
{ 0x05ac, 0x022d, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_APPLE_ISO_KEYBOARD },
and presumably these untested ones:
/* Apple bluetooth alu ANSI keyboard */
{ 0x05ac, 0x022c, HID_QUIRK_APPLE_HAS_FN },
/* Apple bluetooth alu JIS keyboard */
{ 0x05ac, 0x022e, HID_QUIRK_APPLE_HAS_FN },
need to be added to hidp_blacklist in net/bluetooth/hidp/core.c; but I
note that this moved to drivers/hid/hid-apple.c in Jiri Slaby's patch
"HID: move apple quirks" posted here on 2008-05-16. (I'm not posting
this as a proper patch because of this move; I haven't applied Jiri's
patches to my 2.6.25 tree and I don't think it would be useful to post
a patch that would conflict with them. Jiri, presumably you'll have no
trouble adding those entries to your tree, right?)
I'm still unsure how all of this works though. Those are USB vendor
and product IDs. Does bluetooth "borrow" the same scheme of
vendor/product IDs that USB uses? I got the IDs from the table in
drivers/hid/usbhid/hid-quirks.c, but I can't see any way to get find
them from my hardware; "hcitool info" doesn't report them. Were the
entries in drivers/hid/usbhid/hid-quirks.c actually useful before?
Perhaps they would be applied if you had a bluetooth dongle in "HID
proxy" mode. If bluetooth devices do all use USB vendor/product IDs,
maye the better solution is to look them up in a single table rather
than splitting it into separate parts for "real" USB devices and
bluetooth devices. Hmm, maybe that's what Jiri's patches from
2008-05-16 are doing....
Anyway, I now have things like home/end/pgup/pgdown and the keys to the
left of 1 and Z doing the right thing, which is great. There are a
couple more things I'd like to change though; does anyone have any
opinions on either of these:
- I have no delete key, so I can't type ctrl-alt-del! (I have to keep
another keyboard plugged in just for this!) I'd like to use the eject
key, which is immediately above the backspace key, for this. (What do
Mac users do?)
- The FN key and the left Ctrl key are the same size and the keycaps
can easily be exchanged. The order of these keys is often something
that people complain about, e.g. if they're used to pressing the
bottom-left key on their desktop keyboard for ctrl but now find that it
isn't. Often there is nothing that can be done about this because the
logic for the FN key is inside the keyboard and not fixable in
software, but in the case of this keyboard I believe it could be
changed in the kernel. Actually I'm not too bothered about it because
I use caps lock as ctrl, but maybe other people would consider it a
useful feature.
Cheers, Phil.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
