Bug 52546 - mousedev not loaded when USB mouse hotplugged
Summary: mousedev not loaded when USB mouse hotplugged
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-08-24 21:29 UTC by Michael E Brown
Modified: 2007-04-18 16:36 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-01-28 22:00:03 UTC
Embargoed:


Attachments (Terms of Use)
non-working keyboard /proc/bus/usb/devices from 7.2 gold (902 bytes, text/plain)
2001-09-21 20:22 UTC, Michael E Brown
no flags Details
/proc/bus/usb/devices from good version of the keyboard on 7.2 gold (902 bytes, text/plain)
2001-09-21 20:25 UTC, Michael E Brown
no flags Details

Description Michael E Brown 2001-08-24 21:29:40 UTC
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

Comment 1 Trond Eivind Glomsrxd 2001-08-26 22:09:27 UTC
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...


Comment 2 Trond Eivind Glomsrxd 2001-08-27 16:46:47 UTC
hotplug-2001_04_24-11 should fix this - http://people.redhat.com/teg/hotplug/

Comment 3 Michael E Brown 2001-08-27 18:29:50 UTC
Looks good in testing here.

Comment 4 Michael E Brown 2001-09-21 20:21:54 UTC
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.



Comment 5 Michael E Brown 2001-09-21 20:22:54 UTC
Created attachment 32378 [details]
non-working keyboard /proc/bus/usb/devices from 7.2 gold

Comment 6 Michael E Brown 2001-09-21 20:25:02 UTC
Created attachment 32379 [details]
/proc/bus/usb/devices from good version of the keyboard on 7.2 gold

Comment 7 Michael E Brown 2001-09-21 20:26:27 UTC
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.

Comment 8 Michael E Brown 2001-10-02 20:25:36 UTC
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.
>


Comment 9 Pete Zaitcev 2001-10-08 16:54:47 UTC
Problem reproduced with enigma-respin binaries and keyboards
received from Dell.


Comment 10 Pete Zaitcev 2001-10-09 07:22:50 UTC
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


Comment 11 Michael E Brown 2001-10-09 13:49:37 UTC
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?

Comment 12 Bill Nottingham 2001-10-12 03:45:39 UTC
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.



Comment 13 Pete Zaitcev 2001-10-12 04:03:13 UTC
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.



Comment 14 Pete Zaitcev 2001-10-23 18:30:16 UTC
I changed 7.2 Enterprise Edition to build without usbkbd.


Comment 15 Pete Zaitcev 2001-11-09 05:54:31 UTC
Uh-oh, see Bug 55878 - usbkbd strikes back.


Comment 16 Pete Zaitcev 2001-12-09 01:55:49 UTC
   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>
To: Pete Zaitcev <zaitcev>,
   linux-kernel <linux-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


Comment 17 Pete Zaitcev 2002-02-06 23:00:04 UTC
Resolved for Dell with removal of usbkbd, tracking
the "hid fails, ubkbd works" symptom in other bugs
(see comments above for numbers).



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