xcompmgr messing with openbox windows (conky and kde apps only)

brisbin33 · 2008-12-17 15:51:15

here's the involved packages:

openbox 3.4.7.2-1
nvidia 177.82-1
xorg-server 1.5.3-3
xcompmgr 1.1.4-1
kdelibs3 3.5.10-2
conky 1.6.1-2

now the issue is primarily with xcompmgr. when it's running (default options or the whole -cCfF... stuff doesn't make a difference). i have the following:

whenever a kde apps window opens. (i.e. i start amarok or k3b; k3b opens new windows during burn start/stop process) my conky will disappear only to flicker and reappear a few seconds later. (this only happens with kde apps)

when i'm tweaking my conky i will often `pkill conky; sleep 3; conky` to see my changes. when i kill conky, ALL of my active windows on the current desktop disappear and only reappear if a) they are redrawn because of an update to their contents on their own accord, or b) (kinda the same thing) i grab a window and drag it all over the screen resetting whatever i pass over to it's correct visual state. (this only happens when killing conky)

this is annoying me, i love the shadows/fading from xcompmgr but this flickering makes my whole experience feel unstable and i have to turn it off after a few minutes. turn off xcompmgr and it's rock solid just as before... snappier too i think.

this behavior started immediately after the recent xorg update (i saved that for last because i know were all sick of _that_). i changed nothing, but for the -Syu when this happened.

anyways, your thoughts and help is much appreciated.

Xappe · 2008-12-17 17:14:11

I've also noticed some strange behaviour from k3b in openbox with xcompmgr running...after successful burn the window disappears until I move it...

Barghest · 2009-01-03 09:32:45

Same here (Openbox + xcompmgr). I also installed amarok just to test if other kde apps are affected, too...

...they are. When startting k3b or amarok all Windows disappear until I switch to another desktop and back again.

moljac024 · 2009-01-03 11:55:15

So, that's a lesson to you - don't use xcompmgr

I can confirm this btw, I ran xcompmgr yesterday and openbox was really confused...

Barghest · 2009-01-04 08:49:57

moljac024 wrote:

So, that's a lesson to you - don't use xcompmgr
I can confirm this btw, I ran xcompmgr yesterday and openbox was really confused...

But I like these nifty shadows so much. Otherwise the screen looks so "flat"

Since k3b is the only app I use that interferes with xcompmgr (+ conky when I kill it) and I don't burn that often I'll stick with it (There isn't another composite manager that runs with openbox, isn't it?).

Super Jamie · 2009-01-05 05:56:54

moljac024 wrote:

So, that's a lesson to you - don't use xcompmgr
I can confirm this btw, I ran xcompmgr yesterday and openbox was really confused...

Actually, I'd say it's more a problem with KDE playing happily with xcompmgr.

I use openbox+xcompmgr on a GTK-only desktop, never have any problems, and love the fact I can run proper terminal transparency without loading a whole compositing window manager.

brisbin33 · 2009-01-05 13:59:51

Super Jamie wrote:

Actually, I'd say it's more a problem with KDE playing happily with xcompmgr.
I use openbox+xcompmgr on a GTK-only desktop, never have any problems, and love the fact I can run proper terminal transparency without loading a whole compositing window manager.

i'd take your GTK only approach if urxvt didn't vanish on me everytime i kill/reload conky .

transparent urxvt is probably the only thing i really miss when not running xcompmgr.

downgrading xorg just seems like so much work...

Super Jamie · 2009-01-05 21:50:59

Can you use a replacement vte-based terminal? Roxterm is quite good. If you're looking for something borderless, stjerm is a minimalist dropdown solution, and tilda is pretty configurable.

brisbin33 · 2009-01-16 15:52:09

anyone having this problem know if today's upgrade to nvidia 180 fixes it? i can't check until tonight.

edit: it does not... downgrading again...

Last edited by brisbin33 (2009-01-22 15:31:55)

brisbin33 · 2009-03-05 01:19:13

so i'm resurrecting this thread because i hoped, and prayed, that xorg 1.6 in testing would fix this problem. i've been working my ass off to keep my system back in xorg 1.4. my desktop just looks so oldfashioned w/o shadows and transparency.

ok so to re-outline, i'm running:

pacman -Q stuff
xorg-server 1.6.0-1
nvidia 180.29-3
openbox 3.4.7.2-1
xcompmgr 1.1.4-1

with this gpu:

  hwd -s | grep video
   Video      : GeForce 7150 / nForce 630i server: XFree86 (vesa)

i created a minimal xorg.conf via nvidia-xconfig an added a few suggested options (although they _really_ don't seem to affect this bug...):

cat /etc/X11/xorg.conf
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 1.0  (buildmeister@builder62)  Thu Feb  5 00:08:50 PST 2009


Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    Option         "NoLogo" "True"
    Option         "RenderAccel" "True"
    Option         "TripleBuffer" "True"
    Option         "BackingStore" "False"
    Option         "DamageEvents" "True"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

now, here's what happens:
i startx, .xinitrc or autostart.sh bring up xcompmgr, bmpanel, and conky
if i open amarok or k3b, conky and bmpanel (both using transparency) vanish while the splash screen(s) show.
when i burn something with k3b (and new windows appear) i see similar behavior
sometimes it's just for a sec and then it's back, sometimes conky comes back with part of itself missing
also, if you execute `pkill conky` from an xterm, all windows are 'destroyed' until you [blindly] grab that xterm window and move it about your desktop 'revealing' the desktops contents. please see this screenshot for this in action.

killing xcompmgr fixes all this... but it's so ugly. the problems go away if i downgrade to xorg-server 1.4 (and also adjust any related/dependant packages to match).

please please, tell me i'm not alone! a fix would be nice too .

thanks in advance... again

Last edited by brisbin33 (2009-03-05 01:30:10)

LeoSolaris · 2009-03-05 13:50:36

Since I so rarely ever use KDE apps, (in fact I am not really sure I have any) all I do to keep this from happening is kiss xcompmgr right before messing with conky, then once I have conky set, I log out and back in to get the right xcompmgr settings. Otherwise I just switch desktops back and forth to make it redraw.

I haven't found another solution to this issue yet, but if one presents itself, I'll definitely let you know.

brisbin33 · 2009-03-08 20:47:08

i installed xcompmgr-dana from AUR, it's a fork of version 1.1.3. it makes this bug a little less annoying but still present. it also introduces a new bug where shadows are drawn on conky no matter what options i choose in conkyrc. does anyone have a vanilla xcompmgr 1.1.3 package so i could test?

Last edited by brisbin33 (2009-03-08 20:48:38)

pierce.jason · 2009-03-13 00:53:36

I've a similar problem that is not precisely related, but feels vaguely similar. When spawning an Eterm (with transparency set, or fully opaque) inside openbox, lxpanel freaks out a bit. Sometimes lxpanel goes half-transparent, sometimes the lxpanel process alltogether dies. Eterm uses its own internal fake-transparency when xcompmgr isn't installed(or maybe it uses internal always?), and I do not have xcompmgr installed.

K0tuk · 2009-04-30 07:42:43

I have the same problem also... Seems like i`ll have to disable xcompmgr for now, until the problem is fixed

K0tuk · 2009-05-29 11:43:18

I`m not 100% sure, but looks like upgrading conky to a 1.7.1_rc1 version solved the issue with xcompmgr and conky. KDE apps are still glitchy though.

Last edited by K0tuk (2009-05-29 11:43:31)

bernarcher · 2009-05-29 21:16:17

I experience similar problems in IceWM when windows were expanded/shrunk other than by the maximize/minimize buttons. I "resolved" it through stopping/restarting xcompmgr. Apparently there is a buffer copy problem, where xcompmgr does not get properly notified of the screen situation change. Restarting forces it to rewrite the screen contents properly again.

I've put a short script in the wiki: Starting/Stopping xcompmgr on Demand. Binding two keys to the COMP (restart) and COMP -s (stop) commands provided there did reduce screen maintenance to some single keypresses every now and then. Thus I can also disable/reenable xcompmgr in some scripts, e.g. before an mplayer call for video viewing.

kazuo · 2009-05-29 23:12:51

I'm replaced my xcompmgr by cairo-compmgr (in aur, the version need to be updated). It solve the k3b problem for me

brisbin33 · 2009-05-29 23:51:59

hmm, cairo-compmgr built/installed once i added x86_64 to the PKGBUILD but when i started it... nothing happened... either i'm missing something or it's not 64bit compatable... either way i'm left with psuedo-buggy xcomp for now.

thanks for the info though.

bernarcher · 2009-05-30 08:05:52

@brisbin33:

Now I did a short check with an LXDE/Openbox session. While I can confirm your problem (btw. it occurs in IceWM as well), it appears to be neither the fault of xcompmgr nor conky alone.

The problem imo stems from the fact that both attempt to directly write onto the desktop without knowing of each other. So, if e.g. conky tries to alter the desktop or gets disturbed otherwise, the xcompmgr buffers get out of sync. It is rather drastic here when I do a "killall conky", which will affect almost any screen content as long as xcompmgr runs. Yet a simple xcompmgr restart cures that without (hopefully) messing with other running applications.

Just out of interest, could you try some similar in your setup. Instead of restarting cony, restart xcompmgr. It is still awkward, imho, but less obtrusive in my opinion.

brisbin33 · 2009-05-30 15:45:23

bernarcher

thanks for your interest, i was definitely heading down that line of thought when originally posted this thread. i thought it might've been related to some 'null pixmap' errors i was seeing when starting certain apps. i even tried various ways of setting the background (feh, nitrogen, pcmanfm) thinking maybe that was it. no joy.

i'm not quite sure what you want me to 'try' though, the ultimate solution i wanted was a desktop that didn't go all skrewy when i launch amarok or killall conky as you say. i new from the beginning that killing or restarting xcompmgr 'fixed' the situation in that moment.

personally, i took a slightly different approach. i wrote some scripts to handle all my burning needs and switched to mpd for music. amarok and k3b were the only affected apps i used to use so that's done... and now if i mess with conky i just kill xcompmgr before or restart it after. your script or some alias/function can handle that nicely.

bernarcher · 2009-05-30 23:47:58

Thanks brisbin.

I just wanted to know whether the xcompmgr restart trick would work in your setup as well. I "invented" the COMP script mainly to get my Idesk icons display right on the IceWM background. They would produce ugly shadows without.

BTW do you still run xcompmgr-dana? Is this more stable than vanilla xcompmgr? I get screen update issues especially with firefox running aside urxvt two or three times the hour. Although this is cured with a single keypress, it remains annoying.

Let's wait for a stable xcompmgr version coming out soon (hopefully). I like those fading effects in my otherwise simple IceWM setup.

brisbin33 · 2009-05-30 23:55:28

xcompmgr-dana made the bug less obtrusive but still present and it intruduced a new one where shadows were drawn on conky no matter my settings... after about a week i just went back to the repo version.

DonVla · 2009-05-31 10:00:11

hey brisbin33,

have you tried xcompmgr-git?
i had the problems you described - mainly the conky flicker - some months ago when i tried xcompmgr (not git but from extra).
now i gave it another try and works fine wth conky/kde/etc. i guess you know that for conky you need this:

own_window 1
own_window_type override
own_window_transparent

vlad

ps: i use this xcompmgr command:

xcompmgr -nfF -D 6

Last edited by DonVla (2009-05-31 10:01:48)

bernarcher · 2009-05-31 10:26:22

@DonVla

I did not try xcompmgr-git as it is flagged out of date. But on second thought, it is git after all. Are there any PKGBUILD problems (dependencies etc.) or whatever for having this flag set?

Maybe I'll try again once I've got time again to fiddle with my system.

DonVla · 2009-05-31 11:24:56

bernarcher wrote:

@DonVla
I did not try xcompmgr-git as it is flagged out of date. But on second thought, it is git after all. Are there any PKGBUILD problems (dependencies etc.) or whatever for having this flag set?

actually, flagging git PKGBUILDs ood does not make much sense.
and no there are no PKGBUILD problems afais. it built fine here.

Arch Linux

#1 2008-12-17 15:51:15

xcompmgr messing with openbox windows (conky and kde apps only)

#2 2008-12-17 17:14:11

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#3 2009-01-03 09:32:45

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#4 2009-01-03 11:55:15

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#5 2009-01-04 08:49:57

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#6 2009-01-05 05:56:54

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#7 2009-01-05 13:59:51

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#8 2009-01-05 21:50:59

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#9 2009-01-16 15:52:09

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#10 2009-03-05 01:19:13

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#11 2009-03-05 13:50:36

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#12 2009-03-08 20:47:08

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#13 2009-03-13 00:53:36

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#14 2009-04-30 07:42:43

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#15 2009-05-29 11:43:18

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#16 2009-05-29 21:16:17

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#17 2009-05-29 23:12:51

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#18 2009-05-29 23:51:59

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#19 2009-05-30 08:05:52

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#20 2009-05-30 15:45:23

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#21 2009-05-30 23:47:58

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#22 2009-05-30 23:55:28

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#23 2009-05-31 10:00:11

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#24 2009-05-31 10:26:22

Re: xcompmgr messing with openbox windows (conky and kde apps only)

#25 2009-05-31 11:24:56

Re: xcompmgr messing with openbox windows (conky and kde apps only)

Board footer