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

[Jeff LaBundy <jeff@labundy.com>]

Hi Kieran,

On Fri, Nov 05, 2021 at 10:35:07AM +0000, Kieran Bingham wrote:
> 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.

If the goal is to simply perform validation of a driver and/or hardware, is
it not sufficient to map the switch to an existing code?

Similarly, there is no way to know if two are enough. What if we have a new
board tomorrow and need four?

> 
>  include/linux/mod_devicetable.h        | 2 +-
>  include/uapi/linux/input-event-codes.h | 4 +++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index ae2e75d15b21..dfa1e4f41cd8 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -326,7 +326,7 @@ struct pcmcia_device_id {
>  #define INPUT_DEVICE_ID_LED_MAX		0x0f
>  #define INPUT_DEVICE_ID_SND_MAX		0x07
>  #define INPUT_DEVICE_ID_FF_MAX		0x7f
> -#define INPUT_DEVICE_ID_SW_MAX		0x10
> +#define INPUT_DEVICE_ID_SW_MAX		0x12
>  #define INPUT_DEVICE_ID_PROP_MAX	0x1f
>  
>  #define INPUT_DEVICE_ID_MATCH_BUS	1
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 225ec87d4f22..84a7b3debcb3 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -894,7 +894,9 @@
>  #define SW_MUTE_DEVICE		0x0e  /* set = device disabled */
>  #define SW_PEN_INSERTED		0x0f  /* set = pen inserted */
>  #define SW_MACHINE_COVER	0x10  /* set = cover closed */
> -#define SW_MAX			0x10
> +#define SW_1			0x11  /* set = user defined */
> +#define SW_2			0x12  /* set = user defined */
> +#define SW_MAX			0x12
>  #define SW_CNT			(SW_MAX+1)
>  
>  /*
> -- 
> 2.30.2
> 

Kind regards,
Jeff LaBundy