On Wed, Mar 27, 2002 at 01:14:45PM +0100, Eduard Bloch wrote:
> #include <hallo.h>
> Brad Hards wrote on Wed Mar 27, 2002 um 09:39:15AM:
> 
> > > working while the hardware initialisation at boot time. BUT: If an
> > > additional "normal" keyboard is connected, Linux does not have any
> > > problem, I can use both keyboards, remove the old keyboard and continue
> > > working with USB keyboard.
> > It sounds like you have some combination of a BIOS problem, and mismatched 
> > drivers.
> 
> That is the point, I would like to keep keyboard support without
> additional drivers. Background: I am working on Debian's boot-floppies,
> and the keyboard should work when you change the (first!) installation
> disk at boot time. At this point, there is no chance to load modules.

If you want the BIOS legacy keyboard emulation to keep working after you
load USB modules in Linux, that's simply impossible. Once the OS drivers
take over the USB controller, no more legacy emulation can be done by
the BIOS.

Once you load the USB drivers, you also have to load the USB keyboard
driver (hid.o, or if space is a problem then usbkbd.o), and the input
driver (keybdev.o).

> Oh, trying to build input drivers into the kernel, I ran into another
> problem - the drivers have been loaded, the keyboard has been
> found, but if keeped beeing non-functional. Only forced load of
> "keybdev" module (note that the driver has also been compiled into the
> kernel!) woke it up.

That's weird. It works for everyone else OK.

> It is exactly how I wrote. I load usbkbd, the keyboard does not work. I
> load keybdev afterwards, and is iseable. I know, this is confusing, even
> for me, but some kind of breakage _is_ there.
> 
> Summary with 2.4.18 kernel:
> 
> usbkbd + keybdev -> working
> hid + keybdev -> working
> keybdev only -> non-functional
> usbkbd only ->  non-functional

That's normal, this is how it is supposed to work.

> Oh, and if I compile usb-uhci+hid+input+keybdev into the kernel, it
> spews with timeout errors at boot time and the keyboard does not work.
> See attachment.

This is a bug, yes.

> > If you don't (or won't) use the "full HID" support, don't load keybdev.o
> 
> That is the point - usbkbd does NOT work without keybdev.

It isn't bound to the console. That's intentional.

> Another thing I noted while experimenting with USB is this
> unreproducible Oops that happened sometimes when removing the modules:
> 
> 
> Unable to handle kernel paging request at virtual address d8917280
>  printing eip:
> d8917280
> *pde = 0176c067
> *pte = 00000000
> Oops: 0000
> CPU:    0
> EIP:    0010:[<d8917280>]    Tainted: PF
> EFLAGS: 00010282
> eax: d8917280   ebx: d6a02000   ecx: d6bf3000   edx: c160fc28
> esi: d60193f8   edi: d6bf3180   ebp: c1744b80   esp: c4113f14
> ds: 0018   es: 0018   ss: 0018
> Process rmmod (pid: 4251, stackpage=c4113000)
> Stack: d8904a48 d60193f8 d60193f8 d60193f8 c1744b80 00000000 d8904c21 c1744b80
>        d60193f8 d60193f8 c1744b80 00000001 d8905ef9 d60193f8 d89076c0 d60193f8
>        c1744b80 d89083c0 d8903000 bfffdf0c d8906b7a c1744b80 00000000 00000001
> Call Trace: [<d8904a48>] [<d8904c21>] [<d8905ef9>] [<d89076c0>] [<d89083c0>]
>    [<d8906b7a>] [<c01fcc5f>] [<d890707a>] [<d89083c0>] [<c0117017>] [<c01163a7>]
>    [<c0106c5b>]
> 
> Code:  Bad EIP value.

Care to provide the relevant System.map or run the oops through
ksymoops?

> I get three of this warnings, and from this point a such message all 5
> seconds or so:
> 
> usb-uhci.c: interrupt, status 20, frame# 0
> 
> Another time, I loaded keybdev first, then "hid". I took 20seconds till
> modprobe returned, and I saw a bunch of "ust_control/bulk_msg: timeout"
> messages.
> As far as I can see, there is currently NO WAY to make the keyboard work
> without modules.

Have you tried unplugging and replugging it while the system is running?

> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> usb_control/bulk_msg: timeout
> input1,hiddev0: USB HID v1.00 Pointer [Compaq Compaq] on usb1:2.1
> usb.c: hid driver claimed interface cff42ed8
> usb.c: kusbd: /sbin/hotplug add 2
> hub.c: port 1 connection change
> hub.c: port 1, portstatus 300, change 3, 1.5 Mb/s
> hub.c: port 2 connection change
> hub.c: port 2, portstatus 300, change 3, 1.5 Mb/s
> hub.c: port 1 enable change, status 300
> hub.c: port 1 enable change, status 300
> hub.c: port 2 enable change, status 300

This is a very weird keyboard (if it is a keyboard at all!). It seems
like it doesn't like the get_report request or something like that. 
Can you send me the contents of /proc/bus/usb/devices on your system?

-- 
Vojtech Pavlik
SuSE Labs

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Reply via email to