Bug 11242 - Regression with handling the DEL key on Thinkpad X31
Regression with handling the DEL key on Thinkpad X31
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Console/Framebuffers
All Linux
: P1 normal
Assigned To: James Simmons
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-03 14:10 UTC by Moritz Mühlenhoff
Modified: 2008-10-02 23:53 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.26
Tree: Mainline
Regression: Yes


Attachments
A Kernel Configuration (Compressed with lzma) that does not Exhibit the Problem (70 bytes, text/plain)
2008-09-16 01:51 UTC, Shlomi Fish
Details
Suggested patch (1.43 KB, patch)
2008-09-17 02:26 UTC, Pascal Terjan
Details | Diff

Description Moritz Mühlenhoff 2008-08-03 14:10:00 UTC
Latest working kernel version: 2.6.25.10
Earliest failing kernel version: 2.6.26
Distribution: Debian unstable
Hardware Environment: IBM Thinkpad X31
Software Environment: Debian unstable
Problem Description:

I'm running my system without X11 in a fbcon console. Since the update to 2.6.26 the INSERT key is no longer working properly. It seems to lead to a very strange internal "lock": If INSERT is pressed, the arrow keys are no longer accepted. If I press INSERT again, the arrow keys work again. This bug is fairly annoying.
In X11 the INSERT key is handled properly. 2.6.25 works just fine. 

Steps to reproduce:
Run elinks with an arbitary web site; scroll a few lines up with the INSERT key.
Comment 1 Dmitry Torokhov 2008-08-03 21:39:07 UTC
Does it help if you take drivers/char/keyboard.c from 2.6.25 and put it into 2.6.26?
Comment 2 Moritz Mühlenhoff 2008-08-04 11:48:21 UTC
(In reply to comment #1)
> Does it help if you take drivers/char/keyboard.c from 2.6.25 and put it into
> 2.6.26?

Doesn't build:
 
 CC      drivers/char/selection.o
 CC      drivers/char/keyboard.o
drivers/char/keyboard.c: In function ???kbd_keycode???:
drivers/char/keyboard.c:1230: error: ???struct tty_driver??? has no member named ???chars_in_buffer???
make[3]: *** [drivers/char/keyboard.o] Fehler 1
make[2]: *** [drivers/char] Fehler 2
make[1]: *** [drivers] Fehler 2
make[1]: Leaving directory `/home/jmm/linux-source-2.6.26'
make: *** [debian/stamp-build-kernel] Fehler 2

I'm suspecting this commit:

console keyboard mapping broken by 04c71976

Several console keyboard maps are broken since

commit 04c71976500352d02f60616d2b960267d8c5fe24
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Tue Oct 16 23:27:04 2007 -0700

   unicode diacritics support

because that changeset made k_self consider the value as a latin1
character when in Unicode mode, which is wrong; k_self should still take
the console map into account.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

I'll try a build of 2.6.26 with the patch above reverted.
Comment 3 Moritz Mühlenhoff 2008-08-04 15:08:41 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Does it help if you take drivers/char/keyboard.c from 2.6.25 and put it into
> > 2.6.26?
> 
> Doesn't build:
> 
>  CC      drivers/char/selection.o
>  CC      drivers/char/keyboard.o
> drivers/char/keyboard.c: In function ???kbd_keycode???:
> drivers/char/keyboard.c:1230: error: ???struct tty_driver??? has no member
> named ???chars_in_buffer???
> make[3]: *** [drivers/char/keyboard.o] Fehler 1
> make[2]: *** [drivers/char] Fehler 2
> make[1]: *** [drivers] Fehler 2
> make[1]: Leaving directory `/home/jmm/linux-source-2.6.26'
> make: *** [debian/stamp-build-kernel] Fehler 2
> 
> I'm suspecting this commit:
> 
> console keyboard mapping broken by 04c71976
> 
> Several console keyboard maps are broken since
> 
> commit 04c71976500352d02f60616d2b960267d8c5fe24
> Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
> Date:   Tue Oct 16 23:27:04 2007 -0700
> 
>    unicode diacritics support
> 
> because that changeset made k_self consider the value as a latin1
> character when in Unicode mode, which is wrong; k_self should still take
> the console map into account.
> 
> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
> I'll try a build of 2.6.26 with the patch above reverted.

Reverting this change doesn't help. Maybe it's related to the "tty: The big operations rework" commit? The other keyboard.c changes between 2.6.25 and 2.6.26 look harmless.
Comment 4 Moritz Mühlenhoff 2008-08-06 12:33:00 UTC
This is also reproducible with 2.6.27-rc2.
Comment 5 Jakub Wilk 2008-08-10 08:11:44 UTC
I am experiencing the very same bug on my PC workstation with a PS/2 keyboard, Linux 2.6.26.

The bug comes out both in a vgacon and a fbcon, both in XLATE and UNICODE keyboard modes. Remapping keycode 110 to something else than Insert does not alter this behaviour.
Comment 6 Pascal Terjan 2008-09-15 23:53:45 UTC
Still happens with 2.6.27-rc6-git3
Comment 7 Shlomi Fish 2008-09-16 01:51:38 UTC
Created attachment 17801 [details]
A Kernel Configuration (Compressed with lzma) that does not Exhibit the Problem

It seems not all kernel configurations exhibit this problem. While the Mandriva kernel exhibits this problem on my Mandriva Cooker system, this config file used to configure kernel-2.6.26.5 does not.
Comment 8 Pascal Terjan 2008-09-16 15:04:42 UTC
It seems that disabling CONFIG_A11Y_BRAILLE_CONSOLE fixes the issue but I fail to understand why.

Reading braille_console.c :

#define BRAILLE_KEY KEY_INSERT

                        if (param->value == BRAILLE_KEY) {
                                console_show = 0;
                                beep(880);
                                vc_maybe_cursor_moved(vc);
                                vc_refresh(vc);
                                ret = NOTIFY_STOP;
                        }

And reading keyboard.c it will ignore the keypress because of NOTIFY_STOP

But reading printk.c, it should only be enabled when console=brl...
Comment 9 Pascal Terjan 2008-09-16 15:23:58 UTC
static int __init braille_init(void)
{
        register_keyboard_notifier(&keyboard_notifier_block);
        register_vt_notifier(&vt_notifier_block);
        return 0;
}

console_initcall(braille_init);

I have not yet read about how console drivers work, but doesn't that mean that notifiers will always be used even if braille_register_console is never called ?
Comment 10 Pascal Terjan 2008-09-17 02:26:58 UTC
Created attachment 17833 [details]
Suggested patch
Comment 11 Samuel Thibault 2008-09-18 15:01:07 UTC
Thanks for the investigation and the patch, but some commit log would be useful :)    Only register the braille device VT and keyboard notifiers when a braille console is being registered.  Avoids eating insert or backspace key.  Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> 
Comment 12 Adrian Bunk 2008-10-02 23:53:48 UTC
fixed by commit c0c9209ddd96bc4f1d70a8b9958710671e076080

Note You need to log in before you can comment on or make changes to this bug.