Bug#884956: Debian testing
It seems the broken Qt build has reached testing. So much for testing being better for stability. I wants to upgrade from 5.9.2+dfsg-10 to 5.9.2+dfsg-12.
Bug#884956: Now hidpi scaling is even more broken
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, pl
Bug#884956: Now hidpi scaling is even more broken
On Mon, 19 Feb 2018 12:26:54 +0100 Vincent Lefevre <vinc...@vinc17.net> wrote: > On 2018-02-19 12:04:24 +0100, wm4 wrote: > > Yeah, that is strange. I didn't create a new user, because that would > > change nothing. I made sure to override all environment variables for > > the test. 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.) > > IMHO, dependency resolution would not work well (or even not at all) > for downgrades. Getting all the installed package from the same source > package (here, qtbase-opensource-src) could make things easier for > downgrades. > Well, I had the following situation: I uninstalled some Qt and application packages as preparation for downgrading. Then I installed the downgraded Qt packages. Then I wanted to reinstall an application package. But it showed dozens of errors like this: package1 : Depends: package2 (>= version) but it is not going to be installed It turns out the resolution was removing/downgrading just 1 or 2 packages (not package1 or package2) that transitively blocked installing package2. Not even aptitude after crunching on it for minutes could come up with the resolution. I'd really expect better. I don't get why Debian has to split everything into thousands of packages either, when everything depends on everything anyway. Sorry for off-topic.
Bug#884956: Now hidpi scaling is even more broken
On Mon, 19 Feb 2018 12:10:02 +0100 Vincent Lefevre <vinc...@vinc17.net> wrote: > On 2018-02-18 15:25:35 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > wm4, Vincent: can you try setting QT_AUTO_SCREEN_SCALE_FACTOR=0 ? > > QT_AUTO_SCREEN_SCALE_FACTOR=0 works with -12, just like with -10. > > I suspect that different behaviors are due to the fact that among > HiDPI cases, screen sizes, DPI's, etc. are different. > > The patch consisted in truncating instead of rounding to nearest, > so that it might have solved the problem for users where the > real factor was between 1.5 and 2, thus changed from 2 to 1 > when converted to integer, 1 meaning no HiDPI (for which there > are no issues) if I understand correctly. > > I suppose that my real factor is between 2 and 2.5, so that truncating > gives the same result as rounding to nearest. Hence the same behavior. > > I don't know what broke for wm4. "With the patch applied, it scales > to 1, which is nonsense." is not very meaningful. This is what happens > for low DPI, for which no issues have been reported. > Maybe I wasn't clear enough, but I have a HiDPI screen, with a scale factor (as reported by X11) of approximately 1.9. With -12, it reduced the sizes of windows and GUI elements by half, and no combination of environment variables made it scale correctly. I suspect there's some other scaling factoring in somewhere, which somehow controls font sizes. Now I'm back to -10 (testing), and I won't upgrade it until the patch is reverted, so no new tests by me.
Bug#884956: Now hidpi scaling is even more broken
On Mon, 19 Feb 2018 07:54:11 -0300 Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> wrote: > El 19 feb. 2018 4:15 a.m., "wm4" <nfx...@googlemail.com> escribió: > > On Sun, 18 Feb 2018 15:25:35 -0300 > Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> wrote: > > > I've been digging around and: > > > > - One user (wm4, CCed) reported that the fix broke his setup. wm4: can you > > please test -12 with a new user without any change to any setup? > > > > - One user that did not see any change (Vincent, CCed). > > > > - One user and fellow developer Dmitry (auto CCed) which found that for > him > > -12 works better than -10. He also tested that using > > > > QT_AUTO_SCREEN_SCALE_FACTOR=0 > > > > makes VLC work as -12 without that variable set in both -10 or -12, > meaning > > that the patch indeed helps him. > > > > wm4, Vincent: can you try setting QT_AUTO_SCREEN_SCALE_FACTOR=0 ? mw4: in > your > > case I would like you to test in your normal user and in the new user I > asked > > you about above. > > > > I acknowledge that the bug is still there, but as long as we do not have > > strong evidence that it backfires for most people we will keep it around > until > > upstream finds a proper fix. > > > > Cheers, Lisandro. > > > > No combination of these environment variables restores behavior. Please > unbreak this. > > > That's totally strange because that environment variable is supposed to > override that value. Have you tried by creating a new user? Yeah, that is strange. I didn't create a new user, because that would change nothing. I made sure to override all environment variables for the test. 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.)
Bug#884956: Now hidpi scaling is even more broken
On Sun, 18 Feb 2018 15:25:35 -0300 Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> wrote: > I've been digging around and: > > - One user (wm4, CCed) reported that the fix broke his setup. wm4: can you > please test -12 with a new user without any change to any setup? > > - One user that did not see any change (Vincent, CCed). > > - One user and fellow developer Dmitry (auto CCed) which found that for him > -12 works better than -10. He also tested that using > > QT_AUTO_SCREEN_SCALE_FACTOR=0 > > makes VLC work as -12 without that variable set in both -10 or -12, meaning > that the patch indeed helps him. > > wm4, Vincent: can you try setting QT_AUTO_SCREEN_SCALE_FACTOR=0 ? mw4: in > your > case I would like you to test in your normal user and in the new user I asked > you about above. > > I acknowledge that the bug is still there, but as long as we do not have > strong evidence that it backfires for most people we will keep it around > until > upstream finds a proper fix. > > Cheers, Lisandro. > No combination of these environment variables restores behavior. Please unbreak this.
Bug#884956: Now hidpi scaling is even more broken
On Sun, 18 Feb 2018 12:47:04 -0300 Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> wrote: > El 16 feb. 2018 10:21 p.m., "wm4" <nfx...@googlemail.com> escribió: > > This "fix" broke HIDPI scaling for me. > > Looking at the patch, this patch is just broken. Rounding up to > nearest is correct, because it means if you have a scale factor of > 1. you end up with 2. With the patch applied, it scales to 1, which > is nonsense. > > What the heck are you doing? Really? > > > Trying to solve user's bugs. Really. > > Trying to fix bugs which I can't even reproduce. Really. > > Trying to make the world a little bit better by using my free time to > package free software, really. > > And really really demotivated by users who think I'm his employee. Really. Well, your attempt to fix a bug just caused another bug, and didn't seem to fix the original bug either. I'm sorry if my reaction was too strong, but right now every new Qt program I start is unusable, and Debian doesn't provide an easy way to rollback, or even building all the Qt packages with the patch removed. It's a big inconvenience. It's not the first time that Debian makes things worse by randomly applying half-baked patches either. (Also, in this case, from a distro which most likely cares about making Qt behave like Qt only, rather than any kind of real fix. Desktop environments other than Gnome are left broken.) As if HIDPI configuration on Linux weren't already hard enough.
Bug#884956: Now hidpi scaling is even more broken
This "fix" broke HIDPI scaling for me. Looking at the patch, this patch is just broken. Rounding up to nearest is correct, because it means if you have a scale factor of 1. you end up with 2. With the patch applied, it scales to 1, which is nonsense. What the heck are you doing? Really?
