Graphics pixel format

Having an idle poke through the kernel code just now, I thought of something. Let’s assume RISC OS is to be ported to some new hardware. RO has a peculiar ordering of graphics pixels – it’s BGR not RGB. On Iyonix this is fixed in hardware by swapping the R and B analogue lines on the graphics card. But assuming we’re going to be using some device where we can’t do the hardware hack, how should this be fixed? How do other systems (Viewfinder, A9) approach this problem?

There are a number of options, depending on what the hardware supports. Here’s a non-exhaustive list of ideas:

1. Just tell the hardware you want a BGR framebuffer
2. Use hardware features to perform the appropriate component swapping (e.g. palette registers in 8bit modes)
3. Render to texture, then tell the hardware that the texture format is BGR, and get it to blit it to the screen.
4. Mark the framebuffer as inaccessible, then sit on the abort vectors and fix up component ordering for reads/writes.
5. Make wholesale, backwards incompatible, changes to RO to make it use RGB.

Note that (5) will break any application that blits pixels directly to the screen, which is probably most non-trivial ones.