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

[Pali Rohár]

On Sunday 08 April 2018 19:22:28 Giuseppe Bilotta wrote:
> 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.

For users as human readable output from xdpyinfo, those values are
bogus. For users it does not matter how xdpyinfo obtain those values.
Just that it provides values which do not match reality.

I understand that those values comes from X server and xdpyinfo just
print what it receive. But for end-users of xdpyinfo this is really
irrelevant. That tool worked correctly prior changes in X server (do not
remember version).

> > There are plenty of bugs and lot of reports about this problem.
> 
> Because people are using the wrong tool.

I agree, but you can look at it from other side. This tool worked with
older X servers. If it is stopped working with new X servers, then
either tool itself should write information about it or do not report
those values at all.

Providing wrong information without any warning either in --help,
manpage or in stdout is really the worst solution.

> > 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).

The main problem is that this is not documented, nor written anywhere.
And output of xdpyinfo does not looks like core information for
end-users.

What end user reads? He sees resolution (which for with the most common
variant for one monitor) matches what he has configured and the he sees
DPI which does not match his monitor. So it is fully bogus for him.

> Now why does core report bogus values by default?

I understand reasons, for multimontitor setups with different DPIs
function DisplayWidthMM() and DisplayHeightMM() report meaningless
values (or at least values which should not be used for anything in
"correctly" written new applications).

> 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.

Agree.

> 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.

Ok, it makes sense to retrieve this information, but for sure it should
not be used by new applications, scripts and also users to retrieve DPI.

But main problem is that xdpyinfo does not look like for end-users that
it reports "legacy" values which end-users should not read for xrandr
1.2+ display.

> 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).

Those are separate issues, which are really out-of-scope of this
discussion. Personally I like idea that DisplayWidthMM() and
DisplayHeightMM() are calculated to 96 DPI as 96 DPI is sane default for
legacy applications. And special case for one monitor setup is bad
because it would change behavior of applications when more then one
monitor is connected.

-- 
Pali Rohár
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180408/27224e59/attachment.sig>