Представлен XWayland — Xorg-сервер, работающий поверх Wayland

А Wayland поверх Xorg ещё не придумали?

Ты будешь смеяться, но единтсвенная реализация вялена, которая хоть как-то работает и на которой показывают те самые шестеренки, крутится в окошке под X-ами :-)

Вот так. Сначала сделают велосипед, а потом над ним надстроют то, что было раньше. Идиоты.

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

И при этом тот вяленд будет работать поверх иксов.

spacel0rd> Смысл? Wayland делают оттого, что X-ы устарели и тормозят.

Wayland делают потому, что не смогли осилить допилить иксы. Иксы не тормозят. Запусти TWM или MWM и удивись. Когда на вяленде будут крутиться кедогномы - видеть бесполезность затеи с вялендом будут даже самые отъявленные его фанатики.

AVL2> нет. Будет работать медленнее. Но что ты выберешь между подтормаживающей прогой и отсутствием проги вообще?

Выберу нетормозящую программу, выкинув нафиг этот вяленд.

anonymous> Хехе - иксы наркотик похлеще венды, тем wine нужен а этим песочница для обратной совместимости ;-) ну хоть со страха насмерть соплями не изойдут.

Оптимистичное заявление. Посмотри на Mac OS X - не смотря на всё, там иксы присутствуют из коробки.

anonymous> Костыль, но не на костыле а на Wayland - лишний раз доказывает гибкость идеи - графический мультиплексор, сам по себе маленький и эффективный и позволяет строить поверх любые абстракции.

Тогда иксы тем более не костыль. См. Nested X

Mystra_x64> Да, да. Надо писать на Xlib :}

Нет - надо писать на XCB и EFL.

>Нет - надо писать на XCB и EFL.

Ну иди уже, пописай на XCB и EFL :-)

Xv — это не только копирование картинки в видеопамять (есть вариант закидывания через сокеты и через Shm). Xv также выставляет наружу ручки для управления параметрами оверлеев, которые предоставляет видяха. Это запрос X-протокола XvSetPortAttributes, а доступные атрибуты можно посмотреть в выводе xvinfo.

Какой механизм существует или предполагается для этого в Wayland (в ядре Linux)? Кто будет писать драйвера под Linux для старых, но достаточно мощных карточек? Про сетевую прозрачность я уже не спрашиваю, ее точно не будет. А если видеокарточки вообще нет на сервере? В иксах я хоть могу гнать поток YUV на X-сервер (XvPutImage) и преобразовываться в RGB, масштабироваться и т. д. он будет видяхой в терминале.

>Какой механизм существует или предполагается для этого в Wayland

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

>А если видеокарточки вообще нет на сервере?

vnc/spice же.

>Чесслово - смотрю на аватару и понимаю - в библиотеку посылать поздно и страшно ;-)

В какую библиотеку? Я же вопросы конкретные задал. Расскажи.

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

Я написал поддержку Xv для ряда старых карт s3 в Xorg. Можешь говорить со мной на одном языке.

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

Так и есть в Xv. В запросах параметр XvPortID указывает, какой формат видео (список id можно получить xvinfo). XvShmCreateImage создаем расшаренную между сервером и клиентом область памяти. Буфер заполняется клиентом X-клиентом, а потом XvShmPutImage. Удаленная работа — фоллбэк на функции без shared memory.

Это кстати все справедливо и для всего остального. Графические процессоры достаточно несложные устройства. Упоротая nvidia со своим vdpau - пипец тот еще сс3б, они просто дают библиотеки в бинарном виде для которых можно написать биндинги, да я смотрел как один индийский партизан написал поддержку для mplayer - едва не стошнило, для gstreamer можно на порядок проще написать, но индусу памятник однозначно заказать нужно :)

>Я написал поддержку Xv для ряда старых карт s3 в Xorg. Можешь говорить со мной на одном языке.

Отлично - я написал для новых и не понимаю почему ты не понимаешь меня. Скажи - зачем нужен xorg. Для ускорения цветового преобразования, поворотов, масштабирования, обрезки - достаточно написать плагин для gstreamer того же и не нужно париться с иксами, более того с Wayland это уже означает что просто передай ему буфер а он завернет в оконный менеджер и наложит прочие отображения. C gem это будет еще проще и быстрее.

>Скажи - зачем нужен xorg

1. Сетевая прозрачность. 2. Драйвера огромного для огромного числа карт никогда не будут написаны для Linux. Не забываем также о других системах.

Для ускорения цветового преобразования, поворотов, масштабирования, обрезки - достаточно написать плагин для gstreamer того же и не нужно париться с иксами

Это ты предлагаешь сделать мне программно (напоминаю, что смотрим случай, когда GPU нет на сервере)? А потом еще fullscreen в тяжелом RGB тащить через сеть к терминалу? Да я и на терминале могу аппартаное масштабирование сделать, у меня карточка там стоит, которая это умеет делать. И RGB я могу там аппаратно сделать из YUV.

>1. Сетевая прозрачность.

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

2. Драйвера огромного для огромного числа карт никогда не будут написаны для Linux.

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

Это ты предлагаешь сделать мне программно (напоминаю, что смотрим случай, когда GPU нет на сервере)?

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

>Это фарс, данные можно передавать по сети независимо от Wayland.

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

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

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

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

>vnc/spice же.

http://www.youtube.com/watch?v=2O0bLxQoIVw

X-сервер X-Win32 LIVE с протоколом LIVE, который есть не что иное, как лицензированный NX.

>X-сервер X-Win32 LIVE с протоколом LIVE

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

>Ты снова пропостулировал то, с чего начались несколько весьма длинных флеймов вокруг Wayland. Я с самого начала больше не выдержу.

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

Больше икс срачей! Хороших и разных!

Всем пк, клоуны :-)

>отсюда давай поконкретней, Расскажи что есть в иксах такого что нужно всем,

Я написал довольно большой ответ, но потом подумал и стер его, так как увязну в этих спорах. Так не пойдет. Должно быть наорот: X Window System уже есть, работает, предоставляет и композитинг, и отрисовку, и работу с устройствами ввода, и механизм для написания оконных менеджеров (в том числе и композитных), тулкиты давно портированы на Xlib/XCB и тоже работают. Тут приходит Wayland и ненавязчиво спрашивает: «А докажите, почему вы так тут нужны?». Это Wayland должен показать, что же такого мне не хватает сейчас в локальном варианте X Server. А цифр-то и нет никаких. Зато есть много людей, которые про Иксы вообще ничего не знают, но мнение уже имеют. Самое интересно, что при этом умудряются параллельно доказывать необращенным, какой Linux крутой, и показывать им крутые (и большей частью бесполезные) эффекты рабочего стола.

>> А Wayland поверх Xorg ещё не придумали?

Ты будешь смеяться, но единтсвенная реализация вялена, которая хоть как-то работает и на которой показывают те самые шестеренки, крутится в окошке под X-ами :-)

т.е новость реально о том, что появились X-ы работающие из под Wayland-а, который работает из под X-в.

похоже на дурдом

Раньше только в аудио системах был разброд и шатание с двумя системами (ALSA и OSS), из которых более убогая (ALSA) используется вместо более политически враждебной (OSS), и обёртками (PA, Pulse, SDL, JACK, OpenAL) разной функциональности. Теперь получаем то же в графике? X.org и Wayland (обсуждать какая более убога оставим троллям), работающие поверх друг друга с обёртками Qt и GTK.

> с двумя системами

Ох если бы. http://yokozar.org/blog/content/linuxaudio.png

Конкуренция. Абсолютно нормальное явление. Что выживет — станет стандартом.

что есть в иксах такого что нужно всем

gtkperf, тест GtkDrawingArea text, который в локальном и сетевом запусках не отличаются по производительности. Там же тесты lines и circles. Там же GtkTextView и всякие Gtk**Button - все они по скорости локальной и удаленной отрисовки практически совпадают, и не тормозят. Вяленд так не сможет никогда. В принципе.

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

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

Напоминает иксы для мака - медленно, коряво, но как-то работает.

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

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

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

>>Я написал поддержку Xv для ряда старых карт s3 в Xorg.

Отлично - я написал для новых

Для каких? Просто чтобы знать, кто заглянул на огонек.

> что нужно всем

по скорости локальной и удаленной отрисовки

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

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

Всем, кто _промышленно_ использует линуксы/юниксы на десктопе. Нафига мне ставить полнофункциональные системы каждому пользователю, если можно поставить X-терминал, в котором движущихся деталей только кнопка включения?

с промышленных установок иксы никуда и не денутся, пока не появится нормальная замена и после этого не пройдет 5-8 лет

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

Те, кому не нужна удаленная отрисовка, рисуют локально. Это же очевидно.

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

_________

//wfrr

>Для ускорения цветового преобразования, поворотов, масштабирования, >обрезки - достаточно написать плагин для gstreamer того же и не нужно >париться с иксами

Это ты предлагаешь сделать мне программно (напоминаю, что смотрим >случай, когда GPU нет на сервере)? А потом еще fullscreen в тяжелом >RGB тащить через сеть к терминалу? Да я и на терминале могу аппартаное >масштабирование сделать, у меня карточка там стоит, которая это умеет >делать. И RGB я могу там аппаратно сделать из YUV.

YUV удобен в алгоритмах сжатия тем что потеря части информации о цвете практически не влияет на качество результата, в видеокарту ты пересылаешь уже декодированные кадры - разница YUV | RGB будет небольшая. Я не вижу смысла гнать по сети YUV - проще сжатый поток гнать а все декодирование делать локально,так кстати и поступают c HDTV, IPTV.
Xv - это некий общий механизм над возможностями видеодаптеров, но он неудобен - для банальных вещей нужно делать иксовый(!) драйвер тогда как иксы тут вообще непонятно причем - мне например не нужны иксы и все рендерится в фреймбуфер. Wayland позволяет элементарно перенаправить этот фреймбуфер ему и он обернет тебе все в оконную систему.

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

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

Могу дать на размышление хоть суточки - с какой легкостью все что уже было написано интегрируется с Wayland можно заметить по Qt, Gtk, и самим X11. Еще проще будет когда делаешь что-то свое, вместо килотонн устаревшего медленного говна ставишь Wayland и отдаешь ему готовый буфер с данными.

и да - X Windows как и Windows никуда не делись и не денутся - идиотов всегда будет достаточно.

>с какой легкостью все что уже было написано интегрируется с Wayland можно заметить по Qt, Gtk, и самим X11.
При том, что input stack ещё нормально не реализован, не говоря о политике взаимодействия (ICCCM)… Толсто и тупо.

не говоря о политике взаимодействия (ICCCM)… Толсто и тупо

для толстых и тупых предуссмотрен путь -->

и да - X Windows как и Windows никуда не делись и не денутся - идиотов всегда будет достаточно.

>и да - X Windows как и Windows никуда не делись и не денутся - wayland нужен исключительно для запуска GDM
fixed. Новость это подтверждает.

Wayland позволяет элементарно перенаправить этот фреймбуфер ему и он обернет тебе все в оконную систему.

Нет никакой «оконной системы». Все делает приложение. Да и сейчас тебе никто не мешает отрисовать все в буфер и кунть его на любой Drawable.

Нет никакой «оконной системы». Все делает приложение.

А Сompiz для чего хотят использовать в Ubuntu, а толстячок ? ;-)

All window managers become compositing managers, and because we can redirect windows into our own buffers (since we control the entire compositing process) we can enforce our own window decorations.

Да и сейчас тебе никто не мешает отрисовать все в буфер и кунть его на любой Drawable.

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

>All window managers become compositing managers, and because we can redirect windows into our own buffers (since we control the entire compositing process) we can enforce our own window decorations.
Для толстых и тупых:
1. Как мне жёстко задать размер создаваемых окон? (для тайлового WM)
2. Ну и нафиг мне кастрат вместо нормального WM?

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

Да и сейчас тебе никто не мешает отрисовать все в буфер и кунть его на любой Drawable.

Точное описание работы *любого* wayland-приложения. drawable — область RAM.

>Ну и нафиг мне кастрат

У тебя яйца кастрированы по самый мозг, сходи убей себя.

Я не вижу смысла гнать по сети YUV - проще сжатый поток гнать а все декодирование делать локально,так кстати и поступают c HDTV, IPTV.

Все зависит от задач, от железа. На весьма скромном железе, на 100Мбит/с отображение 720p по чистому X11 с Xv (без ssh) со звуком должно показывать и при этом масштабироваться карточкой, если верить цифрам Led'а. Декодирование сжатого потока 720p локальным плеером (его никто не запрещает нам поставить) такая машина вряд ли потянет.

И не все задачи, решаемые через Xv, это просмотры фильмов или потока. Обработка видеопотока может быть встроена внутрь окна. Что-то типа Skype, например: вот пришел к нему поток по какому-то своему протоколу, он этот поток сам декодировал и выплюнул в Xv внутри своего окошка. Если такой софт рисовать удаленно, то никакого кодирования/декодирования не будет, а только YUV или RGB. Хотя, я полагаю умозрительно, возможны варианты с проксированием X-протокола на предмет выхватывания запроса передачи кадра (XvPutImage), его запаковвки и последующей распаковке на стороне терминала — все должно быть прозрачно для X-сервера, он не заметит подвоха.