wayland как замена Х-ов.

DE для тачскрина в 2018 (комментарий)

А что слышно про KDE + Nvidia? Когда будет работать под Wayland?

посмотри в новостях вроде в прошлом месяце пробегало что «уже можно потестить»

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

Как-то так.

ну, тоже вариант. копроративные войнушки никто не отменял.

тем и жив опенсорц, что есть вечное стремление к совершенству :)

А эта «практика», которая «неоднократно показала» — где-то кроме твоего сознания существует?

В объективной реальности.

Ни о чем. Это просто LD_PRELOAD. Мне, пожалуйста, из одного приложения перехватывать ввод других — как я это могу делать в X.

Что мешает это сделать в вяленом? Он способен изолировать только общение в пределах композитора.

Да, ты как всегда.

У тебя по Фрейду проблемы пошли уже.

А есть другие реализации иксов для Linux? XFree86 окуклился, не предлагать.

Ты в своём репертуаре: подмена понятий и отметание других вариантов в угоду подтверждения твоего лживого и никчёмного мнения. Если что, даже на Qt был X-сервер.

Спорь дальше сам с собой.

Слив засчитан.

А эта «практика», которая «неоднократно показала» — где-то кроме твоего сознания существует?

В объективной реальности.

Нет такой практики в объективной реальности.

Хороший пример — Android. По-умолчанию приложению запрещено все. Кому-нибудь мешает тот факт, что приложение один раз за свое существование спросит о том, можно ли ему читать СМС? Нет, не мешает.

Что мешает это сделать в вяленом?

Так сделай. Мне интересно посмотреть на proof-of-concept от тебя. Если ты с такой уверенностью об этом говоришь — для тебя проблемы это не должно составить.

аналог xdotool, стандартно работающий на Wayland protocols, уже завезли?

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

Но из-за того, что протокол существенно проще, система в целом забухнёт (как будет антоним слова «разбухает»? ;-)) обратно, когда тулкитам не придётся тащить на себе совместимость одновременно с W и X протоколами.

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

А ты не понимаешь, что это реакция такая на гномосеков, которые везде пытаются гном-парад устроить?

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

Забудьте вы про прозрачность. Она в wayland-е такая же как в иксах. Иксы для передачи сообщений используют сокеты, wayland для передачи сообщений использует... сокеты! И в иксах и в вейланде проброс этих сокетов делается абсолютно одинаково.

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

А я вангую обращение к теме Леннарта Поттеринга, который наконец-то найдёт в wayland фатальный недостаток и быстренько запилит systemd.graphicsserver.

Для Лёни это уже слишком мелочно. Будет графическая система graphicsd для ОС SJW/Poetterix прямо в загрузчике.

Это у тебя на нвидии работает что ли?

Нет такой практики в объективной реальности.

А как же wayland? Яркий пример «запретить всё, а потом поиметь от этого проблем».

Хороший пример — Android. По-умолчанию приложению запрещено все.

Android тут не к месту. Приложению по умолчанию не запрещено всё и вся. Да и никакого умолчания там нет в принципе - для каждого приложения там изначально прописаны права. Если с каким-то пунктом не соглашается пользователь, то ему придётся отказаться от приложения совсем. В Cyanogenmod и LineageOS поступили иначе. Именно туда и встроили механизмы изоляции приложений, но по умолчанию приложениям всё равно разрешено всё.

Так сделай. Мне интересно посмотреть на proof-of-concept от тебя. Если ты с такой уверенностью об этом говоришь — для тебя проблемы это не должно составить.

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

встроили механизмы изоляции приложений

по умолчанию приложениям всё равно разрешено всё

Уровень логики — Quasar.

Не сделаю, так как вяленый мне не нужен.

Не сделаешь, потому что ты только на словах Д’Артаньян, а на деле — …

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

Уровень логики — Quasar.

Ты вообще читаешь, что я пишу?

Не сделаешь, потому что ты только на словах Д’Артаньян, а на деле — …

Понятно. Не читаешь.

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

А ещё ты игнорируешь тему обсуждения.

Где proof-of-concept, товарищ кло^Wэксперт?

Ты вообще читаешь, что я пишу?

Да, и уровень твоей некомпетентности каждый раз меня поражает.

Где proof-of-concept, товарищ кло^Wэксперт?

Я уже кинул proof-of-concept того, что вяленый не защищает от кейлоггеров. Приложению для вяленого ничто не мешает такие штуки вытворять вне взаимодействия с композитором.

Да, и уровень твоей некомпетентности каждый раз меня поражает.

Пока я вижу, что ты не понимаешь, о чём речь. И после этого ещё что-то про некомпетентность пишешь.

Я уже кинул proof-of-concept того, что вяленый не защищает от кейлоггеров.

Нет, никаких пруфов не было. LD_PRELOAD к обсуждаемому вопросу не имеет никакого отношения.

Так что все еще жду proof-of-concept.

Пусть и уверен, что ничего от тебя не дождусь, потому что ты просто не умеешь.

Нет, никаких пруфов не было. LD_PRELOAD к обсуждаемому вопросу не имеет никакого отношения.

Как вяленый от этого защищает?

Так что все еще жду proof-of-concept.

Ты читать вообще умеешь?

Similar techniques would also work on Windows and Mac, and essentially any platform that doesn't sandbox applications.

У меня такой эффект и в иксах был, но я не помню, что именно надо настроить в smplayer, чтобы его избежать. Это не баг Wayland, это какая-то настройка.

Нет, никаких пруфов не было. LD_PRELOAD к обсуждаемому вопросу не имеет никакого отношения.

Как вяленый от этого защищает?

Это вообще не относится ни к Wayland, ни к X. Я с таким же успехом могу сделать PTRACE_ATTACH, но к обсуждаемому вопросу это тоже не будет иметь никакого отношения.

Так что либо давай нормальный proof-of-concept, либо больше о тематике не говори.

Ты не понял, что тебе написали

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

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

Нет, родной. Система разбухает — это система разбухает, а не процессор захлёбывается или там, память кончается. Почему-то ни hobbit ни Shadow не пишут мне, что я их неправильно понял. Нет, мы прекрасно обсуждаем потребление дисковых ресурсов, и только квазар приходит из параллельной реальности и срывает покровы при помощи своего астрала и тонкого чувства слова (называется — «как хочу — так и чувствую»).

Я уже кинул proof-of-concept того, что вяленый не защищает от кейлоггеров. Приложению для вяленого ничто не мешает такие штуки вытворять вне взаимодействия с композитором.

Логика уровень Квазар ©

Вяленый и от руткитов не защищает, и от скомпрометированных модулей ядра тоже. А уж от MITM так вообще никак. Дрянная, негодная технология.

Это вообще не относится ни к Wayland, ни к X.

Это имеет прямое отношение, так как в вяленом заявлена безопасность, которая оказывается пшиком и борьбой с ветряными мельницами.

Я с таким же успехом могу сделать PTRACE_ATTACH, но к обсуждаемому вопросу это тоже не будет иметь никакого отношения.

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

Так что либо давай нормальный proof-of-concept

Уже привёл ссылку.

либо больше о тематике не говори.

Нет.

Нет, родной. Система разбухает — это система разбухает, а не процессор захлёбывается или там, память кончается.

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

Почему-то ни hobbit ни Shadow не пишут мне, что я их неправильно понял.

Потому, что они тебе своим путём пытаются втолковать разъяснения о том, что ты неправ.

Логика уровень Квазар ©

Вообще-то Аристотель её создал.

Вяленый и от руткитов не защищает, и от скомпрометированных модулей ядра тоже. А уж от MITM так вообще никак. Дрянная, негодная технология.

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

Вот именно.

Всем спасибо, все свободны.

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

Короче. Если выбрать движок Wayland, или OpenGL то будет эффект, как у тебя. Если выбрать движок XV, то будет всё ОК.

С движком всё логично — само приложение работает через XWayland, и когда ты просишь от mpv работать через Wayland или через opengl, mpv создаёт новую поверхность. При работе через XV mpv работает в том же окне, что и интерфейс.

Это имеет прямое отношение, так как в вяленом заявлена безопасность, которая оказывается пшиком и борьбой с ветряными мельницами.

В Wayland заявлена безопасность в контексте того, чем Wayland занимается.

В этом же контексте X был решетом.

Уже привёл ссылку.

Нет, не было никакого proof-of-concept.

Так что PoC or GTFO.

Уж коль пошла такая пьянка, то может кто-нибудь прояснит концептуально, как это все работает?

До сего дня я думал, что wayland - это некий программный компонент (определить точнее, что это, я пока затрудняюсь), который для каждого приложения (окна приложения) выделяет ассоциированный с окном буфер в памяти (видеопамяти?). Приложение с этим буфером работает напрямую, рисует там что хочет и как хочет, используя свой тулкит. При этом имеется композитор, который то, что нарисовано приложением в своем буфере, переносит (со всякими полупрозрачностями и прочими свистоперделками) уже в реальную область видеопамяти, отображающую окно.

Таки возникает некоторое количество вопросов.

1. Одни пишут, что wayland это дисплейниый сервер, другие, что нет. А как на самом деле? Ну даже, если у приложений с wayland общение идет посредством IPC (неважно какого), то в своем буфере то приложение все равно рисует напрямую (пусть даже через OpenGL и пр.). Получаются какие-то сапоги всмятку. Тут играем, тут не играем, тут рыбу заворачивали.

2. Как композитор переносит буфер приложения в окно в видеобуфере? Получается он N раз в секунду, определят, какие окна отображены, и копирует туда изображение? Или все как-то сложнее делается?

3. Помнится разработчики wayland ругали X за двойную буферизацию, дескать тормозит она графику. Но у wayland получается двойная буферизация - это основополагающая концепция? Или может приложение рисует прямо непосредственно в видеопамяти, а композитор каким-то волшебным образом задает на аппаратном уровне параметры отображения (не представляю как это можно сделать без связки с приложением).

4. Может кто-то пояснит, как к этому всему может быть прикручено аппаратное ускорение? Как то не могу это представить, кроме тривиальных случаев декодирования вило потока.

В Wayland заявлена безопасность в контексте того, чем Wayland занимается.

И выше выяснилось, что это нифига не лучше того, что уже есть для иксов.

В этом же контексте X был решетом.

См. выше.

Нет, не было никакого proof-of-concept.

Ну-ну. «PoC не PoC. Ссылки не ссылки.»

1. Одни пишут, что wayland это дисплейниый сервер, другие, что нет. А как на самом деле? Ну даже, если у приложений с wayland общение идет посредством IPC (неважно какого), то в своем буфере то приложение все равно рисует напрямую (пусть даже через OpenGL и пр.). Получаются какие-то сапоги всмятку. Тут играем, тут не играем, тут рыбу заворачивали.

Wayland - это набор протоколов для взаимодействия с композитором. Композитор берёт на себя функции WM и дисплейного сервера, абстрагируя приложение от железа подобно X-серверу.

2. Как композитор переносит буфер приложения в окно в видеобуфере? Получается он N раз в секунду, определят, какие окна отображены, и копирует туда изображение? Или все как-то сложнее делается?

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

3. Помнится разработчики wayland ругали X за двойную буферизацию, дескать тормозит она графику. Но у wayland получается двойная буферизация - это основополагающая концепция? Или может приложение рисует прямо непосредственно в видеопамяти, а композитор каким-то волшебным образом задает на аппаратном уровне параметры отображения (не представляю как это можно сделать без связки с приложением).

Разработчики вяленого ругали X11 за все его преимущества (например, за сетевую прозрачность) и за то, что они не понимают код X.org (одна из множества реализаций, хоть и самая крупная и известная). Для иксов отрисовку можно делать также композитором, что на практике и бывает - для этого в X.org специальную поддержку даже делали. Но это уже техническая сторона того, как рисовать.

4. Может кто-то пояснит, как к этому всему может быть прикручено аппаратное ускорение? Как то не могу это представить, кроме тривиальных случаев декодирования вило потока.

Опять же - это вопрос вывода изображения на конкретном железе. Если говорить про практическую составляющую, то в том же X.org аппаратное ускорение графики делается через direct rendering. Это самый эффективный способ на данный момент. Сама по себе реализация вывода графики может быть какой угодно. Можно сделать так, чтобы был X-сервер, выводящий графику исключительно через OpenGL. Есть такие реализации, которые выводят графику на Java, и даже на JS. Все эти страдания с тирингом это тоже вопрос реализации вывода графики, а не протокола.

Итого все обсуждения wayland vs X11 сводятся к киданию какашками. А всё потому, что сторонники вяленого делают на эмоциональную, а не на техническую сторону, и поэтому очень часто смешивают понятия графического сервера и протокола воедино, трактуя всё так, как им удобно. За примерами далеко ходить не надо - всё в этой теме повторилось.

И выше выяснилось, что это нифига не лучше того, что уже есть для иксов

Не выяснилось.

Ну-ну. «PoC не PoC. Ссылки не ссылки.»

Там нет вообще никакого PoC, который бы имел отношение к вопросу.

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

Так что без proof-of-concept ты продолжаешь оставаться типичным Quasar’ом со свойственным тебе бредом.

Wayland - это набор протоколов для взаимодействия с композитором. Композитор берёт на себя функции WM и дисплейного сервера, абстрагируя приложение от железа подобно X-серверу.

То, что вы сейчас описали практически ничем не отличается от X-ов (кроме того, что в X-ах wm это отдельный компонент). Ради чего тогда все это затевалось?

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

Но это же бред. Получается, что нынешние разработчики wayland в попытках усовершенствовать X-и, не осилили разобраться в них (это даже моно принять как аргумент) и решили одни большие и сложные X-ы заменить на 10-ок хреней чуть попроще и поменьше?

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

Минуточку, но «как рисовать» это же вроде бы был один из принципиальных вопросов. Нам же уже плешь проели недостатками X-ов. X-ы могут рисовать сами, т.е. именно в протоколе заложены механизмы непосредственно рисования в окнах. Они «признаны» устаревшими и медленными, но зато дают сетевую прозрачность. Есть механизмы непосредственного рисования через GPU (dri и пр.). Такие механизмы быстры, но, насколько я понял лишены сетевой прозрачности (поправьте, если ошибаюсь). Насколько я помню, зачинатели wayland на то и упирали, что дескать зачем тащить старые и медленные механизмы отрисовки в светлое будущее. Надо типа дать каждому приложению возможность напрямую работать с драйвером аппаратного 3д - и тогда наступит счастье. То есть получается приложение напрямую рисует в окно, а композитор вообще сам по себе. Если между ними и есть связь, то она какая-то побочная. А иначе получается, что меняется даже не шило на мыло, а шило на другое шило.

Не выяснилось.

Читать научись.

Там нет вообще никакого PoC, который бы имел отношение к вопросу.

Есть. См. изначальный вопрос.

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

Ты не видишь разницу между ядерным руткитом и возможностью сделать что-то непривелигированным пользователем?

Так что без proof-of-concept ты продолжаешь оставаться типичным Quasar’ом со свойственным тебе бредом.

Практика показала, что бред свойственен как раз тебе. Ты пошёл лепить отговорки в стиле «PoC не PoC. Ссылки не ссылки.».

То, что вы сейчас описали практически ничем не отличается от X-ов (кроме того, что в X-ах wm это отдельный компонент). Ради чего тогда все это затевалось?

На самом деле сильно отличается. В иксах есть клиент, а есть сервер. Сервер отвечает только за абстрагирование клиента от железа, поэтому в иксах реализована полная сетевая прозрачность. У вяленого же всё свалено в одну кучу как попало.

Но это же бред. Получается, что нынешние разработчики wayland в попытках усовершенствовать X-и, не осилили разобраться в них (это даже моно принять как аргумент) и решили одни большие и сложные X-ы заменить на 10-ок хреней чуть попроще и поменьше?

Да - это бред. Двое из разработчиков раньше в проекте X.org участвовали, но потом вышли из него, обосрали код, обосрали протокол X11 даже не за реальные проблемы, и пошли пилить вяленого, до сих пор за 10 лет недопилив. Daniel Stone, например, занимался xinput, а потом обосрал свой же код (умолчав об этом) и начал везде визжать, что напишет правильную подсистему ввода (что мешало ему раньше это сделать, если xinput новый с нуля делался, а не древнющим кодом оказался?).

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

Протокол X11 не определяет, как общаться с железом. Он определяет взаимодействие X-клиента с X-сервером. Как рисовать - это вопрос реализации конкретного X-сервера. На Windows, например, организация вывода графики отличается от линукса, поэтому и X-сервер там иначе картинку рисует.

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

В протоколе описаны команды для отрисовки. Они абстрагированы от железа.

Они «признаны» устаревшими и медленными, но зато дают сетевую прозрачность.

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

Есть механизмы непосредственного рисования через GPU (dri и пр.). Такие механизмы быстры, но, насколько я понял лишены сетевой прозрачности (поправьте, если ошибаюсь).

Собственно, сам рендеринг на GPU лишён сетевой прозрачности по своей концепции, так как современные GPU выдают растр, а не примитивами. По сути это опция отрисовки. Если же говорить о сетевой прозрачности с учётом 3D-ускорения, то в иксах есть GLX. По сути удалённо отправляются команды на отрисовку 3D-графики на клиентской машине. Эта возможность осталась просто потому, что нет смысла её выкидывать, но особого развития не получила из-за невостребованности гонять тяжёлые 3D-приложения удалённо, рендеря результат локально. Если спрос будет, то сделают снова, но завязано это будет скорее всего на те или иные API.

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

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

То есть получается приложение напрямую рисует в окно, а композитор вообще сам по себе.

Композитор управляет окнами и заведует отрисовкой этих окон. И, конечно же, напрямую в окно приложение рисует, но по отношению к железу это всё равно не напрямую.

А иначе получается, что меняется даже не шило на мыло, а шило на другое шило.

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

Вот скажыж пожалуйста, почему у яббла все ОК с графикой на локалхосте?
Сперва рендерили в ps, потом стали в pdf. И проблем никаких нет. Вернее уже почти ровно 20 лет рендерят в некое подобие пдф со своими доработками в виде Метал.

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

Основных доводов зачинателей Wayland в его пользу я помню только два. X-ы сильно разрослись, их тяжело развивать и совершенствовать. Дизайн X-ов не позволяет получить высокой производительности графики.

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

В заключение хотелось бы добавить кое-что про X-ы. На мой взгляд ирония судьбы в том, что с развитием железа многие недостатки X-ов уходят в небытие. Да GUI в ядре, конечно, быстрее. Но на современном железе именно в GUI этой разницы уже фактически незаметно. На современных мониторах с HiDPI отрисовка через core protocol смотрится вполне прилично. Еще немного и можно будет не заморачиваться насчет антиалиасинга шрифтов, или иных элементов. Сейчас, когда недостатки X-ов становятся не столь очевидны, а достоинства сохраняются, вся эта возня с Wayland-ом начинает вызывать скажем так чувство легкого недоумения.

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

Еще раз. Ты либо постишь proof-of-concept, который действительно имеет отношения к Wayland/X, либо ты еще раз подтверждаешь, что ты обычный некомпетентный клоун.

кейлоггеров

Предлагаю радикальное решение. После хэндшейка контроллер клавиатуры шлёт криптованный поток, а приложение уже само расшифровывает.

Тут нюанс в том, что Wayland пилют люди, которые втащили в иксы то, чем они стали тормозить.
Про скорость всё логично: иксы хорошо управляются с двумерными окнами и векторами (и раньше отлично работали с 2d ускорителями), а всё современные оконные системы рисуют окна через 3d ускорители. Иксы на это не очень заточены.
Поэтому Wayland как вот это api отдельных окон в 3d - нужно. Но только это настолько низкий уровень программирования, что на фоне иксов не нужно.

Если выбрать движок XV, то будет всё ОК.

хм... действительно.

W от X принципиально отличается тем, что в X приложению для отрисовки даётся окно, а в W — поверхность. При этом в X тоже можно получить поверхность, если использовать композитор, но приложение всё равно будет считать его окном и обязано реализовывать логику обработки окна.

Разницу между окном и поверхностью надо пояснять?

Отсюда возникает естественное желание — если использовать композитор, то большая часть кода, ответственная за отрисовку окна, оказывается не нужна. Окна не нужно перерисовывать, т.к. этим занимается композитор, damagerect никогда не наступает, так зачем его реализовывать и так далее. Примитивами никто не пользуется — тоже выкидываем. Четыре способа поменять раскладку? Оставляем один. Подкручиваем обработку глобальных горячих клавиш. Переделываем модель безопасности. Убираем глобальное позиционирование — оно и в композиторе не работает, так зачем.

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

1. Одни пишут, что wayland это дисплейниый сервер, другие, что нет. А как на самом деле?

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

Как композитор переносит буфер приложения в окно в видеобуфере? Получается он N раз в секунду, определят, какие окна отображены, и копирует туда изображение? Или все как-то сложнее делается?

Окна рендерятся в текстуры, которые потом отображаются при помощи видеоакселератора. Это ничем не отличается от использования X с композитором.

Когда-то (примерно в 2006-м) был композитор, работающий без использования видеоакселератора — назывался Matisse. Но я не слышал, чтобы кто-то делал что-то подобное сегодня, когда видеоакселераторы вставляют даже в часы.

Помнится разработчики wayland ругали X за двойную буферизацию, дескать тормозит она графику. Но у wayland получается двойная буферизация - это основополагающая концепция?

Проблема X в том, что приложение получает окно, и это окно в любой момент может быть выведено сервером на монитор, даже если оно не дорисовано. Чтобы избежать недорисованных окон, приложение должно заводить себе двойную буферизацию. Но приложение может этого и не делать.

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

На счёт «тормозит графику» — не знаю, не измерял. Да и с чего бы.

4. Может кто-то пояснит, как к этому всему может быть прикручено аппаратное ускорение?

См. выше про текстуры.

Потому что яблоки первыми сделали пиксельно-независимую графику, да. Потом Microsoft в своём Aero и Linux со своим Beryl и XGL.

Только в экосистеме Microsoft и Apple внедрение прошло одноэтапно, а в Linux некому крикнуть «цыц!» и перетащить всех в светлое будущее насильно, поэтому тут всё медленно и эволюционно. Так что сегодня мы имеем полный набор как тех, кто не использует композитор (таких очень мало), так и тех, кто использует (подавляющее большинство), и тех, кто уже на Wayland (таких очень мало).