Обзор прогресса портирования Wayland в основных рабочих окружениях Linux

В Wayland нет ни единой инновации. При этом по своей сути это несколько шагов назад по сравнению с иксами.

Aceler> Как там с глобальными шорткатами при открытом меню? В вейленде работает.

Как там у вяленда с сетевой прозрачностью через интернет на узких каналах порядка 64 килобита в секунду? На иксах вот работает вполне прилично. Сейчас этот текст набираю удалённо.

Polugnom> Осталось только невидии дрова запилить и можно наконец закапывать иксы.

Невидия уже свои кривые недодрайверы в виде блобов под иксы запилила. Иксы от этого не умерли.

WatchCat> Так вяленый это по сути протокол. Он готов.

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

Aceler> Нет, в архитектуре Wayland окно не знает, где оно позиционировано абсолютно

Ясен пень - этим WM должен заведовать, а не приложение. Если эту возможность в вяленд внедрят, то будет полный кабздец. Худший протокол получится из всех подобных.

hobbit> X11, конечно, посложнее будет

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

hobbit> Если будет полноценным - то какая разница, что там под иксами крутится.

Разница в оверхеде. Для того, чтобы запускать X-сервер, лучше всего иметь базовую графическую подсистему, которая предоставляет предельный минимум и отвечает за взаимодействие с железом. А уж поверх X-сервер реализовывать. Тогда и оптимус будет легко сделан, и стереорендеринг без костылей, и виртуальные дисплеи для 3D-очков, и т.д.

hobbit> Microsoft вон за 20 лет win32 так и не выбросил

Мелкософт с переменным успехом на дотнет всё переводит. Так что выкидывание win32 - вопрос времени.

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

Wayland

Долгострой, устарел, ненужное говно, как те же иксы. Нужно писать прямо в /dev/fb0, как это всякие PS4 и Android'ы делают.

Mystra_x64> Никто в своём уме поддерживать иксы не возмётся нынче.

Возьмётся.

Hertz> КДЕ5 параша редкостная, и уйти с неё никуда не могу.

KDE4, TDE.

Aceler> Для юзера как раз имеет. Там работают хоткеи при открытых меню — это реальная киллер-фича для конечного юзера.

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

Таки еще раз. Кто-нибудь сможет объяснить, зачем нужен этот вейланд? Какие существующие проблемы решает, какие дает новые возможности?

Прикинь - Qt ещё до всех этих новоделов прямо в фреймбуфер умел рендерить. См. Qtopia и Opie.

anonymous> Кто-нибудь сможет объяснить, зачем нужен этот вейланд?

Легко.

anonymous> Какие существующие проблемы решает

NIH

anonymous> какие дает новые возможности?

Колоссальные возможности по велосипедостроению.

Хватит петросянить. Куча человек прикладывает массу усилий не просто так же. Ведь в иксах проблемы не так уж тяжело и сложно решались: прикрутить рисовалку с нормальными примитивами, и безопасность подпилить (через нее и лимиты и сессии). Тут же создают что-то свое, создают тяжело и трудно, при этом не объясняя ничего!

Оно разве ещё живо?

Колоссальные возможности по велосипедостроению.

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

Помрут через пару лет. И это прекрасно.

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

Это все серьезно? И да, меня еще несколько смущает множественное число раскрытых меню.

Я знаю. Более того, у меня был даже девайс на Qt/Embedded 2.3.8

Вот только там был не совсем уж прямой fb0, а очень-очень простенький аналог иксов, который назывался, QWS.

http://doc.qt.io/qt-4.8/embeddedlinux-support.html

Compact and Efficient Windowing System QWS

Qt builds on the standard API for embedded Linux devices with its own compact window system. Qt-based applications write directly to the Linux framebuffer, eliminating the need for the X11 windowing system.

И этот QWS, конечно, выпилили из Qt 5, лол.

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

гента далеко не всегда равно компиляция, более того, сейчас в генте почти всё есть в бинарниках, другое дело зачем она, а затем, что в rpm и особенно в deb дистрах много ненужных зависимостей, а при пользовании докером их хотят минимизировать. да и 1000 хостов это не много в уловиях, когда 80% из них это одно и тоже, имеющее один конфиг в плейбуке ансибла.

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

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

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

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

и в xorg(x11) это в принципе невозможно

https://bugzilla.gnome.org/show_bug.cgi?id=700316#c3

Подробности знаю, но готового описания в сети не видел.

Как там у вяленда с сетевой прозрачностью через интернет на узких каналах порядка 64 килобита в секунду?

Понятия не имею, не пробовал. Архитектурных ограничений нет.

Also: https://xkcd.com/619/

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

Пользователю похеру на то, на чьей стороне проблема.

Но это всё фигня на фоне кейлоггеров и тотального отсутствия разграничения доступа в иксах.

Ср-нь господня, таки вменяемую безопасность запилили в вейланде? Почему об этом никто не говорит?

Да все говорят. Просто на фоне ко-ко-ко, ситивая празрачнасть, не слышно.

Да все говорят. Просто на фоне ко-ко-ко

Будь любезен, кинь ссылку.

Например вот.

лучше всего обстоят дела в GNOME

Приложения на Qt 5 уже запускаются нативно? Или опять композитор материть будут?

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

Это ужасно. Нет, серьезно, getting window content of other windows is not possible делает нерабочими кучу приложений.

Прицепляться к чужой очереди ввода тоже иногда нужно (reading of key events for other windows is not possible).

Безопасность — это не отсутствие возможности! Это вообще о другом.

Вердикт: обоссать и сжечь.

В Wayland нет ни единой инновации. При этом по своей сути это несколько шагов назад по сравнению с иксами.

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

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

Композитору без разницы, каким образом заполняется буфер. Клиент может рисовать в буфер силами процессора, либо использовать любую из доступных видеокарт.

Иксы могут только в оконный интерфейс, где окна расположены в плоскости XY с координатой глубины Z. Вейленд же позволяет создавать 3d интерфейсы с тесселяцией и реалистичной физикой. Первые ласточки: [1], [2]

Каждому приложению будет доступно 2млрд пикселей в длину и в ширину, а сколько всего будет пикселей? Жуть. Тем временем с иксами ты можешь окружить себя 8 мониторами 4K, но мы ведь говорим о будущем? 640КБ не хватит всем.

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

Т.е. в вяленом неотключаемый vsync? Это как-то повлияет на игровую производительность?

Нет, серьезно, getting window content of other windows is not possible делает нерабочими кучу приложений.

Если кому-то нужно следить за чужим вводом - плагин композитора. Либо запрашивать нужные права через dbus. Либо ещё как-то сообщать композитору о том, что вот этому приложению нужно это. Как всё это сделать ещё до конца не решили. В принципе это не проблема, просто вариантов много.

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

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

Т.е. в вяленом неотключаемый vsync?

Нет. Здесь речь про последовательность кадров, а не про их общее кол-во в секунду.

Так значит изображение все равно может рваться?

Пользователю похеру на то, на чьей стороне проблема.

Т.е. пользователю похеру отчего вэйланд --- неюзабельное говно.

значит изображение все равно может рваться?

А это тут причём?

Нет, при рендере через wayland кадр сперва должен быть готов, и только потом он отрисовывается. Целиком, как следствие не рвётся. Если кадр не успел вовремя, то он дропается, а не рисуется спустя 10 кадров.

Когда будут тесты дотан в wayland и в x11?

Кадр сперва готов, потом он отрисовывается монитором поверх предыдущего и картинка рвется. Если нет - то это таки неотключаемый vsync.

Кадр(приложения) сперва готов -> Композитор совмещает все готовые кадры/заменяет нужные области -> отрисовывает экран целиком/изменения (не знаю как это реализуется).

Если какая-то область обновляется 200 раз в секунду -> будет отрисовываться 200 раз в секунду (если успеет). Vsync тут не при делах.

неотключаемый vsync

Типа того, но более походящее на тройную буферизацию от nvidia. На слайде от самсунга видел 3 буфера (сколько их там предусматривается сложно сказать, может и двумя можно обойтись, может и 10 можно использовать, с одним вряд ли получится). Формально клиент рисует в некоторый «свой» буфер, потом говорит композитору, что буфер готов. Взамен клиент должен взять свободный буфер, где можно рисовать новую картинку. Итого получается - у композитора всегда есть готовый буфер, а у клиента всегда есть текущий, в котором клиент рисует. По-идее тут должна быть блокировка в момент передачи буфера композитору, но третий буфер позволит избавить от ожиданий.

Отличие от всяких композитных режимов Xorg в основном в том, что не делается лишнее копирование в момент передачи содержимого буфера от клиента композитору (хотя тут уже DRI3 есть, который должен позволить Xorg сделать что-то подобное). Алгоритм жонглирования буферами в Wayland вроде как на совести клиента, главное - не менять буфер композитора.

P.S. Использование damage (если не путаю) позволяет обновить только изменившиеся области, чтобы не перерисовывать буфер целиком. Ну там видимо маски какие-то...

Совершенно верно. Очевидно, что прямо сейчас вейланд не составляет конкуренции.

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

Аха, а безопаснее еще вообще не запускать систему, а лучше всего смерть.

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

наличие xspy

Ну ладно, повторю. Плагин к композитору, запрос привилегий по dbus, что-то в стиле ядерных capabilities - вариантов много. Плагины к композитору работают уже сейчас (да, к каждому свои), общие протоколы в разработке.

Может опишешь, каким таким волшебным образом другие системы узнают, кому давать доступ к содержимому окна, а кому нет? Вдруг разработчики что-то упускают, а ты молчишь.

Ну ладно, повторю. Плагин к композитору, запрос привилегий по dbus...

Все это прекрасно, но бла-бла-бла неинтересны никому. Задача решена или нет? По какой-то странной извращенной логике в качестве аргументов за wayland идет критика X. Когда же спрашиваешь, как эта задача решена в wayland, то ответ - никак.

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

Все это прекрасно, но бла-бла-бла неинтересны никому. Задача решена или нет?

Плагины к композитору работают уже сейчас

Решена. Прорабатываются более хорошие решения.

производительность никакая.

Пруфца давай.

Каких-то новых возможностей он не предоставляет

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

не будет стандартной переключалки раскладки

один вопрос: а какого хрена этим (интерпретацией нажатых клавиш, в т.ч. их комбинаций) занимается графический сервер?