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

[Pekka Paalanen]

On Tue, 21 Apr 2020 14:37:41 +0200
Hans de Goede <hdegoede at redhat.com> wrote:

> TL;DR: Yes there will be races, because of both userspace +
> the firmware having; and potentially using r/w access to
> the privacy-screen state. But in practice I expect these
> to not really be an issue. Important here is that userspace
> only commits the property in a transaction to commit if
> it actually intends to change the property so as to not
> needlessly create a situation where we might hit the race.
> 
> As for 1 vs 2 properties for this I guess that in preparation
> for potential devices where the state is locked, having a
> r/w sw-state + a ro hw-state property makes sense.
> 
> So I suggest that we replace the current "privacy-screen" property
> from Rajat's patch-set with 2 props named:
> 
> "privacy-screen-sw-state" (r/w)
> "privacy-screen-hw-state" (ro)
> 
> Where for current gen hardware the privacy-screen-hw-state is
> just a mirror of the sw-state.

Hi,

this sounds like a good plan to me, assuming the kernel writes only to
the ro property and never to the r/w property.

I understand that as long as firmware hotkeys will toggle actual state,
there is no design that could work reliably if userspace will always
commit all KMS state even when it is not necessary. But not committing
KMS state unless it is actually necessary is really a new requirement on
userspace, so that needs to be documented before it's too late.

It's not enough to document "don't set it unless you want to
overwrite/change it" for privacy screen properties. It needs to be
documented as a general rule that userspace must follow with *unknown*
properties as well. "Do not restore unrecognized properties unless the
kernel KMS state might be incorrect compared to what you used to have."

This means that with a display server that does not understand privacy
screen properties, the end user will lose the privacy screen state on
every VT-switch back to the display server.

However, if we had a way to query the kernel for the default state to
reset unknown properties to, the kernel implementation could return the
current value of the privacy screen property instead of "off" to not
lose the firmware state. Assuming firmware hotkeys exist, but if they
don't then return just "off". The point is that the kernel who knows
all the properties makes the decision what a sane reset value is.
Userspace can always override the reset value for the properties
it recognizes.


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/20200421/0fa83b91/attachment-0001.sig>