Wayland опять готов для десктопа (нет)

Если кратко то эти штуки должны быть реализованы на стороне сервера, а Wayland перекладывает их реализацию на разрабов WM. В Valve там что-то сделали в Gamescope для этого, а остальные не осилили походу.

Without this protocol, vkQueuePresent or glSwapBuffers must stall for the 'frame' callback after presenting an image. The only reason we can get away with this on SteamOS is because Gamescope implements what is essentially fifo-v1 and we use that there.

Что сделал Габен увидив корявый X11 в оконной системе? Да первым же делом схватился за голову и побежал делать Gamescope для Steam Deck: […]
Потому что VALVe ведь не иксы пердолить нужно, а сделать так чтобы Steam Deck нормально продавался и разрывов картинки не было видно, а с иксами на игровом поприще каши особо не сваришь.

:)

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

Wayland's render loop design is ridiculous.

This is one of those parts where the limited design of Wayland really hits you in the face. You must design your render loop in a certain way. If you don't, prepare to face the pain. How this works on Wayland is that you get a callback from the compositor (the infamous frame callback), which essentially acts as a hint telling you when to draw. That's cool. The idea is that the compositor tells you when to draw, you obey like a good client, and everything works. Unfortunately, life is not actually that simple. Most compositors throttle rendering by not sending frame callbacks when the client is hidden. Internally in Mesa, a swap interval of 1 on EGL and FIFO mode on Vulkan (AKA basically vsync) work by waiting for frame callbacks. Do you see where this is going? If your client tries to draw while it is hidden, woops it gets indefinitely stalled until you bring it back into view. Well surely the client can just check if it is visible before drawing, right? Actually no, you can't. That's right, clients have no way of knowing if they are hidden or not. It's common to come up with some heuristic to deal with this.

This is the part where Wayland developers will say something like "just draw with the frame callback". If you build a client from ground up specifically with Wayland in mind, sure this is easy. But many applications are cross platform and internally driven. Refactoring a render loop to operate completely differently, just for the sake of one platform that acts like a special snowflake is not appealing to anybody. At this point, many applications just give up and set the swap interval to 0 or Vulkan to mailbox and call it a day. In mpv, I came up with a weird hack that essentially implements a blocking call with a timeout since we need vsync obviously but blocking forever isn't acceptable. There's a heuristic that guesses when mpv is hidden (been wrong before) and it doesn't draw in that case, so we have the same idealized efficiency, just not exactly in the "Wayland-approved" way.

In the past, there was actually an externally driven render loop specifically for mpv which worked like how upstream Wayland developers say it should work. It was extremely buggy, lacked features, and totally brittle. Reverting it was definitely one of the better commits I made. And in retrospect, this actually makes perfect sense. mpv has a crapload of timing code specifically designed to deliver the frame at exactly the right time. It's been battle tested and used over many years. Why would the compositor know when to draw better than mpv? Of course, it wouldn't. And indeed, when I squeezed Wayland's weird rendering design into mpv's internal workflow, frame timings dramatically improved (even before presentation was implemented) and tons of bugs were fixed in the process. The dislike of internally driven renderloops is purely driven by ideology, not any actual technical sound reasoning. There's nothing wrong with an application managing how it should render internally. It's a natural choice for any program that operates in a cross-platform manner. Wayland is the only platform like this, and it makes operating in this way needlessly difficult for no particular reason. We can't "waste" frames but never mind that you can just set the swap interval to 0 and belt it away anyway.

Отсюда: https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html

Вяленый все время что-то на кого-нибудь перекладывает. И даже так ничего не умеет 😒

Протокол в принципе ничего не знает, ничего не может и далее по тексту.

Но любим мы его не за это.

There is no advantage to games and average applications preferring Wayland over X11 – only severe performance and unusability regressions right now.

Этапять, я щитаю!

побежал делать Gamescope для Steam Deck

О боже, теперь каждый, кто что-то разрабатывает под линукс должен пилить свой композитор?

По мнению разрабов вейлада, да.

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

Ну да, это же основной принцип вейланда! А так как нельзя запускать композиторы вместе, то ещё и ковыряться в чужих.

побежал делать Gamescope для Steam Deck

О боже, теперь каждый, кто что-то разрабатывает под линукс должен пилить свой композитор?

Да. А потом писать PR в wayland-protocols, доказывая каким-то шизофреникам, что базовый десктопный функционал реально нужно запилить. Когда мне кажется, что мои коллеги – непроходимые дебилы, я хожу на gitlab.freedesktop.org и читаю обсуждения, где некоторые личности доказывают, что программам никак нельзя позволять менять свои координаты на экране или знать, видит ли их сейчас юзер. После этого я становлюсь гораздо более терпим к людям, ведь даже полный идиот с баклажановой икрой вместо мозга такое сморозить не может.

Wayland – это комедия, а не протокол.

Кто же, кто же все время срет в штаны передовым разработчикам открытого графического сервера нового поколения все эти годы и даже почти десятилетия?

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

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

Ээээ, давайте цифровое вуду делать на урода. Гляньте только, какая отвратительная рожа:

https://media.licdn.com/dms/image/C5603AQE3q4aHTlN0Bg/profile-displayphoto-shrink_800_800/0/1601563187301?e=2147483647&v=beta&t=I8R9MCACquCQDWGIUz1Mf5vmu6kqapi2g8xOsRp7UnE

С него небось мем «Source??» делали

only severe performance and unusability regressions right now.

А где оно на практике проявляется?

Это какой-то позор. И так у них всегда.

Да всё уже сказано про вяленого: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277

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

Весёлое будущее нас ждёт, похоже.

Остаётся только ждать, когда у разрабов наступит отходняк и осознание своих ошибок.

Читай - когда поумнеют. Мсье оптимист.

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

Когда косяки в основных архитектурных решениях, то проще новых нарожать. Или, как тут выше упоминали, X11 рефакторить.

Просто очередной этап приобщения Wayland к миру Vulkan. Не вижу ничего необычного. Но вялендохейтеры как всегда))

Большая часть этой простыни уже давно не актуальна. Как минимум благодаря наличию состояния suspended в xdg-shell

Самое неприятное это то, что приложения, которые работали на иксах после обновления вдруг перестают. Как пример gcolor3, пипетка.
Название прежнее, а зависимостей список от pipewire до wayland и под иксами не работает. Ну так меняйте название не на gcolor3-xorg, а на gcolor3-wayland.

не могу избавиться от мысли, что wayland это продолжение systemd

completely unfixable without an additional protocol

Фффффак, у меня наконец-то hw video в фуррифоксе заработало :( Под вялендом, да.

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

Он щас в MS работает, так что вертел он этот графический сервер. Ибо такое не выгодно для работодателя.

Да, я в курсе. Такой локомотив потеряли

Большая часть этой простыни уже давно не актуальна. Как минимум благодаря наличию состояния suspended в xdg-shell

Это меньшая часть этой простыни.

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

Ну перебрасывание ответственности на композиторы это такое.

Ну перебрасывание ответственности на композиторы это такое.

Надо пойти дальше. Композиторам перебрасывать ответственность на приложения. Тогда заживём, а богомерзкому X11 точно капец.

А в чем проблема? Убрали одну лишнюю сущность, ведь даже на иксах сейчас иксы почти не задействованы никак, отрисовка на клиентах. Есть набор стандартных расширений, каждый композитор вправе сделать что-то свое, для какого-то эксклюзивного функционала. С нуля сейчас композиторы никто не пишет, так что я лично проблем никаких не вижу. Их почему-то видят только те, кто в разработке Wayland не участвует и даже не понимает что там и к чему.

Это трагедия. Потому что это протолкают админресурсом вместо X11, а без конкурнеции они вконец спятят и угробят десктоп и игры на Linux с концами.

Тем временем энтузиасты в параллельной ветке IT запиливают реализацию современного виндового API поверх winXP и не ноют про «сложное ойти» и «древние костыли».

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

Как же так?

Вообще удивительно, на X сессии и так не будет wayland (то есть 99.9% религиозных хейтеров не ощутят разницы), а на wayland сессии будет XWayland, который просто обёртка Xового API над wayland. То есть всё вернётся к тому же что работает через ивенты, без fifo, просто Xwayland ждёт ‘frame’ callback и драпает все неиспользованные кадры, только не будет нормального скейлинга.

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

Да всё уже сказано про вяленого: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277

сам-то читал эту ссылку? коммент:

Sway is not a «desktop environment», yet every single one of the problems you listed here doesn’t happen to me.

ответ автора гиста:

Well, Sway was specifically made for Wayland. Whereas the software we have been using for decades was made way before Wayland was a thing.

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

Он кстати еще и врет. Его первый же пример, ssr, начали пилить 12 лет назад, когда вяленый уже «was a thing».

Какие там косяки-то? X11 работал десятилетиями. Если он столько времени всех устраивал то, наверное, плюсы всё-таки перевешивали минусы.

На иксах как минимум буферизация, управление отрисовкой окон и т.п. (Glamor), учёт окон и их «свойств». Нафиг это тянуть в композиторы - хз.

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

Всё ж таки вэйланду всего 12 лет. Технология ещё слишком юная. Вот исполнится ему 18, тогда уж и возвеселимся в волю.

Если он столько времени всех устраивал то, наверное, плюсы всё-таки перевешивали минусы.

Видимо минусы перевесили, и решили изменить архитектуру и избавиться от прослойки. Можно посмотреть про логику и что не устраивало в X тут https://www.youtube.com/watch?v=cQoQE_HDG8g.

Короче, в оффтопике теперь писать прикольный софт проще :)

Заменили плохое худшим и теперь стесняются признаться, что облажались.

Ну, я не программист, но если Wayland поднял порог вхождения для разработчиков оконных менеджеров/DE - я только рад этому факту. Отсеет всяких быдлокодеров. С другой стороны - композитор сейчас не нужно делать с нуля, полно готовых конструкторов, типа wlroots. Для множества языков есть бинды, пиши хоть на Сях, хоть на расте, хоть на питоне. Так что Wayland - круто.

*вздохнул*

Забыл написать - композитор для оконного интерфейса, как бы, не нужен, но это, конечно, моё мнение: концепция окна как какого-то полигона, управляемого 3D акселератором, излишне механистична и сложна в пространстве оконных интерфейсов, и вот как раз абстракция «окно» намного лучше, чем «устранение прослоек».

Какие там косяки-то?

Про «архитектурные косяки» я говорил про вяленого, в ответ на твой пассаж про вяленого же.

X11 работал десятилетиями. Если он столько времени всех устраивал то, наверное, плюсы всё-таки перевешивали минусы.

Не помню за давностию лет, что там был за вой вокруг его запущенной кодовой базы, в которой сам чёрт ногу сломит, и много ли с тех пор поменялось. И вообще не в теме. Но НЯП, одно из ключевых отличий вяленого от иксов, что в нём поддерживается только режим direct rendering (канвас на клиенте), который в иксах идёт доп. модулем dri. А основной API иксов исторически был – отрисовка примитивов, в т.ч. по сети. Чего бы этот легаси и не убрать. А там может и пути выпрямления кода обнаружатся.

А основной API иксов исторически был – отрисовка примитивов, в т.ч. по сети. Чего бы этот легаси и не убрать.

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

Все, новость не актуальна https://www.phoronix.com/news/SDL-3.0-Wayland-Default-For-Now

Я склонен ответить, что:

(1) XWayland это костыль, который даже сами его разработчики не могут считать вечным (а если считают, я ОЧЕНЬ удивлюсь);

(2) кучу софта переписывают на нативную поддержку вяленого, что по-любому сложнее, чем переписать его же на dri (то, что куча софта до сих пор использует старое API, приму на веру, хотя для меня это звучит дико);

(3) убрав legacy API, мы не получим «тот же самый Wayland», потому что куча всего остального, что есть в иксах полезного, останется, как и – самое главное – его ключевые архитектурные решения (например, такие как отсутствие отрисовки по коллбэку, гыгы). Под «путями к дальнейшему выпрямлению кода» я имел в виду не отрезание всё бОльшего и бОльшего количества фичей, а рефакторинги – допустим, реализация dri как плагина может иметь негативные побочки в виде кода загрузки плагина, фасадов API или ещё чего (звучит неубедительно, но когда разгребаешь чужой код, пути к его упрощению без изменения функционала иногда находятся в самых неожиданных местах).