Hi Giulio, Peter, On Wed, Apr 14, 2021 at 01:22:55PM +0200, Giulio Benetti wrote: > Hi Peter, Dmitry, > > On 4/14/21 8:46 AM, Peter Hutterer wrote: > > On Tue, Apr 13, 2021 at 10:44:07PM -0700, Dmitry Torokhov wrote: > > > Hi Giulio, > > > > > > On Tue, Apr 13, 2021 at 04:44:46PM +0200, Giulio Benetti wrote: > > > > + > > > > + input_mt_report_pointer_emulation(tsdata->input, true); > > > > > > For touchscreens it does not make much sense to report BTN_DOUBLETAP, > > > BTN_TRIPLETAP, etc, events (they are really for touchpads), so I changed > > > this to > > > > > > input_mt_report_pointer_emulation(tsdata->input, false); > > > > > > to only report ABS_X, ABS_Y, and BTN_TOUCH, and applied. > > > > Can you expand on this please, just to make sure I'm not misinterpreting > > those codes? Those bits are just for how many fingers are down (but without > > position), dropping those bits means you restrict the device to a pure > > single-touch screen. Or am I missing something here? They are indeed represent number of fingers on the surface. I think I over-simplified this a bit by saying these events are only for touchpads, as there is allowance for BTN_TOOL_*TAP in Documentation/input/multi-touch-protocol.rst for MT devices that may report more contacts than what they can distinctly track, and it is not restricted to touchpads (but I believe in reality only used by a couple of "semi-MT" touchpad drivers). What I meant to say that for ST fallback of MT-capable devices we typically provide BTN_TOOL_*TAP for devices declared as INPUT_MT_POINTER (which is touchpads) and for INPUT_MT_DIRECT and others we only provide ABS_X, ABS_Y, ABS_PRESSURE and BTN_TOUCH (see input_mt_sync_frame()), and I think this driver should follow the suit. > > I've re-tested the driver after setting input_mt_report_pointer_emulation() > use_count to false. It works correctly with all touch points expected. That > use_count refers to finger count of Touchpad[1]. Also you can see that even > with use_count=false this for loop[2] is entered by counting all the > mt->slots and then input_event() reports all of them. That is not quite true. The loop in question locates the oldest contact still on the surface and MT->ST mapping uses it as the "primary" point for ST events. It is reported in addition to sending all contacts via MT protocol as ABS_MT_SLOT, ABS_MT_POSITION_X, ABS_MT_POSITION_Y, ... > > I hope I've understood correctly :-) > > [1]: https://elixir.bootlin.com/linux/v5.12-rc7/source/drivers/input/input-mt.c#L190 > [2]: https://elixir.bootlin.com/linux/v5.12-rc7/source/drivers/input/input-mt.c#L208 > > > then again, MT support has been in the kernel for long enough that by now > > everything should understand it, so there's a certain "meh" factor. Yeah, there is that too. Thanks. -- Dmitry
