[PATCH] Input: gamepad - use independent axes for analog D-Pad buttons

[PATCH] Input: gamepad - use independent axes for analog D-Pad buttons

[Antonio Ospite]

Model this part of the API after the Sony PlayStation 3 Controller which
exposes independent analog values for each one of the D-Pad buttons.

The PS3 programming API psl1ght also maps the analog D-Pad buttons
individually.

Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
---

Hi,

as David mentioned no gamepad defines analog D-Pad buttons as mentioned in the
gamepad API, so the API change should be OK.

And is it OK too to fill the holes in the ABS space or should I just use
higher codes?

Thanks,
   Antonio

 Documentation/input/gamepad.txt       | 4 ++--
 drivers/staging/et131x/Module.symvers | 0
 include/uapi/linux/input.h            | 5 +++++
 3 files changed, 7 insertions(+), 2 deletions(-)
 delete mode 100644 drivers/staging/et131x/Module.symvers

diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt
index ed13782..aab000d 100644
--- a/Documentation/input/gamepad.txt
+++ b/Documentation/input/gamepad.txt
@@ -124,8 +124,8 @@ D-Pad:
     Digital buttons are reported as:
       BTN_DPAD_*
     Analog buttons are reported as:
-      ABS_HAT0X and ABS_HAT0Y
-      (for ABS values negative is left/up, positive is right/down)
+      ABS_DPAD_*
+      (ABS values start at 0, pressure is reported as positive values)
 
 Analog-Sticks:
   The left analog-stick is reported as ABS_X, ABS_Y. The right analog stick is
diff --git a/drivers/staging/et131x/Module.symvers b/drivers/staging/et131x/Module.symvers
deleted file mode 100644
index e69de29..0000000
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index d3fcbff..dcc73c0 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -842,6 +842,11 @@ struct input_keymap_entry {
 
 #define ABS_VOLUME		0x20
 
+#define ABS_DPAD_UP		0x21	/* Analog D-Pad Up for gamepads */
+#define ABS_DPAD_DOWN		0x22	/* Analog D-Pad Down for gamepads */
+#define ABS_DPAD_LEFT		0x23	/* Analog D-Pad Left for gamepads */
+#define ABS_DPAD_RIGHT		0x24	/* Analog D-Pad Right for gamepads */
+
 #define ABS_MISC		0x28
 
 #define ABS_MT_SLOT		0x2f	/* MT slot being modified */
-- 
1.8.5.2

Re: [PATCH] Input: gamepad - use independent axes for analog D-Pad buttons

[David Herrmann]

Hi

On Mon, Dec 23, 2013 at 5:17 PM, Antonio Ospite
<ospite@studenti.unina.it> wrote:
> Model this part of the API after the Sony PlayStation 3 Controller which
> exposes independent analog values for each one of the D-Pad buttons.
>
> The PS3 programming API psl1ght also maps the analog D-Pad buttons
> individually.
>
> Cc: David Herrmann <dh.herrmann@gmail.com>
> Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
> ---
>
> Hi,
>
> as David mentioned no gamepad defines analog D-Pad buttons as mentioned in the
> gamepad API, so the API change should be OK.
>
> And is it OK too to fill the holes in the ABS space or should I just use
> higher codes?

You might wanna try searching git-history, but apart from ABS_MISC to
ABS_MT_* I think all other spaces can be filled.
Patch is fine with me, but I'd also be ok with the ABS_DPAD_HORIZ/VERT pair.

Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

Thanks
David

> Thanks,
>    Antonio
>
>  Documentation/input/gamepad.txt       | 4 ++--
>  drivers/staging/et131x/Module.symvers | 0
>  include/uapi/linux/input.h            | 5 +++++
>  3 files changed, 7 insertions(+), 2 deletions(-)
>  delete mode 100644 drivers/staging/et131x/Module.symvers
>
> diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt
> index ed13782..aab000d 100644
> --- a/Documentation/input/gamepad.txt
> +++ b/Documentation/input/gamepad.txt
> @@ -124,8 +124,8 @@ D-Pad:
>      Digital buttons are reported as:
>        BTN_DPAD_*
>      Analog buttons are reported as:
> -      ABS_HAT0X and ABS_HAT0Y
> -      (for ABS values negative is left/up, positive is right/down)
> +      ABS_DPAD_*
> +      (ABS values start at 0, pressure is reported as positive values)
>
>  Analog-Sticks:
>    The left analog-stick is reported as ABS_X, ABS_Y. The right analog stick is
> diff --git a/drivers/staging/et131x/Module.symvers b/drivers/staging/et131x/Module.symvers
> deleted file mode 100644
> index e69de29..0000000
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index d3fcbff..dcc73c0 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -842,6 +842,11 @@ struct input_keymap_entry {
>
>  #define ABS_VOLUME             0x20
>
> +#define ABS_DPAD_UP            0x21    /* Analog D-Pad Up for gamepads */
> +#define ABS_DPAD_DOWN          0x22    /* Analog D-Pad Down for gamepads */
> +#define ABS_DPAD_LEFT          0x23    /* Analog D-Pad Left for gamepads */
> +#define ABS_DPAD_RIGHT         0x24    /* Analog D-Pad Right for gamepads */
> +
>  #define ABS_MISC               0x28
>
>  #define ABS_MT_SLOT            0x2f    /* MT slot being modified */
> --
> 1.8.5.2
>

Re: [PATCH] Input: gamepad - use independent axes for analog D-Pad buttons

[Dmitry Torokhov]

Hi Antonio,

On Mon, Dec 23, 2013 at 05:17:43PM +0100, Antonio Ospite wrote:
> Model this part of the API after the Sony PlayStation 3 Controller which
> exposes independent analog values for each one of the D-Pad buttons.
> 
> The PS3 programming API psl1ght also maps the analog D-Pad buttons
> individually.

Hmm, even though the hardware is capable of producing independent analog
values does are they really useful? Looking at my PS3 controller I do
not think users will be pressing up/down and left/right dpad buttons at
the same time.

I'd rather keep using ABS_HAT0X/Y unless there is really good reason for
introducing new events.

Thanks.

-- 
Dmitry

Re: [PATCH] Input: gamepad - use independent axes for analog D-Pad buttons

[Antonio Ospite]

On Sun, 29 Dec 2013 16:52:09 -0800
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> Hi Antonio,
> 
> On Mon, Dec 23, 2013 at 05:17:43PM +0100, Antonio Ospite wrote:
> > Model this part of the API after the Sony PlayStation 3 Controller which
> > exposes independent analog values for each one of the D-Pad buttons.
> > 
> > The PS3 programming API psl1ght also maps the analog D-Pad buttons
> > individually.
> 
> Hmm, even though the hardware is capable of producing independent analog
> values does are they really useful? Looking at my PS3 controller I do
> not think users will be pressing up/down and left/right dpad buttons at
> the same time.
>

I must agree it's unlikely, while still possible.

> I'd rather keep using ABS_HAT0X/Y unless there is really good reason for
> introducing new events.
> 

Having analog D-Pad values reported independently was proposed for these
reasons:

 - it matches _some_ existing hardware closely (that was the main
   reason TBH, to simplify the drivers);

 - it happens to follow what it's being done for D-Pad digital buttons,
   they are also reported independently.

However if some other hardware reported D-Pad axis combined already
then I agree that using something like ABS_HAT0X/Y is safer, I see
decomposing HORIZ/VERT into the separate LEFT/RIGHT and UP/DOWN to be
less intuitive (not harder tho).

Another doubt: David, in the other email you mentioned we could use
ABS_DPAD_HORIZ/VERT, any particular reason to introduce them in place
of ABS_HAT0X/Y?

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: [PATCH] Input: gamepad - use independent axes for analog D-Pad buttons

[David Herrmann]

Hi

On Mon, Dec 30, 2013 at 12:20 PM, Antonio Ospite
<ospite@studenti.unina.it> wrote:
> On Sun, 29 Dec 2013 16:52:09 -0800
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
>> Hi Antonio,
>>
>> On Mon, Dec 23, 2013 at 05:17:43PM +0100, Antonio Ospite wrote:
>> > Model this part of the API after the Sony PlayStation 3 Controller which
>> > exposes independent analog values for each one of the D-Pad buttons.
>> >
>> > The PS3 programming API psl1ght also maps the analog D-Pad buttons
>> > individually.
>>
>> Hmm, even though the hardware is capable of producing independent analog
>> values does are they really useful? Looking at my PS3 controller I do
>> not think users will be pressing up/down and left/right dpad buttons at
>> the same time.
>>
>
> I must agree it's unlikely, while still possible.
>
>> I'd rather keep using ABS_HAT0X/Y unless there is really good reason for
>> introducing new events.
>>
>
> Having analog D-Pad values reported independently was proposed for these
> reasons:
>
>  - it matches _some_ existing hardware closely (that was the main
>    reason TBH, to simplify the drivers);
>
>  - it happens to follow what it's being done for D-Pad digital buttons,
>    they are also reported independently.
>
> However if some other hardware reported D-Pad axis combined already
> then I agree that using something like ABS_HAT0X/Y is safer, I see
> decomposing HORIZ/VERT into the separate LEFT/RIGHT and UP/DOWN to be
> less intuitive (not harder tho).
>
> Another doubt: David, in the other email you mentioned we could use
> ABS_DPAD_HORIZ/VERT, any particular reason to introduce them in place
> of ABS_HAT0X/Y?

A "HAT" is an axis on the top of a joystick, nothing else. It seems
troublesome to overload the definition (which we did for many years).
Device-detection based on advertised ABS-bits gets pretty hard if we
reuse ABS-bits for different hardware. The most annoying example of
what happens is accelerometers being misdetected by Xorg as
mouse-input because they reuse ABS_X/Y.

Thanks
David

Re: [PATCH] Input: gamepad - use independent axes for analog D-Pad buttons

[Dmitry Torokhov]

On Mon, Dec 30, 2013 at 12:44:21PM +0100, David Herrmann wrote:
> Hi
> 
> On Mon, Dec 30, 2013 at 12:20 PM, Antonio Ospite
> <ospite@studenti.unina.it> wrote:
> > On Sun, 29 Dec 2013 16:52:09 -0800
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >
> >> Hi Antonio,
> >>
> >> On Mon, Dec 23, 2013 at 05:17:43PM +0100, Antonio Ospite wrote:
> >> > Model this part of the API after the Sony PlayStation 3 Controller which
> >> > exposes independent analog values for each one of the D-Pad buttons.
> >> >
> >> > The PS3 programming API psl1ght also maps the analog D-Pad buttons
> >> > individually.
> >>
> >> Hmm, even though the hardware is capable of producing independent analog
> >> values does are they really useful? Looking at my PS3 controller I do
> >> not think users will be pressing up/down and left/right dpad buttons at
> >> the same time.
> >>
> >
> > I must agree it's unlikely, while still possible.
> >
> >> I'd rather keep using ABS_HAT0X/Y unless there is really good reason for
> >> introducing new events.
> >>
> >
> > Having analog D-Pad values reported independently was proposed for these
> > reasons:
> >
> >  - it matches _some_ existing hardware closely (that was the main
> >    reason TBH, to simplify the drivers);
> >
> >  - it happens to follow what it's being done for D-Pad digital buttons,
> >    they are also reported independently.
> >
> > However if some other hardware reported D-Pad axis combined already
> > then I agree that using something like ABS_HAT0X/Y is safer, I see
> > decomposing HORIZ/VERT into the separate LEFT/RIGHT and UP/DOWN to be
> > less intuitive (not harder tho).
> >
> > Another doubt: David, in the other email you mentioned we could use
> > ABS_DPAD_HORIZ/VERT, any particular reason to introduce them in place
> > of ABS_HAT0X/Y?
> 
> A "HAT" is an axis on the top of a joystick, nothing else. It seems
> troublesome to overload the definition (which we did for many years).
> Device-detection based on advertised ABS-bits gets pretty hard if we
> reuse ABS-bits for different hardware. The most annoying example of
> what happens is accelerometers being misdetected by Xorg as
> mouse-input because they reuse ABS_X/Y.

But they are good as joysticks (also ABS_X/ABS_Y). I do not think having
all unique events for all device types is feasible. Can we provide hints
(via properties) to lessen ambiguity, like we do with direct/indirect
pointers for touchscreens/tablets?

Thanks.

-- 
Dmitry

Re: [PATCH] Input: gamepad - use independent axes for analog D-Pad buttons

[Dmitry Torokhov]

On Mon, Dec 30, 2013 at 12:20:20PM +0100, Antonio Ospite wrote:
> On Sun, 29 Dec 2013 16:52:09 -0800
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > Hi Antonio,
> > 
> > On Mon, Dec 23, 2013 at 05:17:43PM +0100, Antonio Ospite wrote:
> > > Model this part of the API after the Sony PlayStation 3 Controller which
> > > exposes independent analog values for each one of the D-Pad buttons.
> > > 
> > > The PS3 programming API psl1ght also maps the analog D-Pad buttons
> > > individually.
> > 
> > Hmm, even though the hardware is capable of producing independent analog
> > values does are they really useful? Looking at my PS3 controller I do
> > not think users will be pressing up/down and left/right dpad buttons at
> > the same time.
> >
> 
> I must agree it's unlikely, while still possible.
> 
> > I'd rather keep using ABS_HAT0X/Y unless there is really good reason for
> > introducing new events.
> > 
> 
> Having analog D-Pad values reported independently was proposed for these
> reasons:
> 
>  - it matches _some_ existing hardware closely (that was the main
>    reason TBH, to simplify the drivers);
> 
>  - it happens to follow what it's being done for D-Pad digital buttons,
>    they are also reported independently.
> 
> However if some other hardware reported D-Pad axis combined already
> then I agree that using something like ABS_HAT0X/Y is safer, I see
> decomposing HORIZ/VERT into the separate LEFT/RIGHT and UP/DOWN to be
> less intuitive (not harder tho).
> 
> Another doubt: David, in the other email you mentioned we could use
> ABS_DPAD_HORIZ/VERT, any particular reason to introduce them in place
> of ABS_HAT0X/Y?

I think xpad driver mapping (while in no way perfect) uses HAT0 for that.

Thanks.

-- 
Dmitry

Re: [PATCH] Input: gamepad - use independent axes for analog D-Pad buttons

[David Herrmann]

Hi Dmitry

On Mon, Dec 30, 2013 at 7:50 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Mon, Dec 30, 2013 at 12:44:21PM +0100, David Herrmann wrote:
>> Hi
>>
>> On Mon, Dec 30, 2013 at 12:20 PM, Antonio Ospite
>> <ospite@studenti.unina.it> wrote:
>> > On Sun, 29 Dec 2013 16:52:09 -0800
>> > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>> >
>> >> Hi Antonio,
>> >>
>> >> On Mon, Dec 23, 2013 at 05:17:43PM +0100, Antonio Ospite wrote:
>> >> > Model this part of the API after the Sony PlayStation 3 Controller which
>> >> > exposes independent analog values for each one of the D-Pad buttons.
>> >> >
>> >> > The PS3 programming API psl1ght also maps the analog D-Pad buttons
>> >> > individually.
>> >>
>> >> Hmm, even though the hardware is capable of producing independent analog
>> >> values does are they really useful? Looking at my PS3 controller I do
>> >> not think users will be pressing up/down and left/right dpad buttons at
>> >> the same time.
>> >>
>> >
>> > I must agree it's unlikely, while still possible.
>> >
>> >> I'd rather keep using ABS_HAT0X/Y unless there is really good reason for
>> >> introducing new events.
>> >>
>> >
>> > Having analog D-Pad values reported independently was proposed for these
>> > reasons:
>> >
>> >  - it matches _some_ existing hardware closely (that was the main
>> >    reason TBH, to simplify the drivers);
>> >
>> >  - it happens to follow what it's being done for D-Pad digital buttons,
>> >    they are also reported independently.
>> >
>> > However if some other hardware reported D-Pad axis combined already
>> > then I agree that using something like ABS_HAT0X/Y is safer, I see
>> > decomposing HORIZ/VERT into the separate LEFT/RIGHT and UP/DOWN to be
>> > less intuitive (not harder tho).
>> >
>> > Another doubt: David, in the other email you mentioned we could use
>> > ABS_DPAD_HORIZ/VERT, any particular reason to introduce them in place
>> > of ABS_HAT0X/Y?
>>
>> A "HAT" is an axis on the top of a joystick, nothing else. It seems
>> troublesome to overload the definition (which we did for many years).
>> Device-detection based on advertised ABS-bits gets pretty hard if we
>> reuse ABS-bits for different hardware. The most annoying example of
>> what happens is accelerometers being misdetected by Xorg as
>> mouse-input because they reuse ABS_X/Y.
>
> But they are good as joysticks (also ABS_X/ABS_Y). I do not think having
> all unique events for all device types is feasible. Can we provide hints
> (via properties) to lessen ambiguity, like we do with direct/indirect
> pointers for touchscreens/tablets?

Why don't you think it's feasible? For keys we have one definition for
each key, we don't do KEY_0 to KEY_65535 and just use the first few.
I'd really like to see the same for ABS_*. It's troublesome to detect
devices in user-space otherwise. But I guess your concern is rather
about the implementation than the idea. So could you let me know what
exactly makes you think it's not feasible?

The only problem I see is ->absinfo[] getting too big. My solution for
this would be to add a "uint16_t code" to "struct input_absinfo". So
we keep our current limited ABS set and drivers use just these. But to
add semantics, we can define additional/other ABS2_* or ABS_INFO_*
codes which define what axis this exactly is. So the axis-index is
still the limited ABS code, but to get the semantic code we query
input_absinfo.

Adding additional PROP_* bits is imho the wrong way. For instance if
we use ABS_X/Y for absolute touchpad input and the same for an
accelerometer, devices like the steam-controller couldn't report both
in the same device. Even if they set PROP_TOUCHPAD and PROP_GAMEPAD.

I'd like to get this figured out before I send v3 of the ABS2 patches.

Thanks
David