[PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

[Giuseppe Bilotta]

On Sun, Apr 8, 2018 at 4:33 PM, Pali Rohár <pali.rohar at gmail.com> wrote:
> The main problem is that majority of users use xdpyinfo for getting DPI
> of their monitors.

And in the case of multiple monitors, they'll have to get used to
using `xdpyinfo -ext RANDR`, provided support for that information is
offered this way. I think that's a good compromise between backwards
compatibility and providing the correct information.

> And xdpyinfo reports totally bogus values.

The values reported by xdpyinfo aren't bogus, they are what the core
protocol is providing.

> There are plenty of bugs and lot of reports about this problem.

Because people are using the wrong tool.

> Really what is the purpose of reporting bogus values?

As mentioned, the purpose of xdpyinfo is to report what the core
protocol reports (modulo use of the -ext flag and related ones).

Now why does core report bogus values by default?

The root of the issue is that in the case of multiple monitors with
potentially inconsistent DPI values, the core protocol value is
ambiguous at best. It also has the downside that its value is only
communicated at connection time, so it doesn't dynamically change even
when the circumstances change (e.g. resolution change, move to a
different output with a different DPI, etc). Clients need to be aware
of the possibilities that different outputs may have different DPI
values, and that the values can change, and that requires RANDR
support and listening to the appropriate change notification masks.

So it is important that xdpyinfo keeps reporting what is reporting
because (1) it's its purpose and (2) it's the only way to get what
legacy (non-RANDR-aware) clients get.

Now one could argue that in the case of single output X11 could
automatically set the DPI to the one of the only connected output
(something I actually agree with), but that's (a) a separate issue and
(b) not without its downsides (e.g. should it automatically change
whenever the output changes? what should be done when a new output
gets connected? what should be done when an output gets disconnected
and we're left with one output again? etc).


-- 
Giuseppe "Oblomov" Bilotta