Created attachment 703940 [details] Xorg.0.log after server restart, with ctrl:swapcaps ignored/nonfunctional Description of problem: During startup, the X server appears to ignore a config file I dropped into /etc/X11/xorg.conf.d/ Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.13.2-4.fc18.x86_64 How reproducible: To cause a system-wide swap of the ctrl and capslock keys, I created a file named /etc/X11/xorg.conf.d/01-swapcaps.conf, with the following content: # swap ctrl and caps (GLS): Section "InputClass" Identifier "anaconda-keyboard" MatchIsKeyboard "on" Option "XkbOptions" "ctrl:swapcaps" EndSection I made sure all ownership and permissions (including the selinux attributes) are identical to the 00-anaconda-keyboard.conf file created automatically during install (and whose contents is shown below for completeness): #This file was generated by the Anaconda installer Section "InputClass" Identifier "anaconda-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "us" EndSection When starting the X server (e.g. after booting up, or after each logout, or changing between runlevels 3 and 5), the ctrl:swapcaps is ignored by the X server. Steps to Reproduce: 1. drop file 01-swapcaps.conf as shown above into /etc/X11/xorg.conf.d/ directory 2. restart X server 3. hit left control and capslock keys to check for desired behavior Actual results: Left-Ctrl and CapsLock keys are not swapped. Expected results: Left-Ctrl and Capslock keys should be swapped. Additional info: Interestingly enough, on one of several Fedora 18 machines I use (MacPro5,1), unplugging the USB keyboard and plugging it back in results in the swapcaps option starting to work. On another machine (Dell Optiplex 740), unplugging and reconnecting the keyboard does not seem to help at all. Including Xorg.0.log after X server initially started, and additional log entries occurring after unplugging/reconnecting the keyboard on the MacPro5,1, which gets swapcaps working.
Created attachment 703941 [details] additional Xorg.0.log entries after unplugging/reconnecting USB keyboard; ctrl:swapcaps now functional
From the original log: [ 17.182] (II) config/udev: Adding input device Dell Dell USB Keyboard (/dev/input/event2) [ 17.182] (**) Dell Dell USB Keyboard: Applying InputClass "evdev keyboard catchall" [ 17.182] (**) Dell Dell USB Keyboard: Applying InputClass "anaconda-keyboard" [ 17.182] (**) Dell Dell USB Keyboard: Applying InputClass "anaconda-keyboard" [ 17.182] (II) Using input driver 'evdev' for 'Dell Dell USB Keyboard' ... [ 17.183] (**) Option "xkb_rules" "evdev" [ 17.183] (**) Option "xkb_model" "evdev" [ 17.183] (**) Option "xkb_layout" "us" [ 17.183] (**) Option "xkb_options" "ctrl:swapcaps" so it appears the input class is detected and applied. what desktop evironment do you use and is there the possibility of it overwriting the layout?
The swapcaps option is ignored (by GDM) before I even log into any desktop session. GNOME continues to ignore swapcaps once I log into it. On my Mac, I normally use the wmx window manager, and after logging into wmx -- that is the only time when unplugging+reconnecting the USB keyboard gets swapcaps to start working. I was using vanilla GDM+GNOME on my other machine, and when I stick with that, no amount of plugging/unplugging the keyboard makes any difference. Is it possible that GNOME (GDM + GNOME shell) overwrite/ignore the xorg.conf setup ?
yep, that's the case. use gsettings to set xkb options that aren't available through the GUI. gsettings set org.gnome.desktop.input-sources xkb-options "['compose:caps', 'terminate:ctrl_alt_bksp']"
so I tried to run this (as root, logged in remotely) on one of the machines in question: gsettings set org.gnome.desktop.input-sources xkb-options "['compose:caps']" I get back this error: ** (process:790): WARNING **: failed to commit changes to dconf: Error spawning command line `dbus-launch --autolaunch=c1bac1d9d5b4454582b61b7b9e33b73c --binary-syntax --close-stderr': Child process exited with code 1 Would it be worth reassigning this bug to gnome, which isn't being very nice when it blatantly ignores the underlying xorg.conf settings and does whatever it wants on top of that :)
Actually, switching (back) to lightdm (and continuing to use something other than a GNOME session) fixed my problem. This is clearly not an xorg-x11-server problem, so I'm going to close this as NOTABUG. The fact that GNOME ignores/overrides xorg.conf setting is a debate that should happen between GNOME users and GNOME developers, of which I am neither :) Thanks again --Gabriel
fwiw, running this command as root was your mistake. if you run it at user it should work, since gsettings configures your user-specific settings. still, that won't fix the gdm issue though...
maybe su gdm -c 'gsettings...' ? But yeah, I wanted one spot to make the change system-wide, for all users, under all window managers (well, except GNOME, as it turns out :P), which is why I went for xorg.conf.d/...