[1/3] input: add event codes for user programmable switch events

Add SW_PROG{1,2,3,4} for device switches which are handled by userspace.

This can be used for devices with "generic" switches which are intended
to be user-programmable, for example OnePlus phones contain a tri-state
key which can be used for switching between mute/vibrate/ring, or
programmed by the user to perform any arbitrary actions.

These are analogous to the keys KEY_PROG{1,2,3,4} found on some
keyboards.

Signed-off-by: Caleb Connolly <caleb@connolly.tech>
---
See the next patch in this series for an example usecase.
---
 include/linux/mod_devicetable.h        | 2 +-
 include/uapi/linux/input-event-codes.h | 6 +++++-
 2 files changed, 6 insertions(+), 2 deletions(-)

--
2.36.1

On Mon 16 May 09:22 CDT 2022, Caleb Connolly wrote:

> Add SW_PROG{1,2,3,4} for device switches which are handled by userspace.
> 
> This can be used for devices with "generic" switches which are intended
> to be user-programmable, for example OnePlus phones contain a tri-state
> key which can be used for switching between mute/vibrate/ring, or
> programmed by the user to perform any arbitrary actions.
> 
> These are analogous to the keys KEY_PROG{1,2,3,4} found on some
> keyboards.
> 
> Signed-off-by: Caleb Connolly <caleb@connolly.tech>

This looks reasonable to me.

Dmitry, what do you think?

Regards,
Bjorn

> ---
> See the next patch in this series for an example usecase.
> ---
>  include/linux/mod_devicetable.h        | 2 +-
>  include/uapi/linux/input-event-codes.h | 6 +++++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 5da5d990ff58..45364fbeaaf7 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		0x14
>  #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 dff8e7f17074..339153886a13 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -917,7 +917,11 @@
>  #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_PROG1		0x11  /* set = program 1 (user defined) */
> +#define SW_PROG2		0x12  /* set = program 2 (user defined) */
> +#define SW_PROG3		0x13  /* set = program 3 (user defined) */
> +#define SW_PROG4		0x14  /* set = program 4 (user defined) */
> +#define SW_MAX			0x14
>  #define SW_CNT			(SW_MAX+1)
> 
>  /*
> --
> 2.36.1
> 
>

On 01/07/2022 00:11, Bjorn Andersson wrote:
> On Mon 16 May 09:22 CDT 2022, Caleb Connolly wrote:
>
>> Add SW_PROG{1,2,3,4} for device switches which are handled by userspace.
>>
>> This can be used for devices with "generic" switches which are intended
>> to be user-programmable, for example OnePlus phones contain a tri-state
>> key which can be used for switching between mute/vibrate/ring, or
>> programmed by the user to perform any arbitrary actions.
>>
>> These are analogous to the keys KEY_PROG{1,2,3,4} found on some
>> keyboards.
>>
>> Signed-off-by: Caleb Connolly <caleb@connolly.tech>
>
> This looks reasonable to me.
>
> Dmitry, what do you think?
Any chance someone could take a look at this? (Sorry I really should have bumped
this a few weeks ago).
>
> Regards,
> Bjorn
>
>> ---
>> See the next patch in this series for an example usecase.
>> ---
>>   include/linux/mod_devicetable.h        | 2 +-
>>   include/uapi/linux/input-event-codes.h | 6 +++++-
>>   2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
>> index 5da5d990ff58..45364fbeaaf7 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		0x14
>>   #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 dff8e7f17074..339153886a13 100644
>> --- a/include/uapi/linux/input-event-codes.h
>> +++ b/include/uapi/linux/input-event-codes.h
>> @@ -917,7 +917,11 @@
>>   #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_PROG1		0x11  /* set = program 1 (user defined) */
>> +#define SW_PROG2		0x12  /* set = program 2 (user defined) */
>> +#define SW_PROG3		0x13  /* set = program 3 (user defined) */
>> +#define SW_PROG4		0x14  /* set = program 4 (user defined) */
>> +#define SW_MAX			0x14
>>   #define SW_CNT			(SW_MAX+1)
>>
>>   /*
>> --
>> 2.36.1
>>
>>

--
Kind Regards,
Caleb

Hi Caleb,

On Mon, May 16, 2022 at 02:22:57PM +0000, Caleb Connolly wrote:
> Add SW_PROG{1,2,3,4} for device switches which are handled by userspace.
> 
> This can be used for devices with "generic" switches which are intended
> to be user-programmable, for example OnePlus phones contain a tri-state
> key which can be used for switching between mute/vibrate/ring, or
> programmed by the user to perform any arbitrary actions.
> 
> These are analogous to the keys KEY_PROG{1,2,3,4} found on some
> keyboards.

This has been proposed a few times but this goes against the spirit of
the input subsystem where each key or switch has a defined [default]
purpose and userspace is normally expected to act upon input events
without paying attention to what device they actually are coming from.
IOW if you want to deal with particular GPIO signals you are better off
using GPIO subsystem.

In this context adding KEY_PROG1-4 was actually a mistake and we should
try not extend it further.

As fas as modeling the sliders with multiple settings goes I'd look into
ABS events, probably ABS_MISC, with a set of values.

Thanks.

On 10/08/2022 23:33, Dmitry Torokhov wrote:
> Hi Caleb,
>
> On Mon, May 16, 2022 at 02:22:57PM +0000, Caleb Connolly wrote:
>> Add SW_PROG{1,2,3,4} for device switches which are handled by userspace.
>>
>> This can be used for devices with "generic" switches which are intended
>> to be user-programmable, for example OnePlus phones contain a tri-state
>> key which can be used for switching between mute/vibrate/ring, or
>> programmed by the user to perform any arbitrary actions.
>>
>> These are analogous to the keys KEY_PROG{1,2,3,4} found on some
>> keyboards.

Hi Dmitry,
>
> This has been proposed a few times but this goes against the spirit of
> the input subsystem where each key or switch has a defined [default]
> purpose and userspace is normally expected to act upon input events
> without paying attention to what device they actually are coming from.
> IOW if you want to deal with particular GPIO signals you are better off
> using GPIO subsystem.
>
> In this context adding KEY_PROG1-4 was actually a mistake and we should
> try not extend it further.
>
> As fas as modeling the sliders with multiple settings goes I'd look into
> ABS events, probably ABS_MISC, with a set of values.

Ah I wasn't aware of ABS_MISC, this looks like a good way to go. Thanks.

>
> Thanks.
>
> --
> Dmitry

--
Kind Regards,
Caleb