By default, FVWM uses `CopyFromParent' to create a new window, which would override application's own favorite visual. This generically is not good, if a client want to make use of the ARGB visual supplied by Xorg. Reproducible: Always Steps to Reproduce: 1. Use FVWM as your WM for X 2. Start xcompmgr to enable composition 3. Run x11-misc/cairo-clock Actual Results: Cairo-clock is surrounded by black box, which means it doesn't use the ARGB visual. Expected Results: It should show without the black box. This patch I grabbed from the web[1] makes FVWM pay respect to client's choice of ARGB visual. I don't know who I should give credit to. It works on fvwm-2.5.18-r1. [1] http://data.plan9.de/fvwm-2.5-argb-visual.patch It's very short, so I'll just append it here. ###### fvwm-2.5-argb-visual.patch ###### ? reconf ? debian/Makefile.on Index: fvwm/add_window.c =================================================================== RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v retrieving revision 1.374 diff -u -p -r1.374 add_window.c --- fvwm/add_window.c 29 Jan 2006 09:57:18 -0000 1.374 +++ fvwm/add_window.c 1 Feb 2006 15:17:11 -0000 @@ -782,9 +782,31 @@ static void setup_frame_window( FvwmWindow *fw) { XSetWindowAttributes attributes; - int valuemask; + int valuemask = CWBackingStore | CWBackPixmap | CWEventMask | CWSaveUnder | CWCursor; + int depth; + Visual *visual; + + /* + * We assume that a truecolour visual of depth 32 is + * actually an ARGB visual (hard to detect otherwise) + * in this case, clone the window visual/cmap etc. + */ + if (fw->attr_backup.visual->class == TrueColor + && fw->attr_backup.depth == 32) + { + depth = fw->attr_backup.depth; + visual = fw->attr_backup.visual; + attributes.colormap = fw->attr_backup.colormap; + attributes.background_pixel = -1; + attributes.border_pixel = -1; + valuemask |= CWColormap | CWBackPixel | CWBorderPixel; + } + else + { + depth = CopyFromParent; + visual = CopyFromParent; + } - valuemask = CWBackingStore | CWBackPixmap | CWEventMask | CWSaveUnder; attributes.backing_store = NotUseful; attributes.background_pixmap = None; attributes.cursor = Scr.FvwmCursors[CRS_DEFAULT]; @@ -793,8 +815,8 @@ static void setup_frame_window( /* create the frame window, child of root, grandparent of client */ FW_W_FRAME(fw) = XCreateWindow( dpy, Scr.Root, fw->frame_g.x, fw->frame_g.y, - fw->frame_g.width, fw->frame_g.height, 0, CopyFromParent, - InputOutput, CopyFromParent, valuemask | CWCursor, &attributes); + fw->frame_g.width, fw->frame_g.height, 0, depth, + InputOutput, visual, valuemask, &attributes); XSaveContext(dpy, FW_W(fw), FvwmContext, (caddr_t) fw); XSaveContext(dpy, FW_W_FRAME(fw), FvwmContext, (caddr_t) fw); ###### END of FILE ######
Did you submit this upstream? (Please, don't inline patches, it breaks formatting; use attachments instead).
Created attachment 114441 [details, diff] respect client's choice of argv visual It's the same as the inline one. Sorry again.
Sorry, I'm not familiar with this bugzilla system. I didn't know I can attach file when I submitted the bug. I was trying to find out who first made this hack and if the upstream has already known this. I'll fire it upstream, now.
(In reply to comment #3) > I was trying to find out who first made this hack and if the upstream has > already known this. I'll fire it upstream, now. Once again, any link for upstream bug?
I think there is no bug upstream and is not likely to be included in fvwm at any time soon (or at least in this form). This is the thread on the fvwm-workers ml: http://osdir.com/ml/window-managers.fvwm.devel/2006-02/msg00000.html
In case there's someone looking at this still, A patch for argb visuals was included some time ago in fvwm (like months or so don't remember exactly). I've tried cairo clock and it seems to run just fine, just like urxvt. Can you test this against the latest fvwm? I think that the patch was included around 2.5.25, but I can't be sure it's the same (or equivalent) patch, however compositing seems to work fine for those apps. I am trying to get 2.5.26 (or .27) stabilized, so if more people could test this, we could close this bug. In any case, this is not a show stopper, since it belongs upstream and it's not what I call a must-have for a window manager (it's rather a feature request), but nonetheless it'd be a good thing to close one more bug.
We will stabilise 2.5.27 soon, so closing.
