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

[Hans de Goede <hansg@kernel.org>]

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