1. История.
В 2005 году X сервер отмечает свой 21-й день рождения. Появивишись в 1984 из проекта Athena, он хорошо служил сообществу UNIX все прошедшие годы. X сервер повсеместно используется на рабочих столах пользователей Линукс. В статье в Wikipedia об X сервере рассказывается очень подробно, здесь нужно упомянуть лишь два самых главных его достижения: открытость исходного кода, которая позволила реализовать переносимость между платформами, и сетевую прозрачность. Однако, прошло уже 20 лет с момента разработки X сервера, и оборудование с тех пор очень сильно изменилось. Если вы посмотрите на общий вид современной видео микросхемы, вы обнаружите небольшой блок, с пометкой 2D, ответственный за плоскую/двумерную графику. Дело в том, что 90% микросхемы обслуживают 3D конвейеры. Вы уже заплатили за эти трехмерные аппаратные средства, и было бы неплохо, если бы вы могли использовать их на своем рабочем столе. Многие люди даже не осознают, что оборудование для трёхмерной графики может создавать двумерные рабочие столы. Посмотрите на ваш экран, это ведь двумерное изображение, правильно? Любое изображение, сгенерированное вашим оборудованием с поддержкой трехмерности, в результате превращается в двумерное изображение у вас на плоском экране. Это должно подтолкнуть вас к мысли, что при соответствующем программировании вашего трёхмерного оборудования, оно способно отображать двумерный рабочий стол.
2. Производители графических микросхем.
В былые времена производители охотно делились информацией о микросхемах и их программировании. Но, с ростом патентных баз, рос и страх оказаться под судом за нарушения этих патентов. В настоящий момент производители графических микросхем скрывают всю информацию о своей продукции, затрудняя для держателей патентов поиск нарушений. Точнее, такова версия производителей о том, почему необходимо сокрытие информации о программировании микросхем. Они заявляют так же, что сокрытие подобной информации затрудняет конкурентам понимание того, как именно работает их микросхема, но в этом я сомневаюсь так же, как и в легенде про патенты. Все эта скрытность делает задачу написания драйвера с открытым исходным кодом для этих микросхем очень трудной. Вместо этого, нас заставляют полагаться на то, что производитель сам предоставит драйвера для своего новейшего оборудованя. Если вы ещё не заметили, производителей по-настоящему заботят только системы MS "Окна", и они делают минимально возможное для поддержки своего оборудования в Линукс. Есть исключения: Intel предоставляет драйвера с открытым исходным кодом для некоторых своих микросхем. Nvidia/ATI предоставляют свои собственные драйвера, но они отстают от версий для "Окна". В результате, мы имеем смесь весьма разных по качеству драйверов, от очень хороших до никаких.
3. Альтернативы рабочего стола.
Альтернативы рабочего стола, "Окна" и Mac, оба являются средами, использующими аппаратное ускорение графики. Очевидно, они заметно лучше своих предшественников. В некоторых случаях скорость отрисовки в них более, чем в сто раз превосходит ту, что была в старых моделях. В недалеком будущем производители графических чипов собираются вообще убрать метку 2D и предложить нам оборудование с поддержкой только трехмерной графики. До Microsoft и Apple, по-видимому, дошло, что трехмерность является дорогой, по которой стоит двигаться дальше, и они уже начали это движение. С другой стороны, от некоторых разработчиков X сервера я слышал пожелания прекратить всякие разговоры о какой-либо конкуренции. Они заявляют, что всего лишь хотят улучшить X систему. Им, вероятно, невдомек, а вот мне совершенно ясно, что руководители Redhat и Novell, когда столкнутся со снижением продаж из-за неконкурентноспособной графической системы, ни за что не согласятся с таким подходом.
Использование трехмерной графики на рабочем столе - это не просто создание новых рюшечек. Множество рюшек можно сделать и при помощи glitz. Есть более весомые причины для использования трехмерности. Хотя бы тот факт, что трехмерная графика быстрее двумерной, и никто уже не занимется оптимизацие функций двумерной графики, все аппаратные изыскания [silicon engineering] направлены в сторону трехмерности. С её помощью можно производить быстрые и произвольно сложные операции с рисунками, такие, как изменение цветовой палитры, растяжение/сжатие и другие. Мне довелось видеть, как чрезвычайно сложную фильтрацию проводили на шейдер [shader] оборудовании, что у центрального процесоора заняло бы несколько секунд на кадр. Становится возможна поддержка неоднородных [гетерогенных] цветовых режимов для окон (одновременное присутствие окон в 8-, 16- и 24-битном режимах) с произвольными палитрами; моментальный поворот/отражение экрана на проекторах, увеличение размеров при плохой видимости [visual impaired]. Независимость от разрешения позволяет отрисовывать объекты произвольного размера и проводить их пересемплирование прямо на экране. Более интересные варианты применения приведены ниже в разделе, описывающем управление окнами.
4. Современное состояние X.org сервера.
Ближайшая будущая версия X.org сервера - X11R7. Основным отличием этого релиза станет разделение исходного кода на модули при том, что для обычного пользователя модульность вряд ли что-то изменит, она упростит задачу разработчикам. До разделения исходный код X сервера состоял из 16 миллионов строк кода и развивался в виде одного проекта. Теперь код будет разделен на множество независимых модулей, что упростит его понимание и развитие.
5. X как операционная система.
Является ли X просто приложением или целой операционной системой? Для хорошего понимания принципов работы Х сервера рекомендуется прочесть эту книгу. Несмотря на то, что ей восемь лет, бОльшая её часть всё ещё актуальна. Прочитайте её, если вы не знакомы с такими терминами как DIX, mi, DDX, CFB. Примерно на этапе X11R6.3 Xfree86 стал отдельным проектом, что повлекло за собой изменения дизайна X в сторону платформонезависимости. В операционных системах, где работает X, поддержка распознавания оборудования сильно разнится. Для решения этой проблемы в X появился код, проверяющий шину PCI на наличие подключенных устройств, код для нахождения блоков видео памяти ROM и их запуска для сброса настроек оборудования, распознавания и предоставления драйверов для устройств ввода, управления несколькими устройствами VGA и даже своя система загрузки модулей. С этого момента на вопрос, является ли X приложением или операционной системой, более не существует однозначного ответа. Несмотря на то, что для некоторых платформ данные возможности X, как операционной системы, были просто необходимы, на таких платформах как Линукс, которые сами их предоставляют, это неизбежно привело к конфликтам между X и платформой, которые мы имеем сейчас. Конечно, операционные системы не стоят на месте, и рациональные решения, найденные десять лет назад, могут быть бессмысленными сейчас.
Ядро Линукс предоставляет такие подсистемы, как PCI и framebuffer, которые отсутствуют в BSD и некоторых других системах. Ради кроссплатфоренности вышеуказанные подсистемы были параллельно реализованы в X сервере. В прошлом в этом была необходимость. В современных же системах Линукс это приводит к тому, что две различные программы пытаются одновременно управлять одними и теми же устройствами. Многие пользователи Линукс работают с видеоустройствами без X. Единственное, что их связывает с X, это ядро. Ядро Линукс предоставляет для них множество механизмов, как то: подсистема PCI, драйверы устройств ввода, распознавание подключённых "на лету" устройств [hotplug], драйверы видеоустройств. В интересах координации, лучшее решение на Линукс в данной ситуации - использовать возможности, предоставляемые, в первую очередь, ядром, и запускать код X, обладающий той же функциональностью, только на других системах. Драйверы fbdev и XAA являются наиболее яркими примерами продублированной функциональности.
Линукс имеет замечательную поддержку hotplug, и графической системе было бы полезно использовать ее. Экраны могут быть подключены из различных источников. Тривиальным примером использования системы hotplug является подключение к компьютеру новой видеокарты. Существуют также различные нетривиальные ситуации, где может быть использован hotplug. Если экран, который вы хотите использовать, занят другим пользователем, то его выход из системы для вас может обрабатываться, как подключение экрана "на лету". При подключении внешнего монитора к ноутбуку также может срабатывать система hotplug. С помощью беспроводного соединения можно подключаться к настенным экранам, используя DMX или Chromium. Также источником множества событий hotplug является USB. Пользователь может подключать "на лету" мыши, планшеты, клавиатуры, аудиоустройства или даже графические адаптеры. Из-за отсутсвия взаимодействия с системой hotplug ядра в настоящее время X сервер не обрабатывает ни одну из этих ситуаций.
Стандартное графическое окружение в Линукс системах использует корневой режим Х сервера с корневым окном. Корневой режим X означает, что Х управляет отрисовкой верхнего уровня рабочего стола и расположенных на нем окон. Cygwin/X, Directfb и Apple Darwin используют некорневой режим Х сервера. В этих окружениях экраном управляет другая, главная оконная система, которая отрисовывает рабочий стол и предоставляет свой API для работы с окнами приложений. X может быть интегрирован в такое окружение, как гостевая оконная система, работая в некорневом режиме. А именно, содержимое окон приложений, работающих с X, помещается в системную память, и в определенное время окна X синхронизируются с главной оконной системой, которая отображает их содержимое на экране. Работающий в некорневом режиме X сервер также обеспечивает протоколы для передачи событий ввода между главной и гостевой оконными системами.
6. X Render.
Расширение X Render. В 2000 году Кейс Паккард [Keith Packard] заявил, что существующий X сервер не способен эффективно отрисовывать чистый, сглаженный текст и предложил использовать расширение X Render - это компонент ядра X сервера, позволяющий отрисовывть красиво выглядящие шрифты и дающий возможность внедрить библиотеку Cairo в X сервер. Также X Render добавляет в X сервер операторы Портера-Даффа [Porter-Duff]. С их помощью можно различными способами комбинировать поверхности. Эти операторы очень похожи на концепцию текстур и операций с ними в OpenGL, но, будучи похожими, они не повторяют их полностью.
7. XAA.
XAA впервые появилась в XFree86 4.0. Чтобы сохранить кроссплатформенность, XAA обеспечивает работу 2D драйверов в пространстве пользователя без использования драйверов ядра системы. Драйвера в пространстве пользователя, и правда, работают, но, без своих драйверов, ядро Линукс не имеет возможности отследить, что делает X сервер с оборудованием. X сервер не запустится до тех пор, пока ваша система на загрузится. Вы хотели бы видеть что-нибудь на мониторе во время загрузки системы в случае, если X сервер не сможет успешно запуститься, не так ли? Поэтому во время загрузки Линукс использует текстовый режим [console] со специальными драйверами, самый распространенный из которых VGAcon. Итак, в Линукс у нас всегда есть два драйвера, для X сервера и для текстового режима, и оба пытаются управлять одной и той же частью компьютера. Комбинация XAA, текстового режима и такой возможности ядра Линукс, как виртуальные терминалы [Virtual Terminals] может в итоге приводить к множеству конфликтов, подробнее об этом поговорим потом.
8. EXA.
EXA это надстройка над существующими 2D XAA драйверами, которая позволяет нынешней архитектуре X сервера сохраниться еще на какое-то время. EXA расширяет концепцию XAA драйверов, работая с 3D устройствами, чтобы ускорить работу расширения X Render. Вначале EXA была предложена, как универсальное решение для всех устройств, включая устаревшие. Но это не так. Если в старом устройстве нет ничего, что могло бы ускорить прорисовку, то EXA в этом случае бессильно, хотя вероятно, и может повысить производительность засчет лучшего управления видеопамятью. В итоге получилось так, что для большиства устройств, на которых работает EXA, уже есть драйвера OpenGL. Существуют, естественно, исключения: например nv и i128, оба с аппаратной поддержкой трехмерности, но OpenGL драйвера для них нет. Но EXA драйвера, работая с 3D устройствами из XAA драйверов еще больше увеличивают длинную очередь программ, которые пытаются использовать видео устройство одновременно. В результате EXA - это всего лишь подпорка, которая помогает старому доброму X серверу протянуть еще один, два года. Также существует опасность, что EXA придётся и дальше продолжать разрастаться чтобы поддерживать все новые и новые возможности 3D чипов. Заплатка под названием EXA работает, но это не долговременное решение. Важно помнить, что EXA/Render до сих пор имеет только часть возможностей более функционального Mesa OpenGL API, а со временем мы будем желать все больших и больших возможностей.
9. Cairo.
Цель библиотеки Cairo предоставить высококачественный 2D API, одинаково пригодный для печати и экранной графики. Она разработана с учетом расширения X Render и реализует модель построения изображения документ PDF 1.4. Среди интересных операций можно отметить штрихование и заполнение кубических сплайнов Безье, трансформацию и сочетание прозрачных изображений, сглаженное отображение текста. Дизайн Cairo гибок и позволяет библиотеке работать через различные подключаемые модули: картинка, glitz, png, ps, pdf, svg, quartz, GDI и xlib. Cairo разрабатывается уже около двух лет и должна появиться в ближайших версиях GDK и Mozilla. Главная цель Cairo - облегчить разработчикам создание качественной 2D графики на экране и ее перевод на бумагу. Подключаемые модули сопряжения позволяют приложениям использовать единый код для экрана и принтера.
Один из модулей сопряжения Cairo, названный glitz, использует вывод графики на основе OpenGL. Существует хорошая статья, детально описывающая glitz. Поскольку Cairo может работать как через модуль xlib, так и через OpenGL, можно напрямую сравнивать их производительность. По опубликованным результатам видно, что OpenGL выигрывает у XAA по скорости в 10-100 раз. Эта разница объясняется тем, что glitz/OpenGL использует аппаратное 3D ускорение. Сравнение работы Cairo на glitz и xlib хорошо демонстрирует, что аппаратура, предназначенная для ускорения работы 3D может быть с успехом использована и в 2D графике.
10. DRI и OpenGL.
DRI, инфрастуктура прямого рендеринга [Direct Rendering Infrastructure], реализует взаимодействие OpenGL с X сервером. DRI включает четыре основных компонента. Во-первых, это libGL, которая обеспечивает API OpenGL и действует как переключатель между драйверами. Во-вторых, это специфичная для конкретного видеооборудования библиотека DRI, осуществляющая взаимодействие с графическим процессором. Для возможностей OpenGL, не реализованных драйвером DRI, требуется программная эмуляция, для чего используется Mesa. Следует заметить, что Mesa это полная программная реализация OpenGL. Видеокарты, не поддерживающие ускорение, могут реализовывать OpenGL с помощью Mesa. И наконец, DRM, менеджер прямого рендеринга [Direct Rendering Manager]. DRM драйвера выполняются в контексте ядра, управляя видеоподсистемой компьютера и обеспечивая необходимую защиту от несанкционированного доступа.Интересная черта DRI - это слово прямой [Direct] в названии. Каждое приложение, используя DRI напрямую, управляет видеоподсистемой. В этом отличие от X, где вы посылаете команды отрисовки серверу, и уже сервер обращается к оборудованию. Драйвера DRM обрабатывают множественные запросы для исключения взаимных ошибок. Преимущества такой модели в том, что отрисовка через OpenGL происходит без накладных расходов на обмен и передачу данных серверу. Недостатки - во множественных переключениях контекста видеокарты. Некоторые видеокарты умеют быстро переключать графический контекст, некоторые нет. Microsoft уже столкнулась с этой проблемой, и поддержка аппаратного переключения контекста одно из требований для получения логотипа "Оборудование совместимо с DirectX 10".
DRM также поддерживает концепцию главного пользователя, как известно, обладающего наибольшими правами относительно обычных пользователей. Эти дополнительные права позволяют инициализировать видеокарту и контролировать потребление ресурсов графическим процессором. Текущая реализация X сервера, запускаемого с правами главного пользователя системы, функционирует как "главный пользователь" для DRM. Это не значит, что главный пользователь DRM всегда обязательно должен иметь права главного пользователя всей операционной системы, и существует патч, исключающий такое требование.
Когда видеокарта не поддерживает какую-либо операцию, Mesa реализует её программно. Это называется "возврат ошибочного вызова". Некоторых такое название смущает. Они говорят, что OpenGL не полностью поддерживается X сервером. Подумайте об этом. Аппаратный OpenGL поддерживается не полностью из-за большого количества возможностей функций, в то время как X поддерживает только несколько. Если встречается функция, присутствующую в обоих драйверах, то она будет обработана аппаратно. Если нет, придётся дорабатывать соответствующий драйвер.
11. Безопасность и главный пользователь.
Ядро Линукс содержит около 10 миллионов строк кода, исполняемых с правами главного пользователя. X сервер же содержит 16 миллионов строк кода, большая часть которого исполняется так же с правами главного пользователя. Как по вашему, где больше шансов найти уязвимость в безопасности? Технической необходимости запускать X сервер с правами главного пользователя нет. Однако, в настоящее время ради кроссплатформенной совместимости X сервер запускается с правами главного пользователя, чтобы позволить программировать видеообородование из пространства пользователя. Но в Линукс есть решение этой проблемы. Вы помещаете привилегированный код в драйвер устройства и запускаете пользовательское приложение без привилегий главного пользователя. Привилегированный код в драйвере видеоустройства в среднем занимает около 100 кб и выверить его намного легче чем 16 миллионов строк X сервера.
12. Устаревающее аппаратное обеспечение.
X сервер может быть запущен на любой видеокарте, даже на "тупом" VGA адаптере. Mesa легко и непринужденно проэмулирует весь API OpenGL. Вопрос только в скорости. Сколько ни программируй, ATI X850 из VGA не сделаешь. Старое оборудование отлично обслуживается X сервером, но новые системы разрабатываются для нового оборудования, и могут вести себя некорректно на старом. На тот случай, если вы захотите прикинуть стоимость замены вашего видеоадаптера: графические карты, способные выдать приличную производительность OpenGL, можно купить за 40$ или даже дешевле, если приобрести карту, бывшую в употреблении. В качестве альтернативы вы можете не менять видеокарту и продолжать использовать то программное обеспечение, которое исправно служило вам ранее.13. Поддержка графики ядром.
Когда ядро загружается, вы видите консоль загрузки. На платформе x86 бОльшая часть загрузочных консолей это VGAcon, который использует унаследованную поддержку VGA, реализованную в вашей видеокарте. Поскольку большинство графических адаптеров, используемых на платформе x86, поддерживают VGA, то VGAcon предоставляет универсальную консоль для этой платформы. На платформах, отличных от х86, у вас может не быть поддержки VGA, и на них обычно используется зависящий от чипа драйвер фреймбуфера. В ядро включено значительное число драйверов fbdev (драйверов фреймбуфера), так что поддерживается весьма большой диапазон адаптеров.
14. Обратная совместимость с VGA.
Оригинальная архитектура IBM PC подразумевает существование ограниченного перечня устройств, в соответвие каждому из которых ставятся широко известные адреса; например, доступ к порту COM1 осуществляется по адресу 0x3F8. К сожалению, поддержка VGA большинством видеокарт реализуется по тому же принципу. Пока в системе имеется лишь одно устройство графического вывода, VGA не представляет проблемы. Вставьте вторую видеокарту - и оба устройства будут пытаться занять один и тот же адрес на шине.Нынешняя реализация Х сервера содержит код, допускающий использование более одного VGA адаптера. Однако при этом другие пользователи не получат доступа к графическому устройству. Блокирование таких пользователей (программ) - не лучшее решение, поэтому необходимо найти способ управления доступом пользователей к VGA устройствам. Лучшее решение, которое можно реализовать под Линукс - добавить в ядро механизм VGA-арбитража [VGA arbitration mechanism]. BenH работает над тем вариантом, который недавно обсуждался в OLS.
Другая проблема это инициализация нескольких видеокарт. Видеокарты имеют "Постоянное запоминающее устройство" [ROM], часто называемое "Базовая система ввода/вывода видео" [VBIOS], программный код которого выполняется каждый раз при загрузке для инициализации. Из соображений обратной совместимости, многие из этих инициирующих программ создаются с использованием поддержки VGA. Поскольку мы можем иметь только одно обратносовместимое VGA устройство, системный BIOS игнорирует эту проблему и инициализирует только первую видеокарту. Остается, правда, возможность инициализировать вторичные видеокарты в процессе дальнейшей загрузки. Это достигается запуском VBIOS вторичных видеокарт с помощью виртуального режима x86 машины и координированным использованием одиночного обратносовместимого VGA устройства. Ещё больше усложняет ситуацию существование двух общих форматов ROM: x86 и Open Firmware. Так как производители вкладывают больше сил в Open Firmware модели, стала общим местом возможность использовать x86 устройства на не-x86 машинах. Чтобы это работало,VBIOS так же приходится запускать через эмулятор x86. BenH работает над решением и этой проблемы.
Fbdev, называемый так же фреймбуфер [framebuffer] (буфер кадра), под Линукс в первую очередь отвечает за инициализацию аппаратного обеспечения, распознание подключенных дисплеев, определение их корректных режимов, установку режима развертки и его конфигурирование, аппаратный курсор, гашение [blanking], цветовую палитру [color mapping], сдвиг [pan] и вход/выход в/из режима ожидания. Существует много драйверов фреймбуфера в ядре и они реализуют различные степени поддержки этих возможностей. Обратите внимание, что пока интерфейс к фреймбуферу основан на ядре, ничто не мешает иметь вспомогательные приложения для поддержки фреймбуфера в пространстве пользователя. Эти приложения могут быть использованы для того, чтобы делать вызовы функций VBIOS в ситуациях, когда исходного кода нет в наличии.
Когда вы запускаете VBIOS, он создает набор очень низкоуровневых входных точек, которые могут быть использованы для контроля над дисплеем. Эта часть нуждается в глубокой детализации и я не буду объяснять все различия между VGA, Int10 и VESA. Если кратко, VGA - это основной стандарт аппаратных регистров, установленный IBM. Int10 использует программные прерывания для вывода на дисплей. Программные прерывания работают только в реальном режиме x86, и они почти уже никем не исользуются, за исключением таких программ, как загрузчик GRUB. Источником кода, поддерживающего Int10 является VBIOS, который устанавливается при запуске ROM. Одновременно может быть установлен только один Int10 драйвер. VESA берет за основу модель Int10 и расширяет её для работы в защищённом режиме. При конфигурировании ядра присутствуют три драйвера: VGA, VESA и fbdev, которым также нужен fbconsole для запуска, и VGAcon, который в него включен. На системах, отличных от х86, обычно нужны драйверы fbdev и fbconsole.
15. Работа в многопользовательском режиме.
Линукс - многопользовательская операционная система. Такой она была всегда. Но единственным путем предоставления возможности работы большому количеству пользователей было использование последовательных соединений и сети. Что случится, если вы установите несколько видео адаптеров и запустите многопользовательский режим локально? Он не заработает. Были патчи, которые пытались и заставляли такую конфигурацию работать, такие, как проект Линукс консоли и различные надстройки над X сервером. Проблема в том, что Линукс консоль, называемая "Виртуальный терминал" [VT], контролирует локальные видео адаптеры и поддерживает эффективную работу только для одного пользователя. Заметьте, что fbdev позволяет нормально работать, когда используется большим количеством пользователей, в то время как система Виртуального терминала - однопользовательская.
Многопользовательские локальные системы применяются в таких местах, как школы, системы контроля, интернет-кафе и даже дома. В прошлом потребность в поддержке нескольких видео адаптеров была не такой уж высокой, так как обычные компьютеры поддерживают только один AGP слот. Несколько PCI адаптеров конечно же работают, но их производительность оставляет желать лучшего. Существуют компьютеры класса hi-end с поддежкой нескольких AGP слотов, но они не часто встречаются. Шина PCI Express (PCIe) изменила данную ситуацию. С ней все слоты функционируют равнозначно. Единственная вещь, которая может различаться, это скорость каждого слота. Такое изменение в аппаратной архитектуре позволяет с легкостью создать систему с несколькими высокоскоростными адаптерами. Шина PCIe поддерживает до 16 одновременно работающих видеоадаптеров в системе.16. Разделение консоли.
Если посмотреть на организацию консоли, сразу станут видны два варианта её использования. Системная консоль, отображающая процесс загрузки и используемая для отображения системных ошибок и восстановления, и пользовательская консоль, обычный дисплей, используемый для входа в систему, работы с командной строкой и редактирования. В нынешней консольной системе Линукс в обоих случаях используется один и тот же код консоли.
Возможно разделить код консоли в зависимости от выполняемых функций и разрешить множество существующих проблем. Во-первых, системная консоль должна быть абсолютно надежной в любых обстоятельствах. Она не обязана быть быстрой. Её код должен быть максимально простым, он должен работать во время обработки прерывания и во время режима паники ядра. При этом подразумевается её использование для восстановления системы в однопользовательском режиме. Очевидно, нужно отображать загрузочные сообщения, поддерживать систему отладки ядра kdbg. Эта консоль должна предоставлять SAK и экран безопасного входа в систему. Для поддержки нескольких пользователей, входящих с разных мониторов, подсоединённых к одному видеоадаптеру, консоль должна работать независимо на каждом мониторе. Одним из способов доступа к консоли было бы нажатие клавиши [SysReq], консоль бы перекрывала текущее изображение и использовала текущий видео режим. Именно так работает отладчик ядра от Novell. Системная консоль не поддерживает виртуальных терминалов и не переключаема. Так как она использует текущий видео режим, она может работать даже в экстренных обстоятельствах, например, отображая фатальные ошибки ядра.
Дизайн системной консоли использует fbdev для ослеживания режима и нахождения скан-буфера. Для обеспечения максимальной надежности всякое ускорение вывода отключено. Fbconsole использует центральный процессор [CPU] для прямых манипуляций с видео-буфером. Вывод консоли производится путем прямой записи в видео буфер, используя поддержку растровых шрифтов в fbconsole.
ользовательская консоль работает совершенно иначе. Желательно, чтобы она была быстрой и дружественной к пользователю. Работа вне ядра облегчает поддержку многопользовательского режима путем создания отдельного процесса для каждого пользователя. Режим пользователя упрощает использование аппаратного ускорения, предоставляемого графическим процессором [GPU] через fbdev и DRM. Кроме того, доступны Xft/FreeType для полной поддержки Unicode. Правильный дизайн консоли сделает возможным работу разных пользователей с разными подключенными мониторами. Используя разные клавиатурные комбинации, можно имитировать поведение, аналогичное существующим виртуальным терминалам и поддерживать переключение консолей.
Так как нынешние консоли выполняют все функции сразу, при переключении виртуальных терминалов пользователь сталкивается с обоими типами. В новой модели клавиши переключения виртуальных терминалов вызывают только консоли, работающие в пользовательском режиме. [SysReq] вызывает системную консоль. Командный интерпретатор, работающий в системной консоли, может быть высокоприоритетным процессом для облегчения перехвата управления у "проблемных" процессов.
17. Группируя устройства.
Поддержка локальной многопользовательской среды подразумевает, что Линукс внедрит концепцию консольных групп для периферии, ориентированной на пользовательский интерфейс. Консольные группы - это набор оборудования, создающий вместе консоль входа. Например, в группу войдут монитор, мышь, клавиатура и аудиоустройство. При входе PAM назначит владельцем данной группой устройств того, кто вошёл в систему. Интересным дополнением к данной концепции является включение USB хаба или порта как части консольной группы. Пока пользователь находится в системе, всё, что подключено через USB порт, будет принадлежать ему. После выхода всё вернётся к начальному состоянию.
18. Варианты альтернатив.
Маленькие дополнения: directfb, svglib, fresco, Y Windows, FBUI и так далее. Линукс привлекает большое количество людей, которые хотят экспериментировать с кодом графикой. В существующей модели виртуального терминала [VT] эти графические системы вызывают много проблем при его переключении. После переключения виртуальных терминалов, только что активированная графическая система позволяет делать с оборудованием всё что угодно, в том числе: его переинициализацию, перепрограммирование и очистку VRAM. Когда вы переключаетесь обратно, ожидается, что первоначальная система должна восстановиться при изменённом статусе оборудования. Это не просто недоразумения, которые способны вызвать проблемы при переключени виртуальных терминалов. Можно переключаться ведь и между системной консолью и X Window, или даже между рабочими столами, такими как X и Xegl. Это модель была, скорее всего, замечательной для VGA адаптеров с 14 регистрами и 32 Кб памяти, но она совершенно не подходит для карты с 300 регистрами, 512 Мб памяти и независимым графическим сопроцессором.
19. Эффективное взаимодействие.
Я думаю, что лучшее решение проблемы - это предоставление ядром единого драйвера с широким спектром возможностей для каждого из видеоустройств. Это означает, что конфликтующие драйвера вроде fbdev и DRM должны быть объеденены в одну систему. Это также означает, что должно быть исключены игры с оборудованием из пространства пользователя в то время, когда загружен драйвер устройства из ядра. У меня есть подозрение, что если бы Линукс предоставлял полноценные стандартные драйвера для различных видеокарт, то желание написать еще одну версию драйвера для Radeon исчезло бы само собой.br/> Это не означает, что проекты вроде fresco не могут разрабатывать свои собственные драйвера для видеооборудования. Это означает всего лишь, что вам придётся выгружать стандартные драйвера и затем загружать специальные перед запуском новой программы. Такая выгрузка/загрузка ничем не отличается от выгрузки/загрузки других драйверов ядра. Использование комбинаций клавиш для переключения между двумя активными драйверами видеоустройств для одного и того же оборудования поддерживать больше не следует. Если же в функциональности основного драйвера не хватает чего-либо, то лучше создать патч для стандартного драйвера. Благодаря реализации нужных расширений в стандартном драйвере, ими смогут воспользоваться все программы. Так же будет очень легко переключаться между приложениями, используя их в консольной системе пространства пользователя. Если же мы собираемся оставить комбинации клавиш для переключния между видеодрайверами, то, по-моему мнению, единственный справедливый способ сделать это - также реализовать переключение и между дисковыми и сетевыми драйверами с помощью таких комбинаций
20. OpenGL | ES.
Группа Хронос [Khronos] является стандартизирующей организацией, объединяющей свыше сотни участников. Самый удачный стандарт Хронос - OpenGL ES. OpenGL ES достаточно удобное подмножество OpenGL, предназначенное для систем с небольшим объёмом памяти. Ещё один стандарт - EGL, платформонезависимый эквивалент программных интерфейсов OpenGL GLX/agl/wgl. "EGL предоставляет механизмы для создания областей рендеринга, которые могут использоваться из приложений OpenGL ES и OpenVG для отрисовки, создание графического контекста для клиентских API и синхронизация отрисовки клиентскими API, а так же родными API рендеринга платформы. Это позволяет безболезненно использовать OpenGL ES и OpenVG для высокопроизводительного, ускоренного смешанного 2D и 3D рендеринга."EGL предполагает наличие в операционной системе подсистемы управления окнами. Тем не менее, EGL является платформонезависимой и ничто в EGL API не привязано к системе управления окнами в отличие от GLX/agl/wgl. Все ссылки к локальной системе управления окнами обрабатываются с помощью прозрачных указателей.
Разработчики Mesa предложили расширение для EGL, позволяюещее реализовать подсистему управления окнами поверх EGL. Ядро этого расширения предоставляет API для перечисления доступных экранов, установки режимов и настройки фреймбуфера экрана, сдвига экрана и запроса аттрибутов. Две области, всё ещё требующие доработки в расширении EGL - это аппаратный курсор и отображение цветов/работа с палитрами. Добавление этой функциональности в EGL предоставляет достаточный контроль над аппартной частью для реализации сервера оконной системы аналогичного Xegl. OpenGL плюс EGL и плюс расширения Mesa создают действительно переносимый API для доступа к графическим подсистемам любого класса: от мобильных телефонов до Playstation 3, персональных компьютеров и графических суперкомпьютеров.
Расширенный API EGL хорошо подходит к Линукс. Он предоставляет основу для создания оконной системы или встроенных приложений. Одинаково просто использовать его для развлечений, исследований и экспериментов. Он позволяет сконцентрировать внимание на вашем новом приложении или оконной системе и забыть обо всех сложностях работы с графической подсистемой компьютера.
Я уверен, что группа Хронос представляет собой основную неиспользованную пока еще возможность для сообщества X.org и других, заинтересованных в графике под Линукс. Для большинства стандартов Хроноса отсутствуют базовое воплощение с открытыми исходными текстами, поддержка систем разработки и тесты на соответствие. Большинство из тех, кто поддерживает данную группу, занимаются продажами промышленных систем, основанных на Линукс. Если бы в X.org немного подредактировали уставные документы, они могли бы обратиться в группу Хронос, и предложить себя в качестве их независимого некоммерческого партнера, создающего базовые реализации с открытыми исходными текстами и системы разработки, основанные на Линукс и стандартах Хронос. Это партнерство позволило бы участникам группы Хронос внести финансовые пожертвования в X.org, подобно IBM и сообществу Eclipse.
21. С точностью до пикселя.
Абсолютная пиксельная точность - миф. Единственное, что возможно - бороться за повышение этой точности. Источники погрешности находятся повсюду. Равномерность подсветки LCD, однородность чернил принтера, качество ЦАП, отражательные качества бумаги, проблемы соответствия цветов, разность в алгоритмах отрисовки, применяемых в GPU и так далее. OpenGL не гарантирует, что на разных версиях изображения будут одинаковыми с точностью до пикселя. Самое лучшее, что можно сделать для получения одной и той же картинки - использовать одну и ту же версию программной отрисовки Mesa во всех случаях жизни. Кстати, X сервер тоже не гарантирует точность до пикселя. Как правило, я считаю картинки достаточно похожими, если нужна лупа, чтобы разглядеть разницу. Люди часто не понимают этого. Если дать OpenGL растровое изображение для показа, он скопирует эти пиксели на экран без изменений, если не указано иное. Проблема пиксельной точности отрисовки скорее относится к векторной графике, например, линиям.
Субпиксельно-сглаженные шрифты не проблема. OpenGL предоставляет разнличные пути для их отображения. Если необходимо, OpenGL может использовать тот же механизм отображения глифов, который сегодня использует X server. Так как это один и тот же механизм, глифы будут выглядеть одинаково. Нежелательно привязывать отображение к конкретному алгоритму, это может сделать невозможными дальнейшие улучшения. Например, эта статья (видео) исследует совершенно новый способ генерации шрифтов на GPU. Есть другая интересная работа "Независимый от разрешения рендеринг кривых посредством программируемых графических микросхем" ["Resolution Independent Curve Rendering using Programmable Graphics Hardware"] Луп [Loop] и Блинн [Blinn] труды SIGGRAPH 2005 (доступной ссылки нет). Если бы отрисовка шрифта была определена с точностью до пикселя, вероятно, было бы возможно использовать эти новые технологии. В этом случае глифы генерируются GPU с использованием аппаратно-встроенных алгоритмов, которые пользователь изменить уже не в силах. Преобразование контурных глифов в пиксели для дальнейшей отрисовки их как смешанных изображений (blended images) - это только один из возможных способов отображения глифов. Программируемые GPU предоставляют и другие варианты. Любым API с долгой историей в будущем понадобится это учесть.22. Три поколения окон.
В настоящей версии Х сервера и во многих других оконных системах, окна выводятся на экран в выделенных областях с использованием закрашивающего алгоритма. Закрашивающий алгоритм работает подобно художнику - каждый последующий слой наносится на предыдущий. Сначала отрисовывается фон, а затем каждое окно поверх предыдущего, как бы нанизываясь на ось Z, направленную перпендикулярно плоскости экрана. Если прозрачность не нужна, и вы знаете, где будут нарисованны все окна, то можно оптимизировать данный алгоритм (как это и делает X сервер), используя прямоугольники отсечения, таким образом, чтобы каждый пиксель наносился на экран только один раз. Производительность может быть улучшена путём отслеживания участков окон, нуждающихся в перерисовке. То есть в перерисовке нуждаются только окна, отображение частей которых должно быть изменено. Благодаря этому методу улучшается комфортность восприятия. Дальнейшее улучшение - метод "сохранения фона" [save unders]. Оконная система учитывает, что при сворачивании таких объектов, как всплывающие меню [popup-menus], необходимо восстанавливать исходное изображение. Метод "сохранение фона" сохраняет изображение под указанными объектами и восстанавливает его при их сворачивании.
Расширение Композиция [Composite] использует аппаратные новинки, появившиеся в современном оборудовании для улучшения производительности. При использовании этого расширения, отрисовка окон делается во внеэкранную, невидимую область видеопамяти. Затем оконный менеджер составляет из этих окон изображение для видимой части. Composite по-прежнему использует все тот же закрашивающий алгоритм, но, поскольку оконный менеджер имеет в своем распоряжении содержимое всех окон, становится возможным организовать частичную прозрачность. Она создаётся смешением содержимого части экрана под верхним окном с изображением в данном окне в тот момент, когда окно копируется в буфер. Это называется альфа-смешением [alpha blending]. Поддержка такого алгоритма есть в большинстве современного обоудования. Мерцания изображения не происходит из-за двойной буферизации [double buffering]. В такой модели всё остаётся двумерным и наложение плоских изображений по оси Z производится в обычном порядке.
Лучшие и поддерживающие мультитекстурность видеокарты могут вообще не использовать закрашивающий алгоритм. Каждое окно, находящееся в какой-либо части экрана, объявляется самостоятельной текстурой. Затем происходит отрисовка многоугольников на экран. Эти многоугольники будут иметь соответствующие их вершинам текстурные координаты для каждого окна/текстуры, затем аппартный комбинатор текстур соберт все окна/текстуры вместе, в результате получится конечное изображение. В предельном случае весь экран можно представить как один многотекстурный прямоугольник! Эта технология обладает чрезвычайно высоким быстродействием, не требуется даже двойной буферизации, так как мерцание изображения минимально.
Xgl реализует композиционную модель. Xgl использует (хотя это и необязательно) одно из новых свойств OpenGL - объекты фреймбуфера [FBO]. С расширением OpenGL объекты фреймбуфера позволили бы очень эффективно давать оконному менеджеру доступ к окнам неактивных приложений. Это совсем не сложно, мы ведь уже умеем делать разделение p-буферов между процессами. Для приложения объекты фреймбуфера выглядят как обычные окна для отрисовки. Для оконного менеджера эти окна выглядят как текстуры. Менеджер может управлять ими с помощью обычных комманд отрисовки мультитекстур. В этой модели окна приложений всё ещё двумерные, но уже возможно написать оконный менеджер, основанный на OpenGL, подобный Освещённость [Luminosity]. Такой менеджер может комбинировать окна, используя Z-буфер, и устранить ограничения старого двумерного порядка по оси Z. Например, окну можно придать форму волны, которая многократно пересекает другое окно.
Наконец-то можно устранить двумерные ограничения на окна приложений и придать им толщину или иные трёхмерные формы. Например, всплывающее [popup] меню действительно могло бы всплывать выше в трёхмерном координатном пространстве. Если объединить это с источником света, отбрасываемые тени станут похожими на настоящие, вместо искусственно подрисованных, как в двумерном случае. Проект организации Sun Зеркало [Looking Glass] как раз является оконным менеджером такого типа. Плотность окон показана в демонстрационномвидеоролике проекта Зеркало. Зеркало выполняет существующие X приложения, используя некорневой режим работы X сервера. Окна с придаваемым им утолщением сочетаются с настоящими трёхмерными приложениями, как в демо ролике автоматической системы, сменяющей компакт-диски. Концепция трёхмерного рабочего стола не так удивительна. Рабочий стол уже стал трёхмерным, с тех пор, как произошел переход от расположенных как плитка окон в Windows 1.0 к перекрывающимся - с тех пор как был введён порядок по оси Z, рабочий стол превратился в трёхмерное пространство без перспективы. Элементы трёхмерности присутствуют повсюду на рабочем столе - взгляните на обычные и всплывающие меню. Серьёзной причиной для создания расширения Composite стала необходимость теней, которые, очевидно, есть двумерное представление трёхмерного пространства. Даже элементы управления подобные кнопкам сделаны объёмными посредством двумерной имитации. Почему бы не нарисовать их в объёме и не позволить пользователю управлять источником света? Прозрачность окон очевидно использует представления об объёме. Почему бы не согласиться, что рабочий стол - это трёхмерное пространство, и не начать использовать аппаратную трёхмерную графику для его отрисовки?
23. Подводя черту.
По этим вопросам до сих пор идут споры. В Линукс в действительности есть только один спсособ реализовать рабочий стол с аппаратным ускорением графики на основе открытого кода √ это Mesa OpenGL. Разумеется, можно было бы создать клон DirectX, но кто, спрашивается, будет писать весь этот код и соответствующие драйвера? OpenGL не такой уж и плохой вариант. OpenGL обязательно присутствует в любой системе. OpenGL стандартизована и этот стандарт контролируется Ассоциацией контроля архитектур [ARB]. OpenGL достаточно разработана и неплохо документирована. OpenGL широко распространена и так же широко применяется. В колледжах OpenGL входит в программу обучения и этой библиотеке посвящено достаточно статей. Многие замечательные приложения (в том числе игры) используют OpenGL.
На каком уровне должен работать драйвер графического устройства? XAA и fbdev делают это на низком уровне. Их API имеют дело только с пикселями в фреймбуфере, битблиттером и, возможно, линиями. Все прочие возможности, предоставляемые видеомикросхемой на этом уровне либо недоступны, либо для их реализации нужны дополнительные API, специфические для каждой микросхемы. В случае Xgl отрисовка происходит совершенно другим способом. Такие драйвера работают чуть ли не на самом высоком уровне с использованием непосредственно OpenGL API. Я считаю такой подход более правильным. Желательно, чтобы драйвер работал на значительно более высоком уровне, чем тот, что зашит собственно в микросхему, чтобы эти прошивки могли и дальше развиваться, не затрагивая высокоуровневые API. Мне кажется, Линукс не выиграет, если ему придется иметь дело с большим числом API, как в случае с DirectX. Более перспективный путь, начав с самого высокого уровня, обеспечить соответствующую программную поддержку - Mesa, а затем заменять возможные части этой программной поддержки на ускоряемые аппаратно - DRI. Далее, для OpenGL существуют различные реализации: Mesa, Nvidia и ATI. Какую их них вы будете использовать, это ваше личное дело; хотите верьте, хотите нет, но некоторые предпочитают коммерческие драйвера.
Xgl задумывался, как переходный вариант на ближайшее будущее. Его цель заключалась в том, чтобы прозрачным образом заменить систему отрисовки в существующем X сервере на совместимую, основанную на OpenGL. Все Х API в Xgl сохранены как первичные, никакие новые добавлены не были, и никакие не были объявлены устаревшими. Xgl это высокоуровневый кроссплатформенный шаблон, точнее его код, который нужно портировать для конкретной реализации OpenGL. Один из таких портов, Xglx, предназначен для GLX API. Другой, Xegl, работает с кроссполатформенным API EGL. Следует заметить, что EGL, в свою очередь, является платформонезависимым способом создания GLX, AGL и WGL API. После добавления Mesa как расширения, EGL может управлять низкоуровневым фреймбуфером. Такого сочетания достаточно для того, чтобы создать оконную систему (подобно существующей в современном X сервере) на простом оборудовании. Но Xgl только временное переходное решение и подпорка EXA, позволяя отдалить срок его внедрения, практически отменяет его необходимость.
Периодически возникает тезис о том, что использовать OpenGL вообще не стоит: в нашем развивающемся мире слишком много устаревшего оборудования. Есть два решения этой проблемы. Вот первое из них. OpenGL является масштабируемым API. При помощи программной эмуляции его можно использовать на оборудовании любого уровня. В то же время, OpenGL ES обеспечивает возможность профилирования API. Профили представляют собой четко определенные подразделы OpenGL API. Если понадобится, мы сможем выделить профиль, содержащий минимальный набор OpenGL API. Размер кода не проблема, доступна проприетарная реализация OpenGL ES размером 100Кb. Существует еще один профиль OpenGL ES, который не требует поддержки плавающей запятой. В общем, ничто не может воспрепятствовать появлению открытых решений, если только найдутся соответсвующие ресурсы.Второе решение. Можно запускать напрямую на данном оборудовании только те приложения, которые для него предназначены. Бесполезно ждать, что "Окна Рог" будут работать на IBM PC, но на той же PC до сих пор без проблем работает DOS. Ключевым моментом является то, что OpenGL более масштабируем, чем EXA. Расширяемость EXA имеет серьезнейший изъян √ она не задействует все расширенные возможности графического процессора, такие как трёхмерная графика и перепрограммируемость. При использовании же OpenGL мы можем иметь один и тот же API как для мобильного телефона, так и для суперкомпьютера.
24. Состыковывая блоки.
Большое количество акронимов, конечно, затрудняет понимание. Рассмотрим некоторые конкретные примеры взаимодействия библиотек:App -> gtk+ -> X -> XAA -> hw
Работа современной версии X сервера. Приложение взаимодействует с графической библиотекой, которая использует xlib API.X сервер осуществляет отрисовку через драйвера XAA. X сервер и приложение, в данном случае, - два разных процесса.
App -> gtk+ -> Cairo -> X Render -> X -> XAA/EXA -> hw
Работа с графической библиотекой, использующей Cairo (через X сервер). Cairo применяет X Render. В случае поддержки EXA, используется аппаратно ускоренная версия X Render. X сервер и приложение - снова два разных процесса.
App -> qt -> Arthur -> X Render -> X -> XAA/EXA -> hw
Arthur библиотека, входящая в QT4 эквивалентная Cairo, действует почти также.
App -> gtk+ -> Cairo -> glitz -> GL -> hw
Работа с графической библиотекой, использующей Cairo (через glitz). Cairo использует модуль glitz для отрисовки, основанной на OpenGL. Используется аппаратное ускорение, все происходит в одном процессе.
App -> gtk+ -> Cairo -> X Render -> Xgl -> EGL(standalone) -> GL -> hw
Случай применения Cairo, xlib, Xegl. Xegl применяет glitz для отрисовки. Glitz направляет отрисовку на видеокарту. Xegl и приложение являются разными процессами. Заметьте, что графическая библиотека может выбрать прямое использование glitz, а значит и отрисовку в одном процессе.
App -> gtk+ -> Cairo -> X Render -> Xgl -> GLX(X) -> GL -> hw
В этом случае графическая библиотека работает через X Render и Xglx сервер. Xglx не отдельный сервер, а включенный (nested). В то же время, он не совсем обычный включенный сервер: он работает как подчиненный только на ввод, а отрисовывает изображение через OpenGL внутри окна, созданного на основном сервере. В полноэкранном режиме вы не увидите основного сервера. В данном случае работают три процесса: приложение, Xglx и обычный X сервер. Приложение использует Xglx, Xglx рисует напрямую через DRI. Третий процесс (X сервер) используется, так как он обеспечивает окно и ввод. Так же с него запускается Xglx.
25. Заглянем в будущее.
Линукс теперь уже точно последняя из крупных систем с графическим рабочим столом, которой нужно научиться использовать всю мощность GPU. При условии, что какой-либо гонки уже нет, требуется, вероятно, какое-то долгосрочное решение. Можно было бы создать новый сервер, основанный на OpenGL и Cairo.
Вообще, сама концепция программируемого графического оборудования отсутсвует в API, подобным xlib и Cairo. Это очень важный момент. Одна из главных новых возможностей GPU - программируемость, просто не доступна из современных API X. OpenGL предоставляет эту возможность посредством языка шейдеров.
Обдумывая вариант нового сервера, крайне необходимо разделить концептуальный дизайн на две составляющие: платформозависимую и платформонезависимую. Драйвера устройств платформозависимы, в предложенной модели OpenGL считается драйвером устройства и, следовательно, будет иметь платформозависимую реализацию. Все моменты, связанные с интеграцией с другими подсистемами Линукс, будут спрятаны внутри соответствующих драйверов. Главный сервер будет реализован с использованием кроссплатформенных API, таких как сокеты, OpenGL и EGL. Необходимо будет указать кроссплатформенные API для устройств, допускающих замену "на лету". Необязательно создавать сервер с нуля. Существенные части кода могут быть взяты из других проектов и должны быть скомбинированы новыми способами. Насколько я вижу, 95 или более процентов кода, необходимого новому серверу, уже существует.
Модульность - ключ к созданию хорошего сервера. Его архитектура должна быть разделена на изолированные библиотеки, взаимодействующие посредством стандартных интерфейсов. Такой способ делает лёгкой замену библиотек. Можно иметь полностью различные реализации библиотеки для различных платформ или много способов реализации этой библиотеки на одной платформе. Конечно, кроссплатформный код имеет свои преимущества. Библиотеки, подобные библиотеке Mesa, можно оставить едиными для всех целевых систем.
Помните, как DirectFB использует некорневой режим работы X сервера? Новый сервер мог бы запускать таким же образом X с программным рендерингом, для достижения обратной совместимости. Модель прямого рендеринга DRI - это хорошее дизайнерское решение, которое должно быть задействовано в будущих серверах. Перевод X сервера в режим обратной совместимости предоставляет полную свободу при проектировании структуры нового сервера.Например, новый сервер может иметь новый сетевой протокол. Недавняя статья в Линукс журнале [Linux Journal] о NoMachine и NX протоколе показывает, что протокол X может быть ужат в соотношении 200:1 и больше. Новый протокол должен быть основан на OpenGL и спроектирован так, чтобы избежать циклических задержек при передаче информации между серверной и клиентской частями X сервера, и обеспечивать долговременное кеширование (сохранение в быстродейстродействующей памяти) изображений. Хром [Chromium] - интересная система, предоставляющая поддержку разделения OpenGL дисплея между несколькими мониторами, соединёнными по сети. Сетевая библиотека Хром производит отслеживание состояния OpenGL, что является одним из способов уменьшения сетевого трафика.
Работу с кешем глифов тоже нужно проанализировать. В текущем X сервере клиент создаёт битмэпы (растровые, точечные отображения) глифов и посылает их серверу, где они кешируются. Эта модель препятствует генерации глифов посредством GPU (эта процедура описана в вышеприведённой статье). Обработка шрифтов на стороне клиента это хорошая идея. Их размещение совершенно определенно должно регулироваться приложением. Однако нет никакой необходимости создавать на стороне клиента битмэпы глифов. Если речь идет о масштабируемых шрифтах, генерируемых GPU, то серверу в этом случае пересылается гораздо больше данных, чем при передаче простого битмэпа.
Новый сервер мог бы исправить современные недоработки в сетевом звуке и печати. Он мог бы поддерживать соответствующую ретрансляцию для перемещаемых сессий. С самого начала такой сервер должен быть спроектирован с поддержкой многопользовательского режима.
Обработка событий - хороший пример реализации чего-либо посредством библиотек. Линукс имеет подсистемы evdev, kernel hotplug, HAL и D-BUS, подобные которым не существуют на большинстве других платформ. Поэтому подсистема ввода для BSD и выглядит настолько отличающейся от спроектированной для Линукс. Делая главные подсистемы модульными, мы можем адаптировать их и полностью задействовать возможности окружения, в котором эти подсистемы работают. Это подход, отличный от того, при котором основная цель состоит в поиске наибольшего компромиса между различными окружениями.
X используется разными разведовательными службами во всём мире. Про его нынешнюю реализацию известно, что она недостаточна надежна при работе с секретными документами. Новый сервер будет спроектирован правильно, только если с самого начала выстраивать его структуру с полным учётом требований безопасности. Cоответствующая финансовая поддержка могла бы быть предоставлена, при условии, что все эти требования будут реализованы гарантировано правильно.
Короче говоря, есть много вещей, которые надо сделать и последние разработки ведутся с учётом указанных требований. Первоочередные вопросы - это программа управления памятью для DRM и переработка кода, необходимая для задействования объектов фреймбуфера [FBO] в драйверах DRI. Далее, исключение драйверов fbdev, работающих с оборудованием, для которого есть драйверы DRM. Когда эти подготовительная работа будет проделана, можно начинать и работу над проектом нового сервера.
26. Выводы.
Мой опыт с провалом Xegl подсказал мне, что построение графической системы большая и сложная работа - слишком сложная для одного или двух человек. В целом, сообщество X.org вряд ли имеет достаточно ресурсов для построения сервера. Разбиение этих ресурсов на части ведёт лишь к множеству полузаконченых проектов. Я знаю, что разработчики предпочитают работать только над тем, что им интересно, но применительно к ресурсам доступным X.org этот подход не приведёт в ближайшем будущем к выходу нового сервера или даже полностью конкуретоспособного рабочего стола, основанного на старом сервере . Возможно, наступило время для X.org выработать стратегию, которой все должны следовать.