disable ttyxi input processing (but not clipboard access!) under wayland

[unxed]

Wayland security model does not allow and app to "listen" keystrokes that belong to other windows. So our x11 API-based input helpers are useless with XWayland. More of this, under Wayland ttyxi introduces severe input delay. Steps to reproduce it:

1. install fresh ubuntu 23.10 from

https://releases.ubuntu.com/23.10.1/ubuntu-23.10.1-desktop-amd64.iso

2. install far2l:

sudo apt install far2l

3. run GNOME Terminal
4. run far2l inside
5. press Arrow Up or Arrow Down keys several times being inside a non-empty folder
6. run far2l --nodetect=xi
7. try keys test once again

Still, ttyx module is helpful for clipboard access. So we should disable ttyx[i] input processing under Wayland automatically, but still use x11 clipboard API.

See also: https://github.com/elfmz/far2l/issues/2040

[unxed]

Probably another symptom of this bug is that you still have to press ESC twice even in ttyxi mode if it's a Wayland session.

So using

--ee --nodetect=xi

makes input in GNOME Terminal working without delay even under Wayland, also clipboard works as expected and one ESC press is enough. Would be great to add whose two switches under Wayland by default.

[unxed]

In fact, XWayland allows you to listen to keyboard events of other applications, but only if these applications also use XWayland: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6170 https://t.me/far2l_ru/13854

So probably this workarounds also might work:

GDK_BACKEND=x11 gnome-terminal

or

QT_QPA_PLATFORM=xcb konsole

or even may be

XDG_SESSION_TYPE=x11 any-terminal-app

etc See also: https://community.kde.org/KWin/Wayland#Forcing_KDE_apps_to_run_as_X11

UPD: made some tests, this does not affect delays actually.

[viklequick]

Few words from the theory.

While running multiple GUI applications, Xorg does not isolate them from each other. Wayland does, which is a more secure approach.

XWayland keyboard grabbing

This protocol is application-specific to meet the needs of the X11 protocol through Xwayland. It provides a way for Xwayland to request all keyboard events to be forwarded to a surface even when the surface does not have keyboard focus. In the X11 protocol, a client may request an "active grab" on the keyboard. On success, all key events are reported only to the grabbing X11 client.

The core Wayland protocol does not have a notion of an active keyboard grab. When running in Xwayland, X11 applications may acquire an active grab inside Xwayland but that cannot be translated to the Wayland compositor who may set the input focus to some other surface. In doing so, it breaks the X11 client assumption that all key events are reported to the grabbing client.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6170

Programs running in XWayland can only read keyboard input if another XWayland program is focused. For example, I have a keybind which automatically mutes my mic in Discord. The keybind does not function when the current focused app is not being displayed with XWayland.

So, wayland apps are not allowed to get global keyboard input via compositor, unless you require some permission and/or directly get keyboard events from device, this is a security feature.

What does it mean at practice?

From Wayland point of view, the active window is the terminal one and it is alone application that should consume the typing keys. So, all "nested" applications should interact with terminal itself to get user input. In other words, the tty Xi module is attempt to break security model of the Wayland.

Fortunately, Wayland have an "exceptional case" names XWayland and it means we have a backdoor to loot the keys without terminal window help. But as every workaround, it might have side effects... like one of in the ticket.

Returning back to the theory, terminal + Far2l should work unless it both launched as XWayland clients, e.g. GDK backend should be enforced to X11 for both applications.

[unxed]

@akruphi это бы документировать! Что под Вэйлендом отключается xi и включается --ee. А кому без xi не хватает работы нужных ему кнопок, пусть под kovidgoyal's kitty гоняют, она в свежих убунтах есть и теперь адекватной версии, ок работающей с фаром.

[akruphi]

Because far2l GUI work properly only under XWayland, may be add in main() at first start additional check and show information message? For example change:

			if( Opt.IsFirstStart )
				Help::Present(L"Far2lGettingStarted",L"",FHELP_NOSHOWERROR);

to

			if( Opt.IsFirstStart ) {
				if (WinPortBackend()==L"GUI") {
					FARString fs1, fs2;
					apiGetEnvironmentVariable("XDG_SESSION_TYPE", fs1);
					apiGetEnvironmentVariable("GDK_BACKEND", fs2);
					if (fs1==L"wayland" && fs2!="x11")
						Message(MSG_WARNING | MSG_LEFTALIGN, 1, L"Far2l 1st run under Wayland",
							L"Under Wayland far2l-GUI work properly in XWayland mode:",
							L" - running from console: GDK_BACKEND=x11 far2l",
							L" - inside desktop entry: Exec=env GDK_BACKEND=x11 far2l",
							L"",
							L"See details in help \"FAR2L features - Getting Started\".",
							L"Continue");
				}
				Help::Present(L"Far2lGettingStarted",L"",FHELP_NOSHOWERROR);
			}

If we decide that this information is necesary let's think up short correct text.

[akruphi]

@akruphi это бы документировать! Что под Вэйлендом отключается xi и включается --ee. А кому без xi не хватает работы нужных ему кнопок, пусть под kovidgoyal's kitty гоняют, она в свежих убунтах есть и теперь адекватной версии, ок работающей с фаром.

Сейчас это частично и немного размазано есть в помощи в разделе @Far2lGettingStarted "FAR2L features - Getting Started" / "Особенности FAR2L - начало работы", но мне не нравится как получилось. Как подправить на более кратко и чётче не соображу.

[unxed]

А что там ломается в GUI на Вэйленде? Я не смотрел ещё. Там-то нет хаков типа слушать весь ввод в системе

[akruphi]

А что там ломается в GUI на Вэйленде? Я не смотрел ещё. Там-то нет хаков типа слушать весь ввод в системе

Насколько я понял (в том числе из жалоб в тг-чате и нескольких issue тут) в GUI без XWayland ни клавиатура полноценно не работает, ни буфер обмена. Т.е. получается ограниченный функционал.

Также как в нынешнем TTY|Xi без XWayland буфер обмена недоступен.

Пока вчерне это описано в https://github.com/akruphi/far2l/wiki#wayland и более кратко в far2l help.

Но я сам Wayland у себя отрубил - сижу довольный в x11 и пока проверять не тянет. К тому же, судя по отзывам, некоторые баги Wayland жутко бесившие на моей Ubuntu 22.04 уже в более свежих не проявляются (возможно пофикшены на стороне Wayland).

[unxed]

Так так так, стопэ, у меня буфер обмена чудесно работает в ttyx без ttyxi, и он так может работать только через xwayland, потому что нативного модуля для клипборда через апи вэйленда пока нет

[unxed]

В Ubuntu 23.10 на far2l-gui из PPA в GUI версии, запущенной в Wayland сессии, никаких тормозов ввода нет. Только что тщательно проверил дважды.

[unxed]

It looks like keyboard event interception may work in Wayland under KWin in some future version. If there is a reliable way to determine KWin, we can add an appropriate condition (after this change is in the version used by default in Ubuntu LTS, probably?).

https://invent.kde.org/plasma/kwin/-/merge_requests/4601

[unxed]

https://bugs.launchpad.net/ubuntu/+source/far2l/+bug/2063919

[unxed]

Fix accepted to Ubuntu 24.04 updates and should be delivered to all users within 56 hours.