| 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/vr_flinger.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/vr_flinger.cpp
|
| 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/vr_flinger.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/vr_flinger.cpp
|
| b1e29aff043f9b34322b64cde47510f82ea911a1 |
|
29-Jun-2017 |
Karthik Ravi Shankar <karthikrs@google.com> |
Merge "Add VrFlinger dumpsys to SurfaceFlinger" into oc-dr1-dev am: ae11e71bb7
am: 9579e3cd94
Change-Id: I3f56806205f651d714255c66a1b1bd8e0cc73f6d
|
| 171155a55d7a3b7571ea1292f1aad926b6f82509 |
|
29-Jun-2017 |
Karthik Ravi Shankar <karthikrs@google.com> |
Add VrFlinger dumpsys to SurfaceFlinger
When we do dumpsys SurfaceFlinger, we get no information about the
layers/what is composed when the device is in VR mode.
Bug: 63113212
Test:
VrFlinger state:
Application Surfaces:
Surface 0: surface_id=11 process_id=5550 user_id=10104 visible=1
z_order=0 queue_ids=29,37
Surface 1: surface_id=13 process_id=5035 user_id=10130 visible=1
z_order=0 queue_ids=53,65
Direct Surfaces:
Surface 0: surface_id=8 process_id=5563 user_id=10104 visible=1
z_order=0 queue_ids=17
Display metrics: 1440x2880 537.882x537.882 dpi @ 60 Hz
Post thread resumed: 1
Active layers: 1
Layer 0: type=Device surface_id=8 buffer_id=19
Hardware Composer Debug Info:
-------------------------------
HWC2 display_id: 0
layer: 30 z: 0 compositon: Device/Device alpha: 255 format:
RGBA_8888_UBWC dataspace:0x00000000 transform: 0/0/0 buffer_id:
0x70b4877500
color modes supported: 0 7 9 current mode: 7
current transform:
1.08 -0.02 -0.02 0.00
-0.07 1.03 -0.07 0.00
-0.01 -0.01 1.09 0.00
0.00 0.00 0.00 1.00
-------------------------------
This section doesn't appear when the device is not in VR mode.
Change-Id: I2961a05fc3ea303e070be08de355fb6e56c3d0db
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
/frameworks/native/libs/vr/libvrflinger/vr_flinger.cpp
|
| 5a244ed36c8e45fd95b89ff916caf083fb182ec1 |
|
10-Jun-2017 |
Alex Vakulenko <avakulenko@google.com> |
libudx: Move ServiceDispatcher from libpdx_uds to libpdx
The two separate implementations of ServiceDispatcher for UDS and ServiceFS
are practically identical. Moved the implementation into the base libpdx lib,
and removed the transport-specific versions.
Bug: None
Test: `m -j32` succeeds; pdx_tests, pdx_servicefs_tests, pdx_uds_tests pass
Change-Id: I2344f4f23bc3da27eb7b192344844b87660e8610
/frameworks/native/libs/vr/libvrflinger/vr_flinger.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/vr_flinger.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/vr_flinger.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/vr_flinger.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/vr_flinger.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/vr_flinger.cpp
|
| ae2d58b16a231e6afe5867d312e6811c7b710b4c |
|
06-Feb-2017 |
Hendrik Wagenaar <hendrikw@google.com> |
Add param null-check + error return
* Fail gracefully when no hidl is passed
Test: Manually ran with nullptr
Change-Id: I2726c5ad512c7115f4c6e99d1e41e0fe267e6ff2
/frameworks/native/libs/vr/libvrflinger/vr_flinger.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/vr_flinger.cpp
|