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.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.