[HN Gopher] Accessing a DRM Framebuffer to display an image
       ___________________________________________________________________
        
       Accessing a DRM Framebuffer to display an image
        
       Author : compressedgas
       Score  : 65 points
       Date   : 2024-11-30 12:29 UTC (7 days ago)
        
 (HTM) web link (embear.ch)
 (TXT) w3m dump (embear.ch)
        
       | mdp2021 wrote:
       | In case anyone misinterprets it:
       | 
       | DRM here is for Direct Rendering Manager (not e.g. interfaces
       | studied to limit access to content).
        
       | thebruce87m wrote:
       | Excellent, succinct article. Having fought to understand this
       | process years ago I would have loved to find this exact article
       | at the time.
        
       | rjsw wrote:
       | For a bit more complicated application also using DRM directly
       | there is kmscube [1].
       | 
       | [1] https://gitlab.freedesktop.org/mesa/kmscube
        
       | dividuum wrote:
       | I've worked a lot this year on writing DRM/KMS code while porting
       | my digital signage player (https://info-beamer.com) to support
       | the Raspberry Pi5. Since they moved away from their proprietary
       | Broadcom provided graphical APIs (OMX/dispmanx) the Pi now fully
       | supports DRM and the implementation is really solid by now.
       | 
       | There is a ton more to learn: KMS (kernel mode setting) allows
       | fine control over the video mode in case you cannot or do not
       | want to rely on auto-detection.
       | 
       | Then there's the atomic API: Unlike in the blog post, all changes
       | applied to the output (from video mode to plane positions or
       | assigned framebuffers...) are gathered and then applied
       | atomically in a single commit. If necessary you can test if your
       | atomic commit is correct and will work by doing a "Test only
       | commit" before doing the real commit. Making changes atomically
       | avoids all kinds of race conditions resulting in, for example,
       | screen tearing.
       | 
       | Then there's the interaction with video decoding: Using FFmpeg on
       | the Pi allows you to access to hardware decoder. They produce DRM
       | framebuffers for each video frame. You can then directly assign
       | them to planes and position them on the screen. The resulting
       | playback is zero-copy and as fast as it gets on the Pi.
       | 
       | Another fun feature is the Writeback connector, which unlike the
       | one ending up as an HDMI signal allows you to write your output
       | to a new DRM framebuffer. This can, for example, be used to take
       | screenshots of your output or even feed the buffer back into a
       | video encoder.
       | 
       | One very frustration aspect is that there is basically no real
       | documentation, especially about semantics. I guess it makes sense
       | if you consider that there's probably only a limited number of
       | API consumers (like desktop compositors, special video players).
        
       | maplant wrote:
       | DRM Framebuffers are also the preferred way to interface with
       | Vulkan renderers in GTK. For example, if you wanted to make a
       | game scene editor with gnome, you could render the scene to a DRM
       | Framebuffer and use a GTKGraphicsOffload widget to indicate that
       | it will continue to be updated outside of the event loop.
       | 
       | In practice I've never been able to get this work. Static images
       | totally fine. Graphics offloading fails and manually refreshing
       | the image causes some sort of memory leak in the GPU
        
       | sunk1st wrote:
       | Can this be done on Mac OS?
        
         | krackers wrote:
         | Only before 10.7 from userspace with CGDisplayBaseAddress
         | 
         | https://developer.apple.com/library/archive/documentation/Gr...
         | 
         | After 10.7 (and certainly post-Metal) I don't think the
         | framebuffer is accessible via userspace, you'd probably need to
         | create a kernel extension to expose it somehow.
         | 
         | Although windowserver must write to the framebuffer somehow so
         | there's probably a private API as well
        
       | leighleighleigh wrote:
       | Really helpful introduction to DRM for the uninitiated, thanks
        
       ___________________________________________________________________
       (page generated 2024-12-07 23:00 UTC)