Bug 617959

Summary: Incorrect handling of fr(oss) layout
Product: [Fedora] Fedora Reporter: Nicolas Mailhot <nicolas.mailhot>
Component: xkeyboard-configAssignee: Peter Hutterer <peter.hutterer>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: i18n-bugs, peter.hutterer
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-18 18:49:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 538278    
Attachments:
Description Flags
output of "xkbcomp -xkb $DISPLAY -"
none
Xorg.log none

Description Nicolas Mailhot 2010-07-25 09:54:06 UTC 
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 22:31:28 UTC 
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 17:05:39 UTC 
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 17:07:34 UTC 
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 17:08:06 UTC 
(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 17:34:08 UTC 
(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 12:49:38 UTC 
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 06:03:03 UTC 
(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 23:44:28 UTC 
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 05:19:34 UTC 
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 05:40:36 UTC 
Erm since it is affecting xterm guess you can ignore last comment... :)
Comment 11 Nicolas Mailhot 2010-08-19 06:09:34 UTC 
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 08:10:14 UTC 
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-11 02:38:19 UTC 
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 18:49:32 UTC 
This time it is fixed. Thank you very much for looking at it