Fix several problems in the way that the overscan was plumbed in
which could result in information not being delivered to applications.
There was also a violation of certain invariants regarding the
immutability of returned DisplayInfo objects.
Bug: 10213771
Change-Id: I21184a14305e44278b5e81353bf95d511e8517fb
Refactor the new private virtual display API to also support
creating public virtual displays with various characteristics.
This feature requires special permissions and is only intended
for use by the system.
Change-Id: I44dd19f37cf76ea6d6e313afe42f4a412bd96663
This change enables applications to create a private virtual
display that renders its content to a surface of its own creation.
The display is private in the sense that only the application
that owns the display is allowed to place windows upon it.
Mirroring and blanking is also disabled for these displays.
Bug: 9192512
Change-Id: I852ea07f0c7df1d244e354e3daca3a6960285ca0
The window manager now keeps track of the overscan of
each display, with an API to set it. The overscan impacts
how it positions windows in the display. There is a new set
of APIs for windows to say they would like to go into the
overscan region. There is a call into the window manager to
set the overscan region for a display, and it now has a
concept of display settings that it stores presistently.
Also added a new "wm" command, moving the window manager
specific commands from the "am" command to there and adding
a new now to set the overscan region.
Change-Id: Id2c8092db64fd0a982274fedac7658d82f30f9ff
This new API makes it possible for an application to ask on
which Display it should show a Presentation based on the currently
selected media route.
Also added a new API on DisplayManager to query displays that
support a certain category of uses.
Improved the documentation of the Presentation class to explain
how to choose an appropriate Display for presentation.
Bug: 7409073
Change-Id: Iab451215e570ae55f3718fc228303143c800fe51
Add new API to determine whether a display is secure.
Add new API to make a SurfaceView secure.
Clarify documentation.
Bug: 7368436
Change-Id: I7068c34c910e43b4bc72e43fa0dded59a25f0fe2
Calling blank() on Surface Flinger to turn the screen off is not
enough to ensure that the content is blanked to all virtual displays.
What's more, the black surface left in place by the ElectronBeam may
not completely hide the content (particularly if the display orientation
changes). To fix this for real, we'll want to move the display power
management code from the power manager into the display manager
but we don't have time for that.
As a work around, force all displays to show an empty layer stack
with no surfaces on it while blanked.
Bug: 7311959
Change-Id: I870c985f9e76f3f2322e5d83cdbbed9ed15b9f10
Added a new API to determine whether the display supports
protected buffers so that an application can choose a different
content stream or change how it decodes the content so
that it will be viewable on the display.
At present, wifi display does not fully support protected
buffers although this may be enhanced in the future.
Bug: 6986623
Change-Id: If53a53d72b0ec92753cc4b29f99fcb131e00449b
The window manager is no longer responsible for telling the
input system about the display viewport.
Change-Id: I932882bae55decef55f25093bb2a7ebac1620bb1
Tell the display manager whenever a given logical display
contains interesting windows. If so, then the display
manager arranges to show that content on a physical display,
otherwise it ignores the logical display and makes its
associated primary physical display mirror the default
display.
Assign DisplayContents when Displays are added, remove them when
Displays are removed, and update the DisplayInfo when Displays
change.
Change-Id: I36e08ec538055acabe1e24cdd12c40de4e47a158
Added more complete support for logical displays with
support for mirroring, rotation and scaling.
Improved the overlay display adapter's touch interactions.
A big change here is that the display manager no longer relies
on a single-threaded model to maintain its synchronization
invariants. Unfortunately we had to change this so as to play
nice with the fact that the window manager wants to own
the surface flinger transaction around display and surface
manipulations. As a result, the display manager has to be able
to update displays from the context of any thread.
It would be nice to make this process more cooperative.
There are already several components competing to perform
surface flinger transactions including the window manager,
display manager, electron beam, overlay display window,
and mouse pointer. They are not manipulating the same surfaces
but they can collide with one another when they make global
changes to the displays.
Change-Id: I04f448594241f2004f6f3d1a81ccd12c566bf296
