Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c2d0c706-e006-6c2f-8fe6-ea20a745ddd6@redhat.com>
Date:   Wed, 26 Apr 2023 10:59:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: Function of the camera key on windows
To:     Jonathan Singer <jes965@nyu.edu>,
        platform-driver-x86@vger.kernel.org
Cc:     linux-kernel@vger.kernel.org
References: <MN0PR12MB6101D9688E7904FF52634520E2649@MN0PR12MB6101.namprd12.prod.outlook.com>
 <20230425210953.14597-1-jes965@nyu.edu>
Content-Language: en-US, nl
From:   Hans de Goede <hdegoede@redhat.com>
In-Reply-To: <20230425210953.14597-1-jes965@nyu.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,

On 4/25/23 23:09, Jonathan Singer wrote:
> The key itself triggers a hardware response both on windows and linux.
> It disconnects power from the camera USB module and raises a cover in front
> of the camera aperature. The keycode is as far as I know only to notify the
> operating system in case it wanted to show a message.
> 
> Is that the kind of use case that would benefit from emitting a KEY_CAMERA?

Actually we have SW_CAMERA_LENS_COVER for this and this is what
new Dell laptops with a similar feature use.

The problem with using a SW for this though is that we should then either:

a) Figure out a way to identify models which will report this; or
b) register a separate input_dev just for reporting the SW
   on the first event.

This is necessary because unlike keys where only press + release
events really matter and if those never happens no harm is done,
switches can be acted upon by userspace in both there open and closed
state, so the mere presence of an input_device with a SW_CAMERA_LENS_COVER
may be acted upon by userspace. E.g. if we by default report
SW_CAMERA_LENS_COVER=1 (so lenscover closed) then apps who want to access
the camera may ask the user something like: "Your camera is currently
unavailable, please press the keyboard combination to enable your camera"
which makes no sense to ask on devices without such feature.

Note that simply registering a separate input_dev for just reporting
SW_CAMERA_LENS_COVER on the first event is a good workaround for
this though. We already do the same in other drivers for SW_TABLET_MODE
for similar reasons.

A second problem is that we would need to be able to tell if we
get the 0x1A event because of the camera being enabled or disabled,
but perhaps this info is already present in the event_data ?

Regards,

Hans