Subject: Re: Newer multimedia keyboards and NetBSD
To: Martijn van Buul <pino+gmane_os_netbsd_current@dohd.org>
From: Iain Hibbert <plunky@rya-online.net>
List: current-users
Date: 02/04/2007 08:26:14
On Sat, 3 Feb 2007, Martijn van Buul wrote:

> 1) Implement a specific driver for these uhid devices, which could register
>    itself as a kind of wskbd device, attaching to the same mux as the
>    "QWERTY"-part of the keyboard.

This is a good way to do it

> 	 - 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[*])

> 	 - 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?

> 2. Make ukbd handle these additional uhid devices. A bad idea, IMHO,
>    but I might be wrong.

If the events can be translated cleanly to keymap entries then I don't see
a problem with adding the capability..

>
>         - 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.. 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..

> 3. Have usbhidaction deal with it by allowing it to generate wskbd events

its not great

iain
[*] its on my list to merge Bluetooth and USB HID