GNU bug report logs - #75936
monitor width reporting

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: "david" <david <at> ngdr.net>
Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 75936 <at> debbugs.gnu.org
Subject: bug#75936: monitor width reporting
Date: Sun, 02 Feb 2025 08:19:58 +0200

> From: "david" <david <at> ngdr.net>
> Date: Sat, 01 Feb 2025 13:21:17 -0700
> Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 75936 <at> debbugs.gnu.org
> 
> > If one of the builds is with XRandR and the other without, then the
> > differences in the results are expected, and this is not a bug.
> 
> I am rather shocked that you do not see this as a bug.  Personally, I see
> it as definitional.  Two apparently identical builds that give different
> results for display geometry does not indicate a bug?  How about garbled
> output, displayed to a remote user, simply because the user's build is
> different, albeit not advertised as such, from the software creator's
> build?  That sort of performance is not good for the reputation of Emacs I
> can assure you.

The XRandR extension is _required_ for providing accurate information
about multiple system monitors on X.  Emacs should work fine without
it, and should not produce garbled output, but accurate information
about the dimensions of the system monitors is not available to Emacs
without XRandR.  When built with neither XRandR nor Xinerama, Emacs
produces information for the "combined screen", i.e., it treats
multiple monitors as if they together formed a single monitor.

> At the very least, the build information should indicate the difference.

Agreed.  Po Lu, do we have some indication of whether XRandR was used
in the recorded features that report-emacs-bug shows?  If not, can we
add that?

> I think it is worth pointing out that you did not know why there is a
> problem, even with the debug output in front of you.

I personally am not an expert on X configurations, so I didn't know.
Po Lu, who knows much more about that, saw the reason right away.

> Fortunately someone else had the right knowledge.  Given that, it
> seems to me that to assert "the differences in the results are
> expected" is somewhat disingenuous.

Given the information at hand at this moment, the results are indeed
expected.  There was no intent to imply that you personally should
have known that, only that this is expected given the way Emacs was
built.

> Also, I think that it is worth pointing out that I have absolutely zero
> knowledge of XRandR, just like most people.  I have no idea how it was
> involved in a build; I am confident that I did not choose to use it, unless
> directed to it by the output from configure.  There is a mention of
> information sources, including XRandR, in *note:(elisp)Multiple Terminals,
> otherwise the mention does not help.

The configure script produces a build with XRandR if it is available
on the system where Emacs is built, and omits it otherwise.

> A better solution than only providing, important, build information would
> be also to address comprehension problems such as the combination of the
> output of (display-screens) and the geometry provided in the output of
> (frame-monitor-attributes).  The documentation "This function returns the
> attributes of the physical monitor dominating (see above) FRAME, which
> defaults to the selected frame." is misleading when the actual information
> on a two monitor setup is the attributes of both monitors, reported as one
> combined-screen by (display-screens), not, in fact, the attributes of the
> dominating monitor.

I agree that we should document the prerequisites for these
capabilities better.

Po Lu, is the following correct?

 . accurate information about multiple monitors is available only if
   Emacs was built with XRandR or Xinerama, and was not built with the
   GTK toolkit
 . if the 'source' field of the value returned by
   display-monitor-attributes-list is "fallback", it means neither
   XRandR nor Xinerama are used, and the monitor information is for
   the "combined screen", as if all the physical monitors formed a
   single combined monitor; the results could be inaccurate if the
   system has more than a single physical monitor connected

> So, leaving out a lot of detail, it comes back to the build: with or
> without XRandR.  Without is inadequate; it turns out that build information
> is not important, it is vital.  Alternatively, when writing software it is
> necessary to rely on non-software knowledge, e.g., usual screen sizes.  The
> latter is what I do now: since the screen height is constant (assumption)
> the screen aspect ratio (what I am trying to establish) is not likely to be
> less than 1.24 nor more than 2.5.  Since the reported width changes by a
> factor of 2 it is not difficult to get it right.  But it will go wrong at
> some point.
> 
> So you and I have different definitions of a bug.  I see why you take the
> view you do; but it is narrow and unhelpful to someone writing user
> software.  Crashing Emacs software is a bug for me.  Flagging build
> characteristics at least gives a warning.

Emacs should not crash if it was compiled without XRandR, I agree.  I
don't think it crashed here.

Emacs supports building with XRandR and Xinerama since more than 10
years ago.  I suppose we expect that by now these libraries are
available on most X systems, so their absence is not notably mentioned
in the docs.  I will see about improving this aspect, thanks for
pointing that out.

IOW, I think this is a documentation bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.