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: lsusb: Bus 003 Device 002: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical /var/log/messages: 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': SUBSYSTEM=="input" SYSFS{dev}=="13:33" 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': BUS=="usb" ID=="4-2:1.0" DRIVER=="usbhid" SYSFS{bAlternateSetting}==" 0" SYSFS{bInterfaceClass}=="03" SYSFS{bInterfaceNumber}=="00" SYSFS{bInterfaceProtocol}=="02" SYSFS{bInterfaceSubClass}=="01" SYSFS{bNumEndpoints}=="01" SYSFS{modalias}=="usb:v045Ep006Ad0017dc00dsc00dp00ic03isc01ip02" looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.3/usb4/4-2': BUS=="usb" ID=="4-2" DRIVER=="usb" SYSFS{bConfigurationValue}=="1" SYSFS{bDeviceClass}=="00" SYSFS{bDeviceProtocol}=="00" SYSFS{bDeviceSubClass}=="00" SYSFS{bMaxPacketSize0}=="8" SYSFS{bMaxPower}==" 50mA" SYSFS{bNumConfigurations}=="1" SYSFS{bNumInterfaces}==" 1" SYSFS{bcdDevice}=="0017" SYSFS{bmAttributes}=="a0" SYSFS{configuration}=="" SYSFS{devnum}=="3" SYSFS{idProduct}=="006a" SYSFS{idVendor}=="045e" SYSFS{manufacturer}=="Microsoft" SYSFS{maxchild}=="0" SYSFS{speed}=="1.5" 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': BUS=="usb" ID=="usb4" DRIVER=="usb" SYSFS{bConfigurationValue}=="1" SYSFS{bDeviceClass}=="09" SYSFS{bDeviceProtocol}=="00" SYSFS{bDeviceSubClass}=="00" SYSFS{bMaxPacketSize0}=="8" SYSFS{bMaxPower}==" 0mA" SYSFS{bNumConfigurations}=="1" SYSFS{bNumInterfaces}==" 1" SYSFS{bcdDevice}=="0206" SYSFS{bmAttributes}=="c0" SYSFS{configuration}=="" SYSFS{devnum}=="1" SYSFS{idProduct}=="0000" SYSFS{idVendor}=="0000" SYSFS{manufacturer}=="Linux 2.6.14-1.1656_FC4 uhci_hcd" SYSFS{maxchild}=="2" SYSFS{product}=="UHCI Host Controller" SYSFS{serial}=="0000:00:1d.3" SYSFS{speed}=="12" SYSFS{version}==" 1.10" looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.3': BUS=="pci" ID=="0000:00:1d.3" DRIVER=="uhci_hcd" SYSFS{class}=="0x0c0300" SYSFS{device}=="0x24de" SYSFS{irq}=="11" SYSFS{local_cpus}=="1" SYSFS{modalias}=="pci:v00008086d000024DEsv00001028sd0000019Dbc0Csc03i00" SYSFS{subsystem_device}=="0x019d" SYSFS{subsystem_vendor}=="0x1028" SYSFS{vendor}=="0x8086" 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. Cheers. Version-Release number of selected component (if applicable): all kernels How reproducible: Always 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.
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.
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.
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.
Created attachment 122974 [details] dmesg USB events aren't logged to dmesg but startup shows the mice.
Created attachment 122975 [details] /var/log/messages Shows disconnect and connect.
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: su 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 ^C Thanks. This should tell me if HID actually submits the URB to the device, and if it does, what it receives.
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.
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).
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. Cheers.
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.
Created attachment 122986 [details] Output of debug with both mice plugged in, neither work. Both plugged in.
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.
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.
Created attachment 123029 [details] Modules.txt The ohci and uhci were modprobed just in case. Mouse doesn't work with or without them.
Created attachment 123030 [details] lsusb output one cordless and one corded. corded working to use the desktop.
Created attachment 123031 [details] dmest dmesg from this kernel. It's running and everything but I might have not done the compile correctly.
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.
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 usb-0000:00:07.2-1 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 messages: Jan 10 23:36:10 pershing gpm[1955]: Started gpm successfully. Entered daemon mode. 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 /dev/fd0 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 (uid=0) 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.
Make that "didn't fix it". Typo, sorry.
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.
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.
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...