help with X11/keysymdef.h

nidujay nidujay at
Wed Apr 23 15:26:26 PDT 2008


Thanks for your response.

On 24/04/2008, Samuel Thibault <samuel.thibault at> wrote:
> nidujay, le Thu 24 Apr 2008 07:55:31 +1000, a écrit :
> > Also assuming it is to do with input methods, how should we define
>  > symbols when a single keypress needs to generate multiple unicode
>  > characters?
> What do you call "symbols"?

I meant the #defines in keysyms.h

>  When, because of an input method, a keysym is converted into several
>  unicode characters, it's the input method's matter. Keysyms are just the
>  input for input methods.

So if a key on the keyboard is labelled 'X' and the input method
generates the Unicode characters A + B + C, should keysymdef.h contain

1) #define XK_{language}_X  {value} ?


#define XK_{language}_A  {Unicode char A}
#define XK_{language}_B  {Unicode char B}
#define XK_{language}_C  {Unicode char C}
(Note A, B or C may not even have associated keys on the keyboard layout)

If the former, is the value up to the implementer or are there
guidelines dictating what is acceptable?

>  > The reason I'm asking this is because of the following comment in keysymdef.h:
>  >
>  >  * Where the correspondence is either not one-to-one or semantically
>  >  * unclear, the Unicode position and name are enclosed in
>  >  * parentheses. Such legacy keysyms should be considered deprecated
>  >  * and are not recommended for use in future keyboard mappings.
> That's because keyboard manufacturers have invented keys, unicode has
>  invented characters, and some are quite the same, but not exactly, so
>  the unicode position is given as a hint, but since the meaning is not so
>  clear, these keysyms should not be used.

I'm talking about a standardised keyboard layout for the language I'm
working on.


More information about the xorg mailing list