Bug 457901 - accent deadkeys not working under XIM
accent deadkeys not working under XIM
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: imsettings (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-05 05:55 EDT by Kjartan Maraas
Modified: 2009-03-10 06:42 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-10 06:42:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg config file (797 bytes, text/plain)
2008-09-09 05:13 EDT, Kjartan Maraas
no flags Details
Xorg log file (40.88 KB, text/plain)
2008-09-09 05:19 EDT, Kjartan Maraas
no flags Details

  None (edit)
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 13 Kjartan Maraas 2008-09-09 05:19:33 EDT
Created attachment 316162 [details]
Xorg log 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

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