Основной протокол X Window System


Основной протокол X Window System
Логотип X Window System

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

Корневой протокол системы X Window предусматривает только 4 типа пакетов данных, посылаемых асинхронно через сеть: запросы, отклики, события и сообщения об ошибках. Запросы посылаются клиентом в сторону сервера для выполнения последним какого-либо действия (например, создать новое окно) и/или указания серверу послать назад какие-либо данные. Отклик сервера обеспечивает пересылку этих данных клиенту. События рассылаются сервером для уведомления его клиентов о пользовательской активности или другой деятельности на стороне сервера, в которых заинтересован тот или иной клиент. Сообщения об ошибках рассылаются сервером его клиенту в случае ошибок обработки запросов клиента. Запросы могут порождать отклики, события или сообщения об ошибках. Протокол не устанавливает обязательной последовательности передачи пакетов по сети. Существуют расширения корневого протокола со своими запросами, откликами, событиями или сообщениями об ошибках.

Система X появилась в МИТ в 1984 году (текущий релиз X11 — в сентябре 1987 года). Её разработчик Боб Шифлер и Джим Гетис в ходе её разработки руководствовались правилом, что корневой протокол должен устанавливать «механизм, а не набор правил-политик». В результате корневой протокол не специфицирует взаимодействие между клиентами, а также между клиентом и пользователем. Они являются предметом дополнительных спецификаций [1], таких как ICCCM и Freedesktop.org и они обычно выполняются автоматически с использованием предзаданного набора виджетов.

Содержание

Общий обзор

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

Пример взаимодействия клиента и сервера

После того как соединение установлено, четыре типа пакетов используются для обмена между клиентом и сервером по каналу:

  1. Request: Клиент запрашивает информацию с сервера или просит выполнить действие.
  2. Reply: Сервер отвечает на запрос. Не все запросы, порождают ответы.
  3. Event: Сервер сообщает клиенту о событиях, таких как ввод с клавиатуры или мыши, перемещение окна, изменение размера или раскрытия на весь экран и т. д.
  4. Error: Сервер посылает пакет с описанием ошибки, если запрос является неправильным. Поскольку запросы ставятся в очередь, то пакеты с с сообщением об ошибке порожденные им, не могут быть отправлены немедленно.

Запросы и ответы передаются в пакетах разной длины, в то же время пакеты событий и ошибок имеют фиксированную длину в 32 байта.

Окна

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

Возможное расположение окон: 1) корневое окно на весь экран; 2) и 3) окна наивысшего уровня, 4) и 5) — дочерние окна для 2). Области вне экрана отбрасываются

Клиент может запросить создание окна. Точнее, он может запросить создание подокна в существующем окне. В результате, окна, созданные клиентами, расположены в виде дерева (иерархии). Корень этого дерева в корневом окне, которое является специальным окном создаваемым автоматически при запуске сервера. Все остальные окна, прямо или косвенно подокна корневого окна. Окна верхнего уровня являются прямыми подокнами корневого окна. Явно, что корневое окно такого же размера как и экран (хотя, может быть и больше, в этом случае пользователь может перемещать видимую область), и лежит в основе всех остальных окон.

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

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

Окна могут быть InputOutput или InputOnly. Окна первого рода могут быть показаны на экране, и использованы для рисования. Второй вид окон не отображаются на экране, они используются только для получения ввода.

Анатомия окна FVWM. Пространство белого цвета это окно созданное и видимое клиентским приложением.

Декоративная рамка и заголовок (возможно, в том числе и кнопки), которые обычно наблюдаются вокруг окон создаются диспетчером окон, а не клиентом, который создает окно. Диспетчер окон так же управляет вводом связанным с этими элементами, такими, как изменение размера окна, когда пользователь нажимает и тащит оконную рамку. Клиенты обычно работают в окне, они созданы без учета изменений производимых диспетчером окон. A change it has to take into account is that re-parenting window managers, which almost all modern window managers are, change the parent of top-level windows to a window that is not the root. С точки зрения основного протокола, диспетчер окон, является таким же клиентом как и другие приложения.

Данные об окне можно получить, запустив программу xwininfo. Запустив её из командной строки с аргументом—tree, эта программа показывает дерево подокон из окна, а также их идентификаторы и геометрические данные.

Пиксельные карты и области рисования

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

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

Графические контексты и шрифты

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

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

Основной протокол предписывваетет использовать шрифты на стороне сервера. Такие шрифты хранятся в виде файлов, а сервер осуществляет к ним доступ непосредственно через локальную файловую систему или через сеть с помощью другой программы, называемой сервером шрифтов. Клиент может запросить список шрифтов, доступных на сервере и может запросить загрузить шрифт (если ещё нет) или выгрузки (если они не используются другими клиентами) на сервере. Клиент может запросить информацию о шрифте (например, ascent шрифта) и место занимаемое конкретной строкой, когда прорисовывается определенным шрифтом.

xfontsel позволяет увидеть начертание символов в шрифте.

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

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

Прорисовка шрифтов на стороне сервера в настоящее время считается устаревшим в пользу прорисовки шрифтов на стороне клиента. Такие шрифты прорисовываются клиентом, а не сервером, при поддержке библиотек Xft или cairo, и расширения XRender. В основном протоколе нет спецификации на прорисовку шрифтов на стороне клиента.

Ресурсы и идентификаторы

Все данные об окнах, растровых изображениях, шрифтах и т. д. хранятся на сервере. Клиент знает идентификаторы этих объектов-чисел и использует их в качестве имен при взаимодействии с сервером. Например, если клиент желает создать окно, он посылает запрос серверу о создании окна с заданным идентификатором. Идентификатор может быть использован клиентом позднее, например для запроса строки, которые следует нарисовать в окне. Объекты находятся на сервере, и клиенту известны как цифровые идентификаторы:

  • окно
  • пиксельная карта
  • шрифт
  • цветовая карта (таблица цветов, описание находится ниже)
  • графический контест

Эти объекты называются ресурсами. Когда клиент запрашивает создание одного из таких ресурсов, он также указывается его идентификатор. Например, для создания нового окна, клиент определяет как атрибуты окна (родителей, ширина, высота и т. д.) так и идентификатор связаный с окном.

Идентификаторы являются 32-разрядными целыми числами, но три самых старших бита всегда равны нулю. Каждый клиент имеет свой собственный набор идентификаторов который он может использовать для создания новых ресурсов. Этот набор определяется сервером как два целых числа, включенных в пакет подтверждения соединения (пакет, отправляемый клиенту с сообщением, что соединение принимается). Клиенты выбирают идентификаторы, из этого набора таким образом, что бы они не конфликтовали: любые 2 объекта как окна, растровые изображения, шрифты, цветовые карты, а также графические контексты не могут иметь один и тот же идентификатор.

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

Идентификаторы являются уникальными для сервера, а не только для клиента, например, два окна не могут иметь один и тот же идентификатор, даже если созданы двумя разными клиентами. Клиент может получить доступ к любому объекту по его идентификатору.

Когда ресурс создаётся, его идентификатор, используется клиентом для запросов к серверу. Некоторые операции влияют на выданные ресурсы (например, запрос на перемещение окна), другие операции запрашивают ресурсы, хранящиеся на сервере (например, запросы на атрибуты окон).

Идентификаторы являются уникальными для сервера, а не только для клиента, например, любые два окна не могут иметь один и тот же идентификатор, даже если созданы двумя разными клиентами. Клиент может получить доступ к любому объекту через его идентификатор. В частности, оно может также получить доступ к ресурсам, созданной любым другим клиентом, даже если их идентификаторы вне множества идентификаторов им созданных.

В результате два клиента, подключенных к одному и тому же серверу могут использовать один и тот же идентификатор для ссылок на один и тот же ресурс. Например, если клиент создает окно с идентификатором 0x1e00021 и передает этот номер 0x1e00021 в другое приложение (с помощью любых доступных средств, например, сохраняя этот номер в файл, который также доступен для других приложений), то это другое приложение может работать на том же самом окне. Такая возможность, например в использует X Window версия программы Ghostview: эта программа создает окно-потомка, сохраняет его идентификатор в переменной среды, и вызывает Ghostscript, которая рисует содержимое файла PostScript и отображает в этом окне [8].

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

События

События - пакеты, посланные сервером клиенту, c сообщением, что ожидаемое клиентом, случилось. Например, событие посылается, когда пользователь нажимает клавишу или нажимает кнопку мыши. События могут использоваться не только для ввода: например, события посылают указание на создание новых подокон в данном окне.

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

Клиент может запросить сервер отправить событие другому клиенту, это используется для коммуникации между клиентами. Такие события, например генерируется, когда клиент запрашивает текст, который в настоящее время выделен: это событие направляется клиенту, который перемещает окно, содержащее выделенный текст.

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

Пример события: при нажатии клавиши в окне, создаётся событие и отправляется клиенту в зависимости от его маски события окна, которые клиент может изменить.

Большинство видов событий отправляются только если клиент ранее заявило о своей заинтересованности в них. Поскольку клиенты могут быть заинтересованы только в каких-либо видах событий. Например, клиент может быть заинтересован в событиях связанных с клавиатурой, но не связанных с мышью. Некоторые виды событий, однако, всё равно направляются клиентам, даже если они их специально не запрашивали.

Клиенты определяет, какие виды событий он хочет отправлять, установив атрибут окну. Например, для того, чтобы перерисовать окно, когда его содержание было уничтожено, клиент должен получить событие Expose, которые информирует, что окно должно быть перерисовано. Клиент, однако, пошлёт событие Expose только если клиент уже заявлял о своей заинтересованности в этих событиях. Заявление об интересе осуществляется надлежащей установкой маски атрибута события на окно.

Различные клиенты могут запрашивать события в одном и том же окне. Они могут даже установить различные маски событий на одном и том же окне. Например, клиент может запрашивать только события клавиатуры в окне, а другой клиент запрашивает только события мыши в том же окне. Однако, есть несколько видов событий, которые можно выбрать только по одному клиенту на время для каждого окна. В частности, это события сообщений кликов мышью и некоторые изменения, связанные с управлением окном.

xev - программа, которая показывает события по отношению к окну. В частности, xev -id WID запрашивает все возможные события относительно окна с идентификатором WID и выводит их.

Примеры

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

  1. Клиент открывает соединение с сервером и посылает начальный пакет с указанием порядка байтов который он использует.
  2. Сервер принимает соединение (авторизация не используется в данном примере), отправив соответствующий пакет, который содержит другие сведения, такие как идентификатор корневого окна (например, 0x0000002b), и идентификаторы которые клиент может создать.
  3. Клиент запрашивает создание графического контекста по умолчанию с идентификатором 0x00200000 (этот запрос, как и другие запросы такого типа, например, не генерируют ответы от сервера).
  4. Клиент запрашивает у сервера создание окна верхнего уровня (то есть, он определяет родителя для корневого окна 0x0000002b) с идентификатором 0x00200001, размер 200x200, позиции (10,10) и т.д.
  5. Клиент запрашивает изменение атрибутов окна 0x00200001, указав на заинтересованность в получении событий Expose и KeyPress.
  6. Клиент запрашивает отображение окна 0x00200001 (т.е. оно будет показано на экране).
  7. Когда окно становится видимым и его содержимое должно быть прорисовано, то сервер посылает клиенту событие Expose.
  8. В ответ на это событие, клиент запрашивает прорисовать ящик, отправив запрос PolyFillRectangle с окном 0x00200001 и графическим контекстом 0x00200000.

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

  1. Сервер отправляет другое событие Expose с сообщением клиенту о том, что его окно отрисовывается снова.
  2. Клиент перерисовывает окно посылая запрос PolyFillRectangle серверу.

Цвета

На уровне протокола, цвет представлен 32-битным беззнаковым целым числом, называемым pixelvalue. Следующие элементы принимают участие в представление цвета:

  1. Глубина цвета (colordepth)
  2. Карта цветов (colormap) являющаяся таблицей содержащей значения интенсивности красной, зелёной и синей составлющих
  3. Визуальный тип (visual type) определяющий как таблица будет использована для представления цветов

В простейшем случае, карта цветов содержит триаду RGB в строке. pixelvalue x предсталяет собой x-ю строку в таблице. Если клиент может изменять записи в карте цветов, то представление отождествляется с визуальным классом PseudoColor. Визуальный класс StaticColor схож, но клиент не может менять записи в таблице цветов.

Всего доступно 6 визуальных классов. Каждый определяется различным способом представления триады RGB с pixelvalue. PseudoColor и StaticColor это два. Ещё два это GrayScale и StaticGray, которые отличаются тем что показывают только оттенки серого.

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

Согласно представлению цветов, pixelvalue преобразует в RGB триаду в следующих случаях:

  1. pixelvalue виделась как последовательность бит
  2. эта последовательность нарушается в трех частях
  3. каждый из этих трёх чанков из бит виделись как целое и использовались как индекс для поиска значения в каждой из трёх раздельных таблиц

Этот механизм требует что бы карта цветов состояла из трёх раздельных таблиц, каждая для одного из первичных цветов. Результатом преобразования является ещё тройка значений интенсивности. Визуальные классы используемые этим представлением: DirectColor или TrueColor, различающиеся тем что может клиент менять карту цветов или нет.

Все эти шесть механизмов для представления цветов с pixelvalue требуют некоторых дополнительных параметров для работы. Эти параметры собраны в визуальном типе, который содержит визуальный класс и остальные параметры для представления цветов. Каждый сервер имеет ограниченное количество установленных визуальных типов, и каждый тип ассоциирован с цифровым идентификатором. Идентификаторы являются 32-битными беззнаковыми целыми числами, но не обязательно отличаются от идентификаторов ресурсов или атомов.

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

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

Карты цветов используются независимо от аппаратуры контролирующей экран (т.к. видеокарта) использующей палитру, которая представляет собой таблицу, которая также используется для представления цветов. Серверы используют карты цветов даже если аппаратура не использует палитру. Когда аппаратура использует палитры, ограниченное количество карт цветов можно установить. В частности, карты цветов установленные когда аппаратура показывает согласующиеся цвета. Клиент может запросить сервер установить карту цветов. Однако это может потребовать удалить другую карту цветов: эффектом использования удалённой карты цветов будет изображение с некорректными цветами, эффект двойной цветовой вспышки или цвета высокой интенсивности. Эта проблема может быть решена использованием стандартных карт цветов. Это цветовые карты с предустановленными ассоциациями между pixelvalues и цветами. Благодаря этому качеству, стандартные карты цветов могут использоваться различными приложениями.

Создание карт цветов регулируется соглашением ICCCM. Стандартные карты цветов определяются ICCCM и спецификацией Xlib.

Частью системы цветов X является Система управления цветом X (X Color Management System (xcms)). Эта система появилась вместе с X11R6 Release 5 в 1991 году. Эта система содержится в виде нескольких дополнительных возможностей xlib, находящихся в серии функций Xcms*. Система определяет аппаратно-независимые цветовые схемы которые уже могут быть конвертированы в аппаратно-зависимые системы RGB. Система содержит функции xlib Xcms*, а также Соглашение цветовой характеристики устройсва(X Device Color Characterization Convention (XDCCC)) которая описывает как преобразуются различные аппаратно-независимые цветовые системы в аппаратно-зависимые RGB цветовые системы. Эта система поддерживает цветовые системы CIEXYZ, xyY, CIELUV и CIELAB, а также TekHVC.

Атомы

Свойства

Отображение

Захваты

Прочее

Расширения

Авторизация

Xlib и другие клиентские библиотеки

Не специфицированное корневым протоколом системы X Window

Литература

Ссылки

Примечания

  1.  (англ.) Jim Gettys, Open Source Desktop Technology Road Map




Wikimedia Foundation. 2010.

Смотреть что такое "Основной протокол X Window System" в других словарях:

  • Менеджер окон X Window System — Менеджер окон X Window System  приложение, работающее «поверх» X Window System и определяющее интерфейс и взаимодействие с пользователем. В Unix подобных операционных системах пользователь может выбрать любой оконный менеджер по своему… …   Википедия

  • Оконный менеджер X Window System — Менеджер окон X Window System  приложение, работающее «поверх» X Window System и определяющее интерфейс и взаимодействие с пользователем. Содержание 1 Введение 2 Политика фокусирования 2.1 Focus follows mouse (фокус следует за мышью …   Википедия

  • X Window System — Тип оконная система Разработчик X.Org Foundation Операционная с …   Википедия

  • Фреймовый оконный менеджер X Window System — Фреймовый (или мозаичный) оконный менеджер  это менеджер окон X Window System, разбивающий рабочее пространство экрана на взаимно не пересекающиеся прямоугольные области  фреймы. Каждый фрейм используется для вывода информации отдельным …   Википедия

  • X Window — System Тип оконная система Разработчик X.Org Foundation ОС различные Версия X11R7.4 23 сентября 2008 …   Википедия

  • Tiling window manager — Фреймовый (или мозаичный) оконный менеджер  это менеджер окон X Window System, разбивающий рабочее пространство экрана на взаимно не пересекающиеся прямоугольные области  фреймы. Каждый фрейм используется для вывода информации отдельным… …   Википедия

  • X-сервер — X Window System Тип оконная система Разработчик X.Org Foundation ОС различные Версия X11R7.4 23 сентября 2008 …   Википедия

  • X11 — X Window System Тип оконная система Разработчик X.Org Foundation ОС различные Версия X11R7.4 23 сентября 2008 …   Википедия

  • X11R6 — X Window System Тип оконная система Разработчик X.Org Foundation ОС различные Версия X11R7.4 23 сентября 2008 …   Википедия

  • XOrg — X Window System Тип оконная система Разработчик X.Org Foundation ОС различные Версия X11R7.4 23 сентября 2008 …   Википедия


Поделиться ссылкой на выделенное

Прямая ссылка:
Нажмите правой клавишей мыши и выберите «Копировать ссылку»

We are using cookies for the best presentation of our site. Continuing to use this site, you agree with this.