For quite a few years now, starting the X server has presented me with the warning: === 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 === My settings are === Section "InputClass" Identifier "evdev keyboard catchall" MatchIsKeyboard "on" MatchDevicePath "/dev/input/event*" Driver "evdev" Option "XkbModel" "pc104" Option "XkbLayout" "us" Option "XkbVariant" "euro" Option "XkbOptions" "compose:rctrl" EndSection === and the current version of xkeyboard-config is 2.7 (on arch linux). The "euro" variant was introduced around 2007 (at my own instigation by the way -- Dutch computer-users use us keyboards, with just the additional euro-sign on Altgr-E or Altgr-5, and for those of use who can't stand the dead keys of us-international, this is the preferred layout) and at the time this warning was also present but was back then "promised" to be fixed shortly. I've been looking at the warning for 5 years now though... :-/ Google indicates that I'm also not particularly the only one, and not all of them using this specific variant. Could this be fixed somehow? If really need be perhaps by simply just not having xkbcomp complain, if this is somehow a valid setup? Or otherwise by fixing the layouts?
I appreciate your attention to an innocent warning :) The type ONE_LEVEL has 1 level indeed. RALT has 1 level (see symbols/level3): xkb_symbols "ralt_switch" { key <RALT> { type[Group1]="ONE_LEVEL", symbols[Group1] = [ ISO_Level3_Shift ] }; modifier_map Mod5 { ISO_Level3_Shift }; }; So this looks like an issue with xkbcomp
It's digging through all sorts of these "innocent" warnings to get to the possibly non-innocent ones that's driving said attention :) Thanks for (re-)assigning.
No comments though, so, is anyone actually reading this or have I simply been re-assigned to the dustbin?
Figures. I mean, really, X11 and QA? Hahahaha. What was I thinking...
the warning is still there with openSUSE12.3 running with, <2013Mar24><02:18><~> uname -a Linux kernel 3.8.3-1-desktop #1 SMP PREEMPT Fri Mar 15 08:16:33 UTC 2013 (1ca6928) x86_64 GNU/Linux have not noticed any ill effects assumption: its innocent, hence its ignored
Hmm, interesting stupid little bug. The warning only gets given with the left and right Alt keys, not with the Win keys, nor the Menu key, nor the right Ctrl key (the left one is not assignable as third-level chooser). Looking at the differences between the .xkb files that xkbcomp can produce after choosing sequentially <LALT>, <RALT>, <LWIN>, <RWIN>, <RCTL>, and <COMP> as the third-level chooser, it dawned upon me what the trigger is. The last four keys only ever get one symbol assigned (even though their type is nothing at all, not ONE_LEVEL), but the left Alt and the right Alt key each get two symbols assigned (Alt_L/R, and Meta_L/R on the shift level) before they get redefined as a one-level key that chooses the third level. Somehow xkbcomp still sees that second symbol when it processes the one-level assignment. It should wipe the key before doing any new assignments -- I've tried with "replace" and with "override", but those didn't work. What *does* work is simply delete in the /usr/share/X11/xkb/symbols/altwin file the assignment of Meta_R to <RALT> (the one at the beginning, in xkb_symbols "meta_alt", does it for me). Then the warning does not show any more. It is not the solution, of course, but it's nice to have a workaround. What also helped me figuring out where the problem lies, was observing the output of these: $ setxkbmap -print | xkbcomp -w 1 - $DISPLAY Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols Ignoring extra symbols $ setxkbmap -print | xkbcomp -w 1 -xkb - thekeymap Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols Ignoring extra symbols $ xkbcomp -w 1 thekeymap $DISPLAY The actual keymap does not produce the warning, it is in the extensive and overlapping data that setxkbmap provides that the problem was hiding.
Created attachment 86226 [details] [review] silences the one-level warning by properly reducing the number of levels Attached patch fixes the warning for me, without affecting the resultant in any way. Please test, if you can.
Created attachment 86805 [details] [review] silences the one-level warning by properly reducing the number of levels This version of the patch looks more invasive, but it mainly swaps some lines around in order to make the logic of the modified if statement clearer.
this warning no longer occurs with :- Kernel: 3.11.2-1.g4c1fc5a-desktop x86_64 Desktop: KDE 4.11.2 Distro: openSUSE 13.1 Beta 1 x86_64 (so patch not needed)
(In reply to comment #9) > this warning no longer occurs with :- > Distro: openSUSE 13.1 Beta 1 x86_64 Interesting. Can you give me a URL of the xkbcomp RPM package that goes into openSuse 13.1 beta? I can't find it on the opensuse website.
The warning is still present on Arch Linux (i386) with the, old but seemingly current, package xorg-xkbcomp-1.2.4-1 as found on: https://www.archlinux.org/packages/extra/i686/xorg-xkbcomp/ As said in the original report, its been present for me since 2007... (I'm afraid I'm not set up to test).
(In reply to comment #10) URL: http://download.opensuse.org:80/factory/repo/oss/
(In reply to comment #12) > URL: http://download.opensuse.org:80/factory/repo/oss/ Thanks. I've downloaded http://download.opensuse.org/factory/repo/oss/suse/i586/xkbcomp-1.2.4-9.3.i586.rpm , unpacked it, and used its xkbcomp -- it still gives me the warning. Maybe Suse changed something in the keymap definitions, or maybe you are using now a keymap that doesn't contain the triggering redefinition?
this pc has installed xkbcomp-1.2.4-9.3.x86_64 nothing has been changed, all kbd settings are as per default fwiw A780GM-m2<2013Oct04><17:44><~> dmesg | grep Warning [ 0.000000] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130517/tbfadt-603) [ 10.901122] ACPI Warning: 0x0000000000000b00-0x0000000000000b07 SystemIO conflicts with Region \SOR1 1 (20130517/utaddress-251) A780GM-m2<2013Oct04><17:45><~> A780GM-m2<2013Oct04><17:46><~> cat .xsession-errors-\:0 | grep Warning A780GM-m2<2013Oct04><17:47><~> cat .xsession-errors-\:0 | grep WARNING ** (process:1812): WARNING **: 1 dictionaries weren't free'd. ** (process:1994): WARNING **: 1 dictionaries weren't free'd. ** (process:2561): WARNING **: 1 dictionaries weren't free'd. A780GM-m2<2013Oct04><17:47><~> cat .xsession-errors-\:0 | grep warning I/O warning : failed to load external entity "/usr/share/qalculate/prefixes.xml" I/O warning : failed to load external entity "/usr/share/qalculate/currencies.xml" I/O warning : failed to load external entity "/usr/share/qalculate/units.xml" I/O warning : failed to load external entity "/usr/share/qalculate/functions.xml" I/O warning : failed to load external entity "/usr/share/qalculate/datasets.xml" I/O warning : failed to load external entity "/usr/share/qalculate/variables.xml" I/O warning : failed to load external entity "/usr/share/qalculate/currencies.xml" I/O warning : failed to load external entity "/home/michael/.qalculate/eurofxref-daily.xml" I/O warning : failed to load external entity "/home/michael/.qalculate/eurofxref-daily.xml" A780GM-m2<2013Oct04><17:48><~> A780GM-m2<2013Oct04><17:49></var/log> cat Xorg.0.log | grep Warning [ 24.444] (WW) Warning, couldn't open module fglrx A780GM-m2<2013Oct04><17:52></var/log> cat Xorg.0.log | grep xkb [ 26.218] (**) Option "xkb_rules" "evdev" [ 26.218] (**) Option "xkb_model" "pc104" [ 26.218] (**) Option "xkb_layout" "de" [ 26.218] (**) Option "xkb_variant" "nodeadkeys" [ 26.278] (**) Option "xkb_rules" "evdev" [ 26.278] (**) Option "xkb_model" "pc104" [ 26.278] (**) Option "xkb_layout" "de" [ 26.278] (**) Option "xkb_variant" "nodeadkeys" [ 26.282] (**) Option "xkb_rules" "evdev" [ 26.282] (**) Option "xkb_model" "pc104" [ 26.282] (**) Option "xkb_layout" "de" [ 26.282] (**) Option "xkb_variant" "nodeadkeys" [ 26.283] (**) Option "xkb_rules" "evdev" [ 26.283] (**) Option "xkb_model" "pc104" [ 26.283] (**) Option "xkb_layout" "de" [ 26.284] (**) Option "xkb_variant" "nodeadkeys" [ 26.286] (**) Option "xkb_rules" "evdev" [ 26.286] (**) Option "xkb_model" "pc104" [ 26.286] (**) Option "xkb_layout" "de" [ 26.286] (**) Option "xkb_variant" "nodeadkeys" A780GM-m2<2013Oct04><17:52></var/log> not awhere of what openSUSE has changed
For completeness, could you execute the following single string of commands, and paste the output, if any: setxkbmap -print | xkbcomp -w 1 -xkb - -o - | grep -A3 "key <RALT>"
Please note, if I start X through my display manager (lxdm, for me) the xkbcomp warning appears in its log file, /var/log/lxdm.log: === (excerpt /var/log/lxdm.log) The XKEYBOARD keymap compiler (xkbcomp) reports: > 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 Errors from xkbcomp are not fatal to the X server === The additional first warning is being triggered by some time ago having switched to === (excerpt /etc/X11/xorg.conf.d/10-evdev.conf) Option "XkbVariant" "altgr-intl" === At the time, I actually laughed when my momentary hope of getting rid of my age-old "euro warning" was slain so decisively. Anyways, that's not the point... I also downloaded the SuSE 13.1 beta 1 xkbcomp source package: http://download.opensuse.org/factory/repo/src-oss/suse/src/xkbcomp-1.2.4-9.3.src.rpm and your xkbcomp is just plain vanilla 1.2.4, it seems. Given that it's unlikely that SuSE has been changing keymaps itself, I expect this means that you also do in fact still get the warning (with the keyboard config with which you used to get it) but that's it's now for you buried in some DM log file somewhere. If you don't immediately know how to check, the quickest way might be to boot into a console (ie, "runlevel 3", most likely) and start X through startx -- if you're still that sort of person. You'll then probably see the warning back in full glory on your console. Or just rummage through your DM log, if any.
@ Benno: Here's mine, if it's useful. This is currently with === Section "InputClass" Identifier "evdev keyboard catchall" MatchIsKeyboard "on" MatchDevicePath "/dev/input/event*" Driver "evdev" Option "XkbLayout" "us" Option "XkbVariant" "altgr-intl" EndSection === [rene@e600 ~]$ setxkbmap -print | xkbcomp -w 1 -xkb - -o - | grep -A3 "key <RALT>" 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 key <RALT> { type= "ONE_LEVEL", symbols[Group1]= [ ISO_Level3_Shift ] };
Created attachment 87136 [details] Archlinux PKGBUILD
Created attachment 87137 [details] Benno's ONE_LEVEL diff, re-attached
@ Benno: Apologies, I'm not used to this bugzilla and only see now that the attachments have turned into two additional comments, at least one of which I should have provided this accompanying text for. But... I have tested your patch from comment #8 and it indeed silences the ONE_LEVEL warning for me. I have attached an archlinux PKGBUILD and, due to possible whitespace differences tripping up its checksum mechanism, also your patch from comment #8 again. If you guys do that stuff, and if you want, you can add a Tested-by: Rene Herman <rene.herman@gmail.com> I do still have that other warning about RALT being redefined, but that looks like it it's in fact probably valid -- and anyways, it would be a different issue. Will you be pushing this formward?
(In reply to comment #20) > Apologies, I'm not used to this bugzilla and only see now that the > attachments have turned into two additional comments, ?? Nothing happened to my attachment in comment #8, it is still the same as it is here. Your version contains spaces instead of a tab in one line, but now I see that that is XOrg style, so in fact that is better. > I do still have that other warning about RALT being redefined, It seems Archlinux runs xkbcomp with '-w 10'; with a lower warning level I don't see that message here. > Will you be pushing this formward? I will try. Soon I'll post some patches to xorg-devel.
No, never mind, nothing happened to your attachment. I was only apologizing for taking up three comments due to not knowing how to work this bugzilla. That is, I had planned to write a single message, and then attach the PKGBUILD and my possibly whitespace-mangled copy/paste-version of your patch to that single message -- but after I wrote it, the process of attaching did not attach to the just-written message, but created comments #18 and #19, leaving me to retype the message as comment #20. But that's not important... As to your -w 10 remark: I believe archlinux does most everything very "vanilla" and I in fact also see the warning with your manual -w 1 line: === [rene@e600 ~]$ setxkbmap -print | xkbcomp -w 1 -xkb - -o - | grep -A3 "key <RALT>" Warning: Symbol map for key <RALT> redefined Using last definition for conflicting fields key <RALT> { type= "ONE_LEVEL", symbols[Group1]= [ ISO_Level3_Shift ] }; === (again, with XkbVariant "altgr-intl"). So that's a little odd then? In any case, thanks much for taking this up.
re: Comment 15 oops! really trying, bash-4.2# setxkbmap -print | xkbcomp -w 1 -xkb - -o - | grep -A3 "key <RALT>" Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols Ignoring extra symbols key <RALT> { type= "ONE_LEVEL", symbols[Group1]= [ ISO_Level3_Shift ] }; bash-4.2# last few lines of /var/log/kdm.log -------- 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 The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Compat map for group 2 redefined > Using new definition > Warning: Compat map for group 3 redefined > Using new definition > Warning: Compat map for group 4 redefined > Using new definition Errors from xkbcomp are not fatal to the X server The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Compat map for group 2 redefined > Using new definition > Warning: Compat map for group 3 redefined > Using new definition > Warning: Compat map for group 4 redefined > Using new definition Errors from xkbcomp are not fatal to the X server ------ so not fixed nb. on openSUSE the found symbols.c has only 250 lines bash-4.2# cat symbols.c | grep result bash-4.2# hence application of patch not possible
(In reply to comment #22) > [...] and I in fact also see the warning with your manual -w 1 line: > [...] > (again, with XkbVariant "altgr-intl"). So that's a little odd then? That is indeed a little odd. If you see the "redefined" warning, I would expect you to also see the "Multiple symbols" warning. $ setxkbmap -print | xkbcomp -w 10 -xkb - -o - 2>&1 | grep -A1 "key <RALT>" 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 -- key <RALT> { type= "ONE_LEVEL", When I do this with '-w 1', or even '-w 9', I only get the last two lines.
(In reply to comment #23) > nb. on openSUSE the found symbols.c has only 250 lines That must be a different symbols.c. Are you sure this is the .../xkbcomp/symbols.c ? > bash-4.2# cat symbols.c | grep result Useless use of cat, by the way. When wanting to grep for something in a file you can simply do: grep result symbols.c
(In reply to comment #25) systemtap-2.3-3.3.x86_64 is the only package found containing symbols.c A780GM-m2<2013Oct07><12:38><~/> grep symbol systemtap-file-list /usr/share/systemtap/runtime/linux/autoconf-kallsyms-on-each-symbol.c /usr/share/systemtap/runtime/linux/autoconf-kprobe-symbol-name.c /usr/share/systemtap/runtime/transport/symbols.c /usr/share/systemtap/tapset/linux/context-symbols.stp /usr/share/systemtap/tapset/linux/ucontext-symbols.stp A780GM-m2<2013Oct07><12:39><~/> /usr/share/doc/packages/xkbcomp/ is the only .../xkbcomp/ dir different ballpark
(In reply to comment #26) > /usr/share/doc/packages/xkbcomp/ is the only .../xkbcomp/ dir *Source* packages are not normally installed on user systems. If you want to look at them, change them, build them, and so on, you have to search for them and install them explicitly. Look for an xkbcomp src.rpm in your repos if you want to apply the patch. Or better: do not, there is no need.
(In reply to comment #24)\ Well... at least I also get more warnings with -w 10 than with -w 1... === [rene@e600 ~]$ setxkbmap -print | xkbcomp -w 10 -xkb - -o - 2>&1 | grep -A1 "key <RALT>" Warning: Symbol map for key <RALT> redefined Using last definition for conflicting fields -- Warning: Multiple symbols for level 1/group 1 on key <RALT> Using ISO_Level3_Shift, ignoring Alt_R Warning: Multiple definitions for group 0 type of key <RALT> Using ONE_LEVEL, ignoring TWO_LEVEL Warning: Symbol map for key <RALT> redefined Using last definition for conflicting fields -- key <RALT> { type= "ONE_LEVEL", [rene@e600 ~]$ setxkbmap -print | xkbcomp -w 1 -xkb - -o - 2>&1 | grep -A1 "key <RALT>" Warning: Symbol map for key <RALT> redefined Using last definition for conflicting fields -- key <RALT> { type= "ONE_LEVEL", === But, as can be seen above, I do have the <RALT> redefined one with just -w 1. altgr-intl is as far I know little used, and I actually sort of expected the map to be just "broken" in that sense. Anyways -- the original ONE_LEVEL warning is gone from both, so that is success as far as I'm concerned.
(In reply to comment #28) > Warning: Symbol map for key <RALT> redefined > Using last definition for conflicting fields > -- > Warning: Multiple symbols for level 1/group 1 on key <RALT> > Using ISO_Level3_Shift, ignoring Alt_R > Warning: Multiple definitions for group 0 type of key <RALT> > Using ONE_LEVEL, ignoring TWO_LEVEL > Warning: Symbol map for key <RALT> redefined > Using last definition for conflicting fields Ah, but you get two warnings about "Symbol map redefined", I get only one. > altgr-intl is as far I know little used, and I actually sort of expected > the map to be just "broken" in that sense. Well, I use altgr-intl too. :) But mine is somewhat modified. When I undo one of the modifications, I also get two warnings about "Symbol map redefined", but both of them are *after* the "Multiple symbols" warning, and I still don't get the "Multiple definitions" warning. Well, let's assume that this is because I am on an 'old' system (Ubuntu Lucid from April 2010) and you are on something much newer, and the order of things may have changed since then, and probably new warnings added. (But no, altgr-intl is not "broken" in any way. If it were, many other keymaps would be too.)
(In reply to comment #29) I see. Yes, I'm on "rolling release archlinux" and actually keep it updated once a week or so, so it should indeed be very current. If it's useful to know: [rene@e600 ~]$ pacman -Qo /usr/share/X11/xkb/symbols/us /usr/share/X11/xkb/symbols/us is owned by xkeyboard-config 2.9-2 Well... -- given that my reason for reporting this was to, at the time that I rebuilt this system, get things setup "just right" and therefore not ignore any of the errors or warnings, and the fact that you say that it's not a simple matter of a crusty old keymap file... this would seem to mean that I have in the end progressed in a parallel sense only. Perhaps the right solution is to have the (standard) setup run xkbcomp by default with -w 0 if it's expected that untweaked, vanilla upstream setups trigger these warnings. Certainly since I quite fully expect that fewer than 0.01 percent of prospective readers of these warnings will ever have any use for them.
Package: xkeyboard-config Version: 2.12 Severity: minor Tags: patch File: .../xkb/symbols/level3 --- level3 2014-01-27 00:33:44.000000000 +0000 +++ level3.new 2014-07-24 23:50:46.000000000 +0000 @@ -2,12 +2,14 @@ // so that the third shift level can be reached. // The default behaviour: -// the right Alt key (AltGr) chooses the third symbol engraved on a key. -default partial modifier_keys +// the right Alt key (AltGr) chooses the third position in a keymap line. +// If engraved on a key, then in the lower right corner. +default partial modifier_keys xkb_symbols "ralt_switch" { key <RALT> { - type[Group1]="ONE_LEVEL", - symbols[Group1] = [ ISO_Level3_Shift ] + type[Group1]="TWO_LEVEL", +// If "ISO_Next_Group" is absent, a symbol from the us keymap could appear + symbols[Group1] = [ ISO_Level3_Shift, ISO_Next_Group ] }; include "level3(modifier_mapping)" }; ~
Created attachment 106117 [details] [review] silences the one-level warning by properly reducing the number of levels Hello René, I finally got a review. Could you test the attached slightly modified version of the patch, so that I can again add a Tested-by tag?
Created attachment 106155 [details] [review] silences the one-level warning by properly reducing the number of levels Modified the patch still further after a rereview. :)
I am able to reproduce this on *only one* Debian Sid/unstable system. I’ll try to test this patch on that system. By the way, do you know if this issue also causes delays for the X server start-up?
better late then never, pushed now as commit bf4d7d059daf5c6f81d70f8d3e5e2a87265381b7
This commit (bf4d7d059daf5c6f81d70f8d3e5e2a87265381b7) breaks the Slovene ("si") keyboard layout for me, by making some AltGr combinations not work. AltGr+1 doesn't produce a tilde anymore, and AltGr+, and AltGr+. don't produce < and > anymore. Some combinations still work, though. AltGr+E produces E, and AltGr+V @.
Created attachment 125761 [details] [review] don't specify the keytype when not needed
(In reply to Matej Nanut from comment #36) > This commit (bf4d7d059daf5c6f81d70f8d3e5e2a87265381b7) breaks the Slovene > ("si") keyboard layout for me, by making some AltGr combinations not work. Hello Matej. You are using xkbcomp from git? > AltGr+1 doesn't produce a tilde anymore, To be sure: you mean AltGr+Shift+1 doesn't produce tilde anymore? Because AltGr+1 should produce a dead tilde -- which it probably doesn't do anymore either. AltGr+Shift+2 should produce caron, AltGr+Shift+3 circumflex, etc. > Some combinations still work, though. AltGr+E produces E, You mean AltGr+E still produces euro (€)? Could you try the attached patch against xkeyboard-config?
(In reply to Benno Schulenberg from comment #38) > Hello Matej. You are using xkbcomp from git? Hello. I'm using the latest xkbcomp available from Xenocara (OpenBSD's version of Xorg). I'm not sure from which git commit it was assembled. But since that change got in, and the last CVS commit says "Update to xkbcomp 1.3.1", I assume it's the head version. > To be sure: you mean AltGr+Shift+1 doesn't produce tilde anymore? Because > AltGr+1 should produce a dead tilde -- which it probably doesn't do anymore > either. AltGr+Shift+2 should produce caron, AltGr+Shift+3 circumflex, etc. Yes, that's what I meant. I usually press the dead key twice to generate a tilde. I've only found out about the fourth level (AltGr+Shift) now. :) To be sure, neither work now. > > Some combinations still work, though. AltGr+E produces E, > > You mean AltGr+E still produces euro (€)? Yes, my silly mistake, sorry. It produces €. > Could you try the attached patch against xkeyboard-config? The attached patch does fix the issue, thanks! So xkeyboard-config was incorrect, and the xkbcomp update revealed it?
Just a note, that `/usr/lib/gdm3/gdm-x-session` doesn’t print the warning anymore, since xkbcomp 1.3.1 was installed in Debian Sid/unstable by updating the package x11-xkb-utils (7.7+3) [1]. Benno, thank you very much. [1] http://metadata.ftp-master.debian.org/changelogs//main/x/x11-xkb-utils/x11-xkb-utils_7.7+3_changelog
(In reply to Matej Nanut from comment #36) > This commit (bf4d7d059daf5c6f81d70f8d3e5e2a87265381b7) breaks the Slovene > ("si") keyboard layout for me, by making some AltGr combinations not work. > > AltGr+1 doesn't produce a tilde anymore, and AltGr+, and AltGr+. don't > produce < and > anymore. > > Some combinations still work, though. AltGr+E produces E, and AltGr+V @. Thank you for your report and sorry that you experienced a regression. Could you please open a separate ticket for this though, referencing this one?
(In reply to Paul Menzel from comment #41) > Thank you for your report and sorry that you experienced a regression. Could > you please open a separate ticket for this though, referencing this one? Thank you for the swift reply! I've opened the new bug #97332 as you proposed. I hope quoting this bug in the new one's description is sufficient for the reference.
(In reply to Paul Menzel from comment #40) > [...] doesn’t print the warning anymore, since xkbcomp 1.3.1 was installed [...] That is because of commit 26d1c57a938ce5c0d4fd9d645ace25308e6a7070 by Peter Hutterer, which suppresses the warning for lower levels. If you run xkbcomp with "-w 6", you should still see the warning. My commit to xkbcomp fixes the cause of the warning, but it is not in a release yet.
(In reply to Matej Nanut from comment #39) > The attached patch does fix the issue, thanks! Okay, good. Meanwhile I've been able to verify that myself too. > So xkeyboard-config was > incorrect, and the xkbcomp update revealed it? I'm not sure. Maybe my change to xkbcomp caused a new bug, or it revealed another one. But at the moment that doesn't matter much, because it is easy to avoid it: stop xkeyboard-config from specifying a key as FOUR_LEVEL when in fact defining only the first two levels of it. For the Slovene and related layouts that works, but I will have to see and check whether all other layouts that "overallocate" their keys can have these overspecifications snipped. But will continue this investigation on bug #97332.
(In reply to Benno Schulenberg from comment #44) > (In reply to Matej Nanut from comment #39) > I'm not sure. Maybe my change to xkbcomp caused a new bug, or it revealed > another one. I'm gonna assume the latter, but xkbcomp is a bit hairy so I refrain from looking too deeply into it ;) > But at the moment that doesn't matter much, because it is easy > to avoid it: stop xkeyboard-config from specifying a key as FOUR_LEVEL when > in fact defining only the first two levels of it. For the Slovene and > related layouts that works, but I will have to see and check whether all > other layouts that "overallocate" their keys can have these > overspecifications snipped. > > But will continue this investigation on bug #97332. good find and imo the right solution, thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.