Description of problem: Using the "us_intl" keyboard layout on a standard QWERTY-keyboard, the quite essential composed space & double-quotes keyboard entry cannot be entered in some applications. Version-Release number of selected component (if applicable): How reproducible: Always, in specific apps (e.g. Mozilla, Quanta) Steps to Reproduce: 1. Start Mozilla or Quanta, select an input-enabled widget 2. press the [SHIFT] and [' / "] key 3. press [SPACE] Actual results: Nothing happens. Expected results: The app should be fed a double-quote (") Additional info: - Specific to certain apps (e.g. Mozilla, Quanta) ; - other apps (GEdit, vi, console vt) work fine ; - other composed chars (e.g. accented e (é), tilde (~), umlaut-u (ü), ...) are correctly displayed. Related to bug #83137 ?
It seems all non-Gnome native apps are affected (kprinter, kedit, mozilla, OOo Writer, ...) ; GEdit, AbiWord, gnome-terminal, xterm all work fine.
The examples given are X based, which kbd has nothing to do with. Changing component.
You have not indicated what specific X release you are using. If you have not done so already, please update to the latest XFree86 and rawhide packages. If the problem persists, please attach your X server log and config file, and also report the problem to the xfree86 bug report address to maximize the chances of this problem being fixed before 4.3.0 is released.
Comment #3 : Phoebe 8.0.94, XFree86-4.2.99.901-20030213.0 I'll upgrade to 4.2.99.902-20030218.0 on monday ; nevertheless, I already attached XFree86 log & config file. Coincidentally, I experienced the same bug (no composed double quotes) on my production machine (stock up2dated RHL 8.0) with the latest Mozilla RPM builds from ftp.mozilla.org (1.3b-0_gtk2_xft and 2003021xxx_trunk_rh8_gtk2), forcing me to retrograde to Mozilla 1.2.1 ; I don't know how or whether to cross-reference this bug report to the Mozilla package, though (I guess bugzilla.mozilla.org is a better place for this). Please note that my RHL 8.0 production machine is completely separate from my 8.0.94 test environment.
Created attachment 90256 [details] XF86Config
Created attachment 90257 [details] XFree86.0.log
I'll await your feedback or the .902-upgrade, whichever comes first, before posting this to xfree86.org. Off-topic : thanks for both a truly great product and your inexhaustible commitment. Linux and RH make computing fun again (kinda reminds me of the old TRS-80 days :) ).
I'm experiencing this problem too (using a fresh Phoebe 8.0.94 installation). If I change my keyboard type to U.S. International using "redhat-config-keyboard" I cannot use the double quotes key in, for example, "konsole". With Phoebe 8.0.93 I did not experience this problem. If I change my keyboard type to U.S. English everything works well again.
Upgraded to RawHide XFree86-4.2.99.902-20030220.1, to no avail. As this problem seems to be limited to non-Gnome apps, should I really file a bug report with @xfree86.org ?
Concerning comment #9 : I read this today in the XFree86 cvs changelog (http://www.xfree86.org/cvs/changes.html) : 952. A more complete set of dead accent/space compose sequences, add for letters with a "stroke", and add some combos for exponent characters, katakana voiced sounds, etc to the en_US.UTF-8 compose file (#5646, David Monniaux). Perhaps d better wait for .903 RPM's ?
No go with XFree86-4.2.99.902-20030224.1 (from ftp://people.redhat.com/mharris/testing). (I'll be offline for the next 10 days).
Tested with XFree86-4.3.0-2 & kernel-2.4.20-2.54 : This yields different results : pressing the dblquote/space keys in non-Gnome apps (Mozilla, konsole, OOo Writer) returns something that *resembles* double quotes, but isn't (hex 'c2 a8' instead of '22'). Example (with hexdump) : --- "123" --- ¨123¨ --- 00000000 2d 2d 2d 0a 22 31 32 33 22 0a 2d 2d 2d 0a c2 a8 |---."123".---...|00000010 31 32 33 c2 a8 0a 2d 2d 2d 0a |123...---.| 0000001a I'll be off-line until Mon 2003/03/10.
Problem still exists with XFree86-4.3.0-2.1
I'm changing the status of this bug to UPSTREAM for now, as we will include the upstream fixes for this in our packages when XFree86 developers make fixes available in CVS.
Thanks ; bug filed with XFree86 .
What is the upstream bug URL, can you put it here so I can track it?
Does this help you out ? http://www.mail-archive.com/xfree86@xfree86.org/msg03451.html (merely a reference to this bug report). Note : this bug seems to be fixed in RHL 9 Shrike ; my apologies for not closing it myself. However, as I have completely lost Euro & cent symbols on both console and X (no matter what keyboard layout I use), I suppose I'll have to file a new bug.
I still notice this bug in Red Hat Linux release 9 (Shrike). If I set the keyboard to US International, the " (double-quote's) key does not work. Instead of the " character it returns the ¨ character. With US International "redhat-config-keyboard" executes the following command : "/usr/X11R6/bin/setxkbmap -layout us_intl -model pc105" With US English "redhat-config-keyboard" executes the following command : "/usr/X11R6/bin/setxkbmap -layout us -model pc105" These are the contents of my "/etc/sysconfig/i18n" file : LANG="nl_NL.UTF-8" SUPPORTED="nl_NL.UTF-8:nl_NL:nl:en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16"
*** Bug 90300 has been marked as a duplicate of this bug. ***
THe xfree86 mailing list, used to be the official place upstream to report bugs, however mailing lists are not a reliable way for reporting or tracking bug report progress, and involves a lot of extra work on all parties involved. XFree86.org has instituted bugzilla now for a few months, and all bug reports should be filed in their bugzilla at: http://bugs.xfree86.org Once you have filed the report in bugzilla upstream, please include the URL here once it is filed, and i will track it there. Thanks.
As a quick workaround, for those who can live with this workaround, do the following: - open /etc/sysconfig/i18n - Edit LANG="" - Next time you boot, everything works fine (maybe resetting X is enough, but I am not sure). Off course, doing so you will loose your locale, but your keyboard will work fine in us_intl, including the double_quotes.
Strangely enough, a week or two ago, I played around with some modmaps, etc. (didn't keep a log, unfortunately), and now everything works fine, even Euro chars on a QWERTY keyboard, both in X and console. If IIRC, I did this with XFree86-4.3.0-2 (not -5). Furthermore, main problem with Euro was the new RAlt-mapping in Gnome2 (keycode 113). From what I remember : /etc/X11/XF86Config : (!! please note the us-int instead of us_intl !!) ... Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc101euro" Option "XkbLayout" "us-int" EndSection ... /etc/X11/Xmodmap : ... ! Euro sign support !keycode 26 = e E currency keycode 26 = e E EuroSign keycode 54 = c C cent keycode 113 = Mode_switch Mode_switch Multi_key /etc/sysconfig/i18n : LANG="en_IE@euro" SUPPORTED="nl_BE.UTF-8@euro:nl_BE.UTF-8:nl_BE:nl:en_US.UTF-8:en_US:en" SYSFONT="lat0-sun16" SYSFONTACM="iso15" LC_TIME=nl_BE.UTF-8@euro LC_NUMERIC=nl_BE.UTF-8@euro LC_MONETARY=nl_BE.UTF-8@euro
Regarding comment #22 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84802#c22), it works for you because you are not using UTF. I experimented on RH 9.0 and this is what I get: LANG="en_IE@euro" -> double quotes LANG="en_US.UTF-8" -> diaeresis Thus, the problem is UTF.
Created a bug report at XFree86.org: http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=269 I strongly suggest that you add any comments and information there instead of here.
Thanks, I'll track it upstream now, and monitor for fixes.
FWIW: for a workaround I had to edit /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose. In that file I changed the line <dead_diaeresis> <space> : "¨" diaeresis to <dead_diaeresis> <space> : "\"" quotedbl Now typing Shift + ' and then typing space will give you " (double quote). It's of little use, but typing Shift + ' twice will still give you a ¨ (diaeresis).
I've just reinvestigated this upstream and it is resolved as a DUPLICATE of another bug which is resolved "RESOLVED LATER" with recommendations on how to proceed towards a solution. No further comments are present in the bug report after that suggestion. This is likely a long term issue and not something that will be investigated in the short term by XFree86.org resulting in a backportable patch. The presumption is now that the issue will be investigated by XFree86.org at some point in the future, and a resolution determined which makes it into a future XFree86 release. So at some point in the future, the official upstream resolution will end up incorporated into Red Hat Linux, and we no longer need to track this. Closing WONTFIX for any existing releases.