Bug#884956:

[dodo christoph]

Hallo guten Abend, ich habe Ihnen gestern eine E-Mail geschickt, aber keine
Antwort, bitte rufen Sie mich an oder antworten Sie dringend

Bug#884956: HiDPI scaling is still broken with libqt5core5a 5.10.1+dfsg-6

[Vincent Lefevre]

On 2019-09-15 21:19:57 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> It has been fixed in 5.14, so it will take some time to get into unstable.
> According to what I read the changes are many so I highly doubt or would be
> backportable.

In any case, the workaround is sufficient for me. A backport would
probably be not useful enough and too risky.

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

Bug#884956: HiDPI scaling is still broken with libqt5core5a 5.10.1+dfsg-6

[Lisandro Damián Nicanor Pérez Meyer]

Hi Vincent!

El dom., 15 sep. 2019 08:09, Vincent Lefevre  escribió:

> Control: found 884956 5.11.3+dfsg1-4
> Control: tags 884956 fixed-upstream
>
> On 2018-11-13 15:49:24 +0300, Dmitry Shachnev wrote:
> > Hi Vincent and all!
> >
> > On Sun, May 06, 2018 at 11:09:09AM +0200, Vincent Lefevre wrote:
> > > Control: reopen -1
> > > Control: found -1 5.10.1+dfsg-6
> > >
> > > The bug is still there. The upgrade of the qtbase-opensource-src
> > > packages to 5.10.1+dfsg-6 had no effect.
> >
> > Can you please check if this is still an issue with qtbase 5.11.2+dfsg-4?
>
> Sorry for the last reply. After unsetting QT_AUTO_SCREEN_SCALE_FACTOR,
> the bug still occurs in Debian/unstable.
>
> The bug has been fixed upstream a couple of days ago, but I haven't
> tested.
>

It has been fixed in 5.14, so it will take some time to get into unstable.
According to what I read the changes are many so I highly doubt or would be
backportable.

>

Bug#884956: HiDPI scaling is still broken with libqt5core5a 5.10.1+dfsg-6

[Vincent Lefevre]

Control: found 884956 5.11.3+dfsg1-4
Control: tags 884956 fixed-upstream

On 2018-11-13 15:49:24 +0300, Dmitry Shachnev wrote:
> Hi Vincent and all!
> 
> On Sun, May 06, 2018 at 11:09:09AM +0200, Vincent Lefevre wrote:
> > Control: reopen -1
> > Control: found -1 5.10.1+dfsg-6
> >
> > The bug is still there. The upgrade of the qtbase-opensource-src
> > packages to 5.10.1+dfsg-6 had no effect.
> 
> Can you please check if this is still an issue with qtbase 5.11.2+dfsg-4?

Sorry for the last reply. After unsetting QT_AUTO_SCREEN_SCALE_FACTOR,
the bug still occurs in Debian/unstable.

The bug has been fixed upstream a couple of days ago, but I haven't
tested.

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

Bug#899108: Bug#884956: HiDPI scaling is still broken with libqt5core5a 5.10.1+dfsg-6

[Dmitry Shachnev]

Hi Vincent and all!

On Sun, May 06, 2018 at 11:09:09AM +0200, Vincent Lefevre wrote:
> Control: reopen -1
> Control: found -1 5.10.1+dfsg-6
>
> The bug is still there. The upgrade of the qtbase-opensource-src
> packages to 5.10.1+dfsg-6 had no effect.

Can you please check if this is still an issue with qtbase 5.11.2+dfsg-4?

There have been some upstream changes in 5.11.x, plus I have backported
this commit [1] which may make things better.

[1]: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=5e6bbbc1b86905c4

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#884956: HiDPI scaling is still broken with libqt5core5a 5.10.1+dfsg-6

[Vincent Lefevre]

Control: reopen -1
Control: found -1 5.10.1+dfsg-6

The bug is still there. The upgrade of the qtbase-opensource-src
packages to 5.10.1+dfsg-6 had no effect.

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

Bug#884956: vlc: icons are too big

[Sebastian Ramacher]

Control: notfound -1 3.0.1-1

(This is a Qt bug, so removing incorrect found version.)

On 2018-03-02 20:10:30, Vincent Lefevre wrote:
> Control: found -1 3.0.1-1
> 
> On 2018-03-02 21:25:28 +0300, Boris Pek wrote:
> > VLC 3.0.1 has been released recently. There is interesting note in its 
> > [changelog]:
> > ...
> > Qt Interface:
> >  * Improve scaling on HiDPI displays
> > ...
> 
> I haven't seen any change.
> 
> I wonder which patch it is. I've only seen:
> 
>   
> http://git.videolan.org/?p=vlc/vlc-3.0.git;a=commitdiff;h=8f05b289e0f3efd3ac0aebf28c6f80a552d91dd8
> 
> but it is previous to the 3.0.0 release and seems to concern window
> resize only.

This change only affects the Windows build where vlc upstream patches Qt to fix
some HiDPI issues.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#884956: vlc: icons are too big

[Vincent Lefevre]

Control: found -1 3.0.1-1

On 2018-03-02 21:25:28 +0300, Boris Pek wrote:
> VLC 3.0.1 has been released recently. There is interesting note in its 
> [changelog]:
> ...
> Qt Interface:
>  * Improve scaling on HiDPI displays
> ...

I haven't seen any change.

I wonder which patch it is. I've only seen:

  
http://git.videolan.org/?p=vlc/vlc-3.0.git;a=commitdiff;h=8f05b289e0f3efd3ac0aebf28c6f80a552d91dd8

but it is previous to the 3.0.0 release and seems to concern window
resize only.

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

Bug#884956: vlc: icons are too big

[Boris Pek]

Hi,

VLC 3.0.1 has been released recently. There is interesting note in its 
[changelog]:
...
Qt Interface:
 * Improve scaling on HiDPI displays
...

Try this new version of VLC please to check if the bug is still reproducible.

[changelog] 
http://git.videolan.org/?p=vlc/vlc-3.0.git;a=blob;f=NEWS;hb=399713b542d29c81300d23a657fd2ec22bc927b6

Best wishes,
Boris

Bug#884956: Debian testing

[Diederik de Haas]

On donderdag 22 februari 2018 09:44:21 CET wm4 wrote:
> So much for testing being better for stability.

If you want stability you should use Debian Stable.

If you want to use Testing or Sid, you should expect that things can break 
*and* be able to cope with that. If you're not yet there, but willing to 
learn, there are resources for that (#debian-next f.e.) and you should learn 
your way around your package manager. If you don't want to upgrade to -12, you 
hold your packages at -10, it really isn't that hard.

Whining surely isn't helping anyone.

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

Bug#884956: Debian testing

[wm4]

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

[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?

Bug#884956: vlc: icons are too big

[Lisandro Damián Nicanor Pérez Meyer]

On 16 February 2018 at 11:26, Lisandro Damián Nicanor Pérez Meyer
 wrote:
> On 13 February 2018 at 07:34, Vincent Lefevre  wrote:
>> Control: retitled -1 Qt 5: HiDPI scaling is broken
>>
>> On 2018-02-13 10:11:45 +0100, Sebastian Ramacher wrote:
>>> … and QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to a workaround.
>>
>> I confirm. And this also fixes font size, e.g. for the menus (the font
>> was smaller than the one in the Gtk apps).
>>
>> This also avoids bug 884953 with the nVidia driver.
>
> Interesting. I'm currently trying to find the Fedora patch. Sadly I do
> not have any HiDPI monitor to test this.

Which is 
https://src.fedoraproject.org/rpms/qt5-qtbase/blob/master/f/qtbase-hidpi_scale_at_192.patch

I'll see to add it.

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

Bug#884956: vlc: icons are too big

[Lisandro Damián Nicanor Pérez Meyer]

On 13 February 2018 at 07:34, Vincent Lefevre  wrote:
> Control: retitled -1 Qt 5: HiDPI scaling is broken
>
> On 2018-02-13 10:11:45 +0100, Sebastian Ramacher wrote:
>> … and QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to a workaround.
>
> I confirm. And this also fixes font size, e.g. for the menus (the font
> was smaller than the one in the Gtk apps).
>
> This also avoids bug 884953 with the nVidia driver.

Interesting. I'm currently trying to find the Fedora patch. Sadly I do
not have any HiDPI monitor to test this.

Bug#884956: vlc: icons are too big

[Vincent Lefevre]

Control: retitled -1 Qt 5: HiDPI scaling is broken

On 2018-02-13 10:11:45 +0100, Sebastian Ramacher wrote:
> … and QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to a workaround.

I confirm. And this also fixes font size, e.g. for the menus (the font
was smaller than the one in the Gtk apps).

This also avoids bug 884953 with the nVidia driver.

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

Bug#884956: vlc: icons are too big

[Sebastian Ramacher]

On 2018-02-13 10:07:02, Sebastian Ramacher wrote:
> Control: reassign -1 libqt5core5a 5.9.2+dfsg-6
> Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-53022
> Control: severity -1 normal
> Control: tags -1 = upstream
> 
> On 2017-12-21 23:39:03, Vincent Lefevre wrote:
> > Package: src:vlc
> > Version: 3.0.0~rc2-1
> > Severity: minor
> > 
> > Icons appear to be too big (much bigger than the associated text).
> > I don't think this is intentional. VLC 2.x didn't have such a problem.
> > 
> > I've attached a screenshot of a part of the main window.
> > 
> > Just in case this matters, the configured Xft.dpi is 132, and I can
> > see in ".config/vlc/vlc-qt-interface.conf", in particular:
> 
> It seems to be a Qt bug (maybe related to QTBUG-53022). Fedora seems to carry 
> a
> patch for that (https://bugzilla.redhat.com/show_bug.cgi?id=1381828).

… and QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to a workaround.

Cheers

> 
> Cheers
> 
> > 
> > [FullScreen]
> > pos=@Point(1200 1732)
> > screen=@Rect(0 0 3200 1800)
> > wide=false
> > 
> > [MainWindow]
> > QtStyle=System's default
> > adv-controls=0
> > bgSize=@Size(100 30)
> > pl-dock-status=true
> > playlist-visible=true
> > playlistSize=@Size(600 300)
> > status-bar-visible=false
> > 
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable-debug
> >   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> > 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 4.14.0-1-amd64 (SMP w/8 CPU cores)
> > Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
> > (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages vlc depends on:
> > ii  vlc-bin  3.0.0~rc2-1
> > ii  vlc-l10n 3.0.0~rc2-1
> > ii  vlc-plugin-base  3.0.0~rc2-1
> > ii  vlc-plugin-qt3.0.0~rc2-1
> > ii  vlc-plugin-video-output  3.0.0~rc2-1
> > 
> > Versions of packages vlc recommends:
> > ii  vlc-plugin-notify  3.0.0~rc2-1
> > ii  vlc-plugin-samba   3.0.0~rc2-1
> > ii  vlc-plugin-skins2  3.0.0~rc2-1
> > ii  vlc-plugin-video-splitter  3.0.0~rc2-1
> > ii  vlc-plugin-visualization   3.0.0~rc2-1
> > 
> > vlc suggests no packages.
> > 
> > Versions of packages libvlc-bin depends on:
> > ii  libc62.25-5
> > ii  libvlc5  3.0.0~rc2-1
> > 
> > Versions of packages libvlc5 depends on:
> > ii  libc62.25-5
> > ii  libvlccore9  3.0.0~rc2-1
> > 
> > Versions of packages libvlc5 recommends:
> > ii  libvlc-bin  3.0.0~rc2-1
> > 
> > Versions of packages vlc-bin depends on:
> > ii  libc6   2.25-5
> > ii  libvlc-bin  3.0.0~rc2-1
> > ii  libvlc5 3.0.0~rc2-1
> > 
> > Versions of packages vlc-plugin-base depends on:
> > ii  liba52-0.7.4 0.7.4-19
> > ii  libarchive13 3.2.2-3.1
> > ii  libaribb24-0 1.0.3-1
> > ii  libasound2   1.1.3-5
> > ii  libass9  1:0.14.0-1
> > ii  libavahi-client3 0.7-3
> > ii  libavahi-common3 0.7-3
> > ii  libavc1394-0 0.5.4-4+b1
> > ii  libavcodec57 7:3.4.1-1+b1
> > ii  libavformat577:3.4.1-1+b1
> > ii  libavutil55  7:3.4.1-1+b1
> > ii  libbasicusageenvironment12017.10.28-2
> > ii  libbluray2   1:1.0.2-1
> > ii  libc62.25-5
> > ii  libcairo21.14.10-1
> > ii  libcddb2 1.3.2-5
> > ii  libchromaprint1  1.4.2-1
> > ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
> > ii  libdbus-1-3  1.12.2-1
> > ii  libdc1394-22 2.2.5-1
> > ii  libdca0  0.0.5-10
> > ii  libdvbpsi10  1.3.1-2
> > ii  libdvdnav4   5.0.3-3
> > ii  libdvdread4  5.0.3-2
> > ii  libebml4v5   1.3.5-2
> > ii  libfaad2 2.8.8-1
> > ii  libflac8 1.3.2-1
> > ii  libfontconfig1   2.12.6-0.1
> > ii  libfreetype6 2.6.3-3.2
> > ii  libfribidi0  0.19.7-2
> > ii  libgcc1  1:7.2.0-18
> > ii  libgcrypt20  1.8.1-4
> > ii  libglib2.0-0 2.54.2-3
> > ii  libgnutls30  3.5.16-1
> > ii  libgpg-error01.27-5
> > ii  libgroupsock82017.10.28-2
> > ii  libharfbuzz0b1.4.2-1
> > ii  libjpeg62-turbo  1:1.5.2-2+b1
> > ii  libkate1 0.4.1-7+b1
> > ii  

Bug#884956: vlc: icons are too big

[Sebastian Ramacher]

Control: reassign -1 libqt5core5a 5.9.2+dfsg-6
Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-53022
Control: severity -1 normal
Control: tags -1 = upstream

On 2017-12-21 23:39:03, Vincent Lefevre wrote:
> Package: src:vlc
> Version: 3.0.0~rc2-1
> Severity: minor
> 
> Icons appear to be too big (much bigger than the associated text).
> I don't think this is intentional. VLC 2.x didn't have such a problem.
> 
> I've attached a screenshot of a part of the main window.
> 
> Just in case this matters, the configured Xft.dpi is 132, and I can
> see in ".config/vlc/vlc-qt-interface.conf", in particular:

It seems to be a Qt bug (maybe related to QTBUG-53022). Fedora seems to carry a
patch for that (https://bugzilla.redhat.com/show_bug.cgi?id=1381828).

Cheers

> 
> [FullScreen]
> pos=@Point(1200 1732)
> screen=@Rect(0 0 3200 1800)
> wide=false
> 
> [MainWindow]
> QtStyle=System's default
> adv-controls=0
> bgSize=@Size(100 30)
> pl-dock-status=true
> playlist-visible=true
> playlistSize=@Size(600 300)
> status-bar-visible=false
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.14.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages vlc depends on:
> ii  vlc-bin  3.0.0~rc2-1
> ii  vlc-l10n 3.0.0~rc2-1
> ii  vlc-plugin-base  3.0.0~rc2-1
> ii  vlc-plugin-qt3.0.0~rc2-1
> ii  vlc-plugin-video-output  3.0.0~rc2-1
> 
> Versions of packages vlc recommends:
> ii  vlc-plugin-notify  3.0.0~rc2-1
> ii  vlc-plugin-samba   3.0.0~rc2-1
> ii  vlc-plugin-skins2  3.0.0~rc2-1
> ii  vlc-plugin-video-splitter  3.0.0~rc2-1
> ii  vlc-plugin-visualization   3.0.0~rc2-1
> 
> vlc suggests no packages.
> 
> Versions of packages libvlc-bin depends on:
> ii  libc62.25-5
> ii  libvlc5  3.0.0~rc2-1
> 
> Versions of packages libvlc5 depends on:
> ii  libc62.25-5
> ii  libvlccore9  3.0.0~rc2-1
> 
> Versions of packages libvlc5 recommends:
> ii  libvlc-bin  3.0.0~rc2-1
> 
> Versions of packages vlc-bin depends on:
> ii  libc6   2.25-5
> ii  libvlc-bin  3.0.0~rc2-1
> ii  libvlc5 3.0.0~rc2-1
> 
> Versions of packages vlc-plugin-base depends on:
> ii  liba52-0.7.4 0.7.4-19
> ii  libarchive13 3.2.2-3.1
> ii  libaribb24-0 1.0.3-1
> ii  libasound2   1.1.3-5
> ii  libass9  1:0.14.0-1
> ii  libavahi-client3 0.7-3
> ii  libavahi-common3 0.7-3
> ii  libavc1394-0 0.5.4-4+b1
> ii  libavcodec57 7:3.4.1-1+b1
> ii  libavformat577:3.4.1-1+b1
> ii  libavutil55  7:3.4.1-1+b1
> ii  libbasicusageenvironment12017.10.28-2
> ii  libbluray2   1:1.0.2-1
> ii  libc62.25-5
> ii  libcairo21.14.10-1
> ii  libcddb2 1.3.2-5
> ii  libchromaprint1  1.4.2-1
> ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
> ii  libdbus-1-3  1.12.2-1
> ii  libdc1394-22 2.2.5-1
> ii  libdca0  0.0.5-10
> ii  libdvbpsi10  1.3.1-2
> ii  libdvdnav4   5.0.3-3
> ii  libdvdread4  5.0.3-2
> ii  libebml4v5   1.3.5-2
> ii  libfaad2 2.8.8-1
> ii  libflac8 1.3.2-1
> ii  libfontconfig1   2.12.6-0.1
> ii  libfreetype6 2.6.3-3.2
> ii  libfribidi0  0.19.7-2
> ii  libgcc1  1:7.2.0-18
> ii  libgcrypt20  1.8.1-4
> ii  libglib2.0-0 2.54.2-3
> ii  libgnutls30  3.5.16-1
> ii  libgpg-error01.27-5
> ii  libgroupsock82017.10.28-2
> ii  libharfbuzz0b1.4.2-1
> ii  libjpeg62-turbo  1:1.5.2-2+b1
> ii  libkate1 0.4.1-7+b1
> ii  liblirc-client0  0.10.0-2+b1
> ii  liblivemedia61   2017.10.28-2
> ii  liblua5.2-0  5.2.4-1.1+b2
> ii  libmad0  0.15.1b-8.1
> ii  libmatroska6v5   1.4.8-1.1
> ii  libmicrodns0 0.0.8-1
> ii  libmpcdec6   

Bug#884956: vlc: icons are too big

[Sebastian Ramacher]

On 2017-12-21 23:39:03, Vincent Lefevre wrote:
> Package: src:vlc
> Version: 3.0.0~rc2-1
> Severity: minor
> 
> Icons appear to be too big (much bigger than the associated text).
> I don't think this is intentional. VLC 2.x didn't have such a problem.

If you think this is wrong, I encourage you to discuss this with upstream. Their
bug tracker is at https://trac.videolan.org/vlc.

Cheers

> I've attached a screenshot of a part of the main window.
> 
> Just in case this matters, the configured Xft.dpi is 132, and I can
> see in ".config/vlc/vlc-qt-interface.conf", in particular:
> 
> [FullScreen]
> pos=@Point(1200 1732)
> screen=@Rect(0 0 3200 1800)
> wide=false
> 
> [MainWindow]
> QtStyle=System's default
> adv-controls=0
> bgSize=@Size(100 30)
> pl-dock-status=true
> playlist-visible=true
> playlistSize=@Size(600 300)
> status-bar-visible=false
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.14.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages vlc depends on:
> ii  vlc-bin  3.0.0~rc2-1
> ii  vlc-l10n 3.0.0~rc2-1
> ii  vlc-plugin-base  3.0.0~rc2-1
> ii  vlc-plugin-qt3.0.0~rc2-1
> ii  vlc-plugin-video-output  3.0.0~rc2-1
> 
> Versions of packages vlc recommends:
> ii  vlc-plugin-notify  3.0.0~rc2-1
> ii  vlc-plugin-samba   3.0.0~rc2-1
> ii  vlc-plugin-skins2  3.0.0~rc2-1
> ii  vlc-plugin-video-splitter  3.0.0~rc2-1
> ii  vlc-plugin-visualization   3.0.0~rc2-1
> 
> vlc suggests no packages.
> 
> Versions of packages libvlc-bin depends on:
> ii  libc62.25-5
> ii  libvlc5  3.0.0~rc2-1
> 
> Versions of packages libvlc5 depends on:
> ii  libc62.25-5
> ii  libvlccore9  3.0.0~rc2-1
> 
> Versions of packages libvlc5 recommends:
> ii  libvlc-bin  3.0.0~rc2-1
> 
> Versions of packages vlc-bin depends on:
> ii  libc6   2.25-5
> ii  libvlc-bin  3.0.0~rc2-1
> ii  libvlc5 3.0.0~rc2-1
> 
> Versions of packages vlc-plugin-base depends on:
> ii  liba52-0.7.4 0.7.4-19
> ii  libarchive13 3.2.2-3.1
> ii  libaribb24-0 1.0.3-1
> ii  libasound2   1.1.3-5
> ii  libass9  1:0.14.0-1
> ii  libavahi-client3 0.7-3
> ii  libavahi-common3 0.7-3
> ii  libavc1394-0 0.5.4-4+b1
> ii  libavcodec57 7:3.4.1-1+b1
> ii  libavformat577:3.4.1-1+b1
> ii  libavutil55  7:3.4.1-1+b1
> ii  libbasicusageenvironment12017.10.28-2
> ii  libbluray2   1:1.0.2-1
> ii  libc62.25-5
> ii  libcairo21.14.10-1
> ii  libcddb2 1.3.2-5
> ii  libchromaprint1  1.4.2-1
> ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
> ii  libdbus-1-3  1.12.2-1
> ii  libdc1394-22 2.2.5-1
> ii  libdca0  0.0.5-10
> ii  libdvbpsi10  1.3.1-2
> ii  libdvdnav4   5.0.3-3
> ii  libdvdread4  5.0.3-2
> ii  libebml4v5   1.3.5-2
> ii  libfaad2 2.8.8-1
> ii  libflac8 1.3.2-1
> ii  libfontconfig1   2.12.6-0.1
> ii  libfreetype6 2.6.3-3.2
> ii  libfribidi0  0.19.7-2
> ii  libgcc1  1:7.2.0-18
> ii  libgcrypt20  1.8.1-4
> ii  libglib2.0-0 2.54.2-3
> ii  libgnutls30  3.5.16-1
> ii  libgpg-error01.27-5
> ii  libgroupsock82017.10.28-2
> ii  libharfbuzz0b1.4.2-1
> ii  libjpeg62-turbo  1:1.5.2-2+b1
> ii  libkate1 0.4.1-7+b1
> ii  liblirc-client0  0.10.0-2+b1
> ii  liblivemedia61   2017.10.28-2
> ii  liblua5.2-0  5.2.4-1.1+b2
> ii  libmad0  0.15.1b-8.1
> ii  libmatroska6v5   1.4.8-1.1
> ii  libmicrodns0 0.0.8-1
> ii  libmpcdec6   2:0.1~r495-1+b1
> ii  libmpeg2-4   0.5.1-8
> ii  libmpg123-0  1.25.8-1
> ii  libmtp9  1.1.13-1
> ii  libncursesw5  

Bug#884956: vlc: icons are too big

[Vincent Lefevre]

Package: src:vlc
Version: 3.0.0~rc2-1
Severity: minor

Icons appear to be too big (much bigger than the associated text).
I don't think this is intentional. VLC 2.x didn't have such a problem.

I've attached a screenshot of a part of the main window.

Just in case this matters, the configured Xft.dpi is 132, and I can
see in ".config/vlc/vlc-qt-interface.conf", in particular:

[FullScreen]
pos=@Point(1200 1732)
screen=@Rect(0 0 3200 1800)
wide=false

[MainWindow]
QtStyle=System's default
adv-controls=0
bgSize=@Size(100 30)
pl-dock-status=true
playlist-visible=true
playlistSize=@Size(600 300)
status-bar-visible=false

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vlc depends on:
ii  vlc-bin  3.0.0~rc2-1
ii  vlc-l10n 3.0.0~rc2-1
ii  vlc-plugin-base  3.0.0~rc2-1
ii  vlc-plugin-qt3.0.0~rc2-1
ii  vlc-plugin-video-output  3.0.0~rc2-1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  3.0.0~rc2-1
ii  vlc-plugin-samba   3.0.0~rc2-1
ii  vlc-plugin-skins2  3.0.0~rc2-1
ii  vlc-plugin-video-splitter  3.0.0~rc2-1
ii  vlc-plugin-visualization   3.0.0~rc2-1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.25-5
ii  libvlc5  3.0.0~rc2-1

Versions of packages libvlc5 depends on:
ii  libc62.25-5
ii  libvlccore9  3.0.0~rc2-1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.0~rc2-1

Versions of packages vlc-bin depends on:
ii  libc6   2.25-5
ii  libvlc-bin  3.0.0~rc2-1
ii  libvlc5 3.0.0~rc2-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-19
ii  libarchive13 3.2.2-3.1
ii  libaribb24-0 1.0.3-1
ii  libasound2   1.1.3-5
ii  libass9  1:0.14.0-1
ii  libavahi-client3 0.7-3
ii  libavahi-common3 0.7-3
ii  libavc1394-0 0.5.4-4+b1
ii  libavcodec57 7:3.4.1-1+b1
ii  libavformat577:3.4.1-1+b1
ii  libavutil55  7:3.4.1-1+b1
ii  libbasicusageenvironment12017.10.28-2
ii  libbluray2   1:1.0.2-1
ii  libc62.25-5
ii  libcairo21.14.10-1
ii  libcddb2 1.3.2-5
ii  libchromaprint1  1.4.2-1
ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
ii  libdbus-1-3  1.12.2-1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.5-10
ii  libdvbpsi10  1.3.1-2
ii  libdvdnav4   5.0.3-3
ii  libdvdread4  5.0.3-2
ii  libebml4v5   1.3.5-2
ii  libfaad2 2.8.8-1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.6.3-3.2
ii  libfribidi0  0.19.7-2
ii  libgcc1  1:7.2.0-18
ii  libgcrypt20  1.8.1-4
ii  libglib2.0-0 2.54.2-3
ii  libgnutls30  3.5.16-1
ii  libgpg-error01.27-5
ii  libgroupsock82017.10.28-2
ii  libharfbuzz0b1.4.2-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libkate1 0.4.1-7+b1
ii  liblirc-client0  0.10.0-2+b1
ii  liblivemedia61   2017.10.28-2
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-8.1
ii  libmatroska6v5   1.4.8-1.1
ii  libmicrodns0 0.0.8-1
ii  libmpcdec6   2:0.1~r495-1+b1
ii  libmpeg2-4   0.5.1-8
ii  libmpg123-0  1.25.8-1
ii  libmtp9  1.1.13-1
ii  libncursesw5 6.0+20171125-1
ii  libnfs8  1.11.0-2
ii  libogg0  1.3.2-1+b1
ii  libopenmpt-modplug1  0.3.4-1
ii  libopus0 1.2.1-1
ii  libpng16-16  1.6.34-1
ii  libpostproc547:3.4.1-1+b1
ii  libprotobuf-lite10   3.0.0-9.1
ii  libpulse0