Re: Color swapping problem

[Owen Taylor <otaylor redhat com>]

Jim Buzbee <James.Buzbee@echostar.com> writes:

> I'm trying to track down the source of a color problem I'm having
> and I'm starting to think it may be in Gtk.  Here's my situation.  I
> working on an a x86 (Little Endian) processor but my graphics card
> is "broken" in that it insists on treating its frame buffer as Big
> Endian. I have successfully applied patches to my Xserver to account
> for this behavior and now most apps display fine (32 bit mode).
> Some apps however, have the red and blue colors still swapped.  For
> example, If I run Netscape, all is well.  If I run Mozilla, all the
> blues are red and all the reds are blue.  If I run "xv -root
> image.jpg" the image is color-correct, If I run "Esetroot image.jpg"
> the reds and blues are swapped.
>
> Anyone have any insight?  Are there some assumptions in the Gtk library about
> byte ordering?
 
I'm sort of puzzled as to what sort of video card could be worth
this much work considering the existance of good-performing
$20 cards that work out of the box... but anyways. 

First, note Esetroot doesn't use GTK+ at all, so you have at
least two problems.

GTK+ should not be making any assumptions about byte ordering
in the frame buffer - after all it is quite possible to
remote display GTK+ from big-endian box to a little-endian
box. There are basically three possibilities that come
to mind as to what could be going on in your case:

 - Your hacked server is not reporting the correct information
   about the frame buffer. (The output of xdpyinfo may
   be useful)

 - Your hacked server presents a combination that GdkRGB can't
   handle properly because its rare enough that nobody has
   ever bothered implementing it. 

 - There are bugs in GdkRGB that make it use the wrong 
   rendering code even though it has the code for the rendering
   things correctly.

Could you provide:

 - The output of gtk/testrgb.c from the GTK+ distribution
   (you'll have to build GTK+ from source to get this)

 - The output of 'xdpyinfo' (feel free to trim out obviously
   irrelevant stuff)

 - A description of the exact format of your frame buffer.

Regards,
                                        Owen