LINUX.ORG.RU

Перешёл на KDE 5 + Wayland

 ,


0

2

Переход начался у меня ещё на неттопе с интеловской графикой и 8 Гб RAM в июле. На стационарнике с видеокартой от Nvidia и проприетарными драйверами такая конструкция работать отказалась (Plasma 5.24.6). Возможно, из-за конкретной относительно старой видеокарты. После апгрейда же (AMD Ryzen 9 3900X/64 Гб RAM/AMD Radeon RX 6400/SSD 500 Гб) конструкция KDE 5 + Wayland вполне успешно взлетела.

Почему я задумался о переходе с уютного FVWM'а и иксов? Ну, потому, что Wayland делают сами разработчики иксов на замену иксам, а иксы они больше не развивают. А последнее стало поводом для разработчиков GTK начать обсуждение дропания поддержки иксов в GTK 5: https://www.theregister.com/2022/07/05/gtk_5_might_drop_x11/ . А те же Firefox и Chromium на GTK. Пока что на GTK 3, но в один прекрасный день они доживут до переезда на GTK 5. В общем, уже какое-то время назад стало ясно, что Wayland - это наше будущее независимо от того, хотим мы этого или нет. Вопрос был только в том, насколько это близкое будущее. Так-то и иксы пока что никто не отменял. Но можно заранее подготовиться к этому будущему чтобы потом не метаться в панике, когда поддержка иксов кругом внезапно дропнется.

Что меня огорчило сразу после перехода на KDE 5 + Wayland? Баги создания скриншотов. Рабочим был только один режим создания скриншотов - скриншот окна под курсором. Если бы я не сделал бы патч, то я не смог бы сделать выложенный скриншот. А я патч таки сделал. Для plasma-kwin. 3 режима создания скриншотов спотыкались о нехватку прав для их создания. Мой патч просто-напросто отключил проверку наличия прав на создание скриншотов. Вот он: https://saahriktu.tech/alt/plasma5-kwin-skippermissionscheck.patch .

Рассматривал я и переход на GNOME. Если украсноглазить современный GNOME, то он вполне тянет на замену оконному менеджеру со встроенной скриншотилкой. Т.е. его функционал нынче довольно минималистичен. Однако, возможностей KDE больше и оно реализует более традиционный вид десктопа. Например, из возможностей KDE я ещё использую ускорение колеса прокрутки мыши. Достойная замена иксовому imwheel'у. Кстати, мне не понравилось странное поведение переключалки раскладок GNOME и я её тоже пропатчил. Отключил меню раскладок, которое висит 1,5 секунды (можно ускорить Enter'ом или щелчком мыши). Вот патч: https://saahriktu.tech/alt/gnome-shell-nodelaypopups.patch .

Почему не Sway? Ну, потому, что я и тайловые оконные менеджеры для иксов не осилил, не нравится мне такое. При этом думается, что с эпохой Wayland'а оконными менеджерами продолжат пользоваться только маргиналы, которым мало что нужно. В эпоху иксов между DE и оконными менеджерами разница была только в наборе софта. И идеология оконных менеджеров заключалась в том, что не всем нужны заранее подготовленные набора софта, можно просто отдельные софтины юзать. Но Wayland весь функционал перекладывает на плечи тулкитов и DE. Софтины становятся привязаны к конкретным композиторам (Wayland'овский термин, ага). Например, скриншотилка KDE не работает в GNOME, а скриншотилка GNOME не работает в KDE. И если, например, я хочу юзать скриншотилку KDE, то она тянет за собой всё KDE. Вот такая вот загогулина.

А как же Motif, Tk,... и т.д.? Они же не поддерживают Wayland. Хотя запускаются через Xwayland. Однако, Xwayland могут и дропнуть с наступлением эпохи Wayland'а. Так вот, на том же Motif'е я никогда ничего не писал. А вот тот же PyQt5 вполне тянет на замену Tkinter'у если научиться его готовить. И уже начинают подвозить PyQt6. А в том же Qt Creator'е можно писать и софт на C++ для Qt 6.

Так что, KDE 5 + Wayland вполне можно юзать уже сегодня. Иконки на скриншоте, если что, - kde-1.1.2-new . Изначально хотел допилить значки kdeclassic от KDE 2 (над этим я, кстати, работал ещё во времена KDE 4, но так и не допилил), но потом решил не заморачиваться. Тем более, что они растровые. Хотя можно и перевести в вектор. Но это ещё больше работы.

>>> Просмотр (1920x1080, 1557 Kb)

★★★★★

Проверено: hobbit ()
Ответ на: комментарий от saahriktu

Дык в Wayland’е многое не работает просто потому, что всё это пока ещё просто не перевели на рельсы Wayland’а.

Пытался перелезть на него уже несколько раз, но каждый раз какие-то сложности вылезали. Вот из последнего это какие-то дикие(даже дичайшие) костыли для трансляции экрана с зуме или, прости г-ди, скайпе. А это частенько нужно по работе. У меня коллега из-за этого каждый раз как транслировать нужно «подождите, сейчас перезагружусь в иксы, а то у меня вейланд и трансляция экрана не работает». Ну это же порнография какая-то. Х-ы или Wayland - неважно, но такие базовые вещи должны просто работать. Как молоток. Без костылей.

Loki13 ★★★★★
()
Ответ на: комментарий от Loki13

Это секурность Wayland'а by design, уже писалось выше. Защита от захвата экрана вредоносным софтом, который может отправить потом скриншоты и ролики на сервер товарищу майору.

Во избежание этого экран захватывать может только композитор. А софт должен делать запросы к композитору. А делать эти запросы к композиторам соответствующий софт, вот, пока ещё не успели толком научить.

Но это всё для нашей информационной безопасности.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

Это секурность Wayland’а by design, уже писалось выше. Защита от захвата экрана вредоносным софтом, который может отправить потом скриншоты и ролики на сервер товарищу майору.

Но это всё для нашей информационной безопасности.

Т.е. для гипотетической «безопасности» пары параноиков остальные пользователи должны умыться и терпеть? Вы там реально поехавшие, если ты это на серьёзных щщах пишешь.

agentgoblin
()
Последнее исправление: agentgoblin (всего исправлений: 1)
Ответ на: комментарий от agentgoblin

Почему терпеть-то? Те, кого не устраивает текущий функционал, могут просто подождать на иксах. А те, кому достаточно делать скриншоты руками, могут переходить на Wayland уже сейчас.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

Так а кто мешал сделать это галочкой в настройках «У меня локалхост, мне прятать нечего, дайте мне транслировать наконец!»?

Loki13 ★★★★★
()
Ответ на: комментарий от Loki13

В настройках чего? Wayland - это протокол. В соответствии с которым софт должен делать запросы к композитору. А делать запросы к композиторам, повторяю, соответствующий софт пока ещё не научили.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

В настройках KDE того же, чорт побери! Вот Вы же пропатчили себе отключение секуритей, вот кто мешает это всё нафиг отключить рубильником в systemsettings, чтобы это могли сделать не только те кто патчить умеют?

А делать запросы к композиторам, повторяю, соответствующий софт пока ещё не научили.

Есть опасность, что даже если научат в условном зуме, то не научат в вацаппе или в скайпе и мучения так и останутся мучениями и костылями.

Или нужна одна прослойка, которая будет делать запрос к композитору, а потом давать всем желающим. Наверное лучший выход, хоть и костыль.

Loki13 ★★★★★
()
Последнее исправление: Loki13 (всего исправлений: 2)
Ответ на: комментарий от Loki13

Вот Вы же пропатчили себе отключение секуритей

Конкретно для получения скриншотов тем софтом, который уже знает как делать запросы к kwin для получения скриншотов. А другой софт надо учить делать эти запросы.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

софт должен делать запросы к композитору

Ну и где тут секурность? Залетает к тебе обученный софт, который умеет делать запросы к композитору и точно так же твой экран улетает кому-то. Или там надо пять сертификатов поставить и тысячу разрешений прописать, чтобы это заработало?

agentgoblin
()
Ответ на: комментарий от agentgoblin

При запросе на создание скриншота композитор проверяет есть ли у софтины, которая запросила скриншот, соответствующие права.

Собственно, KDE'шники где-то накосячили в выдаче прав Spectacle. По-хорошему надо было фиксить выдачу этих прав, но самый простой и несекурный способ - отключение проверки наличия прав на создание скриншота (что мой патч и делает).

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

При запросе на создание скриншота композитор проверяет есть ли у софтины, которая запросила скриншот, соответствующие права.

Это звучит уже более-менее вменяемо. Юзер может без танцев с бубном права дать софтине? Как пример, для съёма трафика не от рута я сейчас должен явно дать права утилитке (или это сделает пакетный менеджер в ходе установки):

root@Sandbox# setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

Что-то подобное для создания скринов существует?

agentgoblin
()
Ответ на: комментарий от agentgoblin

В kwin'е, например, проверка прав выполняется таким образом:

bool ScreenShotDBusInterface2::checkPermissions() const
{
    if (!calledFromDBus()) {
        return false;
    }

    const QDBusReply<uint> reply = connection().interface()->servicePid(message().service());
    if (reply.isValid()) {
        const uint pid = reply.value();
        const auto interfaces = KWin::fetchRestrictedDBusInterfacesFromPid(pid);
        if (!interfaces.contains(s_dbusInterface)) {
            sendErrorReply(s_errorNotAuthorized, s_errorNotAuthorizedMessage);
            return false;
        }
    } else {
        return false;
    }

    return true;
}

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

Я не особо могу в плюсы и вероятно не особо понимаю архитектуру взаимодействия, но судя по коду (я даже весь файл на github открыл, чтобы поглядеть откуда это вызывается), тут какая-то ерунда. Получается, что kwin запрашивает разрешения свыше сделать скрин и если оно есть, то берёт и делает. А в твоём случае просто нет проверки, т.е. мы имеем ситуацию:

До патча:

- *берёшь банку* Можно мне варенья?
- Нельзя!
- Пичалька... *поставил банку на место*

После патча:

*берёшь банку и чавкаешь вареньем*

Поэтому я по прежнему продолжаю недоумевать. Тут получается, что ограничение на скрины сделано в самом kwin, а вяленый на этом этапе особо ничего уже и не контролирует? Какая-то странная секурность.

agentgoblin
()
Ответ на: комментарий от agentgoblin

Ну так основа этой секурности заключается в том, что нельзя делать скриншоты в обход композитора. А права на создание скриншотов проверяет композитор. Запросы на создание скриншотов делаются через D-Bus.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

Запросы на создание скриншотов делаются через D-Bus.

Т.е. и само содержимое экрана откуда-то оттуда-же приходит? Я правильно понимаю схему взаимодействия? И я правильно понимаю, что я могу использовать композитор, где нет проверки, и мне тогда вообще пофиг и хоть заснимайся скринов? Потому что пока вырисовывается такая схема:

шотилка            композитор           вяленый
  | ----- скриншочу -> |                    |
  |                    | -------- можно? -> |
  |                    | <- можно! -------- |
  |                    | -- дай картинку -> |
  |                    | <- держи! -------- |
  | <- вот картинко -- |

Тут получается, что секурности в самом вяленом и нет. Просто он где-то держит флажок, мол, снимать можно или нельзя, а по факту, вся проверка на стороне другого приложения. Я думал, что проверка выглядит как-то так и рулится строго на стороне вяленого:

шотилка            композитор           вяленый             сесурити
  | ----- скриншочу -> | -- прога Х шотит ->|                    |
  |                    |                    | -------- можно? -> |
  |                    |                    |               тут трогаем
  |                    |                    |            capabilites файла
  |                    |                    |                например
  |                    |                    | <- можно! -------- |
  |                    |                    | -- дай картинку -> |
  |                    |                    | <- держи! -------- |
  |                    | <- держи картинку- |
  | <- вот картинко -- |

Но либо я код не понимаю, либо одно из двух.

А если верить тому, что тут написано https://support.hubstaff.com/screenshot-capture-support-wayland-linux/

Furthermore, there isn’t a standard API for getting screenshots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so.

то вообще бред какой-то получается. Каждый композитор как прикостылен - так он и снимает. Причём проверки все на стороне композитора. Выглядит так, что не для безопасности что-то сделали, а просто насовали полурабочих костылей в вяленый, а тем, кто композиторы пилит в уши нассали и они давай проверки пихать. Но зато рассказывают всем, что «секурность». Секурность, лол - проверку в клиенте отключил и всё. Все бы так секурность реализовывали.

https://gitlab.freedesktop.org/wayland/wayland/-/issues/32 - и вот судя по этому так и получается - кто костылей напилил, тот и делает скрины. Что мешает условной Кэрол в своего скриншот-зловреда сунуть реализацию вяленозависимой скриншотилки (да, это будет сложнее) - непонятно.

agentgoblin
()
Последнее исправление: agentgoblin (всего исправлений: 1)
Ответ на: комментарий от agentgoblin

Wayland - это, напоминаю, протокол. Весь функционал перекладывается на DE и тулкиты.

Поэтому по поводу конкретных реализаций будут соревноваться конкретные DE.

Wayland лишь вырисовывает конкретную схему, что без запроса к композитору скриншот не получится. Поэтому скриншотилка должна знать о конкретном композиторе, а композитор должен позволять скриншотилке делать скриншоты.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Поэтому скриншотилка должна знать о конкретном композиторе, а композитор позволять скриншотилке делать скриншоты.

Понятно. Всё-таки просто нассали в уши и разработчики давай ломать композиторы в угоду этому убожеству. Вся суть «секурности» протокола.

agentgoblin
()
Последнее исправление: agentgoblin (всего исправлений: 1)
Ответ на: комментарий от agentgoblin

С точки зрения разработчиков Wayland'а - всё лучше чем ничего.

Ну, а с точки зрения сферического юзера иксов в вакууме - лишняя огороженность, да. Я сам был против этой огороженности, да и сейчас моё мнение по поводу не поменялось. Поэтому я и сделал именно такой патч. А вот если бы я был за эту огороженность, то мне пришлось бы искать как выдать Spectacle полные права.

saahriktu ★★★★★
() автор топика

Иконки на скриншоте, если что, - kde-1.1.2-new

Блеск, спасибо.

Скрин - старые добрые кеды, какими я их помню.

yu-boot ★★★★★
()
Ответ на: комментарий от saahriktu

Поэтому скриншотилка должна знать про используемый композитор чтобы делать к нему запрос.

Строго говоря, скриншотилка должна знать про xdg-desktop-portal, конкретную реализацию которого уже предоставляет каждый композитор.

Rootlexx ★★★★★
()
Ответ на: комментарий от Qui-Gon

Но какбы в сухом остатке - программ которые работают на вяленде но не работают на Х пока нет.

Waydroid заработал под X11?

Rootlexx ★★★★★
()
Ответ на: комментарий от Eshkin_kot

Либо можно сделать неперехватываемый хоткей для принудительного ungrab всех клиентов.

Такой уже есть, но отключён по умолчанию, и не без причины: он позволяет обходить блокировщики экрана. Так что такое себе решение, а точнее, не решение вовсе.

Rootlexx ★★★★★
()
Ответ на: комментарий от Loki13

Вот из последнего это какие-то дикие(даже дичайшие) костыли для трансляции экрана с зуме или, прости г-ди, скайпе.

https://www.omglinux.com/zoom-linux-can-now-screenshare-wayland/

Что же до скайпа, то поддержка захвата экрана через pipewire в Electron запилили давно, так что осталось дождаться, когда это и другие подобные приложения переедут на свежую версию.

Rootlexx ★★★★★
()
Ответ на: комментарий от saahriktu

У Wayland’а такая архитектура, что в нём могут работать только те скриншотилки, которые заточены под конкретный используемый композитор.

Это не совсем так. Есть механизм получения скриншота с помощью XDG Portals, который требует наличия соответствующего dbus-сервиса, но не привязан к композитору (и Wayland в целом).

Siborgium ★★★★★
()

Например, скриншотилка KDE не работает в GNOME, а скриншотилка GNOME не работает в KDE.

А вот это называется трындец. Потому что в KDE есть kdenlive, а в гноме нет, даже близкого по функционалу софта, не говоря уже о его совместимости.

einhander ★★★★★
()
Ответ на: комментарий от saahriktu

Ну, это, по сути, перекладывание этого затачивания под конкретные композиторы на XDG Portals.

XDG Portals это, по большому счету, часть композитора – или его окружения.

Баги создания скриншотов. Рабочим был только один режим создания скриншотов - скриншот окна под курсором.

Кстати УМВР, никогда не сталкивался с такими ошибками. На KDE Wayland сижу уже давно.

% pacman -Qi plasma-workspace plasma-wayland-session kwayland spectacle
Name            : plasma-workspace
Version         : 5.25.3.1-1
# ...

Name            : plasma-wayland-session
Version         : 5.25.3.1-1
# ...

Name            : kwayland
Version         : 5.96.0-1
# ...

Name            : spectacle
Version         : 22.04.3-1

Siborgium ★★★★★
()
Ответ на: комментарий от Siborgium
Name            : plasma-workspace
Version         : 5.25.3.1-1

Ну, а я нашёл этот баг в KDE 5.24.x.

plasma5-workspace-5.24.6-alt2.x86_64
plasma5-kwayland-integration-5.24.6-alt1.x86_64
plasma5-kwayland-server-common-5.24.6-alt1.noarch
kf5-kwayland-common-5.96.0-alt1.noarch
plasma5-kwayland-integration-5.24.6-alt1.x86_64
plasma5-kwayland-server-common-5.24.6-alt1.noarch
libkwaylandserver5-5.24.6-alt1.x86_64
kde5-spectacle-22.04.3-alt1.x86_64

XDG Portals это, по большому счету, часть композитора – или его окружения.

Тогда это, получается, универсальная часть разных композиторов, под которую должен быть заточен софт. В противном случае софт затачивается под конкретные композиторы.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Ну, а я нашёл этот баг в KDE 5.24.x.

Я указал установленные у меня в данный момент времени версии пакетов. KDE Wayland я пользуюсь начиная с Plasma 5.21, и такого бага не встречал.

Тогда это, получается, универсальная часть разных композиторов, под которую должен быть заточен софт.

Это реализации единого интерфейса для различных композиторов. На практике их три: GNOME, KDE, wlroots.

Siborgium ★★★★★
()

а иксы они больше не развивают.

Это же отлично, наконец-то стабильность!

Shushundr ★★★★
()
Ответ на: комментарий от Siborgium

Я указал установленные у меня в данный момент времени версии пакетов. KDE Wayland я пользуюсь начиная с Plasma 5.21, и такого бага не встречал.

Ну так, бывает. Где-то баги встречаются, где-то - нет.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от EXL

кривореализованных

Кривореализованных авторами Qt. Вот это же их код, а не X11: https://github.com/qt/qt/blob/0a2f2382541424726168804be2c90b91381608c6/src/gui/kernel/qwidget_x11.cpp#L1587

            XGrabPointer(X11->display, effectiveWinId(), False,
                          (uint)(ButtonPressMask | ButtonReleaseMask |
                                  PointerMotionMask | EnterWindowMask |
                                  LeaveWindowMask),
                          GrabModeAsync, GrabModeAsync,
                          XNone, XNone, X11->time);

Это авторы Qt просят X сервер «пожалуйста заблокируй эксклюзивно ввод пользователю», X сервер только выполняет их просьбу.

Вот и спрашивай у них зачем они это делают.

Eshkin_kot ★★
()
Последнее исправление: Eshkin_kot (всего исправлений: 1)
Ответ на: комментарий от Eshkin_kot

Вот и спрашивай у них зачем они это делают.

Наверное у них есть на это какие-либо причины, раз так делают как в Qt, так и в GTK+ на протяжении 25+ лет.

Возможно это как-то связано с ограничениями X11.

Кривореализованных

Угумс, иксы у нас швятые, а два самых популярных графических тулкита под него – кривореализованны. Ну и где нормально реализованные иксовые графические тулкиты? Не появились за 30+ лет или сгнили как и сам X11?

EXL ★★★★★
()
Ответ на: комментарий от EXL

Возможно это как-то связано с ограничениями X11.

А возможно что нет, а возможно что авторы этих тулкитов хотели эмулировать поведение Windows, но X это не Windows, это другая система с другим поведением и получилось то что получилось.

два самых популярных графических тулкита под него – кривореализованны

Ну да, так бывает.

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

Ну да, так бывает.

Так где эти чудесные эталонные графические тулкиты для X11, в которых этого идиотского поведния нет? В какой Вселенной?

EXL ★★★★★
()
Ответ на: комментарий от Eshkin_kot

Поставьте тут return, не смущайтесь :-)

И сломать работу контекстных меню? Они ведь захватывают мышку, чтобы закрыться при щелчке вне виджета.

И ещё сломать захват ввода во всяких там виртуальных машинах, играх и проч.

Отличное решение, молодец! Не говоря уже о том, что от захвата клавиатуры это не спасёт, и от отправки команды серверу напрямую без xlib тоже.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

И сломать работу контекстных меню?

Почему «сломать»? Просто в X будет поведение не такое как в Windows, ну и что?

от отправки команды серверу напрямую без xlib

Ага, поэтому нет никаких проблем сделать отдельный хоткей для принудительного сброса захвата, если вас это беспокоит, по аналогии с Ctrl-Alt-Backspace. Для этого не надо изобретать wayland.

Eshkin_kot ★★
()
Последнее исправление: Eshkin_kot (всего исправлений: 1)
Ответ на: комментарий от Eshkin_kot

Почему «сломать»? Просто в X будет поведение не такое как в Windows, ну и что?

Потому что меню не будут закрываться при щелчке вне их виджета. Как предлагаете поступать — каждый раз жать Esc, или крестик к каждому меню приделать?

Ну и про остальные случаи вы скромно умолчали.

Ага, поэтому нет никаких проблем сделать отдельный хоткей для принудительного сброса захвата, если вас это беспокоит, по аналогии с Ctrl-Alt-Backspace

Такой уже есть, да вот незадача: это позволяет обойти блокировку экрана. Поэтому по умолчанию он отключён.

Для этого не надо изобретать wayland

В Wayland композитор намного лучше интегрирован в окружение, поэтому блокировщик экрана может быть встроен в композитор. И тогда последний уже не даст сбросить захват, если включена блокировка экрана.

А вообще, ваши попытки придумать этакие быстрофиксы, не задумываясь, как они повлияют на работу существующих приложений, выдают в вас критика Wayland прямо с дивана. «Простые» решения в стиле «отобрать и поделить» хороши ровно до тех пор, пока не начинаешь пытаться воплотить их в жизнь.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Как предлагаете поступать — каждый раз жать Esc, или крестик к каждому меню приделать?

Если вам действительно интересно — посмотрите как сделано меню окна в tk и зачем там пунктирная линия сверху.

Быстрофиксы не задумываясь — это как раз то что сделали авторы тулкитов, реализовав popup чрез блокировку пользовательского ввода.

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

Если вам действительно интересно — посмотрите как сделано меню окна в tk и зачем там пунктирная линия сверху.

Ну конечно - каждый раз или тащить мышку с зажатой кнопкой (что особенно удобно на тачпаде), или совершать лишние действия в виде открепления меню, которое ещё и останется висеть после активации нужного пункта.

И да:

Ну и про остальные случаи вы скромно умолчали.

Быстрофиксы не задумываясь — это как раз то что сделали авторы тулкитов, реализовав popup чрез блокировку пользовательского ввода.

А при чём здесь вообще тулкиты, если проблема в самой возможности с концами захватить ввод, которую даёт X-сервер, причём сделать это может любой клиент?

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Тулкиты тут при том что эту проблему на которую вы жалуетесь, с блокировкой ввода при отображении popup — создали их авторы, а не X сервер.

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

Я «жалуюсь» на саму возможность нафиг заблокировать весь ввод обычным непривилегированным пользовательским приложением. Корень проблемы именно в этом. Нельзя исходить из предположения об исключительной добросовестности всех запущенных приложений при проектировании такого важного элемента системы как графический сервер.

Rootlexx ★★★★★
()
Ответ на: комментарий от Eshkin_kot

Лол. Тебе же внятно написали - любое приложение на любом тулките может залочить весь ввод. Я лично наблюдал, как периодически при запуске виртуалки в VirtualBox клавиатура «помирала» - т.е. система никак не реагировала на нажатия клавиш. Но после выключения ВМ - всё «резко и решительно» начинало работать. Но виноваты тулкиты, конечно :))

htower_ ★★
()
Ответ на: комментарий от Rootlexx

Вы сами дали права этому приложению подключиться к вашему X серверу, а теперь говорите что оно недобросовестно.

Вы уж определитесь, если оно недобросовестно — не подключайте его к X серверу, используйте отдельный сервер, отдельную учётную запись, а то так то оно может и все файлы у вас в HOME удалить, раз оно недобросовестное.

Eshkin_kot ★★
()
Ответ на: комментарий от htower_

Лол, задержка ввода из-за перегрузки CPU никак не связана ни с блокировкой ввода в X сервере ни с тулкитами, она связана с задержками в ядре.

А тулкиты виноваты конечно, посмотрите их код: https://github.com/qt/qt/blob/0a2f2382541424726168804be2c90b91381608c6/src/gui/kernel/qwidget_x11.cpp#L1587

Блокирует ввод не X сервер, а тулкит, и код для блокировки ввода есть не только в Qt или GTK.

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

с логикой капец проблемы ))

Блокирует ввод не X сервер, а тулкит, и код для блокировки ввода есть не только в Qt или GTK.

А они через libastral блокируют, да? Или-таки через XOrg, который дает им такую возможность?

htower_ ★★
()
Ответ на: комментарий от Eshkin_kot

Вы сами дали права этому приложению подключиться к вашему X серверу, а теперь говорите что оно недобросовестно.

Я дал ему права отобразить мне своё окно, а не ноги на стол водружать.

Вы уж определитесь, если оно недобросовестно — не подключайте его к X серверу, используйте отдельный сервер, отдельную учётную запись, а то так то оно может и все файлы у вас в HOME удалить, раз оно недобросовестное.

Не сможет, ибо запущено во flatpak с обрубленным доступом к ФС вне контейнера, однако окно-то как-то отобразить надо, поэтому доступ к X-серверу логичен и не вызывает подозрений. И то, что такое приложение прямо из контейнера сможет прочитать события, предназначенные другим приложениям, а также блокировать весь ввод — это недостаток X-сервера, для которого все клиенты, кто смогли подключиться, считаются одинаково доверенными. Архитектура безопасности в нём давным-давно устарела, а попытки её осовременить не взлетели.

Rootlexx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.