X.Org Server — это бесплатная реализация сервера отображения X Window System (X11) с открытым исходным кодом , поддерживаемая X.Org Foundation .
Реализации клиентского протокола X Window System существуют в форме библиотек X11 , которые служат полезными API для связи с X-сервером. [4] Для X11 существуют две такие основные библиотеки X. Первой из этих библиотек была Xlib , оригинальный API X11 для языка C, [5] но другая библиотека X для языка C, XCB , была создана позже в 2001 году. [6] Существуют и другие меньшие библиотеки X, как интерфейсы для Xlib и XCB на других языках, так и как меньшие автономные библиотеки X. [ требуется ссылка ]
Услуги, с помощью которых X.Org Foundation поддерживает X Server, включают упаковку релизов; сертификацию (за плату); оценку улучшений кода; разработку веб-сайта и распределение денежных пожертвований. [ требуется ссылка ] Релизы кодируются, документируются и упаковываются глобальными разработчиками . [ требуется разъяснение ]
Сервер X.Org реализует серверную часть основного протокола X Window System версии 11 (X11) и его расширения, например RandR. [7]
В версии 1.16.0 интегрирована поддержка запуска и управления на основе systemd , что повысило производительность и надежность загрузки. [8]
Device Independent X (DIX) — это часть X.Org Server, которая взаимодействует с клиентами и реализует программный рендеринг. Основной цикл и доставка событий являются частью DIX. [9]
X-сервер имеет огромное количество функций, которые должны быть реализованы для поддержки протокола ядра X. Сюда входят кодовые таблицы, растеризация и кэширование глифов, XLFD и API рендеринга ядра, который рисует графические примитивы.
Device Dependent X (DDX) — это часть x-сервера, которая взаимодействует с оборудованием. В исходном коде сервера X.Org каждый каталог в "hw" соответствует одному DDX. Оборудование включает в себя графические карты, а также мышь и клавиатуры. Каждый драйвер специфичен для оборудования и реализован как отдельный загружаемый модуль.
По историческим причинам X.Org Server по-прежнему содержит графические драйверы устройств, поддерживающие некоторую форму ускорения 2D-рендеринга. В прошлом настройка режима выполнялась графическим драйвером устройства X-сервера, специфичным для некоторого оборудования видеоконтроллера ( например , GPU ). К этой функциональности настройки режима была добавлена дополнительная поддержка 2D-ускорения, когда таковая стала доступна для различных GPU. Функциональность настройки режима была перемещена в DRM и предоставляется через интерфейс настройки режима DRM, новый подход называется «настройка режима ядра» (KMS). Но ускорение 2D-рендеринга осталось.
В Debian драйверы 2D-графики для сервера X.Org упакованы по отдельности и называются xserver-xorg-video-* . [10] После установки файл драйвера 2D-графики находится в /usr/lib/xorg/modules/drivers/
. Пакет xserver-xorg-video-nouveau устанавливается nouveau_drv.so
с размером 215 КБ, фирменный драйвер Nvidia GeForce устанавливает файл размером 8 МБ с именем nvidia_drv.so
, а Radeon Software устанавливается fglrx_drv.so
с размером около 25 МБ.
Доступные бесплатные и открытые драйверы графических устройств разрабатываются внутри проекта Mesa 3D . Хотя их можно перекомпилировать по мере необходимости, разработка фирменных графических драйверов DDX 2D значительно упрощается, когда сервер X.Org поддерживает стабильный API/ABI в нескольких своих версиях.
С версией 1.17 был выделен общий метод для настройки режима. xf86-video-modesetting
Пакет, названный Debian-package xserver-xorg-video-modesetting
, был упразднен, а содержащийся в нем общий DDX для настройки режима был перемещен в серверный пакет, чтобы стать DDX по умолчанию с поддержкой KMS, поддерживающим подавляющее большинство графических процессоров AMD, Intel и NVidia.
7 апреля 2016 года сотрудник AMD Мишель Дэнцер выпустил xf86-video-ati
версию 7.7.0 [11] и xf86-video-amdgpu
версию 1.1.0 [12], последняя из которых включала поддержку микроархитектуры Polaris .
Существуют (как минимум) XAA (архитектура ускорения XFree86), [13] EXA , UXA и SNA .
В системе X Window архитектура ускорения XFree86 ( XAA ) — это архитектура драйвера, которая делает аппаратное ускорение видеокарты 2D доступным для X-сервера. [14] [15] Она была написана Хармом Ханемайером в 1996 году и впервые выпущена в версии XFree86 3.3. Она была полностью переписана для XFree86 4.0. [16] Она была снова удалена из X.Org Server 1.13.
Большинство драйверов реализуют ускорение с помощью модуля XAA. XAA включен по умолчанию, хотя ускорение отдельных функций можно отключить по мере необходимости в файле конфигурации сервера ( XF86Config
или xorg.conf
).
Драйвер для чипсета ARK был изначальной платформой разработки для XAA.
В версии X.Org Server 6.9/7.0 EXA был выпущен в качестве замены XAA, поскольку XAA практически не обеспечивает преимущества в скорости для современных видеокарт. EXA рассматривается как промежуточный шаг к преобразованию всего X-сервера на использование OpenGL .
Glamor — это универсальный, независимый от оборудования драйвер 2D-ускорения для X-сервера, который преобразует примитивы рендеринга X в операции OpenGL , используя преимущества любых существующих драйверов 3D OpenGL. [17] Таким образом, он функционально похож на Quartz Extreme и QuartzGL (ускорение 2D-производительности) для Apple Quartz Compositor .
Конечной целью GLAMOR является аннулирование и замена всех драйверов графических устройств DDX 2D и архитектур ускорения, тем самым избегая необходимости писать специальные драйверы X 2D для каждого поддерживаемого графического чипсета. [18] [19] [20] Glamor требует 3D-драйвер с поддержкой шейдеров . [21]
Настройка производительности Glamor была принята для Google Summer of Code 2014. [22] Glamor поддерживает Xephyr и DRI3 , [23] и может ускорить некоторые операции на 700–800%. [24] С момента его включения в версию 1.16 сервера X.Org разработка Glamor была продолжена, и были опубликованы исправления для выпуска 1.17. [25]
Существует отдельный и специальный DDX для экземпляров сервера X.Org, которые работают на гостевой системе внутри виртуализированной среды : xf86-video-qxl, драйвер для "видеоустройства QXL". SPICE использует этот драйвер, хотя работает и без него.
В репозиториях Debian он называется xserver-xorg-video-qxl, см. https://packages.debian.org/buster/xserver-xorg-video-qxl
В Debian драйверы, связанные с вводом, находятся в разделе /usr/lib/xorg/modules/input/
. Такие драйверы называются, например evdev_drv.so
, , mouse_drv.so
, synaptics_drv.so
или wacom_drv.so
.
С версии 1.16 сервер X.Org получил поддержку библиотеки libinput в виде оболочки под названием xf86-input-libinput
. [26] На XDC 2015 в Торонто libratbag была представлена как универсальная библиотека для поддержки настраиваемых мышей. [27] [28] xserver-xorg-input-joystick
— это модуль ввода для сервера X.Org для работы с классическими джойстиками и геймпадами, который не предназначен для игр под X, а для управления курсором с помощью джойстика или геймпада. [29] [30]
X.Org Server и любой x-client работают как отдельные процессы. В Unix/Linux процесс ничего не знает о других процессах. Чтобы взаимодействовать с другим процессом, он полностью и всецело полагается на ядро, которое будет модерировать взаимодействие через доступные механизмы межпроцессного взаимодействия (IPC). Сокеты домена Unix используются для взаимодействия с процессами, работающими на той же машине. Вызовы специальных функций сокетов являются частью интерфейса системных вызовов. Хотя сокеты домена Интернета можно использовать локально, сокеты домена Unix более эффективны, поскольку у них нет накладных расходов протокола ( контрольные суммы , порядок байтов и т. д.).
Сервер X.Org не использует D-Bus .
Сокеты являются наиболее распространенным методом межпроцессного взаимодействия (IPC) между процессами X-сервера и его различными X-клиентами. Он предоставляет интерфейс прикладного программирования (API) для взаимодействия в домене TCP/IP, а также локально только в домене UNIX. Существует несколько других API, описанных в X Transport Interface, например TLI (Transport Layer Interface). Другие варианты IPC между X-клиентом и сервером требуют расширений системы X Window, например MIT Shared Memory Extension (MIT-SHM) .
Multi-seat относится к сборке одного компьютера с несколькими «местами», что позволяет нескольким пользователям садиться за компьютер, входить в систему и использовать компьютер одновременно независимо. К компьютеру подключено несколько клавиатур, мышей и мониторов, причем каждому «месту» назначены одна клавиатура, одна мышь и один монитор. «Место» состоит из всех аппаратных устройств, назначенных определенному рабочему месту. Оно состоит как минимум из одного графического устройства (графической карты или просто выхода и подключенного монитора), клавиатуры и мыши. Оно также может включать видеокамеры, звуковые карты и многое другое.
Из-за ограничений системы VT в ядре Linux и протокола ядра X (в частности, того, как X определяет связь между корневым окном и выходом графической карты), многопользовательский режим не работает «из коробки» для обычного дистрибутива Linux, а требует специальной настройки.
Существуют следующие методы конфигурации многоместной сборки:
Используемые параметры командной строки xorg-server:
-isolateDevice bus-id
Ограничить сбросы устройств (вывод) на устройство с идентификатором шины. Строка идентификатора шины имеет вид bustype:bus:device:function (например, 'PCI:1:0:0'). В настоящее время поддерживается только изоляция устройств PCI; т. е. эта опция игнорируется, если тип шины отличается от 'PCI'.vtXX
Например, для Debian 9 Stretch значение по умолчанию равно 7, т.е. нажав Ctrl+ +, пользователь может переключиться на виртуальную машину, на которой запущен xorg-сервер.AltF7Только пользователь на первом мониторе имеет возможность использовать консоли vt и может использовать + + x для их выбора. У других пользователей есть экран входа в GDM , и они могут использовать xorg-server как обычно, но у них нет vt.CtrlAltF
Несмотря на то, что один пользователь может использовать несколько мониторов, подключенных к разным портам одной видеокарты (см. RandR), метод, основанный на нескольких экземплярах xorg-server, по-видимому, требует наличия нескольких видеокарт PCI .
Можно настроить многопользовательскую среду, используя только одну видеокарту, но из-за ограничений протокола X это требует использования протокола управления X Display Manager ( XDMCP). [37]
Также существует Xdmx (Distributed Multihead X).
Современный X.Org Foundation появился в 2004 году, когда орган, который курировал стандарты X и опубликовал официальную эталонную реализацию, объединил усилия с бывшими разработчиками XFree86 . [43] X11R6.7.0, первая версия X.Org Server, была ответвлена от XFree86 4.4 RC2. [1] Непосредственной причиной ответвления стало несогласие с новой лицензией для финальной версии XFree86 4.4, но несколько разногласий среди участников всплыли до разделения. Многие из предыдущих разработчиков XFree86 присоединились к проекту X.Org Server.
В 2005 году были приложены большие усилия по модуляризации исходного кода сервера X.Org, [44] что привело к двойному релизу к концу года. Релиз X11R7.0.0 добавил новую модульную систему сборки на основе GNU Autotools , в то время как X11R6.9.0 сохранил старую систему сборки imake , оба релиза разделяют одну и ту же кодовую базу. С тех пор ветвь X11R6.9 поддерживается замороженной, и вся текущая разработка выполняется в модульной ветви. Новая система сборки также принесла использование стандартного динамического компоновщика dlloader для загрузки плагинов и драйверов, отменив старый собственный метод. В результате модуляризации двоичные файлы X11 перемещались из своего собственного /usr/X11R6
дерева подкаталогов в глобальное /usr
дерево во многих системах Unix .
В июне 2006 года была предпринята еще одна попытка переместить исходный код сервера X.Org из CVS в git . [45] Обе попытки имели долгосрочную цель привлечения новых разработчиков в проект. По словам Алана Куперсмита: [46]
Некоторые из наших усилий здесь были технологическими - одним из движущих усилий преобразований из Imake в automake и из CVS в git было использование инструментов, которые разработчики уже знали и с которыми работали бы продуктивно из других проектов. Проект Modularization, который разбил X.Org из одного гигантского дерева на более чем 200 маленьких, имел цель сделать возможным исправление ошибки в одной библиотеке или драйвере без необходимости загружать и собирать много мегабайт программного обеспечения и шрифтов, которые не изменялись.
В версии 7.1 фреймворк KDrive (небольшая реализация X, написанная Кейтом Паккардом и не основанная на XFree86 , которую разработчики X.Org использовали в качестве испытательного полигона для новых идей, таких как EXA ) был интегрирован в основную кодовую базу сервера X.Org.
В 2008 году новый DRI2, основанный на драйвере kernel mode-setting (KMS), заменил DRI. Это изменение также стало важной вехой в архитектуре сервера X.Org, поскольку драйверы были перемещены из пространства сервера и пользователя (UMS) в пространство ядра .
В 2013 году начальные версии расширений DRI3 и Present были написаны и закодированы Кейтом Паккардом для обеспечения более быстрого и свободного от разрывов 2D-рендеринга. К концу года реализация GLX была переписана Адамом Джексоном в Red Hat . [47]
X-сервер на основе исходников xorg git (например, xming или xwin от cygwin), но скомпилированный с помощью Visual C++ 2010.