Re: usb mouse support update plans

Hello,

I will join discussion to make it more interesting :-)

> > ukbd0: Sony RF Receiver, rev 1.10/1.00, addr 2, iclass 3/1
> > kbd1 at ukbd0
> > uhid0: Sony RF Receiver, rev 1.10/1.00, addr 2, iclass 3/1
...
> But even this isn't quite right, because I don't think both devices
> should appear at address 2 on the same hub. I suspect you transcribed
> the information and typed it in wrong.
He/She does not. I have the same situation (two devices on same addr):

ums0: vendor 0x1733 Wireless RF Mouse, rev 1.10/0.01, addr 2, iclass 3/1
ums0: 3 buttons and Z dir.
uhid0: Cellink Co., LTD. Wireless RF Mouse, rev 1.10/0.01, addr 2, iclass 3/1

ums0 works OK but extra buttons (uhid0) does not. Windows recognise my
mouse as UHID
device. Those extra buttons in windows works as mute, volume up,
volume down, page up,
page down. My mouse has two modes (mouse and presentation tool). My
mouse is neither
mouse nor keyboard. It is something between.

It would be great if I could use my mouse as presentation tool even
though it is the poorest reason in the world.
> Assuming the presence of the 'uhid0' line isn't a mistake, the real
> description of the problem is: "the mouse is showing up as a uhid(4)
> evice instead of a ums(4) device."
Because mouse is more uhid device than mouse IMHO.

...
> Keyboards and mice are considered special enough
> to warrant their own private drivers (ukbd(4) and ums(4))
So maybe this philosophy should be reconsidered?

...
> 2) The mouse is not reporting itself as a generic desktop/mouse
>    device, and the ums(4) driver is ignoring it.

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?

Best regards,
Dalius