Priority: P2: Important
Affects Version/s: 5.12.0
Fix Version/s: None
Environment:Windows 10 with multiple monitors with at least on HiDPI monitor at 200% and on monitor 100%.
We have many customers with HiDPI displays on Windows 10. Most also have multiple monitors with a mixture of 100% and 200% displays.
We also have always run our apps with AA_EnableHighDpiScaling and AA_UseHighDpiPixmaps and
With this configuration the QMouseEvent::globalPos() are not always correct.
What is interesting is the value for QCursor::pos() does appear to be correct.
Note that we are transitioning to 5.12.0 without any testing for any version after 5.9.6, so we do not know when this HiDPI regression was introduced.
There have been problems with HiDPI issues since we switched from 4.8 to 5.6 then through 5.9.6. However we had a to develop a significant patch that worked for us until we decided to get ready to switch to 5.12.0. The proposed patch in QTBUG-62149 was rejected.
And now that we no longer can apply our patch the problem is much worse and QMouseEvent::globalPos() values on HiDPI monitors is no longer correct.
The solution appears to be to help develop a new new HiDPI patch that is acceptable.
Taking the hint from correct native to global conversion from QCursor:pos(), the proposed patch will likely guarantee that all of the native to global and global to native always find the screen that contains the input point and then use that screen to determine the output point.
To correctly handle windows that are span monitors with different scale factors, most, if not all of the conversion functions that use a window will only use the window to find a screen, then the screen will be used to find the screen that really contains the point.
In the meantime we are spending testing and documenting the behavior of our 5.12 - based apps on different HiDPI multi-monitor configurations with different scale factors.