Marcus Alves Grando wrote: > Emil Mikulic wrote: > >>On Tue, May 09, 2006 at 05:01:30PM -0700, Pascal Hofstee wrote: >> >>>I recently decided to add kbdmux support to my default kernel config >>>since i noticed at times that upon kernel panics and similar events my >>>USB keyboard goes dead. >>> >>>Today i got to actually installing a kbdmux enabled kernel and came to >>>the conclusion that even though keys like Capslock, Numlock and >>>Scrolllock perform the functions they're supposed to do, the keyboard >>>leds seem to arbitrarily decide wether or not they want to toggle >>>on/off. >>> >>>on console i noticed that usually after hitting e.g. caps lock a few >>>times the leds decdide to "work with me again" and toggle on/off >>>accordingly .. until i hit any actual textual input .. at which point >>>the previous eratic behavior has resurfaced. >>> >>>Similar problems exist in X as well ... though seem to be even more >>>eratic there. >>> >>>Removing kbdmux from my kernel seems to restore normality again. >>> >>>Am i the only one seeing these problems ? >> >>I'm seeing a similar (but different?) problem - I get an interrupt storm >>every time I hit Caps Lock or Num Lock, or flip VTs in text mode. If >>XMMS is running, the music skips. > > I already get this too and already report to kbdmux maintainer. i can not reproduce it here with dell latitude d610 laptop. i think, that this maybe particular usb keyboard/bios fault. kbdmux(4) really does not do anything except switching slave keyboards into "raw" mode and pass all scancodes to the upper layers. it seems like kbdmux(4) exposes all the little problems with low level keyboard drivers. again, i'm looking into this, but i do not have much time right now. thanks maxReceived on Wed May 10 2006 - 15:24:40 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:55 UTC