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

The main purpose of the paper is to develop a driver architecture for a display transmitter link controller when the controller has its own registers and memory. The developed architecture should reduce update changes in the implementation code and should not require any special tools or methods to develop its implementations. The paper analyzes publicly accessible DRM subsystem-based drivers and identifies two main architecture types, which serve as a basis for the majority of open source drivers. It also analyzes the strengths and weaknesses of the architecture types to achieve the above purpose. The identified architecture types were used to build a new architecture that has the strengths of both types, which allows achieving the purpose.

The paper also describes the developed driver debugging methods, which are based on the architecture under analysis and take into account the possibility of errors in the hardware, absence or insufficiency of controller documentation and incomplete emulation of the devices being developed. The results were evaluated during development of the DisplayPort driver for a perspective controller, and the driver was tested together with a prototype device and a monitor supporting the DisplayPort 1.1 standard.

The results of this paper can be used to create new transmitter link controller drivers for Unix-like systems both when a production state controller exists and when doing parallel development of a new controller and
a driver for it.

The main purpose of the paper is to develop a driver architecture for a display transmitter link controller when the controller has its own registers and memory. The developed architecture should reduce update changes in the implementation code and should not require any special tools or methods to develop its implementations. The paper analyzes publicly accessible DRM subsystem-based drivers and identifies two main architecture types, which serve as a basis for the majority of open source drivers. It also analyzes the strengths and weaknesses of the architecture types to achieve the above purpose. The identified architecture types were used to build a new architecture that has the strengths of both types, which allows achieving the purpose.

The paper also describes the developed driver debugging methods, which are based on the architecture under analysis and take into account the possibility of errors in the hardware, absence or insufficiency of controller documentation and incomplete emulation of the devices being developed. The results were evaluated during development of the DisplayPort driver for a perspective controller, and the driver was tested together with a prototype device and a monitor supporting the DisplayPort 1.1 standard.

The results of this paper can be used to create new transmitter link controller drivers for Unix-like systems both when a production state controller exists and when doing parallel development of a new controller and
a driver for it.

This article describes several methods that the X Windows System interacts with hardware. The basic 2D hardware acceleration operations were examined using the EXA architecture as an example. Xorg was tested with x11perf version 1.5 to examine the performance.

Testing was carried out in 5 modes, i.e. with 2D hardware acceleration and without. The test results lead to the conclusion that the use of 2D hardware acceleration with EXA is justified when high-resolution images are to be used or it is necessary to reduce the load on the CPU.

Performance testing with disabled hardware interaction (2D GPU + dummy EXA) showed that the use of EXA significantly affects the test rate as 2D GPU + dummy EXA driver performs better compared to the modesetting driver only with a certain set of tests. It’s worth noting that the use of EXA with the DRM stack has to be studied further, since, in most cases, scaling, pixmap copying, solid color filling, and other operations are processed by the CPU when using the DRM stack with the EXA_MIXED_PIXMAPS option. In certain situations, the absence of this option can lead to many visual artifacts in the form of unrendered areas of the image when updating the framebuffer.