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>