Hi, Has anything changed on this topic since 2009? Is there another way to achieve dynamic display resolution change on the fly system wide or per app (the one in focus)?
Daniel. On Friday, January 16, 2009 at 2:31:39 AM UTC+2, Mathias Agopian wrote: > > On Thu, Jan 15, 2009 at 4:09 PM, Dianne Hackborn <[email protected] > <javascript:>> 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] <javascript:>> > 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] <javascript:> > > > > 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 --- You received this message because you are subscribed to the Google Groups "android-porting" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
