Incorrect tablet event X/Y reported on a Surface laptop with external monitor

I have a Surface Book laptop connected to an external monitor in "extend the desktop to this monitor" mode, with the desktop extending to the right side.

My Qt app runs on the Surface Book display (set as the main one), and I'm using the Surface Pen input functionality via WinTab, translated as QTabletEvents.

When using the pen, the x/y coordinates of the reported tablet events are offset to the right from the actual pen position on the screen. If I disconnect the external monitor, the x/y coordinates are correct.

I tracked it down to the following lines in QWindowsTabletSupport::translateTabletPacketEvent():

    const QRect virtualDesktopArea =
        QWindowsScreen::virtualGeometry(QGuiApplication::primaryScreen()->handle());

        const QPointF currentGlobalPosF =
            m_devices.at(m_currentDevice).scaleCoordinates(packet.pkX, packet.pkY, virtualDesktopArea);

So this code makes sense for external Wacom-based tablets where the tablet should span the whole virtual desktop, regardless of the number of monitors. However for a touchscreen-like tablet device, we want the desktop area to match the specific monitor instead.

I've looked at the info reported by Wintab, and there's nothing identifying that the device is a touchscreen vs an external flat-type tablet. All we have is the cursor type returned by CSR_TYPE, which in the case of the Surface family of devices actually returns an identifiable non-standard value for the type. However that likely won't work for non-Microsoft devices like the Dell and other 2-in-1s with a Wacom-compatible digitizer. (anybody has one to test on to see what CSR_TYPE reports for those?)

My proposed solution would be to add another platform plugin option to toggle the touchscreen behavior on/off (and would also automatically disable the mouse mode, see my comment on QTBUG-36937), for cases when it can't be automatically detected.

Any other options that come to mind? If not I can prepare a patch that implements the proposed behavior.

By the way, are there any plans for using the native Windows Ink API to implement the tablet events on Windows 10? I'm not sure it's even feasible, and WinTab does the job just fine in the meantime, I'm just curious if that's in the pipeline.