Bug 98772 - ctl- symbols do not work with non-us kbd
Summary: ctl- symbols do not work with non-us kbd
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
URL: http://bugs.xfree86.org/cgi-bin/bugzi...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-07-08 18:18 UTC by Need Real Name
Modified: 2007-04-18 16:55 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-09-01 10:36:04 UTC
Embargoed:


Attachments (Terms of Use)

Description Need Real Name 2003-07-08 18:18:11 UTC
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.

Comment 1 Mike A. Harris 2003-07-17 00:53:21 UTC
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.

Comment 2 Need Real Name 2003-07-17 07:35:59 UTC
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.




Comment 3 Mike A. Harris 2003-07-17 08:20:07 UTC
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).

Comment 4 Mike A. Harris 2003-07-17 08:33:02 UTC
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.

Comment 5 Mike A. Harris 2003-07-17 08:34:41 UTC
Setting bug status to UPSTREAM to monitor upstream bug report when URL
gets added by reporter and fix or upstream resolution is available.

Comment 6 Need Real Name 2003-07-17 08:51:34 UTC
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

Comment 7 Mike A. Harris 2003-07-17 09:08:56 UTC
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.

Comment 8 Mike A. Harris 2004-09-01 10:34:23 UTC
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.



Comment 9 Mike A. Harris 2004-09-01 10:36:04 UTC
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.

Comment 10 Need Real Name 2004-09-01 10:41:12 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.