Bug 460550 - Insert key does not work on console since 2.6.26
Insert key does not work on console since 2.6.26
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
http://bugzilla.kernel.org/show_bug.c...
: EasyFix, Patch, Regression, Upstream
: 458400 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-28 11:03 EDT by Stepan Kasal
Modified: 2008-11-24 09:15 EST (History)
7 users (show)

See Also:
Fixed In Version: 2.6.26.6-79.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-23 12:39:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/var/log/dmesg (25.12 KB, text/plain)
2008-08-28 11:03 EDT, Stepan Kasal
no flags Details
/var/log/Xorg.0.log (20.77 KB, text/plain)
2008-08-28 11:04 EDT, Stepan Kasal
no flags Details
/var/log/messages (192.11 KB, text/plain)
2008-08-28 11:06 EDT, Stepan Kasal
no flags Details
/etc/X11/xorg.conf (435 bytes, text/plain)
2008-08-28 11:07 EDT, Stepan Kasal
no flags Details

  None (edit)
Description Stepan Kasal 2008-08-28 11:03:35 EDT
Created attachment 315224 [details]
/var/log/dmesg

When I boot to level 3, and log in, everything works, I'm using 11 virtual ttys.

After some time, the keys between the main keyboard and the numeric keypad (arrows, Ins, Home, ..., PgDn) stop working.  Not all of them, only some subset.

The sometimes start working after a few minutes or hours...

The problem does not appear with 2.6.25 (namely 2.6.25-0.218.rc8.git7.fc9.i686 have run for many weeks without any problem)
but it seems to appear with various 2.6.26 kernels (e.g. 2.6.26-0.81.rc7.fc10).

I'm using "startx" and I suspect that the problem does not happen before I call startx and switch to X and back to console several times; but perhaps it is only that have not abstained from X was long enough.

I would like to receive any hints how could I help with this.
Comment 1 Stepan Kasal 2008-08-28 11:04:50 EDT
Created attachment 315225 [details]
/var/log/Xorg.0.log
Comment 2 Stepan Kasal 2008-08-28 11:06:35 EDT
Created attachment 315227 [details]
/var/log/messages
Comment 3 Stepan Kasal 2008-08-28 11:07:28 EDT
Created attachment 315228 [details]
/etc/X11/xorg.conf
Comment 4 Peter Hutterer 2008-08-28 21:34:52 EDT
A few questions for clarification:

(In reply to comment #0)
> When I boot to level 3, and log in, everything works, I'm using 11 virtual
> ttys.

do you actually boot into gdm, or just console?
When the keys stop working - is that in X or on the console?

> After some time, the keys between the main keyboard and the numeric keypad
> (arrows, Ins, Home, ..., PgDn) stop working.  Not all of them, only some
> subset.

This is usually a keymap issue. If you are in X when that happens, please run xkbcomp :0 - and attach the output here. Then also attach the same output when it is working.

Likewise, the info of setxkbmap -print is helpful in both cases.

> I'm using "startx" and I suspect that the problem does not happen before I call
> startx and switch to X and back to console several times; but perhaps it is
> only that have not abstained from X was long enough.

so do I get this right: you start X, switch from tty to X and back a few times and at one point it stops working? In X, presumably? Or at the tty?
Comment 5 Stepan Kasal 2008-08-29 03:53:29 EDT
I apologize that my bug report was so unclear.

(In reply to comment #4)
> do you actually boot into gdm, or just console?

I boot to console only.

> When the keys stop working - is that in X or on the console?

It stops working in console.
(In most cases, out of the 10 keys between 

There is no problem in X.

I do use a nonstandard keymap on console.  I do have an ancient keayboard (the hardware).  But I have used both for ages without any problem.  And if I boot to kernel 2.6.25, it works correctly, for several weeks.
Comment 6 Stepan Kasal 2008-09-11 09:17:58 EDT
reproduced with 2.6.27-0.284.rc4.git6.fc10.i686
Comment 7 Andreas M. Kirchwitz 2008-09-17 09:38:01 EDT
I've the same problem on Fedora 8 (32 Bit) after updating from
kernel 2.6.25 to 2.6.26. The system boots into console mode
(run level 3, no X started yet). Users cannot use cursor keys
and other application keys in the shell. Happens on four totally
different machines, so it's unlikely a hardware failure.

Interestingly, hitting the "Insert" key once cures the problem
temporarily but it doesn't last for long. Don't know what's so
special with the "Insert" key.

I hope it's not the first step to the newly introduced plan
to completely remove text consoles from Fedora. ;-)
Comment 8 Roman Rakus 2008-09-17 11:07:56 EDT
*** Bug 458400 has been marked as a duplicate of this bug. ***
Comment 9 Dan Horák 2008-10-02 09:12:24 EDT
My reproduction scenario
- boot into runlevel 5
- switch into vty X, cursor keys are working
- press Insert, cursor keys doesn't work
- press Insert again, cursor keys start working
Comment 10 Marcela Mašláňová 2008-10-02 09:43:56 EDT
My reproduction scenario
- use rawhide in vmware
- boot into runlevel 3
- try edit in vim -> some buttons aren't working - Insert for example
- boot into runlevel 5 -> vim is working, but some keys in konsole or other application are printed more than once.
Comment 11 Dmitry Butskoy 2008-10-08 09:52:46 EDT
Well, it seems the upstream's bug 11242:
http://bugzilla.kernel.org/show_bug.cgi?id=11242

Since 2.6.26, the console's "Insert" key behaves like a strange Lock. After the pressing of "Insert", some keys (including narrow, PgUp/PgDown etc.) no more work. AFter the pressing of "Insert" again, those keys continue to work. "Insert" itself does not work at all under Linux console since 2.6.26.

It seems that kernel developers have chosen the "Insert" key for the start of some accessibility mode under Linux console. Forgive them, guys. They just cannot consider how it is possible to work with computer in the current modern world without GUI. They assume that all the people who used TUI have already died, or (if still not died) need an accessibility, which they have implemented </sarcasm>.

Please, fix this disgusting issue in the next kernel update for all the current releases: Fedora 8, Fedora 9, upcoming Fedora 10 and Rawhide (IOW for all releases which have kernel-2.6.26 now).
Comment 12 Dmitry Butskoy 2008-10-08 10:15:37 EDT
The upstream's patch is here:
http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=review-2.6.26/braille_console-only-register-notifiers-when-the-braille-console-is-used.patch;hb=HEAD

Perhaps it would be better to compile an accessibility support as a module?
Comment 13 Dmitry Butskoy 2008-10-08 10:46:33 EDT
The temporary work-around.

The idea is to change the keycode, generated by the Insert key.

1. Run "dumpkeys" and chose an unused keycode. I've chosen 126 for my case.

2. Cause this keycode to generate "Insert" event (as an ordinary 110 keycode already do):

echo 'keycode 126 = Insert' | loadkeys

(You can test results by "dumpkeys | grep Insert")

3. Run "getkeycodes" and determine, what raw keycodes generated "110". In my case it is "e0 52"

4. Map "e0 52" to 126 instead of 110:

setkeycodes e052 126


As a result, the pressing of "Insert" key now generates "126" instead of "110", thus no more grabbing by the accessibility (which still expects "110"). And the "126" produces the same "Insert" event for the Linux console.


In short: add to /etc/rc.d/rc.local:

setkeycodes eo52 126
echo 'keycode 126 = Insert' | loadkeys
Comment 14 Andreas M. Kirchwitz 2008-10-08 20:05:35 EDT
Thanks, Dmitry, your workaround is great! Text consoles are now usable again.

However, this seems to affect the X Window System, the Insert key no longer
works (for example, toggle Insert/Replace in Vim or Shift-Insert to paste
text from the clipboard in xterm).

When I run "xmodmap -e 'keycode 116 = Insert'", X seems to feel much better.
Comment 15 Dmitry Butskoy 2008-10-09 08:46:04 EDT
Yep.

X keycodes do not match Console keycodes, therefore "xev" command should be used to obtain the keycode of the "changed" (by setkeycodes above) Insert key. Then add to /etc/X11/xinit/xinitrc.d/ some script with:

xmodmap -e 'keycode NNN = Insert'


Finally, I've chosen console code 124 (because 126 is actually in use). The soluiton is:

cat <<EOF >>/etc/rc.d/rc.local
setkeycodes eo52 124
echo 'keycode 124 = Insert' | loadkeys
EOF

cat <<EOF >/etc/X11/xinit/xinitrc.d/insert-key.sh
#!/bin/sh
xmodmap -e 'keycode 133 = Insert'
EOF
chmod +x /etc/X11/xinit/xinitrc.d/insert-key.sh


Note though, that setkeycodes does not affect USB keyboards at all :( Use non-usb keyboard instead for a while.
Comment 16 Chuck Ebbert 2008-10-10 01:50:28 EDT
So this should be fixed in 2.6.26.6 then. It should also be fixed in 2.6.27 since that patch was merged.
Comment 17 Fedora Update System 2008-10-14 15:50:42 EDT
kernel-2.6.26.6-46.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/kernel-2.6.26.6-46.fc8
Comment 18 Fedora Update System 2008-10-14 16:02:08 EDT
kernel-2.6.26.6-71.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/kernel-2.6.26.6-71.fc9
Comment 19 Fedora Update System 2008-10-20 16:29:12 EDT
kernel-2.6.26.6-79.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8929
Comment 20 Dmitry Butskoy 2008-10-21 08:35:50 EDT
for commet #17 :
> kernel-2.6.26.6-46.fc8 has been submitted as an update for Fedora 8.

and even was announced in fedora-devel list. But actually kernel-2.6.26.6-46.fc8 did not appear neither in updates nor in updates-testings.

What plans for F8 update?..
Comment 21 Fedora Update System 2008-10-23 12:38:40 EDT
kernel-2.6.26.6-79.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 Stepan Kasal 2008-11-24 09:15:52 EST
The bug continued to appear in various kernel versions, for example 2.6.27rcX (where X was 4, 5, or 6).
But it seems to be fixed in 2.6.27.5-101.fc10, so I'm happy the bug is fixed.

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