Спустя 15 лет индеец Зоркий Глаз заметил, что...

🤣🤣🤣

Спустя 15 лет. Ору.

Лучше объясни, зачем реализовывать эти протоколы, например, в gnome? Ведь самому по себе гному и так хорошо, у гимпа есть однооконный режим, а проблемы лазаруса и imagej разрабочтиков gnome не касаются

Цирк какой-то.

Вайландохейтеры такие смешные: нет протокола – «кококо, дауны ниасилили!!!», есть протокол – «кококо, 15 лет, ололо»

Ведь самому по себе гному

Настоящему индейцу завсегда везде ништяк. 😁

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

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

Протоколы вейланда пребывают в суперпозиции.

Вайландохейтеры такие смешные: нет протокола – «кококо, дауны ниасилили!!!», есть протокол – «кококо, 15 лет, ололо»

Мы не хейтеры. Я вот лично угораю с этого цирка, жру попкорн и хочу больше этого!

Но ты продолжай вести наблюдения.

Протоколы вейланда пребывают в суперпозиции.

Почитай пост чувака, там больше лулзов. Он пишет, что мол да, указывать координаты надо через протокол в Wayland, а вот запрашивать свои координаты – отдельным вызовом через dbus.

Я рыдаю с этих людей. Настолько чудовищного подхода к проектированию софта я нигде ещё не видел. Clown driven design, прямо. Honk honk!

Я в шоке)) Как они это несут на полном серьезе.

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

Clown driven design

Это надо как тэг для таких тем)

Я в шоке)) Как они это несут на полном серьезе.

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

Ну, эта проблема давно описана, на самом деле: second-system effect. Про неё ещё Фред Брукс писал почти 50 лет назад, а он говна на своём веку повидать успел всякого!

Вот вот.
У подхода wayland конечно есть и плюсы и минусы. Взять например xrandr. В de сделали диалог настройки экранов. Он синхронизирует и настройку многомониторной конфигурации через xrandr и настройку xinput. Но потом в любой момент пользователь иои сторонний софт может взять и прооверрайдить эту конфигурацию, тем самым приведя её в неконсистентное состояние, ещё и не уведомив об этом DE.
Подход же со стороны wayland тут - у композитора и DE монопольный контрлль над разрешением экрана. Никакой xrandr его не сломает. В протоколах должна быть толькр информкция о дисплеях. Ну в крайнем случае - хинты на переключение режимов.
Ну и очевидный минус такого подхода - у каждого способа способ настройки и добавления режима свой, а из-за лени разрабоичиков какие-то фичи могут вообще отсуствтовать. xrandr же везде один и xrandr-команды будут работать во всех DE, пускай и в разрез с его конфигурацией. А такой перенос ответственности на DE приведёт к тому что каждый всё сделает по своему и единого способа не будет

У подхода wayland конечно есть и плюсы и минусы. Взять например xrandr.

Да полное говно у них подход. У меня монитор в вялянде до сих пор нормально не пашет: Как добавить кастомное разрешение в Kwin/Wayland?, как раз из-за отсутствия xrandr или аналогичного функционала.

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

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

есть. Это было бы переизобретением иксов, они принципиально не хотят этого.
Вообще, я подозреваю, что всё закончится написанием wayland-композитора, рисующего в иксовые окна для wayland-only софта, и все, кому нужна нормальная удобная система - на иксах останутся. То что иксы такие deprecated все означают лишь что они уже закончены - в них сделали всё что надо было. Нет, конечно на самом деле есть куча вещей, которые можно было бы доработать, например сделать новый aiglx с поддержкой core профиля opengl (если compatible 2.x+ полностью пробросить сложно, то core 3.3 очень легко оборачивается в x11-подобный протокол), перезапуск glamor при потере контекста без перезапуска сервера, новые протоколы под множественные дисплеи с разной плотностью (это в принципе со стороны WM реализуется).
Но как видно, последнее делаться не будет специально чтобы всех пересадить на wayland, а остальное никому нафиг и не надо. Даже когда у меня видюха крашится, обычно иксы не ломаются сейчас, поскольку glamor практически пофиг на стейт opengl и он даже после сбоя в gpu может продолжать рисовать иксы.

Это было бы переизобретением иксов, они принципиально не хотят этого.

Отож. Иксы придумали белые цисгендерные мужчины, чтоб вы понимали.

есть. Это было бы переизобретением иксов, они принципиально не хотят этого.

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

То что иксы такие deprecated все означают лишь что они уже закончены - в них сделали всё что надо было.

Ах если бы. HDR нету всё ещё. Его правда и в Wayland нет и неясно когда будет.

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

Прикольно. Не знал.

Прикольно. Не знал.

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

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

ну к слову ещё, часто wayland пиарят всякими xrdesktop'ами и прочим. И я по началу тоже захотел в своём vr оверлее wayland композитор сделать. В итоге, после того, как попытался реализовать композитор без говнокода из wlroots, у меня сгорело с того, что в необходимых протоколах одна п*раша и ничего полезного и я буквально за пару дней в иксах сделал лучше, чем вообще можно было сделать в wayland:
https://github.com/mittorn/godot-screengrab/blob/master/src/xcompgrab.c
Эта штука берёт окошки уже запущенных под иксами приложений, берёт их xcomposite текстуры и посылает события в окна.
В wayland такое можно было бы сделать только со своим композитором и соответственно софт пришлось бы запускать изначально под ним. Мой вариант же берёт окна уже присутствующие в иксах и их не нужно убирать с экрана

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

Чо за патч? Скинь. У меня rx6900xt.

Эта штука берёт окошки уже запущенных под иксами приложений, берёт их xcomposite текстуры и посылает события в окна.

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

Как я понимаю, путь вяленых для таких фичей – реализовывать это через dbus. Который тоже будет дёргать композитор, конечно же, но вместо двух пересылок сообщений будет четыре, и всё это будет лагать. Захват экрана через pipewire вроде так и делают, получается хуже чем напрямую через xcomposite (я игры стримлю друзьяшкам, pipewire лагает даже на моём железе блин).

Немного оффтопну.

Знаешь, меня когда-то удивляло, что вот эти архитекторы заменили обмен сообщениями через иксы на обмен сообщениями через dbus и остановились на этом.

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

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

Вот это всегда удивляло.

А потом до меня дошло, что вот этот народ, который вокруг линуксового десктопа ошивается, они просто не умеют в проектирование.

Ну психбольница или нет это уже отдельный вопрос, сами эти люди далеко не бестолковые. Написать как минимум двое из них написали драйвера на GPU с нуля. даже если они и, вдруг, аутисты, само по себе ничего плохого о их способности к разработки не говорит, как и витюберство. конечно и проталкивание rust в ядерный драйвер возможно не очень хорошее занятие, но то, что они пытались сделать с drm подсистемой тем не менее сделало бы её лучше, сейчас она в совсем неадекватном состоянии. Чего только стоит дедлок в ядре при любом зависшем gpu таске...

Чо за патч? Скинь. У меня rx6900xt

У меня ядро 5.18, rx6950xt и rx6600xt. Тут считается что если amdgpu резеттился определёнными методами, то состояние неизвестно и надо посчитать что vram_lost. На деле же в большинстве случаев это не так. Ну и если у тебя резетился gpu - надо срочно переключиться в консоль и прибить вручную процессы, которые могли это сделать. иначе если он резетнется несоклько раз подряд, может и совсем повиснуть.

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 49f734137f15..1d307bb3cff6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2528,6 +2528,7 @@ static void amdgpu_device_fill_reset_magic(struct amdgpu_device *adev)
  * VRAM is lost or now.
  * returns true if vram is lost, false if not.
  */
+#if 0
 static bool amdgpu_device_check_vram_lost(struct amdgpu_device *adev)
 {
        if (memcmp(adev->gart.ptr, adev->reset_magic,
@@ -2544,12 +2545,12 @@ static bool amdgpu_device_check_vram_lost(struct amdgpu_device *adev)
        switch (amdgpu_asic_reset_method(adev)) {
        case AMD_RESET_METHOD_BACO:
        case AMD_RESET_METHOD_MODE1:
-               return true;
+               return false;
        default:
                return false;
        }
 }
-
+#endif
 /**
  * amdgpu_device_set_cg_state - set clockgating for amdgpu device
  *
@@ -4794,7 +4795,7 @@ int amdgpu_do_asic_reset(struct list_head *device_list_handle,
                                if (r)
                                        goto out;

-                               vram_lost = amdgpu_device_check_vram_lost(tmp_adev);
+                               vram_lost = false; //amdgpu_device_check_vram_lost(tmp_adev);
                                if (vram_lost) {
                                        DRM_INFO("VRAM is lost due to GPU reset!\n");
                                        amdgpu_inc_vram_lost(tmp_adev);

Захват экрана через pipewire вроде так и делают, получается хуже чем напрямую через xcomposite (я игры стримлю друзьяшкам, pipewire лагает даже на моём железе блин).

ладно ещё захват экрана, а отдельных окон? а события им слать? Захват экрана кстати я делаю через drm устройство, это что под иксами что под wayland одинаково работает, но требует сервис запущенный от рута.

Итого мы сейчас имеем как минимум 4 общесистемных механизма взаимодействия компонент, которые все делают «одно и то же, но иначе»:

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

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

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

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

А низзя. По двум причинам:

1. dbus тормозит как овощ. Если вспомнишь драму 10-летней давности про kdbus, то причина была как раз в этом. Если ты будешь пихать слишком много сообщений, шина встанет колом. Адекватной задержки от dbus ждать тоже не приходится, т.е. у тебя реакция на запрос может быть дольше чем пинг в другой конец страны.

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

В общем, если тебе нужно запросить название текущего трека у музыкального плеера, то тут dbus – прямо топчик. А если ты хочешь по нему гонять большие массивы данных – экран моего компа сейчас при разрешении 51202160 требует 2.6 гигабайта в секунду, если без сжатия (5120px2160px4bpp60кадров) – с жёсткими требованиями по времени, то тут полный обсёр и можно закапываться.

И тут мы приходим к главной проблеме: в десктопном Linux тупо нет подходящего IPC. За 30 лет его не то что не разработали, про это даже думать боятся. Есть вагон разных примитивов, в основном древних как сам UNIX – сокеты, сигналы, шареная память и прочая срань – но собрать из этого адекватную шины для межпроцессного взаимодействия почему-то никто не осилил.

Тут можно вспомнить мою любимую статью про Linux/Unix, которой в минувшем августе стукнуло аж 11 лет, но она остаётся всё ещё весьма актуальной: https://queue.acm.org/detail.cfm?id=2349257. Очень рекомендую, если есть лишние 5 минут за кофе.

в долбасе нет возможности отправить дескриптор текстуры экрана?

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

Я нисколько не хочу умалять их достижений – в 20 с копейками лет отреверсить драйвер и сделать аналогично, это весьма круто – но есть пара нюансов.

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

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

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

Есть.

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

в долбасе нет возможности отправить дескриптор текстуры экрана?

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

pipewire это же про звук, речь про waypipe?

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

Зато, видимо, требуется, чтобы получить на это финансирование.
«Do i need cut my tesicles to work in Collabora?» - я уже шутил не раз так
Впрочем судя по лине это и правда не обязательно, если ты готов получать финансирование с витюберства

pipewire это же про звук, речь про waypipe?

Нет, именно экран. Из-за того, что вялендовцы долго не могли договориться, как же правильно делать захват экрана, это теперь сделано через pipewire.

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

https://docs.pipewire.org/page_tutorial5.html

нет, pipewire это роутер для звука и изображения. На wayland захват экрана роутится через него

ну значит возможно с ним не так всё плохо. Значит через него можно сделать нормальную архитектуру, под события оконного менеджера например запросив уже свой сокет.
Меня в dbus одно не устраивает - в случае если шине станет плохо и она упадёт, dbus клиенты не могут переподключиться сами. Может конечно это исправили, я что-то давно таких проблем не помню, но лет 10 назад прям регулярно было. Должно быть так, что перезапустил dbus и через какое-то время сервисы обнаружили пропажу и перерегистрировались

идея не очень хорошая, т.к и тут обосрались. Повесили звук и камеры на wireотвалper, он отвалился с сегфолтом в licamera сразу после демонизации, ничего никуда не сказав. В итоге мне получилось понять что произошло через полдня отладки и чтения совершенно нерелевантных доков. Выглядело просто как запускаешь pipewire, а в нём ни одного устройства, только клиенты

Зато, видимо, требуется, чтобы получить на это финансирование.

Да не. Если мне память не изменяет, авторов ati взяли в AMD работать после покупки собственно ATI для работы над открытым драйвером.

«Do i need cut my tesicles to work in Collabora?» - я уже шутил не раз так

Что-то не гуглится.

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

Так он жеж поехавший нудист, вроде. Я не уверен, что деньги ему от втюберства идут.

Что-то не гуглится.

ну видимо не публично шутил, либо кровавая модерастия потёрла...

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

Нене, идея хорошая. Сферическая и в вакууме, правда.

У меня с ним тож регулярно косяки, особенно когда дело до Bluetooth звука доходит. Pipewire очень часто любит не тот профиль использовать, а настроек у него нормальных нету, поэтому проще его прибить и надеяться, что после перезагрузки он подцепит нужный профиль (они в рандомном порядке берутся, похоже).

Главный сопровождающий Nouveau уволился из Red Hat. Но это ещё не всё... (комментарий)

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

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

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

Как синхронизацию тогда делать? Самому руками держать у себя буфер с кадрами на случай рассинхрона? Прикинь, ты стримишь игрушку, а у тебя звук от видео отстаёт (или наоборот).

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

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

я про то, что новость - это предательство и слом канонов

ой всё

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

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

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

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