After playing with Option "Overlay" with my G400, I think I know why most apps only run on the default visual-- it's well nigh impossible to do anything useful on the overlay visual.
It's a little annoying that the default visual is 8 bit PseudoColor and there's no way to make it 24 bit TrueColor from th XF86Config, but that's surmountable on the commandline. It's also annoying that there's no good way to specify an alternate visual using standard X Toolkit options and that the only way I can find to do it with Motif involves somehow specifying a Visual * (not a Visual ID) via a resource. That leaves me required to write special code and making up an application specific way of specifying the visual. It's also annoying, but understandable, that the window manager doesn't handle the colormap correctly when a PseudoColor window is enclosed in a TrueColor toplevel. Just installing a window colormap get ignored and so the PsuedoColor window needs to call XInstallColormap() explicitly when it has focus. The most annoying, however, has got to be dealing with the colormap on the PseudoColor visual. XCreateColormap() is happy to claim to give me a 256 entry colormap, but, I'm assuming because of how the overlay works, entry 255 (the topmost) doesn't work. What's interesting is how it doesn't work... I'm guessing that the hardware uses the value 0xff in the high 8 bits to signal that the bottom 24 bits (i.e. the TrueColor portion) should be displayed. That means that I'd expect any pixel in my Window with a value of 0xff to show whatever the last TrueColor pixel displayed at its current position (in the host framebuffer) and, indeed, with a toplevel overlay window, I do see any obscured TrueColor windows start to bleed through. However, if instead my PseudoColor window is a child of a TrueColor window, then the 0xff pixels of the PseudoColor window display appear with whatever pixel is in the corresponding pixel of the TrueColor window, even though the TrueColor window is completely obscured by its child. That makes it seem like the server considers 24 and 8 bit windows independently, at least for clipping and obscuring calculations. That's kind of cool, because it presents me an excellent way to fake that 256 palette entry (the one that's stolen from the PseudoColor visual to key the overlay)-- convert it to TrueColor and make it the background of the enclosing TrueColor window. The catch is that no amount of contortion on my part appears to be able to programattically redraw the TrueColor window when its background changes. Here's the progression: Initially, the TrueColor window is solid black. Whenever the PseudoColor window fills in its topmost colormap entry, I convert its color to its corresponding 24 bit TrueColor value and pass it to XSetWindowBackground(). Unfortunately, all of the 'transparent' PsuedoColor pixels remain (or the old background color of the TrueColor window) until I drag the whole thing (TrueColor window and enclosed PseudoColor window) off the screen and back on, or obscure it, or something else. As soon as I obscure and re-expose it, the new background shows through and the PseudoColor window looks like all 256 colors are correct. I assumed that meant I had to call XClearWindow() on the TrueColor window after changing its background, but that didn't help. Maybe XClearWindow() does think the TrueColor window is obscured, even though the server clearly doesn't. So, I tried calling XClearWindow() on both the TrueColor window and the PsuedoColor window and then redrawing the whole PseudoColor image. No improvement, just a whole lot of flicker. So, clearly putting another toplevel window on top of the TrueColor window and removing it forces both the TrueColor window to redraw in its new background color and the PseudoColor window to redraw its correct contents, but nothing I can do in the code to try and mimic that works. Any notions? -Jeremy. P.S. Note that this all implies that this means that, if it cared to, the G400 driver could actually honor all 256 colormap entries. For the bottom 255 it would use the colormap for the 8 bit display and for the topmost it would fill in the 24 bit display with the correct color. It'd just make it really expensive to change the topmost entry in the colormap and, if clipping / obscuring is really being done separately for the different depths, it'd confuse that too. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
