Re: Microsoft Wireless Laser Mouse 6000 v2.0 vs. NetBSD

[Rafal Boni <rafal%pobox.com@localhost>]

On Wed, Jul 15, 2009 at 07:44:41PM +0100, Iain Hibbert wrote:
> On Wed, 15 Jul 2009, Rafal Boni wrote:
> 
> (I cut out port-i386 since its not in any way i386 specific)

Thanks, vestige of my original post, I just blindly replied-all to it.

> 
> > It looks like this mouse has several issues with our USB stack:
> >
> >     * We either mis-calculate the report size of the report descriptor
> >       used by the mouse to signal events, or the report size is mis-
> >       reported by the device,
> 
> can you check with "usbctl" and "usbhidctl" to see if they give any
> more useful information?

Unfortunately, I couldn't find anything useful or at least anything that
didn't agree with the uhid(4)/uhidev(4) drivers' view of things.  But I
couldn't find anything showing the locations for the individual report
items.  

Pointers to clues that don't require adding USB_DEBUG to your kernel are
appreciated, if anyone has them.  If not, I'll try and dig into this a
bit more at some point.

> >     * The wheel has a 'tilt' axis, but this is reported as an unusual
> >       HID type (Consumer:AC Pan), so it isn't used.
> 
> I believe that AC PAN is the correct usage for this, the apple mighty
> mouse uses it and I fixed up btms(4) some time ago to use it..

Ah, ok, in that case I should probably make the quirk handling in ums.c
somewhat smarter so it doesn't try and mangle all AC PAN elements (and
Z axes on all AC PAN equipped devices).

> I don't think you should rename all the variables w->t ..

Yeah, that's easy to undo; I was looking at FreeBSD's driver while I was
trying to grok what was going on and stole the 'T' from there, and then
of course had to rename it all for consistency... but I'm not attached to
that letter any more than to 'w' ;)

> > Attached is a patch that makes my mouse works, though I'm not 100% sure
> > if the handling of the report isize / interrupt pipe packet size is the
> > right way to solve that problem (if it got the report isize correct, the
> > rest would simply fall out, but that's harder to make a quirk for).
> 
> I don't see any reason why we shouldn't just use the wMaxPacketSize to
> allocate the buffer, unless whomever wrote it was afraid of broken devices
> claiming to need 0xffff sized buffers..?

Yeah, that might be somewhat more forgiving; we can probably add a special
case to refuse devices that request 0xffff sized buffers.

Thanks for the feedback,
--rafal

-- 
  Time is an illusion; lunchtime, doubly so.     |/\/\|           Rafal Boni
                   -- Ford Prefect               |\/\/|      
rafal%pobox.com@localhost