On Tuesday, October 11th, 2022 at 13:56, Christian König <ckoenig.leichtzumerken@xxxxxxxxx> wrote: > Am 11.10.22 um 13:37 schrieb Simon Ser: > > > On Tuesday, October 11th, 2022 at 13:04, Christian König ckoenig.leichtzumerken@xxxxxxxxx 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?
