Bug 75109 - Problems with Xlib input method
Problems with Xlib input method
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-04 12:11 EDT by Eugene Kanter
Modified: 2007-04-18 12:47 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-21 04:30:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Eugene Kanter 2002-10-04 12:11:18 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
Comment 1 Mike A. Harris 2002-10-05 18:26:20 EDT
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.
Comment 2 Eugene Kanter 2002-10-05 19:44:53 EDT
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.
Comment 3 Owen Taylor 2002-10-06 12:57:16 EDT
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.
Comment 4 Mike A. Harris 2002-10-06 18:20:05 EDT
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.
Comment 5 Owen Taylor 2002-10-06 18:33:48 EDT
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.
Comment 6 Mike A. Harris 2002-10-06 21:16:29 EDT
The X server however definitely wouldn't be involved, however Xlib
is a possibility.
Comment 7 Eugene Kanter 2002-10-07 16:11:58 EDT
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.
Comment 8 Owen Taylor 2002-10-07 17:05:50 EDT
> 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.
Comment 9 Eugene Kanter 2002-10-08 08:40:30 EDT
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.
Comment 10 Owen Taylor 2002-10-08 09:18:21 EDT
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)
Comment 11 Mike A. Harris 2002-12-14 12:07:31 EST
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.
Comment 12 Owen Taylor 2002-12-19 13:25:54 EST
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.
Comment 13 Mike A. Harris 2002-12-21 04:30:27 EST
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.
Comment 14 Eugene Kanter 2002-12-23 20:28:46 EST
I verified that XFree86 server without xkb correclty switches keyboard in
Phoebe. Thanks XFree86 team for discovering this bug independently and fixing it.
Comment 15 Mike A. Harris 2002-12-26 20:54:18 EST
Ok, thanks for the confirmation.

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