Bug 177292 - Microsoft Wireless Mouse doesn't work
Summary: Microsoft Wireless Mouse doesn't work
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-01-09 05:23 UTC by Joseph A. Farmer
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2006-01-12 06:15:00 UTC

Attachments (Terms of Use)
dmesg (13.33 KB, text/plain)
2006-01-09 23:38 UTC, Joseph A. Farmer
no flags Details
/var/log/messages (965 bytes, text/plain)
2006-01-09 23:39 UTC, Joseph A. Farmer
no flags Details
cat /sys/kernel/debug/usbmon/4t > /tmp/bus4.mon output (3.08 KB, text/plain)
2006-01-10 02:04 UTC, Joseph A. Farmer
no flags Details
Output of debug with both mice plugged in, neither work. (6.34 KB, text/plain)
2006-01-10 04:17 UTC, Joseph A. Farmer
no flags Details
Modules.txt (1.92 KB, text/plain)
2006-01-11 03:08 UTC, Joseph A. Farmer
no flags Details
lsusb output (135 bytes, text/plain)
2006-01-11 03:09 UTC, Joseph A. Farmer
no flags Details
dmest (7.59 KB, text/plain)
2006-01-11 03:10 UTC, Joseph A. Farmer
no flags Details
messages with new kernel (79.48 KB, text/plain)
2006-01-11 03:12 UTC, Joseph A. Farmer
no flags Details
modified hid-core.c (3.85 KB, text/plain)
2006-01-11 05:55 UTC, Joseph A. Farmer
no flags Details

Description Joseph A. Farmer 2006-01-09 05:23:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
This problem has existed in FC2/3/4 and test 5.  I have two Microsoft mice and 3 computers (one an AMD) and the problems exists on all combinations.  The mouse is a Microsoft Optical Blue mouse.  It's USB.  When I plug it in the kernel is aware of the mouse:

Bus 003 Device 002: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical

Jan  8 22:57:44 patton kernel: usb 4-2: new low speed USB device using uhci_hcd and address 11
Jan  8 22:57:44 patton kernel: input: USB HID v1.11 Mouse [Microsoft Microsoft Wireless Optical Mouse\uffff 1.0A] on usb-0000:00:1d.3-2
Jan  8 22:57:44 patton hal.hotplug[6991]: DEVPATH is not set (subsystem input)

udevinfo -p /class/input/mouse1 -a:
device '/sys/class/input/mouse1' has major:minor 13:33
  looking at class device '/sys/class/input/mouse1':

follow the "device"-link to the physical device:
  looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.3/usb4/4-2/4-2:1.0':
    SYSFS{bAlternateSetting}==" 0"

  looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.3/usb4/4-2':
    SYSFS{bMaxPower}==" 50mA"
    SYSFS{bNumInterfaces}==" 1"
    SYSFS{version}==" 2.00"

So it sees the mouse.  
cat /dev/input/mouse1 doesn't show any data.  I have another (corded) mouse on /dev/input/mouse0 and doing a cat on that generates data. 

If I remove the corded mouse I just don't get one at all.  I put just the usb wireless on another machine and booted FC5-test1 and the result is the same - no mouse.  This mouse worked in FC1 on two computers so it's something with udev.

The next step is to "disable HID" whatever that means.  A number of people that run various BSDs found that to work.  I have no idea what that means.  lsmod shows no hid.

The rest of that udevinfo command is:
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.3/usb4':
    SYSFS{bMaxPower}=="  0mA"
    SYSFS{bNumInterfaces}==" 1"
    SYSFS{manufacturer}=="Linux 2.6.14-1.1656_FC4 uhci_hcd"
    SYSFS{product}=="UHCI Host Controller"
    SYSFS{version}==" 1.10"

  looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.3':

couldn't open device directory

I found that interesting as lsmod shows:
usblp                  13633  0
ipv6                  249889  17
uhci_hcd               32465  0
ehci_hcd               34381  0

So nothing is using uhci_hcd even though the printer, mouse, and scanner are on it?

In FC1 I seem to remember a hid module and a mouse one.  Now there are neither.

I'm at a loss at this point.

The last thing I tried was making a rule in udev/rules.d with:
[root@patton rules.d]# cat 20-msmouse.rules
# udev rule to create /dev/input/wacomN for wacom tablets

KERNEL="event*", SYSFS{manufacturer}="Microsoft", SYSFS{idProduct}="006a" NAME="input/%k", SYMLINK="input/mymouse"

Sure enough plugging the mouse in creates a mouse1 or mouse2 depending on the timing.  It also creates mymouse which is a symlink to event2.  Cat of mymouse or event2 or mouse1 results in nothing.

I wish I knew what the next step was.  I generally can figure this stuff out but this has me stumped.


Version-Release number of selected component (if applicable):
all kernels

How reproducible:

Steps to Reproduce:
1. Plug in one of these two Microsoft Wireless Blue Mice
2. Boot Fedora Core 2-5
3. No mouse.  

Actual Results:  Mouse pointer in middle of screen and no way to move it.

Expected Results:  Mouse should work.  cat of /dev/input/mice should generate garbage on the screen.

Additional info:

Put new batteries in, no dice.  2 of these mice, neither work.  3 computers, no change.  I just use corded ones instead but it's kind of annoying to have these and they don't work at all.

Comment 1 Pete Zaitcev 2006-01-09 06:10:44 UTC
There's very little I can do if this is not a regression or something
simple like enumeration. Usually such things mean that something
is seriously wrong with reports and descriptors the device sends.

Comment 2 Joseph A. Farmer 2006-01-09 18:05:43 UTC
Thanks for looking Pete.  Since this is a kernel bug near as I can figure should
I just close this and see if I can open one on a Linux USB forum or against UDev
in the kernel's bugzilla?

Don't get me wrong, I love udev.  I lost a mouse but gained easy access to my
printer and scanner.  Much easier than the old system.

Comment 3 Pete Zaitcev 2006-01-09 18:35:09 UTC
Please give me the complete dmesg (taken after the mouse plug) and I'll
forward it to Dmitry. Attach it to the bug, do not drop into the comments box.
He is likely to need some report and descriptor dumps, we'll take it from there.

Comment 4 Joseph A. Farmer 2006-01-09 23:38:58 UTC
Created attachment 122974 [details]

USB events aren't logged to dmesg but startup shows the mice.

Comment 5 Joseph A. Farmer 2006-01-09 23:39:55 UTC
Created attachment 122975 [details]

Shows disconnect and connect.

Comment 6 Pete Zaitcev 2006-01-10 00:21:43 UTC
Excellent, thanks a lot. May I trouble you with getting a usbmon trace?
I'd like to know what the HID layer is doing to the device.
It's done like this:

mount -t debugfs none /sys/kernel/debug
cat /sys/kernel/debug/usbmon/4t > /tmp/bus4.mon
-- plug in the optical mouse, use the same port as for dmesg
   or the bus number will be different
-- wait a second or two
-- Click a button

Thanks. This should tell me if HID actually submits the URB to the device,
and if it does, what it receives.

Comment 7 Joseph A. Farmer 2006-01-10 02:04:25 UTC
Created attachment 122980 [details]
cat /sys/kernel/debug/usbmon/4t > /tmp/bus4.mon output

Was at work so I had to wait until I got home to add the files.

Comment 8 Pete Zaitcev 2006-01-10 02:16:31 UTC
One very last question. Does the mouse work in Windows?

The usbmon trace does not show anything unusual, but then the device simply
does not submit any reports at all (you did click that button, didn't you).

Comment 9 Joseph A. Farmer 2006-01-10 03:04:53 UTC
Does it work in Windows?  That got quite a chuckle.  Short answer is I don't know.

Long answer is, a number of years ago, I had a 486.  Bought a CD burner (SCSI
tray single speed).  Kept screwing up discs with Windows.  Loaded Redhat 6.1? 
Whatever it was it was current before the test version that introduced
internationalization with redneck.  Burner worked, no more underruns.  There are
6 computers in this house.  None of them have Windows.  It's not a religious
thing, we just don't have any use for Windows.  We use Firefox, Gaim, Gramps,
OO, etc.  Games are played on Playstations and Gamecubes.  Kids grew up with
Linux and don't really understand Windows.  Wife uses Windows at work and just
doesn't like the lockups and noise.

So, I don't know.  I suppose I could bring it to work and find a laptop.  I do
know they worked fine on kernel 2.4.  I upgraded to 2.6RC whatever and was able
to get it working.  Greg KH made some changes (the UDev thing) and it got
problematical.  Insmod was able to get it working on 2.6.0.  The first
production release after that and it quit working.  When I say "it" I mean them.
 Two of them.  Dell SC400, Dell Dimension 3000, Empac SoundBlaster PC (old) all
refuse to give mouse data.  The Empac and a whitebox AMD (around here somewhere)
 had 2.4 on them with these mice.  Worked fine.  It was the new 2.6 USB stuff
that made them stop.

Sorry for the book.  These mice are kind of useless in their current state. 
They've been sitting around as I just plugged in corded ones to get mice
working.  If this can't be fixed you can drop me an address and I'll mail one to
you.  At the very least you'll have an addition to the freaky hardware
collection.  At best you'll find a fix and we'll both own 1 functional MS
Wireless Blue.


Comment 10 Joseph A. Farmer 2006-01-10 04:16:31 UTC
ok, I booted FC2 and no mouse.  Fedora Core test (pre-1) also as that had the
2.4 kernel and I didn't get a mouse.  I used to have to do something with ohci
to get it to work on that machine though.  I've dealt with user support and
sometimes it's easier to eliminate problems, what's left is right.  So I plugged
both of them in:

Jan  9 22:03:14 patton kernel: usb 4-2: new low speed USB device using uhci_hcd
and address 3
Jan  9 22:03:15 patton kernel: input: USB HID v1.11 Mouse [Microsoft Microsoft
Wireless Optical Mouse\uffff 1.0A] on usb-0000:00:1d.3-2
Jan  9 22:03:15 patton hal.hotplug[3511]: DEVPATH is not set (subsystem input)
Jan  9 22:03:45 patton kernel: usb 4-1: new low speed USB device using uhci_hcd
and address 4
Jan  9 22:03:45 patton kernel: input: USB HID v1.11 Mouse [Microsoft Microsoft
Wireless Optical Mouse\uffff 1.0A] on usb-0000:00:1d.3-1
Jan  9 22:03:45 patton hal.hotplug[3558]: DEVPATH is not set (subsystem input)

So now two wireless blues are plugged in.

Bus 004 Device 004: ID 045e:006a Microsoft Corp.
Bus 004 Device 003: ID 045e:006a Microsoft Corp.
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 002: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 002: ID 05d8:4003 Ultima Electronics Corp. Artec E+ 48U
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 002: ID 04e8:3252 Samsung Electronics Co., Ltd
Bus 001 Device 001: ID 0000:0000

Bus 4, devices 3 and 4 are wireless blue.

Attached is busmon4-1 which is the debug output plugging in the first, moving
both mice, plugging in the second, and moving them both.  So there should be
input from two.

Comment 11 Joseph A. Farmer 2006-01-10 04:17:54 UTC
Created attachment 122986 [details]
Output of debug with both mice plugged in, neither work.

Both plugged in.

Comment 12 Vojtech Pavlik 2006-01-10 13:10:29 UTC
One thing to try is to add HID_QUIRK_NOGET into hid-core.c for this mouse,
it's possible that the mouse gets upset when we try to read its initial button
state. Quite a number of devices have bugs like this in their HID implementation.

Another thing is: Did these two mice ever work anywhere else? You seem to mention
FC1 as functional ... I just want to check that the mice are properly paired to
their base stations - removing the batteries often resets that - if they weren't,
you'd see exactly the symptoms described above - mouse found, but no motion data.

Comment 13 Joseph A. Farmer 2006-01-11 03:06:58 UTC
Yes, they worked in Redhat 9 and FC1.  When Arjan created the 2.6.0 test kernel
I was able to get it working under that too but it took a series of modprobes in
a rc.mouse script.  FC2 killed them.  They were on two different machines when
FC1 was out and worked on both.  They both died with FC2.

I'm on a different machine.  This is the one that was working with Arjan's
2.6pre kernel.  I recompiled the kernel with most of the USB stuff as modules. 
Attached is the dmesg, messages, lsusb, and lsmod output.  This machine
currently has a corded mouse working and one of the cordless not working.  I'll
see of I can poke into hid-core.c after this.  This machine is very slow (4 hour
kernel compile) so it will be tomorrow before I see the results.  I'm also
taking the mice into work and seeing if XP can deal with them.

Comment 14 Joseph A. Farmer 2006-01-11 03:08:31 UTC
Created attachment 123029 [details]

The ohci and uhci were modprobed just in case.	Mouse doesn't work with or
without them.

Comment 15 Joseph A. Farmer 2006-01-11 03:09:24 UTC
Created attachment 123030 [details]
lsusb output

one cordless and one corded.  corded working to use the desktop.

Comment 16 Joseph A. Farmer 2006-01-11 03:10:24 UTC
Created attachment 123031 [details]

dmesg from this kernel.  It's running and everything but I might have not done
the compile correctly.

Comment 17 Joseph A. Farmer 2006-01-11 03:12:04 UTC
Created attachment 123032 [details]
messages with new kernel

messages from this compiled kernel.  Should we drop some of the cc's from this
bug?  I'm kind of noisy.  I'll see if I can poke that mouse c file and
recompile again.

Comment 18 Joseph A. Farmer 2006-01-11 05:55:59 UTC
Created attachment 123035 [details]
modified hid-core.c 

I made the changes to hid-core.c and recompiled.  Did fix it.  hid-core.c
attached to see if I did it right.

[root@pershing input]# uname -a
Linux pershing.happykilroy.com 2.6.14-jaf_usb_noget #2 Tue Jan 10 23:10:17 CST
2006 i686 i686 i386 GNU/Linux

dmesg on boot:
USB Universal Host Controller Interface driver v2.3
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:07.2: irq 10, io base 0x0000e000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usb 1-1: new low speed USB device using uhci_hcd and address 2
hub 1-0:1.0: over-current change on port 2
input: Microsoft Microsoft Wireless Optical Mouse\uffff 1.0A on
usbcore: registered new driver usbmouse
drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver

Jan 10 23:36:10 pershing gpm[1955]: Started gpm successfully. Entered daemon
Jan 10 23:36:10 pershing gpm[1955]: *** info [mice.c(1766)]:
Jan 10 23:36:10 pershing gpm[1955]: imps2: Auto-detected intellimouse PS/2
Jan 10 23:36:16 pershing fstab-sync[2044]: removed all generated mount points
Jan 10 23:36:18 pershing fstab-sync[2051]: added mount point /media/floppy for
Jan 10 23:36:18 pershing fstab-sync[2054]: added mount point /media/cdrecorder
for /dev/hdd
Jan 10 23:36:32 pershing login(pam_unix)[2070]: session opened for user root by
Jan 10 23:36:33 pershing  -- root[2070]: ROOT LOGIN ON tty2
Jan 10 23:38:02 pershing kernel: usb 1-1: USB disconnect, address 2
Jan 10 23:38:02 pershing hal.hotplug[2409]: DEVPATH is not set (subsystem
input)Jan 10 23:38:07 pershing kernel: usb 1-1: new low speed USB device using
uhci_hcd and address 3
Jan 10 23:38:07 pershing kernel: input: Microsoft Microsoft Wireless Optical
Mouse\uffff 1.0A on usb-0000:00:07.2-1
Jan 10 23:38:07 pershing hal.hotplug[2437]: DEVPATH is not set (subsystem
input)Jan 10 23:38:23 pershing gpm[1955]: *** info [mice.c(1766)]:
Jan 10 23:38:23 pershing gpm[1955]: imps2: Auto-detected intellimouse PS/2
Jan 10 23:38:59 pershing kernel: usb 1-1: USB disconnect, address 3
Jan 10 23:38:59 pershing hal.hotplug[2508]: DEVPATH is not set (subsystem
input)Jan 10 23:39:03 pershing kernel: usb 1-1: new low speed USB device using
uhci_hcd and address 4
Jan 10 23:39:03 pershing kernel: input: Microsoft Microsoft Wireless Optical
Mouse\uffff 1.0A on usb-0000:00:07.2-1
Jan 10 23:39:03 pershing hal.hotplug[2532]: DEVPATH is not set (subsystem
input)Jan 10 23:39:25 pershing ntpd[1871]: synchronized to LOCAL(0), stratum 10

Jan 10 23:39:25 pershing ntpd[1871]: kernel time sync disabled 0041

I had to disconnect it and connect the corded usb one.	Then I had a mouse.

Last thing I know to try is XP with them tomorrow.  Until then.

Comment 19 Joseph A. Farmer 2006-01-11 05:58:03 UTC
Make that "didn't fix it".  Typo, sorry.

Comment 20 Pete Zaitcev 2006-01-11 21:53:13 UTC
We can be reasonably sure that noget didn't work. A usbmon trace would confirm
if it was actually in effect.

I remember getting into trouble with old devices because of the SET-IDLE,
but it sort of faded, and I do not remember details. This is what the
defice refuses with a STALL condition:

e77ee580 1452683908 S Co:016:00 s 21 0a 0000 0000 0000 0
e77ee580 1452688797 C Co:016:00 -32 0

We used to do SET_IDLE for all interfaces, but now we only do it once.
Maybe that's the reason.

I am inclined to think that something is wrong with the IR part. Since neither
works when both are plugged in (comment #10), this is not because the tails
were swapped. But it can be something else.

Getting these working on _anything_ (an ancient Windows borrowed from a friend,
for example), would do a lot of good in dispelling the faulty hardware theory.

Comment 21 Joseph A. Farmer 2006-01-12 05:14:08 UTC
Ok, i dug a hole in the backyard and poured a concrete bunker because you are
all going to kill me when you find this out.

I took the mice to work.  Plugged the first one into an XP box.  It didn't work.
 Went through the whole "trouble shoot the problem" thing and nada.  5
technology professionals standing around playing with the mice.  Finally worker
number 3 figures out there is a black pin on the bottom of the mouse.  Pushed
the button on the receiver and the pin on the mouse and the mouse started
working.  Tried the other one.  Same thing.

In fairness to me, outside of this being rather boneheaded, the mice did work
before early 2.6 and then stopped on both computers after an upgrade to FC2.  I
had never pushed that pin on either of them.  Didn't even know it was there. 
They are working on FC4 now. 

I feel pretty stupid.  I tried Vojtech take the batteries out and reinsert a
number of times and didn't see that pin.

2 kernel compiles for nothing.

jfarmer quietly shuffling off and hiding.

I guess this was a big waste of time for you and I apoligize.

The bug can be closed.  

Comment 22 Pete Zaitcev 2006-01-12 06:15:00 UTC
Heh, I should've asked for it to play after comment #9 :-)
But it's all to the better.

Next time, do not truncate source code, because I use diff -u to see the
changes. Guess what happens when one of them is corrupt with best intentions...

Note You need to log in before you can comment on or make changes to this bug.