-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ttyx[i] module replacement for Wayland API #2040
Comments
Input delay bug under Wayland was also probably described here. As Xi is not used in advanced input modes, input delay bug is not present in kovidgoyal's kitty. |
Wayland console clipboard access tool sources for reference: |
Тут подумал: нам же, вроде бы, только нажатия клавиш-модификаторов слушать нужно? В чем, собственно говоря, угроза безопасности, если разрешать слушать глобально только их? Это бы и нам нормальный UX вернуло бы, и не давало бы такой дыры в безопасности, как в KWin хотят сделать, разрешив слушать через xwayland что угодно. Может, разработчикам предложить? |
XQueryPointer() под Wayland молчит, увы. Не хочет отдавать состояние альтов и контролов. Тут ещё одна идейка пришла в голову. Чтобы починить самые нужные кнопкосочетания тем, кому очень хочется гонять именно скажем в GNOME Terminal или Konsole, можно сделать так: в системные горячие клавиши прописывать на эти комбинации запуск бинарника far2l с какими-нибудь ключиками, передающими через некий IPC активному в данный момент фару, что нажата такая-то комбинация. Фар проверяет, падало ли недавно что-то в терминал, ну и если падало, уточняет событию состояние модификаторов, ну как мы сейчас делаем, собственно. Можно причём сам far2l научить самостоятельно прописывать нужные настойки для основных DE, если пользователь попросит (по ключику командной строки или кнопкой в меню настроек клавиатуры где-нибудь). Финт конечно своеобразный, но кому-то может очень сильно жизнь облегчить. |
Тут подумал. Ведь среды рабочего стола как-то перехватывают под Wayland глобальные хоткеи! Значит, принципиальная возможность это сделать должна существовать. Похоже, для этого нужно стучаться в композитор и просить отдавать события клавиатуры у него. Возможно, перед этим каким-то образом нужно будет получить какие-то дополнительные разрешения. |
Perhaps I was too hasty in reporting that implementing keyboard input similar to ttyxi under Wayland is fundamentally impossible. A similar request came from application developers requiring a global key combination for the PushToTalk function and is currently being discussed in the Wayland bug tracker. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/73 @elfmz could you please add far2l's wishes for the required functionality there? |
This protocol may eventually make xi working on XWayland, so we need some code to check if it is supported and do not disable xi in such cases. https://wayland.app/protocols/xwayland-keyboard-grab-unstable-v1
This protocol probably could be used to implement exclusive key combinations handling. https://wayland.app/protocols/keyboard-shortcuts-inhibit-unstable-v1 |
Иными словами, будто бы ttyxi модуль на Wayland системах через XWayland скоро должен начать работать. См. первую из двух ссылок выше. Но оно ещё не стабильное, и поддержки в композиторах пока может и не быть. Но если будет, надо ещё будет придумать способ определять, поддерживается ли эта штука, и на всякий случай иметь опцию ручного отключения xi, чтобы там, где не поддерживается, он задержки ввода не вносил |
О, кажется, оно есть в KDE и GNOME! https://bugs.kde.org/show_bug.cgi?id=455159 https://bugzilla.gnome.org/show_bug.cgi?id=783342 Интересно, а чего xi не работал у нас под Wayland тогда? @elfmz можете, пожалуйста, глянуть? И, если у нас теперь есть трекинг фокуса, почему бы не слушать вообще весь ввод иксов, когда мы точно знаем, что фокус на терминале? Можно даже переключить фокус с текущего окна на любое другое, и тут же обратно, через X11 API по старое, чтобы терминал сообщил текущее состояние, а то не все это делают при включении режима отслеживания фокуса. |
Ага, в GNOME оно должно быть, но надо включать вручную:
Тут некоторые подробности: А в KDE я собственно баг с задержками ввода и не пытался воспроизводить, кажется. |
Такая настройка в ванильном Ubuntu 24.04 действительно есть, по умолчанию false. Но даже с true xi у меня не заработал, и под sudo тоже, и после перезагрузки тоже. Должно работать, но, почему-то, не работает. Реквестую помощь зала! |
Написал тикет в Mutter |
И в Muffin (это у меня в Mint/Cinnamon). Там вообще пока поддержки нет, вот сделал тикет чтоб добавили: |
Выяснил, что там надо ещё в whitelist добавлять WM_CLASS (который для начала надо для xi модуля ещё выставить. Или вот такое делать: btw, заставить это всё работать пока всё равно не получилось. |
Еееееее у меня получилось заставить перехват работать в KDE на 24.10 (Wayland там впервые по умолчанию в KDE) без каких-то специальных настроке DE. Перехватывается всё, кроме букв. Вот код тестового приложения:
|
Не подходит нам метод c XGrabKeyboard всё же. Grab может делать только одно приложение в единицу времени. Несколько экземпляров фара не смогут работать параллельно :( |
We probably won't be able to listen to all keyboard events in Wayland like we do in X11/Xi (this is also evidenced by the fact that ttyxi keyboard capabilities don't work in GNOME Terminal on Ubuntu 23.10, where Wayland is the default; instead they only introduce input delays). However, we can at least detect the presence of Wayland so as not to unnecessarily activate delay-causing x11-related code. And we can still work with the clipboard through the Wayland API.
Alternative solution would be to use tools like wlclip along with this workaround, still don't know what to do with input delays. Also possible solution for Wayland-only systems is to use OSC52- and extended keyboard input mode supporting terminal emulatior, like kovidgoyal's kitty: all keys supported, no input delays, no x11 code needed for accessing clipboard, but still a little problem persists, see #2039
UPD: Using
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.
The text was updated successfully, but these errors were encountered: