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

[Jani Nikula <jani.nikula@linux.intel.com>]

On Wed, 15 Apr 2020, Hans de Goede <hdegoede@redhat.com> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel