Bug 358689

Summary: [X11] Support Qt 5.6 new highdpi environment variable
Product: [Applications] systemsettings Reporter: Weng Xuetian <wengxt>
Component: kcm_kscreenAssignee: kscreen-bugs-null <kscreen-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: wishlist CC: chalkerx, katyaberezyaka, kde, kfunk, mgraesslin, nate, plasma-bugs, postix
Priority: NOR    
Version: 5.14.3   
Target Milestone: ---   
Platform: Other   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=414866
Latest Commit: Version Fixed In:

Description Weng Xuetian 2016-01-28 16:57:32 UTC
For more details: https://doc-snapshots.qt.io/qt5-5.6/highdpi.html
QT_DEVICE_PIXEL_RATIO is deprecated but still supported by Qt 5.6.
New environment variable includes QT_AUTO_SCREEN_SCALE_FACTOR, 
QT_SCALE_FACTOR, and QT_SCREEN_SCALE_FACTORS.

And now it is possible to configure per screen scale factor via environment variable. 

Reproducible: Always
Comment 1 Nikita Skovoroda 2016-04-03 13:01:43 UTC
Setting QT_SCREEN_SCALE_FACTORS=2 seems to do exactly the same as QT_DEVICE_PIXEL_RATIO=2 did before 5.6.
Comment 2 Nikita Skovoroda 2016-04-03 13:02:52 UTC
See also https://bugreports.qt.io/browse/QTBUG-52285
Comment 3 Nikita Skovoroda 2016-04-03 13:07:25 UTC
QT_AUTO_SCREEN_SCALE_FACTOR enables the auto-scaling, which has certain issues (it does not calculate the correct scale on notebooks, for example), see https://bugreports.qt.io/browse/QTBUG-52202

QT_SCALE_FACTOR is an _additional_ scaling factor, and that one also scales fonts, which are already adjusted by the dpi setting (and forcing dpi to 96 would break other apps).

http://doc.qt.io/qt-5/highdpi.html#qt-support
Comment 4 Martin Flöser 2016-07-20 16:41:18 UTC
@David: this should be fixed by 440a3d7c2035c742c32f104076acd320916fed14 in plasma-workspace, shouldn't it?
Comment 5 Weng Xuetian 2016-07-21 04:17:19 UTC
Emm, I'd prefer leave it open until it support real "per screen" setting instead of set same ratio for all screen.
Comment 6 Martin Flöser 2016-07-21 05:57:07 UTC
(In reply to Weng Xuetian from comment #5)
> Emm, I'd prefer leave it open until it support real "per screen" setting
> instead of set same ratio for all screen.

we cannot have per screen on X11.
Comment 7 Weng Xuetian 2016-07-21 16:21:53 UTC
This setting has nothing to do with X11, it's just for Qt itself.

you can set it like:
QT_SCREEN_SCALE_FACTORS=eDP1=2;eDP2=3

So when you move window among screen, the Qt's window will be rescaled to the screen dpi automatically.

Right now kscreen can only set it to the same value.
Comment 8 Martin Flöser 2016-07-22 05:34:20 UTC
(In reply to Weng Xuetian from comment #7)
> This setting has nothing to do with X11, it's just for Qt itself.
> 
> you can set it like:
> QT_SCREEN_SCALE_FACTORS=eDP1=2;eDP2=3
> 
> So when you move window among screen, the Qt's window will be rescaled to
> the screen dpi automatically.

That cannot work on X11, sorry. That's just Qt's "I don't know how to multi-screen on X11". The problems here are:
* a window is not connected with an output, it has a position within the X screen space
* QWindow allows to set the QScreen, but this does not influence whether the window is sown on the screen
* DPI for multi-screen on common X-Servers is broken. As soon as there are two screens, the X-Server does report a default 96 pdi AFAIK
* when moving a window from one screen to another it could result in an infinite jumping between the different DPI modes
* the totally legit situation of one window on two screens is not handled
* the window manager does not adjust the window decoration
* I could go on and on

Exposing a config option for that would be wrong: we cannot have different scale factors on X11. That would just introduce another set of things which can go wrong with Qt's utterly broken (and broken beyond repair) multi-screen implementation on X11.
Comment 9 Weng Xuetian 2016-07-22 21:30:14 UTC
(In reply to Martin Gräßlin from comment #8)
> (In reply to Weng Xuetian from comment #7)
> > This setting has nothing to do with X11, it's just for Qt itself.
> > 
> > you can set it like:
> > QT_SCREEN_SCALE_FACTORS=eDP1=2;eDP2=3
> > 
> > So when you move window among screen, the Qt's window will be rescaled to
> > the screen dpi automatically.
> 
> That cannot work on X11, sorry. That's just Qt's "I don't know how to
> multi-screen on X11". The problems here are:
> * a window is not connected with an output, it has a position within the X
> screen space
> * QWindow allows to set the QScreen, but this does not influence whether the
> window is sown on the screen
> * DPI for multi-screen on common X-Servers is broken. As soon as there are
> two screens, the X-Server does report a default 96 pdi AFAIK
> * when moving a window from one screen to another it could result in an
> infinite jumping between the different DPI modes
> * the totally legit situation of one window on two screens is not handled
> * the window manager does not adjust the window decoration
> * I could go on and on
> 
> Exposing a config option for that would be wrong: we cannot have different
> scale factors on X11. That would just introduce another set of things which
> can go wrong with Qt's utterly broken (and broken beyond repair)
> multi-screen implementation on X11.

Such complain doesn't solve anything. You're just pointing to some "Potential" Problem that doesn't really happen. 

I have been using QT_DEVICE_PIXEL_RATIO=auto (when it's still old style env var) since Qt 5.4, and it never cause me any trouble. Dynamically change window's scale factor is tricky, but it's also the same approach on Windows. 

I have been use it for such a long time. And if any issue you claim actually happens, Qt should fix it. Not to mention IT IS not the case. I have even seen user complain about startkde script prevent user to set QT_AUTO_SCREEN_SCALE_FACTOR to 1. It's not something badly broken, really.
Comment 10 Nate Graham 2019-07-20 14:03:06 UTC
There's a patch that implements this feature: https://phabricator.kde.org/D12405
Comment 11 David Edmundson 2019-07-20 18:38:33 UTC
That patch also expands on what breaks
Comment 12 Nate Graham 2022-01-21 05:14:28 UTC

*** This bug has been marked as a duplicate of bug 414866 ***