On Wed, 15 Apr 2020, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > ii. Currently the "privacy-screen" property added by Rajat's > patch-set is an enum with 2 possible values: > "Enabled" > "Disabled" > > We could add a third value "Not Available", which would be the > default and then for internal panels always add the property > so that we avoid the problem that detecting if the laptop has > an internal privacy screen needs to be done before the connector > is registered. Then we can add some hooks which allow an > lcdshadow-driver to register itself against a connector later > (which is non trivial wrt probe order, but lets ignore that for now). I regret dropping the ball on Rajat's series (sorry!). I do think having the connector property for this is the way to go. Even if we couldn't necessarily figure out all the details on the kernel internal connections, can we settle on the property though, so we could move forward with Rajat's series? Moreover, do we actually need two properties, one which could indicate userspace's desire for the property, and another that tells the hardware state? I'd so very much like to have no in-kernel/in-firmware shortcuts to enable/disable the privacy screen, and instead have any hardware buttons just be events that the userspace could react to. However I don't think that'll be the case unfortunately. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
