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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
