Dear Francois,
in message <IBJDLO$2F7CB4091C41824099E5E47AB0570FD3 at tiscali.fr> you wrote:
>
> I have been playing with the CoralP, Icecube and Debian.
> Works fine, thanks to the tutorial on the Denx site.
> I now would like to see the microwindows stuff working. I
This will not work. Microwindows can only use a plain framebuffer
interface, but the Coral-P does not allow for such a driver because
of the fact that it has a little-endian register interface. For the
frameboffer, each color is defined by a bit offset and the number of
(contiguous bits) in a data word. For example, assuming a color depth
of 16 bpp you could have something like this:
MSB LSB
rrrrrrgggggbbbbb
In this case the "green" color has bit offset 5 and is 5 bits wide,
while "red" has offset 10 and is 6 bits wide. On the Coral-P you see
the bytes swapped, i. e.
MSB LSB
gggbbbbbrrrrrrgg
The "green" bits are split into two non-contiguous groups which
cannot be desribed in the way it is needed for a framebuffer
interface.
You will need a custom graphics driver which swaps all color data
that get written to the Coral-P. Standard Microwindows does not
support this mode of operation.
> have been trying the demos from the ELDK but I get strange
> colors, it seems my palette is all wrong. The same happens
Yes, this is the effect explained above.
> when I recompile the latest version of microwindows (except
> I get yet another palette).
Again, thisis only to be expected.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Here's a fish hangs in the net like a poor man's right in the law.
'Twill hardly come out." - Shakespeare, Pericles, Act II, Scene 1
