Re: usb mouse support update plans

Alexander Leidinger wrote:
> On Wed, 4 Jan 2006 13:17:56 +0200
> Dalius Dobravolskas <dalius.dobravolskas_at_gmail.com> wrote:
> 
> > 3) The device reported itself as keyboard and algorithm does not check
> > for mouse; It must be checked it is just my guess ;) Brian, could you
> > try to remove ukbd from kernel in this case and look if mouse is
> > found?
> 
> Maxime (CCed) is working on porting the uhidev part from NetBSD. This is
> supposed to fix those problems (at least if I read the symptoms
> correctly).
> 
> Bill, the problem is that some combi-devices don't meet the
> expectations of FreeBSD. AFAIK they report one device with 2 functions
> while FreeBSD currently needs 2 devices to work as expected.

Yes, it might indeed be an USB HID device with mutliple report IDs, in
which case it should work OK as soon as I finish merging the NetBSD
code.  In the new world order, there is an uhidev(4) driver that
attaches to any USB HID device, and it spawns one child per report ID.
The child can be any of ums(4), ukbd(4), ucycom(4), etc, or the "base"
uhid(4) driver if none of the previous ones matched.

Sample output from my dev box :

uhidev0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1
ums0 on uhidev0

And now a multiple report id device :

uhidev1: vendor 0x0810 Twin USB Joystick, rev 1.00/1.06, addr 2, iclass 3/0
uhidev1: 2 report ids
uhid0 on uhidev1
uhid0: input=7, output=4, feature=0
uhid1 on uhidev1
uhid1: input=7, output=4, feature=0

The second device allows one to plug two PS2 gamepads, and I recommend
anyone that likes xmame to buy one.  It's actually what prompted this
work :-).

FWIW, it shouldn't take long for me to finish this stuff, but I'm
currently stuck with ukbd(4) making my system panic in weird ways...
Life would have probably been easier if our kbd framework wasn't such a
mess.

Cheers,
Maxime