Multiple Framebuffer devices(dynamically change) support for Surfaceflinger.

by Robin Gujjar » Wed, 16 Sep 2009 02:37:22 GMT


Sponsored Links
 Hi All,

As suface flinger uses fb0 for rendering the image and video. i want
to change the frame buffer devices dynamically for rendering the image
on the screen one time on Fb0 other time on Fb1. i am looking into the
surface flinger code. but we are not able to get the pointer where to
change for this. can simeone please give us some pointer.

thanks

--~--~---------~--~----~------------~-------~--~----~



Multiple Framebuffer devices(dynamically change) support for Surfaceflinger.

by Robin Gujjar » Thu, 17 Sep 2009 12:35:04 GMT


 Hi All,

As suface flinger uses fb0 for rendering the image and video. i want
to change the frame buffer devices dynamically for rendering the image
on the screen one time on Fb0 other time on Fb1. i am looking into the
surface flinger code. but we are not able to get the pointer where to
change for this. can simeone please give us some pointer.

thank
Robin Singh



Sponsored Links


Multiple Framebuffer devices(dynamically change) support for Surfaceflinger.

by Pankaj » Sat, 26 Sep 2009 02:11:59 GMT


 Hi Dianne,

We have hardware acceleration support and that supports multiple frame
buffer device display ( as we have tested it with driver test
application). but how to fit that into SurfaceFlinger is the issue.
As per our study and understanding of SurfaceFlinger we have done few
changes as below:
1: Instead of mGraphicsPlane, take array of GraphicsPlane,
mGraphicsPlane[2] //for 2 displays fb0 and fb1
2: First Initialize main display DisplayHardware by passing dpy as 0
(Modified the constructor of the Display Hardware), then secondary
DisplayHardware by passing dpy as 1.
3: From init of DisplayHardware pass dpy to EGLDisplaySurface's
mapFrameBuffer and based on dpy value open /dev/graphics/fb0 or fb1.
4: Add a new interface API to the surfaceflinger so that secondary
display could be initilized as and when required.
5: Modified the threadLoop so that each of the APIs handlePageFlip(),
handleRepaint(), unlock Clients() will be called for both displays
dpy-0 and dpy-1.

There are following issues that I am not that much clear.
1: Does we need to modify the OpenGL|ES initialization based on the
DisplayId (dpy) or it will remain same for both display?
2: Does any chnage in the libagl is required for support of multiple
frame buffer support?
3: We have kept the mWormHoleRegion separate for both GrpahicsPlane (0
and 1), so whether we require to maintain different mDirtyRegion and
mInvalidate region for both GrpahicsPlane?
4: How the Layer created on different grphics plane will be composed
to display on the same physical screen?

It will be nice if you can focus some more light on the above issues.

Thanks and Regards,
Pankaj Dubey





--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Tanya : Cara Install *.apk ?

malam rekan2 dan suhu/i
as subject , maklum nubie, saya bisanya download via market tapi karena
dimarket terbatas , jadi saya cari .apk digoogle tapi binggung cara
installnya di robot ijonya
mohon bantuannya.
-- 
Sent from my touch spica white

-- 
"Indonesian Android Community [id-android]" 

2. Default values in SharedPreferences

My application is somewhat complex and has lots of settable
preferences. Fortunately for the user, there are sensible defaults
that I can pre-configure. The SharedPreferences infrastructure
includes defaults in preferences.xml, which I have set accordingly.
The trouble is that if the user has never changed a particular
preference, then SharedPreferences.contains(key) returns false and
SharedPreferences.getXXX(key,default) returns the default field. This
creates a code management issue for defaults. The default values need
to be stored in two different places and kept in sync.

Ideally, the SharedPreferences infrastructure could be told to read in
the entire preferences.xml file so the SharedPreferences database is
loaded with all the initial values. But I haven't found any way to do
that. A key-value pair doesn't come into existence in the database
until the value is changed in the UI.

Second best would be to use the XMLReader to grab the default values,
something like this:

foo = SharedPreferences.getXXX(key,myDefaultReader(key));

Third best would be to store the defaults in their own file and manage
SharedPreferences files and defaults files as pairs. Then on
application startup the defaults file would be read and the values
propagated into the SharedPreferences database.

This is such a generic problem that I'm hoping someone has already
solved it and I can get something off the shelf. Any suggestions?

-- 

3. eclipse HELIOS (3.6) Code Assist very slow

4. About Blowfish Encryptio

5. Kaos & Sticker Android, Palm Pre, Flashdisk Transformer

6. Please help! Hebrew support on Motorola Milestone XT701 and other devices

7. Mod: Undangan Launching (Nexian Android Journey - 3)