Date: Mon, 25 Feb 2008 10:09:56 -0800 From: "Duane H. Hesser" <duane.hesser@gmail.com> To: freebsd-usb@freebsd.org Subject: Re: usb/121052: Microsoft Notebook Optical Mouse 3000 (model 1049) doesn't work Message-ID: <200802251809.m1PI9u4e001934@belinda.androcles.org> In-Reply-To: <20080225165628.GA56247@plan0.kaiwan.csbnet.se> References: <200802242330.m1ONU4H3074911@freefall.freebsd.org> <20080225022450.GA40942@plan0.kaiwan.csbnet.se> <20080225075647.854d071f.dhesser@accima.com> <20080225165628.GA56247@plan0.kaiwan.csbnet.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Feb 2008 17:56:28 +0100
Kai Wang <kaiwang27@gmail.com> wrote:
> >
> > The ms3000 provides multiple input reports, and thus prepends and "ID"
> > byte to each report, so the button bits will start at 8, and the x.pos
> > will be at 16.
>
> You are right. But it does not count that ID byte when you set
> sc->sc_iid to a non-zero value.
>
> excerpt from ums_intr():
>
> } else {
> if (sc->sc_iid) {
> if (*ibuf++ != sc->sc_iid)
> return;
> }
> }
>
> Note that "*ibuf++"
>
> --
> Kai
>
Ahh, right. I revised that section of code weeks ago, so I was
unaware of the increment. The UMS_T branch which survives in the
current ums.c is quite spurious, since there are other mice besides
the Intellimouse which report on the Twheel usage (including the
Microsoft 3000). I would like to see the input reports on the
Intellimouse...the branch is unnecessary (in my revised driver)
unless the Intellimouse does something truly strange.
I think...
----------
Duane Hesser
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802251809.m1PI9u4e001934>