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@xxxxxxxxxxxxxxxx>
> ---
>
> 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
