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 <[email protected]>
---
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
The tri-state-key is a 3-state mute slider found on the OnePlus 6.
The default software maps the states to "mute", "vibrate" and "ring",
expose them as generic switch events so that they can be configured
by userspace.
Signed-off-by: Caleb Connolly <[email protected]>
---
.../boot/dts/qcom/sdm845-oneplus-common.dtsi | 44 +++++++++++++++++--
1 file changed, 40 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
index 07b729f9fec5..f134c51e17ec 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
@@ -7,7 +7,7 @@
/dts-v1/;
-#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sdm845.dtsi"
@@ -26,7 +26,7 @@ chosen {
stdout-path = "serial0:115200n8";
};
- gpio-keys {
+ volume-keys {
compatible = "gpio-keys";
label = "Volume keys";
autorepeat;
@@ -49,6 +49,41 @@ vol-up {
};
};
+ tri-state-key {
+ compatible = "gpio-keys";
+ label = "Tri-state key";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tri_state_key_default>;
+
+ state-top {
+ label = "Tri-state key top";
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_PROG1>;
+ gpios = <&tlmm 126 GPIO_ACTIVE_LOW>;
+ debounce-interval = <50>;
+ linux,can-disable;
+ };
+
+ state-middle {
+ label = "Tri-state key middle";
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_PROG2>;
+ gpios = <&tlmm 52 GPIO_ACTIVE_LOW>;
+ debounce-interval = <50>;
+ linux,can-disable;
+ };
+
+ state-bottom {
+ label = "Tri-state key bottom";
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_PROG3>;
+ gpios = <&tlmm 24 GPIO_ACTIVE_LOW>;
+ debounce-interval = <50>;
+ linux,can-disable;
+ };
+ };
+
reserved-memory {
/* The rmtfs_mem needs to be guarded due to "XPU limitations"
* it is otherwise possible for an allocation adjacent to the
@@ -607,9 +642,10 @@ &usb_1_hsphy {
&tlmm {
gpio-reserved-ranges = <0 4>, <81 4>;
- tri_state_key_default: tri_state_key_default {
+ /* The GPIOs have a hardware pullup */
+ tri_state_key_default: tri-state-pins {
mux {
- pins = "gpio40", "gpio42", "gpio26";
+ pins = "gpio126", "gpio52", "gpio24";
function = "gpio";
drive-strength = <2>;
bias-disable;
--
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 <[email protected]>
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 <[email protected]>
>
> 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.
--
Dmitry
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