Recent USB mouse regression

[Alexey Shuvaev]

On Sat, Nov 08, 2008 at 04:24:22AM +0200, Giorgos Keramidas wrote:
> Building a kernel & userland just before USB2 from svn change 184609
> seems to have fixed this for now.  It seems that even when USB2 is not
> loaded it affects a bit the way ums(4) works.
> 
> What is the best way of troubleshooting this?
> 
I have seen reversed situation when even with usb2_input_ms kld loaded
I am finding ums + usb (old stack) in kldstat after the system goes multiuser.
I would check kldstat after each event (today klds are loaded automatically!)
and try operate in single user mode first.

Could it be that something (moused) is trying to load all klds matching
some symbols (provided interfaces)?

Just my $0.02,
Alexey.

> On Sat, 08 Nov 2008 00:23:53 +0200, Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
> > A recent 8.0-CURRENT installation _without_ USB2 enabled or loaded from
> > `loader.conf' seems to have regressed a bit from a couple of weeks ago.
> >
> > When I attach an old wired mouse I have at home:
> >
> >   ums0: <Genius NetScroll + Mini Traveler, class 0/0, rev 1.10/1.10, addr 2> on uhub4
> >   ums0: 3 buttons and Z dir.
> >
> > and run moused in debugging mode I can see mouse clicks being handled,
> > but mouse movement `dies' after a bit of time.  Pressing one of the
> > mouse buttons generates moused events like:
> >
> >   moused: received char 0x83
> >   moused: received char 0x0
> >   moused: received char 0x0
> >   moused: received char 0x0
> >   moused: received char 0x0
> >   moused: received char 0x0
> >   moused: received char 0x0
> >   moused: received char 0x7f
> >   moused: assembled full packet (len 8) 83,0,0,0,0,0,0,7f
> >   moused: ts:  3708 752982137
> >   moused:   :  3649 133538726
> >   moused: flags:00000001 buttons:00000001 obuttons:00000000
> >   moused: activity : buttons 0x00000001  dx 0  dy 0  dz 0
> >   moused: mstate[0]->count:1
> >   moused: button 1  count 1
> >   moused: received char 0x87
> >   moused: received char 0x0
> >   moused: received char 0x0
> >   moused: received char 0x0
> >   moused: received char 0x0
> >   moused: received char 0x0
> >   moused: received char 0x0
> >   moused: received char 0x7f
> >   moused: assembled full packet (len 8) 87,0,0,0,0,0,0,7f
> >   moused: ts:  3708 859980149
> >   moused: flags:00000001 buttons:00000000 obuttons:00000001
> >   moused: activity : buttons 0x00000000  dx 0  dy 0  dz 0
> >   moused: mstate[0]->count:1
> >   moused: button 1  count 0
> >
> > but moving the mouse doesn't show anything in the log of moused, as if
> > the movement event were never delivered by the USB stack to `/dev/ums0'.
> >
> > Some times moused starts receiving movement events for 1-2 seconds and
> > then they are gone again.
> >
> > One of the ways I can reliably get the mouse in a `dead' state is by
> > typing in an xterm window.  When xterm hides the mouse pointer of X11,
> > mouse movement is gone for good.
> >
> > A second mouse -- a wireless Microsoft mouse -- attaches as ums0 but
> > never delivers anything to moused:
> >
> >   root: Unknown USB device: vendor 0x045e product 0x00e1 bus uhub4
> >   kernel: ums0: <Microsoft Microsoft Wireless Optical Mouse 1.00, class 0/0, rev 2.00/0.07, addr 2> on uhub4
> >   kernel: ums0: 5 buttons and Z dir.
> >
> > Both of these used to work a couple of weeks ago, and I'm looking back
> > through history to find out when this started.
> >
> > Is anyone else seeing something like this?
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"