Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Представлен новый легковесный X-сервер - Wayland"	+/–
Сообщение от opennews (?), 04-Ноя-08, 19:58
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.me/opennews/art.shtml?num=18730
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от не скажу (?), 04-Ноя-08, 19:58	+1 +/–
затея хорошая, главное чтоб хватило энтузиазма довести её до ума.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47

2. Сообщение от Georges (ok), 04-Ноя-08, 19:59	+/–
Всё необходимое перемещается в ядро, а это так сказать юзерспейс утилита... Это будет поменьше чем kdrive. В общем даёшь уменьшение потребления памяти на 50 мегов и увеличение производительности!!! Вот все файлы проекта: http://gitweb.freedesktop.org/?p=users/krh/wayland.git;a=tree
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #18

3. Сообщение от vadiml (?), 04-Ноя-08, 20:41	+/–
> затея хорошая, главное чтоб хватило энтузиазма довести её до ума. если RH будет в этом заинтресована -- доведут
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от atx (?), 04-Ноя-08, 20:56	+/–
Лишь бы по стабильности не ударило...
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от 0сторожный (?), 04-Ноя-08, 20:58	+1 +/–
> Всё необходимое перемещается в ядро главное, чтоб в ядро не перемещалось совсем _всё_
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от Egres (ok), 04-Ноя-08, 21:05	+/–
Угу. Опять "глюк в видео драйвере" начнёт класть всю машину сразу. Удобно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

7. Сообщение от Аноним (7), 04-Ноя-08, 21:52	+/–
А ничо что речь идет пока что об intel-only? Кто дрова под это писать будет? Никто? :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #9, #39

8. Сообщение от Georges (ok), 04-Ноя-08, 22:03	+/–
рассчитано под тех, кто имеет полноценные опенсурс дрова реализующие GEM и Kernel Mode setting (ati intel) под Nvidia не рассчитано. (разве что реверс инжиниринговый noveau) зачем рассчитывать под проприетарщиков?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

9. Сообщение от anonymous (??), 04-Ноя-08, 22:04	+/–
>А ничо что речь идет пока что об intel-only? Кто дрова под >это писать будет? Никто? :) ну как бы AMD, Intel и VIA уже сейчас имеют открытые дрова, не думаю что сложнго будет их перенести. Если всё будет действительно продумано и грамотно сделано nvidia тоже подтянется
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

10. Сообщение от crot (?), 04-Ноя-08, 22:13	+/–
Ну наконец то. Давно пора. X.org стал очень тяжелым и не поваротливым. Может хоть это подтолкнет разработчиков игр делать игры тоже под Linux. Вот бы скорее первый релиз увидеть. На ЛОРЕ вроде писали что Wayland поддерживает nvidia и ati.
Ответить | Правка | Наверх | Cообщить модератору

11. Сообщение от Аноним (7), 04-Ноя-08, 22:18	+/–
>на уровне на уровне ядра. какой уровень находится на уровне ядра?
Ответить | Правка | Наверх | Cообщить модератору

12. Сообщение от valexey (?), 04-Ноя-08, 23:07	+/–
Правильно ли я понимаю, что фактически этот сервер ломает совместимость с X Window System core protocol'ом? Судя по новости, этот новоявленый Х-сервер не будет заниматься отросовкой, а будет принимать от клиентов грубо говоря, только готовые bmp-шки. Т.о. ему уже нельзя будет сказать нарисуй мне линию вот тут, а вот тут полигон. А вот тут текст выведи. (всё это позволяет очень сильно снизить нагрузку на сеть). Т.о. этот "X-server" на самом деле уже не является X-сервером, является уже чем-то другим. Имеющиеся программы с ним работать не будут (по кр. мере те, которые не только bmp-шки гоняли).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #16

13. Сообщение от СуперАноним (?), 04-Ноя-08, 23:14	+/–
А по мне, так пусть лучше сам X-сервер занимается рендерингом виджетов. Зато окошки, выводимые разными тулкитами будут выглядеть одинаково. Да и траффик при таком подходе должен быть меньше.
Ответить | Правка | Наверх | Cообщить модератору

14. Сообщение от valexey (?), 04-Ноя-08, 23:20	+/–
Та-ак... Прочитал по диагонали что это за зверь такой. Так вот -- это НЕ X11-сервер! Т.о. совместимость с имеющимися приложениями нет и не планируется: "They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager." Поправьте заголовок новости и содержимое -- иначе вводит читателя в заблуждение.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25

15. Сообщение от Аноним (7), 04-Ноя-08, 23:24	+1 +/–
Совместимость ломает. Линию рисовать, конечно, можно, но делать это будет не сервер, а тот, кто с ним работает. Любой рендеринг является direct rendering'ом, и все то, что реально рисует придется переписывать (для начала cairo и freetype, со временем, возможно, монстров вроде gtk и qt). Благодаря этому и достигается основная цель сервера - приложение (или тулкит) может контролировать отрисовку, не допуская дефектов изображения в ее процессе; с текущим X-протоколом, гарантирующим только окончательный вид, но не то, что появляется в процессе это сделать непросто. Приходится использовать двойную буферизацию в тулкитах, чтобы X-сервер имел дело только с конечным вариантом изображения, и это все равно не спасает от лагов при перерисовке. Почти все программы используют тулкиты, никто напрямую через Xlib и Xt не работает - мороки слишком много. А переписать athena, motif, gtk, qt и всякую экзотику - работа, в принципе, реальная. Нагрузку на сеть.. Ну текст уже давно локально все рендерят. Нагрузка, наверное, возрастет.. Да и сейчас при запуске чего-нибудь на java со swing'ом с удаленной машины по X-протоколу вылезают совершенно немерянные тормоза при работе по небыстрому каналу, с временем реакции в несколько секунд - vnc решает проблему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

16. Сообщение от geekkoo (??), 04-Ноя-08, 23:40	+/–
>>а будет принимать от клиентов грубо говоря, только готовые bmp-шки. Т.о. ему уже нельзя будет сказать нарисуй мне линию вот тут, а вот тут полигон. А вот тут текст выведи. Ну, про текст уже выше сказали (freetype рендерит шрифт в клиенте, а на сервер уже пересылается растеризованный глифы). Так и с линиями и полигонами практически тоже самое - каиро ИМХО делает отрисовку в клиенте, на сервер идет уже результат. Да и если подумать - кому сейчас нужны эти draw-primitives? Любой тулкит сейчас использует шкурки, так что все равно с клиента приходится гнать на сервер картинки. Так что не проще ли не морочить себе голову Х-протоколом, а гнать сразу скриншоты с экрана. Тем более с современными гигабитными сетями разницы слать ли скрины мощным потоком, или время от времени посылать короткие команды по сети особой разницы нет. Может даже первый вариант предпочтительней (на таймаутах больше выигрыш).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #17

17. Сообщение от geekkoo (??), 04-Ноя-08, 23:45	+/–
Ну, и с фритайпом Кейт Паккард на самом деле проводил сравнения со старым ХFont (чисто серверной реализацией). По его измерениям получалось, что разницы практически никакой нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

18. Сообщение от User294 (ok), 05-Ноя-08, 01:02	+/–
> В общем даёшь уменьшение потребления памяти на 50 мегов и увеличение производительности!!! А также падения ядра в панику заместо падения иксов?... P.S. а облегченые иксы и так в природе есть.Хотя для мобильных девайсов по любому лишним не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

19. Сообщение от User294 (ok), 05-Ноя-08, 01:10	+1 +/–
>Угу. Опять "глюк в видео драйвере" начнёт класть всю машину сразу. Удобно. Ну, вообще, нынче видеодрайвера могут довольно основательно положить систему. Скажем атевый драйвер когда-то давно был с забавным глюком - мог заглохнуть и при том - в своем модуле, на уровне ядра.При этом система вроде и не дохнет совсем, но видео отваливается напрочь, половина пользовательских процессов встает колом и работает только аварийное Alt+SysRs+<буква>.Даже в консоль переключиться - фиг.Впрочем, эта байдень пофикшена уже достаточно давно и теперь оно месяцами не грохается =).Но лучше бы в кернеле поменьше дряни такого плана таскалось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #43

20. Сообщение от Аноним (7), 05-Ноя-08, 01:57	+/–
Для обратной совместимости X-сервер можно портировать под Wayland
Ответить | Правка | Наверх | Cообщить модератору

23. Сообщение от Аноним (7), 05-Ноя-08, 03:29	+/–
> Всё необходимое перемещается в ядро А сколько в своё время было наездов на Windows за такую вот организацию: некрасиво, небезопасно... Спустя пару десятков лет к тому же и пришли
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #27

25. Сообщение от Аноним (-), 05-Ноя-08, 08:47	+/–
>Поправьте заголовок новости и содержимое -- иначе вводит читателя в заблуждение. Читай внимательнее. Разработка только началась, сейчас нет X-сервера, но скоро сделают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #38

26. Сообщение от I (?), 05-Ноя-08, 09:02	+/–
>А сколько в своё время было наездов на Windows за такую вот >организацию: некрасиво, небезопасно... Спустя пару десятков лет к тому же и >пришли Все не так просто. Это другая архитектура.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #29

27. Сообщение от Хелагар (ok), 05-Ноя-08, 09:44	+/–
>> Всё необходимое перемещается в ядро > >А сколько в своё время было наездов на Windows за такую вот >организацию: некрасиво, небезопасно... Спустя пару десятков лет к тому же и >пришли Не к тому же, друже аноним. Но чтобы понять разницу, надо сделать над собой определённое усилие - внимательно почитать новость. Ну и знать организацию ядра Винды и Никсов (не микроядерных), само собой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #28

28. Сообщение от Аноним (7), 05-Ноя-08, 10:27	+/–
>Не к тому же, друже аноним. >Но чтобы понять разницу, надо сделать над собой определённое усилие - внимательно почитать новость. Ну и знать организацию ядра Винды и Никсов (не микроядерных), само собой. Ну и где же тут принципиальные различия? В винде есть драйвер режима ядра win32k.sys, который отвечает за отрисовку графики, в то время как аналогичный функционал в *никс-системах находится в юзерспейсе. Сейчас же и в линуксе хотят это перенести в ядро. Точно так же над ядерным модулем находятся различные библиотеки и тулкиты более высокого уровня, находящиеся в юзерспейс. Естественно, сходство не на 100%, но _Принципиальные_ различия назовите? А подчеркивание анонимного статуса собеседника - это первый признак того, что по теме сказать нечего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #33

29. Сообщение от Аноним (7), 05-Ноя-08, 10:38	+/–
>Все не так просто. Это другая архитектура. А никто и не утверждал, что в винде и в линуксах будет все одинаково. Имелся ввиду лишь АСПЕКТ под названием "ядерная графика". За эту самую ядерную графику винду сильно ругали, дескать, постоянно будет в БСОДы падать из-за ошибок в этом модуле и т.д. Сейчас в линуксе хотят также перенести часть кода в ядро, и получится схема, очень похожая на применяемую в виндовс. Красивое слово "архитектура" тут не уместно по большому счету, не тот масштаб
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #31

30. Сообщение от AsphyX (??), 05-Ноя-08, 10:58	+/–
Похоже, сбывается моя мечта: выкинуть бОльшую часть графических команд из core protocol'а, поскольку они всё равно уже практически не используются (отрисовка примитивов, глифов, блиттинг и Porter-Duff alpha blending давно уже выполняются через XRender).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32, #34

31. Сообщение от User294 (ok), 05-Ноя-08, 11:39	+/–
>очень похожая на применяемую в виндовс. Говоря об архитектуре - очень интересно, а что будет выступать аналогом win32k.sys? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

32. Сообщение от maximnik0 (?), 05-Ноя-08, 12:03	+/–
Боюсь все заглохнет , про фрамбуфер (framebuffer ) надеюсь не забыли - и где эта технология ? А вeдь для фрамбуфера был написан легкий X сервер .Потом появился dri ....и что то до сипор то починят то поломают .
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #35

33. Сообщение от geekkoo (??), 05-Ноя-08, 12:20	+/–
>[оверквотинг удален] >>Но чтобы понять разницу, надо сделать над собой определённое усилие - внимательно почитать новость. Ну и знать организацию ядра Винды и Никсов (не микроядерных), само собой. > >Ну и где же тут принципиальные различия? В винде есть драйвер режима >ядра win32k.sys, который отвечает за отрисовку графики, в то время как >аналогичный функционал в *никс-системах находится в юзерспейсе. Сейчас же и в >линуксе хотят это перенести в ядро. Точно так же над ядерным >модулем находятся различные библиотеки и тулкиты более высокого уровня, находящиеся в >юзерспейс. Естественно, сходство не на 100%, но _Принципиальные_ различия назовите? А >подчеркивание анонимного статуса собеседника - это первый признак того, что по >теме сказать нечего. Принципиальное различие, что Х (был и остается) - это сетевой протокол с клиент-серверной архитектурой. Никто это не оспаривает, вопрос только какую часть функциональности перенести в клиент, а какую - в сервер. Т.е. если X11 это толстый сервер и тонкий клиент, то Wayland предлагает скорее толстого клиента и тонкого сервера (что непосредственно отражается на размерах исходного кода). Хотя, конечно же, это моё ИМХО. Т.е. если кто-то попытается написать книжку про современные Х-ы, то он гарантированно попадет в bestselling authors. "Та самая" книжка про Xlib уже давно устарела, там нет ничего про freetypе, композит, mesa и OpenGL, DRI и AIGLX.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

34. Сообщение от geekkoo (??), 05-Ноя-08, 12:32	+/–
>Похоже, сбывается моя мечта: выкинуть бОльшую часть графических команд из core protocol'а, >поскольку они всё равно уже практически не используются (отрисовка примитивов, глифов, >блиттинг и Porter-Duff alpha blending давно уже выполняются через XRender). Это может и правильно, только как тогда быть с 3D? Я (может быть по наивности) полагал, что OpenGL, как бы, хорошо ложится на Х-протокол. Т.е. клиент шлёт себе команды OpenGL, обёрнутые в соответсвующий сетевой пакет, а X-сервер выступает в роли диспетчера - отдельные команды он просто пересылает видео-карте (в отличии от клиента он имеет непосредственный доступ к модулю, управляющему видео-картой), а некоторые отрабатывает на CPU. Может я просто не сильно въехал в архитектуру Х-ов, но я не очень понял, с чем связаны такие сложности с реализацией A(ccelarated)I(ndirect)GLX, которое появилось значительно позднее DRI. Т.е. мне казалось, что framebuffer (а именно это на мой взгляд пытается реализовать Wayland,  пусть и с сетевой прозрачностью) слишком примитивный уровень абстракции, чтобы на нем получить существенное ускорение 3D операций. Или я не прав?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #36

35. Сообщение от geekkoo (??), 05-Ноя-08, 13:11	+/–
>>и где эта технология ? Вот здесь -> http://www.directfb.org/ Т.е. о чём я и говорил - DirectFB 1.3.0 - first development release with OpenGL based acceleration - 2008-09-29 Фреймбуффер без OpenGL ускорения - мало кому нужен. Сейчас процессоры мощные, так что классические  2D операции их не сильно грузят, композит для затушевывания графики как-то худо бедно реализовали, любители шкурок - сами себе злобные буратины, а вот с 3D косяк ... Правда, к этому DirectFB сетвая прозрачность прилеплена как с боку бантик ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

36. Сообщение от AsphyX (??), 05-Ноя-08, 13:31	+/–
>я не очень понял, с чем связаны такие сложности с реализацией A(ccelarated)I(ndirect)GLX, >которое появилось значительно позднее DRI. А с тем, что в течении длительного времени X-сервер не имел доступа к OpenGL, ему просто некуда было слать десериализованные OpenGL-команды. Сервер только создавал некую низкоуровневую подстилку, позволяющую клиенту, через OpenGL обращаться к GPU и фреймбуферу напрямую. От сервера требовалось, если я правильно понимаю, только предоставить информацию, где во фреймбуфере расположено окно, куда выводить, и как отсекать вывод. Остальное делал клиент через DRI. >Т.е. мне казалось, что framebuffer (а именно это на мой взгляд пытается >реализовать Wayland,  пусть и с сетевой прозрачностью) слишком примитивный уровень >абстракции, чтобы на нем получить существенное ускорение 3D операций. Или я >не прав? См. выше. Если фреймбуфер (вернее, offscreen-буфер, связанный с окном) расположен в памяти видеокарты и доступен GPU, то ничего не мешает нам рисовать в него средствами OpenGL. Главное, корректно этот буфер лочить, чтобы клиент с сервером не поругались. Собственно, как-то так сейчас и делается у Nvidia, в случае включённого композитинга. Ребята из Nvidia просто сделали своего рода эмуляцию AIGLX без "Indirect" составляющей, т.е. рендеринг по-прежнему прямой, но в offscreen-буфер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #37, #41

37. Сообщение от geekkoo (??), 05-Ноя-08, 13:50	+/–
>>я не очень понял, с чем связаны такие сложности с реализацией 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-буфер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

38. Сообщение от Щекн Итрч (?), 05-Ноя-08, 15:45	+/–
>>Поправьте заголовок новости и содержимое -- иначе вводит читателя в заблуждение. > >Читай внимательнее. Разработка только началась, сейчас нет X-сервера, но скоро сделают. Цитатку, плиз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

39. Сообщение от Аноним (7), 05-Ноя-08, 21:33	+/–
>А ничо что речь идет пока что об intel-only? Кто дрова под >это писать будет? Никто? :) Ну логично, только у Intel opensource-дрова. Если проект разовьётся и хорошо себя покажет, то nvidia и ati возможно драйвера портируют под него.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

40. Сообщение от Дмитрий Ю. Карпов (?), 05-Ноя-08, 22:15	+/–
Для работы с терминалом нужен протокол типа HTTP+HTML, когда X-клиент составляет форму, в которой прописано, что он хочет визобразить на экране, а X-сервер сам это отображает. Идея гонять уже отрисованные картинки совершенно дурная - GPU на терминалах будут простаивать, зато CPU на хосте будет дико загружен отрисовкой. PS: Для игр нужен будет отдельный протокол работы с экраном, типа DirectX, который не связан с окнамию
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44

41. Сообщение от geekkoo (??), 05-Ноя-08, 23:32	+/–
Да действительно, я был неправ с этим DRI. Т.е. он представлял из себя костыль, который позволял клиенту напрямую работать с аппаратурой, минуя вообще говоря Xserver. Собственно поэтому им и могли воспользоваться только клиенты работающие на  той же машине, где находится видеокарта. ПОявление AIGLX ситуацию несколько выпрямило, поскольку с его появлением OpenGL команды стали проходить через сервер. Т.е. я действительно ошибался, считая, что это уже давно было реализовано. Но все же сомнительно, что AIGLX (или что-то похожее) будет реализовано в Waуland. Т.е. они  оставят DRI для локальных клиентов, коль скоро это все равно реализуется клиентскими библиотеками. Действительно остается только спинлок прицепить к видеобуфферу, чтобы разграничивать доступ между OpenGL клиентами и сервером.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

42. Сообщение от Lx (?), 06-Ноя-08, 00:09	+/–
Мдя.. Полное крушение представлений о жизни. А я - наивный - полагал, что xorg очень важная и нужная чать системы... что-то там отрисовывает, ускоряет... а оказывается она тупо выводит на экран, уже готовые картинки. К чему тогда она? Давайте фреймбуфер использовать.
Ответить | Правка | Наверх | Cообщить модератору

43. Сообщение от Sergey (??), 06-Ноя-08, 20:16	+/–
да ничего, и сейчас не менее забавный глюк, правда связанный с тем, что X-Server 1.5 по сию пору не поддерживается драйвером fglrx. При хагрузке консоли все еще ничего, а как только стартуют Х, то сразу черный экран, и все! Ни Х убить, ни в консоль выйти, только ресетом клацнуть, как на венде! Ну или можно удаленно войти, поправить конфиг и перегрузить все.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

44. Сообщение от Василий (??), 07-Ноя-08, 19:29	+/–
>Для работы с терминалом нужен протокол типа HTTP+HTML, когда X-клиент составляет форму, >в которой прописано, что он хочет визобразить на экране, а X-сервер >сам это отображает. > >Идея гонять уже отрисованные картинки совершенно дурная - GPU на терминалах будут >простаивать, зато CPU на хосте будет дико загружен отрисовкой. > Это точно. Сервера надо разгружать. Иначе клиенты своей массовостью сделают работу сервера совершенно невозможной. С веб-серверов никто ж не гоняет в сторону броузеров готовые отрендеренные картинки с изображением веб-страницы. Веб-сервера в сторону броузера гонят текст/хтмл, а каждый броузер загружает "рендерингом" хтмл-страницы процессор уже локальной машины.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

45. Сообщение от Света (?), 07-Ноя-08, 20:05	+/–
Никак не пойму, чем вызвана такая большая любовь к C без ++. Разве не удобнее писать тот же графический сервер на C++? Драйвер действительно можно сделать не в ядре (как в микроядерных ОС), но тут надо оценивать соотношение "требуемая надежность/требуемое быстродействие" (для игр, наверное, важнее второе, для серверов - первое, правда там и графика практически не нужна).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #46

46. Сообщение от Taz (?), 27-Май-11, 00:08	+/–
> для серверов - первое, правда там и > графика практически не нужна. не практически, а не нужна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

47. Сообщение от kiwinix (?), 13-Ноя-18, 20:43	+6 +/–
Передаю вам привет из 2018-го!)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #48

48. Сообщение от pavlinux (ok), 14-Ноя-18, 00:42	–2 +/–
Передаю привет в 2028! У вас там чего-нить заработало? В Убунту 28.10 уже дефолтное? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #50

49. Сообщение от Козлетто (?), 17-Окт-20, 14:54	+2 +/–
Привет из 2020 года! Ковид19, Федора 33, Linux 5.9, а этот ваш Wayland до сих пор не готов
Ответить | Правка | Наверх | Cообщить модератору

50. Сообщение от soarin (ok), 22-Апр-23, 12:38	+/–
В 2022 году стало дефолтное, хотя за исключением Nvidia. Средний палец ещё нескоро будет - через четыре года.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема