Re: Color swapping problem

[Jim Buzbee <James Buzbee echostar com>]

Centuries ago Nostradamus foresaw of a time when Owen Taylor would write:
>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. 

It's for an embedded application.  Not your garden variety off the shelf card.


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

OK, perhaps it's a Imlib problem?

>
>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)

name of display:    :1.0
version number:    11.0
vendor string:    The XFree86 Project, Inc
vendor release number:    335
maximum request size:  4194300 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    2
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 134
focus:  window 0x2c0000d, revert to PointerRoot
number of extensions:    18
    BIG-REQUESTS
    DOUBLE-BUFFER
    DPMS
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RECORD
    SECURITY
    SHAPE
    SYNC
    XC-APPGROUP
    XC-MISC
    XFree86-DGA
    XFree86-Misc
    XFree86-VidModeExtension
    XInputExtension
    XTEST
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    704x480 pixels (238x163 millimeters)
  resolution:    75x75 dots per inch
  depths (1):    32
  root window id:    0x25
  depth of root window:    32 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x21
  default number of colormap cells:    2048
  preallocated pixels:    black 0, white 16777215
  options:    backing-store YES, save-unders YES
  largest cursor:    704x480
  current input event mask:    0xf8c033
    KeyPressMask             KeyReleaseMask           EnterWindowMask
    LeaveWindowMask          KeymapStateMask          ExposureMask
    SubstructureNotifyMask   SubstructureRedirectMask FocusChangeMask
    PropertyChangeMask       ColormapChangeMask
  number of visuals:    1
  default visual id:  0x22
  visual:
    visual id:    0x22
    class:    TrueColor
    available colormap entries:    2048 per subfield
    red, green, blue masks:    0xff, 0xff00, 0xff0000
    significant bits in color specification:    8 bits
    depth :    32 planes


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

Possible.

>
> - 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)
>

I'll have to get this..

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

See above ( LSB strings interesting, reflects the host not the framebuffer)

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

It appears like so :  Host sees long as 01 02 03 04 : Frame buffer sees the
opposite: 04 03 02 01

Thanks for the response.

Jim


>
>Regards,
>                                        Owen