seeseemelk/cool-retro-term
1
0
Fork 0
Code Issues 449 Pull Requests 12 Actions Packages Projects Releases 8 Wiki Activity

Input bugs when using multi-level keyboard layouts #11

New Issue
Open
opened 2014-07-29 10:06:47 +02:00 by eigengrau · 15 comments
eigengrau commented 2014-07-29 10:06:47 +02:00 (Migrated from github.com)
Copy Link

Thanks for making this cool toy! I was eager to play with it today when I noticed it gave me some problems in the keyboard input department. I am using an XKB layout based on the Neo2 layout (part of Xorg), where some of the control characters (delete, up/down, insert, etc.) are on an additional level on top of the alphabetic keys. The keyboard handling in cool-old-term seems to get confused by such layouts.

E. g., when I enter return, this will not yield a newline in cool-old-term, but instead produce a unicode glyph in the private use plane. Someone more knowledgeable in all things XKB once informed me that such bugs were indicative of incorrect handling of modifier locks, but I cannot ascertain whether this is the case here.

Pressing return once yields nothing. Pressing return a second time yields the following private-use-unicode character: 􊴓

The following is the xev output when pressing return.

KeyPress event, serial 33, synthetic NO, window 0x3400001,
    root 0x267, subw 0x0, time 4344370, (295,293), root:(296,294),
    state 0x0, keycode 108 (keysym 0xfe0c, ISO_First_Group), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x3400001,
    root 0x267, subw 0x0, time 4344562, (295,293), root:(296,294),
    state 0x0, keycode 36 (keysym 0xff0d, Return), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
"   XmbLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3400001,
    root 0x267, subw 0x0, time 4344825, (295,293), root:(296,294),
    state 0x0, keycode 36 (keysym 0xff0d, Return), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3400001,
    root 0x267, subw 0x0, time 4345226, (295,293), root:(296,294),
    state 0x82, keycode 108 (keysym 0xff7f, Num_Lock), same_screen YES,
    XKeysymToKeycode returns keycode: 94
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Delete, backspace, up/down seem to work, but require two keypresses each.

A related problem occurs when I am using keys on the numeric keypad, which on my layout is accessed using a modifier key. These keypad keys only generate numeric input and never output control characters, but good-old-term treats them as if numlock were disabled and sees them as control chars. E. g., KP_4 will move the cursor left in good-old-term, while it should rather yield the character 4.

Pertinent xev output for the keypad:

KeyPress event, serial 33, synthetic NO, window 0x3600001,
    root 0x267, subw 0x0, time 5196219, (658,583), root:(659,584),
    state 0x0, keycode 94 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x3600001,
    root 0x267, subw 0x0, time 5197039, (658,583), root:(659,584),
    state 0x0, keycode 83 (keysym 0xffb4, KP_4), same_screen YES,
    XLookupString gives 1 bytes: (34) "4"
    XmbLookupString gives 1 bytes: (34) "4"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3600001,
    root 0x267, subw 0x0, time 5197255, (658,583), root:(659,584),
    state 0x0, keycode 83 (keysym 0xffb4, KP_4), same_screen YES,
    XLookupString gives 1 bytes: (34) "4"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3600001,
    root 0x267, subw 0x0, time 5197539, (658,583), root:(659,584),
    state 0x82, keycode 94 (keysym 0xff7f, Num_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3376647-input-bugs-when-using-multi-level-keyboard-layouts?utm_campaign=plugin&utm_content=tracker%2F479407&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F479407&utm_medium=issues&utm_source=github).
Thanks for making this cool toy! I was eager to play with it today when I noticed it gave me some problems in the keyboard input department. I am using an XKB layout based on the Neo2 layout (part of Xorg), where some of the control characters (delete, up/down, insert, etc.) are on an additional level on top of the alphabetic keys. The keyboard handling in cool-old-term seems to get confused by such layouts. E. g., when I enter return, this will not yield a newline in cool-old-term, but instead produce a unicode glyph in the private use plane. Someone more knowledgeable in all things XKB once informed me that such bugs were indicative of incorrect handling of modifier locks, but I cannot ascertain whether this is the case here. Pressing return once yields nothing. Pressing return a second time yields the following private-use-unicode character: `􊴓` The following is the `xev` output when pressing return. ``` KeyPress event, serial 33, synthetic NO, window 0x3400001, root 0x267, subw 0x0, time 4344370, (295,293), root:(296,294), state 0x0, keycode 108 (keysym 0xfe0c, ISO_First_Group), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x3400001, root 0x267, subw 0x0, time 4344562, (295,293), root:(296,294), state 0x0, keycode 36 (keysym 0xff0d, Return), same_screen YES, " XLookupString gives 1 bytes: (0d) " " XmbLookupString gives 1 bytes: (0d) " XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x3400001, root 0x267, subw 0x0, time 4344825, (295,293), root:(296,294), state 0x0, keycode 36 (keysym 0xff0d, Return), same_screen YES, " XLookupString gives 1 bytes: (0d) " XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x3400001, root 0x267, subw 0x0, time 4345226, (295,293), root:(296,294), state 0x82, keycode 108 (keysym 0xff7f, Num_Lock), same_screen YES, XKeysymToKeycode returns keycode: 94 XLookupString gives 0 bytes: XFilterEvent returns: False ``` Delete, backspace, up/down seem to work, but require two keypresses each. A related problem occurs when I am using keys on the numeric keypad, which on my layout is accessed using a modifier key. These keypad keys only generate numeric input and never output control characters, but good-old-term treats them as if numlock were disabled and sees them as control chars. E. g., KP_4 will move the cursor left in good-old-term, while it should rather yield the character `4`. Pertinent `xev` output for the keypad: ``` KeyPress event, serial 33, synthetic NO, window 0x3600001, root 0x267, subw 0x0, time 5196219, (658,583), root:(659,584), state 0x0, keycode 94 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x3600001, root 0x267, subw 0x0, time 5197039, (658,583), root:(659,584), state 0x0, keycode 83 (keysym 0xffb4, KP_4), same_screen YES, XLookupString gives 1 bytes: (34) "4" XmbLookupString gives 1 bytes: (34) "4" XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x3600001, root 0x267, subw 0x0, time 5197255, (658,583), root:(659,584), state 0x0, keycode 83 (keysym 0xffb4, KP_4), same_screen YES, XLookupString gives 1 bytes: (34) "4" XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x3600001, root 0x267, subw 0x0, time 5197539, (658,583), root:(659,584), state 0x82, keycode 94 (keysym 0xff7f, Num_Lock), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False ``` ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3376647-input-bugs-when-using-multi-level-keyboard-layouts?utm_campaign=plugin&utm_content=tracker%2F479407&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F479407&utm_medium=issues&utm_source=github). </bountysource-plugin>
eigengrau commented 2014-07-29 10:44:48 +02:00 (Migrated from github.com)
Copy Link

I realize this will probably be an upstream bug, but you’ll probably know best. Should I take this upstream?

I realize this will probably be an upstream bug, but you’ll probably know best. Should I take this upstream?
Swordfish90 commented 2014-07-29 12:11:00 +02:00 (Migrated from github.com)
Copy Link

Thank you for your feedback!... As you suspected the keyboard handling is completely taken from the Konsole QML plugin. Please try if you can reproduce it https://launchpad.net/ubuntu-terminal-app (I hope you are using Ubuntu) so that they can fix that upstream. If this fails I can try to investigate the problem in the next few days but I can't promise anything.

Thank you for your feedback!... As you suspected the keyboard handling is completely taken from the Konsole QML plugin. Please try if you can reproduce it https://launchpad.net/ubuntu-terminal-app (I hope you are using Ubuntu) so that they can fix that upstream. If this fails I can try to investigate the problem in the next few days but I can't promise anything.
eigengrau commented 2014-09-15 13:45:52 +02:00 (Migrated from github.com)
Copy Link

I have filed a ticket upstream at the following URL: https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1369531

I have filed a ticket upstream at the following URL: https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1369531
KAMiKAZOW commented 2014-09-15 14:36:55 +02:00 (Migrated from github.com)
Copy Link

Oh great, a bug where one has to rely on Canonical to fix it. We're doomed already. ;-)

@Swordfish90: I suspect that KDE's Qt5 port of the original Konsole application is not QML'ified yet, so comparing the input behaviour with that won't probably mean a lot, right?

Oh great, a bug where one has to rely on Canonical to fix it. We're doomed already. ;-) @Swordfish90: I suspect that KDE's Qt5 port of the original Konsole application is not QML'ified yet, so comparing the input behaviour with that won't probably mean a lot, right?
eigengrau commented 2014-09-15 15:06:46 +02:00 (Migrated from github.com)
Copy Link

Hm, I just noticed my cool-retro-term package does not depend on anything called ubuntu-terminal-app. Was this just another client for comparison? I took it to be both the library and client implementation, so I forwarded this issue there.

I could not get a hold of a software by that name, but now I installed http://kde.org/applications/system/konsole/ (along with 300MB of dependencies o_O), and the keyboard layout seems to be handled correctly in that application.

Hm, I just noticed my cool-retro-term package does not depend on anything called ubuntu-terminal-app. Was this just another client for comparison? I took it to be both the library and client implementation, so I forwarded this issue there. I could not get a hold of a software by that name, but now I installed http://kde.org/applications/system/konsole/ (along with 300MB of dependencies o_O), and the keyboard layout seems to be handled correctly in that application.
eigengrau commented 2014-09-15 15:13:31 +02:00 (Migrated from github.com)
Copy Link

This was «konsole» ver. 4.14.0, by the way. Not sure whether this also uses the same Qt5 stuff you guys are using.

This was «konsole» ver. 4.14.0, by the way. Not sure whether this also uses the same Qt5 stuff you guys are using.
KAMiKAZOW commented 2014-09-15 20:25:34 +02:00 (Migrated from github.com)
Copy Link

@eigengrau: CRT's Konsole engine is an embedded fork. KDE Konsole does not have QML integration, yet (AFAIK at least).

@eigengrau: CRT's Konsole engine is an embedded fork. KDE Konsole does not have QML integration, yet (AFAIK at least).
Swordfish90 commented 2014-09-15 23:36:03 +02:00 (Migrated from github.com)
Copy Link

Sorry for the late response but I've just got home. Anyway you got almost the exact situation here. We are not using any external dependencies we have our own fork of konsole. This fork is taken from ubuntu-terminal-app which in turn was taken from konsole 4.14. There is still an important piece of the puzzle: one month ago (when I wrote the message) there were clearly two realities (my project and upstream); now since I'm working with them for the terminal app this division is much more blurred. This means that I can't push the issues upstream anymore because I will push them back to myself.

That said, the best place to fix this is now here (we can merge the fix later upstream) and the best way to fix it is taking the konsole 14.04 source.

Also @KAMiKAZOW is right. There are currently no better QML terminal emulator to use as a base.

Sorry for the late response but I've just got home. Anyway you got almost the exact situation here. We are not using any external dependencies we have our own fork of konsole. This fork is taken from ubuntu-terminal-app which in turn was taken from konsole 4.14. There is still an important piece of the puzzle: one month ago (when I wrote the message) there were clearly two realities (my project and upstream); now since I'm working with them for the terminal app this division is much more blurred. This means that I can't push the issues upstream anymore because I will push them back to myself. That said, the best place to fix this is now here (we can merge the fix later upstream) and the best way to fix it is taking the konsole 14.04 source. Also @KAMiKAZOW is right. There are currently no better QML terminal emulator to use as a base.
Swordfish90 commented 2015-01-24 22:08:37 +01:00 (Migrated from github.com)
Copy Link

@eigengrau I have no updates on this issue. Plenty has changed since this was reported (including a rewrite on the engine) could you please try this again and let me know if the issue is still reproducible?

@eigengrau I have no updates on this issue. Plenty has changed since this was reported (including a rewrite on the engine) could you please try this again and let me know if the issue is still reproducible?
eigengrau commented 2015-01-25 11:18:25 +01:00 (Migrated from github.com)
Copy Link

Sure! I’m happy to check it out again. 1.0.0 looks sweet; congrats. As for the keyboarding issues, this seems to be unchanged. I. e., level-4 «Enter» produces U+10AD13, level-4 «KP_4» is misinterpreted as «KP_LEFT».

I also noticed some characters on level-3 require that level-3 shift is triggered twice. E. g., for «{» to show (which is on Mod3 + «e»), I have to type Mod3 - Mod3 + «e». Below is the xev output for this key.

KeyPress event, serial 33, synthetic NO, window 0x3200001,
    root 0x2a2, subw 0x0, time 7655338, (618,653), root:(1579,654),
    state 0x0, keycode 51 (keysym 0xfe0e, ISO_Last_Group), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x3200001,
    root 0x2a2, subw 0x0, time 7655442, (618,653), root:(1579,654),
    state 0x22, keycode 40 (keysym 0x7b, braceleft), same_screen YES,
    XLookupString gives 1 bytes: (7b) "{"
    XmbLookupString gives 1 bytes: (7b) "{"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3200001,
    root 0x2a2, subw 0x0, time 7655554, (618,653), root:(1579,654),
    state 0x22, keycode 40 (keysym 0x7b, braceleft), same_screen YES,
    XLookupString gives 1 bytes: (7b) "{"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3200001,
    root 0x2a2, subw 0x0, time 7655906, (618,653), root:(1579,654),
    state 0x22, keycode 51 (keysym 0xfe02, ISO_Level2_Latch), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

I’ve also noticed some Xcomposé sequences are not fully input if the sequence produces more than one character, and will show only the first character. E. g., «Composé - k - o - a - l - a» produces the string «ʔ • ᴥ • ʕ». In cool-retro-term, only «ʔ» will appear.

Lastly, some keys that should be dead produce unrelated characters. E. g., my «↻» key is a dead key, but in cool-retro-term, it will produce the character «ȣ». Below is the xev output for «↻».

KeyPress event, serial 33, synthetic NO, window 0x3200001,
    root 0x2a2, subw 0x0, time 8135962, (519,653), root:(1480,654),
    state 0x0, keycode 66 (keysym 0xff7e, Mode_switch), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x3200001,
    root 0x2a2, subw 0x0, time 8136018, (519,653), root:(1480,654),
    state 0x22, keycode 49 (keysym 0x10021bb, U21BB), same_screen YES,
    XLookupString gives 3 bytes: (e2 86 bb) "↻"
    XmbLookupString gives 3 bytes: (e2 86 bb) "↻"
    XFilterEvent returns: True

KeyRelease event, serial 33, synthetic NO, window 0x3200001,
    root 0x2a2, subw 0x0, time 8136218, (519,653), root:(1480,654),
    state 0x22, keycode 49 (keysym 0x10021bb, U21BB), same_screen YES,
    XLookupString gives 3 bytes: (e2 86 bb) "↻"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3200001,
    root 0x2a2, subw 0x0, time 8136266, (519,653), root:(1480,654),
    state 0x22, keycode 66 (keysym 0xfe02, ISO_Level2_Latch), same_screen YES,
    XKeysymToKeycode returns keycode: 51
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
Sure! I’m happy to check it out again. 1.0.0 looks sweet; congrats. As for the keyboarding issues, this seems to be unchanged. I. e., level-4 «Enter» produces U+10AD13, level-4 «KP_4» is misinterpreted as «KP_LEFT». I also noticed some characters on level-3 require that level-3 shift is triggered twice. E. g., for «{» to show (which is on Mod3 + «e»), I have to type Mod3 - Mod3 + «e». Below is the xev output for this key. ``` KeyPress event, serial 33, synthetic NO, window 0x3200001, root 0x2a2, subw 0x0, time 7655338, (618,653), root:(1579,654), state 0x0, keycode 51 (keysym 0xfe0e, ISO_Last_Group), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x3200001, root 0x2a2, subw 0x0, time 7655442, (618,653), root:(1579,654), state 0x22, keycode 40 (keysym 0x7b, braceleft), same_screen YES, XLookupString gives 1 bytes: (7b) "{" XmbLookupString gives 1 bytes: (7b) "{" XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x3200001, root 0x2a2, subw 0x0, time 7655554, (618,653), root:(1579,654), state 0x22, keycode 40 (keysym 0x7b, braceleft), same_screen YES, XLookupString gives 1 bytes: (7b) "{" XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x3200001, root 0x2a2, subw 0x0, time 7655906, (618,653), root:(1579,654), state 0x22, keycode 51 (keysym 0xfe02, ISO_Level2_Latch), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False ``` I’ve also noticed some Xcomposé sequences are not fully input if the sequence produces more than one character, and will show only the first character. E. g., «Composé - k - o - a - l - a» produces the string «ʔ • ᴥ • ʕ». In cool-retro-term, only «ʔ» will appear. Lastly, some keys that should be dead produce unrelated characters. E. g., my «↻» key is a dead key, but in cool-retro-term, it will produce the character «ȣ». Below is the xev output for «↻». ``` KeyPress event, serial 33, synthetic NO, window 0x3200001, root 0x2a2, subw 0x0, time 8135962, (519,653), root:(1480,654), state 0x0, keycode 66 (keysym 0xff7e, Mode_switch), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x3200001, root 0x2a2, subw 0x0, time 8136018, (519,653), root:(1480,654), state 0x22, keycode 49 (keysym 0x10021bb, U21BB), same_screen YES, XLookupString gives 3 bytes: (e2 86 bb) "↻" XmbLookupString gives 3 bytes: (e2 86 bb) "↻" XFilterEvent returns: True KeyRelease event, serial 33, synthetic NO, window 0x3200001, root 0x2a2, subw 0x0, time 8136218, (519,653), root:(1480,654), state 0x22, keycode 49 (keysym 0x10021bb, U21BB), same_screen YES, XLookupString gives 3 bytes: (e2 86 bb) "↻" XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x3200001, root 0x2a2, subw 0x0, time 8136266, (519,653), root:(1480,654), state 0x22, keycode 66 (keysym 0xfe02, ISO_Level2_Latch), same_screen YES, XKeysymToKeycode returns keycode: 51 XLookupString gives 0 bytes: XFilterEvent returns: False ```
eveninglily commented 2016-03-03 03:55:34 +01:00 (Migrated from github.com)
Copy Link

Hello! I see the last update to this was over a year ago, figured I should pop in and ask if anything has changed in terms of this bug, I was triaging bugs in ubuntu-terminal-app where an upstream for this was reported ( https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1369531 ), and I figured I should see if I could get any info about this to see if it's fixed

Hello! I see the last update to this was over a year ago, figured I should pop in and ask if anything has changed in terms of this bug, I was triaging bugs in ubuntu-terminal-app where an upstream for this was reported ( https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1369531 ), and I figured I should see if I could get any info about this to see if it's fixed
eigengrau commented 2016-03-07 15:22:05 +01:00 (Migrated from github.com)
Copy Link

Hello! I see the last update to this was over a year ago, figured I should pop in and ask if anything has changed in terms of this bug, I was triaging bugs in ubuntu-terminal-app where an upstream for this was reported ( https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1369531 ), and I figured I should see if I could get any info about this to see if it's fixed

Hi! I checked again using cool-retro-term 9e62978 (qmltermwidget 0.1.0) and I can still reproduce these observations.

> Hello! I see the last update to this was over a year ago, figured I should pop in and ask if anything has changed in terms of this bug, I was triaging bugs in ubuntu-terminal-app where an upstream for this was reported ( https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1369531 ), and I figured I should see if I could get any info about this to see if it's fixed Hi! I checked again using cool-retro-term 9e62978 (qmltermwidget 0.1.0) and I can still reproduce these observations.
eigengrau commented 2016-03-07 15:23:32 +01:00 (Migrated from github.com)
Copy Link

Oh, FWIW, I’ve noticed that other QT clients (with non-terminal, regular widgets) also produce similar issues. At least text entry fields in Calibre did.

Oh, FWIW, I’ve noticed that other QT clients (with non-terminal, regular widgets) also produce similar issues. At least text entry fields in Calibre did.
eigengrau commented 2016-04-01 10:49:52 +02:00 (Migrated from github.com)
Copy Link

@McIntireEvan It seems that these issues stem from my keyboard layout using xkb redirects to implement the affected keys. I noticed this when similar issues turned up in an application using libxkbcommon, and I found that libxkbcommon’s implementation of xkb removed support for redirects. After editing the layout to not generate redirect actions for these keys, they started working in cool-retro-term as well.

So, if we remove xkb redirects from the picture, the only issue left for #11 is that multi-character composé sequences are truncated to the first character. Can’t tell whether this issue resides in cool-retro-term or upstream, though.

@McIntireEvan It seems that these issues stem from my keyboard layout using xkb redirects to implement the affected keys. I noticed this when similar issues turned up in an application using libxkbcommon, and I found that libxkbcommon’s implementation of xkb removed support for redirects. After editing the layout to not generate redirect actions for these keys, they started working in cool-retro-term as well. So, if we remove xkb redirects from the picture, the only issue left for #11 is that multi-character composé sequences are truncated to the first character. Can’t tell whether this issue resides in cool-retro-term or upstream, though.
almindor commented 2020-01-09 18:01:16 +01:00 (Migrated from github.com)
Copy Link

I'm getting a similar problem as well with backspace for example (return works tho), it registers as "u" for some reason.

It might be related to raw mode tho, as my app uses raw mode.

I'm getting a similar problem as well with backspace for example (return works tho), it registers as "u" for some reason. It might be related to raw mode tho, as my app uses raw mode.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bounty
bug
duplicate
enhancement
help wanted
invalid
priority
high
priority
low
question
wontfix
No Label
bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
seeseemelk
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: seeseemelk/cool-retro-term#11
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?