Subject: Re: Newer multimedia keyboards and NetBSD
To: None <email@example.com>
From: Martijn van Buul <firstname.lastname@example.org>
Date: 02/04/2007 12:26:32
* Iain Hibbert:
> On Sat, 3 Feb 2007, Martijn van Buul wrote:
>> - Done the Linux-way, which seems to be a little bit offhand,
>> this might result in dozens of drivers for individual
>> keyboards, which is hardly desirable.
> No, this results in drivers for usage pages which is exactly what you
> want. its how the HID system is set up (Bluetooth HID is the same[*])
Well, I would still prefer some way of telling the driver what usage table
to use in some way from userland, instead of having individual drivers for
Microsoft keyboards, Logitech keyboards and a plethora of different keyboards
from Taiwanese manufacturers, when they really only differ in their usage
>> - Distinguishing between these multimedia-keyboard-uhid devices
>> and other generic uhid devices might be tricky; Microsoft Windows
>> obviously does it (It supported many of the extended keys without
>> installing any software; it only needed it for the Microsoft-
>> specific keys); I wouldn't be surprised if they merely recognise
>> it by the fact that it's a composite device with a regular
>> keyboard HID. I'm not sore it's going to be easy to teach
>> autoconf about this. Of course, there's always to option of
>> specifying specific product/vendor combo's, but I was hoping for
>> a generic approach.
> not sure if you've examined uhidev(4) yet?
Yes, I have, but maybe not good enough :) If I can somehow convince uhidev
to take *both* of the configurations, that'd be a start. Right now, I get
two uhidev busses for a single physical device.
>> 2. Make ukbd handle these additional uhid devices. A bad idea, IMHO,
>> but I might be wrong.
>> - It violates the device tree. Since to my best knowledge
>> NetBSD doesn't have a "possibly composite USB device"
>> abstraction layer, it would mean combining leaf nodes that
>> have grown apart considerably already. It just doesn't feel
> NetBSD _does_ have this possibly composite USB device abstraction layer so
> far as I know..
Hm, I'll look further into this then, because I think it's needed for a
> each USB device provides a descriptor and handlers are assigned for each
> portion. USB-HID takes this a step further and provides another descriptor,
> then handlers are provided for each report.
> uhid(4) is used when there is no specific handler for a report..
I know. The problem is twofold:
1) These additional HIDs probably can't be caught by a class driver, without
changing the behaviour of other generic HIDs. In other words, I don't
think it's possible to write a reliable _match() for it. The fact that
uhidev* devices don't have a product/vendor-id locator means that you
can't even do a lookup based on that at this point. You can do it
in a kernel config file, but only by configuring a device to a specific
uhidev device (which *can* be tied to an individual product/vendor).
2) uhidev outputs two 'uhidev-busses', each containing a single report-id
right now. Iff I could convince uhidev to cheat and bind to *both*
usb configurations and output both reportid's on a single uhidev-bus,
then I'd be set, because then the presence of a ukbd on the uhidev
bus can be used. In fact, in that case it would also be possible to
have ukbd respond to several report-ids instead of just one.
Thanks for your input; it's given me something to ponder about on a grey
Martijn van Buul - email@example.com