Talk:Xorg/Keyboard configuration

From ArchWiki
Jump to navigation Jump to search

Making Shift+numkeys work like on Windows

I needed Shift+NumHome (numkey 7) to work like Shift+Home and select the text... but with NumLock off it would just type out '7' The solution was either turn on numlock temporarily then Shift+Num7 or make it work like in Windows where Shift key doesn't act like a temporary numlock toggler:

setxkbmap -option "numpad:microsoft"

EmanueLczirai (talk) 19:14, 24 July 2014 (UTC)

xorg.conf.d fails

Wanted to add the following under "Using X configuration files"

Warning: If you use GDM, use localectl.

Due to a bug of gdm 3.14+ on systemd systems described here, gdm does not read the 10-keyboard.conf before it starts up.

I tried using xorg.conf.d files for keyboard and it did not work. I found the linked solution / bug description. I wanted to share that with the community by adding a warning. Not it was removed. Why?

--Denoyse (talk) 11:30, 29 May 2015 (UTC)

1. It would be better to link to an upstream report 2. localectl creates those same *.conf files in xorg.conf.d (besides /etc/vconsole.conf for TTY use), so the cause it not clear from the warning alone. -- Alad (talk) 12:26, 29 May 2015 (UTC)
2. I don't have an explanation either. But the bug is also described here for Arch. --Denoyse (talk) 12:44, 5 June 2015 (UTC)

Configuring compose keys

This section suggests to copy a default combination file to .XCompose. Wouldn't it be cleaner to use an instruction like include "%L" or include "/path/to/specific/locale/compose"? --Lysxia (talk) 17:35, 3 February 2017 (UTC)

I don't know if it would be cleaner. I assume Lysxia reffers to Keyboard configuration in Xorg#Key combinations. Perhaps he would like to edit his post, add the link, and remove my post. Regid (talk) 07:35, 14 March 2017 (UTC)

Make switched keyboard layout persists across applications

I set grp:rctrl_rshift_toggle with setxkbmap in my .xinitrc. After I switched my keyboard layout and move the focus to another application. I found out that the layout is automatically switched to the first keyboard layout but now that I know alpine does this differently where the keyboard layout persists across applications. Is there anyway where I can make behave like alpine linux? Pickfire (talk) 06:59, 26 May 2017 (UTC)

Looks like this has something to do with Fcitx, maybe mentioning it would be nice? Pickfire (talk) 14:57, 13 October 2017 (UTC)

Mention keyboard layout switch shortcut bug

There is annoying, very old x server bug. It makes unusable a lot of shortcuts if you switch keyboard via windows kb shortcuts (alt+shift or ctrl+shift). Currently there is no aur repo for this, there is a patch in a bug tracker which is applied by ubuntu for several years. Yanpas (talk) 22:52, 12 October 2017 (UTC)

The fact that other distributions patch some bug is irrelevant. You should pester upstream to actually fix the bug. -- Lahwaacz (talk) 13:43, 14 October 2017 (UTC)

Persisting layout when USB keyboard connected

"This section needs expanding" suggests discussing here. Is there a consensus for how to set a layout that should persist for laptop keyboard and when external is connected. Using `setxkbmap` in my `.xinitrc` does not persist when usb keyboards are connected (though they are in TTY). Creating an X11 config file does do the job —This unsigned comment is by Theowl (talk) 11:18, 1 June 2018 (UTC). Please sign your posts with ~~~~!

Not sure about consensus, but due to the way input handling has changed in X, just running `setxkbmap` once might not be sufficient and configuration has to be reapplied when devices change. Usually this is handled by the desktop environment. Here is a blog post written by X input developer Peter Hutterer about the issue. If you don't run a DE, there are a few solutions out there, though I haven't tested them myself: xplugd, xinputd Wlhlm (talk) 21:29, 26 August 2018 (UTC)

Key mapping methods not compatible with MATE

I'm running MATE desktop with lightdm, and the only way I discovered to map keys (in my case, mapping capslock to ctrl) was to use the graphical Keyboard app in Control Center, which appears to override the other methods described in this wiki. That's "Control Center > Keyboard > Layouts > Options... > Ctrl Position".

Here's what I experienced using the other methods:

localectl set-x11-map localectl set-x11-keymap "us" "pc105+inet" "" "ctrl:nocaps"

This has no effect. It creates an xorg conf file at /etc/X11/xorg.conf.d/00-keyboard.conf and potentially another file for the console at /etc/vconsole.conf, but they don't do anything.

setxkbmap -option ctrl:nocaps

This actually does work if you do it manually, but it reverts on suspend or reboot. Putting it in ~/.xprofile doesn't set the option on startup like you would expect.

gsettings set org.gnome.desktop.input-sources xkb-options "['ctrl:nocaps']"

Also doesn't do anything. I haven't looked into what MATE's Keyboard app is doing under the hood, but I thought this was still worth mentioning. Kvnvallis (talk) 00:08, 16 November 2019 (UTC)

It is already mentioned at the top of the page:
Note: XKB options can be overridden by the tools provided by some desktop environments such as GNOME and KDE.
-- Lahwaacz (talk) 07:45, 16 November 2019 (UTC)
Yea you're right, this page is fine, it's the MATE page that needs updating. I couldn't find a gsettings command that worked for switching caps with ctrl, so I ended up following the only available instructions on the arch wiki (for xorg). Here's where mate actually stores keyboard options in dconf:
$ gsettings get org.mate.peripherals-keyboard-xkb.kbd options
['Compose key\tcompose:lwin', 'ctrl\tctrl:nocaps']
-- Kvnvallis (talk) 10:49, 16 November 2019 (UTC)