Date: Sun, 20 Mar 2005 13:39:59 -0500 From: Anish Mistry <mistry.7@osu.edu> To: freebsd-stable@freebsd.org Cc: Marius =?iso-8859-1?q?N=FCnnerich?= <marius.nuennerich@gmx.net> Subject: Re: USB Mouse not working Message-ID: <200503201340.07373.mistry.7@osu.edu> In-Reply-To: <20050320154644.15099866@olaf.hackerzberg.dyndns.org> References: <20050320154644.15099866@olaf.hackerzberg.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2879214.5tcGIXf7oX
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Sunday 20 March 2005 09:46 am, Marius N=FCnnerich wrote:
> Hi,
>
> I recently purchased a cheap USB mouse/keyboard combination. If I
> plug it in /dev/ums0 is created, I also can run moused -p
> /dev/ums0, but the mouse will not move.
>
> I upgraded to a recent -STABLE, so ums.c is version 1.70.2.2.
> I compiled a kernel with options USB_DEBUG and set
> hw.usb.ums.debug=3D9999.
> With cat /dev/ums0 > /dev/null I can see the Debug Info on the
> console: ums_intr: sc=3D0x19d5c00 status=3D13
> ums_intr: data =3D 01 00 00 00 00 01
> ums_intr: status=3D13
>
> It seems that this mouse sends 1 extra byte before the usual data,
> just like the MS Wireless Intellimouse 2.0, because data is like:
> 01 BUTTON X Y Z 01
>
> But seems like ums_intr() returns on line 467, so I tried this:
> --- /sys/dev/usb/ums.c Sun Mar 20 14:54:14 2005
> +++ /root/ums.c Sun Mar 20 14:54:04 2005
> @@ -456,7 +456,7 @@
> * Currently it's the only user of UMS_T so use it as an
> identifier. * We probably should switch to some more official
> quirk. */
> - if (sc->flags & UMS_T) {
> +/* if (sc->flags & UMS_T) {
> if (sc->sc_iid) {
> if (*ibuf++ =3D=3D 0x02)
> return;
> @@ -468,9 +468,11 @@
> }
> }
>
> +*/ *ibuf++;
>
>
>
> It sort of works. If I run moused -p /dev/ums0 I can actually use
> that mouse, BUT it moves jerky, I have to move the wheel two
> positions to get one and when a button is pressed when the mouse
> stands still it is not recognized. The mouse _must_ move for the
> button to get noticed.
>
> Has anyone an idea what to try next?
> Any help would be greatly appreciated!
>
Is the code setting the UMS_T flags? If not, then force it in after=20
the detection routine section:
/* The Microsoft Wireless Intellimouse 2.0 reports it's wheel
* using 0x0048 (i've called it HUG_TWHEEL) and seems to expect
* you to know that the byte after the wheel is the tilt axis.
* There are no other HID axis descriptors other than X,Y and=20
* TWHEEL */
if (hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP,=20
HUG_TWHEEL),
hid_input, &sc->sc_loc_t, &flags)) {
sc->sc_loc_t.pos =3D sc->sc_loc_t.pos + 8;
sc->flags |=3D UMS_T;
}
sc->flags |=3D UMS_T; /* <--- Add this to force MS Intellimouse Mode */
If that make is work we'll have to figure out a way to auto detect=20
this since it uses the same byte order, but doesn't have the tilt=20
wheel to facilitate detection.
=2D-=20
Anish Mistry
--nextPart2879214.5tcGIXf7oX
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQBCPcOHxqA5ziudZT0RAvVtAJ0T0qLjrj19Fd8RQsppuU1tqqMsGwCZAX5E
nxJwgbinFBrPy4SCdsKNyas=
=rrR0
-----END PGP SIGNATURE-----
--nextPart2879214.5tcGIXf7oX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503201340.07373.mistry.7>