Hi Dmitry

On Mon, Dec 30, 2013 at 7:50 PM, Dmitry Torokhov
[off-list ref] wrote:

On Mon, Dec 30, 2013 at 12:44:21PM +0100, David Herrmann wrote:

quoted

Hi

On Mon, Dec 30, 2013 at 12:20 PM, Antonio Ospite
[off-list ref] wrote:

quoted

On Sun, 29 Dec 2013 16:52:09 -0800
Dmitry Torokhov [off-list ref] wrote:

quoted

Hi Antonio,

On Mon, Dec 23, 2013 at 05:17:43PM +0100, Antonio Ospite wrote:

quoted

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.

quoted

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