Variable DPI according resolution AND screen size

[Carsten Haitzler]

On Mon, 17 Feb 2020 17:09:06 +0100 Luis Felipe Sánchez-Escobar Retamar
<felipe.retamar at gmail.com> said:

> Thank you for your time Carsten,
> 
> What I mean is that when you install a Desktop Environment in Linux you
> might fight with differents configuration files to get a DPI suitable for
> your screen. You just have to see the Arch Wiki for HiDPI
> <https://wiki.archlinux.org/index.php/HiDPI>. I think this should be easier.

Welcome to the world of choice. Choice of desktop/WM, choice of display system,
choice of toolkit. Opening things up to allow innovation and people to do
things allows for fragmentation and many permutations of it. Also almost all
the advice is wrong - it tells you to set the DPI where actually toolkits/apps
should just support a scaling factor instead as DPI has not changed. DPI is a
fixed value for any display medium + resolution used. You never should SET DPI.
it's a property of the display. You should be setting some "make it bigger" or
"make it smaller" value. Only recently have toolkits been getting these scale
factors. As you saw Gnome/GTK+ gained it then limited it to integer amounts
only. EFL got a scaling factor years before and uses a floating point value so
1.376 is perfectly fine for EFL. I haven't followed what Qt has been doing.

> Some DE have the option to change between "normal" DPI and HiDPI like
> Gnome, but not has fractional scaling or is an experimental feature. Other
> DE hasn't got the possibility to change DPI or it doesn't apply in all
> applications.

That's a Gnome issue. Not providing fractional scaling. A policy decision on
their part (I do believe they may have changed that now?). Other toolkits and
desktops can do it.

> Maybe the problem in not in Xorg, or not only, but I repeat I think
> DPI/PPI/whatever scalation should have an standar and in most cases the DPI
> configuration from the link i posted is really useful.

And as was my point: X provides all the mechanisms to do anything at all. It's
up to software built on top to provide the policy. i.e WM/DE/toolkits etc. etc.
Xorg exposes all the DPI information for every screen. As I even mentioned
you can use xrandr to force scaling at the output level thus making DPI
constant across all screens from an "application point of view" and the
resulting image is scaled for display. Won't work too nicely on low DPI, but on
higher DPI, it might be OK.

Because there isn't a (good) mechanism to scale input, it's all or nothing for
a screen in X. It's all done on the screen as a whole or all up to the client
side to figure out.

This is why Wayland is a good thing. The compositor can do anything it wants
with input, like scale it, so it can scale apps window by window for outputs.
No one is really that into trying to make X work because everything that can be
done, has been done and it's up to the client side, not X side of things. In
the Wayland universe, the compositor can do a lot more to patch things
over client by client and for example scale "dumb" clients up and down on
displays without a native API, and for those able to handle scaling properly,
display them at a native resolution.

> Thanks,
> 
> Felipe.
> 
> 
> 
> El lun., 17 feb. 2020 a las 11:04, Carsten Haitzler (<raster at rasterman.com>)
> escribió:
> 
> > On Sat, 15 Feb 2020 00:10:22 +0100 Luis Felipe Sánchez-Escobar Retamar
> > <felipe.retamar at gmail.com> said:
> >
> > > Hello all,
> > >
> > > Today we have a lot of differents screens, in both aspects size and
> > > resolution.
> > > And a fixed DPI of 96 has no sense.
> >
> > This is absolutely not true and has not been for a very long time (a fixed
> > DPI). Sure - for the old x multi-screen (not xrandr) setup and api each
> > SCREEN
> > had its own DPI. You used to have multiple root windows and screen with
> > each
> > their own DPI. If you still used X in this way you'd have different DPIs
> > per
> > screen. Xrandr/xinerama merged all screen into a single screen/root window
> > negating that design in return for convenience, and xrandr then exposed
> > the DPI
> > for different regions of the same root window to account for that.
> >
> > > I think that could be a good thing to do an automatic adjustment of DPI
> > > with the algorithm like in http://dpi.lv/
> > > Implemented directly in X
> > >
> > > And not depends on how each desktop environment manage DPI
> >
> > X already exposes the DPI of each and every screen via xrandr. It has done
> > its
> > job. X is about mechanism, not policy (primarily - debates in corners
> > rage). The
> > policy is then is implemented by desktops/WMs and whatever other tooling a
> > user
> > chooses.
> >
> > As an aside, I'll actually disagree with your link. It's not DPI or PPI.
> > It's
> > PPD. Pixels Per Degree of visual field. A 20m high monitor/projection at
> > the
> > other end of a large room has very very very low DPI, but this is
> > irrelevant to
> > the person sitting at the back of the room far away, whereas a phone held
> > up
> > very close to your eyes is different to a tablet, laptop, desktop etc. due
> > to
> > distance between eyes and screen. What matters is how many pixels per
> > degree.
> > So in then end this is all just a continuation of the "we're emulating
> > paper
> > and a computer is a device to drive a printer as final output" model when
> > we've
> > already moved beyond it in various ways. In the end the only thing that
> > makes
> > sense is a "this is too big/small - make it smaller/bigger" slider and
> > users
> > set it up because that also then accounts for people with 20/20 or better
> > vision or those who need a lot of visual helpers (glasses etc.) and have
> > poor
> > eyesight. For large rooms with large audiences spread through them then
> > you have
> > to make a call for "worst case" (people in the back) and go for that.
> >
> > You also can use xrandr's scale/transform options to have X force scaling
> > at
> > the output level (comes with upsides and downsides - definitely downsides
> > in
> > performance, but upsides in simplicity for apps and consistent physical
> > surface sizing if used right).
> >
> > So in the end you leave it to higher level software to figure it out
> > because
> > that's the only way to solve this with consistence AND performance AND TV
> > on
> > the other side of living room vs projector at other end of presentation
> > hall vs
> > monitor vs. phone etc. use cases.
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > Carsten Haitzler - raster at rasterman.com
> >
> >


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com