hi Zoltan, Thanks. The display size and density have moved to wm (using lollipop). wm makes changes to the whole system. I am interested in filtering this to specific app(s). Tried to trace the wm code through WindowManager (got a little lost there) but figured in the end that what ever control WindowManager has must run through SurfaceControl down to Layer. I made some debug prints in Layer (setSize, setCrop, setBuffers) and tried to replicate that behavior but failed. It seems I am missing something... Yes, I agree a HAL for controlling the display properties would have been a step in the right direction.
Daniel. On Thursday, January 29, 2015 at 7:05:43 PM UTC+2, Zoltan Kuscsik wrote: > > 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.
