Red Hat Bugzilla – Bug 1264589
Background doesn't redraw when windows are moved
Last modified: 2016-07-19 15:18:45 EDT
Created attachment 1075090 [details]
Description of problem:
When moving a window, the background is not redrawn behind it,
resulting in the "windows solitaire cascade" effect seen in the
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install fvwm
2. Select it from the gdm menu and log in
3. Open a window and move it around
See attached screenshot
Window moves without display issues
I initially thought this was a driver issue, so I bought an ATI card
to use instead of the onboard Intel graphics I'd been using. However,
I saw exactly the same issue, which more or less ruled out that theory.
I tried experimenting with different window managers and desktop
environments, to see if it was fvwm at fault. The window manager could
be selected either from the gdm menu, or started via a .Xclients
file when "user script" was selected from the menu (as provided by
The results showed a mix of those that worked when started by both
methods (windowmaker, blackbox), those that didn't work with either
method (fvwm, pekwm) and more interestingly, those that worked when
started from the menu, but not when started from .Xclients (icewim,
I picked one of those at random (openbox), and tried to see what the
difference was between the two invocation methods. It turned out to
be something unexpected. /usr/libexec/openbox-autostart is only called
when started from the menu, and it invokes:
xsetroot -solid "#303030"
Comment that line out, and it fails. Leave it in and all is good.
Sure enough, running xsetroot under fvwm or pekwm fixes the issue.
My guess is that there's some internal state in the server that is
incorrect at startup but fixed when modifying the root background.
FWIW, it's not just xsetroot. If I set the background using xv, it
also fixes the problem. It's a usable workaround, but the X server
should really be in a sensible state as shipped, without needing
Note that on the same hardware, it was fine with my previous Fedora
release (IIRC, that was 19). So it's something that's been introduced
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.