[PATCH 0/2] Make gpio-keys usable as a hat

[PATCH 0/2] Make gpio-keys usable as a hat

[Paul Cercueil]

Hi,

With this set of two commits, it is now possible to use the
gpio-keys driver with 4 GPIOs representing a hat (D-pad).

[PATCH 1/2] Input: gpio_keys - Also send release events for ABS codes

[Paul Cercueil]

Right now, the gpio-keys driver is mostly used with EV_KEY event types.
However, this driver (and its devicetree bindings) support specifying
a different input type, like EV_ABS, even though this doesn't work in
practice: "key pressed" events are correctly received and treated, but
"key released" are silently ignored.

With this commit, keys configured as EV_ABS will inject an event with
the value 0 when released.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
 drivers/input/keyboard/gpio_keys.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 2909365..7018c49 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -369,6 +369,8 @@ static void gpio_keys_gpio_report_event(struct gpio_button_data *bdata)
 	if (type == EV_ABS) {
 		if (state)
 			input_event(input, type, button->code, button->value);
+		else
+			input_event(input, type, button->code, 0);
 	} else {
 		input_event(input, type, button->code, !!state);
 	}
-- 
2.9.3

Re: [PATCH 1/2] Input: gpio_keys - Also send release events for ABS codes

[Dmitry Torokhov]

On Tue, Nov 01, 2016 at 11:25:03AM +0100, Paul Cercueil wrote:
> Right now, the gpio-keys driver is mostly used with EV_KEY event types.
> However, this driver (and its devicetree bindings) support specifying
> a different input type, like EV_ABS, even though this doesn't work in
> practice: "key pressed" events are correctly received and treated, but
> "key released" are silently ignored.
> 
> With this commit, keys configured as EV_ABS will inject an event with
> the value 0 when released.

No, this will break setups like this:

gpio0 - ABS_X - 0
gpio1 - ABS_X - 1
gpio2 - ABS_X - 2
...
gpio7 - ABS_X - 7

- something like a slider built on top of gpios.

> 
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>  drivers/input/keyboard/gpio_keys.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> index 2909365..7018c49 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -369,6 +369,8 @@ static void gpio_keys_gpio_report_event(struct gpio_button_data *bdata)
>  	if (type == EV_ABS) {
>  		if (state)
>  			input_event(input, type, button->code, button->value);
> +		else
> +			input_event(input, type, button->code, 0);
>  	} else {
>  		input_event(input, type, button->code, !!state);
>  	}
> -- 
> 2.9.3
> 

Thanks.

-- 
Dmitry

Re: [PATCH 1/2] Input: gpio_keys - Also send release events for ABS codes

[Paul Cercueil]

On 03/11/2016 17:21, Dmitry Torokhov wrote:
> On Tue, Nov 01, 2016 at 11:25:03AM +0100, Paul Cercueil wrote:
>> Right now, the gpio-keys driver is mostly used with EV_KEY event types.
>> However, this driver (and its devicetree bindings) support specifying
>> a different input type, like EV_ABS, even though this doesn't work in
>> practice: "key pressed" events are correctly received and treated, but
>> "key released" are silently ignored.
>>
>> With this commit, keys configured as EV_ABS will inject an event with
>> the value 0 when released.
> No, this will break setups like this:
>
> gpio0 - ABS_X - 0
> gpio1 - ABS_X - 1
> gpio2 - ABS_X - 2
> ...
> gpio7 - ABS_X - 7
>
> - something like a slider built on top of gpios.

So what would you suggest for the implementation of a hat / d-pad on top 
of GPIOs?

Thanks,
- Paul

Re: [PATCH 1/2] Input: gpio_keys - Also send release events for ABS codes

[Dmitry Torokhov]

On Sat, Nov 05, 2016 at 12:58:00PM +0100, Paul Cercueil wrote:
> On 03/11/2016 17:21, Dmitry Torokhov wrote:
> >On Tue, Nov 01, 2016 at 11:25:03AM +0100, Paul Cercueil wrote:
> >>Right now, the gpio-keys driver is mostly used with EV_KEY event types.
> >>However, this driver (and its devicetree bindings) support specifying
> >>a different input type, like EV_ABS, even though this doesn't work in
> >>practice: "key pressed" events are correctly received and treated, but
> >>"key released" are silently ignored.
> >>
> >>With this commit, keys configured as EV_ABS will inject an event with
> >>the value 0 when released.
> >No, this will break setups like this:
> >
> >gpio0 - ABS_X - 0
> >gpio1 - ABS_X - 1
> >gpio2 - ABS_X - 2
> >...
> >gpio7 - ABS_X - 7
> >
> >- something like a slider built on top of gpios.
> 
> So what would you suggest for the implementation of a hat / d-pad on
> top of GPIOs?

Maybe we should allow specifying "release" value for ABS GPIOs.

Thanks.

-- 
Dmitry

[PATCH 2/2] Input: gpio_keys - Set ABS params when using axes

[Paul Cercueil]

The gpio-keys supports the EV_ABS event type, but does not actually
configure the input device to work with that mode.

This patch configures the axis corresponding to button->code as being
in the range [-1,+1]. This makes it possible to use gpio-keys to
implement a hat (using the ABS_HAT0X /ABS_HAT0Y axes, with two GPIOs
each with values -1/+1).

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
 drivers/input/keyboard/gpio_keys.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 7018c49..1f2850a 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -540,6 +540,9 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
 
 	input_set_capability(input, button->type ?: EV_KEY, button->code);
 
+	if (button->type == EV_ABS)
+		input_set_abs_params(input, button->code, -1, 1, 0, 0);
+
 	/*
 	 * Install custom action to cancel release timer and
 	 * workqueue item.
-- 
2.9.3

Re: [PATCH 2/2] Input: gpio_keys - Set ABS params when using axes

[Dmitry Torokhov]

On Tue, Nov 01, 2016 at 11:25:04AM +0100, Paul Cercueil wrote:
> The gpio-keys supports the EV_ABS event type, but does not actually
> configure the input device to work with that mode.
> 
> This patch configures the axis corresponding to button->code as being
> in the range [-1,+1]. This makes it possible to use gpio-keys to
> implement a hat (using the ABS_HAT0X /ABS_HAT0Y axes, with two GPIOs
> each with values -1/+1).

What if I am emitting values of 10?

Also, reporting limits on axis is not a requirement, it is simply a
hint. If your userspace refuses axis with unrefined (aka 0) min and max
you need to fix it.

> 
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>  drivers/input/keyboard/gpio_keys.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> index 7018c49..1f2850a 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -540,6 +540,9 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
>  
>  	input_set_capability(input, button->type ?: EV_KEY, button->code);
>  
> +	if (button->type == EV_ABS)
> +		input_set_abs_params(input, button->code, -1, 1, 0, 0);
> +
>  	/*
>  	 * Install custom action to cancel release timer and
>  	 * workqueue item.
> -- 
> 2.9.3
> 

Thanks.

-- 
Dmitry