Render only DRM devices

Simon Ser contact at emersion.fr
Tue Oct 11 15:20:40 UTC 2022


On Tuesday, October 11th, 2022 at 13:56, Christian König <ckoenig.leichtzumerken at gmail.com> wrote:

> Am 11.10.22 um 13:37 schrieb Simon Ser:
> 
> > On Tuesday, October 11th, 2022 at 13:04, Christian König ckoenig.leichtzumerken at gmail.com wrote:
> > 
> > > we already have quite a bunch of devices which are essentially render
> > > only and don't expose any connectors or more general display functionality.
> > > 
> > > Just recently I ran into a case where an older X/DDX combination
> > > caused problems for such a device so I looked a bit into the
> > > possibility to allow drivers to disable the primary node and only
> > > expose the render node.
> > > 
> > > It turned out that this effectively hides the device from X, but
> > > OpenGL and Vulkan can still use it perfectly fine.
> > > 
> > > The only crux is that this is checked so early in the initialization
> > > that drivers don't have an opportunity to update their
> > > dev->driver_features. So we will always need a separate drm_driver
> > > structure for render only devices.
> > > Typically render-only devices still expose a primary node, but don't
> > > expose any KMS resources on it. See drmIsKMS() in libdrm.
> > 
> > Primary nodes could still be used by older user-space for rendering with
> > legacy DRM authentication.
> 
> Yeah, and that's exactly what we try to avoid :)

But, wouldn't that regress user-space which renders using primary nodes +
DRM auth?


More information about the dri-devel mailing list