Sometimes when I boot my Slackware 13 box (dual-booted with WinXP, if it matters), the keyboard becomes totally unresponsive. I can't login or do anything. What makes it even more infuriating is that LILO has no problem with the keyboard, and nor does a little dialog telling me that video mode 303 is invalid and I should press the space bar to accept the default. That always works. It seems to be only when Slackware proper has taken things over.

I'll sometimes go long periods with no problems, and then sometimes it won't work for several boots in a row. Once, it refused to work for 5 or 6 boots in a row. It's a good thing Linux shuts down cleanly when I hit the power button.

I can tell before the login prompt comes up whether the keyboard is going to work. If it's working at all, I can press the keys and they show up among the boot messages, starting somewhere before the "INIT 2.86" or whatever notification goes by.

I have a weird hardware setup that may be contributing. My computer has no PS/2 ports to connect my PS/2 keyboard and mouse to. So I'm using an adapter that routes two PS/2 connections into a single USB connection, which might have something to do with the problem. I always guessed that the mouse was somehow interfering with the keyboard, and I've had some other weird issues where certain mouse movements seem to trigger key presses. I tried disabling GPM, but that didn't have an effect, so I put it back.

Really, though, I don't know what's going on. I'd really like to fix this, and if it solved the other input issues, that would be an added bonus. Thanks everyone!

Edit: Just to be clear, it always works in Windows.

The range of possibles is stupendous for this particular PITA.

The keyboard works at Lilo (on bios). Then you load the kernel, and unless you have keyboard support in, you might lose it. Might I suggest an entry into the 21st millenium as follows:

junk ps/2 as a hangover from dos. Buy a tiny usb hub, if you are embarassed for usb ports. My local 2euro shops have usb hubs for that money. But a usb keyboard, and mouse. One bios setting might affect keyboard action. If you enable 'wake on usb' you should be safe.

Hmm... my experience with USB keyboards is less than pleasant. Do they usually work in the BIOS? I guess the only time I've tested it has been with one of these big stupid Microsoft internet keyboards. I had to plug in my PS/2 keyboard to get into the BIOS, and this on a pretty recent machine. The computer in question is considerably older.

I can't find the BIOS setting you mentioned, or anything similar to it.

Also, my budget for computer equipment for the foreseeable future is zero. So I can't just go and buy a new keyboard and mouse... :/

The startup issue with usb keyboards is usually this: There's a 5V supply in the pc which is switched off on standby, and another which is not (allowing for wake up). In some way the usb is powered from either - and you can usually set that, unless the hardware is old.

The big plus of usb is that it does the same thing every tie.

Well, I guess my hardware is pretty old, because I don't see anything at all about USB in the BIOS settings.

Are there any other options? Windows, for all its faults, handles it fine. It seems like there must be some way to make it work.

Hi AndrewF! This looks like your first thread here - so let me first say "Welcome to LQ!"

I do not have a direct answer for you, but I do have shared sympathies for older hardware and zero budgets - plus I had a problem that sounds similar at one time.

WAY back when, I had a system which suffered from mouse/keyboard "crosstalk" for lack of a better term. They were both PS/2 types, although I cannot remember the exact method of connection (or my own name at times!).

But I recall that very intermittently mouse moves would be interpreted as key presses. Also, as in your case, on the odd occasion the keyboard would not work at all after boot. I think I was using SuSe 6.1 at the time, although that is probably not important.

Anyway, what I found was that if I did not connect the mouse until after boot it would always work, and the keyboard would always 'connect'. So, as you have mentioned some crosstalk between mouse and keyboard, you might try this as an exercise to see if the keyboard ever fails when the mouse is not present. That might lead to discovering something like the driver load order being significant... or nowhere at all.

Thanks for the welcome, astrogeek. I think I have actually tried booting without the mouse and still had the same problem. I guess I'll try again for a while, just to make sure.

Yeah, I just booted without the mouse, and I still had no keyboard.

Well, at least you got a fast answer.

Can you access it after a 'failed' boot through a network, so that you can see dmesg output and look at your devices, etc.? (I assume that if you can you already would have done so, but doesn't hurt to ask).

If so, save dmesg output to a file (#dmesg >dmesg_nokb) and we can see what it says.

Also, you said you have a weird hardware setup - a descrption might help, and maybe a basic description of the system itself.

The "weird hardware setup" I mentioned was just the PS/2 to USB adaptor. I don't think it has any other real oddities, but I can't be sure. The keyboard and mouse are both Compaq.

I've thought about trying to get into it through a network, but I'd never tried since I thought it would be trickier than it was. But all I had to do was grab its IP address from /sbin/ifconfig and PuTTY in across my router. I feel dumb now...

Anyway, it seems my computer is now determined to be free of this problem, because the very next time I rebooted it, just now, the keyboard failed and I grabbed the output of dmesg. Interestingly, when I started X remotely, the mouse worked.

I've posted the output on pastebin, here.

Maybe you should try buying separate PS/2 to USB adapters for the keyboard and the mouse. I know you said Windows works with it, but maybe the Linux driver is confused by it. Someone mentioned looking into your BIOS settings, I think they meant that you should look for a USB keyboard support and USB mouse support option and enable them (if you don't see anything, don't worry about it).

When the keyboard doesn't work and you login remotely, could you look at dmesg, /var/log/syslog, /var/log/Xorg.0.log, and ~/.xsession-errors to see if you spot anything strange? I did look at your dmesg output and didn't see anything related to your keyboard problem.

Another thing you could always try is using the latest kernel and see if the latest driver clears up your problem.

Well it looks like it sees the keyboard and mouse well enough...

I should have also asked you to save the output of lsmod - both when it works and when it fails... so maybe next time. That way we can see what is actually handling your keyboard, and whether some module is not loading, or if one is loading that should not be.

Also, as you now can get in via the network, look for the keyboard under /dev/input/by-path/..., something ending like "...serio-0-event-kbd". That will be a symlink to the real device. To see the raw output:

cat /dev/input/by-path/..kbd - then type a key.

You should see nasty looking "stuff" sent by the keyboard (yes/no). CTRL-C to get your remote shell back.

I am not expert at any of this, especially USB devices (but usually manage to find the way through it), so please be patient.

You mean to see if there is anything there, when the normal keyboard doesn't work?

I'll be as patient as I need to be. I'm just grateful for your patience.

Ok, lsmod output when I can use the keyboard here.
'Failed' lsmod output here.

When I logged in remotely, I got nothing from the /dev/...kbd file when the keyboard wasn't working.

OK, that is what I meant - so no output here limits us to the module (driver) that creates/controls the device node I think.

lsmod shows only two notable differences between when it worked and when it did not:

i810
drm

The i810 is the driver for the Intel graphics chipset and drm would be related. Was X running with the working lsmod, or were you still at the console? The question here is: all else being equal - did the i810 module fail to load, or was the machine state different between the two lsmod listings. i810 would not seem to be related to the keyboard, but it is worth knowing why it was not loaded.

One thing that I do not see but expected was any kind of USB driver. I am not really knowledgable about the USB modules but have had to force loading of them before. I have a USB keyboard on a Slackware 12.1 box and it loads a usbhid module.

THIS IS A GUESS: I really don't know the full use of the HID protocol/module but it should be in your Slack 13 install. You might want to just load it and see if it will bring your keyboard to life (or kill a working one).

modprobe usbhid (as root)

and

modprobe usbkbd (may not be there)

FWIW: On this page read the first two paragraphs to see difference between usbhid and usbkbd modules.

If forcing usbhid wakes it up then we can auto load it at boot. If not... we can read some more...

Hope that was clear enough - it is very late!