| Message ID | 1387815463-29345-1-git-send-email-ospite@studenti.unina.it (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 */
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