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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 14, 2018 at 10:02 PM, Daniel Vetter <daniel@xxxxxxxx> wrote:
> On Fri, Sep 14, 2018 at 7:04 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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.

Oops, slipped :-)

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

/* No render-only settable capabilities for now */

/* Below caps only work with KMS drivers */
if (!drm_core_check_feature(DRIVER_MODESET))
   return -ENOTSUPP;

I think with that it's clear that it's _not_ the top-level check, and
if someone needs to add a gem cap, they know where to put it. Not that
we needed that anytime in the past 10 years, but who knows.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux