Initial DRM Implementation

[ardera]

• add drm::Device:

  • basically a wrapper around the raw file-descriptor to an opened /dev/dri/cardX device node
  • owns a gbm_device and liftoff_device created using that same file descriptor
  • can create drm::Buffer objects using GBM and KMS, and upload those as framebuffers
  • can create a drm::Output object for the first connected display

• add drm::Buffer:

  • wrapper around an (unregistered) framebuffer
  • since there's multiple ways to create buffers with KMS, this is an abstract class, concrete implementations are in device.cc
  • knows its own dimensions, format, format modifier, and the GEM handle, offset, stride & size of its planes
  • can be memory-mapped
  • delegates to DRM_IOCTL_MODE_MAP_DUMP & mmap or gbm_bo_map internally
  • can be added as a framebuffer using drm::Device::addFramebuffer

• add drm::Framebuffer:

  • a special drm::Buffer that was registered as a framebuffer to a drm::Device
  • has an fb_id() that can be used as the FB_ID for atomic commits

• add drm::Output:

  • a logical display with a fixed video mode
  • == a DRM CRTC, Connector & mode tuple
  • owns the liftoff_layers
  • can be used to present a drm::Composition, which will set properties on the internal liftoff_layers

• add drm::Composition:

  • an assembled frame, consisting of multiple layers with framebuffers
  • can also contain a pointer layer, to show a mouse cursor

[ardera]

Let me know what you think of the general design. I think you could also argue for something like this instead:

class OutputLayer {
  public:
    void setBuffer();
    void setSourcePosition();
    void setOutputPosition();
    void setZpos();
};

class Output {
  public:
    std::unique_ptr<OutputLayer> createLayer();

    void commit();
}

Also, right now only the default cursor can be imported and shown on screen. For cursor loading from files, I think it'd be best to drop in this and modify it to fit: https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/cursor (It's basically an adaption of libxcursor, so I think it's fine to adapt it again for our usecase, and it's MIT licensed)

[jwinarske]

@ardera

I think this is a good start. I'm defiantly a fan of making things work first :) Loading the default cursor is fine for now. We can build it out later. As for API opinions, I don't have any yet, I think once we bolt the Flutter Engine Compositor together it will be more clear; this is the most interesting for me at this point.

I'm thinking it might make sense to move your example code to the cursor example, what do you think? I had something in mind for the simple app. Planned patterns track what has been done in waypp.

[jwinarske]

@ardera Also note that I have a branch where I pulled in libliftoff as C++; re-wrote it (without AI assistance). It's needs a little more work, but it's fairly simple and no sense in duplicating things

[jwinarske]

@ardera what's your test setup to run drm-simple?

Running on Ubuntu 20.04 LTS with GCC 9.4 it required this diff to build:

tcna@TC-4000694:~/CLionProjects/drmpp-ardera$ git diff
diff --git a/examples/drm_simple.cc b/examples/drm_simple.cc
index c411528..38e4024 100644
--- a/examples/drm_simple.cc
+++ b/examples/drm_simple.cc
@@ -134,10 +134,10 @@ class App final {

     fb_shared->fill(color);

-    auto layer = drmpp::drm::Composition::Layer{
+    const auto layer = drmpp::drm::Composition::Layer{
         fb_shared,
         {0, 0, width, height},
-        {x, y, width, height},
+        {static_cast<uint32_t>(x), static_cast<uint32_t>(y), width, height},
     };

     composition.addLayer(layer);
diff --git a/include/drmpp/drm/composition.h b/include/drmpp/drm/composition.h
index 1872dec..0a7075a 100644
--- a/include/drmpp/drm/composition.h
+++ b/include/drmpp/drm/composition.h
@@ -18,7 +18,6 @@
 #define INCLUDE_DRMPP_DRM_COMPOSITION_H_

 #include <memory>
-#include <span>
 #include <vector>

 #include <xf86drm.h>
diff --git a/subprojects/libliftoff b/subprojects/libliftoff
--- a/subprojects/libliftoff
+++ b/subprojects/libliftoff
@@ -1 +1 @@
-Subproject commit 8b08dc1c14fd019cc90ddabe34ad16596b0691f4
+Subproject commit 8b08dc1c14fd019cc90ddabe34ad16596b0691f4-dirty

libliftoff change was the 1UL change. Otherwise it will fail to build.

Running

./drm-simple

it shows a black screen with this pointer image, no color squares.

Changing it to:

SPDLOG_LEVEL=trace ./drm-simple

I get the same pointer with colored squares.

[ardera]

I'm on a debian bookworm VM with clang 14; I did get some warnings, but other than that the build was fine.

The broken cursor is intentional but only temporary, the cursor image in left_ptr_default.h is a compressed X11 cursor file rather than a raw RGBA pixel buffer, so until wayland-cursor/libxcursor is checked in to interpret that cursor file, you can't show it correctly. I thought about adding a fastlz-compressed RGBA pixel buffer so it would be correct, but I thought if we're gonna add real cursor loading support anyway soon after, it'll be gone again anyway.

On the VM I never get colored squares because it only has one primary and one cursor plane (and drm_simple at least is not doing any composition), I'll test on a Raspberry Pi

[jwinarske]

@ardera I just merged XCursor support: https://github.com/jwinarske/drmpp/pull/16

The size preference will need to be better accounted for; later

[ardera]

btw, any preferences about meson.build format?

[jwinarske]

btw, any preferences about meson.build format?

My preference is to use the same thing CLion does, as that's my daily IDE.

[ardera]

it shows a black screen with this pointer image, no color squares.

Changing it to:

SPDLOG_LEVEL=trace ./drm-simple

I get the same pointer with colored squares.

I just tested on a raspberry pi 4, worked fine there. Though I did ran into some timeout issues with libliftoff which also resulted in incomplete pictures on screen, maybe that's what you saw? And SPDLOG_LEVEL=trace somehow changed the timeout behaviour, making it show different things? Otherwise I wouldn't know what causes it.

If it still ocurrs with the new version, could you run with tools/drm-debug.sh and share the output?

Also, libliftoff seems to be suuper slow when there's a lot of hardware planes present. On the Pi 4 there's 28 (that are compatible with HDMI-0) and libliftoff does a whopping 3213 atomic test ioctls. I think it takes about half a second for it to determine a plane allocation. So something about that algorithm needs to be changed as well.