Re: VC keyboard configuration
Quoting Thomas Schmitt (scdbac...@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
Re: VC keyboard configuration
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. Have a nice day :) Thomas
Re: VC keyboard configuration
Quoting Thomas Schmitt (scdbac...@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.
Re: VC keyboard configuration
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
VC keyboard configuration
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.
