LINUX.ORG.RU

Релиз Wayland 1.0 и Weston 1.0

 ,


2

2

Состоялся первый стабильный релиз комплекта библиотек и протокола Wayland, а также эталонного композитного сервера Weston. Версия 1.0 знаменует собой стабилизацию протокола, которая, впрочем, не означает, что протокол не сможет более совершенствоваться. Это означает лишь, что нынешняя версия протокола охватывает всю базовую функциональность, использование которой позволит дополнять Wayland нужными возможностями.

Механизм версионирования протокола аналогичен таковому для расширений Хorg. Основная идея в том, что новые версии никогда не нарушают обратной совместимости, вместо замещения старых запросов и событий происходит дополнение. Объект wl_registry уведомляет клиентские приложения о поддерживаемых версиях протокола. Если сервер использует более старый протокол, приложение не будет посылать неподдерживаемые запросы.

Впрочем, устаревшие интерфейсы могут быть удалены, но только после большого промежутка времени в статусе «deprecated» и только при наличии полноценной замены.

Описание политики версионирования:

  • Стабильность протокола и сгенерированного кода, объявленных в wayland.xml, а также клиентского API, определённого в wayland-client.h, будет обеспечиваться для всех версий ветки 1.хх. В ветке 1.хх протокол может быть расширен, но все приложения, собранные с libwayland-client.so версии 1.0.0, будут работать и с версиями в пределах 1.хх.
  • Серверная часть сгенерированного кода и серверный API останутся стабильными в пределах ветки 1.0.х. В главной ветке могут быть различные миграции кода между Wayland и Weston или другие ломающие API ситуации. В итоге может быть выпущен релиз 1.1.0, сохраняющий стабильность протокола и на стороне сервера, но чётких планов в этой сфере пока нет.
  • Weston будет сохранять стабильность API и ABI в пределах ветки 1.0.х. Работа над новыми функциями проолжится в главной ветке.

Изменения с версий 0.95.0 и 0.99.0:

  • Безусловно, самое значительное изменение - более безопасное API нитей. Удалены обратные вызовы из основного API и представлен новый механизм: wl_event_queue.
  • Механизм атомарного обновления поверхностей. Ранее точного определения момента обновления поверхностей просто не существовало, что могло привести к появлению артефактов. Теперь существует запрос wl_surface.commit, который должен использоваться для применения изменений к поверхностям.
  • Более точная проверка ошибок.
  • Удалены неименованные ARRAY_LENGTH и container_of из API.
  • Исправлено большое количество ошибок и существенно дополнена документация.

Напомним, что на данный момент вывод через Wayland поддерживается в Qt 5, GTK+ 3, Clutter и EFL. Также ведётся работа по внедрению поддержки Wayland в SDL.

Для желающих поэкпериментировать доступен git-репозиторий проекта Wayland, а так же Live-дистрибутив для тестирования.

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



Проверено: JB ()
Последнее исправление: JB (всего исправлений: 3)

Ответ на: комментарий от plm

Я жду FVWM :) Без полной поддержки FVWM Wayland не взлетит :)

о, живой пользователь fvwm! ты SwallowNew для FvwmButtons не использовал? //ниасиливаю

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

В итоге можно легко сделать графическое приложение прямо в консольке (например, есть порт quake3 на egl, который можно запускать прямо из консоли, поверх которой он будет рисовать 3D-картинку безо всяких иксов).

А сейчас консолька разве рисуется в текстовом режиме? Возьми любой 3D движок который тебе нравится и слабай в нём консольку со шлюхами и поэтессами.

Есть, кстати, еще одна интересная идея, в которой в ядро linux добавляется менеджер GEM-буферов (как бы виртуальных, а может и реальных консолек), там можно будет реализовать композитор поверх API ядра безо всяких протоколов wayland на TCP/IP, а просто «композитить» GEM-буферы с терминалов на отдельном выделенном терминале...

Ведро рисующее графику - здравствуй виндовс и нагрузка на проц.

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

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

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

Wayland использует ядро, рисующее графику. Это DRI, GEM и KMS. Добавить возможность «выдергивать» из-под других приложений GEM-буферы не такая уж и сложность. Это позволит сделать libwayland ненужным чуть менее чем полностью...

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

1. [...] Но, например, поставить на экране три точки в разных местах быстрее всего именно таким методом.

Надуманный пример - в большинстве случаев быстрее окажется эти же три точки отрисовать со всем остальным, ну например в уже созданном контексте OpenGL. Попиксельное рисование разве что для хелловорлдов сойдёт.

Пункт 2. тоже не очень - ну да, можно обращаться к серверу с просьбой нарисовать примитив, можно и в opengl использовать glRotate/glTransform, каждый раз дёргая драйвер (который и потокобезопасным может быть, что тоже даёт оверхед).

Мне вот интересны способы, использующие преимущества многопоточности, ускорения на видеокарте, отсутствия копирования памяти. Тут уже упоминали буфер глифов для вывода текста, shared memory говорят уже устаревшим считается, а что сейчас модно?

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

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

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

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

Бесполезно. Знатоки матчасти советуют в C++ при перегрузке оператора присвоения проверять this == &other всегда, даже алиасинг не вызовет ошибки - якобы в целях оптимизации, лол. Можно троллить обе стороны и слушать мнения, можно гонять сам вейланд или тулкиты, портированные под него - каждый способ обладает своими преимуществами, но ни один не ответит, что же всё-таки будет лучше для светлого будущего.

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

Этот протокол не позволяет создать WM. Вообще. В его протоколе это не возможно. WM под wayland-ом должен полностью реализовать весь протокол заново.

Надо же, открыл Америку! Я то не знал, что композитор есть имплементация вяленого, реализующая его протокол.

Wayland/weston — это монолит, иксы+WM в одном флаконе.

Вяленый не берет на себя и половины функционала иксов, сравнение не корректно.

Хочешь получить awesome под wayland — форкаешь исходники weston-а и меняешь в нем код управления окнами.
Его протокол не позволяет управлять окнами

/0 аноним доставляет :D

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

Бесполезно. Знатоки матчасти советуют в C++ при перегрузке оператора присвоения проверять this == &other всегда, даже алиасинг не вызовет ошибки - якобы в целях оптимизации, лол.

Это не знатоки, если они не читали Херба Саттера. Поэтому чем просто слушать знатоков, предлагается при этом думать головой.

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

Wayland использует ядро, рисующее графику. Это DRI, GEM и KMS. Добавить возможность «выдергивать» из-под других приложений GEM-буферы не такая уж и сложность. Это позволит сделать libwayland ненужным чуть менее чем полностью...

Круто, технология заложенная Wayland уже устарела, пора переписывать. А с иксами такой хак провернуть нельзя?

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

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

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

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

А теперь в этой теоретической ситуации пользователь нажимает PrintScreen. Что должно произойти?

Вместо окон, к которым скриншотилка не имеет доступа, он увидит белые прямоугольники. Да, это будет by design. Я не хочу, чтбы через уязвимость браузера кто-то мог видеть мой редактор и эмулятор терминала.

наверное, у меня неправильные иксы, пирацкие

А теперь набери xauth list, будешь еще больше удивлён. И прочитай уже ман.

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

И это так, если говорить о голой сетевой прозрачности иксов как таковой.

Я вижу, ты так ничего и не понял, мой зеленый друг.

☑ Еще один вялендолюб, которому бесполезно что-либо объяснять.

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

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

directfb

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

Вяленый не берет на себя и половины функционала иксов

Но стремительно к этому приближается семимильными шагами. Уже есть поддержка методов ввода и обещается поддержка протокола управления окнами. Кто-то тут полгода назад кукарекал про «простой композитинг без лишних функций».

Хочешь получить awesome под wayland — форкаешь исходники weston-а и меняешь в нем код управления окнами.
Его протокол не позволяет управлять окнами

/0 аноним доставляет :D

Код управления окнами != протокол управления окнами. Делишь на ноль тут только ты.

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

Но стремительно к этому приближается семимильными шагами.

4.2

Уже есть поддержка методов ввода

Над этим работают уже очень давно...

обещается поддержка протокола управления окнами

А оконная система без этого вообще может существовать, пусть даже самая простая?!

Кто-то тут полгода назад кукарекал про «простой композитинг без лишних функций».

Что изменилось?!

Код управления окнами != протокол управления окнами.

Код значит есть, протокола нету?! Укуренный?!

Делишь на ноль тут только ты.

Тебя бы поделить, когда уже бан словишь?! Иди ка ты в список друзей, по 5 постов бреда и жира выкладываешь...

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

Когда отображается через RDP - оно по любому гоняет BMPхи с удаленно открытого браузера

Оно «BMPхи» не гоняет. Во-первых, RDP активно жмёт (компрессия). Во-вторых, RDP агрессивно использует кэширование.

Точно так же другие «примитивы» современных фреймворков гоняются битмапами.

Увы, но алгоритмы и в X11, и в RDP в разы лучше чем те идеи, которые используются в «современных фреймворках» когда авторов оных фреймворков «осеняет» очередная идея рисовать всё самим и отдавать только готовый пиксмап.

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

А оконная система без этого вообще может существовать, пусть даже самая простая?!

Как выяснили разрабы вейланда — не может. «А так хотелось.» Для убогоньких памятью напомню, что не так давно все вялендодрочеры собирались фапать на «окнами пусть управляет тулкит через dbus», в том числе, в рассылке. Пока главный девелопер вейланда не объяснил, какую чушь они несут.

Что изменилось?!

Изменился список фич, которые уже приближается к таковым у иксов. Ваш Кэп.

Код значит есть, протокола нету?! Укуренный?!

Разупорись. Код находится в сервере. И через протокол его возможности не доступны. За отсутствием оного протокола в «стабильной версии 1.0».

Тебя бы поделить, когда уже бан словишь?! Иди ка ты в список друзей, по 5 постов бреда и жира выкладываешь...

Твою баттхерт неуча, не осилившего ознакомиьтся с матчастью, путающего протоколы и реализации, VNC и RDP, XRender и core api, и безудержно на этой базе расхожих заблуждений порящего чушь вот уже несколько месяцев подряд, безумно доставляет. Ты меня уже который раз всё отправляешь и отправляешь в игнор-лист, но никак не можешь отправить. Но поскольку меня «всё никак не забанят», можешь в знак протеста забаниться сам. Мы все будем очень по тебе скучать.

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

Как выяснили разрабы вейланда — не может. «А так хотелось.» Для убогоньких памятью напомню, что не так давно все вялендодрочеры собирались фапать на «окнами пусть управляет тулкит через dbus», в том числе, в рассылке. Пока главный девелопер вейланда не объяснил, какую чушь они несут.

Я здесь причём?!

Изменился список фич, которые уже приближается к таковым у иксов. Ваш Кэп.

4.2

Разупорись. Код находится в сервере.

Разупорись, чудик! У него архитектура такая. Сервер - есть имплементация оконного менеджера. Матчасть учи.

путающего протоколы и реализации, VNC и RDP, XRender и core api

Пруф или пароль от акка!

Ты меня уже который раз всё отправляешь и отправляешь в игнор-лист, но никак не можешь отправить.

Пруф! ЗЫ только, что добавил, ради лулзов посмотрел игнорируемые. И не прогадал: 4.2, жир и бред во все поля. Школо-ло такие предсказуемые...

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

Разупорись, чудик! У него архитектура такая. Сервер - есть имплементация оконного менеджера. Матчасть учи.

Атлична! А теперь покажи мне аналог всего вот этого в этом «оконном менеджере».

У него архитектура такая

Кто-то только что прокукарекал про доступность управление окнами через протокол. Мы ждём пруфов. Пруууфов.

Пруф или пароль от акка!

Могу только губозакаточную машинку предложить.

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

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

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

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

Почему печально? Их комментарии по сути закрывают тему, а вялендофилам остается истерить, как erfea, или гнать невнятную муть, как quiet_readonly.

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

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

Слушай, тут на опеннете бочку на xrender накатили. Мол если что он бъёт изображение на кучи примитивов и гонит этот бешеный трафик. И лучше было вместо него какую-то одну высокоуровневую рисовалку запилить - типа кайро. Оно так и есть?

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

Оно «BMPхи» не гоняет. Во-первых, RDP активно жмёт (компрессия)

Оно гоняет именно битмапы 95% времени, независимо от того кеширует их или сжимает ))

Увы, но алгоритмы и в X11, и в RDP в разы лучше чем те идеи

Увы или нет, но важен результат. А результат однозначно говорит о бесполезности этих алгоритмов.

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

Бесполезно. Знатоки матчасти советуют в C++ при перегрузке оператора присвоения проверять this == &other всегда, даже алиасинг не вызовет ошибки - якобы в целях оптимизации, лол.

Это не знатоки, если они не читали Херба Саттера. Поэтому чем просто слушать знатоков, предлагается при этом думать головой.

Что-то я не понял в чем тут проблема. Топик не читал.

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

Не наздо звиздеть. RDP-шный сервер виндовый 90% времени командует закешированными глифами и пиксмапами. Это особенно хорошо заметно при перетаскивании окна или иконки на медленном канале.

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

А результат однозначно говорит о бесполезности этих алгоритмов.

Сейчас результат таков, что

1. RDP и X11 быстрее вяленда по сети

2. X11 быстрее вяленда в локальной прорисовке

3. X11 по масшатбируемости на 2 порядка лучше вяленда

4. X11 в несколько раз лучше продуман (NETWM, XKB и т.д.)

5. X11 «просто работает»

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

Оно гоняет именно битмапы 95% времени, независимо от того кеширует их или сжимает ))

Вы бы не позорились, а прочитали документацию по RDP. Там никаких чудес нет - RDP кеширует что можно и гоняет примитивы, а не битмапы. Его делали умные люди, которые создавали аналог сетевой части X Window System под Windows. Разумеется, как следующее поколение сетевых протоколов, он несколько эффективнее X.

Ну так Х нужно подпилить до современного состояния, а не менять на аналог тупого и тормозного VNC.

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

Сейчас результат таков, что

Единственный вопрос - хватит ли этих недостатков для того, чтобы Wayland не взлетел? Или же его всё равно пропихнут.

constRS
()

Интересно. В винде примитивы по удаленке есть (rdp), а тут? Ни удаленки, ни примитивов? Только разница битмапов?

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

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

RDP кеширует что можно и гоняет примитивы, а не битмапы.

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

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

Увы, но алгоритмы и в X11, и в RDP в разы лучше чем те идеи, которые используются в «современных фреймворках» когда авторов оных фреймворков «осеняет» очередная идея рисовать всё самим и отдавать только готовый пиксмап.

Я так понял, что они готовятся прыгнуть на планшеты и телефоны. Поэтому такой принцип отрисовки и такая версия OpenGL.

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

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

А сейчас программы из разных тулкитов разве не чёрти как выглядят? Но тут есть ещё и другая страшилка: каждое окно сможет нарисовать себе свой уникальный декоратор!

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

Но тут есть ещё и другая страшилка: каждое окно сможет нарисовать себе свой уникальный декоратор!

В принципе, оно и сейчас это может.

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

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

Binary ★★★★★
()

Когда на десктопе оно появится в юзабельном состоянии...

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

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

Да, разумеется, в ряде случаев гоняет битмапы.

Мне просто не хотелось растекаться мыслью по древу. Ведь если 2 странички документации RDP для некоторых - «многа буков», то в комменте вообще должно быть всё чересчур упрощено.

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

Я так понял, что они готовятся прыгнуть на планшеты и телефоны. Поэтому такой принцип отрисовки и такая версия OpenGL.

Да, по-видимому, Wayland пришёл из планшетов. Это объясняет и общеизвестный маразм с декорациями, и стремление экономить на спичках - сетевой прозрачности, и общую убогость задумки.

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

Куда они прыгнут если всё сховал дроид и ифон.

Intel уже не первую мобильную платформу делает (фейл за фейлом, да, но всё же).

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

по-видимому, Wayland пришёл из планшетов.

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

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

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

anonymous
()

Я так понял, надо ждать появления дистриба, в котором не будет systemd и wayland'а, но при этом будет собственный DE, ибо все будущие скурвятся.

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

Куда они прыгнут если всё сховал дроид и ифон.

До дроида был WinCE и Symbian. Ничего, iOS и Андроид как-то их оттеснили.

Прыгнут они в сектор дешевых домашних недокомпов, чьим прародителем является, Raspbery Pi.

А после запиливания слоя совместимости с Андроидом и появления на последнем MS офиса, я думаю, у них вполне есть шанс.

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

А сейчас программы из разных тулкитов разве не чёрти как выглядят? Но тут есть ещё и другая страшилка: каждое окно сможет нарисовать себе свой уникальный декоратор!

Ну если это QT или GTK, то теперь они выглядят более-менее похоже: те же шрифты, те же цвета. Кнопки могут стоять в разном порядке и ресайз GTK-шный бывает затейливым, но все остальное обычно не выбивается.

А вот насчет декоратора, я думаю, позаботится Fedora. Поттеринг на основе pulseaudio и systemd запилит декоратор, потому как графика же нужна с первых минут старта, еще до ядра, чтобы можно было просматривать логи (почему все поломалось), а звук все равно через pulseaudio...

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