Re: [PATCH v2] Input: add 'safe' user switch codes

Hi Jeff, Kieran,

On Fri, Nov 05, 2021 at 12:00:37PM -0500, Jeff LaBundy wrote:

Hi Kieran,

On Fri, Nov 05, 2021 at 10:35:07AM +0000, Kieran Bingham wrote:

quoted

All existing SW input codes define an action which can be interpreted by
a user environment to adapt to the condition of the switch.

For example, switches to define the audio mute, will prevent audio
playback, and switches to indicate lid and covers being closed may
disable displays.

Many evaluation platforms provide switches which can be connected to the
input system but associating these to an action incorrectly could
provide inconsistent end user experiences due to unmarked switch
positions.

Define two custom user defined switches allowing hardware descriptions
to be created whereby the position of the switch is not interpreted as
any standard condition that will affect a user experience.

This allows wiring up custom generic switches in a way that will allow
them to be read and processed, without incurring undesired or otherwise
undocumented (by the hardware) 'default' behaviours.

Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
---

Sigh, a compile test might have at least saved the buildbots the trouble
of notifying me I also need to update the INPUT_DEVICE_ID_SW_MAX. But
even so - I'm really looking for a discussion on the best ways to
describe a non-defined switch in device tree.

Here's a compiling v2 ;-) But the real questions are :

 - Should an existing feature switch be used for generic switches?
 - Should we even have a 'user' defined switch?
 - If we add user switches, how many?

This is merely my opinion, but if a hardware switch does not have a defined
purpose, it does not seem necessary to represent it with an input device.

Yes, exactly. For input core we are trying to avoid generic events with
no defined meaning.

What are these switches? GPIOs? Maybe it would be better to use GPIO
layer to test the state for them?

Thanks.

-- 
Dmitry