Re: Change video hardware on the fly

[Dianne Hackborn]

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 <d...@celiocorp.com> 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?

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 ...)?

--
Dianne Hackborn
Android framework engineer
hac...@android.com

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.

[Mathias Agopian]

On Thu, Jan 15, 2009 at 4:09 PM, Dianne Hackborn <hac...@android.com> 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 <d...@celiocorp.com> 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

[Daniel Doron]

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. 

[Zoltan Kuscsik]

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.

[Daniel Doron]

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.