Hi there

There might be an endian problem somewhere. The 3 bytes of color should be RGB or BGR. Note that the green byte is always in the middle and it's red and blue that can get swapped if the bytes are written little-endian then read big-endian (or vice versa).

Regards.

Hi there

If you're using x86 code as a baseline, always be aware of data alignment when porting to a RISC processor. It is not obvious how alignment and padding might affect (what appears to be) a byte swapping problem. x86 is very lenient, but on ARM, expect _all_ structures and unions to start on a word (4 byte) address, even when the structure or union have only char and/or short data types. The C compiler will insert byte padding to enforce the alignment, although this can be overridden.

Regards

hi
could you give more detail information?

Hi,

I've the same problem with Xorg. I thought that the problem was the Atmel framebuffer driver, so I modified the 16/15bpp section to report that the blue and red offsets were different. As a result, the console colors are swapped (Tux then has blue-ish beak and feet), but there is no change to Xorg. I find this very strange.

Note that if I directly write a pixel to the framebuffer, the "actual" alignment is not changed, so the console must be altering its output based on the framebuffer information I modified in the driver. It appears that Xorg FBDEV does NOT do this, and is always outputting RGB (Atmel format is BGR). I think the simple solution is to modify the Atmel FB driver to actually use RGB format and report it that way as well.

Also note, I haven't found any way yet to alter Xorg's output format outside of changing its source code...

fbset report (length/offset) for original FB driver:
R: 5/0
G: 5/5
B: 5/10
A: 0/0

after modifying Atmel FB driver:
R: 5/10
G: 5/5
B: 5/0
A: 0/0

Atmel FB Bit Format (LSbit on right):
0000 0000 0000 0000
|---B--|---G---|--R---|

Command to write BLUE pixel to screen (Little Endian):

Command to write RED pixel to screen (Little Endian):

Unique: I am also new at this, and having a fresh AT91SAM9263 next to me, I have some questions that need to answer as soon as possible. Knowing that you just got it to work, I wonder if you can share some of that experience with me:

1) what steps did you take to get a running Linux system on the 9263-EK?

2) what cross-compiler are you using?

2) how long is the boot up time to get to a graphical interface?

Thanks!

Carlos

I advice you to have a look at :

TimeSys free BSP:
http://www.timesys.com/services/atmel.htm
For a professional embedded Linux experience.

Another option is to go to:
http://www.linux4sam.org
It will help you to setup a graphical linux demo and, if you want, build it from sources.

Note also that minimizing boot up time to graphical interface requires to optimize all components of a Linux solution : needs work !

I hope it will help you,

Regards,

Hi!
(first of all, sorry for hijacking this post)

Well, that's the thing. I installed the linux4sam demo, and it takes about 1 minute to boot up.

Troubled with that, I installed the Adeneo WinCE demo, and it takes 12 seconds to reach the graphical interface!

And both are supposed to be custom images for this 9263 board...

I am being pushed to take a decision, and boot time is an important factor.

Any information will help.

Thanks!

Carlos

Hello unique1313,

I'm facing the same problem.
Can you share your modifications of "blit()" and "solidFill()" with us?
It would be very helpful.

Thanks,
Arjan

Hello,

I changed the code myself. I have a correct BGR 555 on my AT91SAM9263-EK running Qtopia core open source 4.3.3. (Qtopia core is default fixed RGB 565).
The board is based on the BSP from Timesys.

Anyone interested in my modifications to Qt core?

Arjan

Hi vdkamp,

I'm also facing the same problem with qt91sam9261-ek and Qtopia Core 4.4 tp1 and interested to see your modifications. Would you like to share it to us here?

Thanks

Changes to Qtopia core 4.3.3 (default RGB565) so the frame buffer will be filled with the correct format (BGR555)

I used:
./configure -depths 1,4,8,16 -qt-gfx-transformed

Sorry for the mess