GNU bug report logs - #48268
28.0.50; Blank screen when switching virtual desktops or when starting exwm (regression from 483c5e9)

Previous Next

Full log

View this message in rfc822 format

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Ramon Diaz-Uriarte <rdiaz02 <at> gmail.com>, 48268 <at> debbugs.gnu.org
Subject: bug#48268: 28.0.50; Blank screen when switching virtual desktops or when starting exwm (regression from 483c5e9)
Date: Fri, 14 May 2021 10:38:32 +0100

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

>> The problem is still present (using 43701a8) with XMonad: switching to a
>> different virtual desktop leads to a blank screen. It still responds to (at
>> least) some keyboard shortcuts (I can close with C-x C-x) and if the menu
>
> Is that C-x C-c or is C-x C-x special for you?
>
>> bar or the toolbar are active they also respond to some mouse clicks.
>>
>> Interestingly, the problem does not show up if I launch Emacs in an XMonad
>> session inside XMonad using xephyr.
>
> I'm a bit too dense to understand what you are doing and what does not
> work for you.  Is the behavior of Xmonad showing an Emacs frame OK as
> long as you do not switch to a different virtual desktop?  Are tool and
> menu bar shown in the blank screen case?  Does a blank screen blank out
> other things besides Emacs.  Does it work when Emacs is not supposed to
> be shown on that "different virtual desktop"?
>
> In either case please try to identify the commit that broke this - I
> have my slight doubts that it is 483c5e9.  Could it be already a190b4c?

Bisected the following behaviour on Xmonad to 483c5e9.  In the
screenshots below a red or black border indicates which frame Xmonad
thinks is selected or unselected, respectively.  Similarly a filled or
hollow box cursor shows which frame Emacs thinks is selected or
unselected, respectively.

0. emacs -Q

[0.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

1. C-x 5 2
   [Ignore the missing scroll bar for now.]

2. (visible-frame-list) C-j C-m

3. (mapcar #'frame-visible-p (frame-list)) C-j C-m

[3.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

4. Switch to another workspace.  At this point Emacs thinks neither
   frame is visible (I'm guessing they're all iconified).  I know this
   because in my customised compilation-finish-functions I do a
   notifications-notify for long-running compilations, but only if the
   compilation BUF does not satisfy (get-buffer-window BUF 'visible).

5. Switch back to the workspace with Emacs.

6. Repeat steps 2-3.

[6.png (image/png, inline)]

[Message part 7 (text/plain, inline)]

Note that the unselected frame is still iconified and lacks a toolbar.
Switching to that frame using Xmonad bindings would deiconify it.

7. C-x 5 o
   [Nothing changes.]

8. (select-frame (next-frame)) C-x C-e C-m
   [Nothing changes.]

9. (select-frame-set-input-focus (next-frame)) C-x C-e

[9.png (image/png, inline)]

[Message part 9 (text/plain, inline)]

This deiconifies the frame on the right, which now receives input, but
Xmonad still thinks the frame on the left is selected.

10. C-s focus RET C-e C-x C-e
    [AKA repeat step 9.]

[10.png (image/png, inline)]

[Message part 11 (text/plain, inline)]

Back to where we started, with both frames deiconified.

11. C-x C-e
    [AKA repeat step 9.]

[11.png (image/png, inline)]

[Message part 13 (text/plain, inline)]

So to me it looks like some state/hint either on Xmonad's or Emacs' side
isn't refreshed or heeded when switching workspace.

I actually kind of like that Emacs frames on workspaces other than the
current one are considered invisible now, because of course they're not
visible :).

But switching back to that workspace should ideally make all frames
visible again.  I'm certain that there are both Xmonad and Emacs hooks
that allow the user to program this, but previously this wasn't needed.

BTW, I forgot to include in the recipe above that

  (mapc #'make-frame-visible (frame-list))

also changes nothing.  It seems that the only thing that deiconifies
frames is giving them input focus.

[ P.S. Let me know if fullscreen inline screenshots are annoying, and
  what to do instead.  I passed the images through pngquant so that at
  least their size is small. ]

> As soon as you have done that, I would like to give you a few
> instructions to make the code that broke this a NOOP and, in the worst
> case, make its execution optional on tiling WMs.

Thanks,

-- 
Basil

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-05-13 built on tia
Repository revision: 43701a84367b76ccc93ad46f89110486988eec10
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux bullseye/sid

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --enable-checking=structs
 --with-x-toolkit=lucid --with-file-notification=yes --with-x'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XPM LUCID ZLIB

Previous Next

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