On Thu, Feb 02, 2006 at 01:42:44PM +0100, Marc Lehmann wrote: > On Thu, Feb 02, 2006 at 09:11:40AM +0100, Dominik Vogt <[EMAIL PROTECTED]> > wrote: > > > http://data.plan9.de/fvwm-2.5-argb-visual.patch > > > > Small to medium sized patches can be sent directly to the mailing > > list. That makes life for us much easier: > > Will do next time. > > > > The other small uncleanlieness is the hardwired -1 for the pixel values, > > > but that should hardly create any problems (all bits set boil down to > > > opaque white - its not visible anyways, and is guarenteed to exist in such > > > visuals). > > > > But doesn't this change break normal (non-ARGS) 32 bit TrueColor > > visuals? > > Sure, but is there reason to believe such weird beasts exist? > > One could improve the test by checking wether all masks or'ed together are > less than 32 bit. > > However, I just had a look at xlib, and it detects argb visuals simply by > comparing the depth against 32 (without any further tests, even): > > if (dp->depth == 32 && getenv ("XLIB_SKIP_ARGB_VISUALS")) > > So this seems to be the expected way to detect those visuals at the > moment.
Thinking more about the whole issue I come to the conclusion that the ARGB extension is simply broken if it cannot handle the CopyFromParent depth and visual. Is there any reason why one should have to do that manually? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
