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)

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

Забыл. Это обязательно будет библиотека и специальная часть, отвечающая за внешний вид. Чтобы создать тему, нужно будет на C-подобном языке ее описать и скомпилировать. А чтобы поменять, будет особая тулза + особый конфиг на все случаи жизни.

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

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

Мне кажется, что это вещи несвязанные. Скорее народ совершенно не думает перед тем, как писать систему. Хотя все требования к десктопам уже давным давно известны.

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

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

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

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

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

А как же обязательная перезагрузка?

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

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

Я так 15 лет назад развлекался с festival. Но тут, конечно, речевой движок должен быть встроен в systemd, поэтому его надо писать с 0 на С.

constRS
()

Кстати, cast ckotinko. Как там у него работа над кишками видеоподсистемы продвигается...

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

А как мне защитить информацию в окнах иксов? Злоумышленник сможет читать мои чаты в реальном времени и видеть редактируемые файлы. Предложишь мне каждое приложение запустить на отдельном икс-сервере?

А где-нибудь это вообще реализовано?

Я вот смотрю на виндовую прогу запущенную под административными правами, дык она на скриншоте - сюрприз - есть.

Глупый какой-то пример.

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

А где-нибудь это вообще реализовано?

Если что-то еще нигде не реализовано, это повод ничего не делать? Замечательный ход мысли...

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

Если что-то еще нигде не реализовано, это повод ничего не делать? Замечательный ход мысли...

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

Допустим я юзер. Я запускают от админа программу.

Если мы ее изолируем, то получится, что

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

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

Например, если программы ничего о ней не будут знать, значит никак нельзя будет вывести столь желаемый где-то тут в треде запрос на пароль. Запрос придется выводить перед каждым движением мыши или делать таймаут. Короткий, ибо секьюрность.

Кому это надо?

Какой такой волшебный скрипт и откуда похитит некие данные?

Реально правильно сказали - хотите изолировать приложение, пускайте другие иксы.

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

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

Ваш ход мысли ошибочен.

Если мы ее изолируем, то получится, что
а) нельзя пользоваться буфером ввода вывода.

Что такое «буфер ввода-вывода»? У гуях нет такого понятия.

б) на ней ничего нельзя нажимать.

Вообще, то можно. Каждый агент на иксовой шине, включая сами иксы, имеет собственный набор прав. Иксы имеют права посылать сообщения в эту программу. А условный «потенциально хакнутый фирефокс» — нет.

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

Это абсолютно пофиг. «Другие программы» могут видеть только ID её окна и больше ничего. Зачем фирефоксу что-то знать о нашей программе? Правильно - незачем. WM и панель видят нужные свойства окон, чтобы управлять окном. Композитор видит содержимое окна, чтобы рендерить его.

г) на скриншотах она должна быть темным пятном.

Да. Именно этого я и добиваюсь.

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

Ход мысли объясни.

Кому это надо? Какой такой волшебный скрипт и откуда похитит некие данные?

С виндой давно дело имел? Приходилось слышать про кейлоггеры и трояны, ведущие наблюдение за окнами? Так вот линукс НЕ ЗАЩИЩЕН от уязвимостей приложений. Достаточно поиметь одно приложение в сеансе, чтобы получить доступ ко всему сеансу. Пока что линукс спасается только по причине Неуловимого Джо.

Реально правильно сказали - хотите изолировать приложение, пускайте другие иксы.

А я еще раз спрашиваю: мне под каждое приложение, которое потенциально могут поиметь извне (браузер, мессенджер, торрент-клиент...) запускать отдельные иксы?

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

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

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

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

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

Если под активным имеется ввиду окно, имеющее фокус ввода, можно подписаться на получение FocusOut и FocusIn для каждого имеющегося окна. Пример реализации можно посмотреть в сорцах xneur.

В случае же ICCCWM, достаточно ловить свойство _NET_ACTIVE_WINDOW на корневом окне.

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

Если под активным имеется ввиду окно, имеющее фокус ввода, можно подписаться на получение FocusOut и FocusIn для каждого имеющегося окна. Пример реализации можно посмотреть в сорцах xneur.

к сожалению xneur, xxkb совершенно неадекватно ловят сообщения, во всяком случае в тайлинге. kbdd (собственно ради чего спрашиваю) ловил нормально, но в итоге из-за каких-то других проблем с ненулевой вероятностью лочил Meta4 в тех же тайлингах.

А с переходом на ICCCWM only проблема с локом исчезла, как и поддержка дефолтного xmonad.

но пасиб, за информацию.

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

к сожалению xneur, xxkb совершенно неадекватно ловят сообщения, во всяком случае в тайлинге

Возможно, они тоже рассчитывают на своевременную смену _NET_ACTIVE_WINDOW. Давно это было, когда я сорцы xneur смотрел, уже не помню подробностей. Не думаю, что xneur в без-ICCCWM-ной конфигурации тестировался кем-либо из разрабов.

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

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

Это вы бы не позорились и пользовались бы мозгом, а не только документацией. Примеры выше уже приведены - содержимое окна браузера, результат работы фреймфорков типа WindowsForms/PresentationFoundation/QT/etc. Максимум примитива, который там может быть передан - результирующий битмап содержимого окна. То что RDP кеширует или сжимает - ВООБЩЕ ДЕСЯТОЕ ДЕЛО и не суть.

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

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

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

4.2

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

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

Вооот! Так работа с пиксмапами - это какраз то, что должен делать протокол на базе вяленда. Никто не мешает командовать удаленными пиксмапами. Я к тому, что этой функциональности достаточно на 90%. Рассчитывать что изменилось, сдвинулось. И слать команды. Естественно не нужно тупо слать срез экрана с частотой 15 кадров в секунду.

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

еще раз подумай, чем вялендовая работа с пиксмапами отличается от иксовой,а?

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

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

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

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

Ну, тесты в попугаях уже давно ничего не значат. Те же glxgears у меня на GeForce 9600GT показывают десятки фпс, а на древнем RadeOn 9600 - несколько сотен.

Для этого есть мозги же. Если glxgears показывает стабильно 60FPS, значит он ограничен разверткой монитора. Это можно легко проверить, посмотрев в top и увидев, что он занимает всего несколько процентов CPU. И, кстати, это ограничение легко отключается так:

$ vblank_mode=0 glxgears
В общем, при наличии моззга тесты в попугаях очень даже многое значат.

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

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

Вопрос не в том чего я хочу, а в том - есть ли у нас варианты. Оно уже гоняется картинками. Увы.

И если бы меня, как разработчика, спросили - а можно ли на базе вяленда сделать удаленный протокол, сравнимый по эффективности с RDP - я бы сказал ДА.

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

Это вы бы не позорились и пользовались бы мозгом, а не только документацией. Примеры выше уже приведены - содержимое окна браузера, результат работы фреймфорков типа WindowsForms/PresentationFoundation/QT/etc.

Очевидно, что мозга многим не хватает, чтобы сесть и за 15 минут придумать, почему не надо всё время слать битмапы (и почему в Wayland/VNC наоборот - надо), а потом прочесть документацию, и убедиться, что это так и сделано.

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

Надуманный пример - в большинстве случаев [...]
Пункт 2. тоже не очень [...]

Дело не в том, очень он или нет. Никто (кроме вейландовцев) не говорит, что надо всегда использовать только один способ. Наоборот, речь как раз о том, что надо использовать именно тот способ, который лучше. Если мне нужно три точки поставить, то первый способ лучше. Если мне нужно открыть большое пустое черное окно терминала на весь экран, то один вызов XRenderFillRectangle лучше, чем передавать большой черный битмап 1920х1080. А если мне нужно отобразить фотографию, то лучше таки нарисовать ее битмапом.

И любой современный тулкит это знает, и использует тот способ, который более эффективен. Но автор вейланда решил, что это слишком сложно, надо сделать попроще, и оставить только один способ. :)

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

Да всё. Способов много именно для того, чтобы в каждом конкретном случае использовать наиболее эффективный. :)

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

Есть, кстати, еще одна интересная идея, в которой в ядро linux добавляется менеджер GEM-буферов, там можно будет реализовать композитор поверх API ядра безо всяких протоколов wayland

directfb ilixi compositor? Интеграция с твиттером, google maps вместе с навигатором, плеером, всякими графическими игрушками, и все это с аппаратным ускорением на ихнем видео выглядят неплохо.

anonymous
()

Live-дистрибутив для тестирования
RebeccablackOS
Rebecca Black

Ололо

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

Пока в сравнениях с другими оконными системами иксы сливаются!

В сравнении с какими и в чём сливаются?

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

Вопрос не в том чего я хочу, а в том - есть ли у нас варианты. Оно уже гоняется картинками. Увы.

В вейланде? Да, гоняется. Больше нигде.

И если бы меня, как разработчика, спросили - а можно ли на базе вяленда сделать удаленный протокол, сравнимый по эффективности с RDP - я бы сказал ДА.

На базе иксов — можно, и уже сделано, xpra например, или NX один из лучших. А на базе вейланда... Вот, как разработчик, скажи, как его сделать на базе вейланда? Откуда брать информацию о примитивах, о декорациях, вообще хоть о чем-нибудь? Я не вижу как там сделать что-то лучше чем тупое VNC со сжатием.

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

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

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

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

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

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

У меня примерно такие же ощущения - но нет ли каких нибудь конкретных подтверждений этому предположению?

kernel ★★☆
()

Зачем это всё когда есть widelands и wesnoth?

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

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

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

ВНЕЗАПНО! Qubes OS.

Qubes is an open source operating system designed to provide strong security for desktop computing. Qubes is based on Xen, X Window System, and Linux, and can run most Linux applications and utilize most of the Linux drivers.

Т.е. измененный гипервизор Xen, запускающий группы приложений в отдельных виртуальных машинах. Виртуальные машины на основе linux и что-то там сказано про WM поверх всего этого.

Я так понимаю, Wayland не решит ни одну проблему, которую решила Рутковская своей ОС.

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

а не судорожно искать, есть ли у нас где то в кеше такой же фрагмент, чтоб его не передавать

Никто судорожно ничего искать не будет.

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

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

То есть если внедриться в WM, мы получаем опять все снова здорово?

А условный «потенциально хакнутый фирефокс» — нет.

А условно хакнутый вейвленд? А как отличать хакнутый от нехакнутого?

С виндой давно дело имел?

Это не винда. Ты ж сам там выше говорил про selinux.

мне под каждое приложение, которое потенциально могут поиметь извне (браузер, мессенджер, торрент-клиент...) запускать отдельные иксы?

Хуже. Виртуальную машину. Тут ссылку внизу (по отношению к этому сообщению будет вверху) кинули на Quebec OS. Рутковская всяко не дура.

Про буфер ввода вывода лажанулся, конечно. Просто имелся в виду буфер обмена.

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

даже если все рисовать пиксмапами в иксах, это лучше

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

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

И если бы меня, как разработчика, спросили - а можно ли на базе вяленда сделать удаленный протокол, сравнимый по эффективности с RDP - я бы сказал ДА.

Мы уже убедились, что твоя упоротость не знает границ. Мог бы еще один раз и не подтвержать сей факт.

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

То есть если внедриться в WM, мы получаем опять все снова здорово?

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

Это не винда. Ты ж сам там выше говорил про selinux.

Лицоладонь.exe

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

А НАД ОКНАМИ ОН ЕГО НЕ ОБЕСПЕЧИВАЕТ.

Правильно. Это не винда. Это даже хуже, чем винда. В винде возможно открыть окно, ввод в которое невозможно подделать или прослушать. Запрос пароля UAC у семерке видел? Внезапно, это оно.

Про буфер ввода вывода лажанулся, конечно. Просто имелся в виду буфер обмена.

В буфере видно только то, что человек самостоятельно выделил/скопировал. Причин закрывать доступ к операциям с буфером нет. Однако даже и тут вся прелесть мандатного контроля в том, что если будут причины его закрыть, то можно закрыт и его.

Хуже. Виртуальную машину. Тут ссылку внизу (по отношению к этому сообщению будет вверху) кинули на Quebec OS. Рутковская всяко не дура.

А работает всё это в итоге один хрен на общих иксах? Бугага.

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

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

Только почему-то текущая реализация в несколько раз медлнеее иксов. :D

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

В винде возможно открыть окно, ввод в которое невозможно подделать или прослушать.

Чем gksudo хуже?

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

man xspy
man XQueryKeymap

При желании рубится selinux-ом уже фиг знает как давно... Только всем пофиг, потому что сначала для этого надо прицепиться к иксам, а значит запуститься от локального пользователя. А если левый код запустился от локального пользователя, то ему нафиг не нужны никакие пароли. Что он с ними делать будет, с паролями? Коллекционировать? У него есть локальный юзер, есть доступ в и-нет, можно рассылать спам, использовать машину для ботнета и т.д. Зачем нужны какие-то пароли?

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

И, кстати, это уже не имеет никакого отношения к PrintScreen-у.

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

Ты дурак или полный дурак? Вяленд командует top-level пиксмапами (окнами), в то время как для эффективной работы по сети надо управлять рисовать примитивами и глифами. Впрочем, вялендодрочеры походу неспособны это осознать.

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