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

[Giuseppe Bilotta]

On Sun, Apr 8, 2018 at 8:25 PM, Pali Rohár <pali.rohar at gmail.com> wrote:
> On Sunday 08 April 2018 19:22:28 Giuseppe Bilotta wrote:
>> 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).

If your issue is with the default DPI reported by the X server, that's
the thing you should be fixing,
not what xdpyinfo is reporting.

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

There is no other side. The tool still work as intended regardless of
the X server release, the information it provides is still exactly the
same, and as correct as it used to be —in the sense that it matches
exactly what the server claims. Users using it for a different purpose
fall in the category of this relevant XKCD https://xkcd.com/1172/

Again, your issue isn't what xdpyinfo reports, but what the _server_
reports, and you're trying to fix it in the wrong place.

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

If you feel that the man page and usage help text should better
clarify that all shown values are what the X core protocol reports,
modulo -ext option usage, that can be fixed.

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

And as above, xdpyinfo is not where this should be fixed.

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

And that's why the solution to this is to put support for the RANDR
extension in xdpyinfo the correct way (i.e. accessible with -ext
RANDR), and teach users and scripts to rely on that information as
appropriate.

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

But that's the core of the issue: xdpyinfo reporting the core value
when there are two monitors and the monitor value when there is a
single one would be no less inconsistent.

The only consistent solution  is for xdpyinfo to keep working as
designed, provide the RANDR data via -ext RANDR, consistently with the
rest, and teach users and script to use that information when
possible.

Changes to what the core protocol should report by default remain a
separate matter, which may be worth discussing, but which remains
independent from the scope of this patch.


-- 
Giuseppe "Oblomov" Bilotta