Red Hat угощает Wayland-ом разработчиков Firefox

Какой-то фееричный костыль

Напомнило то, что упомянул почти 2 года назад:

Wayland вроде ещё не готов

Если программка немного задумается и не успеет обработать события от мышки, которая пробегает по окну, то прога просто падает.

Сообщил пользователь Gajim: https://web.archive.org/web/20220309202028/https://conference.gajim.org:5281/muc_log/gajim/2022-03-09

Баг был известен и всё ещё не решён: https://gitlab.freedesktop.org/wayland/wayland/-/issues/159.

Чем «не готов» wayland ? (комментарий)

такими как мышь с частотой 1000 Гц, которая генерирует слишком много событий.

Wayland

Оно там в один поток написано что ли? А писали второкурсники на лабе?

10+ лет разработки, миллиарды баксов вбухано, а результата ноль.

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

Я плачу и смеюсь. Как можно потратить столько времени и сил, чтобы сделать такое кривое говно(

Так они очень старались. Не кривое уже есть - иксы, надо делать не как они.

Как можно потратить столько времени и сил, чтобы сделать такое кривое говно

Ну это же гном. Они вообще странные ребята. Алсо чуваки дело говорят: держать очередь сообщений в ядерном буфере который может переполниться это та еще наркомания.

Не кривое уже есть - иксы, надо делать не как они.

Иксы тоже кривые

Иксы не падают если быстро подергать мышкой

У них разработчики в платьицах не по размеру, мальчикам просто неудобно.

У них хватает своих недостатков

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

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

Увы, весь мир неидеален.

Вау, экспериментальная концепция показа окна приложения!
Как же похорошела айтишечка к 2024 году.

Иксы не падают если быстро подергать мышкой

Wayland тоже не падает. Он просто убивает программы.

Но да, вся эта история – сраный позор.

А в чём позор?

Редхет компания занимающаяся зборочками зверьсиди с линуксовой солянкой софта для государства и корпораций — писать софт вообще не их прерогатива.

Ну накалякал какой-то админ там дисплейный сервер на баше и что?

Редхет компания занимающаяся зборочками зверьсиди с линуксовой солянкой софта для государства и корпораций — писать софт вообще не их прерогатива.

Што? Дядя, у тебя криокамера протекла? В средней федоре и RHEL большая часть софта сейчас от Red Hat идёт. Начиная от systemd и заканчивая гнумом.

Алсо..

«Wayland proxy is load balancer between Wayland compositor and Wayland client. It prevents Wayland client to be disconnected by Wayland compositor if Wayland client is bussy or under heavy load.»

bussy

Из https://www.urbandictionary.com/define.php?term=bussy:

bussy - boy pussy - the asshole of a male

(и, возможно, другие)

Огласите весь список, пожалуйста.

KWin, например, просто помечает окошко «не отвечающим» и спустя какое-то время предлагает его закрыть. С опцией отказаться, само собой, и откатом в случае если клиент начнет отвечать.

Итого из кривых ручек авторов Mutter местные (и зарубежные) белки-истерички раздули сенсацию.

Оно там в один поток написано что ли?

Да. Многопоточности они не научились. Зато научились везде пихать epoll().

Проблема на уровне libwayland и носит фундаментальный характер. Суть в том, что отправка сообщений асинхронная и неблокирующая. То есть если у получателя переполнится очередь сообщений, то сообщение будет просто потеряно, нарушена консистентность состояния и соединение с клиентом будет принудительно закрыто.

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

не двигать мышкой когда открыт Firefox, иначе это может немедленно привести к его закрытию.

И после этого они там что-то на иксы гнали

Проблема на уровне libwayland и носит фундаментальный характер.

Т.е. исправить ее без переписывания протокола и нарушения обратной совместимости нельзя? Что-то мне это напоминает, хмм…

Протокол менять не обязательно (можно использовать тот же протокол, но с блокирующими сокетами и несколькими потоками), но вероятно потребуются несовместимые изменения в libwayland API.

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

Т.е. иксы просто блокируются в такой ситуации? :D

Мне понравился комментарий на Phoronix, очень точно отражает ситуацию:

yup, wayland is the epitome of «instead of learning from our mistakes, lets just do the exact opposite» X11 and Wayland are just both equally shitty

Да, Wayland – это воплощение «вместо того, чтобы учиться на ошибках, давайте сделаем в точности наоборот». X11 и Wayland оба одинаковое говно.

мой любимый - словить зависание приложения или просто брекпоинт в отладчике когда приложение захватило фокус (grab) показывая модальное меню. Помогает Ctrl-Alt-F1 и прибить выполнившее grab приложение из ядрёной консоли.

(пользователь X-ов. Wayland приближается к паритету по проблемам, но года 3 ещё побуду на X-ах).

мой любимый - словить зависание приложения или просто брекпоинт в отладчике когда приложение захватило фокус (grab) показывая модальное меню.

Wayland в данном случае разрывает соединение клиента с сервером (что обычно приводит к падению клиента) из-за переполнения очереди сообщений.

Т.е. иксы просто блокируются в такой ситуации? :D

Там всё веселее. Очередь сообщений хранится а) на сервере б) не имеет ограничений по длине. В результате если запустить любую графическую программу, послать ей SIGSTOP, чтобы она перестала вычитывать сообщения из очереди, и передать идентификатор её окна простейшей программе:

#include <X11/Xlib.h>

#include <error.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
    if (argc < 2)
        error(EXIT_FAILURE, 0, "X11 window id expected");

    Display *dsp = XOpenDisplay(NULL);
    Window   win = atoi(argv[1]);

    while ("Xorg sucks") {
        XClientMessageEvent ev = {};

        ev.type    = ClientMessage;
        ev.display = dsp;
        ev.window  = win;
        ev.format  = 32;

        XSendEvent(dsp, win, false, NoEventMask, (XEvent *)&ev);
        XFlush(dsp);
    }

    return EXIT_SUCCESS;
}

— то получим быстрое «распухание» процесса X-сервера, пока его не прибьёт OOM. Т.е. любой клиент X-сервера может ничтоже сумняшеся уронить X-сервер, просто заспамив его событиями, которые никто не вычитывает.

Как по мне, так лучше уж пускай какой-нибудь условный Firefox помирает, чем весь графический сервер вместе с сеансом.

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

Доводил Windows 98 до похожей ситуации - он при движении мышкой поверх завшего окна логина он начинал щёлкать системным динамиком.

Как по мне, так лучше уж пускай какой-нибудь условный Firefox помирает, чем весь графический сервер вместе с сеансом.

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

https://www.youtube.com/watch?v=ymekITBVRHw

Вариант сделать нормально чтобы никто не умирал никто не рассматривал

Нет. Wayland делает сугубо не как в иксах. Варианта сделать нормально никогда не было, судя по протоколу.

Иван Семёныч угощает голубцами с говном

Проблема с событиями нажатия/отпускания клавиш. Если потеряешь событие, то интерфейс может заглючить. Кнопка залипнет и всё.

Это в любом случае лучше чем потеря соединения с сервером и завершение приложения. Проблему с залипаниями клавиш можно решить путём запоминания последнего состояния клавиатуры наблюдаемого клиентом и посылания сообщений нажатия/отпускания отличающихся от состояния сервера когда клиент отвиснет.

Mutter (и, возможно, другие) завершает работу клиента Wayland, если он распознается как зависший.

А это тогда что?
https://0x0.st/Hg04.png

Почему вообще какая-то очередь может переполниться? Почему размер этой очереди не динамический? Какие-то ограничения может и нужны, но явно не те, которых можно добиться, подвигав мышкой. У меня 64 GB памяти, сколько лет мне нужно мышкой шевелить, чтобы забить эту очередь?

Как по мне, так лучше уж пускай какой-нибудь условный Firefox помирает, чем весь графический сервер вместе с сеансом.

Оба два твоих варианта - говно. Если я в брейке в гдб, я не хочу чтобы говнокомпозитор убивал моё приложение. И, да, квин реализует это корректно.

Меньше минуты. Динамическая очередь на сервере - норм местами (но сильно хуже шареного ринга), на клиенте - усложнение конструкции, потребления памяти и тормоза. Имхо самое норм решение - кидать что-нибудь типа device_lost при переполнении серверной очереди: давай всё сначала

Меньше минуты.

Если мышка генерирует 1000 событий в секунду, то за минуту она сгенерирует 60 000 событий. Если 60 000 событий забивают 64 GB памяти, значит одно событие занимает больше мегабайта памяти. Что-то я сомневаюсь.

Динамическая очередь на сервере - норм местами (но сильно хуже шареного ринга), на клиенте - усложнение конструкции, потребления памяти и тормоза. Имхо самое норм решение - кидать что-нибудь типа device_lost при переполнении серверной очереди: давай всё сначала

Самое норм решение это доработать протокол. Если клиент не отвечает, то сервер это понимает и далее просто шлёт ему пинги, скажем раз в миллисекунду. Как только клиент раздуплился, сервер шлёт ему всё актуальное состояние, клиент заменяет своё текущее состояние актуальным и, собственно, всё.

Бонусом можно пользователю давать понять, что это приложение не отвечает.

Если 60 000 событий забивают 64

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

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

Это и есть device_lost. Пересборка состояния с 0.

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

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

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

Говорит о том, что ты не понимаешь, что такое ринг буфер :D

Или ты не понимаешь. Просто выделяешь ring buffer вдвое большего размера и копируешь туда всё из старого.

И твой клиент ломается потому что ему ничего не известно про этот ринг «вдвое больше»

Не говоря о том, что у него head/tail уже закешированы и ты не знаешь где.

И, да, квин реализует это корректно.

Да неужели?

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

Под линуксом (Gnome Wayland) это приводит к забавному эффекту. Линукс честно пытается выстроить очередь сообщений от клавиатуры и не пропустить ни одно нажатие W. Если пользователь нажал W и держит, значит, пользователю это зачем-то надо. В результате, в игре, ты куда-то бежишь путём нажатия W, а когда ты её отпускаешь, или нажимаешь пробел, персонаж в игре продолжает ломиться в том же направлении ещё секунды две и только потом прыгает. Неудобно.

Под виндовсом (Win11) это приводит к другим забавным эффектам. Если куда-то бежать, то персонаж останавливается сразу после отпускания кнопки W. Но если тебе приспичило открыть меню персонажа (кнопка Tab), игра может просто проигнорировать твоё нажатие. Надо нажать Tab и держать, чтобы нажатие точно сработало. В некоторых случая длинное нажатие и короткое нажатие это разные эффекты и ты не можешь выполнить короткое - потому что короткое игра игнорирует, а длинное приводит к длинному нажатию. Сколько раз я в игре вставал с кресла (длинное E) вместо того, чтобы выбрать объект (короткое E).

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