Red Hat Bugzilla – Bug 98772
ctl- symbols do not work with non-us kbd
Last modified: 2007-04-18 12:55:33 EDT
I have two keyboard languages set:
extract from /etc/X11/XF86Config
Option "XkbRules" "xfree86"
Option "XkbModel" "pc105"
Option "XkbLayout" "us,ru"
Option "XkbVariant" ",phonetic"
Option "XkbOptions" "grp:menu_toggle,grp_led:scroll"
The keyboard switch works OK, menu_toggle (the key on the left of right control
on keyboard) sucessfully switches between us and ru keyboards.
But in any program (emacs/xterm/etc) all ctl- keys
(like ctl-a to the beginning of line, ctl-e to the end of line)
work fine in US mode, but do not work at all (they print some strange symbols)
in ru mode.
So to do ctl-a I need
1. swithch to us mode
2. issue ctl-a
3. switch back to ru mode.
Is there a way to make ctl- keys working in X with not-us kbd.
Bugzilla isn't a tech support forum, please use Red Hat and/or XFree86 mailing
lists for support questions. If you do end up finding a real bug in xkb,
report it to XFree86.org in their bugzilla located at: http://bugs.xfree86.org
Hope this helps.
This is not a tech support question.
Ths is a clear description of a usability problem,
caused by a bug in kbd file. Specifically:
ctl keys do not work with kbd files other than /usr/X11R6/lib/X11/xkb/symbols/pc/us
This is what this bug report means.
I considered it a tech support question, which is why I stated that, however
since you insist, I will give you the benefit of doubt and assume that there
really is a bug in xkb (not kbd, which this is filed against, and which
XFree86 has nothing to do with).
Reassigning bug report to XFree86 component. (kbd is the console keyboard
Now, acting under the assumption that this is indeed an XFree86.org xkb bug...
xkb bugs generally get filed in Red Hat bugzilla on occasion, and then sit here
forever and never get fixed, because they are very low priority and we are not
experts on xkb.
XFree86.org however does have experts on xkb, in particular Ivan Pascal, however
there are others who work on the xkb code and data files as well, and when bugs
get reported to them, they generally fix them either that day, or within a week
in CVS. That has been my experience for 8 months.
So, when someone reports an xkb bug, I defer the bug to upstream, so that an
expert in that area of X is working on it, who can not only fix it almost
instantly, but who actually knows very well that there is a real bug there,
and what the fix is. It also gives us the benefit that when users report
something as a bug in xkb that is NOT a bug in xkb, the official expert
at XFree86.org can clearly tell them that without question, and explain why.
Not having an xkb expert here, means that we may end up trusting that something
a user is reporting as a bug, is actually NOT a bug, and fixing it just to
please the user, when in reality we end up making our XFree86 incompatible
with upstream and everyone else. Additionally, we then have to carry around
extra patches which need to be maintained and which are incompatible with
XFree86. It's also possible that we accidentally break something and then
are responsible for fixing that too.
To be clear, if there is a bug in xkb or it's data files, it is a stock
official XFree86.org bug, and NOT a Red Hat induced bug.
ALL xkb bugs MUST be reported directly, so that an official expert in that
area of code can and will look into it as it is their personal area of
expertise. If they decide it is not a bug and they will not modify the
official sources, then the official Red Hat decision is NOTABUG and we
will also not modify the sources. If they decide it is a bug, and fix it,
which is often the case, it generally happens as I said above, within a few
days to a week, and after that occurs, assuming I am made aware of the
upstream bug report number, at some future date, I will investigate the
bugfix made by the upstream maintainer, and if the changes are simple and
do not seem to be a risk of regression, I create backported patches from
XFree86 CVS and include them in a future Red Hat XFree86 snapshot in rawhide.
This process of delegation to the proper expert upstream authority has
proven to yield faster and more correct bug fixes from XFree86.org than
troubleshooting unfamiliar areas of XFree86 and possibly making the problem
worse. It also has the benefit of fixing the problem not just for Red Hat
users, but for users of every operating system and distribution all at
once, which benefits the community more than just one company.
Once you've filed your report upstream, add the bug report URL to this bug
report for tracking if you would like me to monitor upstream progress and
backport any fixes that they develop, and include them in a future release.
Setting bug status to UPSTREAM to monitor upstream bug report when URL
gets added by reporter and fix or upstream resolution is available.
Thanks, let us hope it will be fixed.
I also submitted this bug to
There always bing a problem in XFree with kbd layouts
other than /usr/X11R6/lib/X11/xkb/symbols/pc/us
For example in XFree86-4.1 pc/ru (russial kbd) did not work at all.
Now in XFree86-4.3 it is working OK, except ctl- keys.
Let us hope that having this bug report they will fix the problem in XFree86-4.4
Yep, don't be surprised if it gets fixed within the week now. I'll monitor
CVS commits and the above bug URL and poke at any fixes that come along.
Upstream considers this bug to not be an XFree86 bug, but an issue
that should be fixed in the application itself. The upstream bug
report contains more information which package maintainers can
use to fix the issue in the given applications.
If this problem is still an issue, please reopen and reassign this
bug to the "vte" component, which is where I believe Owen and Egbert
both feel this problem should be fixed.
Setting status to "WONTFIX" for XFree86/X.Org.
It may be not clear with my report above.
Additional testing show that
the problem with ctl-a ctl-e ctl-k and ctl-w
exists with gnome-terminal and emacs.
In the same time these ctl- commands
work fine with xterm and mozilla.