Обновилась утилита xisxwayland

А ты используешь утилиту, которая используется для проверки используются ли иксы или используется xwayland?

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

Утилита используется для проверки используются ли иксы или xwayland.

Утилита используется для проверки являются ли используемые иксы xwayland.

Обновилась

Устарела, теперь (точнее в следующем релизе) достаточно проверить используемые X11 extension, например с помощью xdpyinfo.

P.S. Хотя не понимаю почему просто в xrandr не посмотреть название output-а.

Обновилась Устарела

На самом деле они добавили проверку XWAYLAND extension.

иксы == xwayland

xorg => deprecated

А что, wayland уже готов для десктопа?

Уже лет пять как готов.

В нём коньки не работают, так что я подожду.

А почему тогда в нем нихрена не работает?

А они нужны? Это же чисто декоративная хрень.

Что именно не работает? Всё нужное работает.

Ну, да, привычная хрень.

Но зачем? Она же на рабочем столе, а рабочий стол 99.9% времени закрыт окнами. В чём смысл её существования?

Глобальные хоткеи в приложениях, запись с экрана, скриншоты, куча связанного с 3D и так далее. Если я захочу использовать лялексовый десктоп эпохи начала 2000х, я поставлю слаку тех времён. А пока что Wayland – это такой жирнейший откат назад. И не слишком понятно ряди чего это.

Глобальные хоткеи в приложениях

Не работают, и это хорошо.

запись с экрана

Работает.

скриншоты

Работают.

куча связанного с 3D

Что именно? Звучит как эталонное 4.2

Не работают, и это хорошо.

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

Работает.

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

Работает.

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

Что именно? Звучит как эталонное 4.2

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

Вон сахрикту патчил кде что-бы в галерею скриншот выложить. Уже не по протоколу, зато работает. Это и называется костыли Вроде можно по другому, через дбас передать разрешение определённому приложению и тогда ВМ ему будет отдавать картинки… но этого нету вроде как нигде толком по нормальному нигде

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

Хорошо будет когда все эти механизмы обхода и подобное включат в вяленый =) Тогда он будет готов ещё больше.

Только специальными приложениями заточенными под конкретные DE

4.2, портал работает одинаково во всех DE

Сделаешь снимок экрана в KDE через gnome-screenshot? И наоборот в Gnome40 через KSnapshot. Или программой scrot или другими приложениями которые отвалились.

Порталы это и есть эталонный полезный костыль который добавили в вяленый и теперь это не костыль =)

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

Я не проверял ибо у меня ни то ни другое

У меня тоже.

Кстати, создал фичреквест по поддержке портала в scrot, спасибо за подсказку.

фичреквест по поддержке портала

Хм…

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

В гноме - да, спрашивает. Недавно запилили таки разрешение на неинтерактивную съёмку скринов. Приложение один раз запрашивает разрешение и после этого никаких дополнительных диалогов. Можно всегда выдать/отозвать разрешение в настройках gnome. Выйдет эта фича в gnome 43.

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

Тем не менее, поддержку портала они запилили. https://github.com/flameshot-org/flameshot/pull/2035

как те диалоги в Vista, которые всех бесили?

Они кстати никуда не делись в следующих редакциях windows.

=)

Костыли-костылики. Похоже, они не хотели ходить через порталы из-за надоедливых диалогов. А теперь вынуждены, потому что GNOME закрыл функции для генерации скриншотов.

Если так подумать, то почему вообще задача, напрямую связанная с оконной системой, реализуется костылём сбоку? И эти люди высмеивали иксы фразой «why would you ever fix anything when you can work around it».

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

Они всё ещё надоедают, но как-то разработчики всё-таки сумели умерить их количество по сравнению с Vista. Хотя возможно, что в Vista специально их показывали избыточно часто, чтобы потом обычное количество воспринималось пользователями как благо. Если так, то подход сработал на все 100%.

Если так подумать, то почему вообще задача, напрямую связанная с оконной системой, реализуется костылём сбоку?

С оконной системой - да. Но не с протоколом дисплейного сервера. Разработчики wayland категорически отказались создавать протокол для захвата экрана, так как это, по их мнению (и я с ними согласен) не входит в задачи дисплейного протокола.

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

С оконной системой - да. Но не с протоколом дисплейного сервера.

Только вот Wayland объединяет оба понятия в одно.

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

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

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

Wayland объединяет оба понятия в одно

Какие понятия? Напомню, что wayland - это протокол. И когда я говорю о «разработчиках wayland», я говорю о разработчиках протокола а не его реализаций.

Раз уж начали решать проблемы, не лучше ли решить как можно больше? Или это специально откладывается на потом?

О каких именно проблемах идёт речь? Что откладывается на потом?

Напомню, что wayland - это протокол.

Ой, как удобно! X11 — тоже протокол. И там есть контроль разрешений и атомарное отображение. Но так сложилось, что если включить контроль разрешений, многие приложения могут поломаться, а атомарное отображение не везде реализовали в драйверах и приложениях. Поэтому когда упоминают, что у иксов проблемы с безопасностью и тирингом, тупо прикрываться тем, что в протоколах вообще-то есть способы на эти проблемы не наступать, потому что реальность отличается от воображаемого мира.

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

Какие понятия?

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

говорю о разработчиках протокола а не его реализаций.

Разработчики Wayland разрабатывают и Weston, который декларирован эталонной реализацией. Эталонная реализация содержит протокол скриншотов. Почему он есть в эталонной реализации, но при этом он не стандартизирован? Это проявление проблемы с видением цели Wayland. Такое ощущение, что они руководствуются идеологией, мол, а, потом по ходу дела разберёмся.

О каких именно проблемах идёт речь?

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

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

Например, глобальные горячие клавиши

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

позиционирование окон на экране

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

Во вторых, для элементов оболочки (их я не отношу к группе "пользовательские приложения) - есть протокол layer-shell. Он не позволяет позиционировать обычные окна, но специальные элементы оболочки, наподобие панелей и уведомлений - пожалуйста, как угодно. Такие объекты UI не считаются toplevel окнами в терминологии wayland.

определение видимости окна

А это зачем может быть нужно?

С цветовыми профилями вроде понятно

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

Возможно это что то говорит о нужности этой фичи?

но на самом деле говорит о непригодности вэйланда

В протоколе wayland, тем более как обязательная для реализции часть протокола - точно не нужно.

Отстойный из тебя архитектор :-D.

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

Спасибо, кэп! Неужели необходимость проектирования фич это что-то не очевидное? Однако пока что достаточной глубины проектирования нет. Ощущение, будто проектированием занимаются вот примерно как ты сообщения пишешь — нет и всё. Никакой аргументации, просто «точно не нужно».

по какой то причине никто её ещё не сделал. Возможно это что то говорит о нужности этой фичи?

Ох, лол. Конечно же ничего не говорит о нужности.

не нужно для пользовательских приложений. Совсем. Никак. Вообще.

Yaquake, например. Там, вроде, костылят открытием окна на полный экран, чтобы ну хоть как-то сносно было. Опять-таки, плохой из тебя архитектор. На лицо подход «мне не нужно, значит никому не нужно».

А это зачем может быть нужно?

Недавно на форуме мелькала ссылка на статью про проблемы Wayland от одного из разработчиков mpv, который пришёл в mpv дорабатывать поддержку Wayland. Вкратце — если рисовать в скрытое окно через контекст EGL, можно встрять, потому что в Mesa вынужденный костыль с ожиданием колбека от композитора, который может не прийти. Из положения выходят попыткой угадать, когда окно скрыто, а это дополнительные костыли.

А вообще - не нужно как часть протокола. Как часть окружения - пожалуйста, реализуйте как хотите.

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

говорит о непригодности вэйланда

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

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

кмк, для ряда задач он остается непригодным, проверю на досуге

X11 — тоже протокол.

Дык не только же. Там ещё есть X server, который работает отдельным процессом, к которому идут запросы по сети (как минимум, по IP 127.0.0.1). И он уже выполяет всю работу по этим запросам.

В случае Wayland'а всю эту работу выполняют тулкиты и DE.

Ну обновилась и обновилась.

Дык не только же. Там ещё есть X server

Ну да. В Wayland тоже есть сервер-композитор. Поэтому глупо прикрываться фразой «wayland это только протокол». X11 тоже только протокол, но когда говорят про иксы, имеют в виду вообще всё вместе связанное.

Обычно мы судим о себе по намерениям, а о других — по действиям. Так и тут: когда говорят про иксы, говорят про десятилетия костылей, но когда говорят про Wayland, говорят о идеях. Конкретные проблемы… ну, их же решат, да?

к которому идут запросы по сети (как минимум, по IP 127.0.0.1).

Если локально, то обычно через AF_UNIX, а не через AF_INET.

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

То есть ты предлагаешь возложить на композитор ещё и задачу хранения разрешений доступа а также интерактивного взаимодействия с пользователем? И сделать всё это обязательной к реализации частью протокола? Я правильно тебя понял?

Вкратце — если рисовать в скрытое окно через контекст EGL, можно встрять

Вот это как раз плохая архитектура. Wayland не гарантирует, что frame callback’и будут приходить регулярно и что они вообще будут приходить. Пишите свои приложения соответствующим образом. Чтобы можно было скипнуть сколько угодно кадров без нарушения целостности картинки, и работоспособности приложения.

Отличное решение!

В данном случае нормальное решение. Эта фича вовсе не обязательна и не необходима для работоспособности. Если разработчики окружения считают, что она им нужна, они найдут способ её реализовать.

но когда говорят про иксы

Обычно имеют в виду Xorg а не X11.

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

То есть ты предлагаешь возложить на композитор ещё и задачу хранения разрешений доступа а также интерактивного взаимодействия с пользователем? И сделать всё это обязательной к реализации частью протокола? Я правильно тебя понял?

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

Вот это как раз плохая архитектура. Wayland не гарантирует, что frame callback’и будут приходить регулярно и что они вообще будут приходить.

Есть три варианта:
① изменить EGL/OpenGL, чтобы они стали соответствовать модели Wayland;
② изменить Wayland, чтобы он стал соответствовать EGL/OpenGL;
③ обложиться костылями и притвориться, что всё хорошо.

Пока что реализован вариант ③. Ты какой бы предпочёл? А какой реалистичнее?

Я бы предпочёл вариант ②. Но пока что всё движется к окаменению варианта ③. Технология только выкатывается, а уже требует костылей. Это навевает грусть.

Эта фича вовсе не обязательна и не необходима для работоспособности.

Опять-таки, налицо подход «мне не нужно, значит никому не нужно».

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

Ты какой бы предпочёл? А какой реалистичнее?

Вариант 4. Не трогать ни wayland ни opengl, а писать софт, который соответствует спецификации wayland. Если ты всю логику своего приложения засунул в обработчик frame callback’ов, не удивляйся, что приложение будет «заморожено» как только оно скроется с экрана.

Опять-таки, налицо подход «мне не нужно, значит никому не нужно».

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

Вариант 4. Не трогать ни wayland ни opengl, а писать софт, который соответствует спецификации wayland.

Ты так и не понял. Проблема не в пользовательском софте, а в инфраструктурном. Конкретнее, в Mesa. Переделать её нельзя, потому что костыль там вставлен из-за несовместимости моделей рисования EGL/OpenGL и Wayland. Любое решение, не включающее в себя пересмотр моделей рисования, будет включать в себя костыли.

Костыли в реализациях не являются чем-то необычным, особенно если стыкуемые модели не вполне совместимы. Но если есть возможность починить одну из моделей, упираться странно. EGL/OpenGL изменить не получится, Vulkan тоже. Но Wayland-то можно уж поменять было, наверное?