Re: usb mouse support update plans

From: Bill Paul <wpaul_at_FreeBSD.ORG>
Date: Wed, 4 Jan 2006 16:55:50 +0000 (GMT)
> 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.

I think you can do this with usbhidaction(1). Like I mentioned earlier,
try using usbhidctl -f /dev/uhid0 -r to see what sort of features the
device reports. It sounds like it just has some buttons. You can use
usbhidaction(1) to have the buttons perform specific actions when activated.
You just need to create a config file and launch usbhidaction at system
startup. This should be fairly easy to do for the volume controls at
least: I'm not sure how to use usbhidaction to emulate keyboard presses.

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

I don't think so. It's convenient to make USB keyboards and mice appear
to work just like legacy keyboards and mice.

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

Something tells me this isn't the case. It's possible for a single USB
device to have multiple interfaces, but bear in mind that you have to
be able to use both the keyboard and mouse at the same time. For that, you
would need two separate device instances, not one device whose personality
can be toggled back and forth between keyboard mode and mouse mode.

Once again, we need to know what usbdevs -v and usbhidctl have to say
before we can speculate further.

-Bill

--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================
Received on Wed Jan 04 2006 - 15:55:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:50 UTC