Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
On Sunday 08 April 2018 19:22:28 Giuseppe Bilotta wrote: > On Sun, Apr 8, 2018 at 4:33 PM, Pali Rohárwrote: > > 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.ro...@gmail.com signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
On Sun, Apr 8, 2018 at 4:33 PM, Pali Rohárwrote: > 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 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
On Wednesday 04 April 2018 11:12:53 Adam Jackson wrote: > code exists that depends on xdpyinfo's output. Exactly and that code expects that xdpyinfo provides correct output. But it is broken since XServer for RandR 1.2+ capable screens started reporting fixed values. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
On Wednesday 04 April 2018 16:00:39 Adam Jackson wrote: > On Wed, 2018-04-04 at 21:30 +0200, Giuseppe Bilotta wrote: > > On Wed, Apr 4, 2018 at 5:12 PM, Adam Jacksonwrote: > > > On Tue, 2018-04-03 at 22:15 +0200, Pali Rohár wrote: > > > > Gently reminder of this patch. Can you comment/review it? > > > > > > Nack. The whole point of (that part of) xdpyinfo is to show you what > > > was sent in the initial connection block. xrandr already exists, and > > > code exists that depends on xdpyinfo's output. > > > > Would it make sense to add the output from RANDR via an explicit `-ext > > RANDR` query similar to what is already done for XINERAMA, > > XInputExtension, etc? > > If it's going to be in xdpyinfo at all - and I kinda don't think it > needs to be, given xrandr already exists, but I don't insist on that - > then yes, it should be behind -ext RANDR. > > - ajax The main problem is that majority of users use xdpyinfo for getting DPI of their monitors. And xdpyinfo reports totally bogus values. There are plenty of bugs and lot of reports about this problem. Really what is the purpose of reporting bogus values? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel