Re: vesa probe is inadequate

[Lee Olsen]

Andrew C Aitchison wrote:

On Mon, 29 Mar 2004, Lee Olsen wrote:

 

The two line vbeModes.c change fixes VBEFindSupportedDepths reporting 
zero for depths
les than 15. The symptom I saw is a 512k card requesting a depth of 16, 
resulting in "No usable
modes."
   

 

diff -bc vbeModes.c*
*** vbeModes.c    Mon Mar 29 15:24:45 2004
--- vbeModes.c.orig    Thu Nov  6 10:38:14 2003
***************
*** 54,61 ****
         depth = 1;
     }
     bpp = mode->BitsPerPixel;
-     if (!depth)
-         depth = bpp;
     VBEFreeModeInfo(mode);
     mode = NULL;
     switch (depth) {
--- 54,59 ----
End of vbeModes.c changes
   

I take it that that these diffs are backwards - can you do
	diff -bc vbeModes.c.orig vbeModes.c
next time ?
 

Certainly.

I'm uneasy about this. The lines before are:
	if (VBE_MODE_COLOR(mode)) {
	    depth = mode->RedMaskSize + mode->GreenMaskSize +
		    mode->BlueMaskSize;
	} else {
	    depth = 1;
	}
	bpp = mode->BitsPerPixel;
	VBEFreeModeInfo(mode);
	mode = NULL;
	switch (depth) {
so your case must have
   VBE_MODE_COLOR(mode)
and
   mode->RedMaskSize + mode->GreenMaskSize + mode->BlueMaskSize == 0
Is this valid ?
Are we missing something else, like a difference between direct and 
indexed colours ?

 

It looks to me like direct is handled correctly and indexed is not. I 
think I'm fixing that.
All the modes I get in /var/log/XFree86.0.log  for bpp <= 8 have zero 
for all the mask sizes.
With the code that follows looking like this:
       case 1:
           return V_DEPTH_1;
       case 4:
           return V_DEPTH_4;
       case 8:
           return V_DEPTH_8;
       case 15:
           return V_DEPTH_15;
       case 16:
           return V_DEPTH_16;
       case 24:
           switch (bpp) {
           case 24:
               return V_DEPTH_24_24;
           case 32:
               return V_DEPTH_24_32;
           }
       }
   }
   if (mode)
       VBEFreeModeInfo(mode);
   return 0;

And an expected return value of V_DEPTH_8 when bpp is 8, it looked like 
a solution. Maybe not THE solution,
but a solution. While we're here, the free is too far down and is 
causing a memory leak. It should be before the
switch.
Enjoy
Lee

_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel