Slow input in far2l ttyxi running under WSL

[Dazzar56]

In console version of far2l running under WSL in ttyxi mode, reaction to keypresses is much slower than when in

1. the same version on Linux system
2. graphical far2l version under WSL
3. the original Far for Windows

Steps to reproduce:

1. install package far2l-ttyx
2. run far2l --tty in Windows Terminal under WSL (use version with ttyxi module)
3. try to press some keys, or press a key and hold it

Expected behavior: instant reaction to keypresses
Observed behavior: noticeable delay before reaction

[Dazzar56]

Found two ways around this problem:

1. use regular far2l package with --tty option.
2. use --nodetect option with far2l-ttyx or portable package

In both cases reaction is instant

[unxed]

use regular far2l package with --tty option.

You meant "without far2l-ttyx ppa package installed", I guess :)

[Dazzar56]

You meant "without far2l-ttyx ppa package installed", I guess :)

Yes, of course it has to be removed

[atolismesh]

May be it is related - after fixing arrow keys autorepeat under wslg, far2l --tty under wsl2 continues show delay, but arrow keys autorepeat now visualy jumps every 3-4 lines, not every 1 line

[unxed]

Very interesting, as tyyxi module which cause this bug have not been changed.

Btw, --nodetect option should still solve it.

[atolismesh]

Yes, --nodetect solves for me the issue with jumps every 3-4 lines under far2l --tty

[elfmz]

Looks Xi just doesn't work under WSL. Everything initialized OK - from XOpenDisplay to XISelectEvents, BUT no key events are arrived at all, so code that checks keydowns waits each time until 100msec timeout. In overall it looks like wslg bug - they must either report failure to setup key events hooks either handle it correctly. But they report OK, but not delivering events then..

[elfmz]

So --nodetect is perfectly fine, anyway it doesnt work right now

[elfmz]

However since win32 terminal works through this - #1581 so no need to use Xi anyway

[unxed]

Maybe we can somehow determine exactly the X server used in Windows and do not enable xi for it?

[elfmz]

no, just need to skip using Xi for key events if found that terminal uses some extensions

[elfmz]

may test now

[atolismesh]

Just tested with new commit (FAR2L, version 2.5.0-15b81623-beta Linux x86_64).
Now tty version working optimally.

[atolismesh]

The GUI version has a slightly larger delay (by 20-25%) than the tty version.

[elfmz]

I dont know, as in my Ubuntu inside of Win11 inside of VMWare inside of Win2008r2 running on i7 3770 they both similary quite sluggish..

[elfmz]

BTW i see that mouse essentially is not working in far2l --tty as terminal sends some weird sequences instead of mouse events that far2l doesn't recognize. Is anybody else see same issue?

[unxed]

It's a known Windows Terminal bug. They pack mouse escape sequences into win32-input-mode key events!
microsoft/terminal#15083

Maybe we should make some kind of workaround for filtering such sequences or even converting them back to normal ones, but that's a bit too hard for me.

[elfmz]

Ugh, i spent whole hour trying to understand that encoding of mouse events, didnt expect that its their bug.. If so dont make sense to worry IMHO, let them fix it.

[elfmz]

Closing then as actual bug about slowness is fixed

[unxed]

spent whole hour

Also fiddled with this problem for a long time, until I realized what was the matter. Considering that I don’t even have Windows, and we caught it with colleagues from the far2l chat remotely.

[unxed]

actually fixed in #2043