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.
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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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
