https://www.opennet.ru/opennews/art.shtml?num=57194
Любли читать такие тексты. Самое интересное, конечно, не что там с wayland с nvidia, а "как оно вообще бывает, и какие задачи люди решают".
У меня выкристаллизировалась такая мысль - wayland сейчас находится примерно рядом с эмуляторами терминала. #foot, #alacritty, #kitty, #wayland #terminfo
Вроде, есть какая-то спека, все договорились ее использовать, но все равно, все терминалы ее реализуют немного по разному, кто-то больше, кто-то меньше, и договориться между собой они не могут.
А сообщение программе про изменение размера терминала до сих пор идет через SIGWINCH(== dbus рядом с wayland, если вы понимаете, о чем я), а не in-band в потоке сообщений. Про проблемы этого подхода я рассказывал. https://ru.wikipedia.org/wiki/SIGWINCH
Удивительный факт - GNOME, такое ощущение, ненавидит wayland, и, была бы их воля, они бы все переделали поверх dbus. Я этого совершенно не понимаю, они стояли у его истоков.
Возможно, я тут упустил какую-то интересную часть истории, расскажите.
———
Я решил устроить фичекат в своей пакетной базе. #mix
Как-то писал, что хочу, чтобы из моей пакетной базы можно было собирать как статически слинкованные программы, так и динамически слинкованные.
Сейчас стало понятно, что пакетная база будет выглядеть очень криво, если из нее надо собирать и то, и другое.
Смотрите.
Довольно часто рядом с библиотекой лежат какие-то данные.
В случае динамической линковки очень естественно, когда .so лежит рядом с данными для этой .so. Ну, типа, если уж слинковал это либу, то и данные понадобятся.
В случае .a файлов это совершенно не так. После того, как программа слинкована, мы совершенно точно не хотим видеть рядом с данными и бинарями .a файлы.
Поэтому я разделяю пакеты не только на bin, lib(помните, рассказывал про bin, lib контексты сборки?), но еще и на aux контекст(там лежит etc/, share/, etc). Программы и библиотеки уже собираются с путями, которые указывают в этот отдельный, третий, таргет. В сборе это выглядит примерно так - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/fontconfig/mix.sh#L14
Это будет выглядеть весьма криво в случае сборки .so файлов.
Пакетная база, которая дает красивый результат для обоих "миров" - сама по себе выглядит ужасно, там куча if, и частных случаев.
Короче, я пока решил это дело пофичекатить.
Любли читать такие тексты. Самое интересное, конечно, не что там с wayland с nvidia, а "как оно вообще бывает, и какие задачи люди решают".
У меня выкристаллизировалась такая мысль - wayland сейчас находится примерно рядом с эмуляторами терминала. #foot, #alacritty, #kitty, #wayland #terminfo
Вроде, есть какая-то спека, все договорились ее использовать, но все равно, все терминалы ее реализуют немного по разному, кто-то больше, кто-то меньше, и договориться между собой они не могут.
А сообщение программе про изменение размера терминала до сих пор идет через SIGWINCH(== dbus рядом с wayland, если вы понимаете, о чем я), а не in-band в потоке сообщений. Про проблемы этого подхода я рассказывал. https://ru.wikipedia.org/wiki/SIGWINCH
Удивительный факт - GNOME, такое ощущение, ненавидит wayland, и, была бы их воля, они бы все переделали поверх dbus. Я этого совершенно не понимаю, они стояли у его истоков.
Возможно, я тут упустил какую-то интересную часть истории, расскажите.
———
Я решил устроить фичекат в своей пакетной базе. #mix
Как-то писал, что хочу, чтобы из моей пакетной базы можно было собирать как статически слинкованные программы, так и динамически слинкованные.
Сейчас стало понятно, что пакетная база будет выглядеть очень криво, если из нее надо собирать и то, и другое.
Смотрите.
Довольно часто рядом с библиотекой лежат какие-то данные.
В случае динамической линковки очень естественно, когда .so лежит рядом с данными для этой .so. Ну, типа, если уж слинковал это либу, то и данные понадобятся.
В случае .a файлов это совершенно не так. После того, как программа слинкована, мы совершенно точно не хотим видеть рядом с данными и бинарями .a файлы.
Поэтому я разделяю пакеты не только на bin, lib(помните, рассказывал про bin, lib контексты сборки?), но еще и на aux контекст(там лежит etc/, share/, etc). Программы и библиотеки уже собираются с путями, которые указывают в этот отдельный, третий, таргет. В сборе это выглядит примерно так - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/fontconfig/mix.sh#L14
Это будет выглядеть весьма криво в случае сборки .so файлов.
Пакетная база, которая дает красивый результат для обоих "миров" - сама по себе выглядит ужасно, там куча if, и частных случаев.
Короче, я пока решил это дело пофичекатить.
www.opennet.ru
Состояние поддержки Wayland в драйверах NVIDIA
Аарон Плaттнер (Aaron Plattner), один из ведущих разработчиков проприетарных драйверов NVIDIA, опубликовал сведения о состоянии поддержки протокола Wayland в проходящей тестирование ветке драйверов R515, для которой компания NVIDIA предоставила исходные тексты…
👍2
commit -m "better"
Будни #bootstrap, обещаный текст про сборку reddit desktop, #imgui * оно требует libmpv, для просмотра видосиков. Почему не ffmpeg напрямую - загадка. Все бы ничего, но сборка libmpv(или это свойство waf вообще) страдает обычным для OSS багом - "а давайте…
#imgui, #wayland, #sdl, #hidpi #gold
Так, третья, заключительная, часть рассказа про "собрать какое-нибудь приложение c imgui".
Прошлый рассказ я закончил на том, что у меня все собралось, запустилось, но было очень сильно замылено.
Скриншот мне делать лень, поэтому просто представьте себе, что картинка была rendered в буфер 100x100, который был растянут на экран 200x200.
Кстати, ровно та же проблема у меня наблюдалась с #dosbox.
Суммарно на решение это проблемы я потратил часов 10, фактически, все прошлые выходные. Зачем? Ну, потому что интересен процесс, а не результат. И потому что, предполагается, что владелец дистрибутива способен такие проблемы пользователей решать, я так думаю.
Я, пожалуй, не буду вдаваться в детали процесса, это слишком долго, я просто расскажу, как устроен hidpi в wayland, к чему это привело в модели sdl, и что я с этим сделал.
* В wayland у каждого буфера, в том числе on screen, есть, кроме обычных WxH(+ формат, но нам это не интересно), еще параметр scale. На мой взгляд, назван он неверно, и это долго меня сбивало с толку.
* Когда композитор отрисовыает буфер приложения в экранный буффер, он масштабирует буфер приложения в отношение scale этих двух буферов. Ну, то есть, если screen->scale == 2, app->scale == 1, то буфер от приложения будет увеличен в 2 раза.
* После чего композитор попиксельно отображает буфер приложения в экранный буффер, отсекая лишнее.
Давайте на примерах:
* screen == 200x200x2, app == 100x100x1. Увеличим app buffer в 2 раза, отобразим получившуюся картинку 200x200 as is. Так, фактически, работают старые приложения, которые не hidpi-aware.
* screen == 200x200x2, app == 100x100x2. Мы получим, что приложение заняло верхнюю левую четверть отведенного ей экрана.
* screen == 200x200x2, app == 200x200x2. Четкая, pixel perfect, картинка.
Что еще важно понимать?
Если композитор имеет размер буфера для приложения 200x200, и screen scale 2, то он, в качестве желаемых размерностей пошлет приложению 100x100, чтобы non-hidpi-aware приложения как-то работали. hidpi aware приложения, для того, чтобы рассчитать размер буфера для отрисовки, должны эту величину умножить на переданный scale.
А дальше все тулкиты изголяются, кто во что горазд.
Например, что делает SDL:
* Он hidpi aware, поэтому он выделяет буфер размера w * scale, h * scale. То есть, цепочка: композитор имеет буфер 200x200x2, он передает в SDL 100x100x2, SDL выделяет буфер для рисования 200x200x2. https://github.com/libsdl-org/SDL/blob/main/src/video/wayland/SDL_waylandwindow.c#L1901-L1905
* Далее SDL делает что-то странное. Он говорит, что всю отрисовку теперь мы будем делать в неких point, point у нас 100x100, каждый point физически отображается в 2 пикселя. https://discourse.libsdl.org/t/high-dpi-mode/34411
* ImGui берет размерности экрана в этих point, 100x100, делает gl viewport 100x100 над буфером 200x200, и рисует в свое удовольствие заблюренный контент.
То есть, как будто hidpi aware приложение само готовит контент низкого разрешения.
Я пробовал починить это разными способами, лучше всего сработал такой - https://git.sr.ht/~pg/ix/commit/fab9a5086801ea5e41d1e454f6c3a26abe9a06ed#pkgs/bin/reddit/desktop/hidpi/imgui_impl_sdl.cpp:
* В коде ImGui умножить размеры, передаваемые SDL, на scale.
* Получится так, что мы создадим viewport 200x200 над буфером 200x200, и отрисовка будет pixel perfect.
Почему я не могу расценивать это как финальное решение:
* Потому что, кроме gui, SDL возвращает масштабированными события от мыши, и получается, когда я их умножаю на scale, я теряю точность(мышка двигается по 2 пикселя по вертикали и гризонтали). Я не смог это заметить глазами на retina display, но как-то неаккуратно. https://forums.libsdl.org/viewtopic.php?p=43373
На мой взгляд, тут баг в SDL, что, когда приложение говорит, что оно hidpi aware, то надо ему возвращать настоящие пиксели, а не points.
Что мне делать с моим патчем в ImGui, я пока не понимаю.
BTW, должен сказать, что, после моего фикса, hidpi support в imgui кажется очень классным, потому что все размеры во float, и привязаны к размеру шрифта.
Так, третья, заключительная, часть рассказа про "собрать какое-нибудь приложение c imgui".
Прошлый рассказ я закончил на том, что у меня все собралось, запустилось, но было очень сильно замылено.
Скриншот мне делать лень, поэтому просто представьте себе, что картинка была rendered в буфер 100x100, который был растянут на экран 200x200.
Кстати, ровно та же проблема у меня наблюдалась с #dosbox.
Суммарно на решение это проблемы я потратил часов 10, фактически, все прошлые выходные. Зачем? Ну, потому что интересен процесс, а не результат. И потому что, предполагается, что владелец дистрибутива способен такие проблемы пользователей решать, я так думаю.
Я, пожалуй, не буду вдаваться в детали процесса, это слишком долго, я просто расскажу, как устроен hidpi в wayland, к чему это привело в модели sdl, и что я с этим сделал.
* В wayland у каждого буфера, в том числе on screen, есть, кроме обычных WxH(+ формат, но нам это не интересно), еще параметр scale. На мой взгляд, назван он неверно, и это долго меня сбивало с толку.
* Когда композитор отрисовыает буфер приложения в экранный буффер, он масштабирует буфер приложения в отношение scale этих двух буферов. Ну, то есть, если screen->scale == 2, app->scale == 1, то буфер от приложения будет увеличен в 2 раза.
* После чего композитор попиксельно отображает буфер приложения в экранный буффер, отсекая лишнее.
Давайте на примерах:
* screen == 200x200x2, app == 100x100x1. Увеличим app buffer в 2 раза, отобразим получившуюся картинку 200x200 as is. Так, фактически, работают старые приложения, которые не hidpi-aware.
* screen == 200x200x2, app == 100x100x2. Мы получим, что приложение заняло верхнюю левую четверть отведенного ей экрана.
* screen == 200x200x2, app == 200x200x2. Четкая, pixel perfect, картинка.
Что еще важно понимать?
Если композитор имеет размер буфера для приложения 200x200, и screen scale 2, то он, в качестве желаемых размерностей пошлет приложению 100x100, чтобы non-hidpi-aware приложения как-то работали. hidpi aware приложения, для того, чтобы рассчитать размер буфера для отрисовки, должны эту величину умножить на переданный scale.
А дальше все тулкиты изголяются, кто во что горазд.
Например, что делает SDL:
* Он hidpi aware, поэтому он выделяет буфер размера w * scale, h * scale. То есть, цепочка: композитор имеет буфер 200x200x2, он передает в SDL 100x100x2, SDL выделяет буфер для рисования 200x200x2. https://github.com/libsdl-org/SDL/blob/main/src/video/wayland/SDL_waylandwindow.c#L1901-L1905
* Далее SDL делает что-то странное. Он говорит, что всю отрисовку теперь мы будем делать в неких point, point у нас 100x100, каждый point физически отображается в 2 пикселя. https://discourse.libsdl.org/t/high-dpi-mode/34411
* ImGui берет размерности экрана в этих point, 100x100, делает gl viewport 100x100 над буфером 200x200, и рисует в свое удовольствие заблюренный контент.
То есть, как будто hidpi aware приложение само готовит контент низкого разрешения.
Я пробовал починить это разными способами, лучше всего сработал такой - https://git.sr.ht/~pg/ix/commit/fab9a5086801ea5e41d1e454f6c3a26abe9a06ed#pkgs/bin/reddit/desktop/hidpi/imgui_impl_sdl.cpp:
* В коде ImGui умножить размеры, передаваемые SDL, на scale.
* Получится так, что мы создадим viewport 200x200 над буфером 200x200, и отрисовка будет pixel perfect.
Почему я не могу расценивать это как финальное решение:
* Потому что, кроме gui, SDL возвращает масштабированными события от мыши, и получается, когда я их умножаю на scale, я теряю точность(мышка двигается по 2 пикселя по вертикали и гризонтали). Я не смог это заметить глазами на retina display, но как-то неаккуратно. https://forums.libsdl.org/viewtopic.php?p=43373
На мой взгляд, тут баг в SDL, что, когда приложение говорит, что оно hidpi aware, то надо ему возвращать настоящие пиксели, а не points.
Что мне делать с моим патчем в ImGui, я пока не понимаю.
BTW, должен сказать, что, после моего фикса, hidpi support в imgui кажется очень классным, потому что все размеры во float, и привязаны к размеру шрифта.
GitHub
SDL/src/video/wayland/SDL_waylandwindow.c at main · libsdl-org/SDL
Simple Directmedia Layer. Contribute to libsdl-org/SDL development by creating an account on GitHub.
🔥9👍2
https://www.phoronix.com/news/Wayland-Protocols-1.27
"The content type hint notification is used for enabling clients to provide hints to the Wayland compositor around the type of visual content provided by the app. In turn the content type hint notifications can be used for the compositor to adapt its behavior. This content-type-v1 protocol was originally written last year and initially supported "content types" are photo, video, or game content. If hinted to be game content, the compositor may optimize for reduced latency, if video it may be optimized for reduced stuttering and better scaling, or photo type for minimal extra processing by the compositor. With this content-type protocol still being in staging, it's possible other content types will still be added but ultimately is left up to the compositor if/what to optimize based upon the various content types"
У нас тут очередной #wayland moment, если вы понимаете, о чем я.
Давайте я быстренько расскажу, какую оптимизационную задачу вынужден решать wayland compositor, как ее решать правильно, и что предлагают эти наглухо упоротые люди.
(это упрощенная схема, как оно устроено "на самом деле" я представляю, но для объяснения сойдет)
Аппаратная начинка вашего монитора и видеокарты должна выдавать какой-то фиксированный RPS. Давайте для простоты вычислений скажем "20 RPS".
То есть, каждые 50ms композитор должен выдавать буфер, откуда аппаратная начинка нарисует нам следующий кадр. Если этот буфер будет меняться в момент отрисовки(например, кто-то продолжит в него писать уже после того, как отдали буфер на отрисовку, или кто-то будет генерить новый буфер быстрее, чем надо), то у нас случится тиринг, BTW.
Как это можно сделать?
(здесь и далее я намеренно не рассказываю, как это все взаимодействует с вводом, потому что это усложнит все в 10 раз)
Самый простой вариант - раз в 50ms делать gather от всех клиентов композитора, блендить их в результирующий буфер, сделать usleep(50 - X), где X - время выполнения gather + blend, и отдать готовый буффер.
С этим решением есть следующая проблема - картинка на мониторе будет отставать от логики приложения на сколько-то времени. Потому что после того, как сделан gather, логика приложения продолжает "тикать".
Это будет ощущаться как постоянный лаг(курсора мышки, нажатия на элементы интерфейса, a/v desync, лаги в играх).
Самый простой способ "пофиксить" это - это сделать usleep() на какую-то константу перед началом всей этой процедуры, так, чтобыи рыбку съесть и окна успели отрисовать себя, но и так, чтобы мы не вывалились за deadline на рисование этого кадра.
(кстати, теперь вы знаете, что делает опция max_render_time в sway, как ее тюнить, и почему она плохо работает)
Одно из правильных решений этой задачи - отдать ее на откуп приложению. Например, делать gather с самого начала кванта в 50ms, и передавать в приложение deadline(скажем, если blend занимает 10ms, то можно передать в качестве deadline now() + 40ms).
Тогда приложение, зная, сколько оно будет рисовать кадр, сможет предпринять нужные действия(например, межкадровую интерполяцию для видеоплеера, или usleep в игре).
Конец рассказа про compositor internals.
Но эти говнюки, конечно, решили сделать по другому - они будут передавать хинты для окна(игра, видео, и так далее), а композитор будет принимать какое-то решение.
И, к гадалке не ходи, GNOME media player будет знать, как работает GNOME compositor(какая там логика), и в GNOME shell оно будет работать прилично, и лагать под другими композиторами.
"The content type hint notification is used for enabling clients to provide hints to the Wayland compositor around the type of visual content provided by the app. In turn the content type hint notifications can be used for the compositor to adapt its behavior. This content-type-v1 protocol was originally written last year and initially supported "content types" are photo, video, or game content. If hinted to be game content, the compositor may optimize for reduced latency, if video it may be optimized for reduced stuttering and better scaling, or photo type for minimal extra processing by the compositor. With this content-type protocol still being in staging, it's possible other content types will still be added but ultimately is left up to the compositor if/what to optimize based upon the various content types"
У нас тут очередной #wayland moment, если вы понимаете, о чем я.
Давайте я быстренько расскажу, какую оптимизационную задачу вынужден решать wayland compositor, как ее решать правильно, и что предлагают эти наглухо упоротые люди.
(это упрощенная схема, как оно устроено "на самом деле" я представляю, но для объяснения сойдет)
Аппаратная начинка вашего монитора и видеокарты должна выдавать какой-то фиксированный RPS. Давайте для простоты вычислений скажем "20 RPS".
То есть, каждые 50ms композитор должен выдавать буфер, откуда аппаратная начинка нарисует нам следующий кадр. Если этот буфер будет меняться в момент отрисовки(например, кто-то продолжит в него писать уже после того, как отдали буфер на отрисовку, или кто-то будет генерить новый буфер быстрее, чем надо), то у нас случится тиринг, BTW.
Как это можно сделать?
(здесь и далее я намеренно не рассказываю, как это все взаимодействует с вводом, потому что это усложнит все в 10 раз)
Самый простой вариант - раз в 50ms делать gather от всех клиентов композитора, блендить их в результирующий буфер, сделать usleep(50 - X), где X - время выполнения gather + blend, и отдать готовый буффер.
С этим решением есть следующая проблема - картинка на мониторе будет отставать от логики приложения на сколько-то времени. Потому что после того, как сделан gather, логика приложения продолжает "тикать".
Это будет ощущаться как постоянный лаг(курсора мышки, нажатия на элементы интерфейса, a/v desync, лаги в играх).
Самый простой способ "пофиксить" это - это сделать usleep() на какую-то константу перед началом всей этой процедуры, так, чтобы
(кстати, теперь вы знаете, что делает опция max_render_time в sway, как ее тюнить, и почему она плохо работает)
Одно из правильных решений этой задачи - отдать ее на откуп приложению. Например, делать gather с самого начала кванта в 50ms, и передавать в приложение deadline(скажем, если blend занимает 10ms, то можно передать в качестве deadline now() + 40ms).
Тогда приложение, зная, сколько оно будет рисовать кадр, сможет предпринять нужные действия(например, межкадровую интерполяцию для видеоплеера, или usleep в игре).
Конец рассказа про compositor internals.
Но эти говнюки, конечно, решили сделать по другому - они будут передавать хинты для окна(игра, видео, и так далее), а композитор будет принимать какое-то решение.
И, к гадалке не ходи, GNOME media player будет знать, как работает GNOME compositor(какая там логика), и в GNOME shell оно будет работать прилично, и лагать под другими композиторами.
Phoronix
Wayland Protocols 1.27 Brings Content Type Hinting, Idle Notification
Wayland-Protocols 1.27 was released this morning by Jonas Ådahl in pushing out two new protocols under the staging umbrella.
👍3🤔3🔥2😱1🍌1
В батле "статическая vs. динамическая линковка" есть один фактор, про который особо никто не рассказывает, ну или мне просто не встречалось раньше.
Это эстетика!
Причем не простая эстетика, что, дескать, в случае статической линковки по всей fs не валяются всякие разные .so, про которые, без пакетного менеджера, не сказать, откуда они и для чего нужны. Это лежит на поверхности, и не очень интересно.
Я как-то, когда рассказывал про #mesa, вскользь упоминал про то, как она собирается.
Речь шла про то, что, в процессе сборки 3 .so-шек собирается 10 .a-шек, и они каким-то, достаточно произвольным, образом, объединяются в соответствующие .so файлы, с использованием linker script для сокрытия общих частей.
Зачем так делается? Почему бы не сделать 10 .so-шек, которые просто линкуются друг с другом, как им и положено, и нет этой магии с дублированием кода и всего прочего?
Этого требует эстетика динамической сборки!
Потому что негоже вываливать на пользователя кучу непонятных .so, без какого-то понятного scope, которые делают невесть что. Надо отдать пользователю понятный набор артефактов, с понятным scope, а то, что между ними код дублируется - кого это волнует?
Кстати, ровно в эту же тему можно отнести мой недавний рассказ про дублирование символов в библиотеках #gtk и #wayland. Это же с ума сойти - выделить эти 3 несчастные функции в какую-то совершенно artificial библиотеку, как ее продать пользователю, как опакетить в дистрибутивах, и прочие неприятные вопросы.
И, наоборот, статическая линковка стимулирует к появлению бОльшего количества более гранулярных зависимостей, потому что это артефакты исключительно времени сборки, и их не видит пользователь. Поэтому они могут быть произвольно всратыми, хоть по 1 функции в каждой, если так удобно, все равно вживую это никто не увидит.
(пример такого разделения библиотек на части - в следующей серии, и так уже много текста)
Поэтому внутренняя эстетика, присущая тому или иному способу линковки, на самом деле, диктует то, как код будет разбит на модули, и (мое личное мнение) статическая сборка приводит к более лучшему, отражающему суть кода, разделению.
Это эстетика!
Причем не простая эстетика, что, дескать, в случае статической линковки по всей fs не валяются всякие разные .so, про которые, без пакетного менеджера, не сказать, откуда они и для чего нужны. Это лежит на поверхности, и не очень интересно.
Я как-то, когда рассказывал про #mesa, вскользь упоминал про то, как она собирается.
Речь шла про то, что, в процессе сборки 3 .so-шек собирается 10 .a-шек, и они каким-то, достаточно произвольным, образом, объединяются в соответствующие .so файлы, с использованием linker script для сокрытия общих частей.
Зачем так делается? Почему бы не сделать 10 .so-шек, которые просто линкуются друг с другом, как им и положено, и нет этой магии с дублированием кода и всего прочего?
Этого требует эстетика динамической сборки!
Потому что негоже вываливать на пользователя кучу непонятных .so, без какого-то понятного scope, которые делают невесть что. Надо отдать пользователю понятный набор артефактов, с понятным scope, а то, что между ними код дублируется - кого это волнует?
Кстати, ровно в эту же тему можно отнести мой недавний рассказ про дублирование символов в библиотеках #gtk и #wayland. Это же с ума сойти - выделить эти 3 несчастные функции в какую-то совершенно artificial библиотеку, как ее продать пользователю, как опакетить в дистрибутивах, и прочие неприятные вопросы.
И, наоборот, статическая линковка стимулирует к появлению бОльшего количества более гранулярных зависимостей, потому что это артефакты исключительно времени сборки, и их не видит пользователь. Поэтому они могут быть произвольно всратыми, хоть по 1 функции в каждой, если так удобно, все равно вживую это никто не увидит.
(пример такого разделения библиотек на части - в следующей серии, и так уже много текста)
Поэтому внутренняя эстетика, присущая тому или иному способу линковки, на самом деле, диктует то, как код будет разбит на модули, и (мое личное мнение) статическая сборка приводит к более лучшему, отражающему суть кода, разделению.
👍13🤔7🔥5😁1🆒1
Вышел релиз wayland-protocols, за номером 1.29. 1.28 была, буквально, на днях, я писал про новые ошибки линковки, с ней связанные. #wayland
Меня удивило, быстро очень, они же там протоколы по 2 года мусолят.
https://lists.freedesktop.org/archives/wayland-devel/2022-November/042499.html
"This release contains a bug fix to the 'content-type' protocol extension, where an incorrect enum name was previously used. See [1] for more information how it eventually can be avoided in the future"
Мусолят-то мусолят, но нихрена не тестируют.
Шапито.
Меня удивило, быстро очень, они же там протоколы по 2 года мусолят.
https://lists.freedesktop.org/archives/wayland-devel/2022-November/042499.html
"This release contains a bug fix to the 'content-type' protocol extension, where an incorrect enum name was previously used. See [1] for more information how it eventually can be avoided in the future"
Мусолят-то мусолят, но нихрена не тестируют.
Шапито.
👍4🔥2🤡2
Продолжая тему #wayland, на днях вышли новые wlroots - https://www.phoronix.com/news/wlroots-0.16-Released
Ничего особенно интересного, но у меня наконец-то починились всплывающие окошки в gtk4. gtk4 перешли на аппаратно-ускоренный рендеринг, и что-то там так себе работало, когда композитор(sway) работал через opengl, а gui рендерило в буфер через #zink(ну, то есть, в буфера попадали команды от vulkan, грубо говоря).
Теперь в #sway хорошо заработал рендер на основе vulkan, и артефакты исчезли.
Ничего особенно интересного, но у меня наконец-то починились всплывающие окошки в gtk4. gtk4 перешли на аппаратно-ускоренный рендеринг, и что-то там так себе работало, когда композитор(sway) работал через opengl, а gui рендерило в буфер через #zink(ну, то есть, в буфера попадали команды от vulkan, грубо говоря).
Теперь в #sway хорошо заработал рендер на основе vulkan, и артефакты исчезли.
Phoronix
wlroots 0.16 Released With More Stable Vulkan Renderer, High Resolution Scrolling
The wlroots Wayland compositor support library that started out as a companion project to Sway is out with a shiny new feature release.
👍3👏2🔥1
И, закрывая тему #wayland на сегодня, скажу, что меня дико бесит способ распространения их протоколов.
Они, видимо, часть общеупотребительных протоколов сразу предоставляют в виде C библиотеки, а всякую шнягу только в виде xml файлов.
И, получается, каждый проект, который их хочет, компилирует эти xml файлы в код, а потом, если такое в рамках одной программы случилось несколько раз, то мы имеем ошибки линковки:
d.lld: error: duplicate symbol: zwp_linux_dmabuf_v1_interface
>>> defined at wayland-linux-dmabuf-unstable-v1-protocol.c
>>> wayland-linux-dmabuf-unstable-v1-protocol.c.o:(zwp_linux_dmabuf_v1_interface) in archive /ix/store/vG3f4y9IuqH0uqOa-lib-qt-6-wayland/./plugins/wayland-graphics-integration-server/libqt-wayland-compositor-linux-dmabuf-unstable-v1.a
>>> defined at linux-dmabuf-unstable-v1-protocol.c:76 (/ix/build/dKHxjGBeXc36a9Nv/obj/src/egl/wayland/wayland-drm/linux-dmabuf-unstable-v1-protocol.c:76)
>>> meson-generated_.._wayland_wayland-drm_linux-dmabuf-unstable-v1-protocol.c.o:(.rodata.zwp_linux_dmabuf_v1_interface+0x0) in archive /ix/store/dKHxjGBeXc36a9Nv-lib-mesa/lib/libEGL.a
ld.lld: error: duplicate symbol: zwp_linux_buffer_params_v1_interface
>>> defined at wayland-linux-dmabuf-unstable-v1-protocol.c
>>> wayland-linux-dmabuf-unstable-v1-protocol.c.o:(zwp_linux_buffer_params_v1_interface) in archive /ix/store/vG3f4y9IuqH0uqOa-lib-qt-6-wayland/./plugins/wayland-graphics-integration-server/libqt-wayland-compositor-linux-dmabuf-unstable-v1.a
>>> defined at linux-dmabuf-unstable-v1-protocol.c:94 (/ix/build/dKHxjGBeXc36a9Nv/obj/src/egl/wayland/wayland-drm/linux-dmabuf-unstable-v1-protocol.c:94)
>>> meson-generated_.._wayland_wayland-drm_linux-dmabuf-unstable-v1-protocol.c.o:(.rodata.zwp_linux_buffer_params_v1_interface+0x0) in archive /ix/store/dKHxjGBeXc36a9Nv-lib-mesa/lib/libEGL.a
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
Я, честно говоря, подзадолбался ходить по библиотекам, и переименовывать там эти символы - https://github.com/pg83/ix/blob/main/pkgs/lib/wpe/fdo/ix.sh#L18. В .so их, понятное дело, просто скрывают.
Они, видимо, часть общеупотребительных протоколов сразу предоставляют в виде C библиотеки, а всякую шнягу только в виде xml файлов.
И, получается, каждый проект, который их хочет, компилирует эти xml файлы в код, а потом, если такое в рамках одной программы случилось несколько раз, то мы имеем ошибки линковки:
d.lld: error: duplicate symbol: zwp_linux_dmabuf_v1_interface
>>> defined at wayland-linux-dmabuf-unstable-v1-protocol.c
>>> wayland-linux-dmabuf-unstable-v1-protocol.c.o:(zwp_linux_dmabuf_v1_interface) in archive /ix/store/vG3f4y9IuqH0uqOa-lib-qt-6-wayland/./plugins/wayland-graphics-integration-server/libqt-wayland-compositor-linux-dmabuf-unstable-v1.a
>>> defined at linux-dmabuf-unstable-v1-protocol.c:76 (/ix/build/dKHxjGBeXc36a9Nv/obj/src/egl/wayland/wayland-drm/linux-dmabuf-unstable-v1-protocol.c:76)
>>> meson-generated_.._wayland_wayland-drm_linux-dmabuf-unstable-v1-protocol.c.o:(.rodata.zwp_linux_dmabuf_v1_interface+0x0) in archive /ix/store/dKHxjGBeXc36a9Nv-lib-mesa/lib/libEGL.a
ld.lld: error: duplicate symbol: zwp_linux_buffer_params_v1_interface
>>> defined at wayland-linux-dmabuf-unstable-v1-protocol.c
>>> wayland-linux-dmabuf-unstable-v1-protocol.c.o:(zwp_linux_buffer_params_v1_interface) in archive /ix/store/vG3f4y9IuqH0uqOa-lib-qt-6-wayland/./plugins/wayland-graphics-integration-server/libqt-wayland-compositor-linux-dmabuf-unstable-v1.a
>>> defined at linux-dmabuf-unstable-v1-protocol.c:94 (/ix/build/dKHxjGBeXc36a9Nv/obj/src/egl/wayland/wayland-drm/linux-dmabuf-unstable-v1-protocol.c:94)
>>> meson-generated_.._wayland_wayland-drm_linux-dmabuf-unstable-v1-protocol.c.o:(.rodata.zwp_linux_buffer_params_v1_interface+0x0) in archive /ix/store/dKHxjGBeXc36a9Nv-lib-mesa/lib/libEGL.a
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
Я, честно говоря, подзадолбался ходить по библиотекам, и переименовывать там эти символы - https://github.com/pg83/ix/blob/main/pkgs/lib/wpe/fdo/ix.sh#L18. В .so их, понятное дело, просто скрывают.
🍌4😢2🐳2
commit -m "better"
#foot https://codeberg.org/dnkl/foot/releases Changed Default color theme is now starlight (#1321). Новый релиз, новая цветовая схема. По крайней мере, его безумие вполне последовательно.
Пока читал changelog, натолкнулся на https://wayland.app/protocols/cursor-shape-v1 (foot его как раз поддержал).
TL;DR - в #wayland теперь можно сказать композитору, какой курсор сейчас отображать по порядковому номеру (значения которых заранее определены и известны), а не загружая кастомную текстуру каждый раз, когда мышка переезжает из окна с #gtk в окно с #QT. Курсоры (при поддержке этого протокола) теперь могут храниться в композиторе, и не загружаться каждым клиентом отдельно.
Короче, чуваки в первый раз в жизни сделали какбоженька велел надо просто, а не как "мы не хотим знать, что вокруг нашего тулкита есть кто-то еще, и хотим все настраивать сами".
UPD: "Copyright 2018 The Chromium Authors Copyright 2023 Simon Ser" - ну, понятно, все #хорошее для Linux Desktop делает гагл, а не какой-то там RH.
Интересно, поддержит ли это #gtk?
TL;DR - в #wayland теперь можно сказать композитору, какой курсор сейчас отображать по порядковому номеру (значения которых заранее определены и известны), а не загружая кастомную текстуру каждый раз, когда мышка переезжает из окна с #gtk в окно с #QT. Курсоры (при поддержке этого протокола) теперь могут храниться в композиторе, и не загружаться каждым клиентом отдельно.
Короче, чуваки в первый раз в жизни сделали как
UPD: "Copyright 2018 The Chromium Authors Copyright 2023 Simon Ser" - ну, понятно, все #хорошее для Linux Desktop делает гагл, а не какой-то там RH.
Интересно, поддержит ли это #gtk?
wayland.app
Cursor shape protocol | Wayland Explorer
A better way to read Wayland documentation
🔥11😁2🆒1
https://gaultier.github.io/blog/wayland_from_scratch.html
А вот, кстати, хороший текст про то, как написать #wayland клиент с 0.
Без использования libwayland, без использования всратого xml codegen, а вот так вот - открыть сокет, записать такие-то байты, так-то распарсить результат. Фрейминг, содержание каждого пакета, устройство event loop - все объясняется "на пальцах".
Короче, если хочется разобраться "как оно работает внутри", а не в изысках, которые нахуевертили вокруг этой простой модели - must read.
Жалко, что там нет самой "мякотки" - инициализации drm context, для 3D ускорения, но это было бы сложновато для такой короткой статьи.
А вот, кстати, хороший текст про то, как написать #wayland клиент с 0.
Без использования libwayland, без использования всратого xml codegen, а вот так вот - открыть сокет, записать такие-то байты, так-то распарсить результат. Фрейминг, содержание каждого пакета, устройство event loop - все объясняется "на пальцах".
Короче, если хочется разобраться "как оно работает внутри", а не в изысках, которые нахуевертили вокруг этой простой модели - must read.
Жалко, что там нет самой "мякотки" - инициализации drm context, для 3D ускорения, но это было бы сложновато для такой короткой статьи.
👍26
https://www.phoronix.com/news/Louvre-Wayland-Library
https://github.com/CuarzoSoftware/Louvre
Wlroots - по сути, безальтернативная библиотека, если вы хотите запилить wayland композитор.
Потому что, знаете ли, кто первый встал, того и тапки - вот, представители kwin, mutter, и wlroots по сути, пишут предложения и расширения к wayland. А считать первые два хоть сколько нибудь отделимыми от своих DE может только сумасшедший.
И ничего хорошего в этом нет, потому что:
* Дрю ДеВолт #ddv, как оказалось, еще тот SJW-гондон.
* Мало конкуренции - плохо для продукта.
Собственно, поэтому нельзя не радоваться еще одной полностью независимой реализации библиотеки для разработки #wayland композитора!
Факт того, что она написана на каком-то разумном С++, без мономорфизации во все дырки, тоже не может не радовать.
Конечно, ее авторы ничего не понимают в сборке, потому что она принудительно лезет в вашу систему - https://github.com/CuarzoSoftware/Louvre/blob/main/src/meson.build#L31-L34
В общем, штука интересная, конкуренция - хорошо.
https://github.com/CuarzoSoftware/Louvre
Wlroots - по сути, безальтернативная библиотека, если вы хотите запилить wayland композитор.
Потому что, знаете ли, кто первый встал, того и тапки - вот, представители kwin, mutter, и wlroots по сути, пишут предложения и расширения к wayland. А считать первые два хоть сколько нибудь отделимыми от своих DE может только сумасшедший.
И ничего хорошего в этом нет, потому что:
* Дрю ДеВолт #ddv, как оказалось, еще тот SJW-гондон.
* Мало конкуренции - плохо для продукта.
Собственно, поэтому нельзя не радоваться еще одной полностью независимой реализации библиотеки для разработки #wayland композитора!
Факт того, что она написана на каком-то разумном С++, без мономорфизации во все дырки, тоже не может не радовать.
Конечно, ее авторы ничего не понимают в сборке, потому что она принудительно лезет в вашу систему - https://github.com/CuarzoSoftware/Louvre/blob/main/src/meson.build#L31-L34
В общем, штука интересная, конкуренция - хорошо.
Phoronix
Louvre Is A New C++ Library Helping To Build Wayland Compositors
While the KDE Plasma and GNOME Shell desktops are running on Wayland well, there are still many smaller desktops that haven't yet been ported over to Wayland or still in the early stages
👍15🔥3🆒2👎1
https://blog.tenstral.net/2024/01/wayland-really-breaks-things-just-for-now.html
Классный текст про #wayland.
Как обычно, много отсылок на километровые дискуссии, где текущие стейкхолдеры отказываются делать что-то, что не вписывается в их идеологию.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247
Хочу подробнее остановиться на
"Desktop environments of course have a design philosophy that they want to push, and want applications to integrate as much as possible (same as macOS and Windows!). However, there are many applications out there, and pushing a design via protocol limitations will likely just result in fewer apps"
Здесь аккуратно написано про следующий факт - люди, которые могут закоммитить новый протокол в wayland (например, позволяющий точно позиционировать окна), по странному стечению обстоятельств, являются стейкхолдерами (в том или ином виде) в kwin(KDE)/gnome shell/wlroots.
И вертели они на хую любые предложения и протоколы, которые не вписываются в их модели работы с десктопом в целом, и окнами приложений, в частности.
Вот, например, зачем человеку, который отвечает за все tiling композиторы принимать proposal, в котором можно разрешить приложению управлять своим положением на экране?
Он не сможет его реализовать в своей модели, а, значит, приложения, использующие эту фичу, в его композиторе будут работать хуже.
Гораздо проще (с точки зрения всей вот этой шайки) просто отказывать во всех предложениях, которые не вписываются в эти 3 модели, и, тем самым, выкручивать руки разработчикам приложений.
Собственно, это все описано вот тут - https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%81%D0%B5%D0%BD%D1%81%D1%83%D1%81#%D0%9A%D1%80%D0%B8%D1%82%D0%B8%D0%BA%D0%B0
Что с этим делать - непонятно, потому что у владельцев репы с wayland-protocols нет никаких стимулов что-то менять (https://cyclowiki.org/wiki/%D0%9F%D1%87%D1%91%D0%BB%D1%8B_%D0%BF%D1%80%D0%BE%D1%82%D0%B8%D0%B2_%D0%BC%D1%91%D0%B4%D0%B0 ), а всем остальным договориться о том, чтобы брать эти протоколы из другого места, кажется нереалистичным.
Классный текст про #wayland.
Как обычно, много отсылок на километровые дискуссии, где текущие стейкхолдеры отказываются делать что-то, что не вписывается в их идеологию.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247
Хочу подробнее остановиться на
"Desktop environments of course have a design philosophy that they want to push, and want applications to integrate as much as possible (same as macOS and Windows!). However, there are many applications out there, and pushing a design via protocol limitations will likely just result in fewer apps"
Здесь аккуратно написано про следующий факт - люди, которые могут закоммитить новый протокол в wayland (например, позволяющий точно позиционировать окна), по странному стечению обстоятельств, являются стейкхолдерами (в том или ином виде) в kwin(KDE)/gnome shell/wlroots.
И вертели они на хую любые предложения и протоколы, которые не вписываются в их модели работы с десктопом в целом, и окнами приложений, в частности.
Вот, например, зачем человеку, который отвечает за все tiling композиторы принимать proposal, в котором можно разрешить приложению управлять своим положением на экране?
Он не сможет его реализовать в своей модели, а, значит, приложения, использующие эту фичу, в его композиторе будут работать хуже.
Гораздо проще (с точки зрения всей вот этой шайки) просто отказывать во всех предложениях, которые не вписываются в эти 3 модели, и, тем самым, выкручивать руки разработчикам приложений.
Собственно, это все описано вот тут - https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%81%D0%B5%D0%BD%D1%81%D1%83%D1%81#%D0%9A%D1%80%D0%B8%D1%82%D0%B8%D0%BA%D0%B0
Что с этим делать - непонятно, потому что у владельцев репы с wayland-protocols нет никаких стимулов что-то менять (https://cyclowiki.org/wiki/%D0%9F%D1%87%D1%91%D0%BB%D1%8B_%D0%BF%D1%80%D0%BE%D1%82%D0%B8%D0%B2_%D0%BC%D1%91%D0%B4%D0%B0 ), а всем остальным договориться о том, чтобы брать эти протоколы из другого места, кажется нереалистичным.
GitLab
staging: Add xdg-toplevel-icon to allow windows to set dedicated icons (!269) · Merge requests · wayland / wayland-protocols ·…
Hi everyone! Here is yet another controversial protocol, but I think it is a lot easier to discuss pros and cons if there is a concrete...
👍10🤔7❤4🔥2😭1
https://www.opennet.ru/opennews/art.shtml?num=60686
Вышли 6-ые кеды.
У меня их нет, и пока не будет (#kparts), а вот то, что они объявили #wayland сеанс основным, очень и очень много значит.
Это значит, что внедрение wayland сейчас станет лавинообразным, и, через год-два, будет не 15% wayland, а 15% X11. #future
Надеюсь, не откатят это, как когда-то сделали SDL.
Вышли 6-ые кеды.
У меня их нет, и пока не будет (#kparts), а вот то, что они объявили #wayland сеанс основным, очень и очень много значит.
Это значит, что внедрение wayland сейчас станет лавинообразным, и, через год-два, будет не 15% wayland, а 15% X11. #future
Надеюсь, не откатят это, как когда-то сделали SDL.
www.opennet.ru
Релиз KDE 6.0
После года разработки опубликован релиз среды рабочего стола KDE Plasma 6, библиотек KDE Frameworks 6 и коллекции приложений KDE Gear 24.02. Для оценки работы KDE 6 можно воспользоваться сборками от проекта KDE Neon.
👍21👌3🐳3
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212
#GNOME #gtk moment
К чувакам пришли с реализацией уже принятого в wayland протокола, на что им, в своей уникальной манере, ответили, что для GTK/GNOME от реализации этого протокола пользы не будет. Речь идет о server side cursor. Попытка решить очень древнюю проблему с неконсистентностью курсовров в разных приложениях (напомню, что поверхность с курсором отдает клиент, и это может быть вообще все, что угодно).
Они, на полном серьезе, сравнивают курсор (который, на минуточку, может быть отрисован не только клиентом, а еще композитором, когда курсор находится вне любого клиента, или клиентом другого DE), и рендеринг шрифтов - https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212#note_2056112
Цикл моих заметок про курсоры в Wayland:
https://t.iss.one/itpgchannel/185
https://t.iss.one/itpgchannel/1214
https://t.iss.one/itpgchannel/246
https://t.iss.one/itpgchannel/854
https://t.iss.one/itpgchannel/1758
Нет слов.
https://www.opennet.ru/opennews/art.shtml?num=60847
А вот "правильный" заход в #Wayland - #SDL говорят, что не будут включать Wayland по дефолту, пока им не запилят два нужных расширения. И тут уж коллегам из Wayland придется прогнуться, потому что один из основных потребителей SDL - Valve, которая сейчас пилит половину десктопного кода под Linux (стек драйверов, компиляторов шейдеров, да и свои компизиторы у них есть https://github.com/ValveSoftware/gamescope). Все #хорошее в графическом стеке Linux делают корпорации!
Будьте уверены, в данном вопросе все пойдет, как по маслу. Потому что одно дело, когда что-то нужно сообществу, тогда можно поломать комедию и повыебываться, а другое дело - когда оно нужно уважаемым людям, которые непосредственно вас кормят.
Вообще, бесит меня этим современный open source, что люди, которые нихуя не делают, а простосидят на трубе обладают паролем от нужного репозитория, палец о палец не пошевелят, пока у задачи не найдется спонсор с деньгами. Если бы эти негодяи просто сами не писали код - это еще полбеды, но они тупо не пропускают нужные изменения в код.
#GNOME #gtk moment
К чувакам пришли с реализацией уже принятого в wayland протокола, на что им, в своей уникальной манере, ответили, что для GTK/GNOME от реализации этого протокола пользы не будет. Речь идет о server side cursor. Попытка решить очень древнюю проблему с неконсистентностью курсовров в разных приложениях (напомню, что поверхность с курсором отдает клиент, и это может быть вообще все, что угодно).
Они, на полном серьезе, сравнивают курсор (который, на минуточку, может быть отрисован не только клиентом, а еще композитором, когда курсор находится вне любого клиента, или клиентом другого DE), и рендеринг шрифтов - https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212#note_2056112
Цикл моих заметок про курсоры в Wayland:
https://t.iss.one/itpgchannel/185
https://t.iss.one/itpgchannel/1214
https://t.iss.one/itpgchannel/246
https://t.iss.one/itpgchannel/854
https://t.iss.one/itpgchannel/1758
Нет слов.
https://www.opennet.ru/opennews/art.shtml?num=60847
А вот "правильный" заход в #Wayland - #SDL говорят, что не будут включать Wayland по дефолту, пока им не запилят два нужных расширения. И тут уж коллегам из Wayland придется прогнуться, потому что один из основных потребителей SDL - Valve, которая сейчас пилит половину десктопного кода под Linux (стек драйверов, компиляторов шейдеров, да и свои компизиторы у них есть https://github.com/ValveSoftware/gamescope). Все #хорошее в графическом стеке Linux делают корпорации!
Будьте уверены, в данном вопросе все пойдет, как по маслу. Потому что одно дело, когда что-то нужно сообществу, тогда можно поломать комедию и повыебываться, а другое дело - когда оно нужно уважаемым людям, которые непосредственно вас кормят.
Вообще, бесит меня этим современный open source, что люди, которые нихуя не делают, а просто
GitLab
wayland: implement cursor_shape_v1 (!6212) · Merge requests · GNOME / gtk · GitLab
This implements https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/194 Let me know if there's a more specific place that _gdk_wayland_cursor_get_enum would fit. Also, would a...
👍12🤯6😭3😢2💯1
Почему GNOME - говно
Гном пошел нагибать Wayland по поводу иконок. Но вот незадача, впервые за время существования wayland-protocols с ним не согласны и уже почти стандартизировали. Значит, время огрызаться на всех с rude and unhelpful. И вообще, это unacceptable, как это, гном…
Продолжение https://t.iss.one/itpgchannel/1586
Гномовцы предложили более слабый протокол, которым не сможет воспользоваться wine:
"One disadvantage of this restriction is that wine will apparently not be able to use it. A lot of Windows window management is not possible with wayland right now. The rootful mode continues to work, and wayland might eventually grow a wine protocol to specifically deal with those cases"
А все для того, чтобы не допущать шага влево от линии партии - "it makes it impossible for apps to relay some status via the icon"
Гномовцы предложили более слабый протокол, которым не сможет воспользоваться wine:
"One disadvantage of this restriction is that wine will apparently not be able to use it. A lot of Windows window management is not possible with wayland right now. The rootful mode continues to work, and wayland might eventually grow a wine protocol to specifically deal with those cases"
А все для того, чтобы не допущать шага влево от линии партии - "it makes it impossible for apps to relay some status via the icon"
Telegram
commit -m "better"
https://blog.tenstral.net/2024/01/wayland-really-breaks-things-just-for-now.html
Классный текст про #wayland.
Как обычно, много отсылок на километровые дискуссии, где текущие стейкхолдеры отказываются делать что-то, что не вписывается в их идеологию.
…
Классный текст про #wayland.
Как обычно, много отсылок на километровые дискуссии, где текущие стейкхолдеры отказываются делать что-то, что не вписывается в их идеологию.
…
🤡12🔥4🆒2
commit -m "better"
Вышел новый #hyprland, и там снова big news: https://github.com/hyprwm/Hyprland/releases/tag/v0.42.0 "News for packagers New dependency: aquamarine Dropped submodule: wlroots" Я сначала подумал, что это они так свой форк переименовали, но нет: https:/…
Небольшое дополнение к этому тексту. #wayland
Оказывается, Simon Ser писал wlroots не по доброте душевной, а за деньги, и теперь собирается "приглушить" свой вклад, потому что больше не работает на проклятого SJW #ddv:
"even Simon Ser recently said he'll have to tone down his contributions due to the termination of his contract with SourceHut - I wish you all the best wherever you end up, Simon"
Такими темпами wlroots превратится в очередной мертвый стандарт от freedesktop, и туда ему и дорога:
"Further reasons could include slow development pace - new wayland features that require changes in wlroots tend to take ages to get merged into wlroots, like for example tearing, where a basically ready MR took 9 months to merge because of 100 "style nits" and 2 actually important remarks, or explicit sync still not being a thing, despite KDE and Gnome having implementations already"
Оказывается, Simon Ser писал wlroots не по доброте душевной, а за деньги, и теперь собирается "приглушить" свой вклад, потому что больше не работает на проклятого SJW #ddv:
"even Simon Ser recently said he'll have to tone down his contributions due to the termination of his contract with SourceHut - I wish you all the best wherever you end up, Simon"
Такими темпами wlroots превратится в очередной мертвый стандарт от freedesktop, и туда ему и дорога:
"Further reasons could include slow development pace - new wayland features that require changes in wlroots tend to take ages to get merged into wlroots, like for example tearing, where a basically ready MR took 9 months to merge because of 100 "style nits" and 2 actually important remarks, or explicit sync still not being a thing, despite KDE and Gnome having implementations already"
👍5😁4🤔4🙏1
commit -m "better"
Не думаю, что они делают это для благотворительности, и у них есть понятный коммерческий интерес, но, в целом, их вклад сложно переоценить.
#gold
https://www.phoronix.com/news/Mesa-frog-fifo-v1-MR
https://www.opennet.ru/opennews/art.shtml?num=61925
https://www.gamingonlinux.com/2024/09/frog-protocols-announced-to-try-and-speed-up-wayland-protocol-development/
Божечки, what a day to be alive.
#valve, по сути, форкнули wayland protocols, и собираются развивать их без заморочек, связанный с моделью разработки wayland. Все #хорошее в графическом стеке Linux делают корпорации!
Но это не самое важное.
Самое важное - что они уже есть в репах Fedora, Arch, и так далее. Есть патч в mesa!
То есть, это не будет местечковая вещь для gamescope, это будет во всех репках, и поддержано в upstream большого числа проектов.
Конечно, это не нравится гондонам, которые годами мусолят элементарные вещи - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31329/#note_2580654
Совершенно феерический тред, там по разрабам #wayland проехались вообще ВСЕ (для примера - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31329/#note_2583219), кого они мурыжили годами (я много про это писал).
Справедливость торжествует!!!
https://t.iss.one/itpgchannel/1947
https://t.iss.one/itpgchannel/1941
https://t.iss.one/itpgchannel/1191
https://t.iss.one/itpgchannel/738
https://t.iss.one/itpgchannel/736
https://t.iss.one/itpgchannel/649
Цикл моих заметок про курсоры в Wayland:
https://t.iss.one/itpgchannel/185
https://t.iss.one/itpgchannel/1214
https://t.iss.one/itpgchannel/246
https://t.iss.one/itpgchannel/854
https://t.iss.one/itpgchannel/1758
https://www.phoronix.com/news/Mesa-frog-fifo-v1-MR
https://www.opennet.ru/opennews/art.shtml?num=61925
https://www.gamingonlinux.com/2024/09/frog-protocols-announced-to-try-and-speed-up-wayland-protocol-development/
Божечки, what a day to be alive.
#valve, по сути, форкнули wayland protocols, и собираются развивать их без заморочек, связанный с моделью разработки wayland. Все #хорошее в графическом стеке Linux делают корпорации!
Но это не самое важное.
Самое важное - что они уже есть в репах Fedora, Arch, и так далее. Есть патч в mesa!
То есть, это не будет местечковая вещь для gamescope, это будет во всех репках, и поддержано в upstream большого числа проектов.
Конечно, это не нравится гондонам, которые годами мусолят элементарные вещи - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31329/#note_2580654
Совершенно феерический тред, там по разрабам #wayland проехались вообще ВСЕ (для примера - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31329/#note_2583219), кого они мурыжили годами (я много про это писал).
Справедливость торжествует!!!
https://t.iss.one/itpgchannel/1947
https://t.iss.one/itpgchannel/1941
https://t.iss.one/itpgchannel/1191
https://t.iss.one/itpgchannel/738
https://t.iss.one/itpgchannel/736
https://t.iss.one/itpgchannel/649
Цикл моих заметок про курсоры в Wayland:
https://t.iss.one/itpgchannel/185
https://t.iss.one/itpgchannel/1214
https://t.iss.one/itpgchannel/246
https://t.iss.one/itpgchannel/854
https://t.iss.one/itpgchannel/1758
www.opennet.ru
Компания Valve запустила проект Frog для ускорения продвижения новых протоколов Wayland
Разработчики из компании Valve представили проект frog-protocols, в рамках которого планируется развивать дополнительный набор протоколов для Wayland, дополняющих протоколы из набора wayland-protocols, поставляющего Wayland-расширения для построения композитных…
😁22🔥15❤7👍4😍2🆒1
commit -m "better"
#gold https://www.phoronix.com/news/Mesa-frog-fifo-v1-MR https://www.opennet.ru/opennews/art.shtml?num=61925 https://www.gamingonlinux.com/2024/09/frog-protocols-announced-to-try-and-speed-up-wayland-protocol-development/ Божечки, what a day to be alive.…
Напомню историю.
#valve завела свою репку, куда начала класть свои протоколы для #wayland.
Вот коммит с поддержкой одного из этих протоколов в #mesa - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31329/#note_2580654 (называется он fifo).
И, ВНЕЗАПНО, выходит новый wayland - https://www.opennet.ru/opennews/art.shtml?num=62038, где:
"fifo - реализует FIFO-механизм (первым пришёл - первым ушёл) обработки очереди обновления содержимого отображаемой поверхности. С практической стороны протокол позволяет при выводе использовать ожидание завершения вертикальной развёртки (vblank) вместо использования callback-вызовов при каждой готовности отобразить новый кадр, что решает проблему с высокой нагрузкой на GPU при использовании VSync"
Что очень забавно, этот новый протокол попал в wayland, минуя все необходимые стадии рассмотрения - https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/fifo
Угу, 22 часа назад положили сразу в staging, минуя unstable, и выпустили свежий релиз.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256#note_2606688 - вот тот самый MR с обсуждением, где, как обычно, это все мурыжили год, но, ВНЕЗАПНО, неделю назад, пришли все, кто имеет там право голоса, и проголосовали "ЗА".
Совпадение?
Сомнительно это нам.
#valve завела свою репку, куда начала класть свои протоколы для #wayland.
Вот коммит с поддержкой одного из этих протоколов в #mesa - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31329/#note_2580654 (называется он fifo).
И, ВНЕЗАПНО, выходит новый wayland - https://www.opennet.ru/opennews/art.shtml?num=62038, где:
"fifo - реализует FIFO-механизм (первым пришёл - первым ушёл) обработки очереди обновления содержимого отображаемой поверхности. С практической стороны протокол позволяет при выводе использовать ожидание завершения вертикальной развёртки (vblank) вместо использования callback-вызовов при каждой готовности отобразить новый кадр, что решает проблему с высокой нагрузкой на GPU при использовании VSync"
Что очень забавно, этот новый протокол попал в wayland, минуя все необходимые стадии рассмотрения - https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/fifo
Угу, 22 часа назад положили сразу в staging, минуя unstable, и выпустили свежий релиз.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256#note_2606688 - вот тот самый MR с обсуждением, где, как обычно, это все мурыжили год, но, ВНЕЗАПНО, неделю назад, пришли все, кто имеет там право голоса, и проголосовали "ЗА".
Совпадение?
Сомнительно это нам.
GitLab
vulkan/wsi/wayland: Use frog-fifo-v1 protocol for FIFO (!31329) · Merge requests · Mesa / mesa · GitLab
This MR adds support for the 'frog-fifo-v1' protocol from frog-protocols, a new repo of Wayland protocols that we intend to be more...
🤣31🔥10👍6😁5❤2🤔1
https://dudemanguy.github.io/blog/posts/2025-02-03-wayland-xorg-2/wayland-xorg-2.html
Пишут, что #wayland - торт.
Так же там высказывается непопулярное мнение, что все #хорошее в explicit sync в Linux сделано благодаря Nvidia, что очень хорошо aligned с моей точкой зрения, что все хорошее в Linux делают корпорации (#valve) (несмотря на активно сопротивляющееся сообщество).
Пишут, что #wayland - торт.
Так же там высказывается непопулярное мнение, что все #хорошее в explicit sync в Linux сделано благодаря Nvidia, что очень хорошо aligned с моей точкой зрения, что все хорошее в Linux делают корпорации (#valve) (несмотря на активно сопротивляющееся сообщество).
🤔9👍5🔥4❤2🤡1🐳1
commit -m "better"
Пишут, что #wayland - торт.
https://www.opennet.ru/opennews/art.shtml?num=62725
"Пользователям KDE рекомендовано попробовать перейти на использование сеанса на базе протокола Wayland, так как разработчики KDE практически прекратили тестирование сеанса на базе X11"
Ну все, лед тронулся, через пару лет про X можно будет просто забыть, эффект будет лавинообразный.
"Пользователям KDE рекомендовано попробовать перейти на использование сеанса на базе протокола Wayland, так как разработчики KDE практически прекратили тестирование сеанса на базе X11"
Ну все, лед тронулся, через пару лет про X можно будет просто забыть, эффект будет лавинообразный.
www.opennet.ru
Сеанс KDE на базе X11 остался почти без тестирования. Начало разработки KDE 6.4
Нейт Грэм (Nate Graham), разработчик, занимающийся контролем качества в проекте KDE, опубликовал очередной отчёт о разработке KDE. После релиза KDE Plasma 6.3.0 выявлено несколько неприятных ошибок, которые планируют устранить в корректирующем обновлении…
👍16🤔10❤8🤡4🤮3😢2🆒1
commit -m "better"
X11, который вы (луддиты) заслужили!
https://www.opennet.ru/opennews/art.shtml?num=63419
Луддиты наступают!
"Разработчики свободной системы автоматизированного проектирования печатных плат KiCad рассказали о состоянии реализации поддержки Wayland и обобщили проблемы, мешающие полноценному использованию данного протокола. Пользователям, профессионально проектирующим печатные платы в KiCad или желающим получить стабильное и полнофункциональное окружение, рекомендовано запускать KiCad в средах рабочего стола на базе протокола X11, таких как Xfce, MATE или X11-сеанс KDE Plasma"
Шутки-шутками, но проблемы wayland обозначены вполне себе верно:
* Много различных реализаций, с разным набором поддерживаемых протоколов, и с уникальными багами, в такой среде сложно работать корректно.
* Отсутствие многих необходимых расширений, связанных с позиционированием окон, и перемещением курсора, ну да про это я часто писал (https://t.iss.one/itpgchannel/2309, и вообще, по тегу #wayland).
Проблема в том, что в X, несмотря на то, что, в моменте, что-то может работать лучше, настолько древняя и неподдерживаемая база (да, я читал), что туда (почти, https://t.iss.one/itpgchannel/3079) никто не хочет лезть.
Луддиты наступают!
"Разработчики свободной системы автоматизированного проектирования печатных плат KiCad рассказали о состоянии реализации поддержки Wayland и обобщили проблемы, мешающие полноценному использованию данного протокола. Пользователям, профессионально проектирующим печатные платы в KiCad или желающим получить стабильное и полнофункциональное окружение, рекомендовано запускать KiCad в средах рабочего стола на базе протокола X11, таких как Xfce, MATE или X11-сеанс KDE Plasma"
Шутки-шутками, но проблемы wayland обозначены вполне себе верно:
* Много различных реализаций, с разным набором поддерживаемых протоколов, и с уникальными багами, в такой среде сложно работать корректно.
* Отсутствие многих необходимых расширений, связанных с позиционированием окон, и перемещением курсора, ну да про это я часто писал (https://t.iss.one/itpgchannel/2309, и вообще, по тегу #wayland).
Проблема в том, что в X, несмотря на то, что, в моменте, что-то может работать лучше, настолько древняя и неподдерживаемая база (да, я читал), что туда (почти, https://t.iss.one/itpgchannel/3079) никто не хочет лезть.
www.opennet.ru
Разработчики САПР KiCad раскритиковали Wayland и рекомендовали использовать X11
Разработчики свободной системы автоматизированного проектирования печатных плат KiCad рассказали о состоянии реализации поддержки Wayland и обобщили проблемы, мешающие полноценному использованию данного протокола. Пользователям, профессионально проектирующим…
❤8