Bug 428990 - High DPI scaling works on display :0 only
Summary: High DPI scaling works on display :0 only
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Setup-Misc (other bugs)
Version First Reported In: 7.1.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-11 21:50 UTC by Gerhard
Modified: 2022-01-14 21:14 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 7.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard 2020-11-11 21:50:54 UTC
In the settings dialogue | Miscellaneous, tab "System" there are two settings about high DPI, "Use high DPI scaling from the screen factor" and "Use pixmaps with high DPI resolution".
The settings work as expected if the KDE session uses display :0. However, if digikam is started in a session using another display, it no longer works, i.e. fonts and images are too small on a high DPI screen.


STEPS TO REPRODUCE
1. log in as first user, start digikam, set the two options named above and restart digikam
2. observe the splash screen on startup is bigger, i.e. the option works
3. start a new KDE session with the same user and start digikam 

OBSERVED RESULT
high DPI scaling no longer works 

EXPECTED RESULT
should be independent of the display

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: openSUSE Tumbleweed 20201108
KDE Plasma Version: 5.20.2
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.1

ADDITIONAL INFORMATION
DPI set to 144, 144
Comment 1 Maik Qualmann 2020-11-12 06:59:30 UTC
Please post the output of:

echo $QT_SCREEN_SCALE_FACTORS

Maik
Comment 2 Gerhard 2020-11-12 07:10:33 UTC
#> echo $QT_SCREEN_SCALE_FACTORS
DisplayPort-0=1.5;DisplayPort-1=1.5;HDMI-A-0=1.5;HDMI-A-1=1.5;

It's the same on both displays :0 and :1

/Gerhard
Comment 3 Maik Qualmann 2020-11-12 07:54:53 UTC
I don't think we can do anything here and the problem is with Qt or KWin. We have no further options to enforce HiDPI.

Maik
Comment 4 Maik Qualmann 2020-11-12 08:22:01 UTC
Can the problem be reproduced with other programs, e.g. Gwenview or Krita?

Maik
Comment 5 Gerhard 2020-11-13 08:13:28 UTC
Good point, in fact, it's quite a lot of programs that suffer from this problem. I tried krita, k3b, kdenlive, showfoto, gwenview (best seen if they have a splash at startup).
However, gimp works correctly on both screens. Maybe it only affects Qt applications?

/Gerhard
Comment 6 caulier.gilles 2022-01-09 15:37:16 UTC
Hi Gerhard,

Please try with the Krita 5 AppImage just released. It use a LTS version of Qt. Perhaps the bug is fixed in this release, or perhaps krita as specific rules at startup for this kind of problem. See below...

Maik,

I recommend to take a quick look to the main.cc file from Krita. It's always a good inspiration as plenty of technical workaround are patched here. Perhaps there is something suitable for digiKam about HDPI support :

https://invent.kde.org/graphics/krita/-/blob/master/krita/main.cc#L293

https://invent.kde.org/graphics/krita/-/blob/master/CMakeLists.txt#L414

Gilles
Comment 7 Maik Qualmann 2022-01-09 16:38:36 UTC
@Gilles, I have often looked in the main.cc file from Krita. ((:-))

Maik
Comment 8 Gerhard 2022-01-14 21:13:10 UTC
Meanwhile, I'm on openSUSE Tumbleweed 20220112, usinf Plasma 5.23.5, KF 5.90, Qt 5.15.2, and digikam 7.4.
The high DPI problem is gone now. digikam, showfoto and krita scale as desired on X displays > :0. :-)
Comment 9 caulier.gilles 2022-01-14 21:14:22 UTC
Great, thanks for the feedback...