Recently I've noticed my Scroll-Lock key was not working under X. I needed it to stop screen updates in monitoring programs like top
or htop
. It was working perfectly under the standard virtual consoles and judging by this post, it probably worked with konsole
with versions of KDE older than 4. So I started digging to see what was going on.
At first it seemed the Scroll-Lock key was not picked at all. I was used to its light being toggled each time I pressed it. But may be some time around the upgrade to KDE4 I noticed the light being used to display the usage of alternate keymap ( EN and BG in my case ). So I did not trust the lamp and looked whether the key was actually reporting any key presses. First I looked at various console key dumpers with no great success under X and then discovered the xev
program (part of x11-utils
in Debian). Running xev
showed me the key was working perfectly fine. So what was wrong ? Why did top
ignored it under X and picked it up under the vconsoles ? I thought that the key was actually being handled by the ncurses
library. So something must have stood in the way. Did konsole
or KDE
caught it before being send to ncurses
? In order to eliminate konsole
and KDE
I've started the Xserver without window manager with only xterm
running ( ran xinit
). The behavior was the same under xterm
. And xev
would not have been able to catch it if this was the case. I was not that sure ncurses
handled the key anymore and started looking elsewhere. It appeared my expected Scroll-Lock behavior was a feature of the Linux vconsoles and handled by their in-kernel code.
So no Scroll-Lock for the terminal emulators under X. Anyway, Ctrl+S
(stop scrolling) and Ctrl+Q
(resume it) work just fine so no real need for Scroll-Lock. Sure Scroll-Lock could be mapped to do the job, but this would be a custom solution and getting used to it would not be of much use across machines I don't maintain.
While I was at the keyboard stuff I decided to look at other related things that interested me. One of them was writing letters with accents. In my native language this is often necessary since there are words/conjunctions with the same spelling and the accent is the only way to distinguish them. E.g.
па̀ра / пара̀
Note that in order to see letters with accents your screen font should also support it.
When I searched the web I first found solutions with custom keymap definitions. I've looked at them, and they were supposed to either replace or complement the definitions in /usr/share/X11/xkb/symbols/
( part of xkb-data
in Debian ). Looking at the default definitions supplied with xkb-data
revealed that the "Bulgaria - Traditional phonetic" mapping I used already had what I needed. The accents were mapped to the "/" (slash) key in Level3. So e.g. writing an "а̀" was just a matter of typing "а" followed by RAlt+/
. The Right alt
key was mapped to the so called ISO_Level3_Shift .
The U0300 unicode symbol is representing ACUTE accent. This is the kind of accent that is used in the Bulgarian language. There is also a mirror variant of the accent - GRAVE accent. It is represented by the U0301 unicode symbol. Here is an example:
а̀ѐѝо̀у̀ъ̀ю̀я̀
а́е́и́о́у́ъ́ю́я́
See the references section near the end of document for the full list of unicode symbol tables.
Just to clarify things for those of you who do not know about the different levels:
key
typed aloneShift+key
RAlt+key
(assuming your Level3 modifier is RAlt)RAlt+Shift+key
A useful command to get your current key mappings is xmodmap
. E.g.
xmodmap
xmodmap -pke
On the desktop in the office I use the following keyboard configuration:
setxkbmap -model pc104 -layout us,bg -variant altgr-intl,phonetic
executed via KDE's "System settings"->"Personal"->"Regional & Language"->"Keyboard layout".
In order to get a visual representation of the keys in the the different levels and groups the xkbprint
command could be used.
In my case I have two different groups (us and bg) and each of them has four different levels. By default the xkbprint
command prints 2 levels - the one specified by the -ll
parameter (or 1 if it is missing) and the next one.
xkbprint -eps -color -lg 1 -ll 1 -lc en_US -nokc $DISPLAY -o xkbprint-lg1_ll1.eps
This command produces a postscript file which I have cropped below:
When the symbols in the two levels are the same only one symbol is printed on a key (I guess xkbprint
does not makes a difference between lower and upper case letter). When there is a difference the symbol for level 1 is printed on the bottom part of the key and the one from level 2 on the upper part.
Let us see levels 3 and 4 in the US group too:
xkbprint -eps -color -lg 1 -ll 3 -lc en_US -nokc $DISPLAY -o xkbprint-lg1_ll3.eps
Remember that level 3 is when you hold ISO_Level3_Shift ( RAlt by default ), and level 4 is when you hold ISO_Level3_Shift + Shift. The merged labels in the image above are:
9
and 0
in level 3So what we see is that we have access to various special chars that might have ever been a key or a two away from you without you ever knowing it.
Let us also see the other group that I have configured.
xkbprint -eps -color -lg 2 -ll 1 -lc en_US -nokc $DISPLAY -o xkbprint-lg2_ll1.eps
Unfortunately I did not find an easy way to print the symbols in the BG group via xkbprint
. Their names are showed instead. These names are defined in the /usr/include/X11/keysymdef.h
file, which is included in x11proto-core-dev
.
And here go levels 3 and 4 in the BG group:
xkbprint -eps -color -lg 2 -ll 3 -lc en_US -nokc $DISPLAY -o xkbprint-lg2_ll3.eps
Note that I have cropped the images above, in order them to be readable on normal screens. You can execute the specified commands yourself and take a look at the PostScript files directly to get the rest of the picture.
The characters which names are showed as U0XXX, where X
is any hexadecimal digit, represent a Unicode symbol.
References: