Red Hat Bugzilla – Bug 75109
Problems with Xlib input method
Last modified: 2007-04-18 12:47:09 EDT
oT: Owen Taylor <otaylor@redhat.com> kOPIQ: ekanter@rcn.com tEMA: Re: displaying RH8.0 applications on an older X server dATA: 04 Oct 2002 10:47:48 -0400 Eugene Kanter <ekanter@rcn.com> writes: > Setup: RH8.0 system, Exceed X server with Russian keyboard file on NT > 4.0. > > 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. # 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 side. 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: /usr/man/man1/xrus.1.gz build and install xruskb. Start xruskb: xrus jcuken-cyr.xmm # standard Russian keyboard or 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 ships.
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 xpert@xfree86.org mailing list, and also to xfree86@xfree86.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, please reopen.
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: http://www.mail-archive.com/i18n@xfree86.org/msg01185.html 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.