Public bug reported:
Binary package hint: xkb-data
Hello! I'm running Jaunty, up to date, although this particular problem
has been following me ever since Dapper or so:
According to /usr/share/doc/xkb-data/README.Debian: “[...] to create a
[custom] layout altering the 'a' key, create a
/usr/share/X11/xkb/symbols/my_fr file [...] To have it appear in your
desktop environment layout manager, add "my_fr" in
/usr/share/X11/xkb/rules/evdev.xml as a new layout.”
(Apparently the file previously used was /etc/X11/xkb/base.xml — I've no
idea which of the various files and symlinks in that folder actually do
anything, and if so, what. This is probably a bug in itself.)
Anyway, the problem with the approach mentioned in that read-me file is
that as far as I can tell the *.xml files in .../rules are sometimes
updated by their owner package. This leads to two problems:
1) During normal upgrades, the update manager demand the user if they
want to keep their version or install the package maintainer's version.
So either I loose my customization or I loose the fix from the
distribution. (Or I spend time to merge the two, which is still
annoying.)
2) During my previous two distribution upgrades (both Intrepid->Jaunty,
on two different machines) I got stuck with my keyboard set to Arabic
right after the upgrade. I'm pretty sure this was caused by some process
getting confused by my custom layout. I suppose the upgrade overwrote
the base.xml file, then something noticed that the (custom) layout "bb"
didn't exist and decided to replace it with Arabic (“ar” is the first
layout alphabetically, I think), or at least something like that.
This second part was really annoying, because I couldn't even log in to
fix it: I can't type my password in Arabic. (Since my custom layout is
set in the initrd, I had to actually break during init and step through
it by hand to reset the layout.) It would be very inconvenient to
downgrade and re-do the upgrade to track exactly what went wrong. But
that's not why I wrote this bug report.
The point is, there should be a way for admins & users to add custom
keyboard layouts without changing the distribution's config files.
Ideally there should be a pair of folders, /etc/xkb and an
~/.config/xkb, which contain layouts (system-wide and per-user,
respectively) and which are merged at run-time with whatever's in
/usr/share/X11/xkb. This is how it's done with all configuration items
on Ubuntu, and it should work the same with layouts.
By the way, there is an /etc/X11/xkb/base.xml in this package, but it's
not at all clear if it's used (see bug #67188) and what's its
relationship with the files in /usr/share/X11/xkb.
** Affects: xkeyboard-config (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
Binary package hint: xkb-data
Hello! I'm running Jaunty, up to date, although this particular problem
has been following me ever since Dapper or so:
- According to /usr/share/doc/xkb-data/README.Debian: “[...] to create a French
layout altering the 'a' key, create a
- /usr/share/X11/xkb/symbols/my_fr file [...] To have it appear in your desktop
environment layout manager, add
- "my_fr" in /usr/share/X11/xkb/rules/evdev.xml as a new layout.”
+ According to /usr/share/doc/xkb-data/README.Debian: “[...] to create a
+ [custom] layout altering the 'a' key, create a
+ /usr/share/X11/xkb/symbols/my_fr file [...] To have it appear in your
+ desktop environment layout manager, add "my_fr" in
+ /usr/share/X11/xkb/rules/evdev.xml as a new layout.”
(Apparently the file previously used was /etc/X11/xkb/base.xml — I've no
idea which of the various files and symlinks in that folder actually do
anything, and if so, what. This is probably a bug in itself.)
Anyway, the problem with the approach mentioned in that read-me file is
that as far as I can tell the *.xml files in .../rules are sometimes
- updated by the package. This leads to two problems:
+ updated by their owner package. This leads to two problems:
- 1) During normal upgrades, the updates demand the user to keep their
- version or install the package maintainer's version. So either I loose
- my customization or I loose the fix from the distribution. (Or I spend
- time to merge the two, which is still annoying.)
+ 1) During normal upgrades, the update manager demand the user if they
+ want to keep their version or install the package maintainer's version.
+ So either I loose my customization or I loose the fix from the
+ distribution. (Or I spend time to merge the two, which is still
+ annoying.)
- 2) During my previous two distribution upgrades (both Intrepid->Jaunty)
- I got stuck with my keyboard set to Arabic right after the upgrade. I'm
- pretty sure this was caused by some process getting confused by my
- custom layout. I suppose the upgrade overwrote the base.xml file, then
- something noticed that the layout "bb" didn't exist and decided to
- replace it with Arabic (ar is the first layout alphabetically, I think),
- or at least something like that.
+ 2) During my previous two distribution upgrades (both Intrepid->Jaunty,
+ on two different machines) I got stuck with my keyboard set to Arabic
+ right after the upgrade. I'm pretty sure this was caused by some process
+ getting confused by my custom layout. I suppose the upgrade overwrote
+ the base.xml file, then something noticed that the (custom) layout "bb"
+ didn't exist and decided to replace it with Arabic (“ar” is the first
+ layout alphabetically, I think), or at least something like that.
This second part was really annoying, because I couldn't even log in to
- fix it. (Since I use my custom keyboard during boot, too, I had to
- actually stop init early and step through it by hand to reset the
- layout.) Unfortunately it would be very inconvenient to downgrade and
- re-do the upgrade to track exactly what went wrong. But that's not why I
- wrote this bug report.
+ fix it: I can't type my password in Arabic. (Since my custom layout is
+ set in the initrd, I had to actually break during init and step through
+ it by hand to reset the layout.) It would be very inconvenient to
+ downgrade and re-do the upgrade to track exactly what went wrong. But
+ that's not why I wrote this bug report.
The point is, there should be a way for admins & users to add custom
keyboard layouts without changing the distribution's config files.
Ideally there should be a pair of folders, /etc/xkb and an
~/.config/xkb, which contain layouts (system-wide and per-user,
respectively) and which are merged at run-time with whatever's in
/usr/share/X11/xkb. This is how it's done with all configuration items
on Ubuntu, and it should work the same with layouts.
** Description changed:
Binary package hint: xkb-data
Hello! I'm running Jaunty, up to date, although this particular problem
has been following me ever since Dapper or so:
According to /usr/share/doc/xkb-data/README.Debian: “[...] to create a
[custom] layout altering the 'a' key, create a
/usr/share/X11/xkb/symbols/my_fr file [...] To have it appear in your
desktop environment layout manager, add "my_fr" in
/usr/share/X11/xkb/rules/evdev.xml as a new layout.”
(Apparently the file previously used was /etc/X11/xkb/base.xml — I've no
idea which of the various files and symlinks in that folder actually do
anything, and if so, what. This is probably a bug in itself.)
Anyway, the problem with the approach mentioned in that read-me file is
that as far as I can tell the *.xml files in .../rules are sometimes
updated by their owner package. This leads to two problems:
1) During normal upgrades, the update manager demand the user if they
want to keep their version or install the package maintainer's version.
So either I loose my customization or I loose the fix from the
distribution. (Or I spend time to merge the two, which is still
annoying.)
2) During my previous two distribution upgrades (both Intrepid->Jaunty,
on two different machines) I got stuck with my keyboard set to Arabic
right after the upgrade. I'm pretty sure this was caused by some process
getting confused by my custom layout. I suppose the upgrade overwrote
the base.xml file, then something noticed that the (custom) layout "bb"
didn't exist and decided to replace it with Arabic (“ar” is the first
layout alphabetically, I think), or at least something like that.
This second part was really annoying, because I couldn't even log in to
fix it: I can't type my password in Arabic. (Since my custom layout is
set in the initrd, I had to actually break during init and step through
it by hand to reset the layout.) It would be very inconvenient to
downgrade and re-do the upgrade to track exactly what went wrong. But
that's not why I wrote this bug report.
The point is, there should be a way for admins & users to add custom
keyboard layouts without changing the distribution's config files.
Ideally there should be a pair of folders, /etc/xkb and an
~/.config/xkb, which contain layouts (system-wide and per-user,
respectively) and which are merged at run-time with whatever's in
/usr/share/X11/xkb. This is how it's done with all configuration items
on Ubuntu, and it should work the same with layouts.
+
+ By the way, there is an /etc/X11/xkb/base.xml in this package, but it's
+ not at all clear if it's used (see bug #67188) and what's its
+ relationship with the files in /usr/share/X11/xkb.
--
no reasonable way of adding custom keyboard layouts
https://bugs.launchpad.net/bugs/322163
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
