• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 101 subscribers
  • Views 872 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.

TEVM4460 Blaze Tablet screen capture from framebuffer issue

Rain Peng
Intellectual 620 points

Hi All,

I just got a TEVM4460 Blaze Tablet Platform, android version is 4.0.3.

I tried to capture screen from framebuffer /dev/graphics/fb0, but I got all zeros, so the image is black, but DDMS tool of Android SDK tool can capture right screen, this is why?

anybody could help?

Thanks,

Rain

  • 0
    TI__Prodigy 120 points

    Hi Rain,

     DDMS uses SurfaceFlinger, whcih directly calls the SGX driver, to capture screen images. Given the way Ice Cream Sandwich renders/composites what you seen on the screen, the information received from reading dev/graphics/fb0 is not of any real value in a default configuration. What you are seeing is expected.

    -   Josh

  • 0 in reply to Josh Arenson
    Prodigy 110 points

    Hi Josh, 

    I am facing basically the same issue as described in http://groups.google.com/group/pandaboard/browse_thread/thread/16c2636fee370fea#. My understanding of the compositioning system is the following - please correct me if I am wrong:
     
    SurfaceFlinger operates on a list of surfaces that, for each threadloop iteration, are passed down to the HWComposer module by calling the prepare() function. The HWComposer module iterates the list and determines if any of these are suitable to be composited by the four HW overlays present on OMAP4. The remaining surfaces are passed to the SGX module to be composited using OpenGL. The composition thus takes place in two "parallel" branches and the only way to access the final composition shown on the display is thus by reading the framebuffer. Traditionally, this is implemented using mmap() as is the case for the ScreenCap application - https://github.com/android/platform_frameworks_base/blob/master/cmds/screencap/screencap.cpp, however from your comment I get the impression that the OMAPDSS/SGX architecture is not compatible with this approach? If this is the case, what other means do we have for reading the final composition?
     
    Regards,
    Martin
  • 0 in reply to Martin Siegumfeldt
    TI__Prodigy 120 points

    Hi Martin,

       Your understanding is correct. If all you want to do it take a screen shot, you could render all the application layers into a framebuffer object, and call glReadPixels to read it back into memory. However, for anything more than a one-time screen shot, this is very slow and inefficient. The display subsystem (DSS) has a writeback pipeline available which is the best solution by far, but I do not believe drivers are available yet. I will continue to look into this for you.

  • 0 in reply to Josh Arenson
    Prodigy 10 points

    I have the same problem: I want to read PandaBoard's framebuffer to run VNC server on it, but /dev/graphics/fb0 is empty.

    How can the default configuration be modified to make it possible? Can I do this modifying values in sysfs or writeback pipeline streaming is the only option?

  • 0 in reply to Anton Kuchin
    TI__Intellectual 2505 points

    I am closing this thread, as it's the same as http://e2e.ti.com/support/omap/f/849/t/161893.aspx.