Bug 83383

Summary:	fail to receive touch_frame after final touch_up (Qt)
Product:	Wayland	Reporter:	Shawn Rutledge <shawn.t.rutledge>
Component:	weston	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium	CC:	johan.helsing
Version:	1.5.0
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Shawn Rutledge 2014-09-02 05:34:53 UTC

In Qt applications it was not possible to press any QPushButton or QtQuick MouseArea on a touchscreen because of this: it waits for the release in order to treat the press-release sequence as a "click".  So we added a workaround: if all touch points have been released, send ourselves an artificial touch_frame.  But it has been said that this might be a regression after the latest work with wayland using libinput.

https://codereview.qt-project.org/#/c/93572/

Tested with the latest git versions of wayland, weston and libinput on Arch Linux, on two different systems both with touchscreens.

Comment 1 Shawn Rutledge 2014-09-02 05:36:19 UTC

related Qt bug: https://bugreports.qt-project.org/browse/QTBUG-36602

Comment 2 Shawn Rutledge 2014-09-02 05:47:23 UTC

I should rather say that the Qt touch handling strategy is to accumulate touchpoints and then handle them when we receive a touch_frame, and that in turn is because of the architecture that multiple touch points are grouped into a single QTouchEvent.  We've been thinking of having separate events for each touch point movement in Qt 6 (can't do such big changes in Qt 5).  This would help to facilitate a better event inheritance tree so that handling of mouse, touch and tablet events could be unified in some elements that don't care much about the differences between them (if there is to be a QPointingEvent base class from which QTouchEvent inherits, it should have only a single pair of coordinates).  And multiple mice could be treated much like multiple fingers (except that multiple mice tends to imply multiple users, so maybe we need a "seat" concept like wayland has).  If we did that, then maybe it would be appropriate to ignore the touch_frame entirely, which might improve reliability.  But for now we depend on it, because we generally don't send a QTouchEvent until all the touch points have been updated (except for this latest workaround when all touch points are released).

Comment 3 Johan Helsing 2018-02-21 09:08:58 UTC

We ended up doing a workaround for it in Qt: https://codereview.qt-project.org/#/c/93572/

Since we're not sort of breaking the protocol, I created: https://bugreports.qt.io/browse/QTBUG-66563

I'm not aware of any problems caused by the workaround, except that it caused one of our tests to be flaky. That can be worked around, too, though.

Comment 4 GitLab Migration User 2018-06-08 23:52:26 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/wayland/weston/issues/44.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.