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

unxed · 2024-03-05T10:09:15Z

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:

install fresh ubuntu 23.10 from

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

install far2l:

sudo apt install far2l

run GNOME Terminal
run far2l inside
press Arrow Up or Arrow Down keys several times being inside a non-empty folder
run far2l --nodetect=xi
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:
#2040

The text was updated successfully, but these errors were encountered:

unxed · 2024-03-05T10:13:44Z

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 · 2024-03-05T20:44:58Z

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 · 2024-03-07T21:56:02Z

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.

Fix for #2041

unxed · 2024-03-10T13:17:34Z

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

akruphi · 2024-03-10T13:19:53Z

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 · 2024-03-10T13:26:20Z

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

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

unxed · 2024-03-10T13:38:41Z

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

akruphi · 2024-03-10T13:48:54Z

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

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

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

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

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

unxed · 2024-03-10T14:14:20Z

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

unxed · 2024-03-10T16:10:20Z

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

unxed · 2024-03-11T13:54:40Z

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 · 2024-04-28T00:15:49Z

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

unxed · 2024-05-30T22:06:13Z

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

unxed changed the title ~~disable ttyx[i] input processing (but not clipboard access!) under wayland~~ disable ttyxi input processing (but not clipboard access!) under wayland Mar 5, 2024

unxed mentioned this issue Mar 5, 2024

ttyx module replacement for Wayland API #2040

Open

akruphi mentioned this issue Mar 6, 2024

COPY/PAST is not working for applications supported XCLIP shmuz/far2m#53

Closed

akruphi mentioned this issue Mar 10, 2024

Fix for #2041 #2043

Merged

elfmz added a commit that referenced this issue Mar 10, 2024

Merge pull request #2043 from unxed/minor-fix

a22cddd

Fix for #2041

unxed closed this as completed Mar 10, 2024

unxed mentioned this issue Mar 10, 2024

make input wait timeouts in ttyxi customizable; default to 100ms for ssh #2056

Open

unxed mentioned this issue Mar 18, 2024

Ctrl+1,2,3..0 do not work in ttyxi in GNome Terminal on Wayland systems #2042

Closed

This was referenced Apr 15, 2024

Ubuntu 24.04 LTS preparations #2088

Closed

Wayland issues left — metabug #2158

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

unxed commented Mar 5, 2024 •

edited

Loading

unxed commented Mar 5, 2024 •

edited

Loading

unxed commented Mar 5, 2024 •

edited

Loading

viklequick commented Mar 7, 2024

unxed commented Mar 10, 2024 •

edited

Loading

akruphi commented Mar 10, 2024

akruphi commented Mar 10, 2024

unxed commented Mar 10, 2024

akruphi commented Mar 10, 2024

unxed commented Mar 10, 2024 •

edited

Loading

unxed commented Mar 10, 2024

unxed commented Mar 11, 2024 •

edited

Loading

unxed commented Apr 28, 2024

unxed commented May 30, 2024

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

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

Comments

unxed commented Mar 5, 2024 • edited Loading

unxed commented Mar 5, 2024 • edited Loading

unxed commented Mar 5, 2024 • edited Loading

viklequick commented Mar 7, 2024

unxed commented Mar 10, 2024 • edited Loading

akruphi commented Mar 10, 2024

akruphi commented Mar 10, 2024

unxed commented Mar 10, 2024

akruphi commented Mar 10, 2024

unxed commented Mar 10, 2024 • edited Loading

unxed commented Mar 10, 2024

unxed commented Mar 11, 2024 • edited Loading

unxed commented Apr 28, 2024

unxed commented May 30, 2024

unxed commented Mar 5, 2024 •

edited

Loading

unxed commented Mar 5, 2024 •

edited

Loading

unxed commented Mar 5, 2024 •

edited

Loading

unxed commented Mar 10, 2024 •

edited

Loading

unxed commented Mar 10, 2024 •

edited

Loading

unxed commented Mar 11, 2024 •

edited

Loading