Render only DRM devices

[Christian König]

Am 11.10.22 um 17:20 schrieb Simon Ser:
> 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?

Yes and that is completely intentional as well. At least for new 
hardware generations we shouldn't have any userspace using this any more.

DRM auth based authentication is seen as a security risk and we want to 
get rid of that for render only devices (at least for the new ones).

I should probably add a wider explanation to the commit message.

Thanks,
Christian.