Happens in rawhide and in F-8. I have a Thinkpad T42. On login, numlock becomes enabled _somehow_. The LED turns on. You can disable numlock by pressing Shift+NumLk/ScrLk on the keyboard. The functionality will be disabled, but the LED is still enabled. The system runs fine otherwise. Numlock becomes re-enabled at different points, most notably when the screen saver starts.
This is happening to me too all of the sudden- never seen it before yesterday, now it is happening randomly, including after resuming from suspend. Note also that the numlock light on the machine no longer seems to bear any relationship to whether or not numlock is on. [This is with latest F8 including updates-testing; Thinkpad X41 tablet.]
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Is this still an issue? the keyboard driver has seem some changes regarding this upstream and it should have trickled down by now. If so, can you please provide an Xorg log so I can have a look at what driver you're using. Thx.
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Not happening here any more, as far as I can tell. Fine by me if it is closed.
Thanks for letting us know.
I guess I can't reopen, but I'm seeing just this again. * numlock light no longer reflects state of numlock key * numlock turned on after every reboot or return from sleep/hibernate. Will attach xorg.log.
Created attachment 320595 [details] xorg log as requested earlier Please reopen the bug. :)
I love reopening bugs ;-). Grrr.
hmm, no success in reproducing this issue, neither with F9 nor F10. down to guesswork. can you toggle the numlock light at all? please attach the xev output when toggling numlock, the output of setxkbmap -print and the out.xkb file after running xkbcomp -xkb :0 out.xkb does the numlock (and the led) change state when VT switching? is there a BIOS option to turn numlock on at start? can you create a test user and log in as test user. is the issue still present then? (this is to make sure there aren't any stale settings)
/can you toggle the numlock light at all?/ No. At least, not in any obvious way. /is there a BIOS option to turn numlock on at start?/ I don't think so. /does the numlock (and the led) change state when VT switching?/ Numlock and the LED appear to work correctly when in a VT instead of in X. If I turn the LED off in the VT, when I return to X the LED stays off, and then I can't turn it back on (unless I go back to a VT.) /can you create a test user and log in as test user. is the issue still present then? (this is to make sure there aren't any stale settings)/ I can check that later, but I doubt it, as this worked, then broke, then work, then re-broke, with no relevant changes of user setting- just upgrades of packages. Like I said I'll check, though. /xev/ KeyPress event, serial 30, synthetic NO, window 0x3c00001, root 0x89, subw 0x0, time 574561506, (172,-10), root:(176,13), state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 30, synthetic NO, window 0x3c00001, root 0x89, subw 0x0, time 574566188, (172,-10), root:(176,13), state 0x1, keycode 77 (keysym 0xfef9, Pointer_EnableKeys), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 30, synthetic NO, window 0x3c00001, root 0x89, subw 0x0, time 574566306, (172,-10), root:(176,13), state 0x1, keycode 77 (keysym 0xfef9, Pointer_EnableKeys), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False PropertyNotify event, serial 30, synthetic NO, window 0x3c00001, atom 0x183 (XKLAVIER_STATE), time 574566308, state PropertyNewValue KeyRelease event, serial 30, synthetic NO, window 0x3c00001, root 0x89, subw 0x0, time 574566738, (172,-10), root:(176,13), state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False [louie@towel ~]$ setxkbmap -print xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+inet+inet(pc105)" }; xkb_geometry { include "pc(pc105)" }; };
Created attachment 321241 [details] out.xkb as requested Note that numlock (and LED) were off (via the VT) when I got this file.
Oh, I think I got it. Please run "setxkbmap -model ibm_spacesaver" and try again. (In reply to comment #11) > KeyPress event, serial 30, synthetic NO, window 0x3c00001, > root 0x89, subw 0x0, time 574566188, (172,-10), root:(176,13), > state 0x1, keycode 77 (keysym 0xfef9, Pointer_EnableKeys), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 0 bytes: > XFilterEvent returns: False You should be getting Num_Lock here, not Pointer_EnableKeys. However, with the T42 keyboard, you have to hit shift + numlock which never sends the Num_Lock keysym. This is due to numlock being on the same phys. key as ScrollLock. This should be avoidable by using Fn instead of Shift for numlock or setting the model to ibm_spacesaver.
Hrm. That setxkbmap invocation doesn't seem to make it work here, nor does using Fn instead of shift. I should probably try it with a clean reboot. [Note that this is F9, not rawhide, if that matters.]
Run xkbcomp :0, then edit the newly created server-0.xkb and replace the line key <NMLK> { [ Num_Lock, Pointer_EnableKeys ] }; with key <NMLK> { [ Num_Lock, Num_Lock ] }; then load the file with xkbcomp server-0.xkb :0 if you run xkbcomp :0 again, the server-0.xkb should now be just as you edited it (this is for verification) If it doesn't work, please attach the xev output again.
(In reply to comment #15) > then load the file with xkbcomp server-0.xkb :0 At this point X segfaults. ;) Alternative suggestions to test/fix the numlock problem, and/or how to get decent debug information on the segfault?
wow. impressive, but that wasn't quite part of the plan. Could you open another bug please with the backtrace if you get one. If you're running a display manager, the backtrace should be in /var/log/Xorg.0.log.old Ideally you could install the debuginfo packages and attach gdb (over ssh from a second machine) to get a detailed backtrace. btw, what's your xserver and xkeyboard-config versions? I got 1.5.0-3 and 1.3.1, respectively. Can you select the space saver keyboard through gnome-keyboard-properties (under IBM in the model selector)?
I'll try to gdb and file another bug some time this week. xserver I get 1.5.0-2 and xkeyboard-config 1.2-4. (Checking koji both appear to be the latest available for FC9.) g-k-p does not show a space saver option under IBM; I'm using Generic 105-key (Intl) PC with US+inet layout, which I think was recommended many moons ago in another bug to resolve volume control problems (which have also cropped up again, but that is another bug; bug 321421 IIRC.)
(In reply to comment #18) > I'll try to gdb and file another bug some time this week. ping
sorry, wrong victim of my NEEDINFO.
Note that I'm seeing this in F10 as well.
actually, there's gnome setting that might be at fault there: - In gconf-editor, un-check /desktop/gnome/peripherals/keyboard/host-HOSTNAME/0/numlock_on. This disables numlock. - In gconf-editor, un-check /desktop/gnome/peripherals/keyboard/remember_numlock_state. With this setting, gnome remembers the numlock state from the last session. Without, numlock is always off when starting. You said numlock was on - is this before or after login? Or has F10 changed the behaviour of the numlock light completely anyway? I'm not 100% sure anymore on the exact symptoms now, they seem to have changed a few times.
i am also seeing this on F10 since last week on a thinkpad x31. at boot or after resuming from suspend numlock gets switched on (so some letter keys become numbers). i shall try some of the remedies mentioned.
setting the needinfo flag, Sam, Luis, if you could try the gnome settings that'd be much appreciated.
the gconf settings do the job. the keyboard layout seems to have no effect on the problem. thanks
closing this as NOTABUG, this is a configuration issue.