Re: keyboard input broken for certain extended characters

[Riccardo Mottola]

Hi,

I follow up on this delicate topic.
A compliation of this issue is not only LANG, but its combination with 
export XMODIFIERS="@im=kinput2"
Unsetting XMODIFIERS makes things work better.

However, eitout it, I tried debugging thigns with fred, checking Key events.

For simple "a" key we get:
2024-09-11 23:13:43.028 Ink[2352:100713] XKeyEvent keyCode 26
2024-09-11 23:13:43.028 Ink[2352:100713] unicode modifiers: 0
2024-09-11 23:13:43.028 Ink[2352:100713] unicode no modifiers: 0
2024-09-11 23:13:43.028 Ink[2352:100713] process_key_event: keys:a ukeys:a
2024-09-11 23:13:43.097 Ink[2352:100713] XKeyEvent keyCode 26
2024-09-11 23:13:43.097 Ink[2352:100713] unicode modifiers: 0
2024-09-11 23:13:43.097 Ink[2352:100713] unicode no modifiers: 0
2024-09-11 23:13:43.097 Ink[2352:100713] process_key_event: keys:a ukeys:a


But If I press "à" we get:
2024-09-11 23:19:51.042 Ink[2352:100713] XKeyEvent keyCode 22
2024-09-11 23:19:51.042 Ink[2352:100713] unicode modifiers: 0
2024-09-11 23:19:51.042 Ink[2352:100713] unicode no modifiers: 0
2024-09-11 23:19:51.042 Ink[2352:100713] process_key_event: keys:è ukeys:è
2024-09-11 23:19:51.125 Ink[2352:100713] XKeyEvent keyCode 22
2024-09-11 23:19:51.125 Ink[2352:100713] unicode modifiers: 0
2024-09-11 23:19:51.125 Ink[2352:100713] unicode no modifiers: 0
2024-09-11 23:19:51.125 Ink[2352:100713] process_key_event: keys:è ukeys:è


so key up is different (and seemingly incorrect) from key dow, which at 
a first glance is confusing, do you agree?

A "technical" reason is apparent in XIMputServer.m for loopupStringForEvent

There, KeyPress isprocessed with Xutf8LookupString if available, but 
KeyUp with XLookupString.
Why? Xutf8LookupString is defined per manpage only for key down! 
Idisynchrasies of X11.
However XLookupString is specified to return ISO Latin1 and string 
conersion is done with that. Since "à" is a character perfectly 
represented by Latin-1 why isn't it working?

Is conversion not working or something different in Press/Release? I 
changed the code so UTF8 is not used and Latin1 is used both in KeyPress 
and KeyRelease.

2024-09-12 00:24:31.333 Ink[6233:100667] XKeyEvent keyCode 30
2024-09-12 00:24:31.334 Ink[6233:100667] unicode modifiers: 0
2024-09-12 00:24:31.334 Ink[6233:100667] unicode no modifiers: 0
2024-09-12 00:24:31.334 Ink[6233:100667] process_key_event: keys:Ã ukeys:Ã
2024-09-12 00:24:31.423 Ink[6233:100667] XKeyEvent keyCode 30
2024-09-12 00:24:31.423 Ink[6233:100667] unicode modifiers: 0
2024-09-12 00:24:31.423 Ink[6233:100667] unicode no modifiers: 0
2024-09-12 00:24:31.423 Ink[6233:100667] process_key_event: keys:Ã ukeys:Ã


now it is consistent! (and doesn't work at all). So it looks that 
getting an ISOLatin1 string for something simple as à doesn't work.

https://github.com/gnustep/libs-back/blob/master/Source/x11/XIMInputServer.m#L158


      /* Always returns a Latin-1 string according to the manpage */
      count = XLookupString (event, buf, BUF_LEN, &keysym, NULL);
      if (count)
    {
      keys = [[[NSString alloc] initWithBytes: buf
                       length: count
                     encoding: NSISOLatin1StringEncoding] autorelease];
    }


looks fine for me! do you spot the bug? or can't we trust this code?

Riccardo