Hi,
there you go... Hope it makes sense to you :-D
-- Christoph
Hans Petter Selasky schrieb:
Hi,
It's not required to add a quirk for apple's I think. All the keys should be
described in the HID descriptor. Can you dump the HID descriptor of your
device?
usbconfig -u 0 -a 2 do_request 0x81 0x06 0x2200 0 0x1000
Numbers after "-u" and "-a" must match those after "ugen" when your device is
plugged. The command above assume the keyboard resides at interface zero.
--HPS
On Saturday 16 May 2009, Christoph Langguth wrote:
Hi Hans Petter,
thanks for the quick reply!
I tried your patch but it doesn't work, all I get is:
May 16 14:00:01 marvin kernel: ukbd0: <Apple Internal Keyboard> on usbus5
May 16 14:00:01 marvin kernel: device_attach: ukbd0 attach returned 6
I don't know why this happens... I tried, but unfortunately I didn't
quite understand what the patch is supposed to do :-)
In the meantime, I had continued writing up a slightly cleaner patch,
that also allows to fully utilize the keyboard. Some considerations first:
- Quite a few apple keyboards (mine included) have an additional quirk
in that they switch two keys. (On [1], that's all the ones having the
APPLE_ISO_KEYBOARD flag). But of course, it's not all of them :-(
- To fully make use of the keyboard, one also needs to consider the Fn
key ("part of" the 10th (9th payload) byte), so as to be able to be able
to type "vital" keys like DEL, INS, PGUP etc. Judging from [1],
everything from Apple that actually is a keyboard also has this FN key,
so I would expect all of these keyboards to send that 9th byte
- It seems that some, but not all, of those keyboards, send this first
byte (the one you called hid_id)
In light of the above, would it make sense to
- try to detect the HID ID byte in the manner that you suggested in your
patch (assuming that I can figure out the logic, and what's going wrong
there, I think it's the cleanest and vendor-independent solution)
- add an additional UKBD-specific quirk for the ISO_KEYBOARD problem
(into usb/quirks/...)
- assume that any available 9th byte contains the Fn key information --
or would yet another quirk, listing all affected products, be more
reliable?
[1]: https://www.linuxhq.com/kernel/v2.6/28-rc8/drivers/hid/hid-apple.c
In any case, I have attached the "full" patch that works for me -- as
stated above, it's not as clean as it should be because it only works
for my specific piece of hardware and doesn't consider the latest
questions/proposed solution... but it already contains all the required
logic so that you can see what I meant.
Again, thanks for your help!
Cheers
Chris
Hans Petter Selasky wrote:
On Friday 15 May 2009, Christoph Langguth wrote:
Christoph Langguth
Hi,
Can you try the following patch on 8-current?
http://perforce.freebsd.org/chv.cgi?CH=162145
--HPS
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
REQUEST = <0x05 0x01 0x09 0x06 0xa1 0x01 0x85 0x01 0x05 0x07 0x19 0xe0 0x29
0xe7 0x15 0x00 0x25 0x01 0x75 0x01 0x95 0x08 0x81 0x02 0x95 0x01 0x75 0x08 0x81
0x01 0x95 0x05 0x75 0x01 0x05 0x08 0x19 0x01 0x29 0x05 0x91 0x02 0x95 0x01 0x75
0x03 0x91 0x01 0x95 0x06 0x75 0x08 0x15 0x00 0x26 0xff 0x00 0x05 0x07 0x19 0x00
0x29 0xff 0x81 0x00 0x05 0x0c 0x75 0x01 0x95 0x01 0x09 0xb8 0x15 0x00 0x25 0x01
0x81 0x02 0x05 0xff 0x09 0x03 0x75 0x07 0x95 0x01 0x81 0x02 0xc0 0x05 0x0c 0x09
0x01 0xa1 0x01 0x85 0x52 0x15 0x00 0x25 0x01 0x75 0x01 0x95 0x01 0x09 0xcd 0x81
0x02 0x09 0xb3 0x81 0x02 0x09 0xb4 0x81 0x02 0x09 0xb5 0x81 0x02 0x09 0xb6 0x81
0x02 0x81 0x01 0x81 0x01 0x81 0x01 0x85 0x09 0x15 0x00 0x25 0x01 0x75 0x08 0x95
0x01 0x06 0x01 0xff 0x09 0x0b 0xb1 0x02 0x75 0x08 0x95 0x02 0xb1 0x01
0xc0><)%uuu)uu&)u%uR%u%uu>
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
