Kristian Hogsberg, работающий в компании Red Hat над развитием X.Org, приступил (http://hoegsberg.blogspot.com/2008/11/premature-publicity-is...) к разработке нового легковесного X11 сервера, отвечающего требованиям реалий сегодняшнего для. Новый проект получил название Wayland (http://cgit.freedesktop.org/~krh/wayland/). Взаимодействие с аппаратным обеспечением, например, проведение инициализации, переключение видеорежимов (drm modesetting) и управление памятью (GEM) графических карт производится через модуль, работающий на уровне на уровне ядра. Кроме того, Wayland работает без привилегий суперпользователя и объединяет в одном процессе дисплейный и композитный менеджер.
В настоящее время проект на начальной стадии развития, созданный прототип насчитывает 3200 строк кода на языке Си. Основная идея (http://cgit.freedesktop.org/~krh/wayland/tree/NOTES) заложенная в Wayland - на уровне сервера выполняется только переадресация всех окон, при которой все операции ренде...URL: http://www.phoronix.com/scan.php?page=article&item=xorg_wayl...
Новость: http://www.opennet.dev/opennews/art.shtml?num=18730
затея хорошая, главное чтоб хватило энтузиазма довести её до ума.
Передаю вам привет из 2018-го!)
Передаю привет в 2028! У вас там чего-нить заработало? В Убунту 28.10 уже дефолтное? :)
В 2022 году стало дефолтное, хотя за исключением Nvidia.
Средний палец ещё нескоро будет - через четыре года.
Всё необходимое перемещается в ядро, а это так сказать юзерспейс утилита...
Это будет поменьше чем kdrive. В общем даёшь уменьшение потребления памяти на 50 мегов и увеличение производительности!!!Вот все файлы проекта: http://gitweb.freedesktop.org/?p=users/krh/wayland.git;a=tree
> Всё необходимое перемещается в ядроглавное, чтоб в ядро не перемещалось совсем _всё_
> В общем даёшь уменьшение потребления памяти на 50 мегов и увеличение производительности!!!А также падения ядра в панику заместо падения иксов?...
P.S. а облегченые иксы и так в природе есть.Хотя для мобильных девайсов по любому лишним не будет.
> затея хорошая, главное чтоб хватило энтузиазма довести её до ума.если RH будет в этом заинтресована -- доведут
Лишь бы по стабильности не ударило...
Угу. Опять "глюк в видео драйвере" начнёт класть всю машину сразу. Удобно.
>Угу. Опять "глюк в видео драйвере" начнёт класть всю машину сразу. Удобно.Ну, вообще, нынче видеодрайвера могут довольно основательно положить систему. Скажем атевый драйвер когда-то давно был с забавным глюком - мог заглохнуть и при том - в своем модуле, на уровне ядра.При этом система вроде и не дохнет совсем, но видео отваливается напрочь, половина пользовательских процессов встает колом и работает только аварийное Alt+SysRs+<буква>.Даже в консоль переключиться - фиг.Впрочем, эта байдень пофикшена уже достаточно давно и теперь оно месяцами не грохается =).Но лучше бы в кернеле поменьше дряни такого плана таскалось.
да ничего, и сейчас не менее забавный глюк, правда связанный с тем, что X-Server 1.5 по сию пору не поддерживается драйвером fglrx. При хагрузке консоли все еще ничего, а как только стартуют Х, то сразу черный экран, и все! Ни Х убить, ни в консоль выйти, только ресетом клацнуть, как на венде! Ну или можно удаленно войти, поправить конфиг и перегрузить все.
А ничо что речь идет пока что об intel-only? Кто дрова под это писать будет? Никто? :)
рассчитано под тех, кто имеет полноценные опенсурс дрова реализующие GEM и Kernel Mode setting (ati intel)
под Nvidia не рассчитано. (разве что реверс инжиниринговый noveau)
зачем рассчитывать под проприетарщиков?
>А ничо что речь идет пока что об intel-only? Кто дрова под
>это писать будет? Никто? :)ну как бы AMD, Intel и VIA уже сейчас имеют открытые дрова, не думаю что сложнго будет их перенести. Если всё будет действительно продумано и грамотно сделано nvidia тоже подтянется
>А ничо что речь идет пока что об intel-only? Кто дрова под
>это писать будет? Никто? :)Ну логично, только у Intel opensource-дрова. Если проект разовьётся и хорошо себя покажет, то nvidia и ati возможно драйвера портируют под него.
Ну наконец то. Давно пора. X.org стал очень тяжелым и не поваротливым. Может хоть это подтолкнет разработчиков игр делать игры тоже под Linux. Вот бы скорее первый релиз увидеть. На ЛОРЕ вроде писали что Wayland поддерживает nvidia и ati.
>на уровне на уровне ядра.какой уровень находится на уровне ядра?
Правильно ли я понимаю, что фактически этот сервер ломает совместимость с X Window System core protocol'ом? Судя по новости, этот новоявленый Х-сервер не будет заниматься отросовкой, а будет принимать от клиентов грубо говоря, только готовые bmp-шки. Т.о. ему уже нельзя будет сказать нарисуй мне линию вот тут, а вот тут полигон. А вот тут текст выведи. (всё это позволяет очень сильно снизить нагрузку на сеть).Т.о. этот "X-server" на самом деле уже не является X-сервером, является уже чем-то другим. Имеющиеся программы с ним работать не будут (по кр. мере те, которые не только bmp-шки гоняли).
Совместимость ломает. Линию рисовать, конечно, можно, но делать это будет не сервер, а тот, кто с ним работает. Любой рендеринг является direct rendering'ом, и все то, что реально рисует придется переписывать (для начала cairo и freetype, со временем, возможно, монстров вроде gtk и qt). Благодаря этому и достигается основная цель сервера - приложение (или тулкит) может контролировать отрисовку, не допуская дефектов изображения в ее процессе; с текущим X-протоколом, гарантирующим только окончательный вид, но не то, что появляется в процессе это сделать непросто. Приходится использовать двойную буферизацию в тулкитах, чтобы X-сервер имел дело только с конечным вариантом изображения, и это все равно не спасает от лагов при перерисовке.Почти все программы используют тулкиты, никто напрямую через Xlib и Xt не работает - мороки слишком много. А переписать athena, motif, gtk, qt и всякую экзотику - работа, в принципе, реальная.
Нагрузку на сеть.. Ну текст уже давно локально все рендерят. Нагрузка, наверное, возрастет.. Да и сейчас при запуске чего-нибудь на java со swing'ом с удаленной машины по X-протоколу вылезают совершенно немерянные тормоза при работе по небыстрому каналу, с временем реакции в несколько секунд - vnc решает проблему.
>>а будет принимать от клиентов грубо говоря, только готовые bmp-шки. Т.о. ему уже нельзя будет сказать нарисуй мне линию вот тут, а вот тут полигон. А вот тут текст выведи.Ну, про текст уже выше сказали (freetype рендерит шрифт в клиенте, а на сервер уже пересылается растеризованный глифы). Так и с линиями и полигонами практически тоже самое - каиро ИМХО делает отрисовку в клиенте, на сервер идет уже результат.
Да и если подумать - кому сейчас нужны эти draw-primitives? Любой тулкит сейчас использует шкурки, так что все равно с клиента приходится гнать на сервер картинки. Так что не проще ли не морочить себе голову Х-протоколом, а гнать сразу скриншоты с экрана. Тем более с современными гигабитными сетями разницы слать ли скрины мощным потоком, или время от времени посылать короткие команды по сети особой разницы нет. Может даже первый вариант предпочтительней (на таймаутах больше выигрыш).
Ну, и с фритайпом Кейт Паккард на самом деле проводил сравнения со старым ХFont (чисто серверной реализацией). По его измерениям получалось, что разницы практически никакой нет.
А по мне, так пусть лучше сам X-сервер занимается рендерингом виджетов. Зато окошки, выводимые разными тулкитами будут выглядеть одинаково. Да и траффик при таком подходе должен быть меньше.
Та-ак... Прочитал по диагонали что это за зверь такой. Так вот -- это НЕ X11-сервер! Т.о. совместимость с имеющимися приложениями нет и не планируется:"They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager."
Поправьте заголовок новости и содержимое -- иначе вводит читателя в заблуждение.
>Поправьте заголовок новости и содержимое -- иначе вводит читателя в заблуждение.Читай внимательнее. Разработка только началась, сейчас нет X-сервера, но скоро сделают.
>>Поправьте заголовок новости и содержимое -- иначе вводит читателя в заблуждение.
>
>Читай внимательнее. Разработка только началась, сейчас нет X-сервера, но скоро сделают.Цитатку, плиз.
Для обратной совместимости X-сервер можно портировать под Wayland
> Всё необходимое перемещается в ядроА сколько в своё время было наездов на Windows за такую вот организацию: некрасиво, небезопасно... Спустя пару десятков лет к тому же и пришли
>А сколько в своё время было наездов на Windows за такую вот
>организацию: некрасиво, небезопасно... Спустя пару десятков лет к тому же и
>пришлиВсе не так просто. Это другая архитектура.
>Все не так просто. Это другая архитектура.А никто и не утверждал, что в винде и в линуксах будет все одинаково. Имелся ввиду лишь АСПЕКТ под названием "ядерная графика". За эту самую ядерную графику винду сильно ругали, дескать, постоянно будет в БСОДы падать из-за ошибок в этом модуле и т.д. Сейчас в линуксе хотят также перенести часть кода в ядро, и получится схема, очень похожая на применяемую в виндовс. Красивое слово "архитектура" тут не уместно по большому счету, не тот масштаб
>очень похожая на применяемую в виндовс.Говоря об архитектуре - очень интересно, а что будет выступать аналогом win32k.sys? :)
>> Всё необходимое перемещается в ядро
>
>А сколько в своё время было наездов на Windows за такую вот
>организацию: некрасиво, небезопасно... Спустя пару десятков лет к тому же и
>пришлиНе к тому же, друже аноним.
Но чтобы понять разницу, надо сделать над собой определённое усилие - внимательно почитать новость. Ну и знать организацию ядра Винды и Никсов (не микроядерных), само собой.
>Не к тому же, друже аноним.
>Но чтобы понять разницу, надо сделать над собой определённое усилие - внимательно почитать новость. Ну и знать организацию ядра Винды и Никсов (не микроядерных), само собой.Ну и где же тут принципиальные различия? В винде есть драйвер режима ядра win32k.sys, который отвечает за отрисовку графики, в то время как аналогичный функционал в *никс-системах находится в юзерспейсе. Сейчас же и в линуксе хотят это перенести в ядро. Точно так же над ядерным модулем находятся различные библиотеки и тулкиты более высокого уровня, находящиеся в юзерспейс. Естественно, сходство не на 100%, но _Принципиальные_ различия назовите? А подчеркивание анонимного статуса собеседника - это первый признак того, что по теме сказать нечего.
>[оверквотинг удален]
>>Но чтобы понять разницу, надо сделать над собой определённое усилие - внимательно почитать новость. Ну и знать организацию ядра Винды и Никсов (не микроядерных), само собой.
>
>Ну и где же тут принципиальные различия? В винде есть драйвер режима
>ядра win32k.sys, который отвечает за отрисовку графики, в то время как
>аналогичный функционал в *никс-системах находится в юзерспейсе. Сейчас же и в
>линуксе хотят это перенести в ядро. Точно так же над ядерным
>модулем находятся различные библиотеки и тулкиты более высокого уровня, находящиеся в
>юзерспейс. Естественно, сходство не на 100%, но _Принципиальные_ различия назовите? А
>подчеркивание анонимного статуса собеседника - это первый признак того, что по
>теме сказать нечего.Принципиальное различие, что Х (был и остается) - это сетевой протокол с клиент-серверной архитектурой. Никто это не оспаривает, вопрос только какую часть функциональности перенести в клиент, а какую - в сервер. Т.е. если X11 это толстый сервер и тонкий клиент, то Wayland предлагает скорее толстого клиента и тонкого сервера (что непосредственно отражается на размерах исходного кода).
Хотя, конечно же, это моё ИМХО.
Т.е. если кто-то попытается написать книжку про современные Х-ы, то он гарантированно попадет в bestselling authors. "Та самая" книжка про Xlib уже давно устарела, там нет ничего про freetypе, композит, mesa и OpenGL, DRI и AIGLX.
Похоже, сбывается моя мечта: выкинуть бОльшую часть графических команд из core protocol'а, поскольку они всё равно уже практически не используются (отрисовка примитивов, глифов, блиттинг и Porter-Duff alpha blending давно уже выполняются через XRender).
Боюсь все заглохнет , про фрамбуфер (framebuffer ) надеюсь не забыли - и где эта технология ?
А вeдь для фрамбуфера был написан легкий X сервер .Потом появился dri ....и что то до сипор то починят то поломают .
>>и где эта технология ?Вот здесь -> http://www.directfb.org/
Т.е. о чём я и говорил -
DirectFB 1.3.0 - first development release with OpenGL based acceleration - 2008-09-29
Фреймбуффер без OpenGL ускорения - мало кому нужен. Сейчас процессоры мощные, так что классические 2D операции их не сильно грузят, композит для затушевывания графики как-то худо бедно реализовали, любители шкурок - сами себе злобные буратины, а вот с 3D косяк ...
Правда, к этому DirectFB сетвая прозрачность прилеплена как с боку бантик ...
>Похоже, сбывается моя мечта: выкинуть бОльшую часть графических команд из core protocol'а,
>поскольку они всё равно уже практически не используются (отрисовка примитивов, глифов,
>блиттинг и Porter-Duff alpha blending давно уже выполняются через XRender).Это может и правильно, только как тогда быть с 3D?
Я (может быть по наивности) полагал, что OpenGL, как бы, хорошо ложится на Х-протокол. Т.е. клиент шлёт себе команды OpenGL, обёрнутые в соответсвующий сетевой пакет, а X-сервер выступает в роли диспетчера - отдельные команды он просто пересылает видео-карте (в отличии от клиента он имеет непосредственный доступ к модулю, управляющему видео-картой), а некоторые отрабатывает на CPU. Может я просто не сильно въехал в архитектуру Х-ов, но я не очень понял, с чем связаны такие сложности с реализацией A(ccelarated)I(ndirect)GLX, которое появилось значительно позднее DRI.
Т.е. мне казалось, что framebuffer (а именно это на мой взгляд пытается реализовать Wayland, пусть и с сетевой прозрачностью) слишком примитивный уровень абстракции, чтобы на нем получить существенное ускорение 3D операций. Или я не прав?
>я не очень понял, с чем связаны такие сложности с реализацией A(ccelarated)I(ndirect)GLX,
>которое появилось значительно позднее DRI.А с тем, что в течении длительного времени X-сервер не имел доступа к OpenGL, ему просто некуда было слать десериализованные OpenGL-команды. Сервер только создавал некую низкоуровневую подстилку, позволяющую клиенту, через OpenGL обращаться к GPU и фреймбуферу напрямую. От сервера требовалось, если я правильно понимаю, только предоставить информацию, где во фреймбуфере расположено окно, куда выводить, и как отсекать вывод. Остальное делал клиент через DRI.
>Т.е. мне казалось, что framebuffer (а именно это на мой взгляд пытается
>реализовать Wayland, пусть и с сетевой прозрачностью) слишком примитивный уровень
>абстракции, чтобы на нем получить существенное ускорение 3D операций. Или я
>не прав?См. выше. Если фреймбуфер (вернее, offscreen-буфер, связанный с окном) расположен в памяти видеокарты и доступен GPU, то ничего не мешает нам рисовать в него средствами OpenGL. Главное, корректно этот буфер лочить, чтобы клиент с сервером не поругались. Собственно, как-то так сейчас и делается у Nvidia, в случае включённого композитинга. Ребята из Nvidia просто сделали своего рода эмуляцию AIGLX без "Indirect" составляющей, т.е. рендеринг по-прежнему прямой, но в offscreen-буфер.
>>я не очень понял, с чем связаны такие сложности с реализацией A(ccelarated)I(ndirect)GLX,
>>которое появилось значительно позднее DRI.
>
>А с тем, что в течении длительного времени X-сервер не имел доступа
>к OpenGL, ему просто некуда было слать десериализованные OpenGL-команды. Сервер только
>создавал некую низкоуровневую подстилку, позволяющую клиенту, через OpenGL обращаться к GPUВ каком смысле? По крайней мере в X-API долгое время (задолго до того, как в Xorg реализовали AIGLX) были команды представляющие из себя кальку с OpenGL команд. Т.е. видимо предполагалось, что клиент напрямую использует эти команды, а как они отрисовываются на сревере (с аппаратным ускорением или без) не его, вообще говоря, дело. Я был очень удивлен, что на самом деле аппаратное ускорение этих команд при работе через сеть появилось только после внедрения AIGLX. Что же тогда клиент слал серверу через сокет (в смысле до появления AIGLX)? Готовые картинки, что-ли?
>и фреймбуферу напрямую. От сервера требовалось, если я правильно понимаю, только
>предоставить информацию, где во фреймбуфере расположено окно, куда выводить, и как
>отсекать вывод. Остальное делал клиент через DRI.Это очень сильно зависело, работает ли клиент на том же хосте, что и сервер, или всё же через сеть. Например, на XFree (некрофилией я из чисто естествоиспытательских соображений занимаюсь, да) AIGLX нет до сих пор, поэтому при работе через сеть весь рендеринг идёт через программный OpenGL.
>[оверквотинг удален]
>>абстракции, чтобы на нем получить существенное ускорение 3D операций. Или я
>>не прав?
>
>См. выше. Если фреймбуфер (вернее, offscreen-буфер, связанный с окном) расположен в памяти
>видеокарты и доступен GPU, то ничего не мешает нам рисовать в
>него средствами OpenGL. Главное, корректно этот буфер лочить, чтобы клиент с
>сервером не поругались. Собственно, как-то так сейчас и делается у Nvidia,
>в случае включённого композитинга. Ребята из Nvidia просто сделали своего рода
>эмуляцию AIGLX без "Indirect" составляющей, т.е. рендеринг по-прежнему прямой, но в
>offscreen-буфер.
Да действительно, я был неправ с этим DRI. Т.е. он представлял из себя костыль, который позволял клиенту напрямую работать с аппаратурой, минуя вообще говоря Xserver. Собственно поэтому им и могли воспользоваться только клиенты работающие на той же машине, где находится видеокарта. ПОявление AIGLX ситуацию несколько выпрямило, поскольку с его появлением OpenGL команды стали проходить через сервер. Т.е. я действительно ошибался, считая, что это уже давно было реализовано.Но все же сомнительно, что AIGLX (или что-то похожее) будет реализовано в Waуland. Т.е. они оставят DRI для локальных клиентов, коль скоро это все равно реализуется клиентскими библиотеками. Действительно остается только спинлок прицепить к видеобуфферу, чтобы разграничивать доступ между OpenGL клиентами и сервером.
Для работы с терминалом нужен протокол типа HTTP+HTML, когда X-клиент составляет форму, в которой прописано, что он хочет визобразить на экране, а X-сервер сам это отображает.Идея гонять уже отрисованные картинки совершенно дурная - GPU на терминалах будут простаивать, зато CPU на хосте будет дико загружен отрисовкой.
PS: Для игр нужен будет отдельный протокол работы с экраном, типа DirectX, который не связан с окнамию
>Для работы с терминалом нужен протокол типа HTTP+HTML, когда X-клиент составляет форму,
>в которой прописано, что он хочет визобразить на экране, а X-сервер
>сам это отображает.
>
>Идея гонять уже отрисованные картинки совершенно дурная - GPU на терминалах будут
>простаивать, зато CPU на хосте будет дико загружен отрисовкой.
>Это точно. Сервера надо разгружать. Иначе клиенты своей массовостью сделают работу сервера совершенно невозможной. С веб-серверов никто ж не гоняет в сторону броузеров готовые отрендеренные картинки с изображением веб-страницы. Веб-сервера в сторону броузера гонят текст/хтмл, а каждый броузер загружает "рендерингом" хтмл-страницы процессор уже локальной машины.
Мдя.. Полное крушение представлений о жизни. А я - наивный - полагал, что xorg очень важная и нужная чать системы... что-то там отрисовывает, ускоряет... а оказывается она тупо выводит на экран, уже готовые картинки. К чему тогда она? Давайте фреймбуфер использовать.
Никак не пойму, чем вызвана такая большая любовь к C без ++. Разве не удобнее писать тот же графический сервер на C++? Драйвер действительно можно сделать не в ядре (как в микроядерных ОС), но тут надо оценивать соотношение "требуемая надежность/требуемое быстродействие" (для игр, наверное, важнее второе, для серверов - первое, правда там и графика практически не нужна).
> для серверов - первое, правда там и
> графика практически не нужна.не практически, а не нужна.
Привет из 2020 года! Ковид19, Федора 33, Linux 5.9, а этот ваш Wayland до сих пор не готов