nanogui: Thread: FLTK colours fubar'd?

I'm running FLTK 1.1.7, Nano-X 0.91 and NXLIB 0.45 on a Colibri PXA270 (ARM
architecture)

When I run an FLTK application (namely the test programs) my colours are
wrong - maroon background, beige text, etc.

fbset says:

mode "640x480-56"
        # D: 25.000 MHz, H: 29.481 kHz, V: 56.155 Hz
        geometry 640 480 640 480 8
        timings 40000 96 48 33 10 64 2
        accel false
        rgba 8/0,8/0,8/0,0/0
endmode

I've configured Nano-X with SCREEN_PIXTYPE = MWPF_TRUECOLOR888

Can anybody help me out here? It would be much obliged...

Regards, Warren.

: When I run an FLTK application (namely the test programs) my colours are
: wrong - maroon background, beige text, etc.

Start with the nano-X demos in src/demo*.sh: are those
colors correct?  Try bin/mdemo also.


Regards,

Greg

The nano-x demos all appear correctly.

If it's any help, when I run the FLTK colbrowser program, odd things happen,
eg incrementing or decrementing the red slider by 1 causes a dramatic change
in colour.

: I'm running FLTK 1.1.7, Nano-X 0.91 and NXLIB 0.45 on a Colibri PXA270
(ARM
: architecture)

> If it's any help, when I run the FLTK colbrowser program, odd things
happen,
eg incrementing or decrementing the red slider by 1 causes a dramatic change
in colour.

I'm wondering if by chance the RGBA is endian-swapped
and ending up GRAB or something like that...  Is the ARM
running big-endian?

If so, perhaps nano-X isn't in fact running properly.

Otherwise, NXLIB is likely at fault, start perhaps
with some inspection and debugging in XOpenDisplay,
where the color format is detected.  There may also be
issues with images only, versus other color draws.
We need to ascertain exactly what sorts of things are
being drawn (images vs rect fills vs blits) and
go from there.

Regards,

Greg






:
: When I run an FLTK application (namely the test programs) my colours are
: wrong - maroon background, beige text, etc.
:
: fbset says:
:
: mode "640x480-56"
:         # D: 25.000 MHz, H: 29.481 kHz, V: 56.155 Hz
:         geometry 640 480 640 480 8
:         timings 40000 96 48 33 10 64 2
:         accel false
:         rgba 8/0,8/0,8/0,0/0
: endmode
:
: I've configured Nano-X with SCREEN_PIXTYPE = MWPF_TRUECOLOR888
:
: Can anybody help me out here? It would be much obliged...
:
: Regards, Warren.
:

Thanks for the feedback Greg- upon further inspection (ie a twelve-hour
session) I have ascertained that I'll need to play with the RGB masks in
XOpenDisplay- they need to be set for whatever pixel format I'm using. The
problem was that my framebuffer starts in 8-bit paletted mode by default.
Unforunately I can't use RGBA 8880 because my framebuffer doesn't support
32bpp. It does support 5650, but my evaluation board incorrectly decodes
this format to Analogue VGA, resulting in all colours being blue-shifted.
I'm guessing it will work correctly when I hook up an LCD panel; but
unfortunately the components I've ordered won't arrive for another month or
so.

6666 (with the upper 6-bits ignored) works great with the 'pbmtofb' test
program I've found, but unfortunately Nano-X doesn't support this colour
mode. It looks like I'm going to have to add this driver to Nano-X myself.
If it all works nicely I'll submit it to you for inspection.

As for endian-ness, it's little endian, so fingers crossed that isn't an
issue.

Just your replies let me know this project is far from dead, which I am very
grateful for.

Regards,
Warren.

On 12/9/06, Greg Haerr ####@####.#### wrote:
>
> : I'm running FLTK 1.1.7, Nano-X 0.91 and NXLIB 0.45 on a Colibri PXA270
> (ARM
> : architecture)
>
> > If it's any help, when I run the FLTK colbrowser program, odd things
> happen,
> eg incrementing or decrementing the red slider by 1 causes a dramatic
> change
> in colour.
>
> I'm wondering if by chance the RGBA is endian-swapped
> and ending up GRAB or something like that...  Is the ARM
> running big-endian?
>
> If so, perhaps nano-X isn't in fact running properly.
>
> Otherwise, NXLIB is likely at fault, start perhaps
> with some inspection and debugging in XOpenDisplay,
> where the color format is detected.  There may also be
> issues with images only, versus other color draws.
> We need to ascertain exactly what sorts of things are
> being drawn (images vs rect fills vs blits) and
> go from there.
>
> Regards,
>
> Greg
>
>
>
>
>
>
> :
> : When I run an FLTK application (namely the test programs) my colours are
> : wrong - maroon background, beige text, etc.
> :
> : fbset says:
> :
> : mode "640x480-56"
> :         # D: 25.000 MHz, H: 29.481 kHz, V: 56.155 Hz
> :         geometry 640 480 640 480 8
> :         timings 40000 96 48 33 10 64 2
> :         accel false
> :         rgba 8/0,8/0,8/0,0/0
> : endmode
> :
> : I've configured Nano-X with SCREEN_PIXTYPE = MWPF_TRUECOLOR888
> :
> : Can anybody help me out here? It would be much obliged...
> :
> : Regards, Warren.
> :
>
>

: Thanks for the feedback Greg- upon further inspection (ie a twelve-hour
: session) I have ascertained that I'll need to play with the RGB masks in
: XOpenDisplay- they need to be set for whatever pixel format I'm using.

This should be done automatically based on the hw bpp, and
match the macros selected by the MWPF_xxx config type
in the config file.  If you add code here, please send a patch.


 The
: problem was that my framebuffer starts in 8-bit paletted mode by default.
: Unforunately I can't use RGBA 8880 because my framebuffer doesn't support
: 32bpp.

Then why did you originally specify TRUECOLOR888 for
nano-X config?  Of course, we also support 8-bit palette mode.


: 6666 (with the upper 6-bits ignored) works great with the 'pbmtofb' test
: program I've found, but unfortunately Nano-X doesn't support this colour
: mode. It looks like I'm going to have to add this driver to Nano-X myself.
: If it all works nicely I'll submit it to you for inspection.

This driver should be fairly easy - just use the unmodified fblin24.c
24bpp driver, with all new macros for the color mixing
in include/mwtypes.h.  The driver won't be doing anything
other than reading/writing ram, it doesn't do any color
manipulation.  The macros to hack would be the
COLOR2* and PIXEL2* in include/mwtypes.h.

I'm still a bit confused as to exactly what your current
hw color format is, though, since things almost seem
to work (nano-X yes, FLTK no?)


: Just your replies let me know this project is far from dead, which I am
very
: grateful for.

If I could find a decent HTML editor that could read/write
web pages from Windows, then the web page wouldn't
be two years behind... ;-)

Regards,

Greg



: On 12/9/06, Greg Haerr ####@####.#### wrote:
: >
: > : I'm running FLTK 1.1.7, Nano-X 0.91 and NXLIB 0.45 on a Colibri PXA270
: > (ARM
: > : architecture)
: >
: > > If it's any help, when I run the FLTK colbrowser program, odd things
: > happen,
: > eg incrementing or decrementing the red slider by 1 causes a dramatic
: > change
: > in colour.
: >
: > I'm wondering if by chance the RGBA is endian-swapped
: > and ending up GRAB or something like that...  Is the ARM
: > running big-endian?
: >
: > If so, perhaps nano-X isn't in fact running properly.
: >
: > Otherwise, NXLIB is likely at fault, start perhaps
: > with some inspection and debugging in XOpenDisplay,
: > where the color format is detected.  There may also be
: > issues with images only, versus other color draws.
: > We need to ascertain exactly what sorts of things are
: > being drawn (images vs rect fills vs blits) and
: > go from there.
: >
: > Regards,
: >
: > Greg
: >
: >
: >
: >
: >
: >
: > :
: > : When I run an FLTK application (namely the test programs) my colours
are
: > : wrong - maroon background, beige text, etc.
: > :
: > : fbset says:
: > :
: > : mode "640x480-56"
: > :         # D: 25.000 MHz, H: 29.481 kHz, V: 56.155 Hz
: > :         geometry 640 480 640 480 8
: > :         timings 40000 96 48 33 10 64 2
: > :         accel false
: > :         rgba 8/0,8/0,8/0,0/0
: > : endmode
: > :
: > : I've configured Nano-X with SCREEN_PIXTYPE = MWPF_TRUECOLOR888
: > :
: > : Can anybody help me out here? It would be much obliged...
: > :
: > : Regards, Warren.
: > :
: >
: >
:

>
> This should be done automatically based on the hw bpp, and
> match the macros selected by the MWPF_xxx config type
> in the config file.  If you add code here, please send a patch.


So they do- my mistake. No changes to be made here.

Then why did you originally specify TRUECOLOR888 for
> nano-X config?  Of course, we also support 8-bit palette mode.


I mis-read my HW documentation and assumed the default FB mode was 8 bits
per channel, not 8 bits per pixel.

I'm still a bit confused as to exactly what your current
> hw color format is, though, since things almost seem
> to work (nano-X yes, FLTK no?)


In palleted mode, nano-X test programs appear correctly but FLTK ones do
not.
Right now, my hardware can only do 24bpp truecolour RGBA 6666.

If I could find a decent HTML editor that could read/write
> web pages from Windows, then the web page wouldn't
> be two years behind... ;-)


If I ever finish this project, I'll step up and do you an all-singing
all-dancing database driven database to say thanks. Who knows, maybe one day
there will be a Nano-X Wiki!

Thanks also for the pointers on writing a driver.

Regards,
Warren.

: In palleted mode, nano-X test programs appear correctly but FLTK ones do
: not.
: Right now, my hardware can only do 24bpp truecolour RGBA 6666.

OK - I think then the real problem is that FLTK doesn't work
in palette mode, but requires truecolor... ?  It is still possible
that NXLIB is broken in palette mode, not FLTK.  Either
of these possibilities might want to be tested running
on a 8bpp palette mode Linux desktop.

The RGBA 6666 should solve the problem, I know FLTK
runs in 24bpp.


: If I ever finish this project, I'll step up and do you an all-singing
: all-dancing database driven database to say thanks. Who knows, maybe one
day
: there will be a Nano-X Wiki!

Wow ;-)

Regards,

Greg