RFC: Drm-connector properties managed by another driver / privacy screen support

Pekka Paalanen ppaalanen at gmail.com
Fri Apr 17 09:05:06 UTC 2020


On Thu, 16 Apr 2020 00:10:06 +0300
Jani Nikula <jani.nikula at linux.intel.com> wrote:

> On Wed, 15 Apr 2020, Rajat Jain <rajatja at google.com> wrote:

> > * I think having 2 properties might be a confusing UAPI. Also, we have
> > existing properties like link-status that can be changed by both the
> > user and the hardware.  
> 
> I think the consensus is that all properties that get changed by both
> userspace and the kernel are mistakes, and the way to handle it is to
> have two properties.

Yes, I very much agree with Jani.

I don't like KMS properties that are writable by both the driver and
userspace. It's awkward to handle in userspace and fundamentally racy
aside from tricks like "what you wrote is not what you read back". I
have ranted against that when looking at HDCP properties, e.g.:
https://lists.freedesktop.org/archives/dri-devel/2019-July/226424.html

See also my other email in this thread about how userspace uses atomic
KMS UAPI: you must expect that userspace will always write the
property for any KMS update, even if it does not change its value, so
any change done by the kernel is randomly lost unless the property is
read-only or otherwise weird.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200417/c3aa6b71/attachment.sig>


More information about the dri-devel mailing list