Caps lock LED changes state even when caps lock is mapped to ctrl

[Phil Sung]

I've mapped the Caps Lock key to be an additional Ctrl from Gnome's Keyboard control panel. It works; however, when I press Caps Lock, the Caps Lock LED on my computer still changes state.

This is on Hardy Alpha 1; I believe this problem did not occur on Gutsy.

I am using a Thinkpad X61s.

[Bogdan Butnaru (bogdanb)]

Similar situation: I have exchanged left Control with Caps Lock, and now
    * left Control changes the real caps lock state (ie, whether or not letters are capitals)
    * but Caps Lock changes the led state on the keyboard (though it works as a Control key)

I've noticed that since Hardy, Compiz displays at startup some information regarding the keyboard leds. So I suspect there's the flaw, though I have no idea what business Compiz has with the keyboard.

[Bogdan Butnaru (bogdanb)]

Attaching the bug to Compiz, where I think the problem originates.

[Phil Sung (psung)]

I am seeing this problem even with Metacity.

[Travis Watkins (amaranth)]

This is not a bug in compiz, what you're seeing is compiz outputting the data from `xset q` because it can't find your log file.

[Roland Dreier (roland.dreier)]

I started seeing this with Hardy on my Thinkpad X60s -- I have caps lock and ctrl switch, and the key labeled "CapsLk" still toggles the caps lock LED, even though it actually behaves like the control key. (And the key labeled "Ctrl" does not affect the caps lock LED, even though it does work like caps lock in that it makes what I type come out as capitals).

This did not happen with Gutsy.

[mrklean (mrklean)]

This problem is definitely Hardy specific. I'm on an Aspire 5100 and it worked on eisty But not on hardy !
Thanks ; )

[Bogdan Butnaru (bogdanb)]

This doesn't happen to me anymore, do you guys have the latest updates?

[Roland Dreier (roland.dreier)]

Still happening here on my Thinkpad X60s, with an up-to-date hardy system.

[anonym (launch-mailinator)]

Can be resolved by executing

xmodmap -e "clear lock" -e "add lock = Caps_Lock"

This should however be done automatically so it's still a bug.

[Hamish Downer (mishd)]

I have this problem as well (Fujitsu Siemens Esprimo E5916, USB keyboard). From the gnome keyboard preferences, I have chosen "Swap ESC and Caps Lock"

The keys work as far as typing output goes (checked in vim) but the caps lock key turns the caps lock light on and off, and the Escape key does not.

I'm using Hardy amd64 beta (up to date, fresh install).

[Jay Finger (jcfinger)]

I see this as well, running an HP 8710w. I have swapped Ctrl and CapsLock. The key labeled "caps lock" works as control but toggles the caps-lock LED. They key labeled "ctrl" works as caps-lock, but does not toggle the caps-lock LED.

I agree that this did not happen in Gutsy.

Using Hardy x86 beta. Problem happens with the standard video driver and the nvidia driver.

[MountainX (dave-mountain)]

I see this bug as well in Hardy i386 beta (up to date) on a desktop computer. I posted about it here:
http://ubuntuforums.org/showthread.php?p=4599879#post4599879
At that post another person said it did not happen in earlier versions.

Even using the keyboard layout utility to assign the capslock light as the alternative layout indicator didn't make it stop responding to the capslock key.

I just used the workaround and now my capslock light is permanently on :S
Maybe it will get resolved when I reboot

[Stephen Hemminger (shemminger)]

I just had this problem on a my laptop. One important clue is that it started only after I enabled:
Automatic Login

Perhaps part of the keyboard initialization process is being accidentally skipped during automatic
login?

[Robin Sheat (eythian)]

On Sunday 30 March 2008 16:17:04 Stephen Hemminger wrote:
> I just had this problem on a my laptop. One important clue is that it
> started only after I enabled: Automatic Login
>
> Perhaps part of the keyboard initialization process is being accidentally
> skipped during automatic login?
Neither of the computers I see it on have automatic login enabled.

[mattismyname (mattismyname)]

I was about to file a bug on this myself, but found this duplicate.

This is pretty annoying from a usability standpoint...especially since it's a regression from Gutsy.

[KarlGoetz (kgoetz)]

Adding a 'me too'.
Ubuntu hardy + Edubuntu, up to date as of today. experiencing the same problem, and as with the others, its a regression.

[mattismyname (mattismyname)]

Just to hilight the seriousness of this, my girlfriend just about took
my head off because she got locked out of her email account because
she didn't know caps-lock was on when she was typing her password.

I think this must get fixed for Hardy.

[Sebastien Bacher (seb128)]

the option is not on by default so no that's not a priority for hardy

[Stephen Hemminger (shemminger)]

Gnome developers need to learn that regressions do matter. It doesn't matter if the new features are better if you piss off previous users. Maybe it's time to go back to KDE like Linus

[Sebastien Bacher (seb128)]

what a constructive comment and behaviour and good luck to find a software which never introduce a breakage, mistakes happens in any project and it's doubtful than linux or kde are exceptions there

[Sebastien Bacher (seb128)]

you can also note than nobody thinks that bug don't matter but there is ten thousand bugs open right now in ubuntu and a really small team working on those, that sucks but everything can't be fixed right now. The people contributing at making those software better do it mostly for free after work and spend a lot of efforts in it so your comment are just unfair to them and their work, especially that ubuntu is not writting this code and not responsable for the change

[MountainX (dave-mountain)]

https://bugs.launchpad.net/xkeyboard-config/+bug/105538
similar bug report

[MountainX (dave-mountain)]

I found a workaround. I'm using Hardy beta.

Do not use gnome's keyboard control (Ubuntu System > Preferences > Keyboard > Layout Options).
Instead follow the example in man xmodmap as explained below.

NOTE: before doing this, undo any changes in Keyboard layout options. Put the options back to defaults in gnome's keyboard control.

And, if you have done anything advanced to try to work around this issue, remove those modifications too. For example, the following is NOT needed so if you are using it, remove it (may require a restart):
 xmodmap -e "clear lock" -e "add lock = Caps_Lock"

Put the following in a text file.

            !
            ! Swap Caps_Lock and Control_L
            !
            remove Lock = Caps_Lock
            remove Control = Control_L
            keysym Control_L = Caps_Lock
            keysym Caps_Lock = Control_L
            add Lock = Caps_Lock
            add Control = Control_L

save the above as /etc/SwapCapsCtrl.kmap

then, from a terminal, run:
xmodmap /etc/SwapCapsCtrl.kmap

To make the change permanent, do this:
edit /etc/rc.local
add the following before the last line that says 'exit 0'
sudo loadkeys /etc/SwapCapsCtrl.kmap

In addition, this solves my problems with tsclient.

[MountainX (dave-mountain)]

the prior comment has a typo:
loadkeys should be xmodmap

[Suckfish (suckfish)]

I use gnome-keyboard-properties to set US keyboard, and on the layout options
set 'swap caps lock and CTRL'

After setting this, caps-lock and CTRL are correctly swapped (as far as the
characters input), put the caps-lock LED on my keyboard is toggled by the wrong
key. i.e.,

(a) the key marked caps-lock now operates as a control key (good) but toggles
the LED (wrong).

(b) the key marked ctrl now operates as a caps-lock key (good) but does not
toggle the LED (wrong).

Package versions:

xorg-x11-server-Xorg-1.4.99.901-13.20080314.fc9.i386
control-center-2.22.0-2.fc9.i386

I think this is different to bug 12434.

[Tom Jaeger (thjaeger)]

Sebastien: Upstream does think this bug doesn't matter. Really, how hard would it be to insert the equivalent of "remove Lock = Caps_Lock" before remapping caps lock? It probably won't take much longer than insisting that this is not a gnome bug (even though it could trivially be worked around there). I'd actually be willing to familiarize myself enough with the gnome-control-center code to fix this, except that it wouldn't get in anyway, since "the option is not on by default" and therefore "not a priority for hardy".

[Tom Jaeger (thjaeger)]

Okay, so this really isn't gnome-control-center's fault. Please move the bug to libxklavier12.

[Sebastien Bacher (seb128)]

what made you change opinion?

[Tom Jaeger (thjaeger)]

I didn't really. libxklavier is the library that actually takes care of the keyboard settings, gnome-control-center is just the front-end.

[Robin Sheat (eythian)]

A curiosity related to this: alt-ctrl-F1 requires you to press the 'real' control, not the remapped one. This also didn't happen in the previous version.

[Tom Jaeger (thjaeger)]

I think I was wrong about libxklavier. I don't actually know where the changes to the keyboard settings are applied, it's probably some gconf backend, who knows? That's not the point, the point is that if I can work around the issue by typing xmodmap -e "remove Lock = Caps_Lock" before reassigning Caps Lock, then it must be trivial to fix - if you know the codepaths involved. It boggles the mind that the problem is still around 4 months after the initial report.

[mrklean (mrklean)]

Hmmmmmmm..a bug not worth fixing ?? Doesn't that sound like Microsoft
??? I thot we were different ; ((

Tom Jaeger wrote:
> I think I was wrong about libxklavier. I don't actually know where the
> changes to the keyboard settings are applied, it's probably some gconf
> backend, who knows? That's not the point, the point is that if I can
> work around the issue by typing xmodmap -e "remove Lock = Caps_Lock"
> before reassigning Caps Lock, then it must be trivial to fix - if you
> know the codepaths involved. It boggles the mind that the problem is
> still around 4 months after the initial report.
>

[KarlGoetz (kgoetz)]

On Fri, 2008-04-11 at 02:19 +0000, mrklean wrote:
> Hmmmmmmm..a bug not worth fixing ?? Doesn't that sound like Microsoft
> ??? I thot we were different ; ((

"We" are different because "we" provide the fix.

>
> Tom Jaeger wrote:
> > I think I was wrong about libxklavier. I don't actually know where the
> > changes to the keyboard settings are applied, it's probably some gconf
> > backend, who knows? That's not the point, the point is that if I can
> > work around the issue by typing xmodmap -e "remove Lock = Caps_Lock"
> > before reassigning Caps Lock, then it must be trivial to fix - if you
> > know the codepaths involved. It boggles the mind that the problem is
> > still around 4 months after the initial report.

Theres more trivial (or more important) bugs then this still open after
more then 4 months. at lest this one has someone interested in fixing
it :)
kk

> >

[Sebastien Bacher (seb128)]

the ubuntu team appreciate your concern, this behaviour is not constructive though, the distribution gets hundred bugs every week and there is a really small team working on those, there is lot of bug about hardware not working correctly, applications crashing, etc so the work has to be prioritized. You will understand that those issues get an higher priority though? There is many people not counting there hours, working late or during weekend for free and doing their best, now do you think it's fair to have those comment again them because there is too much to do and they didn't fix your specific issue yet?

[Sebastien Bacher (seb128)]

note that we don't have keyboard hackers in the team so the fix is not that obvious, I talked with the upstream maintainer who also works on xkeyboard-config and he said that the issue is an xorg server one which changed the way keyboard indicators are working and something which should be fixed there

[Tom Jaeger (thjaeger)]

What's not constructive about "I'd be willing to work on this if there was a chance for a freeze exception"?

[Sebastien Bacher (seb128)]

the comment was not meant to you but rather to the comment before the post, you are welcome to work on a patch and we will review your changes if you get something working, though the workaround might create other issues and not be a good idea

[Jay Finger (jcfinger)]

As an alternative to what MountainX described, name the file ~/.xmodmaprc. The first time that file is present at login the user will be asked if they want to load the file. There is an option to not be asked again. Check that, select the file to load, and from there on out the ~/.xmodmaprc will be loaded at login for that user.

Pro: this can be a per-user thing, not requiring screwing around with global files.

Con: since the file isn't loaded until after you log in, this means that during the login window the ctrl/capslock keys have not yet been swapped. This may be confusing depending on the users of the machine.

If using a version of gnome that doesn't automatically load the file, you could probably achieve the same effect by creating a "~/.gnomerc" that invokes "xmodmap ~/.xmodmaprc". Actually that's what I did at first, and then was pleasantly surprised when gnome recognized the file and did the right thing.

This was behavior was verified on a system running Hardy Beta that is completely up to date as I write this comment.

[Taylor Venable (taylor-metasyntax)]

I have noticed this also with swapping control and caps lock. Another workaround is to enable this option specifically in /etc/X11/xorg.conf by adding the following line to your keyboard "Device" section:

Option "XkbOptions" "ctrl:swapcaps"

This illuminates the LEDs correctly, but applies system-wide, of course.

[Trochee (trochee)]

I have this problem as well on Hardy B5, to which I upgraded this morning 27 April from Gutsy. (My system has incrementally updated since Dapper, so there *may* be cruft, but I've been pretty good about revisiting my dotfiles.

[Sebastien Bacher (seb128)]

upstream says that's an xorg issue

[Victor Zamanian (victorz)]

Just confirming this bug on Ubuntu 8.04 final.

[Robert Lange (rcl24)]

I'll throw my experience with this bug into the hat. I just upgraded from Gutsy, in which this feature worked correctly, to Hardy, in which the bug appeared. Hardy is currently up to date.

First, I reverted my Gnome keyboard preferences to the default. I tried Jay Finger's suggestion of placing MountainX's xmodmap instructions into the ~/.xmodmaprc file and letting Gnome load that file. However, while this swapped the caps lock and left ctrl keys, like the Gnome keyboard preferences option, it *failed* to correctly control the caps lock light.

Then, I deleted the ~/.xmodmaprc file and tried Taylor Venable's suggestion of altering the xorg.conf file, effectively making this a global setting for all users. When I next restarted X, at the gdm login screen I verified that the physical left ctrl key was now both activating caps lock and setting the caps lock light correctly, and that the physical caps lock key was not. So far so good... I logged into Gnome and opened a terminal. Now, pressing the physical left ctrl key toggles the caps lock light, but it still behaves as a ctrl key! Likewise, the physical caps lock key toggles caps lock, but does not alter the caps lock light!

It is important to note that at this time, there was no ~/.xmodmaprc file, and the Gnome keyboard preferences were set to *default*. Let me repeat that the Gnome *default* settings were overriding the Xorg server configuration settings! (Note: It is possible that some crufty setting in gconf or something is causing this to happen, but short of blowing away all of my dot files and directories and starting clean, I don't know how to verify this one way or the other.)

My final attempt, that succeeded in working around the problem, is the brilliant synthesis of the two previous solutions. I used the xorg.conf option *and* the ~/.xmodmaprc file. The xorg.conf setting caused X to behave correctly in gdm and caused X to show the correct caps lock light status when I logged into Gnome, while the ~/.xmodmaprc file caused Gnome to correctly swap the effects of the caps lock and left ctrl keys.

Obviously what is happening here is that a bug in the Xorg server is hard-coding the configured caps lock key to the caps lock light. However, it does seem that Gnome's settings are contradicting the behavior of the configured keyboard options in xorg.conf and substituting Gnome's idea of what the key map is.

[Robert Lange (rcl24)]

I just created a brand new account, and verified that my observations in comment 42 are still happening in a new account. That is, using the xorg.conf workaround, with all defaults for Gnome keyboard preferences and *no* ~/.xmodmaprc file, the default behavior of Gnome overrides the xorg.conf configured keyboard option, but the caps lock light respects that keyboard option.

So, this is definitely default Gnome behavior, and not cruft in one of my dot files.

[Sebastien Bacher (seb128)]

that's not a gnome-control-center bug

[Joro Todorov (gueorguitodorov)]

The permanent solution does not work for me. I have to execute the sudo xmodmap /etc/SwapCapsCtrl.kmap every time that I restart.

[David Carlton (carlton-bactrian)]

Happening to me, too; I agree that it's just cosmetic, but it's still annoying.

[Bryce Harrington (bryce)]

seb128, please explain what the xorg issue is, not just "it's an xorg issue" - we need some additional clues in what needs changed/reverted/fixed...

Also, can someone who is experiencing this problem please post their /var/log/Xorg.0.log (to get version #'s etc.)

[Sebastien Bacher (seb128)]

bryce, I don't know the detail, svu who is the libxklavier, xkeyboard-config, GNOME keyboard capplet maintainer just told me that's a known xserver issue, I'll ask him for details

[James Wenn (james-wenn)]

I'm also experiencing this issue. Currently I'm using a workaround posted above and have a permanently lit LED.

Up to date with all recent updates.

Xorg log attached.

[Joro Todorov (gueorguitodorov)]

'setxkbmap' fixes this and also keyboard layout switching Bug #196277.
 However I have to execute it every time. I tried adding 'setxkbmap' line to .bash_profile or rc.local but it didn't work. Why?

[Jesse Hallett (hallettj)]

Jodo, .bash_profile is only evaluated for bash shell sessions - so settings there won't affect other Gnome or KDE applications. And rc.local is used for system-wide settings; so it is executed as root. setxkbmap configures individual users' settings. So you need to run that command as the user you log in with.

I recommend adding an entry to your Sessions Preferences under System > Settings > Sessions. That will work for Gnome. And there are similar procedures for KDE, XFCE, and others.

[Joro Todorov (gueorguitodorov)]

 Thanks Jesse :)

[Éric Piel (pieleric)]

Same problem here with xserver 1.4.2, swaping escape and caps lock.

However, if I swap the two keys using xmodmap it works fine. Here is my xmodmap file:
remove Lock = Caps_Lock
keysym Escape = Caps_Lock
keysym Caps_Lock = Escape
add Lock = Caps_Lock

[Sergey V. Udaltsov (svu)]

*** Bug 15883 has been marked as a duplicate of this bug. ***

[Avg (avg)]

I can confirm this issue too. I can add that I directly use xkbcomp to load up my highly customized XKB configuration.
Can this bug be related to Bug 4927?

[wendall911 (wendallc)]

Fixed for me using xorg-server-1.5.0 and xf86-input-keyboard-1.3.1. Light toggles correctly and keys are switched when session starts.

Wendall

[Suckfish (suckfish)]

Now works for me also.

[Chris Jones (cmsj)]

I was seeing this on my Thinkpad X300 in Hardy, but after upgrading to test Intrepid alphas, the problem has gone away, so I believe this is fixed somehow.

[Everett Guerny (everett)]

After having been okay for a while, has this recently become a problem for anyone else, once again?

[Robin Sheat (eythian)]

Not for me, although there is a weird thing that xmodmap mappings now only apply to the keyboards that are plugged in - remap, and then plug an external keyboard and it'll behave like you never ran xmodmap on the new keyboard. Remap afterwards, and it behaves like you expect. Are you possibly seeing something along those lines?

[Paul Smith (psmith-gnu)]

All my Hardy systems still have this problem. My one Intrepid system doesn't. Please be clear what release you're using when reporting issues.

[Mark A. Hershberger (hexmode)]

Still having this issue on Hardy.

[Trochee (trochee)]

Eythian: I am also having his problem with a hotpluggable USB keyboard. This is a work laptop that I take to and from home; both locations have a USB keyboard and every time I hotplug, I am required to unset and reset (through System|Preferences|Keyboard|Layouts|Other Options...) my ctrl/caps swap and my compose-key-position setting.

I should probably file a separate bug about this.

[Everett Guerny (everett)]

[Intrepid] This was a problem for me last night on my laptop's integrated keyboard, but appears to be okay today. The fix may have come in the xkb-data package update that came this morning.

[DaveAbrahams (boostpro)]

Still a problem for me in Intrepid with an external keyboard on my laptop

[mattismyname (mattismyname)]

LinkedIn
------------

Bug,

I'd like to add you to my professional network on LinkedIn.

- Matt

Learn more:
https://www.linkedin.com/e/isd/544944457/6FqMtxez/

------------------------------------------

What is LinkedIn and why should you join?
http://learn.linkedin.com/what-is-linkedin

------
(c) 2009, LinkedIn Corporation

[otakuj462 (otakuj462)]

This bug is still present for me on my fully-updated Hardy.

Jake

[anonymous mouse (eeefafe)]

This is still an issue for me.
I'm running 8.04 (up to date) on a HP DV 1700 series laptop. When I use the GUI to swap the ctrl and caps keys, the key marked "caps lock" is still the only one that is triggering the LED. Actually, I ran the command

xmodmap -e "clear lock" -e "add lock = Caps_Lock"

as suggested above, and that has fixed it for now (yet to restart).

On another computer running 9.10 (no way am I putting that on my laptop, I'm sticking with what I *know* works), the problem does not occur. (And, previously, running, I think it was 7.10 on my laptop, it didn't occur either.)

If the xmodmap command sticks after restarting, I'll edit this. Otherwise I'll try other suggestions in the thread and comment on them too.

[anonymous mouse (eeefafe)]

It doesn't stick. But, rather than mess around with config files, I've got another work around. Put the command:
xmodmap -e "clear lock" -e "add lock = Caps_Lock"
into the sessions thingy (System-> Preferences -> Sessions -> Add, the name is whatever, the command is the one above etc.).

Also after switching through the GUI, but before running the xmodmap command, ctrl-alt-backspace has to use the 'real' ctrl key. ctrl-alt-arrow (to switch desktops) has to use the 'new' (formally caps) ctrl key.

After running the xmodmap command, the 'new' ctrl key works for everything.

[Glyph Lefkowitz (glyph)]

I am seeing this again in Lucid, with the "virtual" key LED on the Logitech DiNovo.

The workaround of using xmodmap still works, though.

[Glyph Lefkowitz (glyph)]

Correction: the workaround described above *does not* work any more. I can't figure out a way to prevent my keyboard from beeping constantly. This is really annoying :(.

[Glyph Lefkowitz (glyph)]

So, after trying every combination of options I could think of to no effect, as well as several reboots, I gave up. However, after rebooting the *keyboard itself*, the beeps are gone! So it's possible that this is a firmware bug in the keyboard and not in ubuntu. I will update if I discover anything else.

[Nat Tuck (nat-ferrus)]

Came back in 15.10

[Glyph Lefkowitz (glyph)]

Thanks for the heads up - I will definitely avoid 15.10 until this is fixed :).