[Intel-gfx] [PATCH] drm: Return -ENOTSUPP in drm_setclientcap() when driver do not support KMS

[Daniel Vetter]

On Fri, Sep 14, 2018 at 7:04 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> Quoting Souza, Jose (2018-09-14 17:30:59)
>> On Fri, 2018-09-14 at 09:15 +0100, Chris Wilson wrote:
>> > Quoting José Roberto de Souza (2018-09-13 23:13:41)
>> > > @@ -306,6 +306,9 @@ drm_setclientcap(struct drm_device *dev, void
>> > > *data, struct drm_file *file_priv)
>> > >  {
>> > >         struct drm_set_client_cap *req = data;
>> > >
>> > > +       if (!drm_core_check_feature(dev, DRIVER_MODESET))
>> > > +               return -ENOTSUPP;
>> >
>> > The wider question though is client cap restricted to modesetting
>> > capabilities? Or should each case include a check like
>> > DRM_CLIENT_CAP_ATOMIC.
>>
>> Well all of those:
>>
>> DRM_CLIENT_CAP_STEREO_3D
>> DRM_CLIENT_CAP_UNIVERSAL_PLANES
>> DRM_CLIENT_CAP_ATOMIC
>> DRM_CLIENT_CAP_ASPECT_RATIO
>> DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
>>
>> are just usefull with KMS.
>
> It more about the semantics. If it's the first guard in the function, it
> gives the impression that the setclientcap ioctl is KMS only. If they
> are repeated for each case, then it's clear that the ioctl is more
> general and it just those caps that are KMS only.
>
> Imo, the drm_client is wider than the kms interface, but I may be wrong.

In getcap we have 2 blocks, with DRIVER_MODESET check in between. I
think a comment along the lines of


> -Chris
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch