Bug 3320 - is driFillInModes correct?
Summary: is driFillInModes correct?
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-17 15:37 UTC by Jon Smirl
Modified: 2009-10-20 09:10 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Jon Smirl 2005-05-17 15:37:59 UTC 
Are the FillInModes() functions working right? I found these two
problem when I copied the code into EGL.

drivers/dri/common/util.c
driFillInModes()

               modes->stencilBits = stencil_bits[k];
               modes->depthBits = depth_bits[k];

Shouldn't that be

               modes->stencilBits = stencil_bits[k];
               modes->depthBits = depth_bits[i];

i instead of k?

And in r200screen.c, r200FillInModes()

   depth_bits_array[0] = depth_bits;
   depth_bits_array[1] = depth_bits;

Should be

   depth_bits_array[0] = 0;
   depth_bits_array[1] = depth_bits;

This bug is probably in all of the drivers due to copying.
Comment 1 Ian Romanick 2009-10-20 09:10:34 UTC 
It appears the bug in util.c was fixed aeons ago.  The strangeness with depth_bits_array in r200 and other drivers is intentional.  On DRI1 the depth buffer is pre-allocated and always available, so there is no reason to expose visuals without it.  On DRI2 the depth buffer is allocated per-window, so DRI2 drivers should (and do) expose visuals without depth.

Closing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.