USB Keyboard errors with 2.4.5-ac

I encountered a rather weird problem last night. I was testing out a USB Type 6 Unix layout keyboard from Sun Microsystems and a USB Crossbow model mouse from Sun as well. I like the Sun keyboard and mice and am used to the layout from using it so often at work. I originally thought that it would be no big deal since they both work perfectly in Windows (tested while at work on my Windows 2000 box). When I got them home and tried them out I noticed one thing immediately that I could easily get the mouse to work with GPM and also I could unplug it and plug it back in with no problem as all. The keyboard was a different story, if I plug the keyboard in during operation everything freaks out and I have to reboot the machine to get it to work properly. I also noticed that X would not work properly if I had either the USB keyboard and a PS/2 keyboard plugged in or if I had the USB keyboard plugged in alone. No matter what I tried I could not get X to work, but while trying I noticed my real problem with the keyboard. The kernel apparently expects a PS/2 (AT) keyboard to be plugged in because if there isn't one the kernel reports timeouts and seems slower than when there is a PS/2 keyboard present, my guess is because it is waiting on all of those timeouts. The next major keyboard thing I noticed is that I can type on certain keys but if I do anything like hit the caps lock key or number lock a couple of times then the keyboard stops responding completely and the kernel tells me that there was an error waiting on a IRQ on CPU #1. So I guess my questions are the following, is it totally hopeless to want to try and get a USB keyboard to work as the systems only keyboard and have it work under X and also not freeze the whole system when hitting certain keys? Do I just need to give up for now and get one of those USB->PS/2 converters and use my normal keyboard port, if so will Linux ever be able to not depend on PS/2 hardware for keyboards on ix86? I am not looking for anything fancy here, I mean all the extra keys on it like front, stop etc. would be nice to use eventually but if they do absolutely nothing that is fine with me, I just want to be able to use this keyboard. Below are the pertinent .config sections, this is on a Tyan Tiger 230 which uses a Via chipset. The mouse is still working right now and X works if I have a PS/2 keyboard only plugged in and just use the mouse.

Thanks for any help you can give me.

Jordan Breeding

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y

#
# Input core support
#
CONFIG_INPUT=y
CONFIG_INPUT_KEYBDEV=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_LONG_TIMEOUT=y
CONFIG_USB_LARGE_CONFIG=y
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
CONFIG_USB_UHCI=y
# CONFIG_USB_UHCI_ALT is not set
# CONFIG_USB_OHCI is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH is not set
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_HID=y
CONFIG_USB_HIDDEV=y
# CONFIG_USB_WACOM is not set
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HP5300 is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_PWC is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_PLUSB is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_CATC is not set
# CONFIG_USB_CDCETHER is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_RIO500 is not set

#
# Bluetooth support
#
# CONFIG_BLUEZ is not set

I use a USB keyboard (Macally iKey) and mouse (Logitech iFeel) without problems. I also get these messages, but I dont see any performance problem. It may help you to enable an option like "Legacy USB keyboard support" in your BIOS. This will emulate a PS/2 keyboard until USB is initialized.

This was discussed in the USB mailing list a few weeks ago. Several people experienced this problem, including me. As a workaround, use the alternate UHCI (JE) driver.

bye...

If you're using it on a wintel arch machine, have you managed to get the numeric keypad's = key or the power key to work? Doesn't here and I've tried more than one model of keyboard on more than one machine, no luck even with showkey. MacOS likes the keys just fine, naturally.

Joseph Carter <[email protected]>                   Free software developer

* TribFurry only gets spam mail from ucsd... I used to get email from
            myself but I decided I didn't like myself and stopped talking
	    to me

You are using an SMP kernel. In my experience, nothing USB works with an SMP kernel >2.4.3.

//jb

Yes, the JE driver did solve my problems, the keyboard now works on the console and under X, and of course the mouse still works. Thank you for the help.

Jordan

hei,

I got a compiler source and would like to port it to linux platform later, what Linux specific directories/ methods I would need for this porting? Any documemtation available?

thanks a lot
eric

I just borrowed a Mac keyboard and looked.
The Numpad = key gave scancode 5c, the power key gave e05e. The command getkeycodes showed that the former was assigned to keycode 127, while the latter was not assigned.
The command "setkeycodes e05e 25", where 25 is the keycode for the letter p, made the power key produce the letter p.

You see that you can do with a USB keyboard what you can do with an ordinary keyboard: use setkeycodes to assign a keycode to scancode combinations that didnt have one yet, use loadkeys to assign a function to a keycode.

To understand the details of the code, trace the steps:
(i) The USB code can be found e.g. on

	http://www.win.tue.nl/~aeb/linux/kbd/scancodes-5.html

We find that Power is 102 and that Keypad-= is 103.
(ii) In usbkbd.c:usb_kbd_keycode[] these keycodes are converted to 116 and 117, and then input_event is called.
(iii) In keybdev.c:x86_keycodes[] these codes are converted to 350 and 92. The former is 256+94 and becomes e05e, the latter 5c. This is fed further to the usual keyboard processing.

Andries

I was pretty sure this didn't work the last time I tried it, but I went ahead and fed your example to setkeycodes in case I missed something. The power key still does nothing..

I suspect the problem is that the HID driver never sees these keys in the first place. Just a wild guess.

I find that KP = can also be 134, according to this. I suppose I could toss some debuggatory messages into the HID driver on receipt of a USB code that is unknown to tell me which one it is so it will be known in that case. =) It's a longshot, but it sounds like a reasonable thing to try.

As noted, I'm using the HID driver, but the definitions match. Neither driver defines key 134.

Right, that makes perfect sense. Unfortunately, as I said, it isn't working. The keys do the right thing on a mac. I can only assume that the keyboard is being convinced somehow that these keys should be "dead" (or the motherboard is deciding that for me..) The other thought I have is that perhaps the = key (the important one) is in fact key 134 on this thing and that the power key is something else entirely.

This is, of course, just wild speculation at the moment. I actually have no idea if I am on the right path or going the wrong way down a one way street. I can assume then that if you see me running back this way fast as I can go, the one way street has it.. ;)

Thanks for the reference. Very nifty.

Joseph Carter <[email protected]>                   Free software developer

<dhd> is there a special christmas pack for quake
<dhd> where you get to be like the santa robot on futurama?
<dunham> dhd: that would be a rather unbalanced game...
<Knghtbrd> dunham: that's the idea.  ;>

Yes. The USB spec says for this code: "used on AS/400 keyboards".

Probably not much chance this keyboard will be using it then. Some AT keyboards require some sort of magic enable string be sent to make them use certain unusual keys in the manner you would expect. Any chance of that in the USB arena? I'm just grasping at straws here, but I suppose it's possible.

Joseph Carter <[email protected]>                   Free software developer

<Culus> OH MY GOD NOT A RANDOM QUOTE GENERATOR
<netgod> surely you didnt think that was static? how lame would that be? 
         :-)

Hm, that's a pretty vague statement :)
I'm happily running USB on a few SMP machines around here. What are the problems that you are having?

thanks,

greg k-h

Well, the problems I have (had; I'll get to that) are:

* Hard lockup whenever you try to access an USB audio device
* Sudden reboot sometimes when streaming video from an USB webcam.

The first problem appeared in 2.4.3 and only on SMP, but I know work around that by using the alternate UHCI driver which seems to work well so far. The second problem persists, but that is probably just a bug in the camera driver. Nevertheless, all USB devices I tried on { SMP, kernel >2.4.3, non-alternate UHCI driver } failed, so my statement was correct. :)

Since the alternate UHCI driver works I am satisified, but perhaps someone interested in the normal driver should look into what happened between 2.4.3 and 2.4.4.

//jb