Re: usb mouse support update plans

> 
> > On Tuesday 03 January 2006 17:23, Jordan Sissel wrote:
> >> On my grande circuit of trying to make mouse support better for FreeBSD,
> >> I've finally come about to working on usb mice. I've done a bit of
> >> research about usb hid, and I need some feedback on where I should take
> >> usb mouse support.
> >>
> >
> > Oh, good! :)
> >
> >> Moral of this story is that I want to make known-broken mice work with
> >> FreeBSD. This includes *several* Microsoft USB models, many ps/2 mice
> >> (including usb->ps2 adapted mice), and probably others.
> >>
> >
> >>
> >> How can you help?  If you are having issues with mouse support in
> >> FreeBSD I need to know the following:
> >>    - Mouse model and brand (as specific as possible would help)
> >>    - Symptoms of strange behavior
> >>    - Environment (moused+ums? plain ums in X? plain psm in X? moused
> >>      with serial mice?)
> >
> > Check usb/77604 for some mice known to have problems and for a fix for 
> > them.
> 
> Indeed "Oh Good!"
> 
> I would soooo love to ditch the hacked knoppix-4 I'm currently net booting 
> and nfs mounting to run on my thin client. (I guess a nfs mounted full dvd 
> version of knoppix-4.0 with 4 more gigs of room to grow besides would have 
> to be a fat client)

Would it be too much trouble for you to describe your system in a bit
more depth? "Thin client" is... well, not very helpful.

> The only reason I'm using linux on this thing is because this usb wireless 
> keyboard with built-in touch pad works under linux and not under freebsd, 
> including 6.0 current as of several weeks ago.

That's a really crummy reason to be running Linux.

I'm sorry, but it is.

[...]

> Symptoms: keyboard works fine, mouse is unrecognized. (neither at the OS or 
> X levels)
>
> It's been several weeks since I gave up so I'll need to perform tests again 
> to define "mouse is unrecognized" better.

Well, maybe your memory isn't that great, but the intarweb never forgets.
Travelling back in time to the freebsd-usb mailing list from July, we
find a similar post from you about this very same issue, in which you
thankfully had the presence of mind to say:

> dmesg on 5.4-release shows this near the end:
>
> 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 kbd1 at ukbd0

There's something very strange about this output, by the way. I don't
think you cut & pasted it exactly as it appeared on the screen. I think
it should look more like this:

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

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

uhid(4) is a generic driver for USB devices in the Human Interface Device
class. This includes mice, keyboards, joysticks, gamepads, drawing
tablets, and so on. Keyboards and mice are considered special enough
to warrant their own private drivers (ukbd(4) and ums(4)), largely to
make them emulate the behavior of their non-USB ancestors (thereby
allowing existing application software to use USB keyboards and mice
without having to be modified to include special USB support). Any HID
device that doesn't have a special driver just gets picked up by the
uhid(4) generic driver.

When you plug in your mouse, the USB mouse driver probe checks
its HID usage group to make sure it's a 'generic desktop' device
with 'mouse' usage. If this check fails, the driver decides the
device isn't really a mouse and fails the probe. Later, the uhid(4)
driver will claim the device since nobody else did.

Now, there's two possible things that can be going wrong here:

1) The ums(4) driver isn't loaded. Given that the ums(4) driver is
   part of the GENERIC kernel, the only way this could have happened
   is if you went and built your own kernel and then for some stange
   reason took 'device ums' out of the config file. You never bothered
   to state whether or not you compiled your own kernel, so I have
   no way of knowing whether or not this happened.

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

If the issue is thing 1, then you need to either add 'device ums'
back to your kernel config, or add 'ums_load="YES"' to your
/boot/loader.conf file.

If the issue is thing 2, then you need to do the following:

- Boot up FreeBSD 6.0.
- Plug the wireless keyboard/mouse into a USB port on a FreeBSD machine
- Wait until you see the ukbd0/uhid0 probe output on the console (i.e.
  wait until FreeBSD sees the devices)
- Run "dmesg" and save _ALL_ the output. Report it to us so we can
  see it. And I mean _ALL_ of it.
- Run the following commands, as root:

	# usbdevs -v
	# usbhidctl -f /dev/uhid0 -r

- This should show all the information that the mouse reports about itself.
  Save the output (there'll probably be a page or two of information) and
  report _ALL_ of it here so that we can see it. And I mean _ALL_ of it.

If it really is a USB mouse class device and it's just misrepresenting
itself, then it's likely the USB_MATCH() routine in sys/dev/usb/ums.c
can be tweaked a little to recognize the device. But we won't know for
sure until we see the output of the usbhidctl command.

> I _think_ on the latest ThinBSD, which is 5.4-release, and all later 
> versions, that the touch pad pointer works but not the buttons. I may be 
> misremembering but we don't have to guess once I try it again.

Why didn't you try it again before writing this e-mail? Then your faulty
memory wouldn't be an issue.

Also, what the heck is ThinBSD?

> Some people have said it might be that it's because there is a single usb 
> wireless receiverfor 3 devices (keyboard, built-in touchpad mouse, and a 
> seperate optical mouse which I don't happen to use.) And the keyboard sort 
> of takes exclusive control of the usb device.

The people who told you this are feelthy liars. Feelthy, I say.

> The device works out of the box, no drivers, on XP and I can use usbsnoop if 
> desired too to capture xp traffic, but since it already works on linux then 
> the code to make it work is already out there to be mined right?

I don't think the solution will be all that complicated. Just go boot up
FreeBSD 6.0 and report the stuff I asked for.

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