On Mon, Oct 04, 2004 at 04:24:19PM -0700, Ian Romanick wrote: > Ian Romanick wrote: > > >It looks like destination alpha was disabled in the DDX at some point. I > >seem to remember some discussion about this a long time ago. Do any of > >the DRI developers remember why this was done? > > So, I found this in the archives: > > http://marc.theaimsgroup.com/?l=dri-devel&m=104456147219701&w=4 > > It looks like, basically, there was a bug in the span read function. > Rather than fixing it, destination alpha was just disabled. > > If the DDX is modified to export visuals with an alphaSize of 8 and a > bufferSize of 32, the attached patch should fix things. As noted in the > comment in the patch, this will break RGB888 visuals (e.g., using this > patch with an unmodified DDX). > > I think the right answer is to apply the fix for reading alpha from the > framebuffer and ignore the 888 modes. Since the hardware is operating > in 8888 mode, pretending to be 888 is just wrong. We'd have to go > through and make sure that 0xff is *always* written as the output from > the alpha blend stage in 888 mode. Yuck.
The 888 mode would be useful for the 24+8 overlay case if we change it to not touch the alpha bits. But the drm would require a small change since the swap ioctl always sets PLNWT to 0xffffffff. I actually have (in my Mesa 5 for DirectFBGL tree) span functions for (a)rgb 332, 555, 1555, 565, 888, 8888, and depth/stencil 16/0, 32/0, 15/1, 24/8. The 555 and 888 functions don't touch the alpha bit(s). I have quite a lot of changes in my Mesa 5 tree actually. Guess I really should bite the bullet and flip over to the XFree86/XOrg (ie. dark) side for a while... > I guess this is a case where the DDX version should get a bump and the > DRI driver should check for the new version? > ? src/mesa/drivers/dri/mga/depend > Index: src/mesa/drivers/dri/mga/mga_xmesa.c > =================================================================== > RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/mga/mga_xmesa.c,v > retrieving revision 1.32 > diff -u -d -r1.32 mga_xmesa.c > --- src/mesa/drivers/dri/mga/mga_xmesa.c 4 Oct 2004 22:58:39 -0000 1.32 > +++ src/mesa/drivers/dri/mga/mga_xmesa.c 4 Oct 2004 23:14:57 -0000 <snip> I dislike this fill in modes code. My preference would be that the 3D driver always fill in all the modes it can support. The matching code should select the correct one anyways, right? -- Ville Syrj�l� [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
