Hi, the answer is yes and no. There is now an abstraction of the display that you can use to control/resize, the command am display-size. On the other hand, there is no standard AOSP HAL for changing the resolution of the display output.
On Thursday, 29 January 2015 16:48:38 UTC+1, Daniel Doron wrote: > > 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]> >> 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 --- 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.
