LINUX.ORG.RU
ФорумTalks

LFCS 2012: X и Wayland (кратко)

 , ,


0

3

Keith Packard - разработчик Х-ов с давних времен, рассказывает нам о разработке Wayland - наследника Х.

В начале он рассказал как работают Х и Wayland и как они сделали поддержку Х-овых приложений в Wayland. Механизм поддержки похож на тот, который используется в MacOSX и Windows, шо несет пенальку по производительности, но Паккард уверяет, шо у них есть воркераунд, который позволяет работать Х-прогам так же быстро (как я понял, посредством OGL или VAAPI).

В слеующем параграфе Паккард сравниает X и Wayland, основные различия:

+ Х имеет отдельный compositor, Wayland - внутренний.

+ Х поддерживает управление окнами сторонними приложениями, Wayland занимается этим лично. Среди прочего, в X можна управлять окнами повисших приложений (неясно, как будет в Wayland. Еще это значит, шо наши любимые WM: *box, тайловые и многие другие = не будут работать под wayland (?) o_0).

+ X-проги не рисуют декорации окон, тогда как Wayland-проги должны рисовать их сами (QT рисует свои, GTK - свои, т.е. к каше тем прибавляется еще и каша с декорациями окон, кнопками в разных местах. Непонятно, шо будут рисовать всякие SDL).

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

Еще параграф он посвятил управлению окнами. Как уже упоминалось, декорации будут рисовать приложения, как им захочется (любой формы), будет плавный ресайз, зумирование и кручение окон и другое. Для вырезать/вставить и драг/дроп Wayland использует «MIME-labeled UTF-8 encoded objects».

Кроме того, он думает, шо лучшим путем запуска Х приложений будет не держать Х-сервер постоянно, а активировать по запросу (Weston будет слушать сокет X).

В последнем параграфе он затронул нерешенные проблемы:

- поддержка ввода еще не стабилизирована;

- вопросы по поддержке клавиатур, тачпадов и тачскринов;

- приложения Wayland через сеть. Паккард: Есть много хороших механизмов для передачи изображений, данные могут быть сжатыми итд. Думает, шо приложения, возможно, будут работать быстрее, чем через механизмы Х.

- требуется работа над оконным менеджером X/Wayland, вырезать/вставить, драг/дроп, а также Xinput 2.2.

https://lwn.net/Articles/491509/ (Jake Edge / 11.04.2012)

★★☆☆☆

Последнее исправление: FiXer (всего исправлений: 3)
Ответ на: комментарий от no-dashi

У вяленда есть одно неоспоримое преимущество: Y12 будет гораздо легче реализовать поверх вяленда, чем с нуля.

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

Эм. Если декорации рисует WM, то при ресайзе клиент и WM долго и часто пытаются синхронизировать ресайз. Это чуть ли не гарантирует тиринг.

Ты просто так слова которые знаешь произносишь?

И вообще, в чём проблемы выделенных в отдельную либу декораций?

Угу. В чем проблема выделения в одну либу видгетов.

С принудительной отрисовкой хоть чего-то, если клиент виснет.

Если клиент рисует и клиент виснет - все кончается.

Многие особенности иксов формировались во время, когда динамических библиотек не было, но зачем повторять их сейчас?

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

r ★★★★★
()
Ответ на: комментарий от cvs-255

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

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

Если клиент рисует и клиент виснет - все кончается.

Или его окно затемняется и сервер рисует дефолтную декорацию, как сделано в некоторых ОС.

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

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

Ты в миллиметрах тормоза меряешь?

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

Ну так X11 и fbdev поддерживает. И при желании можно запилить использование ускорения, но выводить все равно во фреймбуффер.

cvs-255 ★★★★★
()
Ответ на: комментарий от x3al

Y12 будет гораздо легче реализовать поверх вяленда

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

Вяленд в принципе неприменим для тонких клиентов - на нём нельзя, В ПРИНЦИПЕ нельзя сделать что-то подобное X-терминалу - сетевая прозрачность отсутствует как класс. В результате, вместо естественной сетевой прозрачности как сейчас, предлагается городить костыли как это сделано в MS-RDP, а та «сетевая надстройка» это костыль похлеще чем X11.

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от Ford_Focus

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

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

в случае с Х11 проблем накопилось многовато, костылей еще больше. такие проблемные вещи проще полностью переписать, чем пытаться исправить.

конечно, было бы логичнее пойти по уже проложенной дорожке, написав Х12, но он никому не интересен видимо.

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

Проблемы... какие например волную вас? Только про использование сети на локалхосте не надо. Тупняк -20.

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

[mode=«hamster»]ИНТЕРФЕЙС ТОРОМОЗИТ!!!1[/mode]

Иногда процесс Xorg может начать съедать ~40% процессора, а интерфейс начать глючить так, что пользоваться им совершенно невозможно. Причем проблема воспроизводится у разных людей, на разном железе, на разных дистрибутивах. Решения, кроме «ИКСЫ ГОВНО!!!1» найдено не было. Также меня страшит вероятность возвращения 12309.

если Wayland может похоронить данную проблему - я двумя руками за Wayland

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

Х тормозят. А вяленый МОЖЕТ БЫТЬ решит эту проблему. Причём причину тормозов Х Вы уже нашли и поняли что она в программе ВНЕЗАПНО X.org. Есть другие реализации X Window System. Чем они вас не устраивают? Или вы решили не мелочиться и записать в отходы сразу архитектуру?

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

само собой, пока нет самого Wayland трудно сказать, что он решит, а что поломает.

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

минусы и проблемы Х11 многократно перетерались, зачем разводить еще один срач? является ли Wayland адекватной заменой иксов покажет время.

Ford_Focus ★★★★★
()
Ответ на: комментарий от no-dashi

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

Это не мешает сделать окно на весь экран вяленда и реализовывать в нём свои окна. С любыми правилами поведения.

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

Они не работают без динамических библиотек, ололо
Можно создать альтернативный тулкит, можно как-то адаптировать qt/gtk в линуксе.

quantum-troll ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.