nanogui: Thread: framebuffer endianess

Hi,

is there any simple way to change the byteorder for the Linux framebuffer access?

I am trying to run nano-x on a powerpc system (big endian) with a little endian
framebuffer. The framebuffer is setup for 16bpp, so I need to find the place where 
the final write to the framebuffer memory takes place in the nano-x code.

Any idea about a good place to add this simple swapping?

Matthias

You've got a "BIGENDIAN" choice in config-file. Tried that?

Matthias Fuchs wrote:
> Hi,
>
> is there any simple way to change the byteorder for the Linux framebuffer access?
>
> I am trying to run nano-x on a powerpc system (big endian) with a little endian
> framebuffer. The framebuffer is setup for 16bpp, so I need to find the place where 
> the final write to the framebuffer memory takes place in the nano-x code.
>
> Any idea about a good place to add this simple swapping?
>
> Matthias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>   

On Friday 18 January 2008 21:03, Daniel Nyström wrote:
> You've got a "BIGENDIAN" choice in config-file. Tried that?
I set that to 'Y'. 

For testing I modified the swapping macro from include/swap.h (to not do any swapping).
It has no impact on the colors on the framebuffer screen.

I grep'ed over the complete code and did not find a place where wswap is used
to swap any access to the framebuffer. The swapping macros are only used when
handling .bmp images.

For further testing I wrote a little tool that maps the framebuffer memory
and runs over every pixel, does a 16bit read, swaps the pixel and writes it back.

In the end my colors look as expected. So it's definetely a swapping issue.

Matthias
> 
> Matthias Fuchs wrote:
> > Hi,
> >
> > is there any simple way to change the byteorder for the Linux framebuffer access?
> >
> > I am trying to run nano-x on a powerpc system (big endian) with a little endian
> > framebuffer. The framebuffer is setup for 16bpp, so I need to find the place where 
> > the final write to the framebuffer memory takes place in the nano-x code.
> >
> > Any idea about a good place to add this simple swapping?
> >
> > Matthias

> You've got a "BIGENDIAN" choice in config-file. Tried that?

That won't affect framebuffer writes, instead it's used to
determine whether to byteswap data read from disk.



> I grep'ed over the complete code and did not find a place where wswap is 
> used
to swap any access to the framebuffer. The swapping macros are only used 
when
handling .bmp images.

The 16bpp driver is src/drivers/fblin16.c.  Write a swap macro
before the word is written to the framebuffer and you should
be on your way.  See the nibble swapping in drivers/fblin4*.c
for ideas.

Regards,

Greg




For further testing I wrote a little tool that maps the framebuffer memory
and runs over every pixel, does a 16bit read, swaps the pixel and writes it 
back.

In the end my colors look as expected. So it's definetely a swapping issue.

Matthias
>
> 

Hi Greg,

thanks for the hint. Thanks for the hint. Updating fblin16.c helped
a lot. Now I can play minesweeper with correct colors :-)
I will post a patch when pre-studies made it into a project.

(BTW, the minesweeper demo does not display the bombs hint from TextValue().
Neither on X11/i386 nor Framebuffer on PowerPC. So it's more lottery than strategy, 
but that's another story :-)

Matthias

On Tuesday 22 January 2008 03:27, Greg Haerr wrote:
> > You've got a "BIGENDIAN" choice in config-file. Tried that?
> 
> That won't affect framebuffer writes, instead it's used to
> determine whether to byteswap data read from disk.
> 
> 
> 
> > I grep'ed over the complete code and did not find a place where wswap is 
> > used
> to swap any access to the framebuffer. The swapping macros are only used 
> when
> handling .bmp images.
> 
> The 16bpp driver is src/drivers/fblin16.c.  Write a swap macro
> before the word is written to the framebuffer and you should
> be on your way.  See the nibble swapping in drivers/fblin4*.c
> for ideas.
> 
> Regards,
> 
> Greg
> 
> 
> 
> 
> For further testing I wrote a little tool that maps the framebuffer memory
> and runs over every pixel, does a 16bit read, swaps the pixel and writes it 
> back.
> 
> In the end my colors look as expected. So it's definetely a swapping issue.