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.