LINUX.ORG.RU

Вышел Wlroots 0.16

 ,


1

0

Wlroots — это набор самостоятельных компонентов и модулей для создания своего уникального композитного менеджера Wayland.

Изначально был написан для разработки SwayWM, но позже набрал популярность и стал использоваться при написании других WM: River, DWL, Cage, Wayfire и т.д. (с полным списком проектов можно ознакомиться здесь).

Основные изменения:

  • добавлена поддержка новых протоколов: ext-session-lock-v1, idle-notify-v1 и single-pixel-buffer-v1;
  • API сцены оптимизирован и добавлены новые функции;
  • реализована отрисовка с помощью Vulkan;
  • переработан API устройств ввода;
  • wlr_damage_ring заменяет wlr_output_damage, что уменьшает нагрузку на процессор;
  • реализована минорная версия xdg-shell, позволяющая изменять положение и размер всплывающих окон;
  • реализована высокая точность прокрутки колесом мыши;
  • реализована дополнительная версия 4 wlr_output_management-v1, в которой добавлена поддержка управления адаптивной синхронизацией (VRR);
  • сделан рефакторинг кода wl_surface и DRM.

Критические изменения:

  • произведён рефакторинг xdg-shell и устройств ввода;
  • разделены реализации wl_compositor и wl_subcompositor;
  • исправлены типы в layer-shell и добавлена поддержка v3;
  • xdg-positioner — обновлена и переписана логика.

Изменения отрисовки и внутреннего устройства:

  • новый механизм отрисовки разрешает создание текстур во время рендеринга;
  • новая реализация wlr_buffer;
  • замена wlr_texture_write_pixels и update_from_buffer.

Изменений много, полный список по ссылке ниже.
Сейчас происходит обновление проектов, зависящих от Wlroots. Разработчики описывают изменения как позитивно влияющие на производительность. Уже рекомендуют пробовать пользоваться своими WM.

>>> Подробности



Проверено: hobbit ()
Последнее исправление: Virtuos86 (всего исправлений: 7)
Ответ на: комментарий от Skullnet

И получается Wayland - это зоопарк говна, а в Xorg одна стандартизированная реализация. Азаза.

Ага, так и получается.

cumvillain
()
Ответ на: комментарий от Skullnet

И получается Wayland - это зоопарк говна, а в Xorg одна стандартизированная реализация. Азаза.

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

khrundel ★★★★
()
Ответ на: комментарий от khrundel

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

СИТИВАЯ ПРАЗРАЧНОСТЬ!!11

Правда, в Wayland есть waypipe, но это не то, и он не из коробки, и вообще, надо было как в иксах.

Original_1
()
Ответ на: комментарий от Original_1

Блин, точно. Был не прав, есть одна такая фича, которая появилась в иксах не случайно.

khrundel ★★★★
()
Ответ на: комментарий от Desmond_Hume

Наблюдаю стабильную работу Wayland в Ubuntu 22.04 … это нормально?

Повезло :) У меня на тестовой машине с 1050ти и проприетарным драйвером nvidia есть некоторые интересные особенности.

Через некоторое время в firefox, при отображение статичного кадра на Youtube начинается мерцание в области статичного кадра. Двигаем мышкой- пропадает.

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

Отсутствие нормального ускорения видео в большинстве видеоплееров. Jellyfin media player - не работаете от слова совсем, показывая черное окно и на этом все. Тыкать в настройки ее не нужно, сама она - обновлена, платформа там выставлена правильно, расширения включены. оставил до лучших времен. Все равно используется в основном как сервер.

Kodi-wayland - работает, однако при проигрывании, через некоторое время начинает выдавать фризы. В сессии X11 такого не происходит.

Так что я лично - не могу сказать, что wayland стабильно работает на ubuntu. Даже после установки свежего 11-го вестона проблемы никуда не ушли.

Единственное, что могу отметить, так то, что прогресс таки идет и вроде как в правильном направлении.

DrRulez ★★★★
()
Последнее исправление: DrRulez (всего исправлений: 2)
Ответ на: комментарий от alex1101

Посмотрю, спасибо. Ротому как одна из причин, отчего я вообще начал более пристально смотреть на wayland в том, что на 4к мониторах, при выставлении дробного масштабирования, некоторые fullscreen приложения (тот-же kodi), отрисовываются - неверно. В wayland такой проблемы - нет.

DrRulez ★★★★
()

Эх, поскорей бы уже вейленд стал готов для десктопа, очень хочу перейти на Hyprland или подобный ВМ.

provaton ★★★★★
()
Последнее исправление: provaton (всего исправлений: 1)
Ответ на: комментарий от Skullnet

Сектанты-разработчики GNOME могут думать что угодно про себя и окружающую их реальность. Если бы существовал достаточный набор базовых обязательных для десктопа протоколов, то их бы реализовали со стороны без проблем. И у нас был бы, условно, wlroots, совместимый с KDE, GNOME и так далее. А уж насколько странно реализовывали бы их последние - это их, гномеров, дело.

geraet4501
()
Ответ на: комментарий от Aceler

Не все композиторы это умеют. В sway или labwc нет встроенной панельки. В итоге в sway это сделано через отдельный unix socket.

cumvillain
()
Ответ на: комментарий от geraet4501

Только вот весь софт пишут с оглядкой на GNOME, а не на wlroots. В итоге, чтобы шарить экран, вместо тривиального протокола wlroots тебе нужны костыли для гномовских порталов, pipewire и dbus.

cumvillain
()
Ответ на: комментарий от cumvillain

Только вот весь софт пишут с оглядкой на GNOME, а не на wlroots. В итоге, чтобы шарить экран, вместо тривиального протокола wlroots тебе нужны костыли для гномовских порталов, pipewire и dbus.

Порталы как раз-таки не гномовские, а способ привести разные реализации в композиторах к общему знаменателю. Так-то в Mutter есть отдельный внутренний API для захвата экрана, поэтому работа через портал + pipewire — это на самом деле благо.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Порталы как раз-таки не гномовские, а способ привести разные реализации в композиторах к общему знаменателю. Так-то в Mutter есть отдельный внутренний API для захвата экрана, поэтому работа через портал + pipewire — это на самом деле благо.

А зачем тебе портал и pipewire, если ты можешь это сделать двумя вызовами библиотечных функций (причем ещё и быстрее)?

cumvillain
()
Ответ на: комментарий от cumvillain

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

khrundel ★★★★
()
Ответ на: комментарий от cumvillain

А зачем тебе портал и pipewire, если ты можешь это сделать двумя вызовами библиотечных функций (причем ещё и быстрее)?

А через что будут работать эти библиотечные функции? Вы, случайно, не путаете интерфейс с реализацией?

Rootlexx ★★★★★
()
Ответ на: комментарий от X512

Порталы я так понимаю прибиты к тормозному d-bus.

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

Rootlexx ★★★★★
()
Ответ на: комментарий от khrundel

Я вообще не понимаю, зачем кому-то в здравом уме может потребоваться xrandr.

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

Давай я тебе дам ответ на общий вопрос: «нормальна ли ситуация, где каждый композитор пилит функцию X»? Ответ: зависит от функции. Если функция реально нужна, работает везде одинаково и должна вызываться из клиентского кода, то никто не запрещает договориться и запилить отдельный протокол или расширение wayland её реализующую.

Она реально нужна. Не договорились. Как и с кучей других фичей.

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

Вот в иксах так и было. Ты запилил dwm, запустил свой zoom и он работает, потому что плевать что у тебя за композитор. В вяленде все не так – ты скачал zoom, а он только под гном написан.

cumvillain
()
Ответ на: комментарий от Rootlexx

А через что будут работать эти библиотечные функции? Вы, случайно, не путаете интерфейс с реализацией?

Нет, я не путаю интерфейс с реализацией. Смотри, сейчас есть xdg-desktop-portal-, который:

  • Берет кадр (через приватный API композитора)
  • Пихает его в pipewire

Клиент:

  • Высасывает через этот fd кадры
  • Пихает куда-то дальше по стеку

Авторы wlroots предложили протокол, который позволяет клиенту сразу:

  • Брать кадр (через стандартизированный протокол композитора)
  • Пихать его куда-то дальше по стеку

Видишь разницу? В одном случае тебе для задачи «взять кадр и пихнуть» нужны pipewire и dbus, в другом – нет.

cumvillain
()
Ответ на: комментарий от cumvillain

Нет, я не путаю интерфейс с реализацией

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

Смотри, сейчас есть xdg-desktop-portal-, который:

  • Берет кадр (через приватный API композитора)
  • Пихает его в pipewire

Клиент:

  • Высасывает через этот fd кадры
  • Пихает куда-то дальше по стеку

Вы не разбираетесь в том, как работает этот механизм. Никакие кадры через xdg-desktop-portal не передаются. Портал лишь позволяет клиенту получить дескрипторы потоков PipeWire, откуда тот уже напрямую читает данные.

Ещё раз: задача портала — наладить коммуникацию между клиентом и PipeWire, и вся передача данных далее осуществляется напрямую из PipeWire в клиент, в идеале через DMA-BUF.

Почему PipeWire? — потому что это, внезапно, универсальный аудио- и видео-фреймворк. Тот же Mutter отдаёт буфер напрямую через PipeWire-ноду.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Путаете-путаете.

Нет, не путаю.

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

Этот API разный у всех, хотя есть стандартный протокол. Понимаешь, да? Вместо одного API есть четыре разных API, потому что фреймы, которые композитор пихает в pipewire, берутся не из воздуха, а из композитора через четыре разных API.

Вы не разбираетесь в том, как работает этот механизм. Никакие кадры через xdg-desktop-portal не передаются. Портал лишь позволяет клиенту получить дескрипторы потоков PipeWire, откуда тот уже напрямую читает данные.

Ты просто не умеешь читать. Это буквально то, что я выше написал.

Ещё раз: задача портала — наладить коммуникацию между клиентом и PipeWire, и вся передача данных далее осуществляется напрямую из PipeWire в клиент, в идеале через DMA-BUF.

Ты почему-то зациклился на той части, которая передает данные клиенту, игнорируя момент передачи данных в сам pipewire из композитора. Ещё раз: они не из воздуха в него передаются, они туда передаются через приватные API композитора.

cumvillain
()
Ответ на: комментарий от cumvillain

Вместо одного API есть четыре разных API, потому что фреймы, которые композитор пихает в pipewire, берутся не из воздуха, а из композитора через четыре разных API.

Композитор пихает кадры в PipeWire, беря их у (ещё одного? самого себя?) композитора через 4 разных API? Шта? Вы сами-то можете прочитать, что понаписали?

У композитора уже есть буфер с кадром, на то он и композитор. И он отдаёт этот буфер клиенту через граф PipeWire, где этот композитор — входная нода.

Никакие кадры через xdg-desktop-portal не передаются. Портал лишь позволяет клиенту получить дескрипторы потоков PipeWire, откуда тот уже напрямую читает данные.

Ты просто не умеешь читать. Это буквально то, что я выше написал.

Ну да, ну да:

Смотри, сейчас есть xdg-desktop-portal-, который:

  • Берет кадр (через приватный API композитора)
  • Пихает его в pipewire

А чуть выше у вас пихает кадры уже не xdg-desktop-portal, а композитор… Смешались в кучу кони, люди…

Ты почему-то зациклился на той части, которая передает данные клиенту, игнорируя момент передачи данных в сам pipewire из композитора. Ещё раз: они не из воздуха в него передаются, они туда передаются через приватные API композитора.

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

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

Rootlexx ★★★★★
()
Ответ на: комментарий от cumvillain

Да, это более примитивный метод. У использования PipeWire, однако, есть преимущества, например:

  • PipeWire не ограничен Wayland, ведь ничто не мешает так захватывать экран и в X11. В результате приложениям не нужно будет реализовывать 100500 методов захвата экрана.

  • Поскольку это универсальный фреймворк, то это позволяет обрабатывать данные в единой точке из самых разных источников: захват ли это экрана, съёмка ли с веб-камеры, или ещё что.

Rootlexx ★★★★★
()
Ответ на: комментарий от cumvillain

Она реально нужна. Не договорились. Как и с кучей других фичей.

Конкретно xrandr - не нужна. Вообще. Мониторы подцепились, выбрал какой справа, какой слева и пользуешься. Если тебе нужно что-то большее, значит с тобой что-то не так.

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

Вот в иксах так и было.

В иксах так не было. Был xorg и всё. А если бы я, например, захотел бы переписать xorg на Rust, то создать продакшен-реди совместимую с софтом реализацию я бы не смог. И даже коллектив из 10 не-фуллтайм разработчиков не смог бы. Поэтому X и плохи. Всё это нытьё иксофанатиков, оно от чего происходит? Ну подумаешь, проклятые корпорасты из редхат запилили свой гуи-протокол, в первый раз что ли? Вон в андроиде тоже свой. Скатертью по жопе, без вас воздух чище. Однако xorg - это такой копролит, что иксофанатики сами не смогут его поддерживать, а уж отрефакторить или переписать тем более. Вот и требуют, чтоб корпорасты не уходили, продолжали работу.

khrundel ★★★★
()
Ответ на: комментарий от Rootlexx

Почему PipeWire? — потому что это, внезапно, универсальный аудио- и видео-фреймворк.

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

SkyMaverick ★★★★★
()
Ответ на: комментарий от alex1101

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

SkyMaverick ★★★★★
()
Ответ на: комментарий от Skullnet

Классная статья в которой хорошо показано отношение разработчиков Wayland к пользователям. «Если у нас чего-то нет, то вам это и не нужно» Типичный гномосечный подход. И почему же Вяленый не взлетает, кто знает 🤷?

WatchCat ★★★★★
()
Ответ на: комментарий от alex1101

Вокруг только и разговоров, что о шаринге экрана, а я не понимаю, нафиг он нужен)

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

А вообще, ещё желательно не только шаринг иметь, а и управление(такое, кстати, вяленд вообще позволяет с его порталами?), ибо часто хочется при шаринге перехватить управление(с разрешения конечно) и показать как правильно делать.

Loki13 ★★★★★
()
Последнее исправление: Loki13 (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.