You are not logged in.
I have been tinkering... yes, "don't do that", I know. Anyway, I had changed four files in /usr/share/X11/xkb/: symbols/dk and rules/{base,evdev}.xml. It was/is an experiment to add mathbold Unicode letters to the keys using an extra keyboard variant, and use the Windows key to activate the variant when held down. Worked fine too.
However, after a reboot, both the console and XFCE keyboard seem stuck as US even if the Keyboard Settings show DA (Danish). So now I am debugging this problem. While doing so, I noticed an error message at boot time. From /var/log/boot:
Setting up keyboard layout...too many (144) entries on one line
However this seems to have happened on previous reboots as well, so it is probably unrelated to my tinkering. It may be worth looking into anyway, perhaps.
I don't know why setting up the console keyboard need to be so convoluted, but anyway, AFAICT, it does the following:
/etc/init.d/keyboard-setup # is run by init, obviously. It then runs (if given start or similar arguments)
/lib/console-setup/keyboard-setup.sh # which either checks if a cached command exists
/etc/console-setup/cached_setup_keyboard.sh # which it then runs, otherwise it does setupcon -k
The /etc/console-setup/cached_setup_keyboard.sh script checks if /run/console-setup/keymap_loaded exists, deletes it and exits if it does, or if it doesn't it runs kbd_mode '-u' /dev/ttyn on tty1 to tty6. After that it loads a cached keyboard map with the command:
loadkeys '/etc/console-setup/cached_UTF-8_del.kmap.gz' > '/dev/null'
This file looks very strange, with loads of repetition, which I find hard to believe can be quite right.
Looking at a different machine (eldo), which has roughly the same config, but hasn't been tinkered, I just did a dumpkeys and compared it with a dump on this machine (xan).
$ diff xan_kmapdumped eldo_kmapdumped
3,4c3,4
< number of keymaps in actual use: 7
< of which 0 dynamically allocated
---
> number of keymaps in actual use: 128
> of which 121 dynamically allocated
something isn't right, I guess. Next, I'll be comparing the cached files on both machines, and see what's going on.
Now this is what I don't get: I can't find any documentation that says loadkeys will accept a gzipped keymap file, and looking at the source files does not seem to support this either. At this point I don't know what's going on anymore; my investigation in the main problem (with my tinkering) will probably take priority. But if anyone can point to a good explanation of how all this keyboard initialisation at boot works, it would be appreciated. I know this is most likely unrelated to the problem I caused by my tinkering, which I am aware that I have to debug in the context of X11/XFCE4 instead. However, the error message caught my eye, and made me curious.
Oh, and if you think I should be punished for my silly tinkering, I can assure you that typing this with a Danish physical keyboard and a US layout was not pleasant. ;-)
Offline
Oh, a little general information, so people don't need to ask :"what version of...?"
uname -a ; cat /etc/os-release /etc/debian_version
Linux xanadu 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
PRETTY_NAME="Devuan GNU/Linux 4 (chimaera)"
NAME="Devuan GNU/Linux"
VERSION_ID="4"
VERSION="4 (chimaera)"
VERSION_CODENAME="chimaera"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"
11.1
Offline
Ah, it's so ๐ง๐ข๐๐ to have my mathbold Unicode letters back. Turned out there was a typo in my symbols file. Mea culpa.
However, the system has regenerated the /etc/console-setup/cached_* files, and the new cached_UTF-8_del.kmap.gz still causes loadkeys to hiccup with "too many (144) entries on one line", and switching from X to a console with Ctrl-alt-F5 I can see that the console is not using Danish keyboard layout. I believe it used to. Just checked on other machine, and sure enough it does have the Danish keyboard set for the Ctrl-Alt-F5 console on tty5.
So now I would like to look at how the cached_UTF-8_del.kmap.gz file is generated, and why TF it gets to be malformed. (It might still be related to my tinkering, of course.) If anyone can shed some more light on this, I'd be thankful, meanwhile I guess I'll cook a little Perl script to find the offending line with too many entries.
Offline
Wow. Sometimes doing silly things pays off. Like wanting to type LWinKey-"a" and get an ๐.
Now, mathbold lowercase "a" ("๐") is code point U+1D41A. It seems loadkeys (from kbd-utils project) does not like that. The Devuan kbd is version 2.3.0-3.
lhp@xanadu:~/sandbox/kbd$ apt list --installed|grep kbd
kbd/stable,now 2.3.0-3 amd64 [installed]
I checked out kbd from https://github.com/legionus/kbd and compiled it.
The Devuan loadkeys gives this message:
lhp@xanadu:~/sandbox/kbd$ sudo loadkeys -v -C /dev/tty5 ~/cached_UTF-8_del.kmap
Loading /home/lhp/cached_UTF-8_del.kmap
too many (144) entries on one line
The presumably most recent version I built from source gives:
lhp@xanadu:~/sandbox/kbd$ sudo src/loadkeys -v -C /dev/tty5 ~/cached_UTF-8_del.kmap
Loading /home/lhp/cached_UTF-8_del.kmap
unicode keysym out of range: U+1d42a
syntax error, unexpected ERROR, expecting NUMBER or LITERAL or UNUMBER
So it was my silly tinkering, after all, that messed things up. (I'd argue that it should be possible to type any Unicode code point, but that's not for me to decide. I guess I'll write a suggestion for the kbd project though.)
Offline