| View previous topic :: View next topic |
| Author |
Message |
lifeless
n00b
Joined: 31 Aug 2004
Posts: 43
|
 Posted: Tue Mar 28, 2006 11:25 am Post subject: POSSIBLE FIX: xkbcomp error about ONE_LEVEL and <RALT> |
 |
|
It seems that a good number of people have encountered this error during X startup:
| Code: | The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
> Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server |
It's mostly cosmetic, but in the process of methodically eliminating X errors, I thought I'd give this one a go as well. I think I've succeeded, but the solution might be somewhat specific to just some subset of users, depending on what sort of setups people are running. I'm running Xorg 7.0 on a PPC, with a Logitech Cordless Desktop Pro, using the Finnish keyboard layout.
Anyway. After a bit of googling and forum browsing, I couldn't find a simple solution to the problem. (Side note: searching web forums is sucky. When a search result points to some non-specific place inside a 37-page thread, head meets table.)
This took me on a journey through xkb internals, and I'm a lot wiser for it now. I'll be somewhat verbose here in outlining the discovery process to increase the understanding of other n00bs like myself, instead of just providing an "edit file X replacing Y with Z" solution.
My keyboard config inside xorg.conf looks like this:
| Code: | Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "logicdp" # Logitech Cordless Desktop Pro
Option "XkbLayout" "fi"
EndSection |
In figuring out what the config should contain, I spent a lot of time inside /usr/share/X11/xkb/symbols, which is the most crucial directory for our purposes. cd there now and look around :-).
After a bit of browsing, I ran into the setxkbmap tool for changing X keymaps on the fly from an xterm. Its -print option was most helpful in diagnosing the issue.
Running setxkbmap -print on my setup returns this:
| Code: | xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc(pc105)+fi+inet(logicdp)" };
xkb_geometry { include "pc(pc104)" };
}; |
When I startx'd with this config, the error message was printed to the terminal I ran the command in (checked it out with ctrl+alt+f1). I then began going through various other layouts and options with setxkbmap to find out what combinations return or don't return the error.
What happens without the -print option is that the code above, produced by setxkbmap, is automatically fed to xkbcomp, the keymap compiler, producing a compiled version of the keymap to be inserted into the running X. All the xkb_(whatevers) in the setxkbmap output are directories inside /usr/share/X11/xkb, and the (optionally plus-delimited) include parameters are files inside those directories. The stuff inside parentheses are sections inside those files. lessing about said files is a good way to see what sort of stuff gets fed to xkbcomp.
After trial and error and the process of elimination, the culprit seemed to be connected to the file level3 inside the symbols directory. When level3 is included into the config as a command-line option or as an include in some other definition file (symbols/fi in my case), the default behaviour is to process the ralt_switch section. It looks like this:
| Code: | default partial modifier_keys
xkb_symbols "ralt_switch" {
key <RALT> {
type[Group1]="ONE_LEVEL",
symbols[Group1] = [ ISO_Level3_Shift ]
};
modifier_map Mod5 { ISO_Level3_Shift };
}; |
I can't claim to intimately understand the concepts and terminology involved, even after skimming through xkb documentation at xfree86.org, but the point is that inside level3, RALT is defined with a ONE_LEVEL key type. It can only contain one symbol. The definition from http://www.xfree86.org/current/XKB-Enhancing4.html is:
| Quote: | | The key does not depend on any modifiers. The symbol from first level is always chosen. |
Other alternatives would be TWO_LEVEL, PC_SYSRQ and many more. If RALT was defined with a key type that would permit more than one "level", it could have many "columns", separated with commas, something like:
| Code: | | symbols[Group1] = [ ISO_Level3_Shift, Alt_R, Meta_R ] |
Comparing this with the one above, it appears that the RALT section inside level3 is perfectly valid, having just one symbol as its key type dictates. So where is the error coming from?
Look at setxkbmap -print again. All the definition files included there can include an arbitrary amount of other definition files, which can do the same, creating a chain of includes that may be a bit hard to follow.
After a bit of grepping inside the symbols directory, I saw that the pc file contained several RALT definitions inside several sections. The file (section pc105, specifically) is included by setxkbmap. I started examining it, starting from the pc105 section. That section includes the pc104 section, and... waaait a second. This is what it looks like:
| Code: | default
xkb_symbols "pc104" {
include "pc(basic)"
key <LALT> { [ Alt_L, Meta_L ] };
key <RALT> { [ Alt_R, Meta_R ] };
key <LWIN> { [ Super_L ] };
key <RWIN> { [ Super_R ] };
key <MENU> { [ Menu ] };
}; |
TWO columns for both RALT and LALT, even though level3 defines them both as being of the key type ONE_LEVEL.
I made a backup copy of pc and edited the RALT line, removing the comma and Meta_R, leaving just the Alt_R symbol (which gets overridden by the ralt_switch section of level3 later). Restarted X, and... the error was gone! Everything worked, the keys output what they were supposed to.
Now here's why I call it a "possible" fix. While it works for me, for my keyboard layout and my hardware, I can't guarantee that it would work in all the circumstances and setxkbmap include chains that may produce the error. Proceed with caution and make backups. I don't know what side effects the fix might have.
Also, this may not be the best or even the only way to correct this problem. For layouts that don't include the ralt_switch bit from level3, and the ONE_LEVEL definition with it, seem to work just fine. setxkbmap us -option "", for example, seems to work without producing the error, IIRC. Someone correct me if I'm wrong, but it seems that without an explicit key type definition, you can assign an arbitrary amount of symbol columns to each key (at least within some predefined boundaries). At least the two-symbol versions of RALT and LALT work error-free when level3 isn't included. And yes, you get the same error using lv3:lalt_switch and lv3:alt_switch instead of lv3:ralt_switch, if you don't modify the pc file, since LALT is also ONE_LEVEL in level3, but has two symbols inside pc. lwin, rwin and menu work without errors, having just one symbol everywhere.
What I don't get is this: since RALT with ONE_LEVEL in level3 overrides RALT without a key type in pc, why does xkbcomp complain about the two-symbol Alt_R, Meta_R bit in pc being in conflict with the ONE_LEVEL key type in level3, even though level3 has just the one ISO_Level3_Shift symbol? Is this a bug/feature in the way xkbcomp parses the include chain?
To investigate, I looked at what xkbcomp would return with a really verbose -w parameter. I reverted pc to its original form and ran the following command: setxkbmap fi -print | xkbcomp - -w 10 -xkb > /tmp/foo 2>&1 (for some reason, the command didn't work if I was inside /usr/share/X11/xkb/symbols, a chdir helped). Here's a relevant snip from the redirected output in /tmp/foo:
| Code: | Warning: Multiple symbols for level 1/group 1 on key <RALT>
Using ISO_Level3_Shift, ignoring Alt_R
Warning: Symbol map for key <RALT> redefined
Using last definition for conflicting fields
Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
Ignoring extra symbols |
Only the last warning is output when X starts. So, Alt_R is there, no mention of Meta_R. Why this happens instead of just the ISO_Level3_Shift being evaluated against ONE_LEVEL (which would make sense to me), I don't know.
Any further insights and improved fixes are most welcome. |
|
| Back to top |
|
 |
ecatmur
Advocate
Joined: 20 Oct 2003
Posts: 3595
Location: Edinburgh
|
| Posted: Tue Mar 28, 2006 2:38 pm Post subject: |
|
|
Hey, that's useful - thanks for a great writeup!
Another possible fix is to edit /usr/share/X11/xkb/symbols/level3 and keep <RALT> as TWO_LEVEL. The only question then is what to put as the second keysym - either put another ISO_Level3_Shift, or alternatively put Multi_Key so Shift+AltGr becomes a Compose key.
_________________
No more cruft
dep: Revdeps that work
Using command-line ACCEPT_KEYWORDS? |
|
| Back to top |
|
|
Marx
n00b
Joined: 07 Dec 2004
Posts: 19
Location: Sweden
|
| Posted: Sat Jun 24, 2006 7:01 pm Post subject: |
|
|
Had exactly the same problem, Thanks alot for the "Possible Fix"! 
I was getting somewhat annoyed with that one. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
