Bug 617959 - Incorrect handling of fr(oss) layout
Incorrect handling of fr(oss) layout
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xkeyboard-config (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: i18n
Depends On:
Blocks: F14Target
  Show dependency treegraph
 
Reported: 2010-07-25 05:54 EDT by Nicolas Mailhot
Modified: 2010-10-18 14:49 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-18 14:49:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
output of "xkbcomp -xkb $DISPLAY -" (62.78 KB, text/plain)
2010-07-26 13:05 EDT, Nicolas Mailhot
no flags Details
Xorg.log (389.35 KB, text/plain)
2010-07-26 13:07 EDT, Nicolas Mailhot
no flags Details

  None (edit)
Description Nicolas Mailhot 2010-07-25 05:54:06 EDT
Description of problem:

I don't really know if the problem is in xkeyboard config, but for some strange reason Fedora has stopped emitting U+2014, U+2013 & U+2011 when using this layout (altgr + shift + 4/5/6). Instead it emits useless $ ⅜ ⅝ ($ is already on first level on a standard key, the fractions have little use)

This is breaking the reference French layout
U+2014, U+2013 & U+2011 are very useful in writing typographically correct French

I've checked /usr/share/X11/xkb/symbols/fr and the definitions are still there, so something else is interfering

Version-Release number of selected component (if applicable):
xkeyboard-config-1.8-6.fc14.noarch

How reproducible:

Always
Comment 1 Peter Hutterer 2010-07-25 18:31:28 EDT
can you attach the output of "xkbcomp -xkb $DISPLAY -" please? does this happen after login or is it visible in a plain X session with nothing but xterm as well?

The Xorg.log file will probably be useful too.
Comment 2 Nicolas Mailhot 2010-07-26 13:05:39 EDT
Created attachment 434468 [details]
output of "xkbcomp -xkb $DISPLAY -"

(In reply to comment #1)
> can you attach the output of "xkbcomp -xkb $DISPLAY -" please?

Here it is
Comment 3 Nicolas Mailhot 2010-07-26 13:07:34 EDT
Created attachment 434469 [details]
Xorg.log

> The Xorg.log file will probably be useful too.

And this one
Comment 4 Nicolas Mailhot 2010-07-26 13:08:06 EDT
(In reply to comment #1)
> does this happen
> after login or is it visible in a plain X session with nothing but xterm as
> well?

Will test this now
Comment 5 Nicolas Mailhot 2010-07-26 13:34:08 EDT
(In reply to comment #4)
> (In reply to comment #1)
> > does this happen
> > after login or is it visible in a plain X session with nothing but xterm as
> > well?
> 
> Will test this now    

I confirm <altgr> + <shift> + <4> emits $ in a plain xterm session too
xterm seems too dumb to display the other glyphs without options I've long forgotten about
Comment 6 Bug Zapper 2010-07-30 08:49:38 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Nicolas Mailhot 2010-08-03 02:03:03 EDT
(In reply to comment #5)

> I confirm <altgr> + <shift> + <4> emits $ in a plain xterm session too
> xterm seems too dumb to display the other glyphs without options I've long
> forgotten about    

And I see that ... has been eaten too to be replaced by yet another worthless symbol.

Can this be fixed?

The whole point of fr(oss) is to give easy access to the symbols something is stomping on now (it even exists as a Windows layout). It builds on fr(latin9) which has created in the early 90's and continually updated since, so it's not a new layout and it is interesting enough for French people new maintainers always stepped up when the previous ones switched interests
Comment 8 Peter Hutterer 2010-08-03 19:44:28 EDT
I'm still trying to reproduce this. On F-13 with an F-14 X stack it works fine but my F-14 is currently in dismay.
Comment 9 Jens Petersen 2010-08-19 01:19:34 EDT
This might be a complete red-herring but
if you are using imsettings-0.108.1-2.fc14
you might want to try turning on X compose in im-chooser (imsettings)
just to see if that makes a difference.
(This change went into F14 testing recently.)
Comment 10 Jens Petersen 2010-08-19 01:40:36 EDT
Erm since it is affecting xterm guess you can ignore last comment... :)
Comment 11 Nicolas Mailhot 2010-08-19 02:09:34 EDT
This layout does not depend on compose at all. All the characters are properly defined in the xkeyboard-config definition
Comment 12 Nicolas Mailhot 2010-10-03 04:10:14 EDT
This is still broken, with all the versions of xkeyboard-config I could test (1.7/1.8/1.9/2.0). Something is stomping on input settings.

Can this be investigated before f14? This is the default Linux layout of a big language? From experience, we won't see bugs filled about it because users are confused about input, but they will feel the pain anyway.
Comment 13 Peter Hutterer 2010-10-10 22:38:19 EDT
Can you please update the two packages below and check if it works then - seems to work for me now

xkeyboard-config-1.9-6.fc14.noarch
xorg-x11-xkb-utils-7.4-9.fc14.i386
Comment 14 Nicolas Mailhot 2010-10-18 14:49:32 EDT
This time it is fixed. Thank you very much for looking at it

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