GNU bug report logs - #75936
monitor width reporting

Previous Next

Full log

Message #26 received at 75936 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, david <david <at> ngdr.net>, 75936 <at> debbugs.gnu.org
Subject: Re: bug#75936: monitor width reporting
Date: Sun, 02 Feb 2025 14:59:29 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

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

Please excuse my ignorance, but where does garbled display output come
into the picture?

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

No, but it's an exceedingly simple oversight that can be addressed thus:

diff --git a/configure.ac b/configure.ac
index 9db1f07d7fc..55a4be1a0ee 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7481,7 +7481,7 @@ AC_DEFUN
  HARFBUZZ IMAGEMAGICK JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 \
  M17N_FLT MODULES NATIVE_COMP NOTIFY NS OLDXMENU PDUMPER PGTK PNG RSVG SECCOMP \
  SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER \
- UNEXEC WEBP X11 XAW3D XDBE XFT XIM XINPUT2 XPM XWIDGETS X_TOOLKIT \
+ UNEXEC WEBP X11 XAW3D XDBE XFT XIM XINPUT2 XPM XRANDR XWIDGETS X_TOOLKIT \
  ZLIB; do
 
     case $opt in

I cannot imagine why this was not installed at the outset, because all
optional features are meant to be enumerated here...

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

"or Emacs was built with the GTK toolkit, in both cases provided that
the X server also supports XRandR or Xinerama."

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

Otherwise, this is correct.  I would clarify that "the attributes
returned in this case represent the dimensions of the X server screen".

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

I should also mention that the lion's share of X configurations feature
a single monitor encompassing the whole of the screen.  So that the
fallback information is likely to be correct under a substantial
majority of configurations.

Previous Next

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