(Hoping this is a suitable forum - the query seems more bare-metal-ish than graphics-ish - it is certainly a very very low-level query, well below any potential OS-layer! TBH, if no-one can answer it, I won't be overly surprised, it is very obscure )
I am wondering if the VideoCoreIV subsystem has the ability to do some custom color-space conversion between the final framebuffer and the video output (HDMI, DSI, DPI).
It would be convienient* to have my frame buffer in a non-RGB format** and have a small bit of code running between the framebuffer and the RGB encoder(s) on the HDMI/DSI/DPI lines to convert to RGB at the absolute last stage of my graphics pipeline. Code would be running on some part of the VidCore subsystem (assuming it has support for such things) on a custom VidCore software stack (luckily I only need 2D acceleration, for now at least).
* Last-stage conversion is not absolutely necessary - I could do the colorspace conversion on the way to the framebuffer if I had to, but doing it at the last possible stage appeals to my sense of neatness. (Another alternative I am playing with is outputting my custom color space as-is on the HDMI RGB port (I'm sure the hardware doesn't actually care what the bits represent, as long as they align with what it expects) and using a HDMI-in-out equipped FPGA board to do the conversion in an in-line dongle. However on-boarding the conversion in software would, obviously, be easier than messing around with external quasi-hardware solutions).
** Think something L*a*b*-like (Y-B, R-G, Luminance) but without the rigorous color-correctness requirement - I have a fairly simple integer algorithm relying mainly on adds, inverts, and shifts worked out for the actual conversion.