-
Bug
-
Resolution: Fixed
-
P1: Critical
-
None
-
6.0, 6.6.0
-
None
Found while testing QTBUG-118909:
void QXcbConnection::xi2ProcessTouch(void *xiDevEvent, QXcbWindow *platformWindow)
{
auto *xiDeviceEvent = reinterpret_cast<xcb_input_touch_begin_event_t *>(xiDevEvent);
TouchDeviceData *dev = touchDeviceForId(xiDeviceEvent->sourceid);
Q_ASSERT(dev);
const bool firstTouch = dev->touchPoints.isEmpty();
if (xiDeviceEvent->event_type == XCB_INPUT_TOUCH_BEGIN) {
QWindowSystemInterface::TouchPoint tp;
tp.id = xiDeviceEvent->detail % INT_MAX; // <-- only one touchpoint in this XI2 event
tp.state = QEventPoint::State::Pressed;
tp.pressure = -1.0;
dev->touchPoints[tp.id] = tp;
}
...
QWindowSystemInterface::handleTouchEvent(platformWindow->window(), xiDeviceEvent->time, dev->qtTouchDevice, dev->touchPoints.values(), modifiers);
dev->touchPoints.values() is all active touchpoints in all windows. QGuiApplicationPrivate::processTouchEvent() takes the window from the event, not the touchpoint. (QWindowSystemInterface::TouchPoint does not include the window, so we do not have the ability to send one event with touches in multiple windows via QWindowSystemInterface::handleTouchEvent(): it needs to be a separate event for each window. This could change if we start using QEventPoint there instead.) Depending on the QHash order, it might first find the pre-existing touchpoint and assign it a new window.
Maybe this is a good reason to take care of QTBUG-119029 and start trying to send QEventPoints directly from the plugin to another overload of QWindowSystemInterface::handleTouchEvent(). It will avoid some conversion overhead; QEventPointPrivate has a QWindow*, so an event with touches in multiple windows might be ok; and, QGuiApplicationPrivate::processTouchEvent() already has code to split up the events by window.
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- resulted from
-
-
- Closed
-
- resulted in
-
QTBUG-119029 Get rid of QXcbConnection::TouchDeviceData; pre-construct QEventPoints in xcb plugin
-
- Reported
-