There are two different translations to apply in the logical
orientation, one before scaling and one after.
So translate, scale, translate then rotate.
Bug: 7139798
Change-Id: I0726991cadb62988390e77503dbbaed54f07bfe3
we now make sure to take the blanked state of a display into
account when we build its list of visible layers, this ensures
that we won't call prepare/set with a non-empty list when the
display is blanked.
Possibly fixes 7075380, 7103553, 7130187, 7016215
Bug: 7075380
Change-Id: I9fdd2e73d1b7621eaeca3d4ac2ae60d9fb1b3631
This adds a trivial workaround for a one-shot boot time crash, plus
an explicit check and abort for a failure condition that currently
presents as a less obvious failure.
Bug: 7145521, 7147557
Change-Id: I548f6a9caa9f0bd5710aaecea0e1c6c7c8f2f281
FramebufferSurface no longer speaks directly to the FB HAL. Now
everything goes through HWComposer (which may or may not be
connected to a hardware composer).
Added display index arg to some query methods.
Change-Id: Id3e157d2d4e3555d33afbb703e518b6e92e2d6d5
onInitializeDisplays() was posting a transaction with changes
to the display projection. Unfortunately, it only set the
display orientation field and left viewport and frame
uninitialized.
The uninitialized values flowed downstream and found themselves
baked into a bogus DisplayDevice mGlobalTransform. That transform
was then applied to some Rects which were turned into Regions
that were them combined with other Regions.
Under certain situations, the uninitialized data might have
a largish value, resulting in the creation of Regions with
components in excess of the Region max-value limit of 0x7ffffff
(note that this is not INT_MAX). Later when performing a
binary operation using the Region, the Spanner would loop
indefinitely trying to figure out how to stuff a humongous
region inside of a max-value region. Not content to try
just once, the Spanner would continue trying again and
again, pegging the CPU and hanging surface flinger during boot.
Insanity soon followed.
Bug: 7130713
Change-Id: I0016f0c9662185be833474c212a1dd408096ae23
- the library is dlopened from libsurfaceflinger
- the library built only when libnativehelper exists
Bug: 7089510
Change-Id: Ib3ea1029d7e8f6e055f4b759d0bf68f5123fa8a1
this would happen when the composition was handled
entirely in h/w composer, in this case, we would
not set the fences for any involved layers.
Bug: 7049373
Change-Id: I1439dc156ce23c24041cdfbbebfe8ff4fdf790f8
this happened because we didn't check that the visible
region was within the bounds of the display.
Bug: 7064121
Change-Id: I2e81850a3dc3d1474253520ad7f9e559c26d5a96
DisplayDevices are now keyed of the wp<IBinder> the client uses.
DisplayID has now become DisplayType which is just used to identify
physical displays (as opposed to virtual displays such as wifi displays).
Change-Id: I0c5968f2c902dcd699a7e0afacf833ff070c12ea
Use only display tokens in the API to refer to new displays.
Don't require the caller to specify the display when creating
a surface (since in general a surface could be shown on
any display).
This is intended to be a minimum change just to update the API.
Note that SurfaceFlinger still uses DisplayID in a few places
internally that might cause some features not to work properly
when there are multiple displays (LayerScreenshot, for example).
Change-Id: I3d91eec2da406eefd97bcd53655d403ad865a7e6
The primary display device was being configured to "blank" by
default, which prevented the boot animation from appearing
(unless you got lucky with the hardware composer state).
Bug 6975688
Change-Id: I0fa52e9e719c6e997c5725a7baf15d9718461b78
The primary display device was being configured to "blank" by
default, which prevented the boot animation from appearing
(unless you got lucky with the hardware composer state).
Bug 6975688
(This reverts an earlier revert.)
HWComposer can now create IDs representing a display
it can deal with. IDs MAIN and HDMI are reserved.
SurfaceFlinger associate HWComposer IDs with a
DisplayDevice and uses that when it talks to HWComposer.
A DisplayDevice doesn't have to have a HWComposer ID,
in that case it just can't use h/w composer composition.
Change-Id: Iec3d7ac92e0c22bf975052ae2847402f58bade71
The primary display device was being configured to "blank" by
default, which prevented the boot animation from appearing
(unless you got lucky with the hardware composer state).
Bug 6975688
Change-Id: Idaa0d0b98ebb331a17d1b16774c6b05bfa1e8728
when multiple displays are connected, we ended-up having to
call eglMakeCurrent() twice per display due to a limitation
in EGL. this fixes that.
Change-Id: I11e4584df50f8c24bbecee74e37b28b3ee031d2f
fix a few bugs with external displays
- HWComposer doesn't really handle multiple displays yet
so there is a lot of ugliness there
- We also need to make sure that external displays are not
blanked by default
- due to some EGL limitations surfaces being swapped need
to be current
Change-Id: I82bff05b43bcebd8da863c7c76b4edbc3bc223a9
due to a typo, SF's main transaction was conditional to having a
display transaction.
more correct fix for 6970310
Bug: 6970310
Change-Id: Iafd8c4e02afa5db829cc1c65950cfcc74754c6af
Layers were not properly being removed because we were
setting the wrong transaction type flag at the time of
removal.
When layers are removed, we must use eDisplayTransactionNeeded,
not eTransactionNeeded, to ensure that the mLayersRemoved
flag is checked and the appropriate cleanup occurs.
Bug: 6970310
Change-Id: Id4b2897a34d4ac00aa0f92349c0ec6db95c1aaf7
- displays are represented by a binder on the client side
- c++ clients can now create and modify displays
Change-Id: I203ea5b4beae0819d742ec5171c27568f4e8354b
once a secure window is put on screen the display
would retain its "secure" flag forever, preventing
screenshots from being taken.
Bug: 6933967
Change-Id: I5be8355145ca7d580d84552311642f8fa912fe6a
- also replace C casts with C++ casts
- only the interface is changed, HWComposer still doesn't
fully handle multiple displays
Change-Id: I48eb89bff2edb76bf1d4d41f46802b9b2a7166a8
This change refactors the FramebufferSurface class to inherit from the new
ConsumerBase class.
Bug: 6620200
Change-Id: I46ec942ddb019658e3c5e79465548b171b2261f2
it's safer this way because this object owns an
EGLSurface which cannot be easily reference-counted.
it also gives us the ability to sub-class it, which
we might want to do soon.
Change-Id: I07358bb052dc5a13b4f2196b2c2b6e6e94c4bb4f
- fix typo drawForSreenshot misspelled
- get rid of DisplayDeviceBase
- removed unused or unneeded code
- always pass a DisplayDevice to Layer methods that are called
on a per-display basis (to make it clear that this could be
called more than once per composition).
Change-Id: Id948b7e09fe5c06db0e42d40d6ed75dd095c7f44
