On Thu, Jan 15, 2009 at 4:09 PM, Dianne Hackborn <[email protected]> wrote: > Multiple screen support has really not been implemented at all, so you > probably have a fair amount of work ahead of you. Mathias can probably help > you some more, but one thing to think about is you probably want to have the > window manager being the one deciding when the switch is to occur, since it > needs to update the layout of all of the windows and send configuration > changes to reflect what happened. The current approach to changing > orientation could be a reasonable model for this. > > On Thu, Jan 15, 2009 at 3:19 PM, dan <[email protected]> wrote: >> >> I need to change the video hardware in an android system on the fly >> and I need the system, and any running applications, to recognize any >> change in video size, format and buffers. I have been browsing the >> source for the SurfaceFlinger, Clinet, Layer, DisplayHardware and >> EGLDisplaySurface classes, but have been unable to figure out how to >> do this. Can anyone give me a hint?
The short and long answer is that both multiple displays and resolutions changes are not supported yet (and frankly are not on the roadmap at this point). >> I created a second frame buffer driver in the kernel mapped to /dev/ >> graphics/fb1 >> >> I modified DisplayHardware and EGLDisplaySurface so that >> EGLDisplaySurface uses a frame buffer based on the screen index that >> SurfaceFlinger passes to DisplayHardware (i.e. if DisplayHardware is >> passed 0 for the dpy parameter of its constructor then >> EGLDisplaySurface will use fb0). I created a second GraphicPlane in >> SurfaceFlinger using a second DisplayHardware object mapped to fb1 >> through EGLDisplaySurface . >> >> I added a command to SurfaceFlinger's onTransact method to implement >> the switch. >> >> When the command to switch comes in I initialize the second display if >> it has not been initialized before. Then I enumerate the existing >> Layer objects calling each of their setSizeChanged and doTransaction >> methods. I then call DisplayHardware's makeCurrent method for the new >> display. >> >> Am I headed down the wrong path here or am I just missing a step (or >> two, or ...)? Just changing the resolution/size/depth of the main display should be a lot easier than this and should be modeled after the orientation change. In any case, it shouldn't require support for 2 different displays (which is a problem a lot more complex). Mathias > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. > > > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
