3.3. Understanding the pipeline¶
In this chapter, the idea is to understand the pipeline that describes where the video displays get their pixel colors from. Configuring the pipeline is explained in a later chapter.
This pipeline directly derives from the Linux kernel API named kernel mode setting (KMS) (part of the direct rendering manager (DRM) interface) with some naming differences though.
The left side of the following picture describes the relations between pipeline entities (or objects) and the right side shows a more visual representation of how an image is formed on a video display surface using the same entities.
To use a video display, our task is to build such valid pipeline. There are so many possible hardware configurations (different graphics chipsets, different video displays, etc.) that the KMS interface is very generic. It lets us build a pipeline quite liberally and then we can test it before enabling it for real if it is valid.
Controller and Plane entities of the graphics pipeline are invariant for each graphics chipset. However Connectors are not invariant because some technologies (such as DisplayPort Multi-Stream Transport) allow the use of connectors hubs which dynamically add additional Connector entities. Frames are managed by software hence they are not invariant either.
3.3.1. Listing entities¶
As our first code example in this tutorial, we will list all the entities of all the graphic cards we find on the system. The whole source code can be found here.
We load all the graphic cards with:
sys <- defaultSystemInit cards <- loadGraphicCards (systemDeviceManager sys)
Then we get entity identifiers with:
mids <- runE (getEntitiesIDs card)
The rest of the code deals with errors and printing the results on the terminal.
The best way to test this code is to use haskus-system-build tool.
> git clone https://github.com/haskus/haskus-system.git > cd haskus-system/haskus-system-examples > haskus-system-build test --init TutEntitiesIDs =================================================== Haskus system - build config --------------------------------------------------- GHC version: 8.6.4 Linux version: 5.1.15 Syslinux version: 6.03 Init program: TutEntitiesIDs =================================================== ==> Configuring Stack... stack will use a sandboxed GHC it installed For more information on paths, see 'stack path' and 'stack exec env' To use this GHC and packages outside of a project, consider using: stack ghc, stack ghci, stack runghc, or stack exec ==> Building with Stack... ==> Building ramdisk... 16299 blocs ==> Launching QEMU... Card 0 - Connector 33 - Controller 31 - Plane 30 [ 1.026338] reboot: Power down
The tool should download, build and install the necessary dependencies and
execute the resulting system into
QEMU. You can see that it reports one
Connector, one Controller and one Plane for the QEMU simulated graphics chipset
(the numbers are their unique identifiers).