[Development] Updated high-DPI support for Qt 5.14

[Allan Sandfeld Jensen]

On Thursday, 26 September 2019 21:07:38 CEST Thiago Macieira wrote:
> On Thursday, 26 September 2019 08:03:32 PDT Edward Welbourne wrote:
> > >>>> If possible, I’d like us to move away from relying on setting
> > >>>> environment
> > >>>> variables, and/or switch to specifying per-screen DPI instead of a
> > >>>> scale
> > >>>> factor.
> > 
> > On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote:
> > >>> Sure, but where, on X11?
> > 
> > On Thursday, 26 September 2019 00:08:34 PDT Allan Sandfeld Jensen wrote:
> > >> xrandr?
> > 
> > Thiago Macieira (26 September 2019 16:47)
> > 
> > > That's not per screen. So my question stands.
> > 
> > For give a simple non-graphics-expert's probably dumb question:
> > IIUC, xrandr is per-display (as in X DISPLAY values).
> > How is that distinct from per-screen ?
> 
> Ok, let's be specific about terms:
> 
> * display: the X display, like :0, :1, localhost:11
> * screen: the sub-display X screen, like :0.0, :0.1. Anything besides "0"
> has probably been broken for over 20 years.
> * output or monitor: the multiple connections that xrandr can manipulate
> 
> xrandr can set a lot of parameters for each output, most frequently the
> video mode, refresh rate and rotation. It can set a scale factor but this
> is a SW scaler that applies to all pixels. You don't get to opt out of it
> and display at highdpi yourself.
> 
> It can also set the full X's DPI mode. X only knows a single DPI for all of
> its outputs.
> 
> Note the --help output and the indentations:
> usage: xrandr [options]
>   where options are:
>   --display <display> or -d <display>
>   --help
>   -o <normal,inverted,left,right,0,1,2,3>
>             or --orientation <normal,inverted,left,right,0,1,2,3>
>   -q        or --query
>   -s <size>/<width>x<height> or --size <size>/<width>x<height>
>   -r <rate> or --rate <rate> or --refresh <rate>
>   -v        or --version
>   -x        (reflect in x)
>   -y        (reflect in y)
>   --screen <screen>
>   --verbose
>   --current
>   --dryrun
>   --nograb
>   --prop or --properties
>   --fb <width>x<height>
>   --fbmm <width>x<height>
>   --dpi <dpi>/<output>
>   --output <output>
>       --auto
>       --mode <mode>
>       --preferred
>       --pos <x>x<y>
>       --rate <rate> or --refresh <rate>
>       --reflect normal,x,y,xy
>       --rotate normal,inverted,left,right
>       --left-of <output>
>       --right-of <output>
>       --above <output>
>       --below <output>
>       --same-as <output>
>       --set <property> <value>
>       --scale <x>[x<y>]
>       --scale-from <w>x<h>
>       --transform <a>,<b>,<c>,<d>,<e>,<f>,<g>,<h>,<i>
>       --filter nearest,bilinear
>       --off
>       --crtc <crtc>
>       --panning <w>x<h>[+<x>+<y>[/<track:w>x<h>+<x>+<y>[/<border:l>/<t>/<r>/
> <b>]]]
>       --gamma <r>[:<g>:<b>]
>       --brightness <value>
>       --primary
> [... more ...]
> 
> There's a "/<output>" in the --dpi switch, but last time I tried that, it
> affected both outputs. Granted, that was several years ago, as highdpi has
> been working fine for me for that long, and granted it might have been
> broken applications. If it's the latter, then we need to cope with them
> anyway and therefore setting per-output DPI is not adviseable.
> 
> I think we should consider HighDPI on X an evolutionary dead-end. Don't try
> to innovate, just keep what's working working.

Well, you can set the physical size, which relative to the resolution is what 
Qt uses to calculate the per-screen dpi on XCB.

But, yes it is more interesting what we can do moving forward more 
generically.

'Allan