Планы Ubuntu по переходу на Wayland по умолчанию

– 504,210 (строк удалено)

Я прозреваю, что 200к из них – скрипт ./configure, когда они на meson перешли.

Но вообще, в Xorg не было 500к в лучшие времена. Прямо сейчас cloc показывает 360к строк.

-----------------------------------------------------------------------------------
Language                         files          blank        comment           code
-----------------------------------------------------------------------------------
C                                  731          59087          55273         322194
C/C++ Header                       472          10280          17180          42260

Вот Red Hat и решил сделать ход конём. Вместо того чтобы тратить деньги и удалять код из копролита – просто удалить копролит.

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

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

За Wayland будущее, я им пока не пользуюсь, но знаю что Wayland это перспективно, скоро везде внедрят

пусть переходят, а я вместо 24.04 апгрейднулся на минт. 19 лет на бубунте был...

То есть с Mir как обычно - сначала канониклы делают своё во славу NIH

Сделали его когда задолбались ждать Wayland. И лучше бы у них тогда получилось довести дело до конца.

Угу, и забудешь ты про запись рабочего стола в телеграме.

Мне кажется, более вероятной была бы новая реализация X11. Раз уж с кодом Xorg действительно так сложно работать, а о всех нужных фичах слишком сложно договориться в новом протоколе, может быть просто реализорвать с нуля старый протокол?

Перед тем как давать советы космического масштаба и космической же глупости, может следовало выяснить, в чём конкретно была проблема?

Главная проблема xorg вовсе не в том что это какой-то необычайно сложный артефакт забытых технологий древних, за 10 лет до начала проекта вейланд его вполне себе отрефакторили. Проблема в том, что xorg требует очень многого, не делая ничего полезного. Вот буквально, единственная функция xorg в современных DE - это обеспечение совместимости с x11 (читай - с собой). Это как если бизнесмену мафиози навязал в партнёры своего племянника, а племянник вместо того чтоб работать или хотя бы просто не мешать и получать зарплату, лезет во всё, везде косячит, и исправление его косяков требует больше ресурсов чем основной бизнес. И вариант «убить племяника и загримировать под него толкового пацана» не катит, так как мафиози хорошо знает своего племяника, и если он в какой-то момент перестанет косячить, то подмена сразу вскроется.

1. Протокол отрисовки. Чтобы я мог в wayland рисовать в приложении что-либо средствами wayland, а не opengl/vulkan, либо на cpu как сейчас. Без этого я даже смысла портировать тулкиты на wayland с иксов не вижу, т.к порт априори получится хуже оригинала - либо прибит к 3д ускорителю, либо рисует всё на CPU.

Это называется «библиотека». Возьми любую библиотеку отрисовки, которая на тебя глядит. Незачем тащить это в графический сервер.

2. Единая реализация композитора, желательно в виде библиотеки со стандартным API.

Предположим, твоя мечта сбылась. Есть единая реализация. А назавтра я с троллфейсом делаю форк этой библиотеки и переставляю параметры во всех функциях в обратном порядке. В итоге у нас теперь 2 реализации композитора с разными API. Станет ли от этого оригинальная библиотека хуже? Если нет - то в чём смысл твоего требования к единости? Если же от этого отказаться, то такая библиотека есть, wlroots называется.

3. Реализация 2d ускорения. В xorg есть sna/uxa/exa и куча вендорских методов ускорения отрисовки 2d помиммо glamor. Вместе с первым пунктом это позволит эффективно использовать оборудование, а не грузить opengl по любой мелочи.

ты повторяешься. Это первый пункт был. Хорошо, предположим, ты сделал железку, котоая умеет ускорять и хочешь чтоб она использовалась. Какие есть варианты?

1. Реализовать для неё opengl. Всё будет работать из коробки.

2. Если opengl плохо ложится на данную железяку, ты попал. Но не всё потеряно. Ты берёшь библиотеку отрисовки и делаешь в её рамках бэкенд под твою железяку. Реально используемых таких библиотек не так уж и много, так что 80% софта ты покроешь относительно малой кровью.

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

Других вариантов нет.

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

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

Второй вариант предлагает некоторое преимущество варианту и интеграцией, так как тебе достаточно запилить бэкенд в графический сервер и он везде подхватится. Но этого же эффекта можно добиться просто кинув в систему адаптированный *.so файл графической библиотеки. Да, в теории пользовательский софт может быть слинкован статически, но в случае оупенсорса это не непреодолимо, да и в принципе прикладной софт завсегда может точно так же использовать прямой доступ к растру и рисовать сам, что будет аналогом статически слинкованной либы.

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

4. Сетевая прозрачность.

Ну конечно, как же без этого бреда.

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

Ты сейчас называешь марсианским экзотическим недоразумением вполне существующие решения, при этом даже не вникнув в суть.
Любая реализация opengl будет тяжелее по ресурсам, чем 2д блиттер. Реализация 2d отрисовки на opengl будет эффективней в сервере когда запущено более одного-двух приложений, потому что как сам контекст oepngl, так и реализация достаточно тяжёлые. Даже время запуска заметно отличается.
Почему-то на windows я запускаю приложение, и могу сразу нарисовать чть-то в окно, не перечисляя при этом список доступных gpu, не создавая после этого клнтекст, не загружая огромную библиотеку с компилятором шейдеров в память, не компилируя шейдеры. И даже если реально на этом gpu есть только opengl, всё это уже будет сделано системой заранее.
Но wayland же композитор, он не должен ничем таким зантматься. Потому делай всё это ради того, чтобы нарисовать мессажбокс!

А теперь главный вопрос: что если по какой-то причине не удалось инициализировать opengl в процессе? Заполнять через cpu по одному пикселю? Да, я понимаю, что тулкит это всё сделает за меня. Но это пока есть тулкит, там же где его нет придётся опять же самому реализовывать софтовый фоллбэк, либо же грузить при ошибке этот тулкит динамически.
Только вот то, что предлагает x11 на порядок лучше всех этих костылей, сделанных лишь ради того чтобы наш вселюбимый композитор оставался простым...

А так сам по себе wayland для тулкитов, которые уже работают только с opengl может быть вполне удобен. Только вот в качестве замены иксов это очень бедная альтернатива и скорее всего композитор, который на каждый вяленный toplevel будет по иксовому окну открывать специально для wayland-only софта будет удобнее. В итоге и никакой Xwayland не нужен

А есть аналог xrdp для вяленого?

про паровое отопление уже шутили?

Эээ, речь вообще не о преимуществах opengl над марсианской железякой. Речь о преимуществах включения графического API в графический сервер над текущим решением в виде «вот тебе буфер и делай с ним что хочешь».

И вот в примере с марсианской железякой как раз видно, что включать графическое API в сервер нельзя ни в каком случае. Потому что если сейчас твоё желание исполнится и добавят какие-то функции, то это то что существует сейчас, т.е. OpenGL. Тебе предложат либо просто функции opengl’а, либо какие-то более близкие к гую, те, которые любая opengl совместимая железяка выполняет эффективно. Поэтому когда ты придёшь со своей марсианской железякой, которая opengl не умеет или выполняет неэффективно, то всё.

В общем-то эта ситуация уже случилась. Были железяки, умевшие ускорять заполнение цветом прямоугольников или заполнение одних прямоугольников содержимым других. Потом оказалось, что хочется полупрозрачности для антиалиасинга, а на горизонте так вообще марсианские железяки с каким-то непонятным opengl, после чего на рисовальные возможности X11 дружно забили и стали рисовать сами, точнее используя библиотеки, всякое clutter, cairo и прочее. Но поддержка рисования в xorg осталось, и остался старый софт, из-за которого эту поддержку выкинуть нельзя. Вот авторы Вейланда и поняли эту ошибку и решили больше не включать графические библиотеки в протокол.

Что значит «сами»? Тот же cairo кэширует битмапы на стороне дисплейного сервера и затем композитингом собирает из них финальную картинку. Речь о том, что для этого ему не нужно самому компилировать шейдеры и инициализировать графический пайплайн. Для него это делает дисплейный сервер.

«Сами» значит сами.

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

«Ачотакова?»

В фоллаутах встречаются такие записи в терминалах. Вроде «удалось снизить смертность от напитка до одного процента».

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

Использовать opengl только для блиттинга или тем более ресолвинга (когда текстура не скейлится) крааайне неэффективно. Как ни странно, в шинде композитор и gdi всё ещё умеют эффективно блиттить. Наверно какому-нибудь гному, которому всё равно обычного blit недостаточно wayland в текущем виде оптималнен. Тем временем я знаю железку, на которой помимо opengl есть 5 способов заблиттить изображение. 2 из них задействованы в иксовом драйвере под неё, ещё один в порте weston. Мало того, использование 2д движка для блиттинга заметно разгружает 3d движок и производительность opengl после того, как я задействовал в своём приложении 2д движок для копирования текстур возрасла примерно в 2 раза, при этом же железка перестала перегреваться.
Стоит ли после этого сомневаться в необходимости реализации рисования в сервере? А вот в случае с wayland это всё задействовать можно только в специальном композиторе под железку, ни в gnome, ни в plasma же рендеринг через 2d движок работать не будет... Да, для своих целей можно использовать weston специальный и вызывать api блиттера напрямую, но для этого придётся переписывать всё вручную. Или же получить тот же результат, ПРОСТО ЗАПУСТИВ ГРЁБАННЫЕ ИКСЫ. К тому же использование специального форка weston и переписывание приложения на api какого-то экзотического блиттера не имеет никакого смысла, если можно сразу дёргать api этого блиттера поверх kms/fbdev

Замечу, что пишу я это с компа на rdna2, на котором в принципе никакого API 2д блиттера отдельного нет (хотя аппаратно может что-то и есть, не знаю), и на котором wayland будет максимально эффективен. Но даже на нём, имея glamor в сервере, я получаю преимущество от иксовой рисовки: пользовательскому процессу нужно загрузить только пару небольших иксовых либ, чтобы уметь рисовать, а рисоваться оно будет уже с применением opengl.
На другом же оборудовании польза от рисованифя сервером будет намного больше

Сделали его когда задолбались ждать Wayland

Если бы они его именно «сделали»,то сеанс mir уже бы несколько релизов как был частью убунты. А они его именно что делали, но как обычно не осилили.

Тебе напомнить как патчи для Mir старательно режектили везде, где могли?

Использовать opengl только для блиттинга или тем более ресолвинга (когда текстура не скейлится) крааайне неэффективно

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

Однако вопрос не в этом, а вот в чём:

Или же получить тот же результат, ПРОСТО ЗАПУСТИВ ГРЁБАННЫЕ ИКСЫ.

На словах это звучит вообще классно, запустил иксы и получил нахаляву. Но в реале всё ровно наоборот. Чтоб вызвать функцию блита надо чтоб она была в сервере. Т.е. тебе чисто повезло, что твоя железяка и xorg говорят на одном языке. Если бы это был wlorg, написанный в десятых под актуальное на тот момент железо, то там бы не было этого блиттинга и тебе, даже если ты сам пишешь софт под свою же железку, пришлось бы делать форк сервера wlorg. Но… проблема в том, что никакого wlorg никогда бы не существовало, сам проект вейланд запущен от того, что разработчиков современных DE задолбало сидеть верхом на чёрном ящике xorg, который норовит перейти в какое-то неожиданное состояние из-за чего всё сломается, им проще выполнить необходимый набор функций самим. Так что в реале, если бы тебе захотелось написать свой прикладной софт под свою же железяку с блиттингом вместо opengl, тебе бы пришлось форкать не 1 wlorg, а mutter, kwin, mir и ещё сверху wlroots.

Так не лучше ли тебе, делая линукс под твою железяку, добавить бэкенд в одну библиотеку cairo и получить поддержку большей части софта? Или, если cairo не подходит под твою же железяку, запилить библиотеку shmairo и по крайней мере добиться что твой собственный софт, использующий эту shmairo будет работать эффективно и на любом DS, хоть на sway, хоть на KDE?

Опять ты предлагаешь какие-то велосипеды, но зачем, когда уже всё давно изобретено n лет назад. Тем более ты предлагаешь заменить написание драйвера под существующее API на форканье cairo-shmairo. Да, возможно дёргать железо напрямую в клиенте будет эффективнее чем таскать всё это через IPC, но вынос 2д блиттера в клиент потребует обеспечить в ядре нехилый такой контроль доступа и стейтменеджер для девайса, чтобы обеспечить немонопольный доступ к нему. Опять же, сейчас эта задача прекрасно решается иксами. То что ты предлагаешь по сути будет означать добавление ядерного API (возможно даже в рамках v4l2???)
Но и опять упираемся, на другой железке где есть только opengl ты будешь грузить огромную кучю разжиревшей месы в каждое gui приложение лишь ради того чтобы чуть быстрее заполнить квадрат цветом

Опять ты предлагаешь какие-то велосипеды, но зачем, когда уже всё давно изобретено n лет назад

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

Ты вообще помнишь, что мы обсуждаем существующую архитектуру wayland, которую ТЫ предлагаешь «улучшить»? Так что это ты предлагаешь «велосипеды».

Тем более ты предлагаешь заменить написание драйвера под существующее API

Нет никакого «существующего API». Было да сплыло. Существующее API - это GBM и иже с ними.

о вынос 2д блиттера в клиент потребует обеспечить в ядре нехилый такой контроль доступа и стейтменеджер для девайса

xorg/kwin/mutter - это вообще-то юзерспейс, так что доступ из юзерспейса в любом случае будет, соответственно ты не можешь филонить и выдавать графическому серверу опасный api.

Опять же, сейчас эта задача прекрасно решается иксами.

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

Ещё раз: люди накушались твоего «графический api должен уметь рисовать», больше не хотят. Для этого отчасти Вейланд и придумали. А тут приходишь ты и начинаешь нести околесицу, потому что твоему утёнку хочется чтоб было как раньше.

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

существующую архитектуру wayland

Которая кривая изначально, потому за 15 лет никому не оказалась нужной

Существующее API - это GBM и иже с ними

gbm это внутренние API для очень ограниченного ряда задач, они не предназначены для работы с ними из конечного софта,чего, например, нельзя сказать о GDI

xorg/kwin/mutter - это вообще-то юзерспейс, так что доступ из юзерспейса в любом случае будет, соответственно ты не можешь филонить и выдавать графическому серверу опасный api.

Это юзерспейс, но он пользуется API, которое запросто может повесить или даже повредить оборудование. Да, я тоже хочу чтобы железки были более безопасные и их безопасно можно было давать софту, но до этого пока слишком далеко. Относительно безопасные железки стоят в мобилках. Адрено тот же при ошибке железа может полностью резетнуться без каких-либо визуально заметных проблем, будет заметен только микрофриз

благодаря тому что иксы писались под эту задачу

Да, ПОД ЭТУ ЗАДАЧУ. Рисовать пользовательский интерфейс, а не свистеть и пердеть. Тем временем первый раз про wayland я слышал именно под эгидой свистения и пердения

больше не хотят

Работать никто не хочет, головой - в особенности. А вот свистоперелки хотят все

нахрена было пилить новый протокол если потом в нём предлагается повторить все решения из предыдущего?

Чтобы эти решения сделать лучше разве что? Чтобы пересмотреть их с учётом нового оборудования? Идея хорошая, но по факту его пересмотрели только с целью упрощения и получили соотвественно какую-то шляпу. По факту фичами, нужными новому оборудованию такми, как sync объекты, drm модификаторы стали заниматься слишком поздно, зато выкинули то, что не нужно части оборудования, у которой неограниченное количество ram и питания

Которая кривая изначально, потому за 15 лет никому не оказалась нужной

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

Чисто для сравнения. Спецификация X11 появилась в сентябре 1987. Именно x11, первые версии даже не рассматриваем. Первое полноценное DE под линукс - KDE, появилась в 1998. 11 лет. Причём к KDE1 никто не предъявлял требований паритета по фичам с лучшими гуями того времени, с той же виндой, например.

Сколько-нибудь готовая спецификация Wayland появилась в 2012. Рабочая wayland-сессия в гноме появилась через пару лет всего. И если не брать откровенных неадекватов, которым «вейланд никогда не будет готов», то вся современная критика состоит из «приложение X, которое мне нужно, не работает в wayland» или «железо X, которое у меня стоит, плохо поддерживает wayland». Такого уровня готовности нет и в x11 до сих пор.

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

gbm это внутренние API для очень ограниченного ряда задач, они не предназначены для работы с ними из конечного софта,чего, например, нельзя сказать о GDI

Я уже несколько раз объяснил причину подобного решения. Видимо рациональных возражений нет. Просто запихай это GDI в библиотеку и работай с ним. Нет ему места в апи для окошек.

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

Если у тебя opengl может сжечь оборудование (или даже убить пользователя), то проблема отрисовки прямоугольников должна быть немедленно отложена в долгий ящик и все силы брошены на исправление opengl. У тебя вообще неадекватные приоритеты. Благо это всё лишь твои фантазии, глупая отмазка, почему ты хочешь рисовалку внутри сервера. Однако я готов рассматривать даже глупые отмазки, но проблема в том, что твоё решение никак не улучшает даже эту надуманную ситуацию. Дисплейный сервер - это юзерспейс. Если ты за ним спрятал опасное API, то и другой софт, в обход дисплейсервера может обратиться к нему. Альтернатива - работа дисплейного сервера из под рута, но это решение создаст ещё больше дыр.

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

Да, ПОД ЭТУ ЗАДАЧУ. Рисовать пользовательский интерфейс, а не свистеть и пердеть. Тем временем первый раз про wayland я слышал именно под эгидой свистения и пердения

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

На практике x11 пилилось под совершенно другую задачу, под работу на машине с небольшим количеством памяти. Блиттинг в железе - это так, мелочь, которую заместили более качественными возможностями железа opengl. Тут как бы и думать нечего, если есть возможность скопировать прямоугольник просто, и есть возможность скопировать с преобразованием, то только дегенерат будет говорить, что у первого варианта есть какое-то преимущество кроме «моя древняя железяка только так умеет».

Знаешь, в 80е было много классных решений, заточенных под задачи. Это ПК был уродцем для скучных таблиц в текстовом режиме и тормозным фреймбуфером, а всякие амиги/атари таскали внутри себя продвинутые 2д ускорители. А если посмотреть на NES, то там, фактически используя аналог текстового режима, делали очень плавную графику на 6502. Поэтому непонятно, с чего ты решил ограничиться возможностями убогих видеоускорителей из 90х. Почему не пойти дальше и не запилить поддержку если не NES, то хотя бы Сеги? А чё, удобно. Разве плохо иметь поддержку спрайтов на хардварном уровне? Эмуляторы старых приставок будет удобнее писать.

Чтобы эти решения сделать лучше разве что? Чтобы пересмотреть их с учётом нового оборудования? Идея хорошая,

Всё с тобой понятно. Переписать из принципа NIH - это хорошо, а исправлять коренные недочёты старой архитектуры - низзя.

Opengl не является опасным api вроде бы, но тем не менее, фурмарк, на нём написанный может запросто спалить видюху. Но с этим ты вряд ли можешь сделать, а вот условное api, которое принимает 2 структуры с описанием параметра и физических адресов уже стоит оставлять в пределах графического сервера. Да, такое api нужно оборачивать в gem/prime, тогда его можно будет выносить в gdi-библиотеку. Это уже было бы можно тащить в клиентское приложение.
Ещё одна проблема сейчас есть - из-за чего drm вообще нельзя пускать в юзерспейс. Отправленный неправильный коммандный буффер на amdgpu либо же забытый (unwaited) fence никак не отслеживаются ядром и gpu просто виснет на них. Ломая этот ваш любимый opengl и drm вообще во всех юзерспейсных процессах.
Если отрисовка идёт через иксы, то иксы могут запомнить состояние и графические процессы не упадут. Wayland же даже если и запомнит хэндлы поверхностей, они уже будут невалидными после сброса gpu.
Да, это хотят обходдить, реализовав переподключение к композитору, котррое конечно же забраковал гном с говном.
Там временем в иксах у меня сейчас резет gpu требует только перезапустить opengl софт.

графические процессы не упадут. Wayland же даже если и запомнит хэндлы поверхностей, они уже будут невалидными после сброса gpu.

В 2023 ловил amdgpu crash иногда, gnome-shell с вероятностью в 75% переживал падение, разве что вызвавшее краш приложение падало.
Иксы падали точно.

Читал у гномеров, что у них есть в планах улучшение поведения при gpu reset, но пока ничего не слышно более.

а к моменту тотального перехода на вейланд он экран-то поворачивать научится?

а то сейчас с этим как-то не очень - «compositor doesn’t support wlr-output-management-unstable-v1» или еще какая-нибудь херь

Это радует, значит есть хоть какие-то подвижки. Когда я последний раз проверял композиторы, lost context никак не обрабатывался вообще, оставляя необновляющийся замусоренный экран
Чтобы иксы переживали падение у меня там хак небольшой, иначе glamor отваливается.
Вот кстати принудительный glamor на amd тоже кучу проблем создавать. Все остальные драйвера реализовали 2д часть без glamor (exa/uxa/sna), чаще всего это либо API какого-то 2д блиттера, минимальный stateless драйвер, умеющий blit для 3д движка.
Проблема glamor в том, что он stateful и ему нужно наврать из ядра что контекст не потерялся, это помогает в 100% случаях не уронить иксы

необновляющийся замусоренный экран

Ну на моей 580 именно так и происходит - причём часто даже само ядро зависает после oops, так что тут для начала нужно amdgpu reset амудешникам чинить.

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

На 580 ситуация сложнее - там при резете vram теряется. На таком gpu нормально пережить резет нельзя, только перезапускать всё, что исполтзует gpu. Я начинал как-то реализовывать обработку потерянного контекста в glamor, но в итоге забил т.к купил 6600, а она уже она vram не замусоривает при резете.

И? Это должно как-то изменить моё мнение про неосиляторство каноникла?

Ты понимаешь разницу между неосилили и осилили, но не приняли? Хотя кому я пишу...

а к моменту тотального перехода на вейланд он экран-то поворачивать научится?

У меня поворачивается. Manjaro. KDE6. Wayland.

У меня поворачивается. Manjaro

рад за тебя.
а тред про Убунту

а к моменту тотального перехода на вейланд он экран-то поворачивать научится?

а тред про Убунту

Проблема не в Wayland. Проблема в Убунте.

Ты понимаешь разницу между неосилили и осилили, но не приняли?

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