VC keyboard configuration

[David Wright]

As a result of the threads "How come i wrote a NO-BREAK SPACE in
xterm+bash" and "How to disable certain keys", I'm revisiting my
own keyboard configuration, starting with the VCs.

My jessie laptop's /etc/default/keyboard contains
XKBMODEL="latitude"
XKBLAYOUT="gb"
XKBVARIANT=""
XKBOPTIONS="caps:none,compose:menu,nbsp:none,terminate:ctrl_alt_bksp"

All the XKBOPTIONS items work as expected except for nbsp:none.
I would have expected that this would make the Space bar produce an
ordinary space, "<space>", regardless of any modifiers pressed.
In fact, Ctrl-Space emits ^@ and Alt-Space emits ^[<space>

One of the things I hoped to configure is the Control key, in
particular to get Ctrl-arrows and the other Ctrl-"navigation" keys to
emit different codes from their non-Ctrl codes. Only BackSpace (of
those keys) appears to be modified (and Ctrl-Fn keys emit nothing).

An important file is /etc/console-setup/cached_UTF-8_del.kmap.gz
What I haven't worked out is: what puts this cache file together?
It's obviously been constructed because near the end it says:
# The content of this file will be appended to the keyboard layout.
followed by commented examples of changes one might make.
Where was the so-called "this file" found when this cache was
constructed?

$ man keymaps documents, I think, what I want to do, but I can't see
what file to do it on. It just says "You can then make a small local
file redefining only those modifier combinations and loading it after
the main file." However, /etc/default/keyboard only has KMAP which
has to refer to a complete replacement map. $ locate keymap and
$ locate kmap don't turn up anything obvious to me.

Cheers,
David.

[Thomas Schmitt]

Hi,

David Wright wrote:
> An important file is /etc/console-setup/cached_UTF-8_del.kmap.gz
> What I haven't worked out is: what puts this cache file together?
> It's obviously been constructed because near the end it says:
> # The content of this file will be appended to the keyboard layout.
> followed by commented examples of changes one might make.
> Where was the so-called "this file" found when this cache was
> constructed?

On Debian 8.1:

# fgrep -r 'will be appended to the keyboard layout' /etc

yields

/etc/console-setup/remap.inc:# The content of this file will be appended to the keyboard layout.

remap.inc looks like the tail of my cached_UTF-8_del.kmap.gz.

# fgrep -r 'remap.inc' /usr

/usr/bin/ckbcomp:my $file1 = "/etc/console-setup/remap.inc";
/usr/bin/ckbcomp:my $file2 = "$installdir/etc/console-setup/remap.inc";


David Wright wrote in "How come i wrote a NO-BREAK SPACE in xterm+bash ?":
> I don't want
> X's involvement, except in as much as it shares configuration files
> like /etc/default/keyboard.

I understand from man 5 keyboard that this file is part of X.
But /usr/bin/ckbcomp is a perl script which in its header
talks of "loadkeys", which is a kernel thing.


When experimenting with XKB, did you take into respect the statement
about
udevadm trigger --subsystem-match=input --action=change
in man 5 keyboard ?


Have a nice day :)

Thomas

[David Wright]

Quoting Thomas Schmitt (scdb...@gmx.net):
> David Wright wrote:
> > An important file is /etc/console-setup/cached_UTF-8_del.kmap.gz
> > What I haven't worked out is: what puts this cache file together?
> > It's obviously been constructed because near the end it says:
> > # The content of this file will be appended to the keyboard layout.
> > followed by commented examples of changes one might make.
> > Where was the so-called "this file" found when this cache was
> > constructed?
>
> On Debian 8.1:
> # fgrep -r 'will be appended to the keyboard layout' /etc
> yields
> /etc/console-setup/remap.inc:# The content of this file will be appended to the keyboard layout.
> remap.inc looks like the tail of my cached_UTF-8_del.kmap.gz.

I don't know how I missed that (maybe flaky pasting or typing)

> # fgrep -r 'remap.inc' /usr
>
> /usr/bin/ckbcomp:my $file1 = "/etc/console-setup/remap.inc";
> /usr/bin/ckbcomp:my $file2 = "$installdir/etc/console-setup/remap.inc";

I see that setupcon calls ckbcomp. So I'm assuming that the Debian Way™
is to run dpkg-reconfigure console-setup, and I see that that does do
the appending to cached_UTF-8_del.kmap.gz.

> David Wright wrote in "How come i wrote a NO-BREAK SPACE in xterm+bash ?":
> > I don't want
> > X's involvement, except in as much as it shares configuration files
> > like /etc/default/keyboard.
>
> I understand from man 5 keyboard that this file is part of X.
> But /usr/bin/ckbcomp is a perl script which in its header
> talks of "loadkeys", which is a kernel thing.

I've added the following lines to /etc/console-setup/remap.inc:

--------
# Last edited 2015-08-20
# After editing this file, run the following on a VC (making no changes):
# dpkg-reconfigure console-setup
# dpkg-reconfigure keyboard-configuration

# Ctrl-arrows do the same as PageUp/Down (for moving by word)
ctrll keycode 105 = Prior
ctrlr keycode 105 = 'z'
ctrll keycode 106 = Next
ctrlr keycode 106 = 'Hello'
#
--------

... and then run dpkg-reconfigure as in the comments. This has an
immediate effect which is rather bizarre: Alt-Left and Alt-Right
(which I use in iceweasel as GoBack and GoForward) now rotate the
display through the VCs, including X. As you know, normally you
can rotate into X but not out of it, which requires CtrlAltF{2-6}.
Note that this bizarre behaviour only happens if X was running (on
VC1) while I was dpkg-reconfiguring on VC2.

> When experimenting with XKB, did you take into respect the statement
> about
> udevadm trigger --subsystem-match=input --action=change
> in man 5 keyboard ?

No. I reboot, and that also has the benefit of eliminating the
bizarre effect above. Bear in mind that I'm not trying to make
two configurations to switch between. I going for a single stable
configuration that comes up at boot.

Anyway, something gets seriously screwed up by adding those
lines. They have no effect on either Control-. However, WindowsL-Left and
-Right no longer behave as normal (ie rotating VCs), so I have to use
Alt-. Without those lines I can use either modifier to rotate through
the VCs. But worse, the keyboard has gone american: < > left of z
(instead of \ |), \ | left of Return (instead of # ~) and so on.
Normality is restored by removing the appended lines and dpkg-reconfiguring.

The output from dumpkeys -f is very different in the two
cases. Here are the first two lines (spaces have been compacted):

With the extra lines:
keymaps 0-2,4-5,8,12
keycode 1 = Escape Escape VoidSymbol VoidSymbol VoidSymbol Meta_Escape VoidSymbol

As normal, without the extra lines:
keymaps 0-127
keycode 1 = Escape Escape Escape Escape Escape Escape Escape Escape Meta_Escape Meta_Escape Meta_Escape
Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Escape Escape Escape Escape Escape Escape Escape
Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape
Escape Escape Escape Escape Escape Escape Escape Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape
Meta_Escape Meta_Escape Meta_Escape Meta_Escape Escape Escape Escape Escape Escape Escape Escape Escape
Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Escape
Escape Escape Escape Escape Escape Escape Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape
Meta_Escape Meta_Escape Meta_Escape Meta_Escape Escape Escape Escape Escape Escape Escape Escape
Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape
Escape Escape Escape Escape Escape Escape Escape Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape
Meta_Escape Meta_Escape Meta_Escape Meta_Escape Escape Escape Escape Escape Escape Escape Escape Escape
Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape Meta_Escape
[I've wrapped that line just to be polite]

Further down the file, you can see the changes that have put the
keyboard into US-English instead of GB. I can't work out how adding
four lines can make all those undesired changes (and no desired ones).

Cheers,
David.

[Thomas Schmitt]

Hi,

in the main course of your endeavor i am overwhelmed,
i fear.

> Note that this bizarre behaviour only happens if X was running (on
> VC1) while I was dpkg-reconfiguring on VC2.

I had similar problems on a smaller scale when i
manipuladed keysyms with xmodmap and assigned meanings
to them at the level of the window manager.
There are translations and caches, which after you change
the keyboard environment do not yield the same result or
yield outdated results, repectively.

> Alt-Left and Alt-Right
> (which I use in iceweasel as GoBack and GoForward) now rotate the
> display through the VCs, including X.

I could have used such keys when my intermediate Jessie VM
came up with a Gnome desktop that offers no kind of shell
window. (Meanwhile it's a Sid with no graphics display
and only SSH access.)

> But worse, the keyboard has gone american:

Everybody should have a QWERTY and only use 7-bit ASCII.
This would promote international understanding, world peace,
and C programming.

> The output from dumpkeys -f is very different in the two

> keycode 1 = Escape Escape VoidSymbol VoidSymbol VoidSymbol Meta_Escape

> keycode 1 = Escape Escape Escape Escape Escape Escape Escape Escape

You must have deeply confused it.
Where did you get the syntax proposal of

ctrlr keycode 106 = 'Hello'

> > udevadm trigger --subsystem-match=input --action=change

> No. I reboot,

Ouch uptime.

[David Wright]

Quoting Thomas Schmitt (scdb...@gmx.net):

> > But worse, the keyboard has gone american:
>
> Everybody should have a QWERTY and only use 7-bit ASCII.
> This would promote international understanding, world peace,
> and C programming.

:)

> > The output from dumpkeys -f is very different in the two
> > keycode 1 = Escape Escape VoidSymbol VoidSymbol VoidSymbol Meta_Escape
> > keycode 1 = Escape Escape Escape Escape Escape Escape Escape Escape
>
> You must have deeply confused it.
> Where did you get the syntax proposal of
> ctrlr keycode 106 = 'Hello'

Yes, that's incorrect. I have discovered that any errors in
/etc/console-setup/remap.inc are severely punished with the
bizarre behaviour. I can only assume that the perl script
ckbcomp does not validate its input, and quite possibly has
some mistakes.

If the 'errors' are slight, then it does nothing, leaving
dumpkeys -f unchanged. So, lines like these work:

ctrll keycode 105 = F55
Control keycode 105 = F55
control keycode 105 = F55

but any one of these silently fails:

Ctrll keycode 105 = F55
Ctrlr keycode 105 = F55
ctrlr keycode 105 = F55

which is ridiculous.

> > > udevadm trigger --subsystem-match=input --action=change
> > No. I reboot,
> Ouch uptime.

Once I got *something* to change, I found it was unnecessary to reboot
all the time. I circulate the F55 numbers each time to ascertain
whether anything changes or not.

Rebooting gives you a few minutes break (to walk to another computer!)
except when I got a recurrence of my binfmt_misc problem: I now have
binfmt_misc in /etc/modules to make sure it gets loaded. This is the
first time since adding the line that
[ Cylon eye ] A start job is running for Enable support for additional
executable binary formats (9min 52s / no limit)
appeared and, as usual, I could ssh into the box, but ls -lR /proc/sys/fs
hangs and even halt -f does nothing (after saying 'Halting.').
I do now remember to umount /home before I hard reset.

Cheers,
David.