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:


     Window and UI elements like scrollbars are too small. The font
     size is correct. Fonts and icons have the correct size.


     Window and UI elements have correct size, but fonts and symbols
     are scaled 4 times (!!!?).


     Everything looks correct, apparently scaling 2x compared to HiDPI


     Same as previous.


     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.

Reply via email to