Red Hat Bugzilla – Bug 75109
Problems with Xlib input method
Last modified: 2007-04-18 12:47:09 EDT
oT: Owen Taylor <email@example.com>
tEMA: Re: displaying RH8.0 applications on an older X server
dATA: 04 Oct 2002 10:47:48 -0400
Eugene Kanter <firstname.lastname@example.org> writes:
> Setup: RH8.0 system, Exceed X server with Russian keyboard file on NT
> GNOME gtk2 application worked correctly. Gedit, gnome-terminal can
> display and accept English and Russian from both keyboard, file and
> clipboard. Others like gtk1, xterm, kate display raw UTF-8 entered from
> keyboard, display existing text fine and can not properly accept
> Russian clipboard text from RH7.3 xterm running on the same display.
> Locale is set to ru_RU.UTF-8
> What component does this belong to?
It's looks like Xlib problem, so the XFree86 component is appropriate.
gtk2 doesnt't use Xlib for doing keyboard input handling for most
languages, which is presumably why it is immune from this problem.
If I had to guess, I'd suspect a bug with the combination:
UTF-8 locale / no XKB extension / default built in Xlib input method
If the software you're using is not UTF-8 capable, then you must choose
a locale which does not use UTF-8 encoding.
I don't particularly see the bug here.
I am using just an X server. I have not seen a place which references any X
server as not UTF-8 capable. Please explain.
I ran xev from both remote X server and local Red Hat 8.0 X server. The reported
keyboard events reported when Russian keyabord is used are absolutely identical
in both cases. Nevertheless only gtk2 applications appear to accept UTF-8
generating characters from this particular kind of remote X server.
The server has virtually nothing to to do with the handling of UTF-8.
My suggestion above is that it is the missing XKEYBOARD extension
that is causing the problems. (You can check if the exceed server
it by looking in the output of xdpyinfo, but I doubt it does)
You can try, in XF86Config changing:
# To disable the XKEYBOARD extension, uncomment XkbDisable.
To see if this reproduces the problem on the local server.
I fail to see how it could be an XFree86 bug at all, server or otherwise
personally. Misconfiguration, of something on one side or the other,
or simple incompatibility between both sides perhaps, but not a bug.
I'll leave it open for now, in case someone has some detailed information
or debugging info that can show there is a real bug in XFree86 here.
I'm pretty positive it's an Xlib bug, Mike. Basically, the server
doesn't get involved in handling of UTF-8 output enough to make
"incompatibility" or "misconfiguration" possible on the X server
And if it happens with both GTK+-1.2 apps and Qt apps it's not
an app bug, so then it has to be a bug in Xlib or possibly (though
I don't quite see how) a bug in the XFree86 config files.
The X server however definitely wouldn't be involved, however Xlib
is a possibility.
On a fresh 8.0 system uncomment XkbDisable in XF86Config, restart X server.
Download xruskb source rpm from rpmfind.net and install it.
Fix spec file by appending .gz to xrus.1 in the %files section:
build and install xruskb.
xrus jcuken-cyr.xmm # standard Russian keyboard
xrus yawerty-cyr.xmm # phonetic Russian keyboard
Default switch method is Shift_L+Shift_R
Start xterm, press on both shifts and start typing.
The raw UTF-8 appears.
> Download xruskb source rpm from rpmfind.net and install it.
Hmm - so xruskb is a program is a program to enable Russian
keyboard support without Xkb? I have some suspicion that
the bug is in that program rather than in anything Red Hat
I do not believe you are correct. Please look at the opening statement. I only
brought that utility for the only purpose: Red Hat developers can reproduce this
without Windows and Exceed.
Both Exceed and xruskb (in default configuration) send symbolic key name events.
xev reports _identical_ events in all three cases: Xkb, xruskb and Exceed.
BTW, xruskb is _only_ a frontend to xmodmap. You can take any existing .xmm file
with symbolic names and feed it to xmodmap your own way with the same results.
And please do not assume that ony Cyrillic is affected. Any double byte UTF-8
keysyms won't work. Greek is another example.
OK, just wanted to check
Note that there is no such thing as a symbolic key name event...
key events contain key codes, which are interpreted by Xlib
into symbolic keysymbols by use of a mapping table that is
stored on the Xserver. (What xmodmap -pk prints out)
Just to update this report...
This report should be submitted by the original reporter to upstream XFree86,
as it may or may not be an actual bug in Xlib, or in something else, or even
in the xruskb application. I'm not even familiar with these areas of X, let
alone an expert in the given area, and am thus neither best suited for
troubleshooting the problem, confirming/denying it, nor for fixing it if it
is in fact an Xlib or other X problem.
My suggestion is to report it on email@example.com mailing list, and also
to firstname.lastname@example.org bug report address so that an expert in this particular
area is aware of it, and can make an official comment about it.
I'm defering this issue for now. Once a response is given from upstream,
This has been fixed recently in XFree86 CVS:
date: 2002/12/10 04:30:39; author: dawes; state: Exp; lines: +8 -6
601. The functions XGetXlibControls and XSetXlibControls must work even if
the X server doesn't have the XKB extensions (#5513, Ivan Pascal).
See thread from:
I don't know if this change is in the current Rawhide RPMs or not.
This would be fixed since my 20021210 snapshot then I presume. Thanks for
catching this in the CVS log and updating the report Owen.
Closing as RAWHIDE.
I verified that XFree86 server without xkb correclty switches keyboard in
Phoebe. Thanks XFree86 team for discovering this bug independently and fixing it.
Ok, thanks for the confirmation.