https://bugs.kde.org/show_bug.cgi?id=461996
Laurent <kde94a0183f4466...@lpsink.fastmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kde94a0183f4466752@lpsink.f
| |astmail.com
--- Comment #11 from Laurent <kde94a0183f4466...@lpsink.fastmail.com> ---
I can confirm. Unfortunately, this seems to be a Qt issue.
Okular gets the DPI here, for the x and y axes separately:
https://invent.kde.org/graphics/okular/-/blob/master/core/utils.cpp#L52
X11 has the correct DPI, but Qt recomputes it as pixel_size / physical_size.
This is baked on several levels, both in platform-independent code:
https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qscreen.cpp?id=71c3aab7baae9220b37178711a49746f66975d63#n211
and in the low-level XCB code:
https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbscreen.cpp?id=71c3aab7baae9220b37178711a49746f66975d63#n104
It seems that physical_size does not come from the X11 display (as returned by
xdpyinfo). This would have been fine because X11 fakes a reasonable physical
size based on the monitors attached. Instead it comes from the monitor geometry
either through xrandr or the EDID information.
This is a problem because it fails to account for the possibility of black bars
on the top and bottom of the monitor when its aspect ratio does not match the
resolution. Indeed Eric sets "xrandr --output eDP-1 --mode 3840x2160", which is
16:9, while also saying the monitor is 16:10.
I was not able to pinpoint the bug the Qt code. Hopefully someone else can. But
I did check that QApplication::desktop()->widthMM() and
QApplication::desktop()->heightMM() indeed return the physical monitor
dimension regardless of black bars (which is perhaps not a bug in itself).
--
You are receiving this mail because:
You are watching all bug changes.
