Bug 34453

Summary: Need six new keysyms
Product: xorg Reporter: Jean-François Colson <jf>
Component: Server/Input/XKBAssignee: Daniel Stone <daniel>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: cloos, thierry.vignaud
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Jean-François Colson 2011-02-18 07:55:48 UTC
A few years ago a new keyboard has been produced with a completely new layout for the Breton language: the C’HWERTY keyboard layout.
This keyboard is sold with a keyboard driver for Windows and an XKB driver is now available in Linux's file /usr/share/X11/xkb/symbols/fr (you can activate it by “setxkbmap fr bre”)
Unfortunately, while Windows' driver works perfectly well, XKB still has a small problem.

In the Breton language, ch is considered as a single letter. So does c’h.
Those two letters were mapped to two keys: c’h is on the qwerty's Q, ch is on M: http://upload.wikimedia.org/wikipedia/commons/9/9e/Bretona-klavaro.jpg

In the XKB code I read:

 // key <AD01> { [    trigraph_c_h,   trigraph_C_h,    trigraph_C_H,    Greek_alpha ] };
    key <AD01> { [           UF8FD,          UF8FE,           UF8FF,    Greek_alpha ] };

 // key <AB07> { [      digraph_ch,     digraph_Ch,      digraph_CH,  Greek_omicron ] };
    key <AB07> { [           UF8FA,          UF8FB,           UF8FC,  Greek_omicron ] };

As you can see, to allow the output of two or three characters with a single keypress, PUA characters have been used in the XKB code and the following seven lines should be included by the end user in the file ~/.XCompose :

<UF8FA> : "ch"  # digraph_ch
<UF8FB> : "Ch"  # digraph_Ch
<UF8FC> : "CH"  # digraph_CH
<UF8FD> : "c’h" # trigraph_c_h
<UF8FE> : "C’h" # trigraph_C_h
<UF8FF> : "C’H" # trigraph_C_H

These lines could be included in the file /usr/share/X11/locale/en_US.UTF-8, but, since the code points U+F8FA to U+F8FF are in the Private Use Area, their inclusion in this file could cause conflicts with other layouts.

To offer a full support of the c’hwerty layout, six keysyms are absolutely necessary:

            either                    or simply
          digraph_ch                     ch
          digraph_Ch                     Ch
          digraph_CH                     CH
         trigraph_c_h                    c_h
         trigraph_C_h                    C_h
         trigraph_C_H                    C_H

Would it be possible to add them in a future release?

Thanks.
Comment 1 Denis Arnaud 2011-03-21 21:48:57 UTC
I am also interested in correction of this bug.
See also 
https://bugs.freedesktop.org/show_bug.cgi?id=19506
https://bugs.freedesktop.org/show_bug.cgi?id=25349
Comment 2 Jean-François Colson 2011-06-28 21:40:35 UTC
Hello everybody

Four months after my previous request, nobody has proposed his help.
Does it mean it’s impossible to provide new keysyms? Why?
Or is it simply a lack of time from the persons responsible for Xkb?

Thanks in advance for your answers.
Comment 3 Daniel Stone 2011-06-29 01:09:23 UTC
Sadly I've just not had time.  I'll try to look at this soonl
Comment 4 James Cloos 2011-06-29 03:06:44 UTC
I sent a possible patch to xorg-devel.

(Ah, I see the Assigned-To now.
Didn’t notice that earlier this morning/sleepless_night.)
Comment 5 Jean-François Colson 2011-06-29 03:53:36 UTC
(In reply to comment #3)
> Sadly I've just not had time.

OK. I understand that problem (the lack of time): it often occurs to me. :-)

> I'll try to look at this soonl

Thank you. That was all I wanted to know. Thus that could be fixed soon.
Comment 6 Jean-François Colson 2011-06-29 04:01:52 UTC
(In reply to comment #4)
> I sent a possible patch to xorg-devel.

Really? That's fine! Which keysyms did you choose exactly?

BTW, is that patch publicly available somewhere?

Is the file http://cgit.freedesktop.org/xorg/proto/x11proto/plain/keysymdef.h always the last official version of the keysymdef.h file?

Where can I find the last version of the Compose files (those usually stored in /usr/share/X11/locale)?

Where can I find the last version of the Xkb files (those usually stored in /usr/share/X11/xkb)?
Comment 7 James Cloos 2011-06-29 06:30:19 UTC
The keysyms are added to xorg/proto/x11proto as of:

http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=06ebd5b8

The compose table in libX11 now needs an update to expand those keysyms into their respective character strings.
Comment 8 Jean-François Colson 2011-06-29 06:38:19 UTC
(In reply to comment #7)
> The keysyms are added to xorg/proto/x11proto as of:
> 
> http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=06ebd5b8
> 
> The compose table in libX11 now needs an update to expand those keysyms into
> their respective character strings.

Thanks.

Are you sure that will be accepted? Can I ask an update at https://bugs.freedesktop.org/show_bug.cgi?id=19506 using those keysyms?
Comment 9 James Cloos 2011-06-29 07:08:21 UTC
>> I sent a possible patch to xorg-devel.

> Really? That's fine! Which keysyms did you choose exactly?

ch, Ch, CH, c_h, C_h and C_H.

> BTW, is that patch publicly available somewhere?

It will be in the xorg-devel archives, at:

http://lists.x.org/archives/xorg-devel

> Is the file http://cgit.freedesktop.org/xorg/proto/x11proto/plain/keysymdef.h
> always the last official version of the keysymdef.h file?

That will be the current version of the git master branch; for the most
recent released version you want the most recent tag on that branch.

> Where can I find the last version of the Compose files (those usually
> stored in /usr/share/X11/locale)?

The cgit urls for the source locale files would look like:

http://cgit.freedesktop.org/xorg/lib/libX11/plain/nls/en_US.UTF-8/Compose.pre

> Where can I find the last version of the Xkb files (those usually
> stored in /usr/share/X11/xkb)?

Those are from the xkeyboard-config module.  Its base cgit url is:

http://cgit.freedesktop.org/xkeyboard-config/
Comment 10 Daniel Stone 2012-08-08 17:41:01 UTC
Closing as the root issue has been fixed.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.