On Tue, 21 Apr 2020 14:37:41 +0200 Hans de Goede <hdegoede@xxxxxxxxxx> 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
Attachment:
pgp0tuyGGYb7c.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
