Bug 1736

what hardware are you using?  what xcompmgr version?

I'm using xcompmgr-1.1 and a SiS300/305 video card, yeah yeah, I know, SiS blows
the dog, but it's all I got

(In reply to comment #0)
> loading xcompmgr cause the background image to be replaced by solid grey. None 
> of the *setbg(fbsetbg, xsetbg, etc) utilites will change the bg from this 
> grey. I have this problem with the following wm's: , blackbox, openbox, aewm, 
> aewm++, evilwm, fvwm, xfce, enlightenment. Also in enlightenment, moving a 
> window once xcompmgr is loaded cause it to leave ghost iamges of that window 
> around the screen, and they don't go away until after xcompmgr is killed.

Same thing happens under vtwm, when a root window image is set with
using xv.  Root window becomes smooth solid grey50 when xcompmgr (v1.1.1)
is started.  Talking about Xorg-6.8.1 cvs Dec 24 10:38 MET.
Does not happen when root window is set using redhat's xsri tool.
Hardware: nvidia geforce4, drivers 6111, 6629.  This is with RendelAccel disabled.

With RenderAccel enabled, root window basically becomes some messy random
pattern.


Here's an overview of some tests I did:


General notes that apply to all tests
=====================================
- nvidia_drv is version 6629
- xsri and xv: tiling the root background starts at (0,0), not at the center of
screen
- display: virtual 2000x1600
- in subsection Extensions: both Composite and RENDER enabled (xcompmgr needs
them both enabled)
- in subsection Display:
  Modes		"1024x768" "1280x1024"
  ViewPort	0 0
  Virtual	2000 1600
- (II) NVIDIA(0): Setting mode "1024x768"
- xcompmgr -f -D 8 -I 0.025 -O 0.025 -l -5 -t -5 -c -r 8
- messed up means: some random pixel-mix like pattern
- in Tests I and II, vtwm always unresponsive after killing xterms/windows; this
also
  affects keyboard; keyboard seems to be in messed up state such that for instance
  keypad left/right arrows now perform ctrl-left/right action in editor joe;
iconifying
  a window by clicking on the titlebar button always keeps working though...;
  de-iconifying does not work anymore though.  After switching to VT and back to
Xserver,
  the keyboard and mouse are sane again, and e.g. vtwm menu popups also work again;
  everything ok except of course messy background.  Background is always restored to
  good original state after exiting xcompmgr.



Tests I:
========
- RenderAccel + nvidia_drv in otherwise standard xorg.conf

xsri:
-----
	2 1
	0 6
	0 0	root bg after		vtwm menu popup
	0 0 8 8	xcompmgr startup	effect on root bg
		----------------	--------------------------------
8x8	0 0 0 0	messed up		sets former popup region to correct bg pattern
8x10	0 0 0 1	messed up		sets former popup region to correct bg pattern
10x8	0 0 1 0	messed up		sets former popup region to correct bg pattern
16x16	0 0 0 0	messed up		sets former popup region to correct bg pattern
63x63	1 1 1 1	messed up		messed up
64x64	1 0 0 0	messed up		messed up
100x100	0 0 1 1	messed up		messed up
102x100	1 0 1 1	messed up		messed up
297x233 1 1 1 1	messed up		messed up


xv:
---
	2 1
	0 6
	0 0	root bg after		vtwm menu popup
	0 0 8 8	xcompmgr startup	effect on root bg
		----------------	--------------------------------------------
8x8	0 0 0 0	messed up		sets former popup region to smooth grey50 bg
8x10	0 0 0 1	messed up		sets former popup region to smooth grey50 bg
10x8	0 0 1 0	messed up		sets former popup region to smooth grey50 bg
16x16	0 0 0 0	messed up		sets former popup region to smooth grey50 bg
63x63	1 1 1 1	messed up		sets former popup region to smooth grey50 bg
64x64	1 0 0 0	messed up		sets former popup region to smooth grey50 bg
100x100	0 0 1 1	messed up		sets former popup region to smooth grey50 bg
102x100	1 0 1 1	messed up		sets former popup region to smooth grey50 bg
297x233	1 1 1 1	messed up		sets former popup region to smooth grey50 bg
notes:
- exit of xcompmgr: xv background pattern reset correctly



Tests II:
========
- RenderAccel disabled + nvidia_drv in otherwise standard xorg.conf (horribly slow)

xsri:
-----
	2 1
	0 6
	0 0	root bg after		vtwm menu popup
	0 0 8 8	xcompmgr startup	effect on root bg
		----------------	--------------------------------
8x8	0 0 0 0	
8x10	0 0 0 1	
10x8	0 0 1 0	
16x16	0 0 0 0	
63x63	1 1 1 1	correct 63x63 pattern	leaves it intact
64x64	1 0 0 0	
100x100	0 0 1 1	
102x100	1 0 1 1	
297x233 1 1 1 1	


xv:
---
	2 1
	0 6
	0 0	root bg after		vtwm menu popup
	0 0 8 8	xcompmgr startup	effect on root bg
		----------------	--------------------------------
8x8	0 0 0 0	
8x10	0 0 0 1	
10x8	0 0 1 0	
16x16	0 0 0 0	
63x63	1 1 1 1	smooth grey50 (not ok)	leaves it intact (smooth grey50)
64x64	1 0 0 0	
100x100	0 0 1 1	
102x100	1 0 1 1	
297x233 1 1 1 1	
- after exiting xcompmgr, root bg is restored from grey50 to the pattern

Additional note on my tests: the messed up server background looks much
like the images attached to bug #1262, 'cept for different coloring and
some different pattern.

bjd

(In reply to comment #4)
> Additional note on my tests: the messed up server background looks much
> like the images attached to bug #1262, 'cept for different coloring and
> some different pattern.
> 
> bjd
> 

Ok, I was about to make a separate bug report for the buggy keyboard/
vtwm behaviour after logging out of an xterm with xcompmgr running,
but it seems now I can't replicate that behaviour anymore.  Everything
is fine in that regard.

It may be that this was only under the stock Xorg-6.8.1.  I will
investigate tomorrow, since I still have that tree around, 'cause now
I'm curious about that and if it's fixed it deserves mention here, since
I brought it up.  Could have been possbily have been fixed in my cvs.
More later.

bjd

(In reply to comment #5)
> (In reply to comment #4)
> > Additional note on my tests: the messed up server background looks much
> > like the images attached to bug #1262, 'cept for different coloring and
> > some different pattern.
> > 
> > bjd
> > 
> 
> Ok, I was about to make a separate bug report for the buggy keyboard/
> vtwm behaviour after logging out of an xterm with xcompmgr running,
> but it seems now I can't replicate that behaviour anymore.  Everything
> is fine in that regard.
> 
> It may be that this was only under the stock Xorg-6.8.1.  I will
> investigate tomorrow, since I still have that tree around, 'cause now
> I'm curious about that and if it's fixed it deserves mention here, since
> I brought it up.  Could have been possbily have been fixed in my cvs.
> More later.
> 
> bjd
> 

I cannot replicate the buggy keyboard/pointer anymore, which in a sense
is good I guess.  It's possible it was related to bug #2228.

bjd

Reporter: Can this be closed now?

Reporter: Can this be closed now? I certainly don't see this with KWin or with
GNOME's wm metacity on different hardware (radeon).

close it if and only if xcompmgr is actually working with more wm's, not dm's
like kde and gnome, which I don't use, and never will use. And last i checked,
gnome only had fake alpha blending, not true alpha blending like xcompmgr provides

It's worth mentioning that gnome (dunno about kde) uses nautilus for desktop
icons which provides a borderless, titleless window that sits on top of the root
window.  So you wouldn't be able to see the bug described here using it.

Has anyone looked into this issue lately?  I still see it on all the systems
I've tried to use xcompmgr (w/ nvidia and ati, with hw accel turned on).  Is
there a work-around available, or some other software I should be using other
than xcompmgr?

Isn't this by design? The compositing manager renders the composited desktop to
the root window, so I'm not sure rendering done by other clients to the root
window is supposed to be preserved.

Is this still an issue ? I am also thinking that Michel is right, it's a design of compositing so root window might not be preserved.

Closing per above comments from years ago.