From: [RSU]G-Lite <g-...@cl...> - 2002-07-30 12:22:46
|
Well, I really couldn't be bothered doing the GUI thing again, so I took another look at the unix gfx problem. First of all, afaik vidmode can't switch depth nor visual class, right? Just resolution. So my question is, why are we testing against all visual classes in find_visual_for_depth()? Seems to me you can use: ... ============================= if (XMatchVisualInfo(x_display, screen, xdepth, DefaultVisual(x_display, screen)->c_class, &visualInfo)) visual_found = true; ============================= ... instead of the whole switch statement. If, however, I'm wrong and vidmode can switch visuals, then there's still a problem. (XMatchVisualInfo might be returning correct information in that case, btw) XF86VidModeSwitchToMode() requires a pointer to a struct XVidModeModeInfo to be passed to it, defined as: ============================= typedef struct { unsigned int dotclock; unsigned short hdisplay; unsigned short hsyncstart; unsigned short hsyncend; unsigned short htotal; unsigned short vdisplay; unsigned short vsyncstart; unsigned short vsyncend; unsigned short vtotal; unsigned int flags; int privsize; INT32 *private; } XF86VidModeModeInfo; ============================= Thing is, there's no visual class anywhere in that struct, so how do we know it's actually switching to DirectColor? (which is what XMatchVisualInfo returned) Then for something else, when forcing TrueColor (which is my default visual class), colors are scrambled. It might be inverted colors don't know for sure. (Black and white are normal, but the folder icons in Mac OS 8 are green instead of light blue and the background you get when booting from the CD (the one with the CDs on it) is green too) DirectColor is messed up too, but DirectColor messes up colors in the whole X Server, not just Basilisk II so I can't tell whether it's displaying them right or wrong there. :) -Stéphan "G-Lite" Kochen |