Hi Dmitry On Mon, Dec 30, 2013 at 7:50 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> wrote: >> > On Sun, 29 Dec 2013 16:52:09 -0800 >> > Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
