Description of problem: I just wasted a half an hour screwing around with yahoo/google passwords because I didn't notice that the capslock key had reverted to capslock instead of my resetting it to ctrl via setxkbmap -option ctrl:nocaps I am NOT very happy right now. Version-Release number of selected component (if applicable): setxkbmap-1.3.4-5.fc42.x86_64 How reproducible: Problem appears randomly Steps to Reproduce: 1.unknown 2. 3. Actual results: unexpected chaos Expected results: a DEPENDABLE result Additional info: This problem has just appeared in the FEDORA 42 system in the past 2-3 months.
setxkbmap is a one-shot command and doesn't really persist as such. Which means *something* is overwriting your settings after you run setxkbmap and the most likely candidate for this is your desktop environment. And the most likely case is that you suspended and on resume all keyboards got resumed with the desktop-configured keymap. Please reassign to the compositor of your current desktop environment (mutter or kwin, most likely). From an architectural point POV setxkbmap is like running `echo foo > bar` and hoping that nothing else ever writes in to bar. That may be the case but it's been prone to be overwritten for about 20y now (ever since we added device hotplugging to the X server).
Peter, Thanks for your response. More info: I NEVER use suspend or hibernate. My desktop manager is Windowmaker which I've been using for several years now since KDE was unstable at times. I just recently started having this problem... so your 20y info doesn't seem to apply here. This problem happens frequently while I'm ACTIVELY using the system/gui. Where is "bar" located? More details needed please? Regards, George...
the foo/bar example was just for an analogy, setxkbmap is equivalent to writing to a specific (well-known) file and hoping no-one else does so after you do it. That works but but fails as soon as something else updates that then writes to the file. I don't have any good debugging advice here, these cases are almost always some client updating the keyboard but finding out which one (if it's not the usual settings panels) is difficult.
Peter, In my travels I seem to have heard of a command to monitor a file for modification... I'm looking for the command now but I think I have solved the problem with an X11 config file "/etc/X11/xorg.conf.d/00-keyboard.conf"... by adding this line to the file it seems to work well so far: Option "XkbOptions" "ctrl:nocaps" Let's go ahead and close this bug report... I'll repost if I find more info. Thanks for your help, George...