RE: [External] Re: RFC: Drm-connector properties managed by another driver / privacy screen support

From: Mark Pearson <mpearson@lenovo.com>
To: Hans de Goede <hdegoede@redhat.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>
Cc: Benjamin Berg <bberg@redhat.com>,
	Christian Kellner <ckellner@redhat.com>,
	Javier Martinez Canillas <javierm@redhat.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Rajat Jain <rajatja@google.com>,
	Nitin Joshi1 <njoshi1@lenovo.com>
Subject: RE: [External] Re: RFC: Drm-connector properties managed by another driver / privacy screen support
Date: Wed, 15 Apr 2020 17:14:09 +0000	[thread overview]
Message-ID: <SG2PR03MB3324D2E70FF609FA020F6C9EBDDB0@SG2PR03MB3324.apcprd03.prod.outlook.com> (raw)
In-Reply-To: <d47ba6ef-efd0-9f28-1ae4-b971b95a8f8b@redhat.com>

Hi,

> -----Original Message-----
> From: Hans de Goede <hdegoede@redhat.com>
> Sent: Wednesday, April 15, 2020 11:41 AM
> On 4/15/20 5:28 PM, Jani Nikula wrote:
> > On Wed, 15 Apr 2020, Hans de Goede <hdegoede@redhat.com> wrote:
> > Moreover, do we actually need two properties, one which could indicate
> > userspace's desire for the property, and another that tells the hardware
> > state?
> 
> No I do not think so. I would expect there to just be one property,
> I guess that if the state is (partly) firmware controlled then there
> might be a race, but we will need a notification mechanism (*) for
> firmware triggered state changes anyways, so shortly after loosing
> the race userspace will process the notification and it will know
> about it.
> 
> One thing which might be useful is a way to signal that the property
> is read-only in case we ever hit hw where that is the case.
> 
> > 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.
> 
> In my experience with keyboard-backlight support, we will (unfortunately)
> see a mix and in some case we will get a notification that the firmware
> has adjusted the state, rather then just getting a keypress and
> dealing with that ourselves.  In some cases we may even be able to
> choose, so the fw will deal with it by default but we can ask it
> to just send a key-press.  But I do believe that we can *not* expect
> that we will always just get a keypress for userspace to deal with.
> 
Afraid, the "hotkeys" control for ePrivacy (Fn+D I believe) is very unlikely 
to change - Windows uses it as well...
We can do notification of any hotkey presses to update the DRM layer (and
userspace) if that helps

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel