Red Hat Bugzilla – Bug 52546
mousedev not loaded when USB mouse hotplugged
Last modified: 2007-04-18 12:36:35 EDT
Description of Problem: Mouseconfig is set to USB 3-button mouse. The system is booted without Keyboard or mouse. When a USB mouse and keyboard are plugged in, the mouse does not work. Manually loading mousedev works just fine. Keyboard is a Chicony USB keyboard with a PS/2 mouse port on the keyboard. Mice plugged into PS/2 port on the keyboard are detected as USB Mice. Version-Release number of selected component (if applicable): RC1 How Reproducible: Boot without USB mouse. Plug in USB mouse. Observe that USB mouse does not work. Load mousedev. restart gpm. observe mouse working. Expected Results: mousedev should be loaded when mouse is detected. [root@localhost root]# cat /proc/bus/usb/devices T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc=236/900 us (26%), #Int= 2, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=ef80 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=04f2 ProdID=0112 Rev= 1.03 S: Manufacturer=CHICONY S: Product=USB Keyboard C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 74mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=hid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl= 10ms I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=hid E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl= 10ms
There are a couple of problems in the hotplug area - the hid-module matches everything. Any module after that in the map file won't be tested...
hotplug-2001_04_24-11 should fix this - http://people.redhat.com/teg/hotplug/
Looks good in testing here.
As of 7.2 Gold, this mouse port on this keyboard no longer works _at all_ with version 1.03 of the keyboard chipset. (See the line above P: Vendor=04f2 ProdID=0112 Rev= 1.03) I have another keyboard that is Rev=1.01 that _does_ work. Other points of information: Red Hat 7.1: version 1.03 WORKS Red Hat 7.2 RC1: version 1.03 WORKS Red Hat 7.2 gold: version 1.03 BROKEN Full output of /proc/bus/usb/devices will be attached for both non-working and working keyboards from 7.2 gold.
Created attachment 32378 [details] non-working keyboard /proc/bus/usb/devices from 7.2 gold
Created attachment 32379 [details] /proc/bus/usb/devices from good version of the keyboard on 7.2 gold
Forgot to add this to the previous comment, but I was not sure whether to re-open this bug, or to enter a new bug, as I'm not sure the breakage was due to changes caused by this bugzilla.
More info from Chicony: > Here are the deltas between the keyboard that works with 7.2 > (Rev 1.01) and the one that does not (Rv 1.03). Please forward this to > the concerned people at RedHat for looking into the issue. > The change in the rev 1.01 (old) to 1.03 (new) was essentially > the firmware change. The reason for this change was to fix some issues > with some Microsoft 5-button mice. The deltas between the 2 firmwares > are as follows: > > 1. In the old firmware, the clock keeps low when keyboard > doesn't send > data to mouse in reset mode. The new firmware keeps high in the > same > condition. > 2. The old firmware adds Report ID to data package to send to > system in > report protocol. The new firmware doesn't. > 3. The old firmware sends 4 data byes in boot protocol. The new > firmware > sends 3 bytes in boot protocol. The 4 data bytes is for 3D mouse > protocol. The 3 data bytes is for 2D mouse protocol. Only legacy > mode will > use boot protocol. The others will use report protocol. >
Problem reproduced with enigma-respin binaries and keyboards received from Dell.
I found a workaround: 1. vi /lib/modules/2.4.7-10/modules.usbmap, find the line for usbkbd and delete it. 2. rm /lib/modules/2.4.7-10/kernel/drivers/usb/usbkbd.o
What does this affect if you do this? What things have the possibility of not working? What is the root cause of the problem/Why does this fix the problem?
As I understand it (Pete, please correct me if I screw this up); keybdev is the full HID keyboard driver. usbkbd is HIDBP (HID Boot Protocol, IIRC) driver, which is more minimal. The usbkbd driver (for all I know) may be tripping up on the > 3. The old firmware sends 4 data byes in boot protocol. The new > firmware > sends 3 bytes in boot protocol. The 4 data bytes is for 3D mouse > protocol. The 3 data bytes is for 2D mouse protocol. Only legacy > mode will > use boot protocol. The others will use report protocol. change. In any case, removing the usbkbd module (or the module entry in modules.usbmap that maps that keyboard class to usbkbd) will cause it to load keybdev instead, which should work. However, we cannot map all keyboards unilaterally to keybdev, because we've run into some PS/2->USB converters that don't work with keybdev, for whatever reason.
Small correction about driver hierarchy -- keybdev is "upper half" above Input Framework, it interfaces with common keyboard.c driver in the same way pc_keyb.c does. The "bottom half" that corresponds to usbkbd is called hid. keybdev must always be loaded, regardless what bottom half is active - hid or usbkbd. On the subject of the PS/2 adapter -- I strongly suspect that Erik's PS/2 adapter does in fact talk HID. It is just extremely flakey, so perhaps usbkbd lets it work better, but not because it supports BOOT, but because it submits URBs differently. I have a PS/2 adapter that looks exactly like Erik's and it talks HID. This is only a speculation until someone takes the adapter in question and plugs it into some machine, and a keyboard into the adapter.
I changed 7.2 Enterprise Edition to build without usbkbd.
Uh-oh, see Bug 55878 - usbkbd strikes back.
Data point for the knowledge base - I think perhaps RH 7.1 and 7.2 loaded usbkbd and hid in different order. Date: Thu, 15 Nov 2001 15:30:22 -0600 From: Martin McWhorter <m_mcwhorter@prairiegroup.com> To: Pete Zaitcev <zaitcev@redhat.com>, linux-kernel <linux-kernel@vger.kernel.org> Subject: Re: Possible Bug: 2.4.14 USB Keyboard > "make modules_install", but this time rename hid.o into hid.hidden. > Let me know if this fixes the problem. I went ahead and did this. Booted up and got the expected error message when HID tried to load. Keyboard works but USB mouse ofcourse does not. So I went and renamed hid.hidden to hid.o and loaded it. Now my USB keyboard and USB mouse are working. I suspect it has something to do with the order the modules are loaded? hid.o must be last? I am just guessing. I suppose I can edit the rc.sysinit to load hid AFTER usbkbd is loaded. Martin
Resolved for Dell with removal of usbkbd, tracking the "hid fails, ubkbd works" symptom in other bugs (see comments above for numbers).