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