[Development] Updated high-DPI support for Qt 5.14

[Thiago Macieira]

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.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products