Релиз Wayland 1.0 и Weston 1.0

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

Не только иксы, но ещё и другого юзера. Недоверенные приложения только так и можно пускать. Тут, рядом голосование идет, жаль, анонимусов туда не пускают, а то они бы рассказали, как правильно использовать юзеров. :)

В линуксах есть отличная многопользовательская система, которая просто создана для того, чтобы изолировать ресурсы друг от друга. Собираешь пакеты — делай это от отдельного юзера, тогда никакой rm -rf в Makefile не страшен. Нужно юзать какую-то подозрительную прогу — создается отдельный юзер, которому в файрволе отрезается интернет, затем делается под него switch user и юзается, и никакого риска. Отдельный юзер wine с отдельными префиксами под каждое приложение — это вообще обычное дело, которое даже winetricks из коробки позволяет. И т.д.

Не хочется делать switch user, хочется видеть окно перед своими глазами — тогда есть Xnest/Xephyr/Xvfb. Теоретически можно каждое приложение в своем Xnest-е запускать, но такие параноики мне пока не попадались.

Текущая реализация порта Qt на iOS гораздо медленнее возможной, её автор из Nokia сам об этом говорил и указывал, что именно можно улучшить, ведь он её сваял наспех в чисто исследовательских целях. А вообще после ваших слов появилось желание погонять Ребекку ;)

Вяленд командует top-level пиксмапами, а иксы дают возможность рисовать примитивами и глифами (вяленд вон тоже даёт возможность делать это посредством XWayland). А теперь, внимание, вопрос: иксы могут явно заставить программу использовать примитивы и глифы? Ну в indirect rendering для OpenGL я ещё могу поверить.

Тут, рядом голосование идет, жаль, анонимусов туда не пускают, а то они бы рассказали, как правильно использовать юзеров. :)

Расскажи прямо здесь. Мне это очень нужно.

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

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

glxgears — не бенчмарк.

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

В телефонной восьмёрке софт не может получить картинку рабочего стола емнип.

А теперь, внимание, вопрос: иксы могут явно заставить программу использовать примитивы и глифы?

Иксы дают возможность использовать примитивы и глифы. Разумные люди этим воспользуются, неразумные - нет. А вяленлд не оставляет вариантов, заставляя всех рисовать в глобальные пиксмапы.

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

Иксы дают возможность использовать примитивы и глифы. Разумные люди этим воспользуются, неразумные - нет. А вяленлд не оставляет вариантов, заставляя всех рисовать в глобальные пиксмапы.

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

Вот именно... Помню, я играл в warcraft3 ещё на диалапе - а вот на удалённых иксах в лучшем случае удастся запустить с незаметными задержками 1-2% самых нетребовательных утилит, а в худшем - вообще ничего. Тот же gtk3 с поддержкой вывода через HTML и то удобнее намного.

Я правильно понимаю, XWayland это реализация X11 протокола для Wayland, тоесть по сути еще один X сервер?

вяленд даёт возможность с помощью XWayland

хэВяленд к вяленду нимеет примерно такое же отношение, как Xming к Windows.

тоесть по сути еще один X сервер?

Именно

реализовать сетевую прозрачность ... на HTML

Да ты не просто укурен, ты эпически неизличимо укурен.

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

Спасибо, Кэп!

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

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

Хотя бы на HTML, который как минимум лучше иксов.

Наркоман?

где когда делаешь скрины привилегированных окон дырки

fixed

зато имеет отношение к ответу на твой вопрос.

не спорю.

Ты спросил, а есть ли вообще нечто под линуксом

Я бы даже сказал, что есть ли вообще нечто подобное. Выяснилось, что есть. И теперь выяснилось, что wayland не поможет, хотя там выше говорилось, что вот она - серебряная пуля.

Я правильно понимаю, XWayland это реализация X11 протокола для Wayland

И напоминает все это mac os x - карбон + иксы. Работало криво.

В телефонной восьмёрке

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

вяленд даёт возможность с помощью XWayland - шило на мыло в данном случае.

Поскольку шило уже есть, мыло идёт на ЙУХ.

Меня раздражает то, что Waylandо-филы не понимают одной простой вещи: чтобы заменить Х нужно быть лучше Х во всём.

Какой смысл менять работающую систему на ту, что местами несколько хуже? Чисто увеличения энтропии для?

В гугле забанили? Вникай: http://www.gotw.ca/gotw/023.htm .

Спасибо, только правильной ссылкой будет вот эта: http://www.gotw.ca/gotw/011.htm

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

Ну и в новом стандарте есть std::addressof.

вообще я такую штуку пилю для wayland - чтоб не было скриншотов процессов куда нет доступа

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

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

Однако на том уровне, на котором ты ее пытаешься решить, это практически невозможно. Для этого есть другие, более низкие уровни и более приспособленная система прав.

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

Запрос пароля UAC у семерке видел? Внезапно, это оно.

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

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

В буфере видно только то, что программа, якобы от лица человека, туда занесла. Это не значит, что нельзя туда занести что-нибудь еще.

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

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

Если честно, я мозг сломал, пока читал, как оно работает. Я так понимаю, есть виртуалка-хост без выхода куда-либо, в которой открываются другие виртуалки-гости. В одних сетевая подсистема работает, в других оконная, в третьих-n-дцатых сами программы. Как я понимаю, в неких embedded-окнах.

Рекомендую попробовать это взломать.

иксы могут явно заставить программу использовать примитивы и глифы?

Нет, но ты считаешь, что, скажем, GTK рисует окно целиком и отдаёт его в таком виде X-серверу или что?

Расскажи прямо здесь.

Все программы, которые торчат в и-нет, работают в чруте от отдельного юзера, напимер ftp и mldonkey. Было желание поставить также и rtorrent, но лень его ставить и настраивать.

Для любых слабо-доверенных действий есть отдельные юзеры. Отдельный юзер для сборки пакетов, отрезанный в файрволе от сети (--uid-owner builduser -j DROP). Очевидно, есть отдельный юзер вайн, которому доступ в и-нет разрешен только на определенные адреса (например, для онлайн-игрушек это сервер игрушки), и любые соединения которого протоколируются (в файрволе и в логе transparent proxy, чтобы видеть, что и откуда оно качало). Также есть несколько отдельных тестовых юзеров, например, чтобы google earth потестить, или teamviewer запустить.

Есть еще пара специализированных юзеров, вроде rtmpdump, созданных не для безопасности, а просто потому, что так было проще. root, как юзер, не используется, вместо него — sudo.

Для взаимодействия со всем этим безобразием основной юзер добавлен в группы урезанных юзеров, чтобы можно было просто копировать файлы. Плюс настроен sudo для простого запуска команд от урезанных юзеров. А серия дополнительных скриптов автоматизирует наиболее частые операции, например, `wine-create newgame` автоматически создаст и настроит новый префикс newgame, а `wine-run newgame c:\\setup.exe` запустит setup.exe от юзера wine из префикса newgame.

Может быть, есть и что-то еще. Все это было сделано очень давно по принципу «настроил и забыл», поэтому, возможно, что-то и забылось.

Мне это очень нужно.

Очень нужно? Мне даже любопытно, а зачем?

Они показывают, насколько быстро данная конфигурация крутит шестерёнки.

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

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

Часто? Прямо так уж и часто? А можно несколько «частых» примеров? Желательно таких, где не забыли применить мозг при анализе результатов.

А сравнение разных вендоров — вообще мрак. glxgears — не бенчмарк.

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

вообще я такую штуку пилю для wayland - чтоб не было скриншотов процессов куда нет доступа

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

Не, я понимаю, это прикольно, но зачем? Для решения какой проблемы/задачи планируется использовать данную фичу? Или это просто PoC, не предназначенный для реальных юзеров?

Во-первых, в данном случае все сравнивалось на одной машине

Не имеет большого значения. glxgears - НЕ бенчмарк. Оно использует очень маленький подсет OpenGL, так что на роль попугая не годится никак. Оно может скакать даже в случае минорного изменения любого компонента связки железо-dri_driver-x_driver-x-mesa. А ты вялым всю связку сверхмажорными изменениями корёжишь.

P.S. Тьфу-тьфу, это не стоит считать оправданием тормознутости вяленого, просто немного матчасти по шестерёнкам.

Вяленд командует top-level пиксмапами, а иксы дают возможность рисовать примитивами и глифами (вяленд вон тоже даёт возможность делать это посредством XWayland).

Не, xwayland за «возможность» не считается. Xwayland — это временная штука, для обратной совместимости, которую в будущем планируют убрать.

Eсли рассматривать wayland+xwayland (точнее, xwayapp, или как оно там называется), то в сумме это те же самые иксы, только толще и медленнее. И тогда возникает логичный вопрос — а зачем было разрабатывать wayland, если он будет бесполезной примочкой к иксам?

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

Вот этот момент я не понял.

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

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

Предполагается, видимо, что сам пользователь имеет доступ rw к этой учётке. Т.е. зайдя под kindlycat вы можете писать и читать в /home/internet. А вот пользователь internet писать в /home/kindlycat не может.

Поэтому то, что нужно залить в сеть, сперва копируется в /home/internet, потом заливается. А то, что скачивается, после скачки нужно забрать из /home/internet/Downloads.

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

Ага, теперь вырисовывается.

Все программы, которые торчат в и-нет, работают в чруте от отдельного юзера, напимер ftp и mldonkey. Было желание поставить также и rtorrent, но лень его ставить и настраивать.

Это хорошо, но уж больно геморройно, не для белого человека. :-(

Предполагается, видимо, что сам пользователь имеет доступ rw к этой учётке. Т.е. зайдя под kindlycat вы можете писать и читать в /home/internet. А вот пользователь internet писать в /home/kindlycat не может.

У белых людей это делается по-другому: браузеру разрешается читать-писать ~/.config/<своя_директория> и ~/Downloads в SELinux/TOMOYO/AppArmor. Всё. Никаких отдельных пользователей, чехарды с правами, симлинков, sudo, suid'ов.

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

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

Программа, которая хочет чего-то там отобразить, должна:

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

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

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

История «победителя» может послужить прекрасным наглядным примером:

There are three very different libraries name Xft. The original 1.0 Xft library shipped with XFree86 4.0.2 and included a private configuration mechanism via the XftConfig file. For X servers without the Render extension, Xft 1.0 used core X fonts instead of client-side fonts. This was supposed to allow applications to code to a common API and run with all X servers.

Early in the deployment of Xft 1.0, it became abundantly clear that another custom X-specific font configuration mechanism was a really bad idea. Both KDE and Pango ended up stealing pieces of Xft to configure fonts. KDE created a GUI Xft configuration tool by stealing the XftConfig parsing code, Pango stole most of Xft so that the XftConfig file could be shared between the Xft and FreeType2 backends. Fontconfig was designed to solve both of these problems. The other problem in Xft 1.0 was the use of core X fonts when the server wasn't blessed with the Render extension. This meant that applications couldn't count on client-side fonts when using the high-level Xft APIs. As client-side fonts provide significant value beyond anti-aliased glyphs, it again became obvious that this design was flawed.

The Xft 1.0 API abstracted configuration details sufficient to permit a binary compatible version, Xft 1.1, to be developed which replaces the XftConfig configuration file with calls in to the Fontconfig library. Unfortunately, the Xft 1.0 API didn't sufficiently hide the rendering details making it impossible to provide for client-side fonts in servers without the Render extension. This means that Xft 1.1 shares font configuration, but isn't really usable on servers without Render.

The current version of Xft (2.0) provides a client-side font API for X applications. It uses FontConfig to select fonts and the X protocol for rendering them. When available, Xft uses the Render extension to accelerate text drawing. When Render is not available, Xft uses the core protocol to draw client-side glyphs. This provides completely compatible support of client-side fonts for all X servers. Drawing anti-aliased text with the core protocol involves fetching pixels from the destination, merging in the glyphs and shipping them back.

OpenGL'ные приложения работают в обоход иксов.

Wayland предлагает честную memory-модель доступа к формированию конечного изображения. Запрашиваешь себе буфер, рисуешь там, всё, что хочешь, даешь вейланду команду, что буфер готов к отображению. Чё и как ты там нарисовал - твои личные проблемы. Эта модель удобна тем, что легко совместима с GL/3D, что практически позволяет использовать один и тот же драйвер для GUI и 3D, как это делают сейчас последние версии венды и оэсыкса, и такая совместимость является одной из целей Wayland.

Все программы, которые торчат в и-нет, работают в чруте от отдельного юзера, напимер ftp и mldonkey. Было желание поставить также и rtorrent, но лень его ставить и настраивать.

Это хорошо, но уж больно геморройно, не для белого человека. :-(

Когда-то давно, лет пять назад, не меньше, это было геморройно, но было и интересно, испытание для собственных знаний.

К счастью, настолько серьезно защищать нужно только то, что торчит в сеть, и к чему могут прицепиться снаружи. Таких программ всего несколько штук, и один раз для них это вполне можно сделать. А с тех пор оно просто работает. Потому это и называется «настроил и забыл». :)

Эта схема приводит к некислому гемору в разработке клиентского софта

И точно такую же схему строит сейчас себе wayland. Не вижу разницы, кроме формата протокола. Те же расширения, тот же механизм версий. Даже транспорт используется тот же самый — сокеты. То же самое в убогом урезанном варианте.

OpenGL'ные приложения работают в обоход иксов.

Ну да, конечно, и как же тогда glxgears работает по ssh -X? Блин, да даже компиз, помнится, по ssh работал. :)

Wayland предлагает честную memory-модель [...] Запрашиваешь себе буфер, рисуешь там, всё, что хочешь, даешь вейланду команду, что буфер готов к отображению

Буфер где? В памяти? А как он передается вейланду? Через Shm? Тогда мы получаем многократную потерю производительности, либо невозможность аппаратного ускорения отрисовки.

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

Эта модель удобна тем, что легко совместима с GL/3D

Эта модель жутко усложняет написание программ. Придется выбирать — либо работать медленно, через shm, но зато где угодно, либо быстро, напрямую с видеокартой, но только на ограниченном наборе конфигураций. Либо реализовывать у себя оба метода. Очень удобная модель.

И точно такую же схему строит сейчас себе wayland. Не вижу разницы, кроме формата протокола.

Нет, не такую. Weston реализует один слой API - работа с буферами (ввод/вывод, «заголовки» поверхностей и др - побочные эффекты). Всю остальную работу теоретически и по-умному могут делать другие модули. Может быть и запись напрямую в системную память, а может и вызов {X,Y,Z}Render'овских {X,Y,Z}PutPixel и {X,Y,Z}FillRectangle.

Буфер где? В памяти? ... Или буфер карты в видеопамяти?

Зависит от реализации, и в идеале определяется конкретной _реализицией_ wayland'а. Разумеется, реализация в видеопамяти - в первую очередь.

как же тогда glxgears работает по ssh -X?

Вот так:

user@host:~$ export LIBGL_ALWAYS_INDIRECT=y
user@host:~$ glxgears

Эта модель жутко усложняет написание программ. Придется выбирать — либо работать медленно, через shm, но зато где угодно, либо быстро, напрямую с видеокартой, но только на ограниченном наборе конфигураций. Либо реализовывать у себя оба метода.

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

И еще пользователем придётся выбирать - Nvidia, AMD/ATI или Intel. ))

Очень удобная модель.

Да, для разработчиков {K, g}Calculator'ов и {K,g}Editor'ов, которые, в идеале, вообще не должны знать, через что идёт отрисовка, а работать через какие-нибудь Qt/GTK, которые будут работать через что-нибудь похожее (если не именно с) Pango/Cairo, которое в свою очередь может работать через EGL/GLES2.

Теоретически, задача wayland'а - дать самый нижний уровень работы с графикой, общий для всех реальных реализаций - хоть средствами видеочипа в видеопамяти, хоть отрисовкой по сети. Место, куда драйверописатели могут приткнуть всю работу с графикой, не связываясь со всей иксовой тряхомундией. Реальная же отрисовка - это задача уже другого уровня API.

нет, это легковесная замена DRM для современных видеокарт.

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

В винде есть API, который можно эффективно транслировать через RDP.

В линуксе есть только говнотулкиты.

И игры тут ни при чем.

Нет, не такую. Weston реализует один слой API[...] Всю остальную работу теоретически и по-умному могут делать другие модули.

Какие модули? Где у weston-а модули? Если его надо патчить, чтобы модули у него появились, то это — не модули. :)

Зависит от реализации, и в идеале определяется конкретной _реализицией_ wayland'а.

Это в идеале. А на практике это не так. В протоколе это — разные вызовы. То есть это действительно зависит от реализации, но от реализации программы, а не от реализации wayland-а.

Только, если ты - норкоман, решивший самостоятельно запилить весь графический стек

Простите, а для кого тогда написание программ стало проще? Для тулкитовцев стало сложнее. Для тех, кто пишет на низком уровне, стало сложнее. Для тех, кто юзает стандартные тулкиты тоже стало сложее (им теперь приходится думать о декорациях и языках). Кому тогда стало проще?

Да, для разработчиков {K, g}Calculator'ов и {K,g}Editor'ов [...] через какие-нибудь Qt/GTK

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

Кстати, про калькулятор, видел livecd с вейландом? Видел там calculator, открывал? И как его закрыть?

Теоретически, задача wayland'а - дать самый нижний уровень работы с графикой, общий для всех реальных реализаций

С этой задачей отлично справлялись иксы. У них действительно есть полный набор функций, позволяющий использовать преимущества отдельных реализаций, но не зависящий от них. Поэтому иксы могут работать на чем угодно, начиная от мобилок и книгочиталок с черно-белым epaper-экраном, и заканчивая десктопом с 24 современными мониторами. А в вейланде независимых от реализации «уровней» не видно...

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

Причем тут драйверописатели? Это в иксах можно писать драйвера графики, причем делать это можно именно «не связываясь со всей иксовой тряхомундией». И кучи написанных драйверов это, как бы, подтверждают. А куда воткнуть драйвер в вейланде? Пропатчить weston? Типа, отдельный форк вестона для ATI, еще один для Nvidia, еще один для Intel? ;)

нет, это легковесная замена DRM для современных видеокарт.

Интересно... А какова конечная цель? Для чего это планируется использовать?

И, кстати, почему именно для wayland? Почему не directfb, например. Хотя, наверное, проще всего сделать это в виде композитного WM в иксах... Вон, чтобы WM написать, достаточно 50 строк на си. :) Композитный оконный менеджер, правда, побольше будет, около 2000 строк, но это и не семпл, возможностей у него побольше.

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

«Именно так» — это как? Все рендерится софтварно через shm, а directx — это все сказки? Или, может, там тоже не поддерживается работа с несколькими мониторами? :)

Хотя в чем-то правильно, никаких отдельных WM-ов и декораторов там нет, это издавна было киллер-фичей только у линуксов, видимо, пришла пора устранить конкурента... Так вот оно в чем дело, вейланд — это замаскированная попытка макрософта уничтожить линукс, скатив его в гавно!

Какие модули? Где у weston-а модули?
...
В протоколе это — разные вызовы. То есть это действительно зависит от реализации, но от реализации программы, а не от реализации wayland-а.

В первую очередь - от реализации конкретной графической системы. От программы ровно в той степени, в которой она с этой системой умеет работать. Мне лень много печатать, так что:

2.2. Wayland Rendering
 One of the details I left out in the above overview is how clients actually render under wayland. By removing the X server from the picture we also removed the mechanism by which X clients typically render. But there's another mechanism that we're already using with DRI2 under X: direct rendering. With direct rendering, the client and the server share a video memory buffer. The client links to a rendering library such as OpenGL that knows how to program the hardware and renders directly into the buffer. The compositor in turn can take the buffer and use it as a texture when it composites the desktop. After the initial setup, the client only needs to tell the compositor which buffer to use and when and where it has rendered new content into it.

Typically, hardware enabling includes modesetting/display and EGL/GLES2. On top of that Wayland needs a way to share buffers efficiently between processes. There are two sides to that, the client side and the server side. 
 On the client side we've defined a Wayland EGL platform. In the EGL model, that consists of the native types (EGLNativeDisplayType, EGLNativeWindowType and EGLNativePixmapType) and a way to create those types. In other words, it's the glue code that binds the EGL stack and its buffer sharing mechanism to the generic Wayland API. The EGL stack is expected to provide an implementation of the Wayland EGL platform. The full API is in the wayland-egl.h header. The open source implementation in the mesa EGL stack is in wayland-egl.c and platform_wayland.c. 
 Under the hood, the EGL stack is expected to define a vendor-specific protocol extension that lets the client side EGL stack communicate buffer details with the compositor in order to share buffers. The point of the wayland-egl.h API is to abstract that away and just let the client create an EGLSurface for a Wayland surface and start rendering. The open source stack uses the drm Wayland extension, which lets the client discover the drm device to use and authenticate and then share drm (GEM) buffers with the compositor. 
 The server side of Wayland is the compositor and core UX for the vertical, typically integrating task switcher, app launcher, lock screen in one monolithic application. The server runs on top of a modesetting API (kernel modesetting, OpenWF Display or similar) and composites the final UI using a mix of EGL/GLES2 compositor and hardware overlays if available. Enabling modesetting, EGL/GLES2 and overlays is something that should be part of standard hardware bringup. The extra requirement for Wayland enabling is the EGL_WL_bind_wayland_display extension that lets the compositor create an EGLImage from a generic Wayland shared buffer. It's similar to the EGL_KHR_image_pixmap extension to create an EGLImage from an X pixmap. 
 The extension has a setup step where you have to bind the EGL display to a Wayland display. Then as the compositor receives generic Wayland buffers from the clients (typically when the client calls eglSwapBuffers), it will be able to pass the struct wl_buffer pointer to eglCreateImageKHR as the EGLClientBuffer argument and with EGL_WAYLAND_BUFFER_WL as the target. This will create an EGLImage, which can then be used by the compositor as a texture or passed to the modesetting code to use as an overlay plane. Again, this is implemented by the vendor specific protocol extension, which on the server side will receive the driver specific details about the shared buffer and turn that into an EGL image when the user calls eglCreateImageKHR.

Простите, а для кого тогда написание программ стало проще?

Пока еще не стало. Но если довести задачу до конца, то станет - каждый будет делать свою часть работы.

Для тех, кто юзает стандартные тулкиты тоже стало сложее (им теперь приходится думать о декорациях и языках).

Им не надо, это не их задача. Это - задача оконной системы, которой по-факту сейчас еще нет даже в проекте.

Теоретически, задача wayland'а - дать самый нижний уровень работы с графикой, общий для всех реальных реализаций

С этой задачей отлично справлялись иксы.

Я уже говорил, как «отлично» иксы с ней справлялись.

Кстати, про калькулятор, видел livecd с вейландом? Видел там calculator, открывал? И как его закрыть?

Ты, походу, не врубаешься, что weston 1.0 - это PoC wayland 1.0. Это пока еще ни разу не рабочее решение.

2.2. Wayland Rendering
[...]
With direct rendering, the client and the server share a video memory buffer.
[...]
The server side of Wayland is the compositor and core UX for the vertical, typically integrating task switcher, app launcher, lock screen in one monolithic application.
[...]

Эта длинная цитата только подтверждает мои слова. Никаких модулей, одно монолитное приложение, возможно даже использующее драйвер-специфичные функции, т.е. таки получаем отдельные форки вестона для nvidia, ati/amd, intel, etc.

Пока еще не стало. Но если довести задачу до конца, то станет - каждый будет делать свою часть работы.

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

Им не надо, это не их задача. Это - задача оконной системы, которой по-факту сейчас еще нет даже в проекте.

Есть. По плану weston — это и есть оконная система «task switcher, app launcher, lock screen in one monolithic application».

Я уже говорил, как «отлично» иксы с ней справлялись.

А по ссылке опять подтверждение моим словам. Развивались шрифты и вместе с ними развивались иксы, совершенствуя общий для всех уровень работы. Старое решение (x core fonts) стало неудобным (поддерживались только растровые шрифты, для обновления шрифта нужно было перезапускать иксы). Для решения проблемы перезапуска сначала был создан отдельный сервер шрифтов (он назывался xfs, и его перезапустить было проще, а иксы брали шрифты у него). Но с появлением и распространением векторных шрифтов (сначала однобайтовых Type1, а позже юникодных TrueType) старый подход был заменен на более современный. Если через 2 года придумают какие-нибудь фрактальные шрифты, то выйдет и третья версия библиотеки.

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

Ты, походу, не врубаешься, что weston 1.0 - это PoC wayland 1.0. Это пока еще ни разу не рабочее решение.

Нее... 1.0 — это официально заявленный стабильный релиз. PoC был четыре года назад.

Никаких модулей, одно монолитное приложение, возможно даже использующее драйвер-специфичные функции,

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

Развивались шрифты и вместе с ними развивались иксы,

А ну-ка найди мне выше по ссылке 1) развитие шрифтов и 2 развитие иксов.

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

Эти фантазии ничего общего не имеют с тем, что было на самом деле. Кончай бредить, я и так уже с трудом сколняюсь отвечать тебе.

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

Иди выше и прочти историю троекратного переписывания интерфейса фритайп библиотеки еще раз.

Нее... 1.0 — это официально заявленный стабильный релиз.

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