Xfbdev color problems due to endianess

[Daniel Stone]

On Wed, Sep 10, 2008 at 05:06:32PM +0200, Leon Ljunggren wrote:
> > wfb works everywhere fb does (i.e. everywhere).  fb is the normal
> > software rasterisation code, which takes a bass address, stride, etc,
> > and writes directly to that range.  wfb is literally the exact same
> > codebase as fb, but instead of writing directly to memory, will issue a
> > function call, if you've set read/write functions, and ask you to please
> > write this pixel value to this location.  This gives you the opportunity
> > to mangle it however you please: change the ordering, tile it, whatever.
> >
> > So yes, it's completely fine.
> 
> That sounds good, but I'm afraid I don't understand how I could change
> from fb to wfb, and how I would then use that to fix the problem.

Change fbScreenInit in hw/kdrive/src/kdrive.c to wfbScreenInit.
setupWrap tells you which drawable you're going to access, and asks you
to set up the memory read/write functions, and finishWrap lets you know
you're done.  So in your setupWrap function, just set pRead and pWrite
to functions which perform the format conversion, but only if pDraw is
the front buffer (i.e. == GetScreenPixmap(screenInfo.screens[0])).

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20080910/f6d23299/attachment.pgp>