Bug#884956: Now hidpi scaling is even more broken

[wm4]

On Mon, 19 Feb 2018 10:12:55 -0300
Lisandro Damián Nicanor Pérez Meyer  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 for fixing 

Bug#884956: Now hidpi scaling is even more broken

[Vincent Lefevre]

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.

Not everything is in the environment variables. There are also
user config files, which might matter even when they shouldn't
(let's recall that we are talking about bugs).

If there are still problems and you don't want to create a new user,
try at least something like (with a correct path):

$ mkdir /path/to/newhome
$ HOME=/path/to/newhome QT_AUTO_SCREEN_SCALE_FACTOR=0 vlc

(possibly with other environment settings).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#884956: Now hidpi scaling is even more broken

[Vincent Lefevre]

On 2018-02-19 10:12:55 -0300, Lisandro Damián Nicanor Pérez Meyer 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:
[...]

I think that wm4 just means that everything is too small.
So this actually does not break anything and is the expected
behavior.

FYI,

  QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=2 vlc

also yields a valid rendering with everything scaled by a factor 2
(wm4, doesn't this solve your issue?).

The issue is that *without* QT_AUTO_SCREEN_SCALE_FACTOR=0, the
text and the icons are not scaled with the same factor.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#884956: Now hidpi scaling is even more broken

[Lisandro Damián Nicanor Pérez Meyer]

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.

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.


> 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.

> 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.


-- 
 SlackDeb: velo como un entrenamiento shaolin para geeks,
en vez de meditación y tortura física, abstinencia de internet y sexo
  Horacio Francisco Sebastián "Perrito" Durán Barrionuevo, sobre un
  viaje que Federico "SlackDeb" Peretti estaba planeando con su novia.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#884956: Now hidpi scaling is even more broken

[wm4]

On Mon, 19 Feb 2018 12:26:54 +0100
Vincent Lefevre  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

[Vincent Lefevre]

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#884956: Now hidpi scaling is even more broken

[wm4]

On Mon, 19 Feb 2018 12:10:02 +0100
Vincent Lefevre  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

[Vincent Lefevre]

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#884956: Now hidpi scaling is even more broken

[wm4]

On Mon, 19 Feb 2018 07:54:11 -0300
Lisandro Damián Nicanor Pérez Meyer  wrote:

> El 19 feb. 2018 4:15 a.m., "wm4"  escribió:
> 
> On Sun, 18 Feb 2018 15:25:35 -0300
> Lisandro Damián Nicanor Pérez Meyer  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

[Lisandro Damián Nicanor Pérez Meyer]

El 19 feb. 2018 4:15 a.m., "wm4"  escribió:

On Sun, 18 Feb 2018 15:25:35 -0300
Lisandro Damián Nicanor Pérez Meyer  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?

Bug#884956: Now hidpi scaling is even more broken

[wm4]

On Sun, 18 Feb 2018 15:25:35 -0300
Lisandro Damián Nicanor Pérez Meyer  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

[Diederik de Haas]

On zondag 18 februari 2018 17:06:36 CET wm4 wrote:
> Debian doesn't provide an easy way to rollback

Like Lisandro already pointed out, there's testing if you use sid.
But there is always http://snapshot.debian.org which allows you to go back to 
any version ever uploaded to Debian (at least since a couple of years).

signature.asc
Description: This is a digitally signed message part.

Bug#884956: Now hidpi scaling is even more broken

[Lisandro Damián Nicanor Pérez Meyer]

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.

-- 
Los comentarios o respuestas sobre SL en tono absolutista solo hacen aparecer
a la comunidad SL como una sarta de fanáticos que viven dentro de un
tupperware.
 Pablo Di Noto - GrULiC

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#884956: Now hidpi scaling is even more broken

[Lisandro Damián Nicanor Pérez Meyer]

El domingo, 18 de febrero de 2018 13:06:36 -03 wm4 escribió:
[snip]
> Well, your attempt to fix a bug just caused another bug, and didn't
> seem to fix the original bug either. 

That happens.

> I'm sorry if my reaction was too
> strong, 

It was, and apologize accepted. Try to remember we maintainers are not 
employees, but people trying to help. Be polite with us.

> 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.

qtbase 5.9.1-12 is only available in unstable. Unstable is the place when 
things like this *can* happen. So if you think this is really an inconvenience 
please use testing, not unstable.

By the way the patch solved the issue for the users of at least two other 
distros, so it's reall ynot half-baked. Yes, there is the chance that it might 
not work everywhere, as you discovered.

But now that we are on this please check this bug log and see if the 
workaround works for you with this patch. I would test it, but I'm far from 
having a HiDPI monitor.

Thanks, Lisandro.


-- 
$ make war
make: *** No rule to make target `war'.  Stop.  Try `love' instead
  David Gravereaux

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#884956: Now hidpi scaling is even more broken

[wm4]

On Sun, 18 Feb 2018 12:47:04 -0300
Lisandro Damián Nicanor Pérez Meyer  wrote:

> El 16 feb. 2018 10:21 p.m., "wm4"  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

[Lisandro Damián Nicanor Pérez Meyer]

El 16 feb. 2018 10:21 p.m., "wm4"  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.

Bug#884956: Now hidpi scaling is even more broken

[Lisandro Damián Nicanor Pérez Meyer]

El 17 feb. 2018 8:30 a.m., "Vincent Lefevre"  escribió:

Control: reopen -1
Control: found -1 5.9.2+dfsg-12

On 2018-02-17 02:19:35 +0100, wm4 wrote:
> This "fix" broke HIDPI scaling for me.

It doesn't seem to have any effect for me. At least the icons are
still very big compared to the text.


Thanks for the feedback. It seems I'll need to revert the patch then.

Bug#884956: Now hidpi scaling is even more broken

[Vincent Lefevre]

Control: reopen -1
Control: found -1 5.9.2+dfsg-12

On 2018-02-17 02:19:35 +0100, wm4 wrote:
> This "fix" broke HIDPI scaling for me. 

It doesn't seem to have any effect for me. At least the icons are
still very big compared to the text.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#884956: Now hidpi scaling is even more broken

[wm4]

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?