• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 509 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.

OMAP3530 DVSDK decode demo aplication rotation

Ron Donio
Prodigy 20 points
Other Parts Discussed in Thread: OMAP3530

Hi All

I just ported DVDSK to 2 new OMAP3530 board. one with 4" LCD and the other with 7" LCD.

All work fine beside the  rotation. I can set  size of the displayed video. I can't change the rotation of it.
I tried all option of the command line omapfb.rotate=1 omapfb.rotate_type=1, it just rotate the fb console.
I tried to played with the decode source and change the decode display.c line 85:

dAttrs.rotation = envp->displayOutput == Display_Output_LCD ? 90 : 0; to fix rotation, didn't help.

 

Thanks, Ron.

  • 0
    TI__Intellectual 1910 points

       There is a third parameter you need to rotate a video overlay under Linux, "omap_vout.vid1_static_vrfb_alloc=y".  Please try adding that for either the Vid1 or Vid2 overlays.

      I have these 3 options set to enable rotation for the DVSDK demo:

    omapfb.rotate=1

    omapfb.rotate_type=1

    omap_vout.vid1_static_vrfb_alloc=y'

      This page may help, but I think it is explained better in the Users Guide.

    http://wiki.davincidsp.com/index.php/OMAP35x_DVEVM_Bootargs_Options

    UserGuide-02.01.03.11.pdf

    Regards, Clay

  • 0 in reply to Clay Montgomery
    Prodigy 20 points

    Clay

     

    I already try that. Didn't help.

    The omfab.rotate works for the FB display driver. The rotate for the decode is for the the V4L2 Video driver.
    I am quite sure that this is an application problem.

     

    Ron.

  • 0 in reply to Clay Montgomery
    Prodigy 10 points

    I have been battling an xoverlay rotation problem for a while on the Gumstix Overo Fire OMAP3530 processor.
    I have a landscape orientation lcd43 display (Samsung 4.3" LCD 480x272 from Gumstix connected to the Overo via Chestnut43 expansion board).

    I have used the kernel bootargs as stated above in Clay Montgomery's response:
    omapfb.rotate=1
    omapfb.rotate_type=1
    omap_vout.vid1_static_vrfb_alloc=y'
    ...along with...
    vram=12M
    omapfb.vram=0:3M,1:3M,2:3M

    I've become much more familiar with the Omap DSS parameters thanks to the Linux Kernel OMAP/DSS documentation:
    http://www.mjmwired.net/kernel/Documentation/arm/OMAP/DSS
    ...and...
    http://www.omappedia.com/wiki/Bootargs_for_enabling_display

    fb0, fb1 & fb2 are the physical memory maps.
    overlay0, overlay1,overlay2,overlay3 are specific region maps and access mode definitions for those framebuffers fb0,fb1 & fb2

    The file /etc/fb.modes is list of valid available framebuffer definitions that the current display(s) can support.

    In my case after a bootup with the above bootargs fb0 is well defined as seen with the fbset -a -fb /dev/fb0.  fb1 & fb2 have no definition when viewed with the fbset command.

    Upon start of Xorg server it appears that fb2 and overlay2 are reconfigured, I assume for use as an Xoverlay interface for use by X applications.

    I am then running a GTK+ / Gstreamer application that streams the output of a gstpipeline to that Xoverlay by way of a Gstreamer gstxoverlay widget that has a handle to that Xoverlay.  This works fine when the display is not rotated at bootup.  However, if the video is rotated at bootup, framebuffer fb0 gets setup properly changing from 480x272 to 272x480 but the xoverlay interface doesn't seem to follow.

    It appears that my video stream reaches overlay2.  It appears to be the proper size but is still in the original landscape orientation (not rotated).  It overlays on top of my GTK full screen window as it should.  Once it is on the screen I can move it around slightly using the sysfs commands.  This adds a nice little sanity check.

    So it seems the overlay is unaware that the framebuffers are rotated and that the x,y positions don't match the x,y positions of the framebuffer.

    Some ideas I'm chasing now:
    1)  This LCD is a non-standard ratio 480x272.  This may be the cause of the omapdss overlay errors during bootup.
    3)  My /etc/fb.modes file contains no mode definitions
    2)  There appear to be significant patches to DSS available in newer kernel builds http://www.spinics.net/lists/linux-omap/msg34426.html

    Any insight and correction to the above would be greatly appreciated.

    -John Buckley

  • 0
    Prodigy 10 points

    see:

    display_v4l2.c: _Display_sysfsChange function, this function set the rotation value.