/etc/X11/xkb/base.xml is ignored (wrong documentation)

Bug #297428 reported by Gabor Karsay on 2008-11-13
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
xkeyboard-config
Invalid
Medium
xkeyboard-config (Debian)
Fix Released
Unknown
xkeyboard-config (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: xkb-data

In Hardy /etc/X11/xkb/base.xml used to be the configuration file for keyboard layouts shown in gnome-keyboard-properties. This has changed in Intrepid, but /usr/share/doc/xkb-data/README.Debian (in the section "Customised layouts") still recommends to change this file for customised layouts. (xkb-data 1.3-2ubuntu4)

Gnome now completely ignores it (you can rename the file without consequences), instead it uses /usr/share/X11/xkb/rules/evdev.xml. It took me some time to find out, so I'd like the information in the readme updated. My other guess is that the information is correct, but evdev.xml should be a symlink to base.xml, since its pretty much the same (and /usr/share/X11/xkb/rules/evdev.lst should point to /usr/share/X11/xkb/rules/base.lst).

I hope this is the right place for this "bug", even not sure if it is a bug ...
[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 82P965/G965 Memory Controller Hub [8086:29a0] (rev 02)
     Subsystem: Micro-Star International Co., Ltd. Device [1462:7238]
01:00.0 VGA compatible controller [0300]: nVidia Corporation G70 [GeForce 7600 GT] [10de:0391] (rev a1)
     Subsystem: Giga-byte Technology Device [1458:3417]

Bryce Harrington (bryce) wrote :

[This is an automated message]

Hi gabor-karsay,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

Changed in xkeyboard-config:
status: New → Incomplete
Gabor Karsay (gabor-karsay) wrote :

Let me first emphasize that my custom keyboard setup works well but the way I got it working is different than described in the packaged readme-file and different than it used to be in Ubuntu 8.04. I don't request any help but would like to help other users.

The files requested are attached, I changed my /etc/X11/xorg.conf at some time but reverted it later to its orginal state.

Cheers,
Gabor

Gabor Karsay (gabor-karsay) wrote :

And here the /var/log/Xorg.0.log. It's the actual one, the "issue" is permanent.

Bryce Harrington (bryce) on 2008-12-16
Changed in xkeyboard-config:
assignee: nobody → bryceharrington
importance: Undecided → Low
status: Incomplete → Triaged

I got stuck on this problem too. Thanks for helping me out Gabor, and please fix the documentation.

Bryce Harrington (bryce) on 2009-01-17
description: updated
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xkeyboard-config - 1.4-1ubuntu2

---------------
xkeyboard-config (1.4-1ubuntu2) jaunty; urgency=low

  * README.Debian: Correct documentation about location for keyboard
    customizations
    (LP: #297428)

 -- Bryce Harrington <email address hidden> Mon, 26 Jan 2009 14:48:05 -0800

Changed in xkeyboard-config:
status: Fix Committed → Fix Released
Bryce Harrington (bryce) wrote :

Thanks, uploaded

Changed in xkeyboard-config:
status: Triaged → Fix Committed
Bryce Harrington (bryce) wrote :
Bryce Harrington (bryce) wrote :

I'm reopening this because I think the README change I did earlier isn't exactly correct. I'm dropping those changes for now.

Changed in xkeyboard-config:
status: Fix Released → In Progress
Gabor Karsay (gabor-karsay) wrote :

I examined the differences in custom layouts between hardy and intrepid once more and in my opinion there's a regression because intrepid has no real configuration file anymore (evdev.xml is the configuration file, but it will be overwritten with every update).

My test case: I forced an old version of xkb-data both in hardy an intrepid and then installed my custom layout with the symbols file in /usr/share/X11/xkb/symbols and a modified /etc/X11/xkb/base.xml in hardy and a modified /usr/share/X11/xkb/rules/evdev.xml in intrepid. The custom layout worked fine, then I did the update of xkb-data.
1. In hardy everything's fine. The configuration file base.xml is not changed.
2. In intrepid the update overwrites evdev.xml without notification or asking anything. Surprisingly at first glance nothing has changed, because Gnome now uses the symbols file that's stored in gconf-editor under desktop/gnome/peripherals/keyboard/kbd/layouts and that is still my custom symbols file. In gnome-keyboard-properties the layout is now indicated with its file name, not with the description as before. If I remove it and want to add it again, it's lost. (Not tested: KDE, distribution upgrade)

My conclusion: The actual behavior (overwriting evdev.xml) is not good.
Secondly, the Readme is wrong as it names the wrong configuration file, and that the new file is not really a configuration file because it will be overwritten in the update process.

Forwarding this bug from a Ubuntu reporter:
https://bugs.edge.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/297428

[Problem]
It used to be that /etc/X11/xkb/base.xml was used as a config file for keyboard layouts. However, now this file is ignored and there is no way to do this configuration. Further, the documentation in xkb-data/README.Debian is outdated and describes the old method.

[Original Report]
In Hardy /etc/X11/xkb/base.xml used to be the configuration file for keyboard layouts shown in gnome-keyboard-properties. This has changed in Intrepid, but /usr/share/doc/xkb-data/README.Debian (in the section "Customised layouts") still recommends to change this file for customised layouts. (xkb-data 1.3-2ubuntu4)

Gnome now completely ignores it (you can rename the file without consequences), instead it uses /usr/share/X11/xkb/rules/evdev.xml. It took me some time to find out, so I'd like the information in the readme updated. My other guess is that the information is correct, but evdev.xml should be a symlink to base.xml, since its pretty much the same (and /usr/share/X11/xkb/rules/evdev.lst should point to /usr/share/X11/xkb/rules/base.lst).

I examined the differences in custom layouts between hardy and intrepid once more and in my opinion there's a regression because intrepid has no real configuration file anymore (evdev.xml is the configuration file, but it will be overwritten with every update).

My test case: I forced an old version of xkb-data both in hardy an intrepid and then installed my custom layout with the symbols file in /usr/share/X11/xkb/symbols and a modified /etc/X11/xkb/base.xml in hardy and a modified /usr/share/X11/xkb/rules/evdev.xml in intrepid. The custom layout worked fine, then I did the update of xkb-data.
1. In hardy everything's fine. The configuration file base.xml is not changed.
2. In intrepid the update overwrites evdev.xml without notification or asking anything. Surprisingly at first glance nothing has changed, because Gnome now uses the symbols file that's stored in gconf-editor under desktop/gnome/peripherals/keyboard/kbd/layouts and that is still my custom symbols file. In gnome-keyboard-properties the layout is now indicated with its file name, not with the description as before. If I remove it and want to add it again, it's lost. (Not tested: KDE, distribution upgrade)

My conclusion: The actual behavior (overwriting evdev.xml) is not good.
Secondly, the Readme is wrong as it names the wrong configuration file, and that the new file is not really a configuration file because it will be overwritten in the update process.

I do not understand the matter of the problem.
Both evdev.xml and base.xml (for drivers evdev and kbd respectively) are generated during the build from base.xml.in (for a moment, evdev.xml is a copy of base.xml). That is the way process works and will work in foreseable future. What exactly should I fix here?

While users can modify these files - honestly, they cannot expect them to remain in place during version upgrades (unfortunately XKB configuration scheme is not really modular). But again, this is up to distribution (.deb package) - whether to treat these files as configuration (and keep backup) or usual data file.

README.Debian is responsibility of Debian/Ubuntu people, I have no authority over it.

Bryce Harrington (bryce) wrote :

Hi Gabor,

I'm still not sure how best to fix this. So I've forwarded your bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=20743 - please subscribe to this bug report in case upstream needs further information or wishes you to try something. Thanks ahead of time!

Changed in xkeyboard-config:
status: Unknown → Confirmed
Bryce Harrington (bryce) on 2009-03-19
Changed in xkeyboard-config (Ubuntu):
assignee: bryceharrington → nobody
status: In Progress → Triaged

On Wed, Mar 18, 2009 at 10:40:35PM -0700, <email address hidden> wrote:
> It used to be that /etc/X11/xkb/base.xml was used as a config file for keyboard
> layouts. However, now this file is ignored and there is no way to do this
> configuration. Further, the documentation in xkb-data/README.Debian is
> outdated and describes the old method.

The documentation bit is clearly not an upstream issue.

> instead it uses /usr/share/X11/xkb/rules/evdev.xml. It took me some time to
> find out, so I'd like the information in the readme updated. My other guess is
> that the information is correct, but evdev.xml should be a symlink to base.xml,
> since its pretty much the same (and /usr/share/X11/xkb/rules/evdev.lst should
> point to /usr/share/X11/xkb/rules/base.lst).

No, they were split for a reason. If you look, evdev specifies the evdev
keycode set, whereas base specifies the xfree86 keycode set. You use the
evdev ruleset with the evdev driver, and the base/xorg ruleset with the
kbd driver, or anything that sends AT scancodes.

I'm fairly sure this move was well documented.

> I examined the differences in custom layouts between hardy and intrepid once
> more and in my opinion there's a regression because intrepid has no real
> configuration file anymore (evdev.xml is the configuration file, but it will be
> overwritten with every update).

Not an upstream issue.

> My conclusion: The actual behavior (overwriting evdev.xml) is not good.

As above.

> Secondly, the Readme is wrong as it names the wrong configuration file, and
> that the new file is not really a configuration file because it will be
> overwritten in the update process.

As above.

-> INVALID

Bryce Harrington (bryce) wrote :

Okay, wow, upstream closed that without delay.

So it seems upstream feels that these files are NOT intended to be end-user configurable files, and have rejected the bug report. Given that, I think I'm just going to drop the bits from the README.Debian entirely. The approach seems a bit hackish anyway, and as you point out, prone to get overwritten on upgrade.

What I might suggest, if you still would like an ability to do this, is that you file a wishlist bug upstream to support keyboard layout customizations, so we can get proper support added for it.

Bryce Harrington (bryce) wrote :

We're in beta freeze so not uploading this now, but here's the debdiff I'll be putting in.

Bryce Harrington (bryce) on 2009-03-19
Changed in xkeyboard-config (Ubuntu):
status: Triaged → In Progress
Gabor Karsay (gabor-karsay) wrote :

Well, that was too fast for me to react, but I understand upstream's decision and I think to drop that passage entirely is the right thing to do.

My primary concern was the wrong documentation, I can live without officially supported keyboard layout customization. I made a patch for my personal use to insert my custom keyboard layout after updates of xkb-data. I know that launchpad is for bugs and not how-tos, but I attached it anyway (as an example).

Thanks for your work!

Changed in xkeyboard-config:
status: Confirmed → Invalid
Michael Terry (mterry) wrote :

Patch went into 1.5-2ubuntu10, not sure why this bug wasn't auto-closed.

Changed in xkeyboard-config (Ubuntu):
status: In Progress → Fix Released
Changed in xkeyboard-config (Debian):
status: Unknown → New
Changed in xkeyboard-config (Debian):
status: New → Fix Committed
Bogdan Butnaru (bogdanb) wrote :

Hello Bryce,

Like you said, I'd very much like to have an “official” way of using custom keyboard configurations. Manually editing X's config files after each update is tiresome, and occasionally problematic*.

However, I'm not sure if this is a feature for X11 devs or for Gnome itself. AFAIK it's possible to set a keyboard layout that isn't in the {base|evdev}.{xml|lst} index files. (I don't remember exactly how, it involved piping output from xkbcomp to setxkbmap.)

So, technically X11/XKB supports custom keyboard layouts out of the box, it's Ubuntu that doesn't offer any option to do it. Adding it would imply modifying, at least, Gnome's keyboard layout applet (and probably the KDE equivalent), and whatever uses /etc/default/console-setup.

Since this is kind of a power-user feature, it doesn't even need any UI changes, just some way of setting the option in console-setup and GConf without confusing updates and causing a mess. It may be even possible to get away with just an Ubuntu-specific change to xkb-data, so that it merges some user-specified file (eg, /local/share/X11/xkb/...) in the /usr/share/X11/xkb/... ones on updates. This seems easier than adding a custom config file for XKB; even if that happened I think the aforementioned apps would still need updating to use it.

(* Funny anecdote: During at least one Ubuntu release update my custom keyboard config was lost, and the update scripts decided to replace my system-wide keyboard layout with some kind of Arabic (I suppose it was the first in some alphabetical ordering). Since I can't type my password in Arabic, and for some reason I couldn't change the login layout in that version of GDM, It took me a while to log-in again and fix it; I had to halt the init process at the step just before setting the keyboard layout...)

Gabor, do you apply that patch manually on each update? If there were a way to just apply it automatically on updates I wouldn't have any trouble with this bug anymore.

Gabor Karsay (gabor-karsay) wrote :

@ Bogdan: Yes, I apply the patch manually. I don't know how to apply it at updates automatically, but you could check on every system start with this line in /etc/rc.local:
if [ "`grep \<name\>your-custom-layout\</name\> /usr/share/X11/xkb/rules/evdev.xml`" == "" ]; then patch /usr/share/X11/xkb/rules/evdev.xml < /path/to/your/patch; fi;

Changed in xkeyboard-config (Debian):
status: Fix Committed → Fix Released
Changed in xkeyboard-config:
importance: Unknown → Medium
Changed in xkeyboard-config:
importance: Medium → Unknown
Changed in xkeyboard-config:
importance: Unknown → Medium
Frank Billington (d-m-s) wrote :

If I may interject here: I too need this previous feature to work again. I have learned (the hard way) how to edit evdev.xml so that my custom keyboard definition for the Nuer language (Sudan) appears in Kubuntu 10.04 at Control Center | Regional and Language | Keyboard Layout | Layout. IIUC from the comments here, that is going to disappear next time I upgrade.

I guess I am requesting as well that this issue be cared for. While it is indeed a 'power user' feature, surely an African distro that is made for 'the people' should be able to handle custom keyboards in the language of that people. It should not take a degree in computing to bring this about. The user should not have to hand-edit config files to get what is needed, only to have them overwritten the next time he/she upgrades.

I am not the only one needing this feature either:

http://ubuntuforums.org/showthread.php?p=10499753#post10499753

I appreciate greatly the work of the many volunteers that make this project go, and I am not complaining. I am just a simple user that has come to depend on this excellent distro for my day to day needs, and I am making a polite request that it be cared for.

If I should be posting this info elsewhere, then please let me know. And, thanks again, folks, for all your hard work.

Frank.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.