* 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
tables

>> 	 - 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
>> 	  right.
>
> 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
clean solution.

> 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
sundayafternoon :)

-- 
Martijn van Buul - pino@dohd.org