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

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

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

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

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

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

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

В статье описаны некоторые методы взаимодействия графической системы X Windows System с аппаратным обеспечением. На примере архитектуры EXA рассмотрены основные операции аппаратного 2D-ускорения.

Для исследования производительности было проведено тестирование Xorg с помощью утилиты x11perf версии 1.5. Тестирование проводилось в 5 режимах с использованием аппаратного 2D-ускорения и без. На основании результатов тестирования можно сделать вывод, что использование аппаратного 2D-ускорения с EXA оправдано в случаях, когда планируется использование изображений с высоким разрешением или есть необходимость снизить загрузку центрального процессора.

Тестирование производительности с отключенным взаимодействием с аппаратной частью (2D GPU + dummy EXA) показало, что использование EXA существенно влияет на скорость выполнения тестов, поскольку только на определенном наборе тестов драйвер 2D GPU + dummy EXA показывает лучший результат относительно драйвера modesetting.

Следует отметить, что использование EXA c DRM-стеком требует дополнительного исследования, так как при использовании DRM-стека с опцией EXA_MIXED_PIXMAPS в большинстве случаев операции масштабирования, копирования pixmap, заливки сплошным цветом и т.д. осуществляются на CPU. В определенных ситуациях отсутствие этой опции может привести к ряду графических артефактов в виде неперерисовывающихся областей изображения при обновлении кадрового буфера.