DM365: DMAI, FBDev, V4L and kernel arguments

Maybe I can help make a little since, though I have done little testing to verify all combinations.  My understanding is that video windows (VID0 and VID1) can be controlled by V4L2 or FBDev driver for video display, but OSD windows (OSD0 and OSD1) are controlled by FBdev driver for graphics display (V4L2 is video specific and not geared towards graphics).  With V4L2, video buffers are allocated at run time by application, but with FBdev video and osd buffers are allocated during boot time, determined by the information you pass via bootargs.

That said, by default GSG suggests 'video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K", which means FBDev does not control vid0 or vid1 (defaults to V4L2 control), but does control osd0 and the maximum size that any application would require of osd0 at run-time is 720x576 16-bit pxels.  FYI, 720x576x2 bytes per pixel  x 5 buffers = 4050K, but I am not sure whay they need 5 buffers.  normally double or tripple buffering should be enough so you probrably can make this last part smaller.  Also it is important to note than since nothing was specified for osd1 (OFF or size), then osd1 will initialize per driver default size.  So why does the screen appear black when you use Display_Attrs_DM365_VID_DEFAULT?  my guess is that OSD1 (attribute window which controls belnding) default values are such that OSD0 window is 100% visible and VID1 is 0% visible.  A simple test which writes all zeros to OSD1 should prove this (e.g. cat /dev/zero > /dev/fb/2)

when you use 'video=davincifb:vid0=OFF:vid1=OFF:osd0=OFF:osd1=OFF' you are specifically disabling OSD1 (by setting it to OFF), hence FBDev driver knows to disable it and not initialize it at all.  Furthermore, you are disabling FBDev control of all windows, which means only video windows controlled by V4L2 are active and hence Display_Attrs_DM365_VID_DEFAULT works (not hidden behind OSD window since it is disabled).

Marco Braga said:

Checking sprs566a, it seems that the same window can be accessed using FBDev or V4L2, but it is not clear to me if this can happen at the same time without reconfiguring linux. For example, can I access video window 2 using /dev/fb/3 in one application and /dev/video3 in another (not at the same time)?

Yes, but only one can own the resource (vid1) at a time.  To do this, you would have to enable vid1 window via bootargs to give FBdev control and ensure it allocated video buffer during boot time.  Then, I believe there is a runtime 'fbset' command which applications can call to release and take back control of vid1 by FBdev.  Of course, V4L2 can access vid1 when FBDev has release it via such command.

Hi Juan,

thank you very much for your explaination, in fact it confirmed some suspects I had. I've found in the PSP examples some more apps that proved useful to undertand a bit more how display works, in particular "fbdev_loopback" and "v4l2_xxxx_loopback". Both capture video from video0, using v4l, but the first does loopback using fbdev, the second using v4l2 display.

Now, if I give all windows to FBDev, using:

video=davincifb:vid0=720x576x16,4050K:vid1=720x576x16,4050K:osd0=720x576x16,4050K:osd1=720x576x16,4050K

then fbdev_loopback works, as I can see the video. Instead v4l2_xxxx_loopback do not work and give an error. Instead if I only give osd0 and osd1 to fbdev:

video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K:osd1=720x576x16,4050K

then fbdev_loopback does not work. Instead v4l2_xxxx_loopback works (I see the debug strings), but the screen remains black.

Your suggestion seems correct: perhaps osd0 or osd1 is obscuring vid0 or vid1 window. The problem is that I have not been able to make it transparend with "cat /dev/zero > /dev/fb/2" as you suggested).

This also brings me another question: osd1 is a real window or is it used as an attribute window for the main osd? How can I make osd0 transparent?

Thanks!

Hi Juan,

my error was to try to set the attributes to osd1 in the kernel. I've rebooted with this:

video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K

Then used "cat /dev/zero > /dev/fb/2" as you suggested. Now v4l2_xxxx_loopback works, doing a loopback from video0 to video2 using v4l2. The original video_display app now works both using OSD and VID. Thanks a lot!

I am still not sure how osd1 works and what's its correct size, but now it is everything a lot more clear.

osd1 can be used as either attribute window (default in fbdev) or osd window for graphics.  By default, it is used as attribute window which controls transparency between video windows and osd0.

Thank you very much! I'll look for a document explaining how this attribute window works. I suggest that at least DMAI's demos should be modified to set transparency else they will appear as not working while they instead to work.

I agree, the driver code should initialize attribute window to have 50% transparenvy by default (allowing users who want to see vid0 or osd0 to see either one partially).  FYI, you can get more information on attribute window in the VPBE UG http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprufg9a

Hi,

    I have appro's dm355 IPNC.

   And I want to know whether should I configure the video argument just like evm's.

Hi Marco, did you find some good documentation to explain this so slower guys like me can also understand it?

I am working with the fbdev_loopback demo and am really having a hard time to figure transparency and blending out on a low level.  When I was using encodedecode demo it was working easier but now climbing into the nitty gritty it is hard.  the explanation you got earlier in the thread needs to be in a wiki about dm365, I wish I had come across it sooner than on page 27 of a search I did on the from for OSD.

Anyway, transparency and blending is really a nice to have on my app now which should only show some text and a fancy cross-hair during calibration mode of which I am just putting the cross-hair straight into display memory but would appreciate some advice on the text issue.  Will the simplewidget that the encodedecode demo is using be the best route or is there another way you know of?

Thanks for the help, Jinh T.