Re: Bug with keyboard input

[Eric.Brunet@lps.ens.fr]

On Tue, May 13, 2008 at 10:47:47PM +0200, Jiri Slaby wrote:
> On 05/13/2008 11:27 AM, Eric.Brunet@lps.ens.fr wrote:
>> Hi list,
>>
>> With uptodate Fedora 7 (kernel kernel-2.6.23.15-80.fc7) on a Dell D430 laptop.
>
> Please file a bug on redhat bugzilla. They (like other distro providers) 
> have bunch of patches included in it.
>
> Or try some kernel.org tree and recheck if the problem persist, then report it here.

Well that's not the sort of things distributions are patching, but you're
of course right, it is better to make sure. So I downloaded the sources
of a linux-2.6.25, copied the fedora .config, ran make oldconfig and
made the default answer to every question. With that pristine kernel, the
bug is still here.

Thanks,

	Éric Brunet

> In short, if I do
>         echo -n "i8042" > /sys/bus/platform/drivers/i8042/unbind
> followed by
>         echo -n "i8042" > /sys/bus/platform/drivers/i8042/bind
> everything works fine, EXCEPT if I hit a key on the keyboard between the
> unbind and the bind (tested with leftcontrol and spacebar). If I hit a
> key, it looks like the keyboard isn't taking release events anymore and
> the next key I hit is forever repeated. When my keyboard is in its
> working
> state, I read
>         N: Name="AT Translated Set 2 keyboard"
> in /proc/bus/input/devices. When it is in its non-working state (I hit a
> key between unbind and bind), I read
>         N: Name="AT Raw Set 2 keyboard"
> in the same file, and each time I hit a key, I have messages such as
>     atkbd.c: Unknown key pressed (raw set 2, code 0x11f on
> isa0060/serio0).
>     atkbd.c: Use 'setkeycodes 1f <keycode>' to make it known.
>     atkbd.c: Unknown key pressed (raw set 2, code 0x11e on
> isa0060/serio0).
>     atkbd.c: Use 'setkeycodes 1e <keycode>' to make it known.
> in my logs.
> 
> Note that the key doesn't have to be pressed while the bind happens, it
> is sufficient that the key have been pressed and released before the
> bind.
> 
> So, is there a way to make it work and have the input layer automatically
> recognize the correct keyboard type or keyboard mode ? If not, is there a
> way to keep it from guessing and to force it to treat the keyboard as an
> "AT Translated Set 2 keyboard" ?
> 
> As a final note, I get hit by this bug quite often during suspend/resume
> cycles. I had found that the keyboard wasn't all the time properly waking up,
> (it was getting stuck) so I've added a file in /etc/pm/sleep.d to do the
> unbind at suspend time and the bind at resume time. This fixed my
> problem, except that at times I stupidly press a key in the hope that the
> resume is done and that the screen is black only because of the
> screensaver, and that hitting a key will make appear the unlocking
> window...