| bfe46a053be03836a060853711b467ed5e10affa |
|
16-Feb-2018 |
Steven Thomas <steventhomas@google.com> |
Support external display rendering in vr flinger
Add support for external displays to vr flinger, hidden behind a system
property until we're ready to use it. To turn it on for testing:
$ adb shell setprop persist.vr.use_external_display 1
With external display support turned on and an external display
connected, all output is redirected to the external display, and we
switch to the external display's vsync.
Bug: 75047963
Test: Most of the testing was done on a Polaris, which now supports
external display hotplugging.
- Tested external display connect/disconnect while the device was
donned.
- Tested external display connect/disconnect while doffed.
- Verified booting with the external display connected doesn't cause the
device to crash, although we don't seem to get a hotplug event for the
external display until the cable is disconnected and reconnected, so
we output to the primary display at first.
- Did some basic testing on a Walleye to confirm vr behavior there is
unchanged.
- Verified the external display is ignored when the sysprop is unset.
Change-Id: I3d3f40e276d354551fc1c577b9392709398ad96e
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 9af9d4b9f7b5d64153c350d01e85fc013581387a |
|
09-Mar-2018 |
John Bates <jbates@google.com> |
Remove unused brightness control from HardwareComposer
This codepath was already disabled by a macro.
Bug: 70855691
Test: manually built and tested on Vega
Change-Id: Ic66db41a2469078d9535a79308f6343d6152c15f
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| a822d52f1a7f651bf1056f4b99e7b8dd214c2ebb |
|
21-Dec-2017 |
Lloyd Pique <lpique@google.com> |
SF: Separate Hwc2::Composer into interface and impl
This makes the android::Hwc2::Composer substitutable. In this case the
intent is to allow a mock::Composer GMock class to be defined.
Hwc2::Composer now is a pure interface class. Hwc2::impl::Composer is
the normal implementation.
Also included is another minor change to allow HWC2::Device to be
constructed with a Hwc2::Composer (interface) pointer instead of a
service name. This means that now SurfaceFlinger itself constructs the
Hwc2::impl::Composer using the service name, rather than passing it down
a call chain.
Test: Code builds
Bug: None
Change-Id: Ic79f645cee40c534651b9c7b70f05497d98e51dc
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 7f8761eef7d657a4f341f3792ff887638940cc47 |
|
19-Jan-2018 |
Steven Thomas <steventhomas@google.com> |
Fix race condition when enabling vr flinger
The following sequence could result in the surface flinger main thread
getting blocked indefinitely:
1. A vr flinger client creates a surface to be displayed.
2. Vr flinger requests the display from surface flinger.
3. The surface flinger main thread calls
mVrFlinger->GrantDisplayOwnership(), to give the display to vr
flinger. The main thread blocks in HardwareComposer::Enable(), as it
waits for the vr flinger post thread to start running.
4. The vr flinger client from step 1 destroys or hides its display
surface.
5. The post thread, signaled by the main thread in step 3, wakes up,
but since it has no surfaces to draw, it goes back to sleep.
At this point the surface flinger main thread will be stuck
indefinitely, as it waits for the post thread to start running. Since
the post thread has no work to do it'll never start running.
Waiting for the post thread to change state is only necessary when
surface flinger takes the display back from vr flinger, in which case we
need to wait for the post thread to destroy its connection to hardware
composer before continuing. I added separate code to wait for the post
thread in that case, and removed the code to wait in the other cases.
Bug: 72335362
Test: It's pretty hard to hit the timing to expose the race condition.
I locally modified the code to add a sleep in
HardwareComposer::Enable(), after asking the post thread to resume but
before checking to see if it's resumed, and quickly exited vr during the
sleep (on a phone). I confirmed the surface flinger main thread became
stuck waiting for the post thread to resume. Since the code to wait for
the post thread is removed in this CL, the race condition is fixed.
I also tested normal vr usage on phones and standalones.
Change-Id: I75c26be91cf0dd1c910de5443c80cfd18ca629b7
(cherry picked from commit b0ea58eca378cb09a81e3afd9d23d2090d2ba8c3)
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 4668484104f28a30ada7c6906f05c818e82f9bf4 |
|
14-Dec-2017 |
John Bates <jbates@google.com> |
Remove spurious composer validate call to avoid hang
Presumably during Doff transitions as the hardware composer post
thread was being interrupted, there was an edge case when
a validate command could be posted without following up with
present. That could lead to create/delete layer calls between
validate and present which are not supported by some HWC
implementations.
Bug: 70178957
Test: manually verified that create layer will fail if done
between validate and present.
Change-Id: If8db231223b23370eb4ca5ae76ced1c9d88b473d
(cherry picked from commit e3117ed7d2c99afa6488bdbbba600030e4415d64)
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| af33627a44279bad668af4f7466309b2e6f152a8 |
|
05-Jan-2018 |
Steven Thomas <steventhomas@google.com> |
Have vr flinger take the display after boot on standalones
1. Have vr flinger request the display immediately after boot finishes
on standalones, to prevent incorrectly showing normal 2d content from
surface flinger on the display during startup.
2. If we don't get any surfaces to show for a while after boot finishes,
turn the display off. This should only occur if VrCore is misbehaving
somehow.
Bug: 65742855
Test: - Verified no flickering in the boot anim.
- Verified that if no surfaces are created the display is turned off.
Change-Id: Ibfcd97101334e552d1d562fe4ae9c36877b44397
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 6e8f706c21a01d6a1225e86972ff432bba5f0106 |
|
22-Nov-2017 |
Steven Thomas <steventhomas@google.com> |
Fix usage of HWC_DISPLAY_PRIMARY in vr flinger
The hardware composer functions require display ids obtained from the
onHotplug() composer callback. Our vr flinger code was supplying
HWC_DISPLAY_PRIMARY as the primary display id, which is incorrect. The
HWC_DISPLAY_* values are used for representing the display type, not the
display id. The code worked anyway because most hardware composers
always use 0 as the primary display id, which happens to be the same
value as HWC_DISPLAY_PRIMARY. The emulator uses 1 as the primary display
id though, which exposed the bug.
This CL changes the vr flinger code to get the display id from the
onHotplug() composer callback, and uses that value when talking to
hardware composer, instead of HWC_DISPLAY_PRIMARY. This matches the
behavior of surface flinger.
Bug: 69631196
Test: Verified the vr flinger code path works as expected on phones and
standalones.
Change-Id: Ia691941d0eafaa1f89e0ee81a4ae27fdef5a57cf
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| d674dd42975e214b588fb6c420ae6bdc2cb76ffb |
|
29-Sep-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Minor cleanup to DvrConfig processing in vrflinger"
|
| 3819afa4849370689f5de398e51e46bdc262c787 |
|
29-Sep-2017 |
Corey Tabaka <eieio@google.com> |
Merge "Use the HWC caching mechanism to avoid stalls in the ion driver." into oc-mr1-dev
am: 17209ec9e2
Change-Id: I44d7f54d46628de1dc5bbe4d5bd681cfde434f23
|
| cc65c3c6c748a5bb87395a9233d01358ef638f4b |
|
28-Sep-2017 |
John Bates <jbates@google.com> |
Minor cleanup to DvrConfig processing in vrflinger
The intention of the previous code was to update the sequence number
so that the struct was only updated on new config changes. The
sequence number needs to be incremented to achieve that behavior.
This is minor, because the previous code is harmless: it just
sets the 16 byte struct every time through, which isn't much
different from the new code.
Bug: 66969271
Test: confirmed with VrCore change to set the DvrConfig struct.
Change-Id: Ica60e2dc8b7d852d56549bab574a6802cea592fc
(cherry picked from commit 4fa590c446e8103a6642e95e382ef8c7d9d1aa8e)
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 0d07cdd593f982e5f6e75706c7f9a99a3c5a9264 |
|
28-Sep-2017 |
Corey Tabaka <eieio@google.com> |
Use the HWC caching mechanism to avoid stalls in the ion driver.
HWC supports caching buffers for layers using "slot" assignments.
Use this in VrFlinger to avoid importing a buffer handle every
frame. The avoids periodic stalls we observe in the ion driver
when mapping a buffer into the HWC address space.
Bug: 66459419
Test: Observe systraces no longer have MapBuffer in HWC in steady
state; system does not drop frames.
Change-Id: Iba4161b33561322bfbccbfafe600b432a6fa7c44
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 95d4273eae9582986345fcb2d56f678f98c72afe |
|
21-Sep-2017 |
Corey Tabaka <eieio@google.com> |
Merge "Deal with unreliable VSYNC signals due to scheduler." into oc-mr1-dev
am: d3da615084
Change-Id: I42758ffcf8e9a2c1f8a27b935aea3f91032f41b9
|
| b3732f08c0655998b2f31c76aac8595a343b511e |
|
16-Sep-2017 |
Corey Tabaka <eieio@google.com> |
Deal with unreliable VSYNC signals due to scheduler.
We see two sources of scheduler jank when waiting for VSYNC:
- A kernfs issue that wakes up threads using a normal priority
work queue that may be delayed or have other work on it.
- The VSYNC callback from HWC is handled by a normal priority
HwBinder thread that may be delayed by other work.
Change the VrFlinger frame post thread to use an absolute timer-
based dead reckoning loop. VSYNC timestamps from the display
driver are reliable, even if the delivery of the value takes time.
Predict the VSYNC time into the future based on the last known
VSYNC time. If we see that VSYNC has not been signaled by the time
we need to post a frame to HWC we assume that the driver and/or
HWC was delayed so much that the previous frame is still pending
and skip the upcoming frame to avoid double stuffing the driver.
Bug: 65064949
Test: Extensive system tests and systraces. See bug for details.
Change-Id: Iae6c4173b8eac1d179adc3fc8004d3d475b3f156
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 451256f7f908fe4b87a29fd3d325251f34d53729 |
|
22-Aug-2017 |
Corey Tabaka <eieio@google.com> |
Keep standalone devices in VrFlinger mode.
Avoid unnecessary tear-down and bring up of HWC client in standalone
devices. This saves time during screen-on because standalone devices
only use VrFlinger mode.
Remove dead code that used to check the panel driver for missed frames.
No drivers expose the sysfs node that provided this function anymore.
Test: Manual testing. Observe stable DON/DOFF behavior.
Bug: 65248224
Change-Id: Id9ebb76982621848d97792496a09b6da8c4e5928
(cherry picked from commit 9b81f53cdffda0bd54daef7386d04113a857ada1)
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 7024b8f8925de0888c6c9d2fa929980c50dbc072 |
|
22-Aug-2017 |
Corey Tabaka <eieio@google.com> |
Keep standalone devices in VrFlinger mode.
Avoid unnecessary tear-down and bring up of HWC client in standalone
devices. This saves time during screen-on because standalone devices
only use VrFlinger mode.
Remove dead code that used to check the panel driver for missed frames.
No drivers expose the sysfs node that provided this function anymore.
Test: Manual testing. Observe stable DON/DOFF behavior.
Bug: 65248224
Change-Id: Id9ebb76982621848d97792496a09b6da8c4e5928
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 878a9b16244e4f254e0f1d2ed70b4f597b24b72a |
|
08-Sep-2017 |
Pat Plunkett <patplunkett@google.com> |
Set the layer composition type in HWC
am: 9db7166d7c
Change-Id: Ic2cef4359d38384ff67c7e51cb3f4531fd9119c5
|
| 9db7166d7cf1ef4b9b1a0a997fada57318851e74 |
|
12-Jul-2017 |
Pat Plunkett <patplunkett@google.com> |
Set the layer composition type in HWC
Setting up the VR hardware composer was causing a call to
setLayerCompositionType with an invalid composition type. This removes the
call, since setting the layer composition type is already handled in
Layer::Prepare().
Bug: 63633934
Test: Start VR mode, check that the logcat errors are no longer present.
Change-Id: I94f9a253bce9c5c25be7927d0003adbb9409ab36
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| e3917218880571e25af6940c2e2549e39410f1ab |
|
08-Sep-2017 |
Corey Tabaka <eieio@google.com> |
Merge commit '88a9bc0d985a5f0cdb0c2167e0172693aa829563' into manual_merge_88a9bc0d9
Test: Manual tests.
Change-Id: I1a3bbb11aba89061b064fa9197688e8f844a2bfa
|
| 2c4aea369d9ec77e98c6b9c08e6feb25fc5a20d2 |
|
01-Sep-2017 |
Corey Tabaka <eieio@google.com> |
Clean up handling of VR surface updates.
- Fix bug where adding a new hardware layer causes existing single-
buffered surface layers to unlatch their buffer.
- Rename variables holding Composer pointers from hidl to composer
to improve readability.
- Remove the arbitrary hardware layer limit, moving responsibility
for efficient use of hardware layers to the VR display manager.
Bug: 64987282
Bug: 64756801
Test: Build system for multiple devices and manually test operation.
Change-Id: I8f05ca83830f62e15b18cd52df3014432c887681
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| b02664ddc146893e6bbe7939ee2b948d54e7166a |
|
27-Jul-2017 |
Steven Thomas <steventhomas@google.com> |
Use a separate hwcomposer hidl instance for vr flinger
Improve robustness of vr flinger <--> surface flinger switching by
having vr flinger use a separate hardware composer hidl instance instead
of sharing the instance with surface flinger. Sharing the hardware
composer instance has proven to be error prone, with situations where
both the vr flinger thread and surface flinger main thread would write
to the composer at the same time, causing hard to diagnose
crashes (b/62925812).
Instead of sharing the hardware composer instance, when switching to vr
flinger we now delete the existing instance, create a new instance
directed to the vr hardware composer shim, and vr flinger creates its
own composer instance connected to the real hardware composer. By
creating a separate composer instance for vr flinger, crashes like the
ones found in b/62925812 are no longer impossible.
Most of the changes in this commit are related to enabling surface
flinger to delete HWComposer instances cleanly. In particular:
- Previously the hardware composer callbacks (which come in on a
hwbinder thread) would land in HWC2::Device and bubble up to the
SurfaceFlinger object. But with the new behavior the HWC2::Device
might be dead or in the process of being destroyed, so instead we have
SurfaceFlinger receive the composer callbacks directly, and forward
them to HWComposer and HWC2::Device. We include a composer id field in
the callbacks so surface flinger can ignore stale callbacks from dead
composer instances.
- Object ownership for HWC2::Display and HWC2::Layer was shared by
passing around shared_ptrs to these objects. This was problematic
because they referenced and used the HWC2::Device, which can now be
destroyed when switching to vr flinger. Simplify the ownership model
by having HWC2::Device own (via unique_ptr<>) instances of
HWC2::Display, which owns (again via unique_ptr<>) instances of
HWC2::Layer. In cases where we previously passed std::shared_ptr<> to
HWC2::Display or HWC2::Layer, instead pass non-owning HWC2::Display*
and HWC2::Layer* pointers. This ensures clean composer instance
teardown with no stale references to the deleted HWC2::Device.
- When the hardware composer instance is destroyed and the HWC2::Layers
are removed, notify the android::Layer via a callback, so it can
remove the HWC2::Layer from its internal table of hardware composer
layers. This removes the burden to explicitly clear out all hardware
composer layers when switching to vr flinger, which has been a source
of bugs.
- We were missing an mStateLock lock in
SurfaceFlinger::setVsyncEnabled(), which was necessary to ensure we
were setting vsync on the correct hardware composer instance. Once
that lock was added, surface flinger would sometimes deadlock when
transitioning to vr flinger, because the surface flinger main thread
would acquire mStateLock and then EventControlThread::mMutex, whereas
the event control thread would acquire the locks in the opposite
order. The changes in EventControlThread.cpp are to ensure it doesn't
hold a lock on EventControlThread::mMutex while calling
setVsyncEnabled(), to avoid the deadlock.
I found that without a composer callback registered in vr flinger the
vsync_event file wasn't getting vsync timestamps written, so vr flinger
would get stuck in an infinite loop trying to parse a vsync
timestamp. Since we need to have a callback anyway I changed the code in
hardware_composer.cpp to get the vsync timestamp from the callback, as
surface flinger does. I confirmed the timestamps are the same with
either method, and this lets us remove some extra code for extracting
the vsync timestamp that (probably) wasn't compatible with all devices
we want to run on anyway. I also added a timeout to the vysnc wait so
we'll see an error message in the log if we fail to wait for vsync,
instead of looping forever.
Bug: 62925812
Test: - Confirmed surface flinger <--> vr flinger switching is robust by
switching devices on and off hundreds of times and observing no
hardware composer related issues, surface flinger crashes, or
hardware composer service crashes.
- Confirmed 2d in vr works as before by going through the OOBE flow on a
standalone. This also exercises virtual display creation and usage
through surface flinger.
- Added logs to confirm perfect layer/display cleanup when destroying
hardware composer instances.
- Tested normal 2d phone usage to confirm basic layer create/destroy
functionality works as before.
- Monitored surface flinger file descriptor usage across dozens of
surface flinger <--> vr flinger transitions and observed no file
descriptor leaks.
- Confirmed the HWC1 code path still compiles.
- Ran the surface flinger tests and confirmed there are no new test
failures.
- Ran the hardware composer hidl in passthrough mode on a Marlin and
confirmed it works.
- Ran CTS tests for virtual displays and confirmed they all pass.
- Tested Android Auto and confirmed basic graphics functionality still
works.
Change-Id: Ibf1dbdf3ec15ca66467697d711f8109dc9e46a47
Merged-In: I17dc0e060bfb5cb447ffbaa573b279fc6d2d8bd1
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| d7f49c5e93a554c2f0e85e279a765f92fb1e66f1 |
|
27-Jul-2017 |
Steven Thomas <steventhomas@google.com> |
Use a separate hwcomposer hidl instance for vr flinger
Improve robustness of vr flinger <--> surface flinger switching by
having vr flinger use a separate hardware composer hidl instance instead
of sharing the instance with surface flinger. Sharing the hardware
composer instance has proven to be error prone, with situations where
both the vr flinger thread and surface flinger main thread would write
to the composer at the same time, causing hard to diagnose
crashes (b/62925812).
Instead of sharing the hardware composer instance, when switching to vr
flinger we now delete the existing instance, create a new instance
directed to the vr hardware composer shim, and vr flinger creates its
own composer instance connected to the real hardware composer. By
creating a separate composer instance for vr flinger, crashes like the
ones found in b/62925812 are no longer impossible.
Most of the changes in this commit are related to enabling surface
flinger to delete HWComposer instances cleanly. In particular:
- Previously the hardware composer callbacks (which come in on a
hwbinder thread) would land in HWC2::Device and bubble up to the
SurfaceFlinger object. But with the new behavior the HWC2::Device
might be dead or in the process of being destroyed, so instead we have
SurfaceFlinger receive the composer callbacks directly, and forward
them to HWComposer and HWC2::Device. We include a composer id field in
the callbacks so surface flinger can ignore stale callbacks from dead
composer instances.
- Object ownership for HWC2::Display and HWC2::Layer was shared by
passing around shared_ptrs to these objects. This was problematic
because they referenced and used the HWC2::Device, which can now be
destroyed when switching to vr flinger. Simplify the ownership model
by having HWC2::Device own (via unique_ptr<>) instances of
HWC2::Display, which owns (again via unique_ptr<>) instances of
HWC2::Layer. In cases where we previously passed std::shared_ptr<> to
HWC2::Display or HWC2::Layer, instead pass non-owning HWC2::Display*
and HWC2::Layer* pointers. This ensures clean composer instance
teardown with no stale references to the deleted HWC2::Device.
- When the hardware composer instance is destroyed and the HWC2::Layers
are removed, notify the android::Layer via a callback, so it can
remove the HWC2::Layer from its internal table of hardware composer
layers. This removes the burden to explicitly clear out all hardware
composer layers when switching to vr flinger, which has been a source
of bugs.
- We were missing an mStateLock lock in
SurfaceFlinger::setVsyncEnabled(), which was necessary to ensure we
were setting vsync on the correct hardware composer instance. Once
that lock was added, surface flinger would sometimes deadlock when
transitioning to vr flinger, because the surface flinger main thread
would acquire mStateLock and then EventControlThread::mMutex, whereas
the event control thread would acquire the locks in the opposite
order. The changes in EventControlThread.cpp are to ensure it doesn't
hold a lock on EventControlThread::mMutex while calling
setVsyncEnabled(), to avoid the deadlock.
I found that without a composer callback registered in vr flinger the
vsync_event file wasn't getting vsync timestamps written, so vr flinger
would get stuck in an infinite loop trying to parse a vsync
timestamp. Since we need to have a callback anyway I changed the code in
hardware_composer.cpp to get the vsync timestamp from the callback, as
surface flinger does. I confirmed the timestamps are the same with
either method, and this lets us remove some extra code for extracting
the vsync timestamp that (probably) wasn't compatible with all devices
we want to run on anyway. I also added a timeout to the vysnc wait so
we'll see an error message in the log if we fail to wait for vsync,
instead of looping forever.
Bug: 62925812
Test: - Confirmed surface flinger <--> vr flinger switching is robust by
switching devices on and off hundreds of times and observing no
hardware composer related issues, surface flinger crashes, or
hardware composer service crashes.
- Confirmed 2d in vr works as before by going through the OOBE flow on a
standalone. This also exercises virtual display creation and usage
through surface flinger.
- Added logs to confirm perfect layer/display cleanup when destroying
hardware composer instances.
- Tested normal 2d phone usage to confirm basic layer create/destroy
functionality works as before.
- Monitored surface flinger file descriptor usage across dozens of
surface flinger <--> vr flinger transitions and observed no file
descriptor leaks.
- Confirmed the HWC1 code path still compiles.
- Ran the surface flinger tests and confirmed there are no new test
failures.
- Ran the hardware composer hidl in passthrough mode on a Marlin and
confirmed it works.
- Ran CTS tests for virtual displays and confirmed they all pass.
- Tested Android Auto and confirmed basic graphics functionality still
works.
Change-Id: I17dc0e060bfb5cb447ffbaa573b279fc6d2d8bd1
Merged-In: I17dc0e060bfb5cb447ffbaa573b279fc6d2d8bd1
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 2233a9ecb40d1521f83e0e1eb2fd5002f466dba7 |
|
05-Aug-2017 |
Corey Tabaka <eieio@google.com> |
Merge "Fix race condition clearing VSYNC enable on VrFlinger startup." into oc-dr1-dev am: 8f09b6abec
am: ba893c2cbf
Change-Id: Ic10087594889b2e846fb5cfdc586cc9de4f51b6f
|
| e0433c8d96d05ca59e4212f51a9e56e91f899145 |
|
05-Aug-2017 |
Corey Tabaka <eieio@google.com> |
Merge "Fix race condition clearing VSYNC enable on VrFlinger startup." into oc-dr1-dev
am: 8f09b6abec
Change-Id: I671c34252d7e0cfedeb2b22d77e6e635aa3d907b
|
| df0b91683d63f988036e214d2193d00fca31010c |
|
04-Aug-2017 |
Corey Tabaka <eieio@google.com> |
Fix race condition clearing VSYNC enable on VrFlinger startup.
Fix VrFlinger to avoid touching the VSYNC enable setting in HWC
during startup by avoiding calling the cleanup code when entering
idle state for the first time.
Bug: 63626797
Test: Manual testing.
Change-Id: I5320bd5c1febb51367e759a8619d35f155789628
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 353a6f69f2ff24c4f10d4994afaa1d4d46bcb9a6 |
|
27-Jun-2017 |
George Burgess IV <gbiv@google.com> |
Fix signed/unsigned integer comparison warning
allowed_pending_fence_count is apparently an int32_t, which made clang
unhappy when compared with the size_t from calling size().
Cast size() to an int32_t, since I doubt we'll have > 2.1 billion FDs
open any time soon. :)
Bug: None
Test: mma. Warning is gone.
Change-Id: I895b2c6e1a6d5a42c692470f6a5c5fd22d55b2ff
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 2ddf567064b5c307bec097293e40ac4eeb8f4b49 |
|
15-Jun-2017 |
Steven Thomas <steventhomas@google.com> |
Fix vr flinger post thread to resume correctly
After being paused, the vr flinger post thread remained paused until it
was enabled by requesting display ownership, but the request for display
ownership was made from the vr flinger post thread, causing the post
thread to get stuck in the paused state forever. I moved the display
ownership request to the vr flinger dispatcher thread, so the post
thread can be resumed.
Bug: 62666511
Test: Put a device through a sleep/wake cycle and confirmed the vr
flinger post thread resumes as expected.
Change-Id: Ic57adb7376c8f2b5760bfaa4a5a30b58894a7ab7
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 69a5973c81c80f5abb72f089d87d080727d4d40f |
|
07-Jun-2017 |
Corey Tabaka <eieio@google.com> |
libvrflinger: Move display request to avoid duplicate calls.
Move the request display call to avoid duplicate calls when direct
surfaces change but the current VrFlinger mode does not change.
Bug: 62389162
Test: build; flash; VrFlinger mode works.
Change-Id: I1348ada93e2992306cba7e319f9b20726fb97cb7
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 89bbefcb31d77059c275abe843578d09264475c9 |
|
07-Jun-2017 |
Corey Tabaka <eieio@google.com> |
libvrflinger: Move some tracing to a more verbose level.
Quiet the logs when using TRACE=1.
Bug: None
Test: Set TRACE=1; build; observe traces do not appear.
Change-Id: I521fa5cf4b0ab18e73f89a1898bf2d58fc2d1f88
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 0b485c91f95fa7022998971fb9f407fe198bb853 |
|
19-May-2017 |
Corey Tabaka <eieio@google.com> |
libvrflinger: Add additional info to PDX dump.
- Add logging for surface and layers.
- Minor cleanup of AcquiredBuffer code.
- Add additional debug tracing.
Bug: None
Test: servicetool --dump /dev/socket/pdx/system/vr/display/client
Change-Id: Ie7cfe46978139e0eef2184b03acb4b9bab428a33
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 6f468c6a3731d2bae41c4b86143b7246fcde1f83 |
|
31-May-2017 |
Okan Arikan <okana@google.com> |
Sync up the DvrConfig struct with Google3
Bug: 38506720
Test: No functional change. Just make.
Change-Id: Ib159dd156cef353a7881bc6b4004c46da5e2d449
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 822b710a714c342dda0087f594c8ababa6630f44 |
|
08-May-2017 |
Okan Arikan <okana@google.com> |
Adopt the use of shared buffers.
Bug: 37001948
Test: Make system image
Change-Id: I032574f250e0f0fe7768af649730406e24d853db
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 954796e27e89209b38b35779949c243bec490c28 |
|
11-May-2017 |
John Bates <jbates@google.com> |
Add shmem config buffer to libvrflinger
This allows VrCore to configure some tunable behaviors
of libvrflinger.
- Added dvrDisplayManagerDeleteNamedBuffer for testing config buffer
creation.
- Added tests for named buffers, including one for the config buffer.
- Added IsValid to broadcast_ring to avoid tracking redundant state
externally.
Bug: 38193993
Test: Run dvr_named_buffer-test
Change-Id: I52722dd314233b5bea1ca6377c14b5c856825746
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| cdb605375d66153d21641b800bd05af6ca81a125 |
|
09-May-2017 |
Hendrik Wagenaar <hendrikw@google.com> |
Remove graphics.cpp and friends
* Delete a bunch of code that isn't used in the O2 path
Bug: 36776792
Test: Compiled
Change-Id: I4adf6ec5678a53e0850229f9dda60e8687793376
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| a9d668acaa888acc04705b73d6e4fe3c0069d06f |
|
08-May-2017 |
Hendrik Wagenaar <hendrikw@google.com> |
Remove framebuffer_target
* Remove unused variable
Bug: 38132845
Test: Compiled
Change-Id: I08afba75b72c3d27aca042755bf36584979c7f0c
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 2251d822dac2a96aad4184a6fdc2690f0a58af7c |
|
21-Apr-2017 |
Corey Tabaka <eieio@google.com> |
Remove the VR compositor from the framework.
Remove the VR compositor framework and enable out-of-process VR composition
in VrCore.
This CL seems large due to the ripple effect of changing the VrFlinger
API and protocol types. There are three major modules that require
concurrent changes:
1. Protocol definitions and low-level VrFlinger API in libdisplay.
* Additional changes needed to keep old interfaces working for
a short time while replacing the dependent code (dvrGraphics*).
2. VrFlinger service implementation changes to support VrCore compositor
and the removal of the internal compositor.
3. Changes to libdvr platform library API due to changes in #1 and #2.
Because of the nature of the interdependence of types and other defs it is
difficult to break this CL into smaller chunks. However, review of the three
major modules (libdisplay, libdvr, and libvrflinger) may be done separately
to ease the mental burden on reviewers.
Change Summary:
- Remove obsolete screenshot service. VR screenshots will be implemented
by VrCore.
- Update display protocol definitions for changes in VrFlinger service
requirements. The majority of the changes in libdisplay are a
consequence of these protocol and service changes.
- Update VrFlinger to support two kinds of surfaces:
1. Application - use by VR apps.
2. Direct - used by VrCore (protected by permission check).
- Remove VrFlinger internal compositor and GL context.
- Remove obsolete debug console.
- Update VrFlinger hardware composer interface to handle direct
surfaces only, removing the concept of GPU (compositor) layers.
- Update display manager to expose access to application surface info
to VrCore (protected by permission check).
- Update libdvr platform library interfaces for changes to VrFlinger
API / protocol.
- Clean up libdvr API struct setup using a common include.
- Add C++ header-only helpers for DVR platform library opaque types.
Bug: 36401174
Test: Build; run VrFlinger display test tool.
Change-Id: I15abfde5f72dbb3725a3f58621486afba6b64902
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 0af4b9f88a48a6ecc705b4a8cec3d3ba24c53ead |
|
26-Apr-2017 |
Steven Thomas <steventhomas@google.com> |
Call validateDisplay() when skipping frames
Layer management was getting screwed up in vr flinger in the following
scenario:
1. In frame X, post a new buffer to layer L.
2. Decide to skip frame X (e.g. because we're behind our target
schedule).
3. In frame X+1, delete layer L.
When we skip the frame in step 2, we weren't calling validateDisplay()
or presentDisplay() on the hardware composer, so the composer's internal
command queue wasn't being flushed. When we called validateDisplay() for
frame X+1 the update buffer call from frame X would be run, referencing
the deleted layer L, causing a crash.
Now we always call validateDisplay() when we change the layer state,
even if we decide to skip the frame.
I also added code to explicitly clear the Composer object's internal
command buffer when we transfer control from surface flinger to vr
flinger and back. There were certain cases where there could be commands
left in the command buffer after the display handoff.
Bug: 37159844
Test: I used an app switcher script that quickly switches vr apps, which
would consistently trigger the setLayerBuffer crash. I confirmed with
this CL applied I can run the app switcher until surface flinger runs
out of file descriptors (that's a separate bug), and I never see the
setLayerBuffer crash. I also confirmed from the log output there are no
additional hardware composer errors.
Change-Id: I85832b87f393754dc6b034eb38f2937d7b58ed74
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 4b78832d7fc3cdd13a20587dfee96d1505916213 |
|
24-Mar-2017 |
Luke Song <songwalker@google.com> |
Remove/Cleanup Obselete References
Bug: 36039686
Bug: 36040117
Bug: 36039685
Bug: 36040550
Test: Build
Change-Id: Ifd5ae90138e39d0a14c6a5a8198a9145f74ec8f6
(cherry picked from commit 8126b9df8987fd9959eab1ae76620c343c32f4fc)
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 1f42e3a02c4f9a1ba1916a2f0e47082bedb73e41 |
|
10-Apr-2017 |
Daniel Nicoara <dnicoara@google.com> |
VR: Update VR HWC to use buffer metadata passed by SurfaceFlinger
Without gralloc1 support, need to pass buffer metadata in order to
import native buffers and used them as graphic buffers.
Bug: 36481301
Test: Compiled and ran on device; Verified VR Window Manager properly
displays SurfaceFlinger buffers.
Change-Id: I8426be1d79dcc2fbd631c399427ae03cb2afc21d
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 66747c180e456cc762821c61a75a17bee03a4cf9 |
|
23-Mar-2017 |
Steven Thomas <steventhomas@google.com> |
Fix BlockUntilVSync() to actually block
In my refactoring in ag/2008740 I introduced a regression where blocking
until the next vsync would busy loop instead of actually blocking on an
event on the vsync fd. The problem was I changed the poll() call to
listen for POLLIN in addition to POLLPRI. While waiting for vsync events
we only want to listen for POLLPRI.
Bug: 36495351
Test: Confirmed with debug logs the busy loop bug and that we correctly
block with this patch applied.
Change-Id: Iec4951e014575a5d0ed3cfe3fc20ea91c67edf1b
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 050b2c83304bd16ec3a838da08b6ba6acf6a3af4 |
|
06-Mar-2017 |
Steven Thomas <steventhomas@google.com> |
Revert "Revert "Tie vr flinger to persistent vr mode""
This reverts commit 7480c060cb3466d97ec3125d61bbace153f534c8.
Transfer display control to vr flinger when persistent vr mode is
entered, rather than when vr mode is entered. This allows cardboard
apps, which will invoke vr mode but not persistent vr mode, to work as
in N.
This activates vr flinger at device boot for Daydream ready devices,
which fixes an issue where an app would attempt to create a surface
before vr flinger was running, which would hang indefinitely.
The VrManager listener for persistent vr mode is put in vr flinger
instead of surface flinger. This is cleaner since the vr interaction
with the rest of the device is now consolidated in vr flinger.
While testing I encountered a problem where vr flinger was given control
of the display but vsync was turned off, causing vr flinger's post
thread to hang. I changed the vr flinger logic to give control over
vsync and other display settings to the post thread, and took the
opportunity to further simplify and improve vr flinger's thread
interactions.
Bug: 35885165
Test: Manually confirmed that when persistent vr mode is not invoked we
get the N-based render implementation, and when persistent vr mode is
invoked we get vr flinger.
Change-Id: I3b5ad599cc0748e38b861c714c4cc3118f854acf
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 7480c060cb3466d97ec3125d61bbace153f534c8 |
|
21-Mar-2017 |
Jin Qian <jinqian@google.com> |
Revert "Tie vr flinger to persistent vr mode"
This reverts commit f43d13e4e35ae7d3cdafc4b97c819669d42cef78.
Change-Id: Ib67db8e51b7ea2dbbe6faccce36962bf5b44a6e2
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| f43d13e4e35ae7d3cdafc4b97c819669d42cef78 |
|
06-Mar-2017 |
Steven Thomas <steventhomas@google.com> |
Tie vr flinger to persistent vr mode
Transfer display control to vr flinger when persistent vr mode is
entered, rather than when vr mode is entered. This allows cardboard
apps, which will invoke vr mode but not persistent vr mode, to work as
in N.
This activates vr flinger at device boot for Daydream ready devices,
which fixes an issue where an app would attempt to create a surface
before vr flinger was running, which would hang indefinitely.
The VrManager listener for persistent vr mode is put in vr flinger
instead of surface flinger. This is cleaner since the vr interaction
with the rest of the device is now consolidated in vr flinger.
While testing I encountered a problem where vr flinger was given control
of the display but vsync was turned off, causing vr flinger's post
thread to hang. I changed the vr flinger logic to give control over
vsync and other display settings to the post thread, and took the
opportunity to further simplify and improve vr flinger's thread
interactions.
Bug: 35885165
Test: Manually confirmed that when persistent vr mode is not invoked we
get the N-based render implementation, and when persistent vr mode is
invoked we get vr flinger.
Change-Id: Ieeb8dabc19e799e3179e52971f3b63f5a8f54b3b
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| a3613612a1142c3134045f08c30a861ea43288ed |
|
09-Mar-2017 |
Jiwen 'Steve' Cai <jwcai@google.com> |
Refactor VrFlinger to use BufferHubQueue
1/ Remove DisplayRPC::AllocateBuffer, as individual buffer allocation
is now handled by BufferHubQueue.
2/ Reimplement native_buffer_queue using bufferhubqueue.
3/ Hook up consumer queue in DisplaySurface.
4/ Remove epoll_event_dispatcher as its no longer being used.
Bug: 36033302
Test: Built and ran particles.apk
Change-Id: I38ee1c57195888ede935ebc50119bcb7e4ab4e36
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 016e5e3ca751de7e86731349985d1eaf7c072515 |
|
22-Feb-2017 |
Stephen Kiazyk <skiazyk@google.com> |
Ensure display metrics on display service creation
This fixes a potential race condition where a VR app could request the
display metrics from the VR display service before it actually queries
them from the HWC.
Bug: None
Test: Compiled and ran Vr app.
Change-Id: Ie95b7f5a8ef2e286c7b2994ca94fd87214567e24
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 3cfac28462910d3f976aebac54ac7301aca7e434 |
|
06-Feb-2017 |
Steven Thomas <steventhomas@google.com> |
Ignore callbacks from the non-active hardware composer
Ignore callbacks from the non-active hardware composer so we don't get
e.g. duplicate vsync callbacks, one from each composer.
Bug: None
Test: Manually confirmed with logs we're now ignoring callbacks on the
non-active composer.
Change-Id: I8b475d6283d86c64ff96b41e78528bce8c6ff1d3
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 06d63de03cb2a551ca99608f5aa0c4f3e200b0fc |
|
04-Jan-2017 |
Chia-I Wu <olv@google.com> |
surfaceflinger: cache HWC client targets and buffers
Remember HWC client targets and buffers, and make sure we send each
unique slot/handle pair only once. This allows the composer to
clone/register/retain each buffer only once.
Test: builds and boots
Change-Id: Ib485189043a9c132031e82d4d7380ace3bf9453d
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| c8da5b356ee215f4c8cc53a5728aa303478772b5 |
|
08-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix vr flinger deadlock and race condition"
|
| 282a5ed48f64e4010f97ca4077e3bd4b54ba3268 |
|
08-Feb-2017 |
Steven Thomas <steventhomas@google.com> |
Fix vr flinger deadlock and race condition
While investigating hangs when transitioning from 2d --> vr and back I
found a deadlock and race condition in the vr flinger pause/resume
handling. This CL should fix both issues.
Unfortunately there's still another deadlock related to multiple threads
trying to suspend/resume vr flinger, but considering how vr flinger is
currently used by surface flinger we shouldn't ever hit that scenario in
practice.
Bug: None
Test: I was able to reliably get a hang when starting/stopping vr
launcher a few times, but with this CL applied and another CL to remove
calls to SetPowerMode() applied (that CL will be submitted separately),
I no longer see any hangs.
Change-Id: Ie842bf9fb00e4e2937769ed7e1e2ec9cc47861f7
(cherry picked from commit cf921a3919d68d8c8d1b8be39e03a372f6346f57)
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| 105036fa54ad282611d355ecea00c470abbfa4a0 |
|
08-Feb-2017 |
Jiwen 'Steve' Cai <jwcai@google.com> |
Stop calling setPowerMode in VrFlinger
Seems that SetPowerMode from VrFlinger is causing the HIDL HWC service
(android.hardware.graphics.composer@2.1-service) to hang.
Bug: None
Test: Start particles, stop particles, start CubeSea; stop CubeSea
Change-Id: I074568fa0b04041d94dd76768ff27d467e699682
(cherry picked from commit 7fba71a24630bdf757bd4e8a28193a3995c133aa)
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| ea572425ac5438d6d27eca83104b795100ca87af |
|
02-Feb-2017 |
Hendrik Wagenaar <hendrikw@google.com> |
Remove access to the backlight brightness
* We don't need to set the display brightness at the moment, and
access to the brightness fd requires an SELinux policy change
that we'd like to avoid, so ifdef out the code for now.
Bug: None
Test: To be tested along with Nick's SELinux policy cl
Change-Id: Ic6de9a1bd15d0eab2780bda31ec67fab94f8d6da
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|
| a8a92784bc5f6a50ce00311c6161fbcfc0898c5a |
|
27-Jan-2017 |
Alex Vakulenko <avakulenko@google.com> |
Add libvrflinger for use in SurfaceFlinger
A separate CL uses this code from SurfaceFlinger.
Bug: None
Test: Manually ran modified SurfaceFlinger
Change-Id: I34588df1365588c0a0265e1e2325e3dd5516206a
/frameworks/native/libs/vr/libvrflinger/hardware_composer.cpp
|