Red Hat Bugzilla – Bug 457901
accent deadkeys not working under XIM
Last modified: 2009-03-10 06:42:34 EDT
Description of problem:
I recently started experiencing problems entering 8-bit characters in evolution. I noticed this when I tried writing an email in evolution in norwegian using the norwegian special characters (æøå) and after some more testing I found that this happens in gedit as well.
This does not happen in xchat-gnome and abiword so maybe it's related to a few special widgets in gtk+? Are there any other shared widgets between gedit and evolution that could be the problem here? I cannot reproduce this in gtk-demo anywhere...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
This is also true for the run dialog opened with alt+f2 in a GNOME session.
[kmaraas@localhost ~]$ locale
Keyboardlayout is "Norwegian" and model is "Generic 105 key (Intl) PC"
Sorry, didn't see the gtk2 component until after adding the report.
You'll have to specify your problems in entering these characters in a little more detail. How did you enter them before ? using input methods, or are they directly accessible in the norwegian keymap ? And what happens now if you try to enter them ?
They are directly available on my keyboard or through compose keys which should give me e grave for example. I'm starting to think that this has something to do with recent X.org changes more than gtk2 though. with a generic 105 key (Intl) keyboard set in the keyboard layout preferences I don't get norwegian chars at all in any app including those that worked before. With an evdev managed keyboard I do get those, but compose keys are not working.
Still seeing this and now I can't type any characters with caron or acute etc in emacs either. In addition I see this when starting xterm from a terminal:
[kmaraas@localhost camel]$ xterm
Warning: locale not supported by Xlib, locale set to C
Is this xorg breakage maybe?
I'm using a generic 105 key intl keyboard set up in gnome-keyboard-properties, and the strange thing is that I can type the chars in the test entry there, just not in any other apps...
> Is this xorg breakage maybe?
Possibly. What does
xprop -root | grep XKB
[kmaraas@localhost ~]$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "base", "evdev", "no", "", ""
_XKB_RULES_NAMES(STRING) = "base", "evdev", "no,no", ",nodeadkeys", "grp:alts_toggle"
Configuring evdev managed keyboard in gnome-keyboard-properties does not help here. This is a setting that is used instantly, right?
What's the right component to move this report to?
After upgrading to the latest stuff found in koji while waiting for rawhide to start updating again I now can enter these chars in most apps. The only exception seems to be emacs, but I think that's because of something else maybe.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
I don't think this is just related to the evdev driver beacuse entering these characters work for almost all apps now. The key here was the scim applet which is started by default. When I disconnect the applet from the input method I can type all these chars in vi, ed, gvim, and all gnome apps. Clicking again to connect it breaks it again.
The only app where this is broken regardless of the input method setting is emacs. I can't type any chars like éšö etc in emacs at all, even when it's working in all other apps.
Created attachment 316161 [details]
Xorg config file
Created attachment 316162 [details]
Xorg log file
(In reply to comment #11)
> I don't think this is just related to the evdev driver beacuse entering these
> characters work for almost all apps now. The key here was the scim applet which
> is started by default. When I disconnect the applet from the input method I can
> type all these chars in vi, ed, gvim, and all gnome apps. Clicking again to
> connect it breaks it again.
Based on that - changing component to scim.
Hi Kjartan Maraas,
Could you use commands 'GTK_IM_MODULE=scim-bridge gedit' and 'GTK_IM_MODULE=scim' to start gedit, and test this problem? I want to know if this problem will happen.
I tried both and didn't see the problems with either of them.
(In reply to comment #16)
> I tried both and didn't see the problems with either of them.
If problems do not happen with scim or scim-bridget im module, I think it is a problem of imsettings or im-chooser.
just put testing packages at http://tagoh.fedorapeople.org/tests/457901/. please test them carefully if the composition sequences and X applications are really working for you. to test it, please make sure if you don't have any Input Method feature enabled, i.e. turn the checkbox off on im-chooser.
and if you do want to test it on GTK+ applications, that might be better set GTK_IM_MODULE=xim first. that would really purposes testing packages on GTK+ applications.
I should clarify more what was causing this:
We defaults XMODIFIERS=@im=imsettings now to provide a feature of changing IM for X applications on demand. when you turned off IM feature on im-chooser, the client applications in the fact connects to the loopback XIM server instead of something like @im=none in libX11, because there are no way of connecting to one in libX11 so that it gets things done internally. in the above testing packages, it should behaves same thing with the composition sequences provided by /usr/share/X11/locale/*/Compose - it doesn't have any own sequence data but just read it, but anyway.
This looks fixed to be with the packages in comment 18.
xterm runs now and one can input modifiers with deadkeys (except acute which only seems to work under gtk?).
Kjartan, could you please test too?
The test packages work for me too. I no longer have to disconnect from the input method to be able to type these chars.
Thanks for testing. fixed in libgxim-0.2.0-1.fc10 and imsettings-0.104.0-1.fc10.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here: