Наши партнеры

Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

На главную -> MyLDP -> Тематический каталог -> Графические оболочки Линукс

Жизнь "после X"

Оригинал: "LPC: Life after X"
Автор: Jonathan Corbet
Дата публикации: November 5, 2010
Перевод: Н.Ромоданов
Дата перевода: декабрь 2010 г.

Кейт Пакард (Keith Packard) сделал, вероятно, больше, чем кто-либо другой, чтобы система X Window оказалась на наших рабочих столах. В течение своей 25-летней истории система X работала исправно, но нет ничего вечного. Похоже, что время X Window подходит к концу. Но что придет ей на смену? В своем выступлении на конференции Linux Plumbers Conference Кейт Пакард заявил, что никто не в курсе, куда все движется, но у него есть относительно этого несколько соображений. Эти соображения помогут с интересом взглянуть на будущее наших графических систем.

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

Кейт Пакард задает вопрос: как в этих приложениях поддерживается прозрачность работы в сети, что является одной из главных особенностей X? Как в них обеспечивается совместимость с требованиями ICCCM? И как в них вообще используется система X? Конечно, ответом на все эти вопросы будет - "очень слабо". Наоборот, разработчики, создающие такие системы, скорее всего, недовольны системой X из-за ее сложности, из-за ее затрат по памяти и нагрузки на процессор, а также из-за того, что она долго загружается. Они бы с удовольствием от нее отказались. Как считает Кейт Пакард, им надо помочь без потерь для всех остальных.

По пути к будущему без X

К лучшему или к худшему, но в настоящее время есть много различных API рендеринга, из которых есть что выбрать при создании графических библиотек. По словам Кейта Пакарда, из них интересны только два варианта. Для видео рендеринга есть пара VDPAU / VAAPI (объяснения некоторых аббревиатур смотрите в конце статьи), а для всего остального есть OpenGL. В будущем другие API интереса представлять не будут.

В эпоху прямого рендеринга ни одно из этих API фактически не зависит от X. Так чем же ценна система X? На сервере X еще много что делается и, прежде всего, настройки видеорежимов. Основная часть этой работы, по крайней мере для графических чипсетов "большой тройки", уже перенесена в ядро, но все еще есть то, что требуется делать в X. Если вы все еще хотите создавать скучные 2D-графики, то, по словам Кейта Пакарда, X - для вас, любителей уродливых линий и рваного текста. В X все еще выполняется большая обработка, связанная с вводом данных; интерфейс ядра evdev делает некоторую часть этой работы, но это далеко не все. В X обеспечивается отображение клавиш; опять же, все, что из этого выполняется ядром, это - "примитив". В X обрабатывается вырезание частей изображений в случаях, когда окна приложений накладываются друг на друга, в X также с помощью расширения GLX осуществляется управление 3D объектами.

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

Но с тех пор, как 25 лет назад начала использоваться система X Window, многое изменилось. В 1985 году системы Unix не поддерживали совместную работу с библиотеками; если пользователь запускал два приложения, слинкованные с одной и той же библиотекой, то в память, которая в то время была дефицитным ресурсом, помещались две копии этой библиотеки. Так что имело смысл выделять графический код в отдельный центральный сервер (X), где он мог одновременно использоваться несколькими приложениями. Теперь этого делать не нужно, поскольку наши системы гораздо лучше используют один и тот же код, который можно располагать в различных адресных пространствах.

У нас также более сложные приложения, раньше все, что было, это - xterm. Сейчас приложения обрабатывают большой объем графических данных, и почти в каждой операции требуется работать с изображениями. Приложения, использующие дистанционный доступ, реализованы с помощью таких протоколов, как HTTP, им больше не требуется использовать протокол X. У нас есть графические средства, с помощью которых можно реализовать графические темы динамически, при этом больше нет необходимости запускать специальный менеджер окон, реализующий конкретную тему. Стало проще получить "более быстрый" отклик системы. Множество функций, реализованных в сервере X, были разработаны во времена, когда системы работали медленно. Сейчас у нас есть цветные мониторы, которые были редки и дороги в те дни, когда система X только что появилась.

Со временем оконная система была разделена на несколько частей: сервер X, оконный менеджер, композитный менеджер, и т.д. Все части связаны между собой с помощью сложных асинхронных протоколов. В результате снижается производительность системы, например, нажатие каждой клавиши должно быть обработано, по крайней мере, тремя процессами: приложением, сервером X и композитным менеджером. Но нам не следует больше пользоваться таким подходом; мы можем упростить архитектуру и повысить быстродействие. Есть некоторые нерешенные проблемы, возникающие при смене подхода: не ясно, как осуществлять поддержку всех тех 3D эффектов, которые могут быть реализованы такими оконными / композитными менеджерами, как compiz, но, может быть, нам все они и не нужны.

А как в мире, свободном от X, будут работать приложения, запускающиеся дистанционно? Кейт Пакард полагает, что больше нет необходимости в сетевой прозрачности в стиле X. Одними из первых приложений, в которых использовалась сетевая прозрачность, были приложения с формами ввода и диалоговыми окнами, а сейчас все это реализуется с помощью веб-браузеров. В ряде приложений используются такие инструментальные средства, как VNC и rdesktop, которые работают лучше, чем исходная система X. В некоторых случаях для дистанционного доступа могут потребоваться такие технологии, как беспроводный дисплей WiDi (Wireless Display фирмы Intel).

Что нужно сделать

Так, может быть, можно отказаться от X? Но, как уже было ранее сказано, все еще есть ряд важных функций, которые выполняет сервер X. Если сервера X не будет, то эти функции нужно будет выполнять в другом месте. Настройка режимов перемещается в ядро, но есть еще масса устройств, настройка которых не поддерживается в ядре (в режиме Kernel Mode Setting - KMS). Для них кто-то должен будет написать драйвера KMS, либо эти устройства, в конечном счете, перестанут работать. Поддержка устройств ввода частично выполняется при помощи evdev. Сейчас управление графической памятью в ряде случаев осуществляется в ядре с помощью пакета GEM. Иными словами, работа перемещается в ядро. Кейт Пакард, кажется, был доволен пониманием совокупности проблем, связанных с общими функциональными возможностями.

Хотя кое с чем есть проблемы. Одной из них является правильное отображение клавиш; его не нужно (и не следует) делать в ядре. Для того, чтобы отображение клавиш можно было выполнять непосредственно в приложениях, выполняются работы по созданию библиотеки libxkbcommon. Все другие аналогичные действия, например, работа с клавишами мыши и залипанием клавиш, также должны обрабатываться где-нибудь в пользовательском пространстве. Проблема с драйверами ввода решена не полностью; для сложных устройств (например, сенсорных панелей) поддержку нужно также реализовывать в пользовательском пространстве. Некоторые функции должны выполняться проще, задача в большинстве случаев состоит в том, чтобы заменить интерфейсы API на более эффективные варианты. Так GLX можно заменить на EGL, во многих случаях вместо OpenGL можно использовать GLES, а VDPAU является улучшением в сравнении с Xv. Есть также определенная проблема, связанная с созданием единого пользовательского интерфейса при одновременном запуске приложений, использующих X, и приложений, не использующих X.

Кейт Пакард рассказал о некоторых положительных результатах, полученных попутно в процессе выполнения работ; многие из них окажутся полезными в будущем. Например, механизм композитности (наложения изображений — прим.пер.), был использован для добавления модных эффектов в 2D-приложения. Как только у разработчиков X появился этот механизм, они поняли, что с его помощью можно отображать окна без необходимости вырезать их части, что сильно упрощает дело. При этом рендеринг отделяется от процесса изменения содержимого на экране. Эти две задачи раньше были тесно связаны друг с другом, в результате возможности рендеринга существенно расширяются. Пакет GEM предназначен для решения ряда задач, в том числе для организации страничного доступа к видеопамяти, в результате можно из растровых изображений создавать специальные текстурные копии и осуществлять непрерывное управление 3D объектами. Кроме того, что благодаря GEM можно пользоваться прямым рендерингом без блокировок и это улучшает производительность, появляется возможность без снижения производительности запускать несколько оконных систем. Механизм настройки режимов в ядре (Kernel mode setting) был предназначен для повышения надежности графических настроек и для получения возможности отображать сообщения kernel panic, но этот же механизм облегчает создание альтернативных оконных систем, и даже позволяет запускать приложения вообще без оконной системы. Графическая библиотека EGL была создана для портирования приложений с платформы на платформу; с ее помощью можно запускать графические приложения в системах без X и выводить дамп буфера GLX.

Кейт Пакард показал два рисунка, демонстрирующих организацию графической системы в Linux. На рисунке "до" изображена куча интерфейсов, обращающихся к серверу X, который изображен в центре рисунка. На рисунке "после" вместо него в центре находится ядро Linux, а оконные системы, такие как X и Wayland, смещены в сторону точно также, как и другие специализированные приложения. Когда мы доберемся до схемы "после", мы получим более простую графическую систему, которая позволит достичь большей гибкости и улучшить производительность.

Естественно, чтобы достичь этого, потребуется еще кое-что сделать. Еще предстоит работа по полному интегрированию библиотек GL и VDPAU в систему. Нужно еще решить проблемы с драйверами ввода, а также решить вопрос о поддержке механизма KMS для видеоадаптеров, поставляемых не только "большой тройкой". Если мы хотим избавиться от каких-нибудь оконных менеджеров, то кто-то должен выполнять за них работу; в Windows и Mac OS эта задача решается в приложениях, может быть, и мы должны поступить аналогичным образом. Но, что касается всего другого, это будущее уже, в основном, наступило. Можно, например, запускать систему X в качестве клиента Wayland или наоборот. Начинается эпоха "после X".

Примечание переводчика

В статье используются следующие сокращения:

VDPAU (Video Decode and Presentation API for Unix) является библиотекой с открытым кодом (libvdpau) и интерфейсом API, первоначально разработанные фирмой NVIDIA для карт GeForce серии 8 и последующих серий. Библиотека и интерфейс предназначены для использования в системе X Window. С помощью этого VDPAU API можно разгрузить программы видеообработки, перенаправив часть работы по обработке видео в аппаратно реализованный GPU .

VAAPI (Video Acceleration API) является библиотекой с открытым кодом (libVA) и интерфейсом API. С их помощью можно при обработке видео получать доступ к аппаратным средствам ускорения обработки. Библиотека и интерфейс предназначены для использования в системе X.

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

GEM (The Graphics Execution Manager) является комплексом программ, разработанных фирмой Intel и предназначенных для управления памятью в драйверах графических чипсетов. GEM была создана как более простая альтернатива менеджеру памяти Translation Table Maps (TTM), разработанному фирмой Tungsten Graphics.

EGL (Embedded-System Graphics Library) является графической библиотекой для встроенных систем. Представляет собой интерфейс между интерфейсами API, осуществляющими рендеринг, такими как OpenGL ES, и аппаратно реализуемыми функциями.

Xv (X video extension) является расширением, позволяющим ускорить вывод видеофрагментов на экран с использованием возможностей графической платы и уменьшить тем самым нагрузку на центральный процессор.

На нашем сайте опубликованы еще 2 статьи на тему будущего графического интерфейса в Linux: