> Brian Paul <[EMAIL PROTECTED]> writes
> >The span-writing functions use the LFB_WRITE_SPAN_MESA macro which
> >is conditionally defined for RGB vs BGR order.
> >
> >AFAIK, the RGB vs BGR problem was only on pixel read-back, not
> >writing. If we indeed have to write different pixel formats depending
> >on a runtime condition then the code is broken.
> >
> >I don't have a Banshee card to test with.
>
> Many thanks. I (currently:-)) believe the situation is the same with
> writing pixels as it is with reading them, so I'll try and have a look
> at this in the next few days. I have a Banshee:-) (I'll be working with
> a Windows rather than a Linux build, but as far as I can tell from the
> code this shouldn't make any difference).
After seeing folks fight with this issue for quite a while, I thought it might be helpful to shine a little light on what is probably going on...
On the Voodoo1 and Voodoo2 architectures, there are dedicated read ports and write ports for LFB accesses. These ports can be set up to automatically reorder the ARGB lanes depending on some configuration bits in the hardware. It was therefore possible to return BGR data when an app was doing direct LFB reads. IIRC, the ordering of the colors was dependant upon what constant you passed to grSstWinOpen(). This ordering also affects other places in Glide that used a constant color value.
Now enter Banshee/Voodoo3. On this architecture there is no longer a special read port for LFB reads. Thus, no matter how you configure the hardware you will get RGB back if you read from the framebuffer directly. However, writes can still be set up to reordered from BGR to RGB, so this is somewhat non-orthogonal.
Now, it happens (again IIRC) that Mesa us asking for an ABGR (or BGRA) color format when it calls grSstWinOpen(). This will cause *most* color values to be in that format, but not all, depending on which hardware you're running on.
At this point, the best way I can think of to clear up the problems across all 3dfx hardware would be to switch the FX driver to always ask for an ARGB color format when it calls grSstWinOpen(). While this will require that a bunch of code be changed since a lot of stuff assumes ABGR, this *should* make all of the 3dfx hardware work consistently, or at least more consistently than it is now.
-Ken --- Kenneth Dyke, [EMAIL PROTECTED] (personal), [EMAIL PROTECTED] (work) Staff Engineer, Cross Platform Development, 3dfx Interactive C++: The power, elegance and simplicity of a hand grenade.
_______________________________________________ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
