(2) Question about Linux MT Protocol B type
Peter Hutterer
peter.hutterer at who-t.net
Fri May 22 11:26:48 UTC 2020
On Fri, May 22, 2020 at 05:44:09PM +0900, 강정현 wrote:
> Dear Mr. Hutterer.
>
> Thanks you for your reply.
>
> And I have another question about this, so I hope you reply about this
> question.
>
> Following my second case, libinput reports below events. (used evtest and
> libinput debug-events)
for the future: use libinput record instead of evtest, it spits out YAML and
adds some extra bits for puny humans which make things easier to understand.
and of course YAML is easier to process if you need to.
> ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
> │Event: time 1420073073.110197, type 3 (Absolute), code 57 (MT Tracking ID), │
> │value 22 │
> │Event: time 1420073073.110197, type 1 (Key), code 330 (Touch), value 1 │
> │Event: time 1420073073.110197, type 3 (Absolute), code 53 (MT Position X), │
> │value 176 │
> │Event: time 1420073073.110197, type 3 (Absolute), code 54 (MT Position Y), │
> │value 1027 │
> │Event: time 1420073073.143950, -------------- Report Sync ------------ │
> │Event: time 1420073073.165862, type 3 (Absolute), code 57 (MT Tracking ID), │
> │value -1 │
> │Event: time 1420073073.165862, type 1 (Key), code 330 (Touch), value 0 │
> │Event: time 1420073073.165862, type 3 (Absolute), code 47 (MT Slot), value 1 │
> │Event: time 1420073073.165862, type 3 (Absolute), code 57 (MT Tracking ID), │
> │value 23 │
> │Event: time 1420073073.165862, type 1 (Key), code 330 (Touch), value 1 │
fwiw, this isn't correct because you're releasing BTN_TOUCH and
setting it within the same evdev frame. Any client that cannot handle the MT
protocol but just goes by BTN_TOUCH will likely treat this as continuous
touch. evdev state accumulates until the SYN_REPORT and is only then
handled, so in this case a client would unset the bit, then set the bit and
only then later look at it.
clients that handle MT *probably* don't care about BTN_TOUCH so it won't
matter for those.
Oh, and I just noticed you're missing BTN_TOOL_FINGER which you should set
for any touch device.
> │Event: time 1420073073.165862, type 3 (Absolute), code 53 (MT Position X), │
> │value 628 │
> │Event: time 1420073073.165862, type 3 (Absolute), code 54 (MT Position Y), │
> │value 1099 │
> │Event: time 1420073073.177031, -------------- Report Sync ------------ │
> │Event: time 1420073073.210082, type 3 (Absolute), code 57 (MT Tracking ID), │
> │value -1 │
> │Event: time 1420073073.210082, type 1 (Key), code 330 (Touch), value 0 │
> │Event: time 1420073073.210082, -------------- Report Sync ------------ │
> └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
>
>
>
> ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
> │ event2 TOUCH_DOWN +39.022s 0 (0) 24.44/80.23 (176.00/1027.00mm) │
> │ event2 TOUCH_FRAME +39.022s │
> │ event2 TOUCH_UP +39.078s │
> │ event2 TOUCH_DOWN +39.078s 1 (0) 87.22/85.86 (628.00/1099.00mm) │
> │ event2 TOUCH_FRAME +39.078s │
> │ event2 TOUCH_UP +39.122s │
> │ event2 TOUCH_FRAME +39.122s │
> └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
>
> So I looks like 1st finger down -> 1st finger up -> 2nd finger down -> 2nd
> finger up
>
> I interpret it: 2nd finger down can come first than 1st finger, after all
> fingers are released.
the TOUCH_FRAME is the key here - anything within the frame is considered
the same hardware event. So in the list above, you have 3 events:
- touch 0 down
- touch 0 up and touch 1 down
- touch 1 up
The order within a frame must not matter to a client (evdev clients and
libinput client, for that matter).
> I have thought that first touch down's index is always 0.
the touch index value is an implementation detail. the only guarantee is
that any given index refers to the same touch until the touch up event. It
may get reused after that. (iirc) libinput increases them, but not always
just by 1 due to implementation details. So right now the first index is
zero but if I'm bored tomorrow I could change this to 42 and no client
should break :)
hth
Cheers,
Peter
> But following in this case, second or third touch down can come fater than
> first touch down.
>
> So I ask it to you that second finger down came fisrt situation is normal
> situation or not..
>
> I'll waiting for your reply.
>
> If you reply about this, it helps me a lot.
>
>
>
> Thanks and regards,
>
> JeongHyun Kang.
>
>
>
> --------- Original Message ---------
>
> Sender : Peter Hutterer <peter.hutterer at who-t.net>
>
> Date : 2020-05-22 12:32 (GMT+9)
>
> Title : Re: Question about Linux MT Protocol B type
>
>
>
> On Thu, May 21, 2020 at 07:42:33PM +0900, 강정현 wrote:
> > Dear all,
> >
> > I have an one question about Linux MT Protocol B type.
> >
> > Asume that press touch screen using first finger.
> >
> > And release fisrt finger and press second finger toghether.
> >
> >
> >
> > In that case, which procotol is correct?
> >
> > ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
> > │ ABS_MT_SLOT 0 │
> > │ │
> > │ ABS_MT_TRACKING_ID 1 │
> > │ │
> > │ ABS_MT_POSITION_X 10 │
> > │ │
> > │ ABS_MT_POSITION_Y 5 │
> > │ │
> > │ ABS_MT_SYNC <-- first finger press │
> > └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
>
> There's no such thing as ABS_MT_SYNC, use SYN_REPORT here.
>
> > first case
> >
> > ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
> > │ ABS_MT_TRACKING_ID -1 │
> > │ │
> > │ ABS_MT_TRACKING_ID 2 │
> > │ │
> > │ ABS_MT_POSITION_X 15 │
> > │ │
> > │ ABS_MT_POSITION_Y 10 │
> > │ │
> > │ ABS_MT_SYNC <-- first finger release and first finger press is generated │
> > └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
>
> Nope, that's wrong. You could skip the tracking ID -1 event and switch
> directly to ID 2. This is technically allowed by the protocol but
> a lot of userspace (anything Xorg and libinput) will struggle with it
> for historical reasons. Where you are re-using the same slot, you should
> always stop a touch and start the next touch in a separate frame.
>
> Direct switching also introduces some ambiguity because it merely means
> "kernel lost tracking of touch point", so userspace now has to decide
> whether it's the same touch or a new touch.
>
> >
> > second case
> >
> > ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
> > │ ABS_MT_TRACKING_ID -1 │
> > │ │
> > │ ABS_MT_SLOT 1 │
> > │ │
> > │ ABS_MT_TRACKING_ID 2 │
> > │ │
> > │ ABS_MT_POSITION_X 15 │
> > │ │
> > │ ABS_MT_POSITION_Y 10 │
> > │ │
> > │ ABS_MT_SYNC <-- first finger release and second finger press is generated │
> > └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
>
> this is the correct sequence (except for the ABS_MT_SYNC bit :).
>
> Cheers,
> Peter
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://protect2.fireeye.com/url?k=b0d106c4-ed1dcf40-b0d08d8b-0cc47aa8f5ba-4eb0ded9c4a94a0e&q=1&u=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fwayland-devel
>
>
>
> [cid]
>
> *
More information about the wayland-devel
mailing list