иксы в линукс что это

Сетевые соединения X11

Есть две технологии в ИТ, которые казалось должны были исчезнуть на рубеже прошлого века, но их живучесть и удобство раз за разом отодвигает их уход со сцены. Речь идет об IPv4 и X11. Если первый из них практически во всех аспектах уступает IPv6, то преимущества Wayland, как технологии над X11 очевидны не всем. Wayland вовсе не универсален, как X Windows System, он намного более прост. Это дает ему ряд преимуществ по сравнению с иксами, но в этом же кроются его недостатки.

Если говорить о преимуществах, то это в первую очередь простота реализации и долгожданное избавление пользователей графической среды Linux от таких артефактов перерисовки, как разрывы изображения, a․ k․ a․ tearing. С этим особенно часто сталкиваются обладатели видеокарт NVidia. Хватает и недостатков и противники замены X-сервера напирают на гибкость использования сетевых возможностей в различных сценариях.

As mentioned, X is essentially a networking protocol with graphical displaying capabilities.

▍ Сетевая структура взаимодействий X-сервера

Наиболее распространенным IPC, т․ е․ способом взаимодействия между процессами, X-клиента и X-сервера, являются сокеты. Их роль в предоставлении API связи с использование TCP/IP, а также сокетов домена Unix. Помимо сокетов клиент и сервер для коммуникации могут также использовать иные каналы IPC, например MIT Shared Memory Extension.

Доменные сокеты Unix (от англ. Unix Domain Sockets, UDS) являются POSIX-механизмом IPC, с помощью которого различные процессы ОС могут взаимодействовать друг с другом. Такие сокеты эффективнее локальных TCP/IP соединений, так как не требуют дополнительных байтов в заголовке протокола. Подобно сокетам TCP/IP, доменные сокеты Unix поддерживают надёжную потоковую передачу данных с помощью SOCK_STREAM. Они также могут работать в режиме упорядоченной ( см․ SOCK_SEQPACKET) и неупорядоченной ( см․ SOCK_DGRAM) передачи датаграмм.

Рис. 1 Сетевое взаимодействие между клиентом и сервером X с помощью UDS.

UDS используют файловую систему ОС в качестве адресного пространства имён (например /tmp/my_xapp ), сами сокеты в ней всего лишь inode, а процессы обращаются к сокетам, так же, как к файлу. Однако обмен данными в активном соединении использует не файловую систему, а только буферы памяти ядра.

Рис. 2 Сетевое взаимодействие между клиентом и сервером X поверх TCP/IP.

Количество таких интерфейсов определено константой NUMTRANS в файле X11/Xtrans/Xtrans.c.

Таблица Xtransports[] определена в том же самом файле и содержит 10 элементов, таким образом NUMTRANS ≤ 10.

Проследив цепочку до системного вызова socket() находим такую последовательность транспортных процедур.

▍ Взгляд изнутри трафика между клиентом и сервером X

Запустим простейшую иксовую программу Xclock и проверим как все это работает на практике.

Рис. 3 Установка параметров соединения в сессии X11.

Рис. 4 Сетевой след соединения X11 в WireShark.

То же самое и во всех подробностях можно увидеть в tshark в текстовом формате. Так выглядит клиентский запрос X11 в сторону сервера.

Пакет с ответом со стороны X-сервера совсем не так лаконичен, в нем указаны все необходимые детали для форматирования графического вывода на экран.

▍ Удаленное подключение к X-серверу по ssh

Переходя от теории сетевых взаимодействий X Window System к практике, рассмотрим, как запустить графическое приложение на уделенном X-сервере при подключении по ssh.

/.Xauthority y. Если все нормально, то файл уже создан и проверка показывает на наличие MAGIC COOKIE.

Рис. 5 Собственно xclock, значит удаленные иксы настроены и работают.

Я стараюсь по мере возможности тестировать сеанс Wayland при каждом новом релизе KDE Plasma, несмотря на многочисленные улучшения с каждым разом, на версии kde-apps-21.04.3 работать можно лишь на Plasma-X11. В чем бы не состояли преимущества Wayland, до тех пор пока в терминале зависает команда man, хаотично прыгают элементы ниспадающего меню и блуждает внешний монитор, старый и добрый X Window System остается вне конкуренции. Надеюсь так не будет продолжаться долго.

Источник

X Window System

Обратите внимание на то, что все заглавные буквы «X» в этой лекции — латинские.

На свете существует множество графических устройств, управление которыми на низком уровне (вывод изображений и ввод данных, например, о перемещении мыши) — задача совсем не для пользователя, тем более, что каждый вид устройства управляется по-своему. Заботы о вводе и выводе на низком уровне берёт на себя графическая подсистема Linux — X Window System, предоставляя пользовательским программам возможность работать в терминах оконного интерфейса.

X Window System появилась всё в той же UNIX, проект этот был настолько наукоёмок и настолько полно охватывал тогдашнюю область задач, связанную с графикой, что ему так и не возникло никаких серьёзных альтернатив.

X-сервер и X-клиенты. Протокол X11

X Window System использует традиционную оконную модель, в которой пространством ресурсов является экран. Экран — это прямоугольник, на котором отображаются команды графического вывода и организуется обратная связь с устройствами графического ввода. Пример обратной связи — указатель мыши. Сама мышь — довольно простое устройство ввода, способное передавать информацию о его перемещении и состоянии кнопок. Указатель же отображает мнение подсистемы об абсолютных координатах гипотетической «точки ввода».

Иллюстрация 3. Расположение точки ввода (фокус)

В примере указатель мыши показывает расположение точки ввода (на кнопке « WindowMaker »). Если сейчас Мефодий нажмёт на левую клавиу мыши, графическая подсистема зафиксирует это событие ввода и передаст его той задаче, которой принадлежит соответствующая кнопка. Именно задачи (а не сидящий за монитором пользователь) и являются субъектами для X Window System, между ними разделяются графические ресурсы. Каждой задаче принадлежит одно или несколько окон, представленных некоторой (как правило, прямоугольной) частью экрана. Внутри окна выполняются графические операции (вывод) и именно окнам передаётся поток данных от устройств ввода. Какое окно получит события ввода — определяется с помощью синтетического понятия фокус: вводимые данные передаются от графической подсиcтемы только тому окну, которое «получило фокус», по умолчанию это происходит, когда указатель мыши попадает в часть экрана, занимаемую этим окном.

В более сложном случае окна могут перекрываться, частично занимая один и тот же участок экрана. Если дополнительно постановить, что каждое из них лежит на своей глубине, то самое «верхнее» будет отображаться полностью, и ему будет доступен для вывода и получения фокуса весь заказанный прямоугольник. Следующее за верхним окно может быть им «загорожено», тогда отображается только часть этого окна, которую «видно из-под» верхнего. Заметим, что выводить это окно может в пределах всего заказанного прямоугольника, просто видно может быть не всё, и управление фокусом будет происходить на основании видимой части окна.

Программа, которая отвечает за работу с устройствами графического ввода и вывода и обеспечивает при этом логику оконной системы, называется X-сервером (X Server, то есть сервер системы «Икс»). В рамках X Window System, X-сервер — это ядро. Подобно ядру, он выполняет низкоуровневые операции и взаимодействует с аппаратурой, ничего самостоятельно не предпринимая. Подобно ядру, он предоставляет задачам унифицированный интерфейс к этим низкоуровневым функциям, а также занимается разделением доступа (окно и фокус) к графическим ресурсам. X-сервер не волнует, отчего эти задачи вообще появляются и чем живут. Он только принимает запросы на выполнение графических действий и передаёт по назначению вводимые данные. Жизнеобеспечение процессов и даже способ передачи X-запросов — дело исключительно операционной системы, по отношению к которой и сам X-сервер — задача.

Задачи, которые обращаются к X-серверу с запросами, называются X-клиентами. Обычно X-клиент сначала регистрирует окно (можно несколько), которое и будет ему полем ввода-вывода. Потом он сможет рисовать в этом окне и обрабатывать происходящие с окном события: активность устройств ввода и изменение свойств самого окна (размер, перемещение, превращение в иконку, закрытие и т. п.). X-клиент в Linux — это процесс, запускаемый обычно в фоне (не связанный по вводу с терминальной линией). В самом деле, зачем процессу читать с терминала, когда для ввода он может использовать X-сервер? Если с X-сервером связаться не удастся, на стандартном выводе ошибок может появиться какое-нибудь сообщение — его легко перенаправить в файл.

X-сервер Программа, принимающая и обрабатывающая X-запросы.

Клиент передаёт серверу X-запросы любым доступным ему способом. В разных версиях Linux, например, могут использоваться различные объекты файловой системы (чаще всего — т. н. сокеты, сходные по функциональности с двунаправленными каналами). Во многих случаях запросы передаются по сети, при этом неважно, какой именно транспортный уровень будет использован для соединения клиента с сервером (в современных системах это, чаще всего, сеть TCP/IP и протокол TCP). Главное, чтобы клиент посылал стандартные запросы, соответствующие определённому протоколу обмена данными. Кстати сказать, другое имя X Window System — X11 (или X11R6) — это просто номер версии X-протокола, стандартизующего X-запросы, при этом «R6» обозначает номер подверсии (revision) и вполне может увеличиться, если X11R6 устареет настолько, что потребует нового пересмотра (revision).

«Голый» X-сервер, к которому ни присоединён ни один X-клиент, можно запустить из командной строки, для этого достаточно выполнить команду « X » (одна заглавная латинская буква X). Именно так и поступил Мефодий, текстовая консоль сменилась чёрным экраном без всяких окон.

В некоторых вариантах X Window System экран по умолчанию раскрашивается в чёрно-белую крапинку.

Эта функция не будет работать, если в конфигурационном файле X-сервера включён параметр « DontVTSwitch ».

DISPLAY

$ export DISPLAY=:0
methody@susanin:

$ xcalc &

Пример 1. Запуск X-клиента из виртуальной консоли

Иллюстрация 4. Запуск X-клиента

Итак, X-сервер запускается на одном компьютере, а X-клиенты вполне могут работать на других (причём на нескольких!), посылая ему запросы. С точки зрения человека, сидящего за (обратите внимание!) X-сервером, каждый такой клиент представлен в виде окна. Требования к аппаратуре на машинах, запускающих X- клиенты, будут изрядно отличаться от требований к аппаратуре машины для X- сервера. Типичная машина с X-сервером — это рабочее место (workstation). Она должна быть оборудована качественными устройствами ввода-вывода — монитором, видеокартой, клавиатурой и мышью. Что же касается её вычислительных способностей, то их должно быть достаточно для выполнения X-запросов, и только. Такой компьютер не обязан работать под управлением Linux, на нём даже может вообще не быть операционной системы! В восьмидесятые годы выпускались подобные устройства, называемые «X-терминал» (X terminal).

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

В отличие от машины с X-сервером, компьютер для запуска X-клиентов может совсем не иметь устройств графического ввода-вывода. Его задача в том, чтобы все X-программы и запустившие их пользователи не мешали друг другу работать. На такой машине нужна хорошо настронная операционная среда, с достаточным для запуска многих процессов быстродействием и объёмом оперативной памяти. Пара X11R6–Linux весьма неплохо работает на т. н. бездисковых комплексах. Рабочие станции в таких комплексах — самые настоящие X-терминалы, они не имеют жёстких дисков. Вся работа происходит на центральном компьютере, с которого на рабочую станцию загружается по сети урезанный вариант системы, достаточный для запуска X-сервера, и сам X-сервер. В таких комплексах администрировать нужно одну только центральную машину, они надёжнее компьютерных залов и, что немаловажно, стоят дешевле, причём в качестве X-терминалов можно использовать и довольно маломощные, пожилые компьютеры.

Виртуальный сервер

Виртуальный X-сервер может вообще никаких действий не выполнять, а только передавать X-запросы куда-нибудь дальше, например, «настоящему» X-серверу. Так поступает демон Secure Shell, sshd (программа терминального доступа, о которой шла речь в лекции Сетевые и серверные возможности), переправляя X-запросы X-серверу в зашифрованном виде. Этим свойством sshd можно воспользоваться, если сообщение по X-протоколу между двумя компьютерами невозможно (запрещено межсетевым экраном), или вы считаете такое соединение небезопасным.

ssh methody@fuji
methody@fuji’s password:
Last login: Sat Dec 25 13:26:40 2004 from localhost
methody@fuji:

$ xcalc
Error: Can’t open display:
methody@fuji:

$ export DISPLAY=sakura:0
methody@fuji:

$ xcalc
Error: Can’t open display: sakura:0
methody@fuji:

$ logout
Connection to fuji closed.
methody@sakura:

Демон SSH заводит виртуальный X-сервер на удалённой машине, причём номер_сервера обычно заводится таким, чтобы не пересекаться с X-серверами, которые могут быть запущены на этой машине (в примере номер_сервера равен 10). Виртуальный sshd-X сервер принимает все X-запросы с того же компьютера и передаёт их — в зашифрованном виде — на компьютер, где запущен ssh и невиртуальный X-сервер. Здесь все X-запросы вынимаются из SSH-«водопровода» и передаются местному серверу, как если бы они исходили от местного X-клиента (так оно и сеть: этот клиент — ssh ).

XFree86 и XOrg

Наиболее распространённая версия реализации X11R6 называется XFree86. Эта графическая подсистема изначально проектирвалась как реализация X11R5 для машин архитектуры i386 — самых распространённых на сегодня персональных компьютеров. Главная особенность этой архитектуры — бесчисленное многобразие устройств графического вывода (т. н. видеокарт) и непрестанное нарушение их разработчиками всех мыслимых стандартов. Поэтому главной задачей создателей XFree86 было устроить гибкую структуру компоновки и настройки X-сервера в соответсвии с подвернувшимся под руку устройством графического вывода, а заодно и ввода, потому что клавиатур, мышей и заменяющих их устройств на свете тоже немало. Сегодня XFree86 существует для многих архитектур и многих операционных систем.

В последние годы параллельно с XFree86 развивается основанная на тех же исходных текстах X Window System графическая подсистема XOrg. До недавнего времени по спектру поддерживаемого оборудования, архитектур и функциональности XOrg мало чем отличалась от XFree86, и сейчас они примерно эквивалентны с точки зрения пользователя. Однако направления развития этих двух проектов, состав их разработчиков и лицензионная политика несхожи. В ближайшем будущем вполне вероятно, что Xorg обгонит XFree86 и по возмпожностям, и по частоте использования.

Конфигурация X-сервера

Мы рассмотрим конфигурацию графической подсистемы на примере XFree86. Файл XF86Config-4 структурирован: состоит из нескольких обязательных разделов, которые могут следовать в любом порядке. В раздел объединяется часть профиля, связанная с одной из сторон деятельности X-сервера. Каждый раздел имеет такую структуру:

Files Пути к файлам с ресурсами, необходимыми X-серверу
ServerFlags Общие параметры X-сервера
Module Расширения, которые следует загрузить
InputDevice Описание устройств ввода
Device Описание устройства вывода (видеокарты)
Monitor Описание монитора
Modes Описание видеорежимов
Screen Описание экрана (связывает монитор и видеокарту)
ServerLayout Конфигурация сервера

Пример 4. Разделы XF86Config

Section «ServerLayout»
Identifier «layout1»
Screen «screen1»
InputDevice «Mouse1» «CorePointer»
InputDevice «Keyboard1» «CoreKeyboard»
EndSection

Пример 5. Раздел ServerLayout конфигурацонного файла XF86Config

Модули и расширения

Требование гибкости привело к тому, что в реализации XFree86 и XOrg графическая подсистема стала совсем уже похожа на операционную систему. Сам X-сервер играет роль ядра. Запускаясь, сервер подгружает драйверы — специальные компоненты, работающие с выбранной видеокартой, и модули — компоненты, расширяющие функциональные возможности сервера (в конфигурационном файле XF86Config необходимые модули перечисляются в разделе Modules ). Есть весьма нужные расширения, вроде glx (высокоуровневые функции трёхмерной графики) или freetype (поддержка шрифтов TrueType), а есть экзотические, которые иногда могут понадобиться, напрмер, RECORD, позволяющее записывать, а после — «проигрывать» все происходящие с сервером события.

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

Источник

Иксы в линукс что это

И последнее, о чем следует знать, — это о текстовом (консольном) и графическом режимах работы. Ибо непонимание их отличий является источником множества недоразумений, связанных, например, с поддержкой видеокарт, различием клавиатурных раскладок в консоли и в Иксах, и так далее.

Так вот, Linux изначально предназначался для работы в текстовом режиме. В коем и поддерживает все видеокарты, соответствующие стандарту VESA — то есть все, изготовленные человечеством за последние полтора десятка лет. Правда, в ядре его есть и поддержка собственно графического режима — через так называемый линейный кадровый буфер(frame buffer). Однако программ, использующих такой режим, очень немного.

Основным же способом вывода графики в Linux является оконная система X (X Window System) или, в просторечии, Иксы. Это — не часть Linux’а, а именно самостоятельная система, предназначенная для работы поверх любых Unix-подобных операционок (и не только их). Тем не менее, она стандартно входит во все дистрибутивы Linux общего назначения, за исключением специализированных (например, сугубо серверных). И часто устанавливается по умолчанию.

Установить Иксы мало — их нужно еще и должным образом настроить. В понятие это входит определение видеокарты, характеристик монитора, мыши, установка экранного разрешения, и так далее. С большинством вопросов, касающихся распознавания «железа», успешно справляются инсталляторы юзерофильных дистрибутивов, и соответствующие параметры устанавливаются автоматически (хотя тут часто допустимы и ручные коррективы). А вот доведение до конца локализации предоставляется пользователю: он может указать желаемую клавиатурную раскладку (например, русскую), ее вариант (в современных условиях обычно winkeys — для Windows-маркированных клавиатур), переключатель с латиницы на кириллицу, и так далее.

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

Однако и настройкой Иксов дело не заканчивается. Так как сама по себе оконная система X не способна выполнить никакие пользовательские задачи. Для этого она требует специальной программы — менеджера окон или интегрированной рабочей среды (так называемого пользовательского десктопа). Выбор таковых развитые инсталляторы также предоставляют пользователю.

И, наконец, последнее. Традиционный способ авторизации в Linux — задание логина и пароля в текстовом режиме. После чего Иксы можно (и обычно — нужно) запустить вручную специальной командой. Однако возможна и автоматическая загрузка Иксов при старте системы — и сейчас в юзерофильных дистрибутивах именно это, как правило, и практикуется. В этом случае авторизация происходит посредством специальной программы — десктоп-менеджера. Который, помимо всего прочего, позволяет обычно выбрать менеджер окон или интегрированную среду.

Источник

Графический стек Linux

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика).

Я постоянно дёргал их, снова и снова расспрашивал о всяких мелочах, а потом эти мелочи благополучно забывал. В конце концов, я задал им вопрос — а нет ли какого-нибудь обзорного документа, уткнувшись в который я бы избавил ребят от своего назойливого внимания? Не получив утвердительного ответа я решил написать эту статью, которая по завершению была вычитана Эдэмом Джексоном и Дэвидом Эйрли. Они оба работают над этим стеком.

Я хочу вас предупредить, дорогие читатели — такое устройство большой части графического стека Linux, каким оно показано в этой статье, справедливо для открытых драйверов. Это означает, что внутри проприетарных драйверов от AMD или nVidia всё может быть немного не так. Или не совсем так. Или вообще не так. У них могут быть как свои собственные реализации OpenGL, так и скопированная реализация Mesa. Я буду описывать тот стек, который реализуется в открытых драйверах “radeon”, “noveau” и драйверах фирмы Intel.

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

Для начала я прямо тут кратко распишу все компоненты стека. Ну, для того, чтобы вы в общих чертах в них ориентировались по ходу дальнейшего описания.

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

Трёхмерная отрисовка с помощью OpenGL

Двухмерная отрисовка с помощью cairo

Ну, и для того, чтобы получить нарисованное на экране, Xorg сам с помощью KMS и драйверов видеокарты подготавливает кадровый буфер.

X Window System, X11, Xlib, Xorg

X11 напрямую не относится к графической системе — в него включена система доставки сообщений, описание свойств окон и многое другое. Кроме того, поверх X11 реализована куча вещей, вообще не имеющих отношение к графике (например, буфер обмена и поддержка “drag-and-drop”). Я пишу о X11 тут только для общего понимания его места внутри X Window System. Надеюсь, когда-нибудь получится написать отдельный пост об X Window System, X11 и их странной архитектуре.

Я стараюсь быть максимально аккуратным в именованиях. Если я пишу «X-сервер», то я говорю про абстрактный сервер X — это может быть Xorg, может быть реализация сервера X от Apple, а может быть и Kdrive. Без разницы. Если же я пишу “X11” или “X Window System”, то это значит, что я имею в виду архитектуру протокола и системы в целом. Ну а если я пишу “Xorg” — то это про детали реализации Xorg, самого распространённого X-сервера и ни в коей мере не про детали реализации каких-либо других X-серверов. Если вы встретите просто “X” — это опечатка или косяк.

X11 (сам протокол) разрабатывался с целью быть расширяемым (т.е. с возможностью добавления новых фич без создания принципиально нового протокола и без потери обратной совместимости со старыми клиентами). Для примера, xeyes и oclock выглядят, скажем так, «нестандартно», из-за Shape Extension, которое позволяет использовать окна непрямоугольной формы. Если вам не очень понятно, с помощью какой магии эта функциональность появляется из ниоткуда, то вот ответ: магия тут ни при чём. Поддержка расширения должна быть добавлена на обеих сторонах — и у клиента, и у сервера. В базовой спецификации протокола есть специальный функционал для получения клиентами информации от сервера о доступных расширениях. С помощью этого функционала клиенты могут решать, что использовать, а что ­— нет.

В архитектуру X11 была заложена возможность быть прозрачным для сетевой среды. Проще говоря, мы не можем полагаться на то, что клиентская и серверная части (X-сервер и X-клиент) находятся на одной машине, поэтому общение между ними должно быть реализовано посредством сети. На самом деле, современные среды рабочего стола в обычной конфигурации так не работают, потому что, кроме X11 в интерпроцессном взаимодействии участвуют, например, всякие DBus. Работа же по сетевому соединению достаточно интенсивна и порождает большое количество трафика. Когда клиентская и серверная часть X Window System находятся на одной машине, вместо общения посредством сетевого соединения они общаются через UNIX-сокет и это здорово снижает нагрузку на ядро.

К X Window System и ряду его расширений мы вернёмся чуть-чуть позже.

Cairo

Сairo может рисовать на поверхностях X11 через специальный Xlib-бэкенд.

В GTK+2 вплоть до версии 2.8 cairo использовался как опциональный компонент. В настоящее время для GTK+3 cairo считается обязательным.

Расширение XRender

Для поддержки отрисовки примитивов с антиалиасингом в протоколе X11 есть специальное расширение, XRender (базовые операции рисования протокола X11 не используют антиалиасинг). Кроме отрисовки примитивов с антиалиасингом, это расширение позволяет использовать градиенты, матричные трансформации и т.д.

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

К сожалению, практика показала, что программная растеризация (в силу достаточно неочевидных причин) ничуть не уступает в скорости аппаратной. Ну да ладно.

XRender работает с выравненными трапециями — четырёхугольниками с, возможно, непараллельными левой и правой сторонами. Карл Уорт и Кейт Пэккард разработали для отрисовки этих примитивов достаточно быстрый программный метод. У выравненных трапеций есть ещё один плюс — трапеции легко представимы в виде двух треугольников. Это упрощает их отрисовку с помощью железа. У cairo есть замечательная утилита show-traps, которая демонстрирует то, как происходит рассечение примитивов, передаваемых ей на отрисовку, на трапеции.

Простой пример из красной окружности. Окружность разбивается на два набора трапеций — один для контура и один для заливки. Поскольку реализация show-traps малоинформативно показывает этот процесс, я поправил исходники утилиты для того, чтобы каждая трапеция красилась своим собственным цветом. Вот пример набора трапеций для отрисовки чёрного контура.

pixman

И X-сервер, и cairo нуждаются в работе с пикселями. Ранее Cairo и Xorg по-разному реализовывали работу с растеризацией, попиксельным доступом к разнообразным буферам (ARGB32, BGR24, RGB565), градиентами, матрицами и всем остальным. Теперь же и cairo и X-сервер делают всё это через относительно низкоуровневую библиотеку pixman. Несмотря на то, что pixman — это разделяемая библиотека, у неё нет ни публичного API, ни определённого API для операций отрисовки. Строго говоря, у неё вообще нет API — это просто хранилище кода для дедупликации его между ранее упомянутыми двумя компонентами.

OpenGL, mesa, gallium

А это самая весёлая часть — современное аппаратное ускорение отрисовки. Я полагаю, что все и так знают, что такое OpenGL. Это не библиотека, это даже не конкретный набор исходников для сборки libGL.so. У каждого производителя своя собственная libGL.so, так или иначе совместимая со спецификацией OpenGL.

Например, nVidia предоставляет свою реализацию OpenGL и собственную libGL.so, которая реализуется по-разному для тех же Windows или OS X.

Если вы используете открытые драйверы, то реализация вашей libGL.so, скорее всего, основана на mesa. Mesa — это большая куча всего, но основная и самая известная часть этой кучи — открытая реализация OpenGL. Внутри самой mesa за OpenGL API используются различные бэкенды для трансляции API в исполнительные команды. Существует три программных бэкенда:

Кроме программных бэкендов mesa поддерживает аппаратные:

На самом деле, gallium — это набор компонентов, поверх которых можно достаточно просто построить драйвер. Смысл в том, что драйвер состоит из:

К сожалению, разработчики Intel не используют gallium. Мои коллеги говорят, что это из-за нежелания разработчиков драйверов Intel иметь какие-либо прослойки между mesa и своим драйвером.

Немного сокращений

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

Драйверы Xorg, DRM, DRI

Чуть раньше я писал, что Xorg может производить аппаратно-ускоренную отрисовку. Добавлю, что это реализовано не через трансляцию команд рисования X11 в вызовы API OpenGL. Тогда как Xorg работает с железом, если драйверы железа работают в недрах mesa, а Xorg на mesa не завязан?

Ответ прост. Ведь как оно? Mesa отвечает за реализацию OpenGL, Xorg отвечает за реализацию отрисовки команд X11, и они оба должны рисовать на железе с помощью специфичных для конкретного железа команд. В своё время в архитектуры Xorg и mesa был введён разделяемый компонент, который и загружает эти команды в ядро — так называемый “Direct Rendering Manager” («менеджер прямой отрисовки») или DRM.

Libdrm использует набор оригинальных закрытых ioctl’ей ядра для выделения ресурсов графического ускорителя и предоставления ему команд с текстурами. Общий интерфейс из этих ioctl’ей бывает (в общем-то, предсказуемо) двух видов:

Между ними нет значимых различий. Они оба делают одно и то же, просто чуть-чуть различаются в реализации. Исторически GEM был представлен компанией Intel, в качестве простой альтернативы TTM. Через некоторое время GEM разросся и «простота» стала такой же, как у TTM. Такие дела.

К чему всё это? К тому, что, например, когда вы запускаете утилиту типа glxgears, она загружает mesa. Mesa загружает libdrm. Libdrm общается с драйвером ядра, используя GEM/TTM. Да, glxgears напрямую работает с ядром для того, чтобы показать вам несколько крутящихся шестерёнок, таким образом напоминая о том, что это бенчмаркинговая утилита.
Если вы выполните в консоли команду (подставив lib32/lib64 в зависимости от архитектуры):

то увидите, что там лежат аппаратно-зависимые драйверы. Для тех случаев, когда функциональности, заложенной в GEM/TTM недостаточно, драйверы mesa и X-сервера предоставляют ещё более закрытый набор ещё более закрытых ioctl’ей для общения с ядром, которые, собственно, и находится в этих аппаратно-зависимых драйверах. Сам libdrm эти драйверы не загружает.

X-серверу необходимо знать, что же вообще происходит с графической подсистемой для того, чтобы реализовывать синхронизацию. Эта методология синхронизации (например, между запущенным вами glxgears, ядром и X-сервером) называется DRI или, более правильно, DRI2. DRI расшифровывается, как “Direct Rendering Infrastructure” («инфраструктура прямой отрисовки»). Вообще, под DRI понимают две вещи:

Поскольку мы придерживаемся строгой терминологии, а DRI1 выглядит глупо, мы будем говорить о протоколе и библиотеке, называя их DRI2.

Раз уж мы немного отошли от темы и начали говорить об инфраструктурных вещах, я задам вопрос. Предположим, вы работаете на новом X-сервере или вы хотите отобразить графику в виртуальном терминале без использования X-сервера. Как, в таком случае, вы это сделаете?

Вам надо сконфигурировать железо таким образом, чтобы оно могло отображать графику.

Внутри у libdrm и ядра есть специальная подсистема KMS, делающая именно это. Аббревиатура KMS расшифровывается, как “Kernel Mode Setting” («настройка режима из ядра»). Опять же, эта подсистема через набор ioctl’ей позволяет установить графический режим, настроить кадровый буфер и сделать всё нужное для того, чтобы показывать графику прямо в TTY. До появления KMS в ядре был (да так никуда пока и не делся) разношёрстный набор ioctl’ей, для замены и стандартизации которого, собственно, и создали разделяемую библиотеку libkms с единым и документированным API.

Правда, внезапно (как это принято в мире Linux) после libkms в ядре появился новый API, буквально называнный «тупыми ioctl’ями». Поэтому в настоящее время рекомендуется пользоваться не libkms, а этим набором ioctl’ей.

Насмотря на то, что эти ioctl’и очень низкоуровневые и простые, они позволяют сделать практически всё. Примером для этого может служить plymouth, который практически во всех современных дистрибутивах Linux отвечает за графическое отображение процесса загрузки без запуска X-сервера.

Модель “Expose”, Redirection (перенаправление), TFP, Compositing (композиция), AIGLX

Нельзя говорить о термине “композиционный менеджер окон“ без понимания того, что такое “композиция” и что делает менеджер окон.

В те далёкие 80-е, когда разрабатывалась для операционных систем UNIX архитектура X Window System, куча компаний типа HP, DEC, Sun и SGI разрабатывали свои продукты, базировавшиеся на X Window System. При этом протокол X11 никак не регламентировал правила управления окнами и делегировал ответственность за их поведение отдельному процессу, который назывался “window manager” («менеджер окон»).

Например, CDE, популярная оконная среда для своего времени, исповедовала поведение окон, которое было названо «фокус следует за мышью». Суть его в том, что фокус ввода передавался в окно, когда пользователь наводил на него курсор мыши. Это отличается от поведения окон в Windows или Mac OS X, в которых фокус окну передаётся кликом.

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

Опять же, в те далёкие 80-е у многих систем был банальный недостаток памяти, поэтому они не могли хранить в пиксельном виде всё содержимое окна. И Windows, и X11 решили эту проблемы одинаково: каждое окно X11 не должно иметь пиксельного состояния. По необходимости приложение получало уведомление о необходимости перерисовать часть своего окна (произвести «экспозицию», “expose”).

Представьте такой набор окон. Теперь переместим окно GIMP’а:

Область, закрашенная тёмно-коричневым, экспонирована. Событие ExposeEvent посылается приложению, которому принадлежит окно и приложение перерисовывает область экрана, соответствующую экспонированной. Именно из-за этой модели перерисовки окна подвисших приложений в Windows и Linux имеют белые области, когда вы перетаскиваете поверх них какое-нибудь другое окно. Учитывая тот факт, что в Windows рабочий стол отрисовывается точно такой же программой без особых привилегий, которая точно так же может зависнуть, легко можно понять причины этого весёлого артефактного поведения.

Сегодня у компьютеров много памяти. Поэтому мы имеем возможность сделать с помощью X11 окна, не теряющие своё пиксельное представление. Делается это с помощью механизма, называемого “redirection” («перенаправление»). Когда мы перенаправляем окно, X-сервер создаёт пиксельные буферы для рисования каждого окна, а не рисует напрямую во внеэкранный кадровый буфер. Это значит, что содержимое окна напрямую никогда не появляется на экране. Кое-что другое отвечает за отрисовку пикселей на внеэкранном кадровом буфере.

Расширение композиции позволяет композиционному менеджеру окон (или “compositor”’у, «композитору») создать так называемое Composite Overlay Window (“окно композиционного слоя”) или COW. После этого композитор назначается владельцем окна COW и может проводить его отрисовку.

Когда вы запускаете Compiz или GNOME Shell, эти приложения используют OpenGL для отображения перенаправленных окон на экране. X-сервер даёт им пользоваться содержимым окон с помощью GL-расширения “Texture from Pixmap” («текстура из пиксельной карты») или TFP. Это расширение позволяет OpenGL-приложению использоваться пиксельные карты X11 так, как если бы это были нативные текстуры OpenGL.

Композиционные менеджеры окон, в принципе, могут не использовать TFP или OpenGL. Просто TFP и OpenGL — самый лёгкий способ сделать композицию. Ничто не мешает менеджеру окон просто рисовать пиксельные карты окон на COW стандартными средствами. Мне рассказывали, что kwin4 так и поступает, напрямую используя Qt для композиции.

Композиционные менеджеры окон получают пиксельную карту от X-сервера через TFP и отрисовывают её в OpenGL-сцене в нужном месте, создавая иллюзию того, что вы работаете с обычным окном X11. Может показаться глупым называть это «иллюзией», но вы можете убедиться в «иллюзионности» композиции, если используете, например, GNOME Shell. Для этого можно изменить размер и позицию действующих окон, введя в looking glass GJS-код:

Иллюзия композиции исчезнет сразу, как только вы поймёте, что вы тыкаете мышью не в то окно, в которое хотели, а в другое. Для того, чтобы вернуть всё назад, введите в looking glass этот же код, поменяв 0.5 на 1.0.

Теперь, когда вы в курсе всех этих деталей, можно рассказать об ещё одном сокращении — об AIGLX. AIGLX расшифровывается как “Accelerated Indirect GLX” («ускоренный транзитный/непрямой GLX»). Поскольку X11 — это сетеориентированный протокол, OpenGL должен уметь работать через сеть. Когда OpenGL используется в таком режиме, режим называется “indirect context” («транзитный контекст»), в отличие от стандартного режима “direct context”, в котором OpenGL используется на этой же машине. Грусть в том, что сетевой протокол для транзитного контекста ужасающе неполный и нестабильный.

Для того, чтобы понять компромиссность архитектурных решений AIGLX, надо понять проблему, которую пытались ими решить: необходимость сделать композиционные менеджеры типа Compiz’а реально быстрыми. В то время, когда у проприетарного драйвера NVidia есть свой собственный интерфейс управления памятью на уровне ядра, у открытого графического стека его нет. Поэтому прямой перенос пиксельной карты окна в виде текстуры из X-сервера на графическое железо выливался бы в копирование этой пиксельной карты каждый раз, когда окно обновляется. Дико медленно. Поэтому AIGLX заранее был признан временным костылём для быстрой программной реализации OpenGL с целью исключения копирования пиксельных карт при аппаратном ускорении. Ну и, поскольку сцена, которая рисуется Compiz’ом, обычно не очень сложная, работало это вполне приемлемо.

Несмотря на кучу похвалы и статьи Phoronix’а, AIGLX так никогда и не использовался для серьёзных вещей — просто потому, что у нас сейчас есть нормальный DRI-стек, в котором можно реализовать TFP без копирования.

Теперь вам должно быть понятно, что копирование (или, если говорить более точно, подстановка) содержимого пиксельной карты окна так, чтобы оно могло быть передано в отрисовку в виде текстуры OpenGL невозможно без непосредственного копирования данных. Из-за этого у большинства оконных менеджеров в настройках есть фича, которая позволяет отключать перенаправление для окон, развёрнутых на весь экран. Возможно, называть это “unredirection“ («деперенаправление») глупо, потому что в результате мы получаем окно таким, каким оно и должно быть по логике X Window System. Да, исторически это так. Но, в современном Linux, такое состояние трудно назвать обычным состоянием окна. Зачем нужно деперенаправление? Да затем, что в развёрнутом состоянии любое окно всё равно целиком закрывает COW, поэтому не надо проводить комплексную композицию и её можно отключить. Эта фича нужна для того, чтобы дать полноэкранным приложениям типа игр и видеопроигрывателей работать без дополнительного копирования данных окна с максимальной производительностью обновления, достигающей позволенных 60 кадров в секунду.

Wayland

Выше мы вычленили достаточно большой кусок инфраструктуры из монолитной архитектуры иксов. Но графическая подсистема — это не всё, что вывалилось со временем из монолита: практически вся обработка устройств ввода переместилась в ядро с помощью evdev, а поддержка горячего подключения устройств вернулась обратно в udev.

Причина того, что X Window System живёт и сейчас в том, что всё это время усилия сообщества направлялись на работы по его замене. Эта замена — Xorg, с большим количеством разнообразных расширений, обеспечивающих необходимую для современного графического окружения функциональность. Можно сказать, что классический X Window System — списанный хлам.

Въезжаем в Wayland. Wayland переиспользует очень большой объём той инфраструктуры, что мы создали на замену X Window System. Единственная противоречивая вещь в архитектуре Wayland — это непрозрачность сетевого и отрисовочного протоколов. С другой стороны, в наше время колоссальная гибкость сетевого протокола становится ненужной, ведь львиная доля функциональность иксов уже раскидана по другим службам — например, DBus. На самом деле, стыдно смотреть на те хаки в архитектуре X Window System, что понаделаны в вещах типа буфера обмена или поддержки Drag and Drop исключительно для совместимости с сетевым прошлым иксов.

Как уже было сказано, Wayland может использовать весь вышеописанный стек для того, чтобы получить кадровый буфер для монитора и запуститься. У Wayland сохраняется определённый протокол обмена, но он основан исключительно на сокетах UNIX и локальных ресурсах. Самое большое отличие Wayland от Xorg в том, что он не запускается с помощью /usr/bin/wayland и не висит в памяти отдельным процессом. Он, в соответствии с духом времени и требованиями к современным средам рабочего стола, связывает всё непосредственно с процессами менеджеров окон. Такой оконный менеджер или, точнее, «композитор» в терминологии Wayland, подтягивает события из ядра с помощью evdev, настраивает кадровый буфер с помощью KMS или DRM и отрисовывает на нём картинку с помощью любого графического стека, включая OpenGL. Несмотря на то, что упоминание такого клеевого слоя сразу вызывает ассоциации с тоннами кода (потому что во взаимодействии участвует куча разбросанных везде систем), на самом деле порядок объёма укладывается в две-три тысячи строк кода. Кажется, что довольно много? Представьте, что только небольшая часть mutter, описывающая механизм фокуса, стэкирования окон и синхронизирующая их с X-сервером — это уже четыре-пять тысяч строк кода.

Хотя у Wayland есть эталонная библиотека реализации протокола и настойчиво рекомендуется её использовать как для клиентов, так и для композиторов, — ничто не мешает кому-нибудь написать всего композитора для Wayland на Python. Или на Ruby. И реализовать протокол на чистом Python, без использования libwayland.

Клиенты Wayland общаются с композитором и запрашивают буфер. Композитор отдаёт буфер, в который они могут рисовать хоть с помощью cairo, хоть с помощью OpenGL, хоть самостоятельно. Композитор потом уже сам решает, что делать с этим буфером — показывать его просто так, дать ему приоритет из-за настойчивости приложения или повращать его гм… на кубике потому, что нам хочется выложить в YouTube новую видюшку с окнами Linux, вращающимися на кубике. Ну, вы поняли.

Кроме этого, композитор ответственен за ввод и за обработку событий. Если вы пробовали запустить кусок GJS-кода для GNOME Shell, вы наверняка были озадачены вопросом — «Почему мышь работает с нетрансформированными окнами»? А потому, что мы воздействовали на отображение окна, а не на само окно внутри X11. X-сервер отслеживает окна самостоятельно и надеется, что композиционный менеджер окон их отображает соответствующим образом. Если это не так, то приходится озадачиваться, как в случае выше.

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

Выводы

Я часто слышу высказывания о том, что реализация Xorg монолитна. Доля истины в таких высказываниях, конечно же, присутствует, но со временем истины в таких высказываниях всё меньше и меньше. Это не результат некомпетентности разработчиков Xorg, нет. Просто нам надо жить не только с Xorg, но и со всем багажом, накопленным за долгие годы — а это, например, аппаратно-ускоренный протокол XRender или, если взять что-то более раннее, — команды рисования без антиалиасинга типа XPolyFill. Понятно, что со временем X уйдёт со сцены и будет заменён Wayland’ом. Но я хочу, чтобы было понятно и то, что это делается с пониманием и колоссальной помощью от разработчиков окружений рабочего стола и Xorg. Они не упрямы и они не некомпетентны. Чёрт возьми, поддерживать протокол тридцатилетней давности без поломок и перестраивать его архитектуру, — это отличная работа с их стороны.

Также я хочу выразить признательность всем, кто работал над вещами, о которых эта статья. Огромное спасибо Оуэну Тэйлору, Рэю Строуду и Эдэму Джексону за долготерпение и ответы на все мои тупые вопросы. Отдельное спасибо Дэйву Эйрли и Эдэму Джексону за помощь в технической вычитке этой статьи.

Несмотря на то, что я мельком пробежал по основным вещам графического стека Linux, вы всегда можете копнуть глубже, если вам это интересно. Например, вы можете почитать про геометрические алгоритмы и теории, которые лежат в основе разбиения cairo примитивов на четырёхугольники. Или, может быть, стоит взглянуть на алгоритм быстрой программной растеризации этих четырёхугольников и разобраться в причинах высокой скорости его работы. Попробуйте поковыряться в DRI2. А вдруг вам интересно само железо и то, как оно рисует, и вы разберётесь в даташитах и попробуете сами его запрограммировать? В любом случае, если вы решите углубиться в какую-нибудь из этих областей, — сообщество и проекты, перечисленные выше, будут счастливы принять вас с вашим вкладом.

Я планирую написать больше про всё это. В Linux используется много разнообразных стеков технологий, а у сообщества GNOME до сих пор нет вменяемых обзорных документов, описывающих их на более-менее высоком уровне.

Спасибо хабрапользователям Roosso, trollsid и Xitsa за вычитку.

Источник