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.
Does it help if you take drivers/char/keyboard.c from 2.6.25 and put it into 2.6.26?
(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.
(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.
This is also reproducible with 2.6.27-rc2.
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.
Still happens with 2.6.27-rc6-git3
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.
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...
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 ?
Created attachment 17833 [details] Suggested patch
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>
fixed by commit c0c9209ddd96bc4f1d70a8b9958710671e076080