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 backage).
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 http://bugs.xfree86.org/show_bug.cgi?id=508 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. Thanks.
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.