well we do not need it for direct RGB updates but either for direct YUV updates or for using Xv API (I guess Xv does only YUV). Also Xv only works on N8x0 so for 770 we'd need to use direct framebuffer access anyway.

IVA is currently inaccessible but the C55x DSP could do it too,well at least in theory. It is a bit easier on 770 since dsp tasks can have framebuffer memory directly mapped, on N8x0 this is not enabled because no video codec is implemented on DSP anymore. I think there were some experiments done by Lardman to map it on N8x0 too but don't know the result. The idea was to do RGB->YUV conversion (and maybe even scaling for 770?) on DSP and also perform some sort of double-buffering. With current direct fb access way one needs to wait for transfer before drawing next frame. With extra frame one would need to wait only for finishing the conversion.

I also can't remember if it worked for the N8x0, but will check this evening if people are interested.

I should add that in the absence of the DSP, Serge's optimised conversion code in mplayer would probably be a pretty good bet (and may be faster than the DSP what with the overhead) - I think it was a YUV to YUV conversion though, so perhaps not relevant here.

With that said I am interested in testing this out on the DSP. I was supposed to send Serge some code, but got sidetracked. The current task I have uses shared memory to output whatever it's fed to the framebuffer on the DSP-side (fire-and-forget for the ARM). I've started some conversion code, but it's untested so far as Serge wanted me to wrap the DSP task in a library which could be called from Mplayer (for example) and I've not got round to it.

I'll dig the code out and put it up somewhere for people to look at (and suggest conversion routines and scaling routines). It would also be useful to have some sort of test harness to send various types of pixel format to the DSP task to test if the conversion/scaling/etc. works. Any thoughts on the best way to do this?

http://people.bath.ac.uk/enpsgp/noki...sp/csconvert.c

Some notes/code for the DSP-side task

Thanks lardman,

looking int othe code you display a table of formats:
enum omapfb_color_format {
OMAPFB_COLOR_RGB565 = 0,
OMAPFB_COLOR_YUV422,
OMAPFB_COLOR_YUV420,
OMAPFB_COLOR_CLUT_8BPP,
OMAPFB_COLOR_CLUT_4BPP,
OMAPFB_COLOR_CLUT_2BPP,
OMAPFB_COLOR_CLUT_1BPP,
OMAPFB_COLOR_RGB444,
OMAPFB_COLOR_YUY422
};

This is the table I stared at quite often when first looking around at the omapfb here and did not notice RGB888 there.

fanoush, do you have any info on how to enable direct RGB888 (even at low resolution), or is it something which the LCD controller itself supports, but that nothing has been coded into the omapfb?

In section 3.3 Input Data Formats of the x73ba001.f01 (S1D13745A01 Spec Rev 1.0).pdf document it says:

"• RGB: 8:8:8, 6:6:6, 5:6:5
• YUV: 4:2:2, 4:2:0
Note
All input data will be automatically converted and stored as appropriate according to the
intended display surface and available memory. Data intended for the LCD display will
be stored as 24 bpp RGB. Data intended for the TV will be stored as YUV 4:2:2 or 4:2:0
depending on REG[60h] bit 7."

So presumably it is supported, but just not implemented.

Also interesting that there are two of OMAPFB_COLOR_YUV422 in the enum (- oops, I misread, one is YUY_), and OMAPFB_COLOR_RGB444 which the spec document doesn't seem to think it supports. Is that altered in the omapfb code?

seems like the story of this little devices' life.

Not that I am changing direction now, the XV stuff is seemingly good enough for me to do some fancy things..

All the emulators need a low-resolution, high fps tearsync screen update.

As far as I can tell, X is driving the lcd refresh and is not overrideable (this may be incorrect).

At this point, i'm hoping perhaps switching to another VT and drawing to framebuffer, with hardware scaling, might be possible.