* keyboard.c fix in 2.4.21 breaks my (buggy?) keyboard
@ 2003-07-01 22:38 Andreas U. Trottmann
2003-07-02 6:39 ` Catalin BOIE
0 siblings, 1 reply; 2+ messages in thread
From: Andreas U. Trottmann @ 2003-07-01 22:38 UTC (permalink / raw)
To: linux-kernel
Hello linux-kernel,
patch-2.4.21 contains the following patch to keyboard.c:
diff -urN linux-2.4.20/drivers/char/keyboard.c linux-2.4.21/drivers/char/keyboard.c
--- linux-2.4.20/drivers/char/keyboard.c 2002-08-02 17:39:43.000000000 -0700
+++ linux-2.4.21/drivers/char/keyboard.c 2003-06-13 07:51:33.000000000 -0700
@@ -213,7 +215,17 @@
}
kbd = kbd_table + fg_console;
if ((raw_mode = (kbd->kbdmode == VC_RAW))) {
- put_queue(scancode | up_flag);
+ /*
+ * The following is a workaround for hardware
+ * which sometimes send the key release event twice
+ */
+ unsigned char next_scancode = scancode|up_flag;
+ if (up_flag && next_scancode==prev_scancode) {
+ /* unexpected 2nd release event */
+ } else {
+ prev_scancode=next_scancode;
+ put_queue(next_scancode);
+ }
/* we do not return yet, because we want to maintain
the key_down array, so that we have the correct
values when finishing RAW mode or when changing VT's */
But apparently, there is not only hardware that sends the key release
event twice, but also hardware that sends the key press event twice
in certain circumstances.
I've got a keyboard ("Unikey model KWD-205"), which, for the left
control key (and apparently only for this key) sends the key down
event twice, followed by two key up events. For certain applications
using VC_RAW (most important XFree86), this means that the ctrl
key gets "stuck" once it's been pressed.
I don't know an "appropriate" fix to this problem. Obviously, the
patch got inserted in 2.4.21 because it fixes broken keyboards
owned by many people. As I didn't find any reports about my
problem with google, it seems that keyboards like my one are
quite rare. One possible solution would be to ignore any events
where next_scancode==prev_scancode, regardless of up_flag - but
this breaks autorepeat, which then would maybe need to be
emulated.
Another possible fix would be to only ignore multiple identical
"up" events for non-modifier keys, but this would require
keyboard.c to have a list of key symbols of keys like "control",
"shift" etc.
So, are there other people having the same problem? Is it worth
to find a "good" fix for the linux kernel, or should I just
remove this patch by hand every time I compile a new kernel,
until my keyboard dies and I get a non-broken one? ;-)
--
Andreas Trottmann
Ideen Werft22 GmbH
Tel +41 (0)56 210 91 37
Fax +41 (0)56 210 91 34
Mobile +41 (0)79 229 88 55
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: keyboard.c fix in 2.4.21 breaks my (buggy?) keyboard
2003-07-01 22:38 keyboard.c fix in 2.4.21 breaks my (buggy?) keyboard Andreas U. Trottmann
@ 2003-07-02 6:39 ` Catalin BOIE
0 siblings, 0 replies; 2+ messages in thread
From: Catalin BOIE @ 2003-07-02 6:39 UTC (permalink / raw)
To: Andreas U. Trottmann; +Cc: linux-kernel
Hi!
I have this problem with left shift key.
X 4.2.0, 2.4.21, epox motherboard, several keyboards.
But this happen from 6 to 6 hours. And seems to last 10-20 seconds.
> Hello linux-kernel,
>
> patch-2.4.21 contains the following patch to keyboard.c:
>
> diff -urN linux-2.4.20/drivers/char/keyboard.c linux-2.4.21/drivers/char/keyboard.c
> --- linux-2.4.20/drivers/char/keyboard.c 2002-08-02 17:39:43.000000000 -0700
> +++ linux-2.4.21/drivers/char/keyboard.c 2003-06-13 07:51:33.000000000 -0700
> @@ -213,7 +215,17 @@
> }
> kbd = kbd_table + fg_console;
> if ((raw_mode = (kbd->kbdmode == VC_RAW))) {
> - put_queue(scancode | up_flag);
> + /*
> + * The following is a workaround for hardware
> + * which sometimes send the key release event twice
> + */
> + unsigned char next_scancode = scancode|up_flag;
> + if (up_flag && next_scancode==prev_scancode) {
> + /* unexpected 2nd release event */
> + } else {
> + prev_scancode=next_scancode;
> + put_queue(next_scancode);
> + }
> /* we do not return yet, because we want to maintain
> the key_down array, so that we have the correct
> values when finishing RAW mode or when changing VT's */
>
>
> But apparently, there is not only hardware that sends the key release
> event twice, but also hardware that sends the key press event twice
> in certain circumstances.
>
> I've got a keyboard ("Unikey model KWD-205"), which, for the left
> control key (and apparently only for this key) sends the key down
> event twice, followed by two key up events. For certain applications
> using VC_RAW (most important XFree86), this means that the ctrl
> key gets "stuck" once it's been pressed.
>
>
> I don't know an "appropriate" fix to this problem. Obviously, the
> patch got inserted in 2.4.21 because it fixes broken keyboards
> owned by many people. As I didn't find any reports about my
> problem with google, it seems that keyboards like my one are
> quite rare. One possible solution would be to ignore any events
> where next_scancode==prev_scancode, regardless of up_flag - but
> this breaks autorepeat, which then would maybe need to be
> emulated.
>
> Another possible fix would be to only ignore multiple identical
> "up" events for non-modifier keys, but this would require
> keyboard.c to have a list of key symbols of keys like "control",
> "shift" etc.
>
>
> So, are there other people having the same problem? Is it worth
> to find a "good" fix for the linux kernel, or should I just
> remove this patch by hand every time I compile a new kernel,
> until my keyboard dies and I get a non-broken one? ;-)
>
> --
> Andreas Trottmann
> Ideen Werft22 GmbH
> Tel +41 (0)56 210 91 37
> Fax +41 (0)56 210 91 34
> Mobile +41 (0)79 229 88 55
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
---
Catalin(ux) BOIE
catab@deuroconsult.ro
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-07-02 6:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-01 22:38 keyboard.c fix in 2.4.21 breaks my (buggy?) keyboard Andreas U. Trottmann
2003-07-02 6:39 ` Catalin BOIE
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).