Red Hat Bugzilla – Full Text Bug Listing
|Summary:||accent deadkeys not working under XIM|
|Product:||[Fedora] Fedora||Reporter:||Kjartan Maraas <kmaraas>|
|Component:||imsettings||Assignee:||Akira TAGOH <tagoh>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||10||CC:||i18n-bugs, peter.hutterer, petersen, tagoh, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-03-10 06:42:34 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Kjartan Maraas 2008-08-05 05:55:46 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): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Comment 1 Kjartan Maraas 2008-08-05 06:30:09 EDT
This is also true for the run dialog opened with alt+f2 in a GNOME session. [kmaraas@localhost ~]$ locale LANG=nb_NO.utf8 LC_CTYPE="nb_NO.utf8" LC_NUMERIC="nb_NO.utf8" LC_TIME="nb_NO.utf8" LC_COLLATE="nb_NO.utf8" LC_MONETARY="nb_NO.utf8" LC_MESSAGES="nb_NO.utf8" LC_PAPER="nb_NO.utf8" LC_NAME="nb_NO.utf8" LC_ADDRESS="nb_NO.utf8" LC_TELEPHONE="nb_NO.utf8" LC_MEASUREMENT="nb_NO.utf8" LC_IDENTIFICATION="nb_NO.utf8" LC_ALL= Keyboardlayout is "Norwegian" and model is "Generic 105 key (Intl) PC"
Comment 2 Kjartan Maraas 2008-08-05 06:31:51 EDT
Sorry, didn't see the gtk2 component until after adding the report.
Comment 3 Matthias Clasen 2008-08-05 21:48:10 EDT
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 ?
Comment 4 Kjartan Maraas 2008-08-06 05:23:00 EDT
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.
Comment 5 Kjartan Maraas 2008-08-18 06:31:10 EDT
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...
Comment 6 Matthias Clasen 2008-08-18 08:46:25 EDT
> Is this xorg breakage maybe? Possibly. What does xprop -root | grep XKB say ?
Comment 7 Kjartan Maraas 2008-08-18 09:07:51 EDT
[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"
Comment 8 Kjartan Maraas 2008-08-19 04:46:36 EDT
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?
Comment 9 Kjartan Maraas 2008-08-24 16:34:35 EDT
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.
Comment 10 Matěj Cepl 2008-09-08 12:39:29 EDT
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.
Comment 11 Kjartan Maraas 2008-09-09 05:12:30 EDT
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.
Comment 12 Kjartan Maraas 2008-09-09 05:13:06 EDT
Created attachment 316161 [details] Xorg config file
Comment 14 Peter Hutterer 2008-09-09 11:21:53 EDT
(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.
Comment 15 Peng Huang 2008-09-09 20:03:58 EDT
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.
Comment 16 Kjartan Maraas 2008-09-10 01:53:06 EDT
I tried both and didn't see the problems with either of them.
Comment 17 Peng Huang 2008-09-10 02:27:51 EDT
(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.
Comment 18 Akira TAGOH 2008-09-14 05:30:03 EDT
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.
Comment 19 Akira TAGOH 2008-09-14 14:57:55 EDT
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.
Comment 20 Jens Petersen 2008-09-16 04:47:20 EDT
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?
Comment 21 Kjartan Maraas 2008-09-16 05:40:39 EDT
The test packages work for me too. I no longer have to disconnect from the input method to be able to type these chars.
Comment 22 Akira TAGOH 2008-09-19 01:19:44 EDT
Thanks for testing. fixed in libgxim-0.2.0-1.fc10 and imsettings-0.104.0-1.fc10.
Comment 23 Bug Zapper 2008-11-25 21:39:37 EST
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping