The setDisplayMode() specification is not clear about the interpretation of the
BIT_DEPTH_MULTI constant.  This has become an issue now that DisplayMode
switching and fullscreen exclusive mode are available on Linux, where we have
historically used BIT_DEPTH_MULTI to describe the bit depth on those
configurations.

There are a couple questions to address here:

- Should we interpret BIT_DEPTH_MULTI as "any bit depth"?  For example, if an
application calls setDisplayMode() with BIT_DEPTH_MULTI, should we just select
any available DisplayMode that matches otherwise (width, height, refresh rate)?
(This is similar to the question posed in 5041225, where we now will pick some
DisplayMode if the user specifies REFRESH_RATE_UNKNOWN, as long as the mode
matches otherwise (the width, height, and bit depth all match.)

- Likewise, if the application tries to set a DisplayMode with a bit depth of,
say 32, should we treat that as a successful match to BIT_DEPTH_MULTI?  Many
fullscreen apps have been written already with Windows in mind, where 32-bit
DisplayModes are almost always available, so developers may be in for a surprise
when they try their app on Linux, where 32-bit mode may not be enabled for
their particular configuration.  (Many distros default to 16-bit mode, for
example...)

There are no clear cut answers here, but we should give these issues some
thought to help solidify the spec in this area.

N/A

Should be clarified in the Mustang timeframe, since display mode switching and
fullscreen exclusive mode will be possible on Linux in that release.
  xxxxx@xxxxx   2004-08-30
After some discussion, I think we've determined that the answer to both
questions above should be "no", so we should clarify the spec to that extent.
This will be addressed as part of the fix for 6430607.  Transferring to the
engineer responsible for that fix.
Posted Date : 2006-07-25 23:03:36.0