Window flickering when reconfiguring outputs

[wavexx]

I'd like to resurrect this old issue #127 and possibly #240.

As written in #127, it's hard to explain, but when reconfiguring outputs via xrandr, sometimes spectrwm enters a weird state where it starts to "flicker" a window under the mouse cursor (as if the window is constantly shown and hidden from the current region). I can move the mouse cursor between screens, and the flickering window will follow the cursor on the current region, still flickering at maximum refresh speed.

I don't think it's an xrandr bug at all, since spectrwm still responds to MOD+q. Once restarted, spectrwm works perfectly under the new configuration.

I experienced this while reconfiguring two screens (rare) or three screens (more common), under both the intel 915, newer intel kms and currently the amdgpu driver, so again I don't think a driver/xrandr issue at all.

This happens generally with the following sequence:

xrandr --auto
xrandr --some-output-position-reconfiguration

xrandr --auto is used to bring up newer outputs, and a subsequent xrandr call is done to reposition the screens. I do this automatically with a script, so I suspect the rapid time of events this is causing can make spectrwm enter some unhandled state.

[wavexx]

Upon closer examination, it seems that the flickering is caused by the rapid switching of two existing windows one beneath the other. As if they shared same region coordinates and were fighting for focus. Indeed one of the screens is lacking the bar when this happens. The bar is moved along when moving the mouse.

Sadly the switching is too fast to be caught on video (I'm just seeing a blur), so not very helpful.

[mvhulten]

I have a similar issue. I happened to have used xrandr for docking/undocking the laptop (two external screens). Several minutes later the problem occurred. However, the problem has also occurred here without calling xrandr recently (my ~/.xsession always calls xrandr).

I remember that it only happens (sometimes) when I cycle_layout to full-screen, none of the windows in the current workspace get focus (wind_kill with MOD+Shift+x does not work) and the screen appears to flicker, probably because all the windows try to get focus.

I am running OpenBSD-current on a Dell laptop with an Intel video output, usually connected to a Dell WD19TB dock.

[wavexx]

I recently gave the xrandr code a look for #501 and I couldn't spot an issue related to display reloading while I was at it. Maybe the focus issue is a better trail. If you can find any way to reproduce that it would be awesome.

I have some way to trigger this when adding/removing external screens, but it's not realiable and doesn't really help it always happens when I need to work on other stuff..

[mvhulten]

I am not able to (consistently) reproduce this.

When I have more time, I hope to be more useful and try to figure out what exactly triggers this problem.

[wavexx]

I was able to shed a bit more light on this issue. Looks like the issue is not in xrandr itself, but in focus management. The stack trace in such a case looks like the following:

#80514 0x00005603f0d293ac in event_drain (rt=7 '\a') at ../spectrwm.c:1617
#80515 focus_flush () at ../spectrwm.c:1627
#80516 focus_flush () at ../spectrwm.c:1624
#80517 0x00005603f0d293ac in event_drain (rt=7 '\a') at ../spectrwm.c:1617
#80518 focus_flush () at ../spectrwm.c:1627
#80519 focus_flush () at ../spectrwm.c:1624
#80520 0x00005603f0d293ac in event_drain (rt=7 '\a') at ../spectrwm.c:1617
#80521 focus_flush () at ../spectrwm.c:1627
#80522 focus_flush () at ../spectrwm.c:1624
#80523 0x00005603f0d30002 in switchws (bp=bp@entry=0x5603f1d33030, r=r@entry=0x5603f1d2c440, args=args@entry=0x7
#80524 0x00005603f0d317c5 in cyclews (bp=bp@entry=0x5603f1d33030, r=0x5603f1d2c440, args=<optimized out>) at ../
#80525 0x00005603f0d404d6 in keypress (e=0x5603f1fb4ab0) at ../spectrwm.c:11638
#80526 event_handle (evt=0x5603f1fb4ab0) at ../spectrwm.c:13769
#80527 0x00005603f0d293ac in event_drain (rt=7 '\a') at ../spectrwm.c:1617
#80528 focus_flush () at ../spectrwm.c:1627
#80529 focus_flush () at ../spectrwm.c:1624
#80530 0x00005603f0d30002 in switchws (bp=bp@entry=0x5603f1d32fe0, r=r@entry=0x5603f1d2c440, args=args@entry=0x7
#80531 0x00005603f0d317c5 in cyclews (bp=bp@entry=0x5603f1d32fe0, r=0x5603f1d2c440, args=<optimized out>) at ../
#80532 0x00005603f0d404d6 in keypress (e=0x5603f1fd3360) at ../spectrwm.c:11638
#80533 event_handle (evt=0x5603f1fd3360) at ../spectrwm.c:13769
#80534 0x00005603f0d4428f in main (argc=<optimized out>, argv=<optimized out>) at ../spectrwm.c:13957

Aside from the starting condition, focus_flush can enter an infinite recursive loop, where some existing event is not removed from the queue before we call event_drain() and process it again. This can happen in several places (among those, focusin), and does explain the continuous focus cycling. In the case above I attached to the wm too late to see the real starting cause (note the stack depth ;)).

[LordReg]

This is a window remap/remanage cycle triggered by rapid/simultaneous randr screen change events. Basically, it can occur when a second screenchange event is handled before the notify events generated from the first are handled.

I'll be pushing a batch of fixes/improvements which includes a fix for this and #224/related. In the mean time, it is possible to workaround this issue by adding a delay between successive xrandr calls.

[wavexx]

Having a fix for both would be awesome, do you think it's something which will happen relatively soon? (as in "breathing in a bag due to anxiety" soon? ;))

[tarwinmuralli]

Hi, I have been having the exact same problem as mvhulten and I am running Artix. This problem does not even happen when I connect my laptop to an external monitor. It just happens when I am cycling through different layouts and during full screen the flicker starts to happen .Has there been a fix? I am still having this issue and I have to kill xinit every time this happens. It's really annoying.

[wavexx]

:love_letter: biggest xmas gift ever :))) Thanks @LordReg