On Mon, 19 Feb 2018 10:12:55 -0300
Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> wrote:
> El lunes, 19 de febrero de 2018 08:04:24 -03 wm4 escribió:
> > On Mon, 19 Feb 2018 07:54:11 -0300
> [snip]
> > Yeah, that is strange.
>
> *Too* strange. According to src/gui/kernel/qhighdpiscaling.cpp:
>
> 2) Per-screen scale factors
> Some platform plugins support providing a per-screen scale
> factor based on display density information. These platforms
> include X11, Windows, and Android.
>
> There are two APIs for enabling or disabling this behavior:
> - The QT_AUTO_SCREEN_SCALE_FACTOR environment variable.
> - The AA_EnableHighDpiScaling and AA_DisableHighDpiScaling
> application attributes
>
> Enabling either will make QHighDpiScaling call
> QPlatformScreen::pixelDensity()
> and use the value provided as the scale factor for the screen in
> question. Disabling is done on a 'veto' basis where either the
> environment or the application can disable the scaling. The intended
> use
> cases are 'My system is not providing correct display density
> information' and 'My application needs to work in display pixels',
> respectively.
>
> And efectively the code does that in usePixelDensity() from the same code.
> QPlatformScreen::pixelDensity() in X11 is implemented by
> src/plugins/platforms/xcb/qxcbscreen.cpp, which is the file that the patch
> touches.
>
> So the fact that the env variable "does not changes things" for you is really
> really strange.
I didn't say it didn't change anything. I just couldn't make it do the
right thing. In fact, even with -10, QT_AUTO_SCREEN_SCALE_FACTOR=0 will
break it, probably in a similar way like with -12. If that env var is
set, QT_SCALE_FACTOR=1 will make the window too small, and
QT_SCALE_FACTOR=2 will make it too big. So either way, something else
must factor into this, but I didn't check the code.
The effects with -10 are as follows:
QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=1:
Window and UI elements like scrollbars are too small. The font
size is correct. Fonts and icons have the correct size.
QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=2:
Window and UI elements have correct size, but fonts and symbols
are scaled 4 times (!!!?).
QT_AUTO_SCREEN_SCALE_FACTOR=1 (QT_SCALE_FACTOR unset):
Everything looks correct, apparently scaling 2x compared to HiDPI
disabled.
QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCALE_FACTOR=1:
Same as previous.
QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCALE_FACTOR=2:
Looks correct, except it scales 4x instead of 2x, so everything
has double the size it should have.
> Let's also look at the patch:
>
> - m_pixelDensity = qMax(1, qRound(dpi/96));
> + m_pixelDensity = qMax(1, (int) (dpi/96));
>
> The first line is the original code. The only way I see this could work for
> you in -10 but not in -12 is that (dpi/96) > 2.
>
> Please tell me which exact branch and model of monitor you have please, so I
> can check this value.
xdpyinfo contains:
dimensions: 3840x2160 pixels (530x301 millimeters)
resolution: 184x182 dots per inch
Assuming Qt computes the dpi value the same way, that makes dpi/96
approximately 1.9. (int)1.9 is 1, qRound(1.9) is 2. I'm not sure why
you're arguing with something about "> 2".
Now I don't even know if that specific patch caused the bug, since
apparently there were other Qt builds between -10 and -12, but it seems
like a rather likely candidate.
>
>
> > I didn't create a new user, because that would
> > change nothing. I made sure to override all environment variables for
> > the test.
>
> OK, but don't complain later if things do not work out for you.
What environment variable or config setting do you suppose could have
influence that a new user would remove? I set these environment
variables for my whole system anyway _and_ I tested with overwriting
their values locally from the terminal. Also before you suspect I'm
unable to set environment variables correctly: setting them certainly
had an effect.
Anyway, as it was just suggested, I also tried with setting HOME to
something else, and the result was the same.
> > I can't test anymore because after fighting Debian's
> > absolutely crappy package manager to make it downgrade to testing's
> > Qt packages, it works again. (And I'll defend my word choice "crappy".
> > Why can't it figure out transitive dependencies? It's just bad.
> > aptitude didn't behave better.)
>
> And this behavior makes me want to avoid helping you any further. So if you
> really value our work and are willing to help, please stop with this.
Depends if you find it unreasonable whether a user gets angry about
having to sink time into making a distro maintainer to revert a patch
(that was apparently never accepted in upstream Qt), that was applied as
trial&error for fixing a bug, and which wasn't reverted even after it
turned out that it 1. caused regressions for other users, and 2. didn't
fix the original bug.
