Перезагрузка Wayland композитора без потери сессии

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

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

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

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

Отставание от винды в этом плане всего на какие-то жалкие 14 лет. И то, разработчики gnome, насколько знаю, решили такое не реализовать.

а вот вейланд вроде как раз какой-то не очень клиент-серверный?

Как раз клиент-серверный. Композитор присутствует в единичном экземпляре. Клиенты к нему подключаются через сокет.

Это хорошо, конечно. Но всякие хромы/фоксы/электроны/gtk-приложения этим никак не затронуты, да?

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

В общем движение хорошее, но полноценное распространение эта фича получит ещё не скоро.

Это хорошо, конечно. Но всякие хромы/фоксы/электроны/gtk-приложения этим никак не затронуты, да?

Нет, это реализовано в Qt. Надеюсь что если будет пользоваться спросмо и прочие тулкиты подтянутся.

не скоро

Поживем увидим. Но лучше иметь такую фичу хоть в органиченом наборе приложений, чем нигде.

Ага, это чтобы плазма продолжала падать, но пользователи не ныли. Ловко!

Падение плазмы тут не причём. От него приложения не закрываются.

Это для того, чтобы kwin_wayland мог падать и пользователи не ныли. Но он и так не падает. Как минимум лично я не помню, когда я такое в последний раз видел, разве что в начале перехода кед на wayland.

Нет, это реализовано в Qt. Надеюсь что если будет пользоваться спросмо и прочие тулкиты подтянутся.

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

Ей богу, просто позор и днище. Чуваки задались целью сделать максимально через жопу всё.

Нет, это реализовано в Qt.

Есть где нибудь описание подробностей? Какой-то специальный Wayland протокол для этого сделали?

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

Дело не в api. Дело в том, что композитор – огромный монолит, в который всё напихано зачем-то.

так ведь там в статье они пишут: we have pending patches for GTK, SDL and even XWayland

Wayland – единственная шняга, для которой такое нужно реализовывать в каждом клиенте

«наши автомобили самые красивые, внедрены самые совершенные инженерные решения, бла-бла-бла…»

теперь автомобильному дилеру достаточно просто добавить свое…рулевое управление, … тормозную систему … и подвеску тоже … ах, да, и двигатель вам тоже добавить придется … нет, вы сами должны его разработать… …ну, и топливную систему(слышны звуки ударов) … ой, и систему охла…(крики «по яйцам врежь ему!»… ох…

архитектура доставляет, канешна.

Первая ссылка в посте на блог автора патчей в Qt. Можно у него спросить.

https://discuss.kde.org/t/qtwayland-6-6-brings-robustness-through-compositor-...

Это они падучесть кед так пофиксили? Типа, нехай падают, лишь бы юзер не заметил?

на линуксе заставить всех писать используя определённое апи нельзя.

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

с композитором не путаете?

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

После близкого знакомства с gpu hang на слабой встройке Amd hd3000 + blender 3.3 я вообще считаю что винды просто успешнее ресетят ГПУ, по признакам похоже на «перезагрузку драйвера» (экран становится чёрным, потом восстанавливается) но это не полный крах когда kernel oops + hw/bus hang, а что-то восстановимое в работопсопосбное состояние.

Ну да, виртуализация ГПУ вроде как с Висты есть, при поддержке железа, ага (gpu contexts). Но это всех классов ошибок это не спасает … А в Линуксе - ну да, несколько по остаточному приципу это gpu recovery долго делалось, частично потому что доки были закрыты на АМД с Нвидией, частично потому что ГПУ это такой свой мирок с виртуальной адресацией и прочим, что неприятно отражается на скорости написания софта под него (драйверов).

Ну вот, паритет с иксами по-тихоньку приближается. Еще года два-три, и на зеленых картах заработает, а через пять будет готово для десктопа :-D

После близкого знакомства с gpu hang на слабой встройке Amd hd3000 + blender 3.3 я вообще считаю что винды просто успешнее ресетят ГПУ, по признакам похоже на «перезагрузку драйвера» (экран становится чёрным, потом восстанавливается) но это не полный крах когда kernel oops + hw/bus hang, а что-то восстановимое в работопсопосбное состояние.

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

Но это всех классов ошибок это не спасает … А в Линуксе - ну да, несколько по остаточному приципу это gpu recovery долго делалось, частично потому что доки были закрыты на АМД с Нвидией, частично потому что ГПУ это такой свой мирок с виртуальной адресацией и прочим, что неприятно отражается на скорости написания софта под него (драйверов).

Дело не в закрытости. Просто в лялексе граф.подсистема – это ад и холокост. Даже если вспомнить историю иксов отдельно от Wayland, в которых сначала дрова с пафосом выносили из ядра, а потом с таким же пафосом обратно запиливали KMS и прочие DRM. При этом в лялексе нет safe mode для гуя. Т.е. либо всё отлично работает, либо хер тебе а не вывод на экран. Короче, всё плохо.

компонент direct rendering manager в ядре с поздних 2.2 Совсем в юзерспейсе был utah-glx

но там (dri1/drm) сначала не было тонкого управления памятью (например был общий back/front/depth буфер на всех, окошки вырезались «ножницами»), и установки видеорежимов. в kms/dri2 это добавили.

А в Вин только на поверхности все кажется хорошо - поглубже в дебри и быстро всплывают всякие междусобойчики между Нвидия и Микрософтом к примеру, так что у АМД почти постоянно даже под Вин то пиксельные шейдеры в оригинальном Радеоне чуть не той системы, то тесселяцию в r200 никто не использовал, то еще какие-нибудь мелочи типа close to metal интерфейса, который как бы прародитель opencl, но на самом деле нет.

Что в Вин,что в Лин, что в макоси часть компонентов драйвера в ядре, часть - в пространстве пользователя. И попытки натянуть драйвер на свежую Амд встройку на вин7 - приключение которое у меня не получилось, хотя «в интернете» со скриншотами вроде как ставили … драйверочек мааленький, всего несколько сот мегабайт :) (на этом фоне 10 мб монстр от нвидии 15 летней давности уже не кажется таким монструозным ..ах да Нвидия еще пол-графического стэка в своей проприетарщине тащила - glx, своя архитектура ускорения 2д, ….)

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

И попытки натянуть драйвер на свежую Амд встройку на вин7

Удивительно, правда? Попробуй натянуть драйвер на свежую встройку AMD на ядро 2.6.32.

спасибо, я лучше со стороны посмотрю как на РеактОС ДХ10 нятягивают :)