• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 532 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM365 Gstreamer LCD hints

Matt Waddel
Prodigy 45 points

I am working on adding gstreamer support to a custom DM365 based platform. 

I have modified the Linux frame buffer driver to interface to our 480x272 LCD

and I can display static output on the screen through the OSD0 device (/dev/fb/0). 

 

At this point I would like to run gstreamer and display videos to the screen.

So starting with the gstreamer posted by TI at gstreamer.ti.com I have got it to

run on the device without errors or crashing, but I see no output on the LCD.  I

understand that most of the current dm365 gstreamer support was written for the

component/composite displays on the DM365EVM, but can some one direct

me to the parts of gstreamer that I will need to change to add LCD support? 

I'd appreciate any gstreamer tips.

 

Thanks,

Matt

  • 0
    Intellectual 750 points

    Hi Matt,

    The gstreamer-ti project forums may be a better place to get this help ;).

    I don't the recall the changes at the top of my mind, but basically you need to tell DMAI to use the LCD as output, but also you need to modify DMAI to know about the LCD. By default the configuration for DM365 will use the component output, so you will need to tell the plugin to use the LCD display explicitly as well.

    Regards,

    Diego

  • 0 in reply to ddompe
    TI__Genius 14212 points

    Hi Matt,

     

    from looking at the V4L2 driver for VID0 and VID1, it does look to me that the driver can support the output on the LCD digital RGB888 interface. And from above you have been able to switch the OSD0 out to the LCD digital interface. Can you confirm that you can do the same for the VID0 and VID1? Just want to make sure the driver is capable of that. If that is the case then the modifications should be limited to a DMAI plugin change as Diego says and making sure the driver supports the correct timing for your display.

     

    Regards,

    --Gunter

  • 0 in reply to Gunter Schmer
    Prodigy 45 points

    Hi Gunter and Diego,

    Thank you for the responses.  I'll keep looking at the DMAI code in the dvsdk.

    To answer your questions Gunter.

    I was sure my kernel driver was correct, but now I'm having some doubts.  Let me describe what I have done to verify my kernel device driver. 

    We have a display on /dev/fb0.  I assumed this is OSD0 and everything is correct because we can correctly see the image.

    When I type "cat /dev/urandom > /dev/fb1" the screen fills up with random pixels and I assumed that was VID0.  (VID1 isn't enable in the kernel command line so sending data to fb3 fails.)

    "cat /dev/urandom > /dev/fb2" displays about every other pixel as random, but I can still see the OSD0 image through the noise.  So I assumed this was OSD1 or the Attribute window.

    There are no /dev/video0-3 devices.  Is this the problem?  Is my /dev/urandom test even valid for video devices?

    When the kernel boots, here are the frame buffer messages:

    Console: switching to colour frame buffer device 60x34                         
    davincifb davincifb: dm_osd0_fb: 480x272x16@0,0 with framebuffer size 255KB    
    davincifb davincifb: dm_vid0_fb: 480x272x16@0,0 with framebuffer size 382KB    
    davincifb davincifb: dm_osd1_fb: 480x272x4@0,0 with framebuffer size 255KB     
    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

    Thanks, Matt

  • 0 in reply to Matt Waddel
    TI__Mastermind 37340 points

    Matt,

    You are correct that /dev/fb/2 is the attribute window.

    FYI, video windows (VID0 and VID1) can be controlled by V4L2 driver (/dev/videoX type devices) or frame buffer dirver (/dev/fb/x type devices) and OSD windows (OSD0 and OSD1) can only be controlled by frame buffer driver since these are primarily for graphics.  That said, depending on how you specify your bootargs, control will be gieven to either V4L2 or framebuffer driver (e.g. default value of VID0=OFF tells frame buffer driver no to create /dev/fb/x device because V4L2 will control this window).  Hence this may explain why you see some device nodes created and some which may be missing.