bug#9366: Display geometry change hook

bug#9366: Display geometry change hook

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

Severity: wishlist

Raised by Edward O'Connor in emacs-devel thread [1], filing in 
bugtracker so it doesn't get lost over the feature freeze period.

Emacs doesn't appear to currently provide a hook that is reliably called 
when the _display_ geometry changes on graphical window systems. e.g. 
screen resolution changed by user, monitor hotplugging.

Emacs frame/window geometry might sometimes be considered to remain the 
same by the window system terms despite changing overall display 
geometry, so e.g. window-configuration-change-hook is not always run 
when the display geometry changes.

Attached is an initial x11-only stab at an implementation that calls 
window-configuration-change-hook when display geometry changes, though a 
separate hook would be another design option.

For ns, Edward also mentioned:

"On GNUStep and Mac OS X, applications can listen for 
NSApplicationDidChangeScreenParametersNotification for this sort of thing"

Dunno about w32 as yet, but presumably it has something similar.


[1] http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00544.html
From: "Edward O'Connor" <...>
Date: Fri, 12 Aug 2011 10:51:25 -0700
Message-ID: 
<CAME3nGLnjLXixmSY45BWFX6qtCp2_XBR4x6a281hO6Mu=rnSuQ@mail.gmail.com>
Subject: is there a hook run when display geometry changes?


[-- Attachment #2: xrandr_monitoring_r1.diff --]
[-- Type: text/x-patch, Size: 9390 bytes --]

=== modified file 'configure.in'
--- configure.in	2011-08-04 17:04:39 +0000
+++ configure.in	2011-08-13 04:36:34 +0000
@@ -160,6 +160,8 @@
 OPTION_DEFAULT_ON([xml2],[don't compile with XML parsing support])
 OPTION_DEFAULT_ON([imagemagick],[don't compile with ImageMagick image support])
 
+OPTION_DEFAULT_ON([xrandr],[don't compile with XRandR support])
+
 OPTION_DEFAULT_ON([xft],[don't use XFT for anti aliased fonts])
 OPTION_DEFAULT_ON([libotf],[don't use libotf for OpenType font support])
 OPTION_DEFAULT_ON([m17n-flt],[don't use m17n-flt for text shaping])
@@ -2590,6 +2592,21 @@
 fi
 AC_SUBST(LIBXSM)
 
+### Use xrandr (-lXrandr) if available
+HAVE_XRANDR=no
+XRANDR_LIBS=
+XRANDR_CFLAGS=
+if test "${HAVE_X11}" = "yes"; then
+  if test "${with_xrandr}" != "no"; then
+    PKG_CHECK_MODULES(XRANDR, xrandr > 1.0, HAVE_XRANDR=yes, HAVE_XRANDR=no)
+    if test "${HAVE_XRANDR}" = "yes"; then
+      AC_DEFINE(HAVE_XRANDR, 1, [Define to 1 if you have the Xrandr library (-lXrandr).])
+    fi
+  fi
+fi
+AC_SUBST(XRANDR_LIBS)
+AC_SUBST(XRANDR_CFLAGS)
+
 ### Use libxml (-lxml2) if available
 if test "${with_xml2}" != "no"; then
   ### I'm not sure what the version number should be, so I just guessed.
@@ -3700,6 +3717,8 @@
 echo "  Does Emacs use -lotf?                                   ${HAVE_LIBOTF}"
 echo "  Does Emacs use -lxft?                                   ${HAVE_XFT}"
 
+echo "  Does Emacs use -lXrandr?                                ${HAVE_XRANDR}"
+
 echo "  Does Emacs use toolkit scroll bars?                     ${USE_TOOLKIT_SCROLL_BARS}"
 echo
 

=== modified file 'lisp/frame.el'
--- lisp/frame.el	2011-07-16 13:02:51 +0000
+++ lisp/frame.el	2011-08-13 04:04:16 +0000
@@ -1585,6 +1585,18 @@
 (define-obsolete-variable-alias 'blink-cursor 'blink-cursor-mode "22.1")
 
 \f
+;; Display geometry changes
+
+(defun handle-screen-change-notify-event (event)
+  "Handle screen-change-notify-event on the display in EVENT.
+   At present, just runs any window-configuration-changed-hook
+   for all frames on the display."
+  ; FIXME: do we want a completely separate hook instead?
+  (interactive "e")
+  (let ((display-name (nth 1 event)))
+    (mapcar #'run-window-configuration-change-hook
+            (frames-on-display-list display-name))))
+
 ;;;; Key bindings
 
 (define-key ctl-x-5-map "2" 'make-frame-command)
@@ -1592,6 +1604,9 @@
 (define-key ctl-x-5-map "0" 'delete-frame)
 (define-key ctl-x-5-map "o" 'other-frame)
 
+(define-key special-event-map [screen-change-notify-event]
+  'handle-screen-change-notify-event)
+
 (provide 'frame)
 
 ;;; frame.el ends here

=== modified file 'src/Makefile.in'
--- src/Makefile.in	2011-08-04 17:04:39 +0000
+++ src/Makefile.in	2011-08-13 05:16:52 +0000
@@ -170,6 +170,9 @@
 
 LIBXSM=@LIBXSM@
 
+XRANDR_CFLAGS = @XRANDR_CFLAGS@
+XRANDR_LIBS = @XRANDR_LIBS@
+
 LIBXTR6=@LIBXTR6@
 
 ## $(LIBXMU) -lXt $(LIBXTR6) -lXext if USE_X_TOOLKIT, else $(LIBXSM).
@@ -313,6 +316,7 @@
   $(SETTINGS_CFLAGS) $(FREETYPE_CFLAGS) $(FONTCONFIG_CFLAGS) \
   $(LIBOTF_CFLAGS) $(M17N_FLT_CFLAGS) $(DEPFLAGS) $(PROFILING_CFLAGS) \
   $(LIBGNUTLS_CFLAGS) \
+  $(XRANDR_CFLAGS) \
   $(C_WARNINGS_SWITCH) $(CFLAGS)
 ALL_OBJC_CFLAGS=$(ALL_CFLAGS) $(GNU_OBJC_CFLAGS)
 
@@ -388,7 +392,8 @@
    $(LIBXML2_LIBS) $(LIBGPM) $(LIBRESOLV) $(LIBS_SYSTEM) \
    $(LIBS_TERMCAP) $(GETLOADAVG_LIBS) $(SETTINGS_LIBS) $(LIBSELINUX_LIBS) \
    $(FREETYPE_LIBS) $(FONTCONFIG_LIBS) $(LIBOTF_LIBS) $(M17N_FLT_LIBS) \
-   $(LIBGNUTLS_LIBS) $(LIB_PTHREAD) $(LIB_PTHREAD_SIGMASK) \
+   $(LIBGNUTLS_LIBS) $(XRANDR_LIBS) \
+   $(LIB_PTHREAD) $(LIB_PTHREAD_SIGMASK) \
    $(LIB_GCC) $(LIB_MATH) $(LIB_STANDARD) $(LIB_GCC)
 
 all: emacs$(EXEEXT) $(OTHER_FILES)

=== modified file 'src/keyboard.c'
--- src/keyboard.c	2011-08-04 17:04:39 +0000
+++ src/keyboard.c	2011-08-13 03:41:32 +0000
@@ -331,6 +331,8 @@
 #endif
 static Lisp_Object Qconfig_changed_event;
 
+static Lisp_Object Qscreen_change_notify_event;
+
 /* Lisp_Object Qmouse_movement; - also an event header */
 
 /* Properties of event headers.  */
@@ -4033,6 +4035,11 @@
 	  obj = make_lispy_event (event);
 	  kbd_fetch_ptr = event + 1;
 	}
+      else if (event->kind == SCREEN_CHANGE_NOTIFY_EVENT)
+	{
+	  obj = make_lispy_event (event);
+	  kbd_fetch_ptr = event + 1;
+	}
       else
 	{
 	  /* If this event is on a different frame, return a switch-frame this
@@ -5987,6 +5994,9 @@
 			       Qnil));
        }
 #endif /* HAVE_GPM */
+    case SCREEN_CHANGE_NOTIFY_EVENT:
+	return Fcons (Qscreen_change_notify_event,
+                      Fcons (event->frame_or_window, Qnil));
 
       /* The 'kind' field of the event is something we don't recognize.  */
     default:
@@ -11527,6 +11537,7 @@
   DEFSYM (Qsave_session, "save-session");
   DEFSYM (Qconfig_changed_event, "config-changed-event");
   DEFSYM (Qmenu_enable, "menu-enable");
+  DEFSYM (Qscreen_change_notify_event, "screen-change-notify-event");
 
 #if defined (WINDOWSNT)
   DEFSYM (Qlanguage_change, "language-change");
@@ -12288,6 +12299,10 @@
 
   initial_define_lispy_key (Vspecial_event_map, "config-changed-event",
 			    "ignore");
+
+  initial_define_lispy_key (Vspecial_event_map, "screen-change-notify-event",
+			    "ignore");
+
 }
 
 /* Mark the pointers in the kboard objects.

=== modified file 'src/termhooks.h'
--- src/termhooks.h	2011-06-06 19:43:39 +0000
+++ src/termhooks.h	2011-08-13 03:18:24 +0000
@@ -206,6 +206,13 @@
   , NS_NONKEY_EVENT
 #endif
 
+  /* Generated when a bitmapped display's (upon which emacs has
+     frame(s) open) geometry changes dynamically e.g. by monitor
+     hotplugging or resolution change.
+     On X, that which is handled by the X Resize and Rotate
+     Extension.  */
+  , SCREEN_CHANGE_NOTIFY_EVENT
+
 };
 
 /* If a struct input_event has a kind which is SELECTION_REQUEST_EVENT

=== modified file 'src/window.c'
--- src/window.c	2011-08-05 11:04:44 +0000
+++ src/window.c	2011-08-13 04:04:18 +0000
@@ -6542,7 +6542,11 @@
 	       doc: /* Functions to call when window configuration changes.
 The buffer-local part is run once per window, with the relevant window
 selected; while the global part is run only once for the modified frame,
-with the relevant frame selected.  */);
+with the relevant frame selected.
+
+If emacs can detect them, changes to the overall geometry of a display
+upon which a frame is open will by default also run this hook via
+the function `handle-screen-change-notify-event`.  */);
   Vwindow_configuration_change_hook = Qnil;
 
   DEFVAR_LISP ("recenter-redisplay", Vrecenter_redisplay,

=== modified file 'src/xterm.c'
--- src/xterm.c	2011-08-04 11:06:22 +0000
+++ src/xterm.c	2011-08-13 05:00:47 +0000
@@ -85,6 +85,10 @@
 #include <X11/Shell.h>
 #endif
 
+#ifdef HAVE_XRANDR
+#include <X11/extensions/Xrandr.h>
+#endif
+
 #ifdef HAVE_SYS_TIME_H
 #include <sys/time.h>
 #endif
@@ -359,7 +363,6 @@
 static void x_wm_set_icon_pixmap (struct frame *, ptrdiff_t);
 static void x_initialize (void);
 
-
 /* Flush display of frame F, or of all frames if F is null.  */
 
 static void
@@ -6993,6 +6996,26 @@
       break;
 
     default:
+#ifdef HAVE_XRANDR
+    /* xrandr extension may or may not be present on a display =>
+       can't check for it as a constant C "case" arg, hence "if" here  */
+    if (dpyinfo->xrandr_present &&
+        (event.type == (dpyinfo->xrandr_event_base + RRScreenChangeNotify)))
+      {
+        /* FIXME: is XRRUpdateConfiguration actually called by the toolkit/gtk+?
+           Even if it is, can/should we call it ourselves here?  */
+#if !(defined USE_X_TOOLKIT || defined USE_GTK)
+        BLOCK_INPUT;
+        XRRUpdateConfiguration(&event);
+        UNBLOCK_INPUT;
+#endif
+        /* FIXME: do we really need a separate event kind? It seems
+           conceptually similar to a CONFIG_CHANGED_EVENT */
+        inev.ie.kind = SCREEN_CHANGE_NOTIFY_EVENT;
+        inev.ie.frame_or_window = XCAR(dpyinfo->name_list_element);
+      }
+    goto OTHER;
+#endif /* HAVE_XRANDR */
     OTHER:
 #ifdef USE_X_TOOLKIT
     BLOCK_INPUT;
@@ -8169,6 +8192,25 @@
 
 #endif /* not HAVE_X11R6_XIM */
 
+\f
+/***********************************************************************
+			   X Resize and Rotate
+ ***********************************************************************/
+
+#ifdef HAVE_XRANDR
+
+static void
+xrandr_initialize (struct x_display_info *dpyinfo)
+{
+  dpyinfo->xrandr_present = XRRQueryExtension (dpyinfo->display,
+                                               &(dpyinfo->xrandr_event_base),
+                                               &(dpyinfo->xrandr_error_base));
+  if (dpyinfo->xrandr_present)
+    XRRSelectInput (dpyinfo->display, dpyinfo->root_window,
+                    RRScreenChangeNotifyMask);
+}
+
+#endif /* HAVE_XRANDR */
 
 \f
 /* Calculate the absolute position in frame F
@@ -10315,6 +10357,10 @@
   xim_initialize (dpyinfo, resource_name);
 #endif
 
+#ifdef HAVE_XRANDR
+  xrandr_initialize (dpyinfo);
+#endif
+
   xsettings_initialize (dpyinfo);
 
   /* This is only needed for distinguishing keyboard and process input.  */

=== modified file 'src/xterm.h'
--- src/xterm.h	2011-07-07 02:24:56 +0000
+++ src/xterm.h	2011-08-13 02:41:25 +0000
@@ -354,6 +354,14 @@
 
   /* SM */
   Atom Xatom_SM_CLIENT_ID;
+
+#ifdef HAVE_XRANDR
+  /* X Resize and Rotate */
+  Bool xrandr_present;
+  int xrandr_event_base;
+  int xrandr_error_base;
+#endif
+
 };
 
 #ifdef HAVE_X_I18N

bug#9366: Display geometry change hook

[Eli Zaretskii]

> Date: Thu, 25 Aug 2011 06:16:58 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> 
> Dunno about w32 as yet, but presumably it has something similar.

On MS-Windows there's the WM_DISPLAYCHANGE message sent to the message
pump.  Emacs already accepts that message (see w32term.c), but
currently does nothing with it except announcing the change to the
attached debugger.

However, on Windows the message also specifies the new resolution, so
this:

> +        inev.ie.kind = SCREEN_CHANGE_NOTIFY_EVENT;
> +        inev.ie.frame_or_window = XCAR(dpyinfo->name_list_element);

is not general enough: there should be a way to provide the new
dimensions to the event queue.  It also means that a "normal" hook is
insufficient to handle this event, it should be a -functions style
hook.

bug#9366: Display geometry change hook

[David De La Harpe Golden]

On 25/08/11 06:55, Eli Zaretskii wrote:
>> Date: Thu, 25 Aug 2011 06:16:58 +0100
>> From: David De La Harpe Golden<david@harpegolden.net>
>>
>> Dunno about w32 as yet, but presumably it has something similar.
>
> On MS-Windows there's the WM_DISPLAYCHANGE message sent to the message
> pump.  Emacs already accepts that message (see w32term.c), but
> currently does nothing with it except announcing the change to the
> attached debugger.
>
> However, on Windows the message also specifies the new resolution, so
> this:
>

Technically the incoming x11 event does too, but as you can re-query 
with the existing #'display-pixel-width etc. functions (and get the new 
values) anyway by the time the hook actually runs (on x11), wasn't sure 
we needed to allow for propagation of the info really.

bug#9366: Attempting to add myself to this bug's CC list

[Edward O'Connor]

I apologize for the noise; the normal way of CCing oneself apparently
doesn't work[1].


Ted

1. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5439

bug#9366: Display geometry change hook

[Lars Ingebrigtsen]

David De La Harpe Golden <david@harpegolden.net> writes:

> Attached is an initial x11-only stab at an implementation that calls
> window-configuration-change-hook when display geometry changes, though
> a separate hook would be another design option.
>
> For ns, Edward also mentioned:
>
> "On GNUStep and Mac OS X, applications can listen for
> NSApplicationDidChangeScreenParametersNotification for this sort of
> thing"
>
> Dunno about w32 as yet, but presumably it has something similar.

This was nine years ago, but this didn't get much attention at the time.

[...]

> +if test "${HAVE_X11}" = "yes"; then
> +  if test "${with_xrandr}" != "no"; then
> +    PKG_CHECK_MODULES(XRANDR, xrandr > 1.0, HAVE_XRANDR=yes, HAVE_XRANDR=no)
> +    if test "${HAVE_XRANDR}" = "yes"; then
> +      AC_DEFINE(HAVE_XRANDR, 1, [Define to 1 if you have the Xrandr library (-lXrandr).])
> +    fi

Emacs is now built with xrandr support by default (on the relevant
systems)...

[...]

> +#ifdef HAVE_XRANDR
> +    /* xrandr extension may or may not be present on a display =>
> +       can't check for it as a constant C "case" arg, hence "if" here  */
> +    if (dpyinfo->xrandr_present &&
> +        (event.type == (dpyinfo->xrandr_event_base + RRScreenChangeNotify)))
> +      {
> +        /* FIXME: is XRRUpdateConfiguration actually called by the toolkit/gtk+?

But looking through the code, it doesn't seem like Emacs has grown this
capability over the years?  But I may be looking in the wrong places.

In any case, it sounds useful?  I haven't tried applying the patch,
though, so I don't know how much work that would be to bring it up to
date.

Anybody got any opinions here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#9366: Display geometry change hook

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 19 Sep 2020 17:28:48 +0200
> Cc: 9366@debbugs.gnu.org
> 
> > +#ifdef HAVE_XRANDR
> > +    /* xrandr extension may or may not be present on a display =>
> > +       can't check for it as a constant C "case" arg, hence "if" here  */
> > +    if (dpyinfo->xrandr_present &&
> > +        (event.type == (dpyinfo->xrandr_event_base + RRScreenChangeNotify)))
> > +      {
> > +        /* FIXME: is XRRUpdateConfiguration actually called by the toolkit/gtk+?
> 
> But looking through the code, it doesn't seem like Emacs has grown this
> capability over the years?  But I may be looking in the wrong places.
> 
> In any case, it sounds useful?  I haven't tried applying the patch,
> though, so I don't know how much work that would be to bring it up to
> date.
> 
> Anybody got any opinions here?

Do we really have to do this on such a low level?  Why cannot we call
such a hook from change_frame_size, which would allow us to do that in
platform-independent manner?

Martin, am I missing something here?

bug#9366: Display geometry change hook

[martin rudalics]

 > Do we really have to do this on such a low level?  Why cannot we call
 > such a hook from change_frame_size, which would allow us to do that in
 > platform-independent manner?
 >
 > Martin, am I missing something here?

Would change_frame_size be aware of such a geometry change?  IIUC
the original request

https://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00544.html

Edward would really just want a completely separate hook that reports to
Emacs the identity of the changed display and maybe its new geometry and
is only called in those, IMO very rare, occasions.  Or what am I missing
here?

martin

bug#9366: Display geometry change hook

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> Edward would really just want a completely separate hook that reports to
> Emacs the identity of the changed display and maybe its new geometry and
> is only called in those, IMO very rare, occasions.  Or what am I missing
> here?

No, I think that's it -- it's a hook that's run when the display changes
size, not when any Emacs frame changes size.

But I wonder whether triggering this from an xrandr context makes much
sense these days.  Surely on most (any?) modern GNU/Linux systems,
plugging in a new screen will trigger a Dbus message?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#9366: Display geometry change hook

[Eli Zaretskii]

> Cc: david@harpegolden.net, 9366@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 20 Sep 2020 10:14:34 +0200
> 
>  > Do we really have to do this on such a low level?  Why cannot we call
>  > such a hook from change_frame_size, which would allow us to do that in
>  > platform-independent manner?
>  >
>  > Martin, am I missing something here?
> 
> Would change_frame_size be aware of such a geometry change?  IIUC
> the original request
> 
> https://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00544.html
> 
> Edward would really just want a completely separate hook that reports to
> Emacs the identity of the changed display and maybe its new geometry and
> is only called in those, IMO very rare, occasions.  Or what am I missing
> here?

So this is only about switching to a different display?  And you are
saying that Emacs in general doesn't know about such display changes?

Would it work to test the display geometry from focus-in-hook?  Or
from a timer?

bug#9366: Display geometry change hook

[martin rudalics]

 > So this is only about switching to a different display?

A different geometry but still on the same display IIUC.

 > And you are
 > saying that Emacs in general doesn't know about such display changes?

I don't know.  Are we already informed when the user plugs in a new
display?

 > Would it work to test the display geometry from focus-in-hook?

Sounds expensive (BTW 'focus-in-hook' is obsolete since 27.1).  And what
about a user who currently has no frame on that display but might
consider switching to it when its geometry meets certain requirements?

 > Or
 > from a timer?

To poll the geometry?  Sounds much too expensive too.  If and when the
underlying windowing system informs us of display changes, I would just
react to them.  What's speaking against it?

martin

bug#9366: Display geometry change hook

[Eli Zaretskii]

> Cc: larsi@gnus.org, david@harpegolden.net, 9366@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 20 Sep 2020 14:24:10 +0200
> 
>  > Would it work to test the display geometry from focus-in-hook?
> 
> Sounds expensive

How so?  Is the API which we use to determine the display geometry
expensive?  Any quantitative data about that?

> And what about a user who currently has no frame on that display but
> might consider switching to it when its geometry meets certain
> requirements?

Is this an important use case?

>  > Or
>  > from a timer?
> 
> To poll the geometry?  Sounds much too expensive too.

Same question as above.  We currently have several timers running in
every session, so a timer that ticks, say, once a second doesn't sound
too expensive to me.  Especially since this will most probably be an
optional feature.

> If and when the underlying windowing system informs us of display
> changes, I would just react to them.  What's speaking against it?

The proposed solution was only for X, and using an optional component
at that.  I'd rather find a solution that would work on all supported
platforms and required no special APIs.

bug#9366: Display geometry change hook

[martin rudalics]

 >>   > Would it work to test the display geometry from focus-in-hook?
 >>
 >> Sounds expensive
 >
 > How so?  Is the API which we use to determine the display geometry
 > expensive?

I meant expensive in the sense that Emacs would poll the display
geometry in every focus event with maybe a handful of people ever making
use of it.

 > Any quantitative data about that?
 >
 >> And what about a user who currently has no frame on that display but
 >> might consider switching to it when its geometry meets certain
 >> requirements?
 >
 > Is this an important use case?

I don't know.  I never plug a monitor into a running session.

 >>   > Or
 >>   > from a timer?
 >>
 >> To poll the geometry?  Sounds much too expensive too.
 >
 > Same question as above.  We currently have several timers running in
 > every session, so a timer that ticks, say, once a second doesn't sound
 > too expensive to me.  Especially since this will most probably be an
 > optional feature.

You mean when the value of 'display-geometry-change-hook' is non-nil,
for example.

 >> If and when the underlying windowing system informs us of display
 >> changes, I would just react to them.  What's speaking against it?
 >
 > The proposed solution was only for X, and using an optional component
 > at that.  I'd rather find a solution that would work on all supported
 > platforms and required no special APIs.

But it would probably rely on 'display-monitor-attributes-list' and thus
use its APIs.  And on Windows, for example, the "special" API is already
there in WM_DISPLAYCHANGE and I suppose the other platforms should be
able to handle fullscreen frames after a display change in a similar way
too.

In either case it's no great deal.  I won't implement it because I've
sworn to never change the resolution of a running system again (once an
xfce Debian here insisted for weeks to come up with a 640x480 screen
resolution because it did not trust my monitor's repeat frequency) and
master still struggles with the (funcall eldoc-documentation-function)
issue.

martin

bug#9366: Display geometry change hook

[Eli Zaretskii]

> Cc: larsi@gnus.org, david@harpegolden.net, 9366@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 21 Sep 2020 09:26:01 +0200
> 
>  >> To poll the geometry?  Sounds much too expensive too.
>  >
>  > Same question as above.  We currently have several timers running in
>  > every session, so a timer that ticks, say, once a second doesn't sound
>  > too expensive to me.  Especially since this will most probably be an
>  > optional feature.
> 
> You mean when the value of 'display-geometry-change-hook' is non-nil,
> for example.

Yes.

>  >> If and when the underlying windowing system informs us of display
>  >> changes, I would just react to them.  What's speaking against it?
>  >
>  > The proposed solution was only for X, and using an optional component
>  > at that.  I'd rather find a solution that would work on all supported
>  > platforms and required no special APIs.
> 
> But it would probably rely on 'display-monitor-attributes-list' and thus
> use its APIs.  And on Windows, for example, the "special" API is already
> there in WM_DISPLAYCHANGE and I suppose the other platforms should be
> able to handle fullscreen frames after a display change in a similar way
> too.

Yes, I know about WM_DISPLAYCHANGE (although we currently only handle
the full-screen frames there).  But the corresponding X feature
requires the use of a special X module, and I don't know what happens
on macOS.  So I thought a platform-independent method that always
works, and can be implemented in just one place, is a better
alternative.

Besides, adding one more special event comes with minor disadvantages
of its own -- one more event to disregard in situations like
while-no-input etc.

bug#9366: Display geometry change hook

[martin rudalics]

 > Yes, I know about WM_DISPLAYCHANGE (although we currently only handle
 > the full-screen frames there).

Has anyone ever confirmed that it correctly handles the full-screen
frames?

 > But the corresponding X feature
 > requires the use of a special X module, and I don't know what happens
 > on macOS.  So I thought a platform-independent method that always
 > works, and can be implemented in just one place, is a better
 > alternative.

But such a platform-independent method on X would boil down to using the
same special X module as the platform-dependent method.  That is, we
would try running XRANDR in either case ...  I don't know about macOS.

 > Besides, adding one more special event comes with minor disadvantages
 > of its own -- one more event to disregard in situations like
 > while-no-input etc.

But at least on Windows we have to pay attention to such events anyway.

martin

bug#9366: Display geometry change hook

[Eli Zaretskii]

> Cc: larsi@gnus.org, david@harpegolden.net, 9366@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 22 Sep 2020 09:16:58 +0200
> 
>  > Yes, I know about WM_DISPLAYCHANGE (although we currently only handle
>  > the full-screen frames there).
> 
> Has anyone ever confirmed that it correctly handles the full-screen
> frames?

I don't know.  I don't have a system to try that.

>  > But the corresponding X feature
>  > requires the use of a special X module, and I don't know what happens
>  > on macOS.  So I thought a platform-independent method that always
>  > works, and can be implemented in just one place, is a better
>  > alternative.
> 
> But such a platform-independent method on X would boil down to using the
> same special X module as the platform-dependent method.  That is, we
> would try running XRANDR in either case ...

Do we use XRANDR to query the display geometry?

>  > Besides, adding one more special event comes with minor disadvantages
>  > of its own -- one more event to disregard in situations like
>  > while-no-input etc.
> 
> But at least on Windows we have to pay attention to such events anyway.

I didn't mean MS-Windows events (a.k.a. "messages"), I meant events in
the Emacs event queue.  A message coming from the window manager
doesn't have to be converted to an Emacs event, it can be handled
directly.

bug#9366: Display geometry change hook

[martin rudalics]

 >> Has anyone ever confirmed that it correctly handles the full-screen
 >> frames?
 >
 > I don't know.  I don't have a system to try that.

Maybe someone on Windows could give it a try:

(1) With an Emacs frame run 'toggle-frame-fullscreen' (F11).

(2) Change the resolution of the monitor the frame appears on.

(3) Look whether the frame is still fullscreen.

 > Do we use XRANDR to query the display geometry?

If they are available, Emacs tries XRANDR first and, if that fails,
XINERAMA next.

 > I didn't mean MS-Windows events (a.k.a. "messages"), I meant events in
 > the Emacs event queue.  A message coming from the window manager
 > doesn't have to be converted to an Emacs event, it can be handled
 > directly.

You mean that we'd have to put a function running the hook into the
event queue when no input is allowed?  And running 'gui_set_fullscreen'
OTOH can be handled directly?

martin

bug#9366: Display geometry change hook

[Corwin Brust]

Hi Martin.

On Wed, Sep 23, 2020 at 2:16 AM martin rudalics <rudalics@gmx.at> wrote:
>
>  >> Has anyone ever confirmed that it correctly handles the full-screen
>  >> frames?
>  >
>  > I don't know.  I don't have a system to try that.
>
> Maybe someone on Windows could give it a try:
>
> (1) With an Emacs frame run 'toggle-frame-fullscreen' (F11).
>
> (2) Change the resolution of the monitor the frame appears on.
>
> (3) Look whether the frame is still fullscreen.

The frame remains full screen, both when immediately when I make the
change and also when I choose "revert".   When I selected "revert" it
did drop briefly out of full-screen mode but then restored itself
properly immediately thereafter.  I have several displays and most of
them have a full-screen emacs in them most of the time.  LMK if there
else I could assist with.  Emacs 27.1 GNU bin dist.

>
> martin

Regards,
Corwin

bug#9366: Display geometry change hook

[martin rudalics]

 >> Maybe someone on Windows could give it a try:
 >>
 >> (1) With an Emacs frame run 'toggle-frame-fullscreen' (F11).
 >>
 >> (2) Change the resolution of the monitor the frame appears on.
 >>
 >> (3) Look whether the frame is still fullscreen.
 >
 > The frame remains full screen, both when immediately when I make the
 > change and also when I choose "revert".   When I selected "revert" it
 > did drop briefly out of full-screen mode but then restored itself
 > properly immediately thereafter.  I have several displays and most of
 > them have a full-screen emacs in them most of the time.  LMK if there
 > else I could assist with.  Emacs 27.1 GNU bin dist.

Thanks.  That last sentence makes me doubt whether you really tested
this on Windows.  What is a "GNU bin dist"?  Please clarify.

martin

bug#9366: Display geometry change hook

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, Lars Ingebrigtsen <larsi@gnus.org>,
>  9366@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 23 Sep 2020 10:14:37 +0200
> 
>  > The frame remains full screen, both when immediately when I make the
>  > change and also when I choose "revert".   When I selected "revert" it
>  > did drop briefly out of full-screen mode but then restored itself
>  > properly immediately thereafter.  I have several displays and most of
>  > them have a full-screen emacs in them most of the time.  LMK if there
>  > else I could assist with.  Emacs 27.1 GNU bin dist.
> 
> Thanks.  That last sentence makes me doubt whether you really tested
> this on Windows.  What is a "GNU bin dist"?  Please clarify.

I'm guessing that's the Windows binaries available from the GNU FTP
site.  So we are safe, I think.

bug#9366: Display geometry change hook

[Eli Zaretskii]

> Cc: larsi@gnus.org, david@harpegolden.net, 9366@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 23 Sep 2020 09:15:16 +0200
> 
>  > Do we use XRANDR to query the display geometry?
> 
> If they are available, Emacs tries XRANDR first and, if that fails,
> XINERAMA next.

Then maybe the proposed method is not a big deal.  But I'd like to
understand the situation on macOS first -- is there an equivalent
feature there?

>  > I didn't mean MS-Windows events (a.k.a. "messages"), I meant events in
>  > the Emacs event queue.  A message coming from the window manager
>  > doesn't have to be converted to an Emacs event, it can be handled
>  > directly.
> 
> You mean that we'd have to put a function running the hook into the
> event queue when no input is allowed?

Sorry, I don't think I understand this.  Can you explain what you
mean?

> And running 'gui_set_fullscreen' OTOH can be handled directly?

We already do that, no?

bug#9366: Display geometry change hook

[martin rudalics]

 >>   > I didn't mean MS-Windows events (a.k.a. "messages"), I meant events in
 >>   > the Emacs event queue.  A message coming from the window manager
 >>   > doesn't have to be converted to an Emacs event, it can be handled
 >>   > directly.
 >>
 >> You mean that we'd have to put a function running the hook into the
 >> event queue when no input is allowed?
 >
 > Sorry, I don't think I understand this.  Can you explain what you
 > mean?
 >
 >> And running 'gui_set_fullscreen' OTOH can be handled directly?
 >
 > We already do that, no?

I probably didn't understand what you wrote first.  Let me ask it this
way: Since we can run 'gui_set_fullscreen' directly, then couldn't we
run 'display-geometry-change-hook' directly too?

martin

bug#9366: Display geometry change hook

[Eli Zaretskii]

> Cc: larsi@gnus.org, david@harpegolden.net, 9366@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 23 Sep 2020 19:41:40 +0200
> 
> Let me ask it this way: Since we can run 'gui_set_fullscreen'
> directly, then couldn't we run 'display-geometry-change-hook'
> directly too?

I think so, yes.

bug#9366: Display geometry change hook

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> But such a platform-independent method on X would boil down to using the
> same special X module as the platform-dependent method.  That is, we
> would try running XRANDR in either case ...  I don't know about macOS.

Does XRANDR work under Wayland?

Like I said earlier, it seems more useful to do this off of Dbus than in
a XRANDR context -- that's likely to be relevant for more systems, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no