I am trying to output a pixel-perfect frame out of the DSI interface of the jetson nano. Outputting a semi-pixel perfect frame works, but the imperfections come from the fact that I have to convert my frame to NV12 first, which then converts back to RBG888 on DSI.
To output frames, I currently am using gstreamer pipeline elements as nvoverlaysink and nvdrmvideosink, but these don’t seem to work when I feed them RGB directly. (It has to be converted to I420/NV12, (e.g. by using nvvidconv) which then causes the conversion loss from my original RGB image)
From the TRM, it seems perfectly possible to set the hardware framebuffer (the windows in the tegra DC) into mode RGB(A), and so in theory, I should be able to output an exact pixel stream from userspace through gstreamer. So far I haven’t quite found out how to do this (those gst sinks are also closed source…)
I also experimented a bit with the fbdev device. By blanking/unblanking it, it seems to configure the windows in the tegradc in rgb mode. In theory I could try to use gstreamer with the fbsink then and hope for no conversion loss. Would this be a recommended option, or can we just use NVMM buffers also in RGBA mode and use one of the official gstreamer sinks?
So, to summarize, my main question: How can I place RGB(A) data into memory and make sure it is output on DSI without going through an YUV conversion?
Then I can access the /dev/fb1 device (my gdm/X is disabled), and read/write to it.As far as I can see, the window for the framebuffer should be configured in RGBA mode…
I can then scope the outgoing DSI stream.
But strangely enough, if I fill up the framebuffer with 0xFF FF FF FF, the resulting RBG888 value transmitted over DSI is (always accross the entire screen) 0xFF EE F0 .
Outputting 0xAB CD EF 00 (in RGBA), yields a DSI output frame containing all 0xED C1 A0 ( in RGB888)
hexdump -C /dev/fb1
00000000 ab cd ef 00 ab cd ef 00 ab cd ef 00 ab cd ef 00 |................|
*
I don’t understand why this is happening. Thanks in advance for any feedback on this.
@Dane, I had been trying with RGBA, that wasn’t it.
I found the cause. I started from a DSI example where the CMU was enabled. This causes my input colors to be slightly modified, which I mistakenly interpreted as a RBG->YUV->RBG conversion artifact.
Adding
nvidia,default_color_space = <1>;
To the DTS, or just removing the cmu node fixes it.