Variable DPI according resolution AND screen size

[Luis Felipe Sánchez-Escobar Retamar]

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.

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.

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.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20200217/df6bf6a0/attachment.htm>