GNU bug report logs - #75936
monitor width reporting

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75936 in the body.
You can then email your comments to 75936 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "david" <david <at> ngdr.net>
To: bug-gnu-emacs <at> gnu.org
Subject: monitor width reporting
Date: Wed, 29 Jan 2025 17:03:39 -0700

This is a bug that caused me some trouble; but mainly it is FYI.  The physical
arrangement is a laptop, which has a 4K screen, driving a single 4K screen.  I
get (still and always) the different results below from two different Emacs
builds.

The items below are:

A: code from a startup file; the messages are debug stuff, normally absent, the
   intention behind the code is to compute the aspect ratio of a single monitor.

B and C: output from two different Emacs builds, see ned and nut directories.
         The different widths matter to me because I am computing a ratio that
         later wreak havoc 8-(  The creation dates probably matter to you.
         Other than the dates I see no way to differentiate between the builds.

 A
  ;; Probably this is not the aspect ratio of the full screen, probably the window manager will keep
  ;; some of the screen for itself.
  (defconst  .emacs-monitor-aspect-ratio
    (let  ((geometry  (assoc  'geometry  (frame-monitor-attributes  (selected-frame))) ))
      (message  (format  "geometry   %s"  geometry))
      (message  (format  "width      %s" (float  (nth  3  geometry))))
      (message  (format  "height     %s" (nth  4  geometry)))
      (message  (format  "pix width  %s" (display-pixel-width)))
      (message  (format  "pix height %s" (display-pixel-height)))
      (message  (format  "mm width   %s" (display-mm-width)))
      (message  (format  "mm height  %s" (display-mm-height)))
      (message  (format  "screens    %s" (display-screens)))
      (message  (format  "attributes %s" (display-monitor-attributes-list)))
      (message  (format  "frame atts  %s" (frame-monitor-attributes)))
      (/  (float  (nth  3  geometry))
          (nth  4  geometry)))
    "*The ratio width/height for the current display screen, calculated in screen pixels.")

 B
    .emacs-emacs-directory:  /home/dajo/ned/emacs-29.3/
geometry   (geometry 0 0 3840 2160)
width      3840.0
height     2160
pix width  7680
pix height 2160
mm width   2032
mm height  572
screens    1
attributes (((name . DP-1) (geometry 0 0 3840 2160) (workarea 0 72 3840 2088) (mm-size 597 336) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x559619a129a8>) (source . XRandR 1.5)) ((name . eDP-1) (geometry 3840 0 3840 2160) (workarea 3840 0 3840 2160) (mm-size 309 173) (frames) (source . XRandR 1.5)))
frame atts  ((name . DP-1) (geometry 0 0 3840 2160) (workarea 0 72 3840 2088) (mm-size 597 336) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x559619a129a8>) (source . XRandR 1.5))

Nepenthes .emacs loading in GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
 of 2024-07-18.

 C
    .emacs-emacs-directory:  /home/dajo/nut/emacs-29.3/
geometry   (geometry 0 0 7680 2160)
width      7680.0
height     2160
pix width  7680
pix height 2160
mm width   2032
mm height  572
screens    1
attributes (((name . combined screen) (geometry 0 0 7680 2160) (workarea 0 72 7680 2088) (mm-size 2032 572) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x5620435c10a8>) (source . fallback)))
frame atts  ((name . combined screen) (geometry 0 0 7680 2160) (workarea 0 72 7680 2088) (mm-size 2032 572) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x5620435c10a8>) (source . fallback))

Nepenthes .emacs loading in GNU Emacs 29.3 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
 of 2025-01-29.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "david" <david <at> ngdr.net>, Po Lu <luangruo <at> yahoo.com>,
 martin rudalics <rudalics <at> gmx.at>
Cc: 75936 <at> debbugs.gnu.org
Subject: Re: bug#75936: monitor width reporting
Date: Thu, 30 Jan 2025 08:52:25 +0200

> From: "david" <david <at> ngdr.net>
> Date: Wed, 29 Jan 2025 17:03:39 -0700
> 
> This is a bug that caused me some trouble; but mainly it is FYI.  The physical
> arrangement is a laptop, which has a 4K screen, driving a single 4K screen.  I
> get (still and always) the different results below from two different Emacs
> builds.

Can you tell more about the differences between these two builds?  Are
they builds of the same Emacs version with the same configure-time
switches/options and the same versions of the development tools, or
are any of those factors different between the builds (and if so,
which ones)?

> 
> The items below are:
> 
> A: code from a startup file; the messages are debug stuff, normally absent, the
>    intention behind the code is to compute the aspect ratio of a single monitor.
> 
> B and C: output from two different Emacs builds, see ned and nut directories.
>          The different widths matter to me because I am computing a ratio that
>          later wreak havoc 8-(  The creation dates probably matter to you.
>          Other than the dates I see no way to differentiate between the builds.
> 
>  A
>   ;; Probably this is not the aspect ratio of the full screen, probably the window manager will keep
>   ;; some of the screen for itself.
>   (defconst  .emacs-monitor-aspect-ratio
>     (let  ((geometry  (assoc  'geometry  (frame-monitor-attributes  (selected-frame))) ))
>       (message  (format  "geometry   %s"  geometry))
>       (message  (format  "width      %s" (float  (nth  3  geometry))))
>       (message  (format  "height     %s" (nth  4  geometry)))
>       (message  (format  "pix width  %s" (display-pixel-width)))
>       (message  (format  "pix height %s" (display-pixel-height)))
>       (message  (format  "mm width   %s" (display-mm-width)))
>       (message  (format  "mm height  %s" (display-mm-height)))
>       (message  (format  "screens    %s" (display-screens)))
>       (message  (format  "attributes %s" (display-monitor-attributes-list)))
>       (message  (format  "frame atts  %s" (frame-monitor-attributes)))
>       (/  (float  (nth  3  geometry))
>           (nth  4  geometry)))
>     "*The ratio width/height for the current display screen, calculated in screen pixels.")
> 
>  B
>     .emacs-emacs-directory:  /home/dajo/ned/emacs-29.3/
> geometry   (geometry 0 0 3840 2160)
> width      3840.0
> height     2160
> pix width  7680
> pix height 2160
> mm width   2032
> mm height  572
> screens    1
> attributes (((name . DP-1) (geometry 0 0 3840 2160) (workarea 0 72 3840 2088) (mm-size 597 336) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x559619a129a8>) (source . XRandR 1.5)) ((name . eDP-1) (geometry 3840 0 3840 2160) (workarea 3840 0 3840 2160) (mm-size 309 173) (frames) (source . XRandR 1.5)))
> frame atts  ((name . DP-1) (geometry 0 0 3840 2160) (workarea 0 72 3840 2088) (mm-size 597 336) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x559619a129a8>) (source . XRandR 1.5))
> 
> Nepenthes .emacs loading in GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
>  of 2024-07-18.
> 
>  C
>     .emacs-emacs-directory:  /home/dajo/nut/emacs-29.3/
> geometry   (geometry 0 0 7680 2160)
> width      7680.0
> height     2160
> pix width  7680
> pix height 2160
> mm width   2032
> mm height  572
> screens    1
> attributes (((name . combined screen) (geometry 0 0 7680 2160) (workarea 0 72 7680 2088) (mm-size 2032 572) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x5620435c10a8>) (source . fallback)))
> frame atts  ((name . combined screen) (geometry 0 0 7680 2160) (workarea 0 72 7680 2088) (mm-size 2032 572) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x5620435c10a8>) (source . fallback))
> 
> Nepenthes .emacs loading in GNU Emacs 29.3 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
>  of 2025-01-29.

Looks like one of the outputs reports two separate screens, whereas
the other reports a combined screen?  If so, aren't the differences
expected?  Or what am I missing?

Message #11 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: martin rudalics <rudalics <at> gmx.at>, david <david <at> ngdr.net>,
 75936 <at> debbugs.gnu.org
Subject: Re: bug#75936: monitor width reporting
Date: Thu, 30 Jan 2025 15:24:43 +0800

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

>> From: "david" <david <at> ngdr.net>
>> Date: Wed, 29 Jan 2025 17:03:39 -0700
>> 
>> This is a bug that caused me some trouble; but mainly it is FYI.  The physical
>> arrangement is a laptop, which has a 4K screen, driving a single 4K screen.  I
>> get (still and always) the different results below from two different Emacs
>> builds.
>
> Can you tell more about the differences between these two builds?  Are
> they builds of the same Emacs version with the same configure-time
> switches/options and the same versions of the development tools, or
> are any of those factors different between the builds (and if so,
> which ones)?
>
>> 
>> The items below are:
>> 
>> A: code from a startup file; the messages are debug stuff, normally absent, the
>>    intention behind the code is to compute the aspect ratio of a single monitor.
>> 
>> B and C: output from two different Emacs builds, see ned and nut directories.
>>          The different widths matter to me because I am computing a ratio that
>>          later wreak havoc 8-(  The creation dates probably matter to you.
>>          Other than the dates I see no way to differentiate between the builds.
>> 
>>  A
>>   ;; Probably this is not the aspect ratio of the full screen, probably the window manager will keep
>>   ;; some of the screen for itself.
>>   (defconst  .emacs-monitor-aspect-ratio
>>     (let  ((geometry  (assoc  'geometry  (frame-monitor-attributes  (selected-frame))) ))
>>       (message  (format  "geometry   %s"  geometry))
>>       (message  (format  "width      %s" (float  (nth  3  geometry))))
>>       (message  (format  "height     %s" (nth  4  geometry)))
>>       (message  (format  "pix width  %s" (display-pixel-width)))
>>       (message  (format  "pix height %s" (display-pixel-height)))
>>       (message  (format  "mm width   %s" (display-mm-width)))
>>       (message  (format  "mm height  %s" (display-mm-height)))
>>       (message  (format  "screens    %s" (display-screens)))
>>       (message  (format  "attributes %s" (display-monitor-attributes-list)))
>>       (message  (format  "frame atts  %s" (frame-monitor-attributes)))
>>       (/  (float  (nth  3  geometry))
>>           (nth  4  geometry)))
>>     "*The ratio width/height for the current display screen, calculated in screen pixels.")
>> 
>>  B
>>     .emacs-emacs-directory:  /home/dajo/ned/emacs-29.3/
>> geometry   (geometry 0 0 3840 2160)
>> width      3840.0
>> height     2160
>> pix width  7680
>> pix height 2160
>> mm width   2032
>> mm height  572
>> screens    1
>> attributes (((name . DP-1) (geometry 0 0 3840 2160) (workarea 0 72 3840 2088) (mm-size 597 336) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x559619a129a8>) (source . XRandR 1.5)) ((name . eDP-1) (geometry 3840 0 3840 2160) (workarea 3840 0 3840 2160) (mm-size 309 173) (frames) (source . XRandR 1.5)))
>> frame atts  ((name . DP-1) (geometry 0 0 3840 2160) (workarea 0 72 3840 2088) (mm-size 597 336) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x559619a129a8>) (source . XRandR 1.5))
>> 
>> Nepenthes .emacs loading in GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
>>  of 2024-07-18.
>> 
>>  C
>>     .emacs-emacs-directory:  /home/dajo/nut/emacs-29.3/
>> geometry   (geometry 0 0 7680 2160)
>> width      7680.0
>> height     2160
>> pix width  7680
>> pix height 2160
>> mm width   2032
>> mm height  572
>> screens    1
>> attributes (((name . combined screen) (geometry 0 0 7680 2160) (workarea 0 72 7680 2088) (mm-size 2032 572) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x5620435c10a8>) (source . fallback)))
>> frame atts  ((name . combined screen) (geometry 0 0 7680 2160) (workarea 0 72 7680 2088) (mm-size 2032 572) (frames #<frame *scratch* - GNU Emacs at Aglaea 0x5620435c10a8>) (source . fallback))
>> 
>> Nepenthes .emacs loading in GNU Emacs 29.3 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
>>  of 2025-01-29.
>
> Looks like one of the outputs reports two separate screens, whereas
> the other reports a combined screen?  If so, aren't the differences
> expected?  Or what am I missing?

The latter Emacs build was configured on a system without XRandr
headers, XRandr being the X server extension that provides detailed
monitor information.

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

From: "david" <david <at> ngdr.net>
To: "Po Lu" <luangruo <at> yahoo.com>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 75936 <at> debbugs.gnu.org
Subject: Re: bug#75936: monitor width reporting
Date: Thu, 30 Jan 2025 09:10:41 -0700

> Can you tell more about the differences between these two builds?  Are
> they builds of the same Emacs version with the same configure-time
> switches/options and the same versions of the development tools, or
> are any of those factors different between the builds (and if so,
> which ones)?

> Looks like one of the outputs reports two separate screens, whereas
> the other reports a combined screen?  If so, aren't the differences
> expected?  Or what am I missing?

> The latter Emacs build was configured on a system without XRandr
> headers, XRandr being the X server extension that provides detailed
> monitor information.

The two builds can be run within seconds of each other on the two-screen
setup described; the reported attributes are different; the build
information is the same.  Hence, the attributes information cannot be
relied on by a user.  It looks as though Po Lu has pointed out a difference
at a lower level.  I have created a kludge function that gets it right for
me with 16x9 screens and a sometimes 2x attributes error.

The builds were done six months apart; I have no recollection of the first.
Perversely, the second build was done to check accuracy of my code and
procedures.  The second build was done with a newly downloaded tar file; I
make minor changes to data.c and keymap.c; the patches are available if you
want them: irrelevant, not recommended.  As far as my build procedure is
concerned, I keep it as simple as possible.  For the most part, I involve
only the libraries that are mentioned by configure.  Although, in both
cases, I installed cairo [apt install libcairo-dev] because text size is a
disaster without it.  Cairo is in the build information.  I do not have any
idea how XRandR came into the picture.

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

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: Re: bug#75936: monitor width reporting
Date: Sat, 01 Feb 2025 11:51:10 +0200

> X-Spam-Status: No, score=0.099 tagged_above=-100 required=4.5
>  tests=[ALL_TRUSTED=0.1, BAYES_40=-0.001] autolearn=ham autolearn_force=no
> From: "david" <david <at> ngdr.net>
> Date: Thu, 30 Jan 2025 09:10:41 -0700
> Cc: "Eli Zaretskii" <eliz <at> gnu.org>, "martin rudalics" <rudalics <at> gmx.at>, 75936 <at> debbugs.gnu.org
> 
> > Can you tell more about the differences between these two builds?  Are
> > they builds of the same Emacs version with the same configure-time
> > switches/options and the same versions of the development tools, or
> > are any of those factors different between the builds (and if so,
> > which ones)?
> 
> > Looks like one of the outputs reports two separate screens, whereas
> > the other reports a combined screen?  If so, aren't the differences
> > expected?  Or what am I missing?
> 
> > The latter Emacs build was configured on a system without XRandr
> > headers, XRandr being the X server extension that provides detailed
> > monitor information.
> 
> The two builds can be run within seconds of each other on the two-screen
> setup described; the reported attributes are different; the build
> information is the same.  Hence, the attributes information cannot be
> relied on by a user.  It looks as though Po Lu has pointed out a difference
> at a lower level.  I have created a kludge function that gets it right for
> me with 16x9 screens and a sometimes 2x attributes error.
> 
> The builds were done six months apart; I have no recollection of the first.
> Perversely, the second build was done to check accuracy of my code and
> procedures.  The second build was done with a newly downloaded tar file; I
> make minor changes to data.c and keymap.c; the patches are available if you
> want them: irrelevant, not recommended.  As far as my build procedure is
> concerned, I keep it as simple as possible.  For the most part, I involve
> only the libraries that are mentioned by configure.  Although, in both
> cases, I installed cairo [apt install libcairo-dev] because text size is a
> disaster without it.  Cairo is in the build information.  I do not have any
> idea how XRandR came into the picture.

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.

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

From: "david" <david <at> ngdr.net>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 75936 <at> debbugs.gnu.org
Subject: Re: bug#75936: monitor width reporting
Date: Sat, 01 Feb 2025 13:21:17 -0700

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

At the very least, the build information should indicate the difference.
It happens that I have just carried out a re-build because I realized that
one build had been done with cairo, the other not, and the display was poor
in one case.  And I read the difference in the build information.  If the
build information in the current case had shown a difference, I should have
investigated.

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

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.

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.

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.

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

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

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.

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

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

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: "david" <david <at> ngdr.net>,  rudalics <at> gmx.at,  75936 <at> debbugs.gnu.org
> Date: Sun, 02 Feb 2025 14:59:29 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> 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

Thanks.  And the same with XINERAMA, I presume?

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

The documentation portion of the changeset which added support for
XRandR and Xinerama is lacking in more than one way, unfortunately.
E.g., the NEWS item didn't even mention these two X features, which
are prerequisites for multiple-monitor support.

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

So GTK also supports this internally?  Where's the code for that?
xfns.c defines monitor attributes only "#ifndef USE_GTK", AFAICT.
What did I miss?

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

OK, will do.

Message #32 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 <at> ngdr.net, 75936 <at> debbugs.gnu.org
Subject: Re: bug#75936: monitor width reporting
Date: Sun, 02 Feb 2025 18:30:31 +0800

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

>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: "david" <david <at> ngdr.net>,  rudalics <at> gmx.at,  75936 <at> debbugs.gnu.org
>> Date: Sun, 02 Feb 2025 14:59:29 +0800
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> 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
>
> Thanks.  And the same with XINERAMA, I presume?

Right.  That's also absent.

> The documentation portion of the changeset which added support for
> XRandR and Xinerama is lacking in more than one way, unfortunately.
> E.g., the NEWS item didn't even mention these two X features, which
> are prerequisites for multiple-monitor support.

That's quite lamentable.

> So GTK also supports this internally?  Where's the code for that?
> xfns.c defines monitor attributes only "#ifndef USE_GTK", AFAICT.
> What did I miss?

The code that interfaces with GTK is in the DEFUN
Fx_display_monitor_attributes_list, not x_get_monitor_attributes.

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

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

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: david <at> ngdr.net,  rudalics <at> gmx.at,  75936 <at> debbugs.gnu.org
> Date: Sun, 02 Feb 2025 18:30:31 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > So GTK also supports this internally?  Where's the code for that?
> > xfns.c defines monitor attributes only "#ifndef USE_GTK", AFAICT.
> > What did I miss?
> 
> The code that interfaces with GTK is in the DEFUN
> Fx_display_monitor_attributes_list, not x_get_monitor_attributes.

Thanks.  Does PGTK use that (and thus supports this functionality)?

Message #38 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 <at> ngdr.net, 75936 <at> debbugs.gnu.org
Subject: Re: bug#75936: monitor width reporting
Date: Sun, 02 Feb 2025 20:02:48 +0800

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

>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: david <at> ngdr.net,  rudalics <at> gmx.at,  75936 <at> debbugs.gnu.org
>> Date: Sun, 02 Feb 2025 18:30:31 +0800
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > So GTK also supports this internally?  Where's the code for that?
>> > xfns.c defines monitor attributes only "#ifndef USE_GTK", AFAICT.
>> > What did I miss?
>> 
>> The code that interfaces with GTK is in the DEFUN
>> Fx_display_monitor_attributes_list, not x_get_monitor_attributes.
>
> Thanks.  Does PGTK use that (and thus supports this functionality)?

Yes, although it uses its own copy of the same code.

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

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

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: david <at> ngdr.net,  rudalics <at> gmx.at,  75936 <at> debbugs.gnu.org
> Date: Sun, 02 Feb 2025 20:02:48 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Po Lu <luangruo <at> yahoo.com>
> >> Cc: david <at> ngdr.net,  rudalics <at> gmx.at,  75936 <at> debbugs.gnu.org
> >> Date: Sun, 02 Feb 2025 18:30:31 +0800
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> > So GTK also supports this internally?  Where's the code for that?
> >> > xfns.c defines monitor attributes only "#ifndef USE_GTK", AFAICT.
> >> > What did I miss?
> >> 
> >> The code that interfaces with GTK is in the DEFUN
> >> Fx_display_monitor_attributes_list, not x_get_monitor_attributes.
> >
> > Thanks.  Does PGTK use that (and thus supports this functionality)?
> 
> Yes, although it uses its own copy of the same code.

Thanks, I've added this to the doc string and the ELisp manual (on the
emacs-30 branch), and also added XINERAMA and XRANDR to
system-configuration-features (on the master branch).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: luangruo <at> yahoo.com, rudalics <at> gmx.at, david <at> ngdr.net
Cc: 75936-done <at> debbugs.gnu.org
Subject: Re: bug#75936: monitor width reporting
Date: Sat, 15 Feb 2025 13:21:59 +0200

> Cc: rudalics <at> gmx.at, david <at> ngdr.net, 75936 <at> debbugs.gnu.org
> Date: Sun, 02 Feb 2025 16:12:52 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Po Lu <luangruo <at> yahoo.com>
> > Cc: david <at> ngdr.net,  rudalics <at> gmx.at,  75936 <at> debbugs.gnu.org
> > Date: Sun, 02 Feb 2025 20:02:48 +0800
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > >> From: Po Lu <luangruo <at> yahoo.com>
> > >> Cc: david <at> ngdr.net,  rudalics <at> gmx.at,  75936 <at> debbugs.gnu.org
> > >> Date: Sun, 02 Feb 2025 18:30:31 +0800
> > >> 
> > >> Eli Zaretskii <eliz <at> gnu.org> writes:
> > >> 
> > >> > So GTK also supports this internally?  Where's the code for that?
> > >> > xfns.c defines monitor attributes only "#ifndef USE_GTK", AFAICT.
> > >> > What did I miss?
> > >> 
> > >> The code that interfaces with GTK is in the DEFUN
> > >> Fx_display_monitor_attributes_list, not x_get_monitor_attributes.
> > >
> > > Thanks.  Does PGTK use that (and thus supports this functionality)?
> > 
> > Yes, although it uses its own copy of the same code.
> 
> Thanks, I've added this to the doc string and the ELisp manual (on the
> emacs-30 branch), and also added XINERAMA and XRANDR to
> system-configuration-features (on the master branch).

No further comments, so I'm now closing this bug.

Previous Next

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