Bug 1264589 - Background doesn't redraw when windows are moved
Background doesn't redraw when windows are moved
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
22
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-18 18:53 EDT by Tethys
Modified: 2016-07-19 15:18 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 15:18:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot (112.45 KB, image/png)
2015-09-18 18:53 EDT, Tethys
no flags Details

  None (edit)
Description Tethys 2015-09-18 18:53:13 EDT
Created attachment 1075090 [details]
Screenshot

Description of problem:
When moving a window, the background is not redrawn behind it,
resulting in the "windows solitaire cascade" effect seen in the
attached screenshot.

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.17.2-2.fc22.x86_64
xorg-x11-server-common-1.17.2-2.fc22.x86_64
xorg-x11-xinit-session-1.3.4-8.fc22.x86_64


How reproducible:
Every time

Steps to Reproduce:
1. Install fvwm
2. Select it from the gdm menu and log in
3. Open a window and move it around

Actual results:
See attached screenshot

Expected results:
Window moves without display issues

Additional info:
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
xorg-x11-xinit-session).

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,
openbox, xfce/xfwm4).

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

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
since then.
Comment 1 Fedora End Of Life 2016-07-19 15:18:45 EDT
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.