Re: usb mouse support update plans

----- Original Message ----- 
From: "Bill Paul" <wpaul_at_FreeBSD.ORG>
To: "Brian K. White" <brian_at_aljex.com>
Cc: <freebsd-current_at_freebsd.org>
Sent: Wednesday, January 04, 2006 5:45 AM
Subject: 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.

Don't let "thin client" imply strange hardware. It's not very special 
hardware other than small form factor and low power dissipation.
Normal x86 platform. It's this board from intel: 
http://www.mini-itx.com/news/17911903/
I was not able to find any real docs about it on the net and I got it used 
on ebay without docs.
It came with a plain unmarked cd-r driver disk which provides basic clues 
but everything was already supported out of the box in freebsd anyways.

Here is the last kernel config I had used on it. Note this appears to 
reflect a test in progress. atkbdc, atkbdc and psm are commented out and 
ukbd & ums are built-in.
Looks like the generic kernel would run fine on it as all I did was remove 
unused nic and disk controllers and build in snd_ich.
http://keyofr.homeunix.net:81/netgear_hub_thin_client/HUBPC
(dmesg provided below)

And build it with this make command:
make CPUTYPE=pentium3m KERNCONF=HUBPC DESTDIR=/pxe buildkernel

Which by the way I want to say to whoever cares, I think is exceedingly cool 
to be able to build a target system from a host systems source tree by doing 
just that.
Note /pxe is a fs mount point for the sake of the nfs share, and since I 
didn't want to carve up my disk or be locked into any particular size, it's 
a file backed ramdisk.


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

Well, since the telepathy driver is still in negative zeta, and no other rf 
wireless keybord with built in touch-pad exists that I've found, barring one 
other unit that's over $200, (the Sony is already $150)
And since it's just a thin client (or fat, I don't care which), it doesn't 
much matter what runs on it. The real machine with the raid array and the 
cpu horsepower and which is hosting the nfs shared unpacked copy of knoppix, 
and dhcp & tftp is freebsd. Not that I'm overly religeous about it. Right 
next to it on the same rack in my cellar, both performing necessary tasks, 
are a SuSE 10 box and a SCO Open Server 5.0.6 (sometimes 5.0.7) box.

Really, rather than being a crummy reason to run Linux, it's the other way 
around. I actually don't have a defensible reason I can think of to bother 
with the necessary effort to get freebsd working on the thin client as long 
as anything at all works that has the necessary client software 
(rdesktop/vnc/web browser/ssh/telnet/NX/etc... Even if the only thing that 
worked were win-ce.

But I'm not too snooty to admit that I simply want to run freebsd on it 
because I just want to. :)
Because it's "cool" and so that I can say that I am running freebsd as part 
of my entertainment system without making my living room look like a server 
closet.
Rather, having more functionality (via using any*ix) and at the very same 
time having to put up with actually less computer station ugliness than most 
people, who have a ordinary windows pc and all the typical parephenalia 
somewhere in their living space. Cake, and eating it too.

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

At the moment, ums is built-in, and psm is commented out.

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


The following were all run on the thin client, using the kernel and world 
built from this config file:
http://keyofr.homeunix.net:81/netgear_hub_thin_client/HUBPC

root_at_ngh# dmesg >20060106_dmesg.txt
http://keyofr.homeunix.net:81/netgear_hub_thin_client/20060106_dmesg.txt

- removed and reinserted the receiver -

root_at_ngh# tail -10 /var/log/messages >20060106_ukbd_insert.txt
http://keyofr.homeunix.net:81/netgear_hub_thin_client/20060106_ukbd_insert.txt
Note: there is a 3rd device not showing here, that is part of the kit, but 
which I am not using, which is the seperate wireless mouse. It uses the same 
reciever as the keyboard and touch pad.
There is also a "sleep" button on the keyboard that doesn't generate a 
scancode (even on Linux where the touch pad mouse works fully) so that may 
be yet another device all it's own. (It is used to put windows to 
sleep/hibernate/death so it's not something purely local to the device like 
the on/off switch on the side of the keyboard.
There are also a few multimedia buttons implimented as hardware hot keys 
("Fn" + F2/F3/F4), but they already generate scancodes and so they are 
obviously part of ukbd.

> - Run the following commands, as root:
>
> # usbdevs -v
root_at_ngh# usbdevs -v >20060106_usbdevs.txt
http://keyofr.homeunix.net:81/netgear_hub_thin_client/20060106_usbdevs.txt

> # usbhidctl -f /dev/uhid0 -r
root_at_ngh# usbhidctl -f /dev/uhid0 -r >20060106_usbhidctl_uhid0.txt
http://keyofr.homeunix.net:81/netgear_hub_thin_client/20060106_usbhidctl_uhid0.txt


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

It's way cool daddy-o.
Short answer: stripped down freebsd 5.4-release that:
* runs entirely within a small ramdisk
* boots the kernel & loads modules via tftp
* gets the ramdisk via tftp
* gets key per-client configuration via dhcp
* includes an rdp client and x server ready to go out of the box
* is installed by merely placing the premade compressed fs image, and 
unpacking a premade tar of the /boot tree, in /tftpboot
* is configured by merely adding a few lines to dhcpd.conf

Though as it happens I'm currently more interested in a full nfs boot, nfs 
root, and so that's what I'm doing now.
But this is primarily just to make it easier to work out problems like this 
keyboard and do other customizations like add a ups monitor, print server, 
audio server, wired remote controls for all the entertainment components, 
other clients besides rdp & x, like vnc, nx, ssh, cu, kermit, etc...
Ultimately after arriving at a working customized system, I may then try to 
make a customized thinbsd out of it and go back to the simpler scheme of 
only needing tftp & dhcp.

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

Done. Thanks much.

Brian K. White  --  brian_at_aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!