[Xorg] Current blocker bug list

[Kevin E Martin]

On Thu, Aug 12, 2004 at 11:49:58PM -0700, Keith Packard wrote:
> 
> Around 1 o'clock on Aug 13, Kevin E Martin wrote:
> 
> > * Bug #991: Composite exposes extra visuals
> >   - Keith Packard is working on a solution
> >   - He said he would check in a patch to disable the extra visuals in
> >     the connection block ASAP so that testing can proceed
> 
> The cure was worse than the disease.
> 
> I now recommend exposing the visual in the core protocol and teaching the 
> (very few) applications which stumble upon it what to do.
> 
> Applications which just accidentally use this visual for windows will 
> work correctly as long as no compositing manager is actually running, and 
> if they allocate colors through the X server, they will even work with a 
> compositing manager running as long as the X server hands out pixels with 
> the alpha bits set to one; I've hacked the dix/colormap code to do just 
> that without also modifying the visual structure (it uses nplanes == 32)

Sorry about that, I forgot to update this bug list entry last night with
the info from the e-mail thread yesterday.

One comment, on the release wranglers call Wedensday we talked about
going with another solution along the same lines as GLX's FBConfigs.
GLX's original solution did pretty much the same thing that you are
doing -- exposing extra visuals and confusing applications.  With
FBConfigs, GLX was able to store extra information about particular
visuals (in their case, depth buffers, stencil buffers etc.).  You could
do the same with Composite by creating a new "extended visual struct"
with any new extended visual info that you require.  Then, you could
teach Render (and any other supporting libraries) about the "extended
visual struct".  This is particularly useful if you plan to extend the
capabilities further.  If, however, you will not need any further
extensions to the visual structure, then perhaps this is overkill.

In any case, since the Composite extension is disabled by default with
the understanding that interfaces and functionality might change in the
future, I think that the solution you proposed is fine for the current
release.