Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.7.0
-
None
-
Arch Linux
Description
The current QScreen::geometry makes no note of the behavior regarding screens with different devicePixelRatio's set, so I assumes that the coordinates and sizes would be measured in device-independent pixels. It however turns out that the origin is in native pixels while the dimensions are measured in device-independent units.
If this is the intended behavior, please document it. Similarly, a clarification for QCursor::pos() regarding the HiDPI situation would also be nice (currently it seems to add the origin (native pixels) to the relative offset in the current screen (in device-indep pixels)).
The High DPI Displays page also makes no special mention of Linux, but apparently users can set the QT_AUTO_SCREEN_SCALE_FACTOR=1 and it reportedly seems to work.
Background for this issue: I was trying to improve HiDPI support for the Spectacle screenshot program for KDE where information like external window dimensions are measured in native pixels and where a user takes a screenshot with a size measured in native pixels. The naive approach was to multiply/divide every x, y, width and height by the screen scaling factor but that failed. (It would also not work in presence of screens with different scaling ratios, but it illustrates the difficulties during development.)
Example output (with QT_SCALE_FACTOR=2):
"eDP-1" QRect(0,360 960x540) "DP-2" QRect(1920,0 1280x720) QPoint(3200,720)
Attachments
Issue Links
- is duplicated by
-
QTBUG-84206 QScreen size() returns incorrect offset for second monitor
- Open
- relates to
-
QTBUG-68571 [xcb][eglfs][wayland] QCursor does not support hidpi pixmaps
- Reported
-
QTBUG-64163 QScreen reports wrong geometry on dual HiDPI screens
- Closed
-
QTBUG-85125 QScreen::geometry() returns a mix of physical pixels and device independent pixels
- Closed
-
QTBUG-64992 The High-DPI Display Layout Problem
- Closed