making Ctrl-Alt-Bksp work

Felix Miata mrmazda at earthlink.net
Fri May 9 03:43:08 UTC 2014


On 2014-05-08 08:43 (GMT+1000) Peter Hutterer composed:

> On Wed, May 07, 2014 at 02:38:59PM -0400, Felix Miata wrote:

>> Your (locale pt) and Reindl's (locale de) answers beg two questions:

>> 1-why do 00-keyboard.conf for pt and de contain
>> terminate:ctrl_alt_bksp, but for locale us it is absent?

>> 2-what creates 00-keyboard.conf in the first place, since it doesn't
>> get automatically recreated even by rebooting if deleted?

> systemd-localed. This file is written when you change the locale, either
> during install or later with localectl. It doesn't automatically get
> restored when you delete it.

> http://fedoraproject.org/wiki/Input_device_configuration
> lists the magic command as:
>     localectl set-x11-keymap "us" "" "" "terminate:ctrl_alt_bksp"

On a Rawhide system originally installed 6 weeks ago running in multi-user I deleted 
00-keyboard.conf, then did yum upgrade, and before rebooting the new kernel tried 
that command, with these results:

Failed to set keymap: Connection timed out
new 00-keyboard.conf not written
I had to force a reboot, as most anything I tried related to shutting down timed out.

After reboot it succeeded, but I still wonder why CAD gets enabled there at 
installation time for pt and de by not us. :-(

> which communicates the new keymap to systemd-localed, which then writes out
> the file.

> but having just tested this on F20, just running "localectl set-keymap us"
> also writes out the right configuration, including the terminate option. The
> above is needed for custom x11 keymaps, but shouldn't be needed for normal
> setup.

>> re 2: Maybe your two installations have 00-keyboard.conf carried
>> over from before xorg-x11-drv-keyboard was superceded by
>> xorg-x11-drv-evdev, which on (re)installation does not create it if
>> it does not exist?

> neither the keyboard nor the evdev driver have anything to do with it. the
> retirement of the keyboard driver should have no effect on anything newer
> than, say, Fedora 12.

> Zapping in the server works as a two-stage process. A key combination is
> interpreted by a XKB as a Terminate_Server action. The server then
> interprets that and terminates. With DontZap you only control the
> second part, i.e. whether the server terminates when the action is triggered.
> If you don't have the XKB setting, you can't trigger it in the first place.
> And DontZap is only useful if you want to _prohibit_ zapping completely. It
> just makes Terminate_Server do nothing.

> For your use-case, forget about DontZap, it has no effect. I'm the
> maintainer for these parts of the server, so regardless of how many
> configurations you find that tell you to enable it, please trust my word
> here. You need to get the terminate XKB option into your keymap, that's all
> that matters.

FWIW, on one F21 system with radeon video here even a normal exit from a startx KDE 
session is leaving the screen on the tty started from black. A shift to a tty and 
back then draws what had been expected. I've tried on 6+ other installations, one 
with radeon, and all the others behave as expected.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/


More information about the devel mailing list