Comments 115
Про "прозрачность сети" небольшая глава. Поддерживает Wayland клиент-серверную архитектуру или нет?
Wayland это общее описание, как оно должно работать в итоге. Работа по сети через клиент-сервер зависит от конкретной реализации. Но именно это в "Х`сах" и мешает. В Wayland фишка в прямом доступе к памяти и избавление от бутылочного горлышка.
фишка в прямом доступе к памяти и избавление от бутылочного горлышка
Так разве MIT-SHM(MIT Shared Memory Extension, XShm) в X11 не тоже самое делает?
Работа по сети через клиент-сервер зависит от конкретной реализации.
Так есть ли сейчас общая реализация, прокидывающая десктоп на Wayland по сети? Насколько вижу - wayvnc поддерживает только конкретные композиторы (GNOME и KDE не работают), есть RDP поддержка в Weston и GNOME, то есть всё работает только в частных случаях.
Не знаю, что значит общая, есть Waypipe, аналог ssh -X. Позволяет запускать удалённые приложения waypipe ssh user@theserver weston-terminal
Оно удалённую сессию с полным рабочим столом создать может?
Вроде бы нет.
Может, но крайне сыро, или кривизна рук не смогли нормально завести. Мне удавалось запустить на удаленном компе sddm (менеджер логина) на федоре 39 через waypipe, и оно открывало окно входа, в котором при логине получалось зайти на рабочий стол, и даже запускались приложения (только wayland, x приложения не отображались), но лагало это просто неимоверно, к тому же через пару минут словил полное зависание системы, ребут только через hard-reset помог.
в X11 практически убили "прозрачность сети", я лет 10 назад активно пользовался этим, потом начались проблемы, потом перестал пользоваться.
Изначально X11 работали по сети, но потом появились видеокарты и разработчики начали добавлять расширения для прямого доступа к железу видеокарты, всякие CUDA, Vulkan, аппаратные декодеры видео требуют прямого доступа к железу, и иксы вроде как по сети работают, но рядом еще не по сети, и смысл в этой сети тогда? Не скажу какая сейчас ситуация с поддержкой, скорее всего, простые тулзы все еще работают нормально
wayland же решили не мучить жоп не создавать себе проблемы, чтобы потом пытаться героически их решать и в итоге получить "иксы, вид сбоку"
Работаю через проброс иксов каждый день, все отлично, и стало гораздо лучше, чем раньше. Прокидываемые приложения даже получают настройки темы оформления хоста. Лет 10 назад такого не было.
Даже сложные интерфейсы типа IDE от Jetbrains, прокидываются идеально. Работает все быстро, компромиссов нет.
Единственная проблема на сегодня лично у сеня - у хрома в новых версиях отвалились диалоговые окна при пробросе. У того же фаерфокса все отлично.
Спасибо за актуальный статус, значит не все так плохо сейчас с X11.
Хром вообще в аппаратное ускорение упор делает, у меня figma на AMD встройке очень странно работала, а на Nvidia в wayland были вылеты всего DE
Можете поточнее описать ваше сетап?
У меня от использования ssh -X ощущение, что адски тормозит. Высокий latency очень мешает. С x2go сильно лучше, но у него другой протокол
Виртуалбокс на мощной машине, рабочее место на ноуте, либо на той же машине, по обстоятельствам, смотря что удобнее.
И хост и гость - LinuxMint Cinnamon. Разных версий, но не сильно. На клиентах последняя, на виртуалке отстает на 1-2.
Коннект через ssh -X
Сеть - локальная беспроводная, 5ггц. Даже если хост и гость на одной машине, все равно подключение через 192.168.1.X.
Быстродействие и отклик - не отличить от "нативных".
На 2.4ггц в засранном эфире многоэтажки, помню, были тоже проблемы. На 5ггц все идеально работает.
Я подозреваю ещё сильно зависит от приложений. Я пробовал firefox через ssh -X с сильно удалённой машины (пинг 80 мс), и хоть 100 мбит/с по этому каналу пролезают, но отклика на действия иногда приходилось ждать по десятку секунд.
Ну PHPstorm не самый лёгкий софт. Фаерфокс и хром тоже летают. Опять же - я работаю в локальной сети.
Да, всякие incscape и gimp тоже работают отлично.
Когда пинг 80 и машина сильно удалённая, разумеется, уже будет дискомфорт. Но эта штука проектировалась для сетевой прозрачности до интернета. Речь шла о том, что есть мейнфрейм в здании, и есть легкие клиенты этого мейнфрейма в том же здании. То, что мейнфрейм и клиент будут в разных городах, или на разных континентах, не планировалось.
Прошу в комментарии, если вы нашли еще минус
Скорее все минусы объединяются в один: нельзя просто взять и начать работать. И это бьет по самой базе - офисной работе. Дробный масштаб (fractional scaling) часто вызывает мыло. Над чем долго смеялись в винде.
Верю в светлое будущее допиленного wayland.
Дробный масштаб если поддерживается соответствующий протокол не вызывает мыла. Мыло возникает только в Xwayland и там другая проблема, которая описана ниже в комментах. Но сейчас у меня осталось только одно приложение, которое не умеет нативно работать в Wayland и это Steam. Например в VS Code починили Wayland в последних релизах. Думаю, если у вас дистрибутив не эпохи царя гороха, то вы вряд ли найдете приложение, которое не умеет работать нативно в Wayland.
KiCad пока ещё нормально не работает в Wayland; как-то работает через XWayland, но при необходимости масштабирования там получается мыло.
Хм, он вроде давно же работает в Wayland, когда года 2 назад в wxwidgets добавили подержку wayland. Как помню мыло было только в иконках, так же как в либреофис, а в интерфейсе там надо было настройки менять и все нормально отображалось.
Ну вот в том багрепорте как раз расписано, что и где не работает. Там ещё проблема в том, что зоопарк WM для X11 сейчас превратился в зоопарк композиторов для Wayland, и этот зоопарк, похоже, ещё похуже старого — если с WM основная проблема была в некорректном позиционировании окон в некоторых комбинациях софта (что, кстати, именно сейчас наблюдается в комбинации Kicad 7/8 + i3 — KiCad пытается запоминать позицию некоторых окон и восстанавливать её при повторном открытии, но ошибается на размер рамки и заголовка окна в i3), то в случае Wayland разработчики наплодили 500 штук разных протоколов, из которых каждый композитор поддерживает какой-то свой набор со своими специфическими багами, и что и как надо реализовывать в приложениях — чёрт ногу сломит.
Плюс мешают принципиальные ограничения Wayland — например, тот же KiCad для поддержки позиционирования объектов с клавиатуры и скроллинга при перемещении за пределы видимой области хочет управлять позицией курсора мыши, с чем в X11 никаких проблем нет, а в Wayland это либо не работает вообще, либо надо придумывать очередной протокол, который опять же будет когда-нибудь реализован в половине композиторов, причём в половине из них как-то криво.
Дробный масштаб (fractional scaling) часто вызывает мыло
Это потому, что масштабировать свое отображение должны приложения а не композитор. И ни вейланд, ни иксы, ни винда ни макось это обеспечить не могут. Они полагаются в этом на приложения, которые будут отрисовывать себя правильным образом - со шрифтами и иконками увеличенного размера.
ПыСы - не надо говорить "а вот в макоси это не так там все работает" - там в стандартный тулкит это встроено. А попытка притащить скалирование в графический сервер вместо тулкита всегда заканчивается вырвиглазием и мылом. Физику и математику, знаете ли, не обманешь.
wayland - монопольное использование десктопа одним пользователем
X11 - совместное использование сервера многими пользователями
Если вы один пользователь, то лучше wayland, он быстрее. Если вы не один, то у вас нет вариантов.
Вообще, в современном мире линукса, X нужен только на Unix / Linux рабочих машинах, ибо не на андройде, не на хромбуках иксы никому не нужны.
Тут случай когда ошибка полностью ломает смысл предложения. Вероятно вы хотели написать "Иксы нужны на рабочих машинах, и не нужны на андроиде и хромбуках" но написали вместо этого "Нужны на рабочих машинах, но не нужны нигде кроме андроида и хромбуков".
Чтобы исправить надо написать "ни на андройде, ни на хромбуках"
Если это не компиляция чужих статей, включая GPT, то мой почтение.
Искал информацию, переводил, перечитывал, проверял на оригинал, ошибки. Пожалуй самая качественная моя статья. GPT, каюсь, использовал когда составлял содержание, план статьи. Но в самом тексте - ни капли.
На мой взгляд, слишком длинная статья и слишком много второстепенных деталей. Можно было сократить раз в 5.
Сложности работы двух мониторов с разным dpi или частотой обновления
Это практически невозможно заставить нормально работать в X11.
То есть с этим вы сами не сталкивались а только форум читали?
Просто стоит у меня несколько мониторов, разных годов и размеров, у половины разная частота обновления. И на мой взгляд все нормально работает. Уже лет 10 наверное. Кучу апгрейдов OS пережило.
Про DPI да, есть такой нюанс, но если у вас не комбинация когда один из мониторов высокого разрешения, то также особенных проблем не доставляет, ну помельче на одном какие-то элементы изображения ну и что?
Дробное масштабирование
Изначально wayland его тоже не умеет - в стандартном протоколе коэффициенты целочисленные. Ну ладно в 1984 про это не думали, но в 2008 то можно было хотя бы на винду посмотреть. А например KDE его колхозит через свои расширения протокола. Соответственно унификация опять идет лесом, и разработчики тулкитов снова страдают
KDE не колхозят свой протокол для Fractional Scaling, это бы сломало совместимость и никто бы его кроме них не реализовал. Они решали проблему синхронизации размеров и координат виртуальных поверхностей Xwayland с композитором и реализовали это через хак - спавнят все диаголовые окна в центре экрана. Проблема заключается в том, что там сложные расчеты, надо считать unscale и scale размеры, что делали патчем xwayland. Патчи эти не принял никто. Но можно обойтись без патча xwayland, и делать unscale на стороне композитора, мыла не будет в xwayland, но окна будут спавниться в рандомном месте экрана, поэтому можно с помощью хака их спавнить всегда в центре экрана. Я делал похожий хак и MR для Hyprland https://github.com/hyprwm/Hyprland/pull/3942 и вот багрепорт https://github.com/hyprwm/Hyprland/issues/3029
Вот, например, есть такое расширение https://wayland.app/protocols/fractional-scale-v1 . Sway WM уже поддерживает.
FS давно уже поддерживают все нормальные композиторы, проблема только есть в XWayland. Но это не проблема Wayland, это проблема X11.
А wl_output_listener::scale это тоже проблема X11?
О какой конкретно проблемы вы говорите? Скинете ссылку на багрепорт?
И причем тут базовая функция scale клиента которая обрабатывает scale в клиенте? https://wayland-client-d.dpldocs.info/wayland.client.protocol.wl_output_listener.html
Конкретно о целочисленном параметре factor, который, очевидно, во всех реализациях с дробным масштабированием возвращает ложное значение.
Пруфы? Ссылки на код?
Вам нужны пруфы того что в тип int нельзя передать значение 1.5 или что?
The sent scale is the numerator of a fraction with a denominator of 120.
А это разве проблема?))
Ну так тут то, в отличие от расширения упомянутого выше, не denominator of 120 приходит, а округленное вверх число - 1, 2, 3 итп.
Все равно не понимаю причем тут базовый протокол, и fractional scaling т.к. обработчик FS реализуется отдельно.
https://wayland.app/protocols/fractional-scale-v1
Можете все же вы ссылки на багрепорты с пруфами скинете?
Я программировал fs для egl приложения, и у меня не было никаких проблема с fs. Поэтому я не понимаю вас.
Все равно не понимаю причем тут базовый протокол, и fractional scaling
При том что если в базовом протоколе возвращается некорректное значение, то это косяк архитектуры - протокол плохо продуман.
Можете все же вы ссылки на багрепорты с пруфами скинете?
Что вы так на багрепортах зациклились? Мне специально для вас багрепорт создать нужно или что? Вы хотите сказать что я лгу о том что wl_output_listener::scale вернет 2 при настройках в системе 1.5? Ну так попробуйте сами, оно так себя ведет абсолютно на любом wayland-окружении с fs. Или нужен туториал как с wl_output_listener работать?
Он может что угодно вернуть, но FS обрабатывает свой обработчик т.к. это расширение протокола. Хотите FS реализуйте его соответствующим протоколом. Поэтому я вас не понимаю.
Он может что угодно вернуть
Признак хорошего протокола или апи - или возвращать ожидаемые результаты или не возвращать ничего. А тут возвращается фактически не имеющий отношения к реальности мусор. Потому что изначально решили что 640кб хватит всем, и пришлось колхозить расширения поверх потому что починить это нельзя не сломав совместимость.
Так было до Sway 1.9 и wlroots 0.17
SwayWM 1.9 вышел несколько дней назад
Сейчас у меня стоит scale 1.5 в системе, и mpv играет pixel perfect 4K видео, выходное разрешение. До Sway 1.9 я пользовался костылём и перед включением фильма в 4K масштабирование устанавливал на 1. Сейчас же всё отлично, mpv явно показывает в полноэкранном режиме, что разрешение окна - 3840х2160 (раньше показывал большее значение, раза в полтора-два. Точно не помню, но до Sway 1.9 mpv не показывал выходное разрешение в 3840х2160 в полноэкранном режиме).
Как человек, далёкий от темы, наивно поинтересуюсь. Если передачей картинки по сети небрежно пожертвовали, то
зачем было проектировать протокол, а не api?
в андроиде есть графика, андроид открыт, почему не использовать их решение для графики, зачем wayland?
Унификация и стандартизация.
в андроиде есть графика, андроид открыт, почему не использовать их решение для графики, зачем wayland?
Графический стек андроида сильно привязан к самому андроиду и его сценариям использования. Wayland это более общее решение для более широкого круга задач.
Спасибо за ответ. Я предполагал что-то подобное. Если возможно, не могли бы вы привести примеры подобной привязки стека андроида? Мой интерес чисто познавательный, я не смогу получить эту информацию сам, поверхностно пролистав доки. Как вы считаете, можно ли было адаптировать стек андроида для более общего применения в unix? Возможно, иметь в софтверном ландшафте два похожих графических стека, а не два непохожих, было бы лучше для всех.
Ещё есть ChromeOS, в которой используется нечто под названием "Freon", созданное на замену X и не на базе Wayland или Mir. Почему бы его не взять на замену? За этим Freon должно быть достаточное количество опытных разработчиков на топовых зарплатах, с налаженным процессом разработки и с адекватным управлением проектом. Они выдали результат. Первый релиз Wayland был 15 лет назад, но иксы по-прежнему остаются основным решением для графики. Это провал.
Нечто, созданное для того, чтобы рисовать Хром и только Хром... Наверное, это была бы слишком ограничивающая замена.
Если верить ArsTechnica, ХромОС как раз таки отказывается от Freon в пользу Wayland. А то, что поддержка Вейленда появляется медленно вызвано тем, что дополнения к протоколу утверждаются медленно, так как в этом участвует множество сторон
Автору плюс за статью. Но в статье есть несколько мифов, которые были скопированы и отнесены к недостаткам Wayland.
Не по теме.
KDE MegaRelease 6
The KDE community proudly presents Plasma 6, Frameworks 6 and Gear 24.02
Released Wednesday, 28 February 2024
https://kde.org/announcements/megarelease/6/
Пацаны, как Wayland дружит с LXDE и XFCE? Если бы автор про них не забыл, я бы ему свой последний на сегодня голос пожертвовал.
lxde вроде проект заброшенный, и вряд ли поддержка Wayland будет добавлена. А в xfce уже вроде стали обсуждать добавление поддержки wayland, говорят что в xfce 4.20 Wayland добавят
На иксах можно каждый монитор посадить на свой сервер, если у вас их несколько, на вяленом такое можно провернуть?
И, хотел узнать, если две видеокарты, можно ведь на каждый сервер использовать отдельную видеокарту (опять же на иксах)?
И курсор мыши до сих пор жирный при масштабировании ?
Просто оставлю это здесь. Вкратце, за Wayland никакого будущего и в помине нет.
Это полнейшая чушь
комментарии под видео читали?
А graphical redirection, типа ssh -X, в Wayland есть?
Учитывая что почти все сейчас рисуется GPU, проброс X в общем виде деградирует до RDP/VNC.
Насколько вижу, в Wayland сейчас даже общего решения для проброса через RDP/VNC нет.
Так вроде же pipewire пилят для похожей задачи. И он претендует на универсальное решение.
Посмотрел - там вроде про видео/аудио. Оно точно сможет весь рабочий стол пробросить?
Через VNC запускал удалённо SwayWM. Браузер, несколько приложений. Всё работало
Я получил глубокий взгляд на современные технологии отображения в Linux и разницу между ними. Статья отлично структурирована, и автор ясно объясняет сложные концепции, что делает ее доступной даже для тех, кто не очень хорошо разбирается в технических деталях.
У иксов есть еще важный момент -хост, на котором выполняется приложение вообще может не иметь графики. Удаленныц режим а сервер - на другой ВМ, хосте или ОС. Есть около 20 реализаций X11, в том числе и пяток для Windows. Есть места где это удобно или крайне важно с т.з. безопасности.
О, и подключиться можно ко множеству серверов одновреэменно, на каждом свои окна и, и т.д.
Автору конечно спасибо за статью, но ощущения двоякие.
С одной стороны, читать было интересно, материала много, в общем здорово.
С другой стороны, создалось ощущение, что автор статью писал, но не перечитывал. Встречаются подобные вещи:
"Когда программа занимается отрисовкой, оно обращается к своей базовой
библиотеке, а он уже переадресовывает вызов (или цепочку вызовов) в
libX11, которая используя основной протокол"
еще пример:
"Другие основные настольные компьютеры (LXDE, Xfce и Enlightenment) пытаются быть совместимыми с ATK."
И это только два примера, такого в статье гораздо больше.
OpenVMS - уних подобное ?! Чего только не встретишь тут ...
активно популяризируется вяленый...
Это до перевода, в оригинале что было? :-)
Пробовал Gentoo собрать без иксов в прошлом году - не вышло. Ни одного браузера на чистом Wayland не нашел. Плюнул на затею и вернулся в Винду. Ещё в лине дико раздражает, что при выключении системы не закрывает приложения должным образом. Как сервер норм, как десктоп ну нафиг
Код Xlib очень раздутый и старый, а его альтернатива XKB плохо продвигается.
XKB это вообще-то X Keyboard Extension. Может вы хотели написать XCB?
С 2016 года пытался заставить иксы на игровом ноутбуке msi (2013 года) совместно с nvidia prime. Это в целом костыльная задача, потому как подружить иксы видеокартой, которая нужна только для выполнения\отображения только одного окна не вписывается в архитектуру первого. И вот тут wayland, который появился из коробки в ubuntu 17.04, неплохо сработал. Более-менее заработал nvidia prime, анимации стали шустрее, плюс некоторое облегчение от отказа xorg.conf. Не перешел из-за ограниченной поддержки приложениями.
Чуть позже предпринимал еще попытке перейти на wayland, и он действительно стал лучше, но obs\discord\firefox не могли записывать экран, от чего пришлось снова от него отказаться.
Поддержу автора: как только допилят до ума, чтобы работало из коробки - сразу выкину пачку конфигов от иксов и перейду в светлое будущее. А пока что, идея перейти звучит как, дополнительный геморрой, который придется долго решать и костылить, как это было в свое время с иксами.
Очень интересная статья! Больше бы таких. И подробно и никакой лишней "воды" нет.
В целом, ничего особо нового я не узнал, но теперь все разложилось по полочкам и я более-менее понял что за зверь вайлэнд.
Спасибо!
Раньше я считал, что это просто какая-то глючная урезанная (без сети) замена X11 для запуска игр, а теперь соглашусь: это нашу будущее, но "торопиться не надо" ;)
стоит ожидать появление первого аппаратного обеспечения, не поддерживающего X11
Это как ?
И X11 и Wayland используют kms. Для X11 есть DDX драйвер modesetting его можно использовать если нет специфичного драйвера. Врядли из ядра выкинут kms, совместимость с userspace тоже ломать не будут.
А что там по hyperland ?
Вперед в будущее: Wayland против X11