Buffered keyboard inputs are continue to be dispatched to newly started application in X

Environment

Windows build number: 21382
Your Distribution version: Ubuntu 20.04, 20.10 and 21.04
Your WSLg version: 1.0.19

Steps to reproduce

Open emacs from a terminal, such as Windows Terminal

Use ctrl-x ctrl-c to close emacs

Reopen the terminal, and click the text-entry butter and "c" will repeat over and over until you press "ctrl-c"

This will persist upon reopening, until: You press "ctrl-c again" or
you restart WSL with wsl --shutdown

Expected behavior

I expect "ctrl-x ctrl-c" to gracefully exit the program, without resulting in something being hung, which waits for the next ctrl-c to stop the key entry.

Actual behavior

See attached screenshot

I am also experiencing this issue.
Here is my uname -a
Linux chrishome 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
My Windows 10 is Build 21382.co_release.210511-1415. WSL version 1.0.19

Hi, thanks for reporting issue! I would like to clarify the reproduce step,

1: Use ctrl-x ctrl-c to close emacs (not terminal) ?
2: Reopen the emacs (not terminal?), and click the text-entry butter and "c" will repeat over and over until you press "ctrl-c"

Thus basically I tried launching and closing emacs twice in row, but I do not encounter this issue. Am I missing something ?thanks!

1: Use ctrl-x ctrl-c to close emacs (not terminal) ?

Yes. I am not aware of a default key-binding to close a terminal that uses 'ctrl-x ctrl-c'.

2: Reopen the emacs (not terminal?), and click the text-entry butter and "c" will repeat over and over until you press "ctrl-c"

Yes, emacs.

Thus basically I tried launching and closing emacs twice in row, but I do not encounter this issue. Am I missing something ?thanks!

You can avoid it with carefully placed mouse clicking. I don't know exactly what you are doing, so it's hard to say.

Hideyuki Nagase (@hideyukn88)

Hideyuki Nagase (@hideyukn88) For your question 1, that is the default for closing emacs, not the terminal.
Try this:

Open the emacs GUI via emacs.
Close emacs by Ctrl-x ctrl-c
Reopen emacs GUI and click in the GUI.

I just did this and got the offending behavior just now.

Hideyuki Nagase (@hideyukn88)

Hideyuki Nagase (@hideyukn88) I didn't realize what you may have suggested until Christopher Blanton (@chrisblanton) made his comment. Using "ctrl-c" to terminate a program on the command line of a terminal would kill emacs.

Ctrl-x Ctrl-c is how you exit emacs, gracefully. Ctrl-C passes SIGINT, which will interrupt and kill emacs, in this case. That is not what we are talking about.

Thanks, so this is what I did.

1: from gnome-terminal, 'emacs -nw' - this opens emacs inside gnome-terminal.
2: 'M-&' and type 'emacs &' - this opens emacs GUI. Is this what you mean by "Open the emacs GUI via emacs." ?
3: 'C-x' 'C-c' on emacs on gnome-terminal.
4: it asks "active process exist", answer 'yes'.
5: then both emacs (on gnome-terminal) and emacs GUI terminated.
6: So how do I open emacs GUI ? I typed 'emacs &' on gnome-terminal, it looks come up fine and no repeated 'c' issue observed.

I guess I'm still missing something...

Thanks!

Hideyuki Nagase (@hideyukn88)

Hideyuki Nagase (@hideyukn88) That is not reproducing the steps. No where is it being said to open a window less instance of emacs inside a terminal, and the launch another instance of emacs from inside of that.

Also, it was a typo in the original post that has been fixed that said "close the terminal with ctrl-x ctr-c"

That is the keybinding to close emacs.

EricPell

EricPell , I would like to understand the more precise repro step (such as exact command/key input), if you can provide that, very appreciated, thanks!

I appologize for my prior comment, and that I made a typo in the original post that has been fixed that said "close the terminal with ctrl-x ctr-c"

That is the key binding to close emacs. I assume you are familiar with emacs?

Hideyuki Nagase (@hideyukn88)

Hideyuki Nagase (@hideyukn88) I was able to capture a screen shot that will help. The input that is being repeated is ctrl-c. It happened when I did NOT click on the emacs window. I left the screenshot below. It should help that emacs recorded what happened automatically.

EricPell

EricPell , would you please check weston.log at /mnt/wslg and if the log has below message when this occurred ? thanks!

Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!

Hideyuki Nagase (@hideyukn88)

Hideyuki Nagase (@hideyukn88) No, that is not there. But there are thousands of repeats of the following:

[20:41:58.653] shell_blend_overlay_icon: app 48x48; overlay 128x128; scale 4.67x4.67
[20:41:58.653] rdp_rail_set_window_icon: original icon width:48 height:48 format:537036936
[20:41:58.653] rdp_rail_set_window_icon: converted icon width:48 height:48 format:537036936
[20:41:58.726] Client: ClientGetAppidReq: pid:8690 appId:Emacs
[20:41:58.727] shell_blend_overlay_icon: app 48x48; overlay 128x128; scale 4.67x4.67
[20:41:58.727] rdp_rail_set_window_icon: original icon width:48 height:48 format:537036936
[20:41:58.727] rdp_rail_set_window_icon: converted icon width:48 height:48 format:537036936
[20:43:07.572] Client: clipboard_client_format_list clipboard format list: numFormats:4
[20:43:07.572] Client: clipboard_client_format_list clipboard formats[0]: formatId:13, formatName:CF_UNICODETEXT
[20:43:07.572] Client: clipboard_client_format_list clipboard formats[1]: formatId:16, formatName:CF_LOCALE
[20:43:07.572] Client: clipboard_client_format_list clipboard formats[2]: formatId:1, formatName:CF_TEXT
[20:43:07.572] Client: clipboard_client_format_list clipboard formats[3]: formatId:7, formatName:CF_OEMTEX
[20:43:07.572] Client: clipboard_client_format_list (0x7f77cc000c60) allocated
[20:43:07.572] Client: clipboard_client_format_list (0x7f77cc000c60) mine_type:"text/plain;charset=utf-8"
[20:43:07.572] RDP clipboard_data_source_publish (0x7f77cc000c60)
[20:43:07.572] RDP clipboard_data_source_cancel (0x7f77cc000de0)
[20:43:07.572] RDP clipboard_data_source_send (0x7f77cc000c60) fd:97, mime-type:"text/plain;charset=utf-8"
[20:43:07.572] RDP clipboard_data_source_send (0x7f77cc000c60) request index:0 formatId:1 CF_TEXT
[20:43:07.572] RDP clipboard_set_selection (base:0x7f77cc000c60}
[20:43:07.572] RDP clipboard_data_source_unref (0x7f77cc000de0): refcount:0
[20:43:07.575] Client: clipboard_client_format_data_response (0x7f77cc000c60) flags:2, dataLen:0
[20:43:07.575] RDP clipboard_data_source_unref (0x7f77cc000c60): refcount:1
[20:43:07.623] Client: clipboard_client_format_list clipboard format list: numFormats:4
[20:43:07.623] Client: clipboard_client_format_list clipboard formats[0]: formatId:13, formatName:CF_UNICODETEXT
[20:43:07.623] Client: clipboard_client_format_list clipboard formats[1]: formatId:16, formatName:CF_LOCALE
[20:43:07.623] Client: clipboard_client_format_list clipboard formats[2]: formatId:1, formatName:CF_TEXT
[20:43:07.623] Client: clipboard_client_format_list clipboard formats[3]: formatId:7, formatName:CF_OEMTEX
[20:43:07.623] Client: clipboard_client_format_list (0x7f77cc000de0) allocated
[20:43:07.623] Client: clipboard_client_format_list (0x7f77cc000de0) mine_type:"text/plain;charset=utf-8"
[20:43:07.623] RDP clipboard_data_source_publish (0x7f77cc000de0)
[20:43:07.623] RDP clipboard_data_source_cancel (0x7f77cc000c60)
[20:43:07.624] RDP clipboard_data_source_send (0x7f77cc000de0) fd:97, mime-type:"text/plain;charset=utf-8"
[20:43:07.624] RDP clipboard_data_source_send (0x7f77cc000de0) request index:0 formatId:1 CF_TEXT
[20:43:07.624] RDP clipboard_set_selection (base:0x7f77cc000de0}
[20:43:07.624] RDP clipboard_data_source_unref (0x7f77cc000c60): refcount:0
[20:43:07.651] Client: clipboard_client_format_data_response (0x7f77cc000de0) flags:1, dataLen:2385
[20:43:07.652] RDP clipboard_data_source_write (0x7f77cc000de0) write completed (2384 bytes)
[20:43:07.652] RDP clipboard_data_source_unref (0x7f77cc000de0): refcount:1

EricPell

EricPell , thanks for checking, I realized that the message I pointed is from X server, so it's not captured in weston.log, sorry for confusion. now I am able to reproduce the issue, it looks the key inputs are buffered, and remains even after application is terminated, then flushed once application is relaunched. And it looks the buffering is done either at X server or weston compositor, but not at RDP backend nor Windows side. Further investigation is required, thanks for report and helping for reproduce step!

Hideyuki Nagase (@hideyukn88)

Hideyuki Nagase (@hideyukn88) Thank you for looking into this. We all appreciate how fast you all respond to issues.

And I'm sorry I was confused and perhaps impolite earlier. I didn't mean to be.

A good simple test case is "xev" which prints all X11 events in its window. Just start it up, and it'll print keyboard events continuously. Normal behavior is it should print nothing until mouse enters/leaves, or you type in its window.

Could you give a try to the updated version of WSLg shipping with the new WSL package in the Windows Store. It contains the fix to properly reset the keyboard state which should eliminate those key repeats. There remains a known issue with crtl/shift/alt key where they might end up in the wrong state and where you have to hit it again to get it reset to the right state. This is understood and an issue in msrdc, but we don't yet have a fix.

You can try the latest version of WSL in the store by following this link.

And for more info take a peek at our blog on this.

Keldon Alleyne (@avasopht)

I first installed the latest WSLg from https://github.com/microsoft/wslg/releases/download/v1.0.28/wsl_graphics_support_x64.msi, and that did not fix it for me. But your WSL preview link does fix the main issue, and I confirm the CTRL issue is still present. I will continue to use the emacs workaround from Keldon Alleyne (@avasopht) -- thanks for that!

Could you give a try to the updated version of WSLg shipping with the new WSL package in the Windows Store. It contains the fix to properly reset the keyboard state which should eliminate those key repeats.

It now works for me on my test program. Plus, the update experience to the new WSL package from the Windows Store has been seamless thus far. Thank you.

This issue is kept opened to track "stuck modifier key issue" discussed at #207 (comment) until the fix, which will be made in Windows RDP client software, msrdc.exe bundled in Store version of WSL, to be released.

Hideyuki Nagase (@hideyukn88)

Hideyuki Nagase (@hideyukn88) Hi,

Is there a github (or anywhere else) an issue for the RDP client software?
If so, can you please drop it here, so we can track it more easily? :)

Thank you!

Hi,

Is there any ETA for the fix?
Still waiting to switch to WSL2.0 because of this :/

Thnak you!

Mátyás Szombathy (@Re4zOon)

Mátyás Szombathy (@Re4zOon), internally the fix is already integrated to WSLg, so the next release of WSLg will have the fix, thanks!

Mátyás Szombathy (@Re4zOon)

Mátyás Szombathy (@Re4zOon), internally the fix is already integrated to WSLg, so the next release of WSLg will have the fix, thanks!

Any idea of when WSLg next be released? My Windows11 PC has a last-modified date of June 5, 2021 7:06 AM, file version 10.0.22000.1:

(C:\Windows\System32\wslg.exe)

Is there a way to get the update manually sooner than general release?

Mátyás Szombathy (@Re4zOon)

Mátyás Szombathy (@Re4zOon), Daniel A Glasser (@FilkerZero), now the WSL with the fixed is released from Store app, please update your WSL from aka.ms/wslstorepage. And you can double check you have fixed RDP software by wsl --version, and it should show MSRDC version: 1.2.2924. Btw, there is known issue that older mstsc.exe is used with WSL instead of msrdc.exe came with WSL. In this case, this buffered key issue still remains, and we are working on this. This is observed when the first instance of WSL is launched from new Windows Terminal Preview. The workaround is to start WSL first with command prompt or Start Menu, then start Windows Terminal Preview to connect WSL. Please let us know how it goes, thanks!

Hideyuki Nagase (@hideyukn88)

Hideyuki Nagase (@hideyukn88) Thank you very much; I followed your directions, and it worked. Seems my WSL2 was out of data ("wsl --version" was not recognized). I haven't seen the keyboard buffer problem getting the updates.

Navigation Menu

Repository navigation

Buffered keyboard inputs are continue to be dispatched to newly started application in X #207

Environment

Steps to reproduce

Expected behavior

Actual behavior

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Buffered keyboard inputs are continue to be dispatched to newly started application in X #207

Description

Environment

Steps to reproduce

Expected behavior

Actual behavior

Activity

chrisblanton commented on May 17, 2021

hideyukn88 commented on May 17, 2021

EricPell commented on May 17, 2021

chrisblanton commented on May 17, 2021

EricPell commented on May 17, 2021

hideyukn88 commented on May 17, 2021

EricPell commented on May 17, 2021

hideyukn88 commented on May 17, 2021

EricPell commented on May 17, 2021

EricPell commented on May 17, 2021

hideyukn88 commented on May 17, 2021

EricPell commented on May 17, 2021

hideyukn88 commented on May 17, 2021

EricPell commented on May 17, 2021

21 remaining items

garyo commented on Nov 18, 2021

spronovo commented on Nov 18, 2021

garyo commented on Nov 18, 2021

damonlynch commented on Nov 18, 2021

hideyukn88 commented on Jan 14, 2022

Re4zOon commented on Jan 27, 2022

Re4zOon commented on Feb 28, 2022

hideyukn88 commented on Mar 7, 2022

FilkerZero commented on Mar 20, 2022

hideyukn88 commented on Mar 21, 2022

FilkerZero commented on Mar 22, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions