[PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[Hans de Goede]

Hi All,

Here is a patch series for adding support for the electronic privacy screen
on/off events send on e.g. Dell Latitude 7300 models.

On these laptops the firmware does not allow querying the presence nor
the status of the eprivacy screen at boot. This makes it impossible to
implement the drm connector eprivacy properties API (1) since drm objects
do not allow adding new properties after creation and the presence of
the eprivacy cannot be detected at boot.

So instead this series adds 2 evdev keycodes for eprivacy screen on + off
and modifies the dell-wmi driver to use these, so that we can still
propagate these events to userspace for e.g. a DE to show an OSD.

Dmitry, can we get your ack for the addition of the 2 new keycodes?
I think it will be easiest if Ilpo merges the entire series through
the pdx86 tree with your ack for the keycodes.

Regards,

Hans


1) https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#standard-connector-properties


Hans de Goede (2):
  Input: Add keycodes for electronic privacy screen on/off hotkeys
  platform/x86: dell-wmi-base: Handle electronic privacy screen on/off
    events

 drivers/platform/x86/dell/dell-wmi-base.c | 12 ++++++++++++
 include/uapi/linux/input-event-codes.h    | 12 ++++++++++++
 2 files changed, 24 insertions(+)

-- 
2.51.0

[PATCH 1/2] Input: Add keycodes for electronic privacy screen on/off hotkeys

[Hans de Goede]

Add keycodes for hotkeys toggling the electronic privacy screen found on
some laptops on/off.

There already is an API for eprivacy screens as kernel-mode-setting drm
connector object properties:
https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#standard-connector-properties

this API also supports reporting when the eprivacy screen is turned on/off
by the embedded-controller (EC) in response to hotkey presses.

But on some laptops (e.g. the Dell Latitude 7300) the firmware does not
allow querying the presence nor the status of the eprivacy screen at boot.
This makes it impossible to implement the drm connector properties API
since drm objects do not allow adding new properties after creation and
the presence of the eprivacy cannot be detected at boot.

The first notice of the presence of an eprivacy screen on these laptops is
an EC generated (WMI) event when the eprivacy screen hotkeys are pressed.

In this case the new keycodes this change adds can be generated to notify
userspace of the eprivacy screen on/off hotkeys being pressed, so that
userspace can show the usual on-screen-display (OSD) notification for eprivacy
screen on/off to the user. This is similar to how e.g. touchpad on/off
keycodes are used to show the touchpad on/off OSD.

Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 include/uapi/linux/input-event-codes.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index ca5851e97fac..d2987786c28e 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -630,6 +630,18 @@
 #define KEY_BRIGHTNESS_MIN		0x250	/* Set Brightness to Minimum */
 #define KEY_BRIGHTNESS_MAX		0x251	/* Set Brightness to Maximum */
 
+/*
+ * Keycodes for hotkeys toggling the electronic privacy screen found on some
+ * laptops on/off. Note when the embedded-controller turns on/off the eprivacy
+ * screen itself then the state should be reported through drm connecter props:
+ * https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#standard-connector-properties
+ * Except when implementing the drm connecter properties API is not possible
+ * because e.g. the firmware does not allow querying the presence and/or status
+ * of the eprivacy screen at boot.
+ */
+#define KEY_EPRIVACY_SCREEN_ON		0x252
+#define KEY_EPRIVACY_SCREEN_OFF		0x253
+
 #define KEY_KBDINPUTASSIST_PREV		0x260
 #define KEY_KBDINPUTASSIST_NEXT		0x261
 #define KEY_KBDINPUTASSIST_PREVGROUP		0x262
-- 
2.51.0

Re: [PATCH 1/2] Input: Add keycodes for electronic privacy screen on/off hotkeys

[Dmitry Torokhov]

On Mon, Oct 20, 2025 at 05:23:30PM +0200, Hans de Goede wrote:
> Add keycodes for hotkeys toggling the electronic privacy screen found on
> some laptops on/off.
> 
> There already is an API for eprivacy screens as kernel-mode-setting drm
> connector object properties:
> https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#standard-connector-properties
> 
> this API also supports reporting when the eprivacy screen is turned on/off
> by the embedded-controller (EC) in response to hotkey presses.
> 
> But on some laptops (e.g. the Dell Latitude 7300) the firmware does not
> allow querying the presence nor the status of the eprivacy screen at boot.
> This makes it impossible to implement the drm connector properties API
> since drm objects do not allow adding new properties after creation and
> the presence of the eprivacy cannot be detected at boot.
> 
> The first notice of the presence of an eprivacy screen on these laptops is
> an EC generated (WMI) event when the eprivacy screen hotkeys are pressed.
> 
> In this case the new keycodes this change adds can be generated to notify
> userspace of the eprivacy screen on/off hotkeys being pressed, so that
> userspace can show the usual on-screen-display (OSD) notification for eprivacy
> screen on/off to the user. This is similar to how e.g. touchpad on/off
> keycodes are used to show the touchpad on/off OSD.
> 
> Signed-off-by: Hans de Goede <hansg@kernel.org>

Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

> ---
>  include/uapi/linux/input-event-codes.h | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index ca5851e97fac..d2987786c28e 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -630,6 +630,18 @@
>  #define KEY_BRIGHTNESS_MIN		0x250	/* Set Brightness to Minimum */
>  #define KEY_BRIGHTNESS_MAX		0x251	/* Set Brightness to Maximum */
>  
> +/*
> + * Keycodes for hotkeys toggling the electronic privacy screen found on some
> + * laptops on/off. Note when the embedded-controller turns on/off the eprivacy
> + * screen itself then the state should be reported through drm connecter props:
> + * https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#standard-connector-properties
> + * Except when implementing the drm connecter properties API is not possible
> + * because e.g. the firmware does not allow querying the presence and/or status
> + * of the eprivacy screen at boot.
> + */
> +#define KEY_EPRIVACY_SCREEN_ON		0x252
> +#define KEY_EPRIVACY_SCREEN_OFF		0x253
> +
>  #define KEY_KBDINPUTASSIST_PREV		0x260
>  #define KEY_KBDINPUTASSIST_NEXT		0x261
>  #define KEY_KBDINPUTASSIST_PREVGROUP		0x262

-- 
Dmitry

[PATCH 2/2] platform/x86: dell-wmi-base: Handle electronic privacy screen on/off events

[Hans de Goede]

Add handling for events for the electronic privacy screen found on some
models (e.g. Dell Latitude 7300) being toggled on/off.

Emit KEY_EPRIVACY_SCREEN_OFF / KEY_EPRIVACY_SCREEN_ON events for this so
that userspace can show the usual on-screen-display (OSD) notification for
eprivacy screen on/off to the user.

Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 drivers/platform/x86/dell/dell-wmi-base.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/platform/x86/dell/dell-wmi-base.c b/drivers/platform/x86/dell/dell-wmi-base.c
index 841a5414d28a..28076929d6af 100644
--- a/drivers/platform/x86/dell/dell-wmi-base.c
+++ b/drivers/platform/x86/dell/dell-wmi-base.c
@@ -365,6 +365,13 @@ static const struct key_entry dell_wmi_keymap_type_0012[] = {
 	/* Backlight brightness change event */
 	{ KE_IGNORE, 0x0003, { KEY_RESERVED } },
 
+	/*
+	 * Electronic privacy screen toggled, extended data gives state,
+	 * separate entries for on/off see handling in dell_wmi_process_key().
+	 */
+	{ KE_KEY, 0x000c, { KEY_EPRIVACY_SCREEN_OFF } },
+	{ KE_KEY, 0x000c, { KEY_EPRIVACY_SCREEN_ON } },
+
 	/* Ultra-performance mode switch request */
 	{ KE_IGNORE, 0x000d, { KEY_RESERVED } },
 
@@ -435,6 +442,11 @@ static int dell_wmi_process_key(struct wmi_device *wdev, int type, int code, u16
 				      "Dell tablet mode switch",
 				      SW_TABLET_MODE, !buffer[0]);
 		return 1;
+	} else if (type == 0x0012 && code == 0x000c && remaining > 0) {
+		/* Eprivacy toggle, switch to "on" key entry for on events */
+		if (buffer[0] == 2)
+			key++;
+		used = 1;
 	} else if (type == 0x0012 && code == 0x000d && remaining > 0) {
 		value = (buffer[2] == 2);
 		used = 1;
-- 
2.51.0

Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[Dmitry Torokhov]

Hi Hans,

On Mon, Oct 20, 2025 at 05:23:29PM +0200, Hans de Goede wrote:
> Hi All,
> 
> Here is a patch series for adding support for the electronic privacy screen
> on/off events send on e.g. Dell Latitude 7300 models.
> 
> On these laptops the firmware does not allow querying the presence nor
> the status of the eprivacy screen at boot. This makes it impossible to
> implement the drm connector eprivacy properties API (1) since drm objects
> do not allow adding new properties after creation and the presence of
> the eprivacy cannot be detected at boot.
> 
> So instead this series adds 2 evdev keycodes for eprivacy screen on + off
> and modifies the dell-wmi driver to use these, so that we can still
> propagate these events to userspace for e.g. a DE to show an OSD.
> 
> Dmitry, can we get your ack for the addition of the 2 new keycodes?
> I think it will be easiest if Ilpo merges the entire series through
> the pdx86 tree with your ack for the keycodes.

Yes, that should be fine, although I wonder if this is best modeled as a
pair of keys or a single switch? I know we have touchpad on/off but I
wonder if it was the best option... Probably more convenient at some
point if it was done through the atkbd.

Thanks.

-- 
Dmitry

Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[Hans de Goede]

Hi Dmitry,

On 22-Oct-25 7:54 PM, Dmitry Torokhov wrote:
> Hi Hans,
> 
> On Mon, Oct 20, 2025 at 05:23:29PM +0200, Hans de Goede wrote:
>> Hi All,
>>
>> Here is a patch series for adding support for the electronic privacy screen
>> on/off events send on e.g. Dell Latitude 7300 models.
>>
>> On these laptops the firmware does not allow querying the presence nor
>> the status of the eprivacy screen at boot. This makes it impossible to
>> implement the drm connector eprivacy properties API (1) since drm objects
>> do not allow adding new properties after creation and the presence of
>> the eprivacy cannot be detected at boot.
>>
>> So instead this series adds 2 evdev keycodes for eprivacy screen on + off
>> and modifies the dell-wmi driver to use these, so that we can still
>> propagate these events to userspace for e.g. a DE to show an OSD.
>>
>> Dmitry, can we get your ack for the addition of the 2 new keycodes?
>> I think it will be easiest if Ilpo merges the entire series through
>> the pdx86 tree with your ack for the keycodes.
> 
> Yes, that should be fine, although I wonder if this is best modeled as a
> pair of keys or a single switch? I know we have touchpad on/off but I
> wonder if it was the best option... Probably more convenient at some
> point if it was done through the atkbd.

EV_SW has the same problem as the drm property API. The mere presence
of advertising a new SW_PRIVACY_SCREEN capability on an /dev/input/event#
node would convey to userspace that there is an eprivacy-screen and we
also would need to know the initial state (on/off) for using an EV_SW
for this and we know neither presence nor status before hand (1).

The real issue is that the firmware does not tell us if there is
an eprivacy screen. As mentioned the first time we find out is when
the eprivacy screen gets toggled on or off.

We are having similar issues with SW_TABLET_MODE which userspace
uses to e.g. show / not show an on screen keyboard when a text
entry field is focussed. So the mere presence of SW_TABLET_MODE
can influence userspace without ever sending any events and we
have all kind of special handling in various foo-laptop and
intel-vbtn, etc. drivers for this, which I would like to avoid
here.

So having ON / OFF EV_KEY events which we only generate when
there is an actual eprivacy on/off event are by far the most KISS
and fool proof solution.

Regards,

Hans

Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[Dmitry Torokhov]

On Wed, Oct 22, 2025 at 08:24:46PM +0200, Hans de Goede wrote:
> Hi Dmitry,
> 
> On 22-Oct-25 7:54 PM, Dmitry Torokhov wrote:
> > Hi Hans,
> > 
> > On Mon, Oct 20, 2025 at 05:23:29PM +0200, Hans de Goede wrote:
> >> Hi All,
> >>
> >> Here is a patch series for adding support for the electronic privacy screen
> >> on/off events send on e.g. Dell Latitude 7300 models.
> >>
> >> On these laptops the firmware does not allow querying the presence nor
> >> the status of the eprivacy screen at boot. This makes it impossible to
> >> implement the drm connector eprivacy properties API (1) since drm objects
> >> do not allow adding new properties after creation and the presence of
> >> the eprivacy cannot be detected at boot.
> >>
> >> So instead this series adds 2 evdev keycodes for eprivacy screen on + off
> >> and modifies the dell-wmi driver to use these, so that we can still
> >> propagate these events to userspace for e.g. a DE to show an OSD.
> >>
> >> Dmitry, can we get your ack for the addition of the 2 new keycodes?
> >> I think it will be easiest if Ilpo merges the entire series through
> >> the pdx86 tree with your ack for the keycodes.
> > 
> > Yes, that should be fine, although I wonder if this is best modeled as a
> > pair of keys or a single switch? I know we have touchpad on/off but I
> > wonder if it was the best option... Probably more convenient at some
> > point if it was done through the atkbd.
> 
> EV_SW has the same problem as the drm property API. The mere presence
> of advertising a new SW_PRIVACY_SCREEN capability on an /dev/input/event#
> node would convey to userspace that there is an eprivacy-screen and we
> also would need to know the initial state (on/off) for using an EV_SW
> for this and we know neither presence nor status before hand (1).

How is this different form presence of KEY_PRIVACY_SCREEN_ON/OFF? They
also imply that there is a privacy screen.

If we really do not know if there is functionality present or not maybe
you can register a 2nd input device for the privacy switch upon
receiving the first event for it?

> 
> The real issue is that the firmware does not tell us if there is
> an eprivacy screen. As mentioned the first time we find out is when
> the eprivacy screen gets toggled on or off.
> 
> We are having similar issues with SW_TABLET_MODE which userspace
> uses to e.g. show / not show an on screen keyboard when a text
> entry field is focussed. So the mere presence of SW_TABLET_MODE
> can influence userspace without ever sending any events and we
> have all kind of special handling in various foo-laptop and
> intel-vbtn, etc. drivers for this, which I would like to avoid
> here.

Probably have a similar solution: delay registration of corresponding
input device until you know the existence/state?

> 
> So having ON / OFF EV_KEY events which we only generate when
> there is an actual eprivacy on/off event are by far the most KISS
> and fool proof solution.

This assumes you assign special meaning to it (i.e. pretend that it is
not really there until you see events).

Thanks.

-- 
Dmitry

Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[Hans de Goede]

Hi,

On 22-Oct-25 8:40 PM, Dmitry Torokhov wrote:
> On Wed, Oct 22, 2025 at 08:24:46PM +0200, Hans de Goede wrote:
>> Hi Dmitry,
>>
>> On 22-Oct-25 7:54 PM, Dmitry Torokhov wrote:
>>> Hi Hans,
>>>
>>> On Mon, Oct 20, 2025 at 05:23:29PM +0200, Hans de Goede wrote:
>>>> Hi All,
>>>>
>>>> Here is a patch series for adding support for the electronic privacy screen
>>>> on/off events send on e.g. Dell Latitude 7300 models.
>>>>
>>>> On these laptops the firmware does not allow querying the presence nor
>>>> the status of the eprivacy screen at boot. This makes it impossible to
>>>> implement the drm connector eprivacy properties API (1) since drm objects
>>>> do not allow adding new properties after creation and the presence of
>>>> the eprivacy cannot be detected at boot.
>>>>
>>>> So instead this series adds 2 evdev keycodes for eprivacy screen on + off
>>>> and modifies the dell-wmi driver to use these, so that we can still
>>>> propagate these events to userspace for e.g. a DE to show an OSD.
>>>>
>>>> Dmitry, can we get your ack for the addition of the 2 new keycodes?
>>>> I think it will be easiest if Ilpo merges the entire series through
>>>> the pdx86 tree with your ack for the keycodes.
>>>
>>> Yes, that should be fine, although I wonder if this is best modeled as a
>>> pair of keys or a single switch? I know we have touchpad on/off but I
>>> wonder if it was the best option... Probably more convenient at some
>>> point if it was done through the atkbd.
>>
>> EV_SW has the same problem as the drm property API. The mere presence
>> of advertising a new SW_PRIVACY_SCREEN capability on an /dev/input/event#
>> node would convey to userspace that there is an eprivacy-screen and we
>> also would need to know the initial state (on/off) for using an EV_SW
>> for this and we know neither presence nor status before hand (1).
> 
> How is this different form presence of KEY_PRIVACY_SCREEN_ON/OFF? They
> also imply that there is a privacy screen.

I've never seen userspace change behavior depending on which keycodes
are advertised as possibly being send by a device.

Typically userspace does not care of the initial state of keys (it
assumes they all start unpressed), where as for switches the initial
state matters and we cannot query the initial state here.

> If we really do not know if there is functionality present or not maybe
> you can register a 2nd input device for the privacy switch upon
> receiving the first event for it?

Yes that is one of the hacks which we use for SW_TABLET_MODE, but
I do really see this as a hack and I would like to avoid this if
possible.

>> The real issue is that the firmware does not tell us if there is
>> an eprivacy screen. As mentioned the first time we find out is when
>> the eprivacy screen gets toggled on or off.
>>
>> We are having similar issues with SW_TABLET_MODE which userspace
>> uses to e.g. show / not show an on screen keyboard when a text
>> entry field is focussed. So the mere presence of SW_TABLET_MODE
>> can influence userspace without ever sending any events and we
>> have all kind of special handling in various foo-laptop and
>> intel-vbtn, etc. drivers for this, which I would like to avoid
>> here.
> 
> Probably have a similar solution: delay registration of corresponding
> input device until you know the existence/state?

Right that is already done in some cases. What complicates things
wrt SW_TABLET_MODE is that we would like to have it present as soon
as the driver probes so that a 2-in-1 which is booted in tablet mode
behaves correctly from the start. Most of the firmware APIs for
SW_TABLET_MODE support getting the initial state, but their implementation
can be unreliable. So we only fallback to the delayed registration
for known unreliable models, which requires quirks...

This is getting a bit offtopic but it does show why I'm not in
favor of using EV_SW style input-devices when there is no reliable
initial state.

>> So having ON / OFF EV_KEY events which we only generate when
>> there is an actual eprivacy on/off event are by far the most KISS
>> and fool proof solution.
> 
> This assumes you assign special meaning to it (i.e. pretend that it is
> not really there until you see events).

As I see it there are 2 cases:

1. We can query the presence and status of the eprivacy screen at
boot, this would map nicely to a SW_EPRIVACY_SCREEN, but we already
have the drm properties API for this and this was put in DRM because
this ties the privacy screen to a specific output which is useful
to know.

2. The first thing we findout / hear about an eprivacy screen is
a eprivacy on/off hotkey press. Notice the "hotkey" there iow
this event gets send as the result of a key-press event.

For 2. I think that just modelling this as the key events which
these also happen to actually be is much simpler then dynamically
registering a second input device on the first such a key press

and I also think that the userspace side will be simpler with
just key-press events rather then having to deal with the dynamic
second device registration + reading an EV_SW .

Regards,

Hans

Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[Dmitry Torokhov]

On Wed, Oct 22, 2025 at 09:15:35PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 22-Oct-25 8:40 PM, Dmitry Torokhov wrote:
> > On Wed, Oct 22, 2025 at 08:24:46PM +0200, Hans de Goede wrote:
> >> Hi Dmitry,
> >>
> >> On 22-Oct-25 7:54 PM, Dmitry Torokhov wrote:
> >>> Hi Hans,
> >>>
> >>> On Mon, Oct 20, 2025 at 05:23:29PM +0200, Hans de Goede wrote:
> >>>> Hi All,
> >>>>
> >>>> Here is a patch series for adding support for the electronic privacy screen
> >>>> on/off events send on e.g. Dell Latitude 7300 models.
> >>>>
> >>>> On these laptops the firmware does not allow querying the presence nor
> >>>> the status of the eprivacy screen at boot. This makes it impossible to
> >>>> implement the drm connector eprivacy properties API (1) since drm objects
> >>>> do not allow adding new properties after creation and the presence of
> >>>> the eprivacy cannot be detected at boot.
> >>>>
> >>>> So instead this series adds 2 evdev keycodes for eprivacy screen on + off
> >>>> and modifies the dell-wmi driver to use these, so that we can still
> >>>> propagate these events to userspace for e.g. a DE to show an OSD.
> >>>>
> >>>> Dmitry, can we get your ack for the addition of the 2 new keycodes?
> >>>> I think it will be easiest if Ilpo merges the entire series through
> >>>> the pdx86 tree with your ack for the keycodes.
> >>>
> >>> Yes, that should be fine, although I wonder if this is best modeled as a
> >>> pair of keys or a single switch? I know we have touchpad on/off but I
> >>> wonder if it was the best option... Probably more convenient at some
> >>> point if it was done through the atkbd.
> >>
> >> EV_SW has the same problem as the drm property API. The mere presence
> >> of advertising a new SW_PRIVACY_SCREEN capability on an /dev/input/event#
> >> node would convey to userspace that there is an eprivacy-screen and we
> >> also would need to know the initial state (on/off) for using an EV_SW
> >> for this and we know neither presence nor status before hand (1).
> > 
> > How is this different form presence of KEY_PRIVACY_SCREEN_ON/OFF? They
> > also imply that there is a privacy screen.
> 
> I've never seen userspace change behavior depending on which keycodes
> are advertised as possibly being send by a device.

On Chrome OS we are trying to go by what peripherals report, but I can
see that it might not work for a generic Linux distro.

> 
> Typically userspace does not care of the initial state of keys (it
> assumes they all start unpressed), where as for switches the initial
> state matters and we cannot query the initial state here.
> 
> > If we really do not know if there is functionality present or not maybe
> > you can register a 2nd input device for the privacy switch upon
> > receiving the first event for it?
> 
> Yes that is one of the hacks which we use for SW_TABLET_MODE, but
> I do really see this as a hack and I would like to avoid this if
> possible.
> 
> >> The real issue is that the firmware does not tell us if there is
> >> an eprivacy screen. As mentioned the first time we find out is when
> >> the eprivacy screen gets toggled on or off.
> >>
> >> We are having similar issues with SW_TABLET_MODE which userspace
> >> uses to e.g. show / not show an on screen keyboard when a text
> >> entry field is focussed. So the mere presence of SW_TABLET_MODE
> >> can influence userspace without ever sending any events and we
> >> have all kind of special handling in various foo-laptop and
> >> intel-vbtn, etc. drivers for this, which I would like to avoid
> >> here.
> > 
> > Probably have a similar solution: delay registration of corresponding
> > input device until you know the existence/state?
> 
> Right that is already done in some cases. What complicates things
> wrt SW_TABLET_MODE is that we would like to have it present as soon
> as the driver probes so that a 2-in-1 which is booted in tablet mode
> behaves correctly from the start. Most of the firmware APIs for
> SW_TABLET_MODE support getting the initial state, but their implementation
> can be unreliable. So we only fallback to the delayed registration
> for known unreliable models, which requires quirks...
> 
> This is getting a bit offtopic but it does show why I'm not in
> favor of using EV_SW style input-devices when there is no reliable
> initial state.
> 
> >> So having ON / OFF EV_KEY events which we only generate when
> >> there is an actual eprivacy on/off event are by far the most KISS
> >> and fool proof solution.
> > 
> > This assumes you assign special meaning to it (i.e. pretend that it is
> > not really there until you see events).
> 
> As I see it there are 2 cases:
> 
> 1. We can query the presence and status of the eprivacy screen at
> boot, this would map nicely to a SW_EPRIVACY_SCREEN, but we already
> have the drm properties API for this and this was put in DRM because
> this ties the privacy screen to a specific output which is useful
> to know.
> 
> 2. The first thing we findout / hear about an eprivacy screen is
> a eprivacy on/off hotkey press. Notice the "hotkey" there iow
> this event gets send as the result of a key-press event.
> 
> For 2. I think that just modelling this as the key events which
> these also happen to actually be is much simpler then dynamically
> registering a second input device on the first such a key press
> 
> and I also think that the userspace side will be simpler with
> just key-press events rather then having to deal with the dynamic
> second device registration + reading an EV_SW .

OK, I agree that if you have a reliable way of querying the state you
can simply go with the DRM properties solution.

Since this keys are in effect notification only, not something that
userspace needs to actively handle, I don't suppose you can add another
state to the DRM privacy-screen hw-state: "unknown" and update it when  
the state becomes known?

Thanks.

-- 
Dmitry

Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[Hans de Goede]

Hi,

On 22-Oct-25 10:24 PM, Dmitry Torokhov wrote:
> On Wed, Oct 22, 2025 at 09:15:35PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 22-Oct-25 8:40 PM, Dmitry Torokhov wrote:
>>> On Wed, Oct 22, 2025 at 08:24:46PM +0200, Hans de Goede wrote:
>>>> Hi Dmitry,
>>>>
>>>> On 22-Oct-25 7:54 PM, Dmitry Torokhov wrote:
>>>>> Hi Hans,
>>>>>
>>>>> On Mon, Oct 20, 2025 at 05:23:29PM +0200, Hans de Goede wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Here is a patch series for adding support for the electronic privacy screen
>>>>>> on/off events send on e.g. Dell Latitude 7300 models.
>>>>>>
>>>>>> On these laptops the firmware does not allow querying the presence nor
>>>>>> the status of the eprivacy screen at boot. This makes it impossible to
>>>>>> implement the drm connector eprivacy properties API (1) since drm objects
>>>>>> do not allow adding new properties after creation and the presence of
>>>>>> the eprivacy cannot be detected at boot.
>>>>>>
>>>>>> So instead this series adds 2 evdev keycodes for eprivacy screen on + off
>>>>>> and modifies the dell-wmi driver to use these, so that we can still
>>>>>> propagate these events to userspace for e.g. a DE to show an OSD.
>>>>>>
>>>>>> Dmitry, can we get your ack for the addition of the 2 new keycodes?
>>>>>> I think it will be easiest if Ilpo merges the entire series through
>>>>>> the pdx86 tree with your ack for the keycodes.
>>>>>
>>>>> Yes, that should be fine, although I wonder if this is best modeled as a
>>>>> pair of keys or a single switch? I know we have touchpad on/off but I
>>>>> wonder if it was the best option... Probably more convenient at some
>>>>> point if it was done through the atkbd.
>>>>
>>>> EV_SW has the same problem as the drm property API. The mere presence
>>>> of advertising a new SW_PRIVACY_SCREEN capability on an /dev/input/event#
>>>> node would convey to userspace that there is an eprivacy-screen and we
>>>> also would need to know the initial state (on/off) for using an EV_SW
>>>> for this and we know neither presence nor status before hand (1).
>>>
>>> How is this different form presence of KEY_PRIVACY_SCREEN_ON/OFF? They
>>> also imply that there is a privacy screen.
>>
>> I've never seen userspace change behavior depending on which keycodes
>> are advertised as possibly being send by a device.
> 
> On Chrome OS we are trying to go by what peripherals report, but I can
> see that it might not work for a generic Linux distro.
> 
>>
>> Typically userspace does not care of the initial state of keys (it
>> assumes they all start unpressed), where as for switches the initial
>> state matters and we cannot query the initial state here.
>>
>>> If we really do not know if there is functionality present or not maybe
>>> you can register a 2nd input device for the privacy switch upon
>>> receiving the first event for it?
>>
>> Yes that is one of the hacks which we use for SW_TABLET_MODE, but
>> I do really see this as a hack and I would like to avoid this if
>> possible.
>>
>>>> The real issue is that the firmware does not tell us if there is
>>>> an eprivacy screen. As mentioned the first time we find out is when
>>>> the eprivacy screen gets toggled on or off.
>>>>
>>>> We are having similar issues with SW_TABLET_MODE which userspace
>>>> uses to e.g. show / not show an on screen keyboard when a text
>>>> entry field is focussed. So the mere presence of SW_TABLET_MODE
>>>> can influence userspace without ever sending any events and we
>>>> have all kind of special handling in various foo-laptop and
>>>> intel-vbtn, etc. drivers for this, which I would like to avoid
>>>> here.
>>>
>>> Probably have a similar solution: delay registration of corresponding
>>> input device until you know the existence/state?
>>
>> Right that is already done in some cases. What complicates things
>> wrt SW_TABLET_MODE is that we would like to have it present as soon
>> as the driver probes so that a 2-in-1 which is booted in tablet mode
>> behaves correctly from the start. Most of the firmware APIs for
>> SW_TABLET_MODE support getting the initial state, but their implementation
>> can be unreliable. So we only fallback to the delayed registration
>> for known unreliable models, which requires quirks...
>>
>> This is getting a bit offtopic but it does show why I'm not in
>> favor of using EV_SW style input-devices when there is no reliable
>> initial state.
>>
>>>> So having ON / OFF EV_KEY events which we only generate when
>>>> there is an actual eprivacy on/off event are by far the most KISS
>>>> and fool proof solution.
>>>
>>> This assumes you assign special meaning to it (i.e. pretend that it is
>>> not really there until you see events).
>>
>> As I see it there are 2 cases:
>>
>> 1. We can query the presence and status of the eprivacy screen at
>> boot, this would map nicely to a SW_EPRIVACY_SCREEN, but we already
>> have the drm properties API for this and this was put in DRM because
>> this ties the privacy screen to a specific output which is useful
>> to know.
>>
>> 2. The first thing we findout / hear about an eprivacy screen is
>> a eprivacy on/off hotkey press. Notice the "hotkey" there iow
>> this event gets send as the result of a key-press event.
>>
>> For 2. I think that just modelling this as the key events which
>> these also happen to actually be is much simpler then dynamically
>> registering a second input device on the first such a key press
>>
>> and I also think that the userspace side will be simpler with
>> just key-press events rather then having to deal with the dynamic
>> second device registration + reading an EV_SW .
> 
> OK, I agree that if you have a reliable way of querying the state you
> can simply go with the DRM properties solution.
> 
> Since this keys are in effect notification only, not something that
> userspace needs to actively handle, I don't suppose you can add another
> state to the DRM privacy-screen hw-state: "unknown" and update it when  
> the state becomes known?

That would break existing userspace consumers of the API and this is
not just about not being able to query the initial state it is also
about not being able to query if there the eprivacy screen option is
installed at all. The presence of the drm-properties currently lets
to userspace that there is an eprivacy screen present and e.g. will
make gnome-control-center show a toggle to turn it on/off IIRC.

Regards,

Hans

Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[Dmitry Torokhov]

On Thu, Oct 23, 2025 at 03:42:04PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 22-Oct-25 10:24 PM, Dmitry Torokhov wrote:
> > On Wed, Oct 22, 2025 at 09:15:35PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 22-Oct-25 8:40 PM, Dmitry Torokhov wrote:
> >>> On Wed, Oct 22, 2025 at 08:24:46PM +0200, Hans de Goede wrote:
> >>>> Hi Dmitry,
> >>>>
> >>>> On 22-Oct-25 7:54 PM, Dmitry Torokhov wrote:
> >>>>> Hi Hans,
> >>>>>
> >>>>> On Mon, Oct 20, 2025 at 05:23:29PM +0200, Hans de Goede wrote:
> >>>>>> Hi All,
> >>>>>>
> >>>>>> Here is a patch series for adding support for the electronic privacy screen
> >>>>>> on/off events send on e.g. Dell Latitude 7300 models.
> >>>>>>
> >>>>>> On these laptops the firmware does not allow querying the presence nor
> >>>>>> the status of the eprivacy screen at boot. This makes it impossible to
> >>>>>> implement the drm connector eprivacy properties API (1) since drm objects
> >>>>>> do not allow adding new properties after creation and the presence of
> >>>>>> the eprivacy cannot be detected at boot.
> >>>>>>
> >>>>>> So instead this series adds 2 evdev keycodes for eprivacy screen on + off
> >>>>>> and modifies the dell-wmi driver to use these, so that we can still
> >>>>>> propagate these events to userspace for e.g. a DE to show an OSD.
> >>>>>>
> >>>>>> Dmitry, can we get your ack for the addition of the 2 new keycodes?
> >>>>>> I think it will be easiest if Ilpo merges the entire series through
> >>>>>> the pdx86 tree with your ack for the keycodes.
> >>>>>
> >>>>> Yes, that should be fine, although I wonder if this is best modeled as a
> >>>>> pair of keys or a single switch? I know we have touchpad on/off but I
> >>>>> wonder if it was the best option... Probably more convenient at some
> >>>>> point if it was done through the atkbd.
> >>>>
> >>>> EV_SW has the same problem as the drm property API. The mere presence
> >>>> of advertising a new SW_PRIVACY_SCREEN capability on an /dev/input/event#
> >>>> node would convey to userspace that there is an eprivacy-screen and we
> >>>> also would need to know the initial state (on/off) for using an EV_SW
> >>>> for this and we know neither presence nor status before hand (1).
> >>>
> >>> How is this different form presence of KEY_PRIVACY_SCREEN_ON/OFF? They
> >>> also imply that there is a privacy screen.
> >>
> >> I've never seen userspace change behavior depending on which keycodes
> >> are advertised as possibly being send by a device.
> > 
> > On Chrome OS we are trying to go by what peripherals report, but I can
> > see that it might not work for a generic Linux distro.
> > 
> >>
> >> Typically userspace does not care of the initial state of keys (it
> >> assumes they all start unpressed), where as for switches the initial
> >> state matters and we cannot query the initial state here.
> >>
> >>> If we really do not know if there is functionality present or not maybe
> >>> you can register a 2nd input device for the privacy switch upon
> >>> receiving the first event for it?
> >>
> >> Yes that is one of the hacks which we use for SW_TABLET_MODE, but
> >> I do really see this as a hack and I would like to avoid this if
> >> possible.
> >>
> >>>> The real issue is that the firmware does not tell us if there is
> >>>> an eprivacy screen. As mentioned the first time we find out is when
> >>>> the eprivacy screen gets toggled on or off.
> >>>>
> >>>> We are having similar issues with SW_TABLET_MODE which userspace
> >>>> uses to e.g. show / not show an on screen keyboard when a text
> >>>> entry field is focussed. So the mere presence of SW_TABLET_MODE
> >>>> can influence userspace without ever sending any events and we
> >>>> have all kind of special handling in various foo-laptop and
> >>>> intel-vbtn, etc. drivers for this, which I would like to avoid
> >>>> here.
> >>>
> >>> Probably have a similar solution: delay registration of corresponding
> >>> input device until you know the existence/state?
> >>
> >> Right that is already done in some cases. What complicates things
> >> wrt SW_TABLET_MODE is that we would like to have it present as soon
> >> as the driver probes so that a 2-in-1 which is booted in tablet mode
> >> behaves correctly from the start. Most of the firmware APIs for
> >> SW_TABLET_MODE support getting the initial state, but their implementation
> >> can be unreliable. So we only fallback to the delayed registration
> >> for known unreliable models, which requires quirks...
> >>
> >> This is getting a bit offtopic but it does show why I'm not in
> >> favor of using EV_SW style input-devices when there is no reliable
> >> initial state.
> >>
> >>>> So having ON / OFF EV_KEY events which we only generate when
> >>>> there is an actual eprivacy on/off event are by far the most KISS
> >>>> and fool proof solution.
> >>>
> >>> This assumes you assign special meaning to it (i.e. pretend that it is
> >>> not really there until you see events).
> >>
> >> As I see it there are 2 cases:
> >>
> >> 1. We can query the presence and status of the eprivacy screen at
> >> boot, this would map nicely to a SW_EPRIVACY_SCREEN, but we already
> >> have the drm properties API for this and this was put in DRM because
> >> this ties the privacy screen to a specific output which is useful
> >> to know.
> >>
> >> 2. The first thing we findout / hear about an eprivacy screen is
> >> a eprivacy on/off hotkey press. Notice the "hotkey" there iow
> >> this event gets send as the result of a key-press event.
> >>
> >> For 2. I think that just modelling this as the key events which
> >> these also happen to actually be is much simpler then dynamically
> >> registering a second input device on the first such a key press
> >>
> >> and I also think that the userspace side will be simpler with
> >> just key-press events rather then having to deal with the dynamic
> >> second device registration + reading an EV_SW .
> > 
> > OK, I agree that if you have a reliable way of querying the state you
> > can simply go with the DRM properties solution.
> > 
> > Since this keys are in effect notification only, not something that
> > userspace needs to actively handle, I don't suppose you can add another
> > state to the DRM privacy-screen hw-state: "unknown" and update it when  
> > the state becomes known?
> 
> That would break existing userspace consumers of the API and this is
> not just about not being able to query the initial state it is also
> about not being able to query if there the eprivacy screen option is
> installed at all. The presence of the drm-properties currently lets
> to userspace that there is an eprivacy screen present and e.g. will
> make gnome-control-center show a toggle to turn it on/off IIRC.

OK, fair enough. Let's merge it. I just acked the patch adding the new
keycodes, feel free to merge through the platform tree.

Thanks.

-- 
Dmitry

Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[Ilpo Järvinen]

On Mon, 20 Oct 2025 17:23:29 +0200, Hans de Goede wrote:

> Here is a patch series for adding support for the electronic privacy screen
> on/off events send on e.g. Dell Latitude 7300 models.
> 
> On these laptops the firmware does not allow querying the presence nor
> the status of the eprivacy screen at boot. This makes it impossible to
> implement the drm connector eprivacy properties API (1) since drm objects
> do not allow adding new properties after creation and the presence of
> the eprivacy cannot be detected at boot.
> 
> [...]


Thank you for your contribution, it has been applied to my local
review-ilpo-fixes branch. Note it will show up in the public
platform-drivers-x86/review-ilpo-fixes branch only once I've pushed my
local branch there, which might take a while.

The list of commits applied:
[1/2] Input: Add keycodes for electronic privacy screen on/off hotkeys
      commit: 8f3eaad9812f62e7006ad08602444b32c3101824
[2/2] platform/x86: dell-wmi-base: Handle electronic privacy screen on/off events
      commit: 4173edb076b3ae30d734d55fce0ebac63139b656

--
 i.