History log of /frameworks/native/libs/vr/libvrflinger/display_service.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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/display_service.cpp
3f82d31341f66d0c58e1ec3360ea5f528ffe0ea4 20-Apr-2017 Corey Tabaka <eieio@google.com> Remove unnecessary clients and rename files.

- Remove clients for obsolete services.
- Rename display protocol defs file to match purpose.
- Rename display manager client file. "impl" does not match naming
conventions used by DVR libraries.
- Remove video mesh surface interface. This will be replaced by more
general surface support in the unified O compositor.

Bug: 36401174
Test: Build; run cube sea.
Change-Id: Idb782623319329f6fa1b0aa45005d9fee3b9957d
/frameworks/native/libs/vr/libvrflinger/display_service.cpp
0057fddc71d1c3c3de8f9d0bd45a51bb293bfa3c 02-May-2017 Jiwen 'Steve' Cai <jwcai@google.com> Deprecate producer/consumer usage: Step 2

Clean up bufferhub_rpc, display_rpc and service side producer/consumer
usage reference.

Next (final) step is to remove all remaining client side reference to
producer/consumer usage and update dvr_xxx API.

This also fixes a minor typo in dvr_named_buffer-test

Bug: 37881101
Test: Build, flash, ran particles.apk and buffer_hub_queue-test
Change-Id: Ibae4376c1fd1ed964843d8b2ad2fb27204fe5e28
/frameworks/native/libs/vr/libvrflinger/display_service.cpp
044963e1dd0479035b6e5f2c6bd618bde7143710 02-May-2017 Jiwen 'Steve' Cai <jwcai@google.com> Deprecate producer/consumer usage: Step 1

Clean up producer/consumer usage from IonBuffer.

Bug: 37881101
Test: Build, flash, ran particles.apk
Change-Id: I66a8c4db2348b014a7b458b69157ed7c150112e1
/frameworks/native/libs/vr/libvrflinger/display_service.cpp
f8b1ef4fd9cd4e0bd750b07f502add63ddf43166 19-Apr-2017 Hendrik Wagenaar <hendrikw@google.com> Fix default optics

* Prior cl caused an infinite loop with the defaults
* Removed linear approximation - it caused issues with
inverse distortion

Bug: 37443861
Test: Manually ran on a few phones
Test: Wrote a program that compared the distortion and
undistortion values with the old and new path
Change-Id: I7221679585dd7f0fe966ff11170e9d3ec74a51df
/frameworks/native/libs/vr/libvrflinger/display_service.cpp
db5763834df1b6a1a3aef9442982451f7505f402 18-Apr-2017 Hendrik Wagenaar <hendrikw@google.com> Dvr api usages should follow AHardwareBuffer

* Since vrcore doesn't have access to gralloc1 usages
* Since gralloc1 may be replaced in the future

Bug: 37435415
Test: TestNamedBufferUsage
Change-Id: Iaa47396aca26460541d1b9031dce0b971b630555
/frameworks/native/libs/vr/libvrflinger/display_service.cpp
302b74ffc656243d91ee6ddd8743239ef2dfbdba 04-Apr-2017 Hendrik Wagenaar <hendrikw@google.com> Update optics

* Specify optics via system properties

Bug: 36039976
Test: Ran on device

Change-Id: I7a38e5a9eb3b8a861f1997d5011ec109f5e79cca
/frameworks/native/libs/vr/libvrflinger/display_service.cpp
eaa5522feac452703a0836310047d4b15702487d 06-Apr-2017 Hendrik Wagenaar <hendrikw@google.com> Convert the pose buffer into a more generic named buffer

* It's likely that we'll have more than one pose buffer
* It's cleaner to separate the vsync info into a separate buffer

Bug: 37001881
Bug: 37240552
Test: Added and manually ran TestNamedBuffersSetup
Change-Id: I76621d3cfa8c21c9d5d1e6e648854067673be9ab
/frameworks/native/libs/vr/libvrflinger/display_service.cpp
356bc37719bb748346a79935e1979e264c81c296 06-Apr-2017 Albert Chaulk <achaulk@google.com> Check if a visible layer exists instead of an invisible layer exists

Multiple layers may exist at index 0 and what we really want to know
is if any of them are active, not if any aren't.

Bug: 36867186, 36036583
Test: Launch ithaca then youtube
Change-Id: I5881a838c7df8670fa42eece558717140d4cb021
/frameworks/native/libs/vr/libvrflinger/display_service.cpp
f0a7bd033941e26e380232a0515e903cf8e678e5 01-Apr-2017 Alex Vakulenko <avakulenko@google.com> pdx: Rework error reporting when transfering file and channel handles

There is a lot of confusion about reporting errors when passing file
and channel handles over PDX transport between client and service.

Methods like Message::PushFileHandle return an integer which means
both a file handle reference value (if positive) and a possible error
code (if negative). But file handles could contain negative values too
(when they are empty). This is used frequently when passing buffer
fences around (when a fence is not being used, its fd is set to -1).

This results in a special case of when PushFileHandle is called with
a file handle with value of -1, the return value is actually "-errno"
which becomes dependent on a global state (errno is not set by
PushFileHandle itself in case file handle value is negative) and results
in unpredicted behavior (sometimes errno is 0, sometimes its >0).

Cleaned this all up by using Status<T> everywhere we used an int to
pass value payload along with possible error code.

Now the semantics of the calls are more clear.

Bug: 36866492
Test: `m -j32` for sailfish-eng succeeds
Ran unit tests on device (pdx_tests, libpdx_uds_tests, bufferhub_tests,
buffer_hub_queue-test, buffer_hub_queue_producer-test), all pass
Ran CubeSea, NativeTreasureHunt and Ithaca on Sailfish with vrflinger
enabled, was able to use controller and screen rendered correctly.

Change-Id: I0f40c3f356fcba8bc217d5219a0ddf9685e57fd7
/frameworks/native/libs/vr/libvrflinger/display_service.cpp
b7c8a4bd8131ce18fb4ab4ee986c3b6b1ed27ad5 20-Mar-2017 Albert Chaulk <achaulk@google.com> Implement an API for vrwm to query if the current vr app is active

The API returns if the client_order 0 layer is visible or not. This
aids in 2D app detection

Bug: None
Test: Manual with permissionsgen & calculator

Change-Id: Id988e61a9f93885e93c28ed83ffaffd84f3bdf15
/frameworks/native/libs/vr/libvrflinger/display_service.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/display_service.cpp
10e68eb8aa4db8b6f8cfbf2c3754e2677d7bf848 15-Mar-2017 Hendrik Wagenaar <hendrikw@google.com> Add dvr_buffer apis

Test: None
Bug: None
Change-Id: I234d7ef4dabb4453cdbc67d3112adf2ffbbadaf4
/frameworks/native/libs/vr/libvrflinger/display_service.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/display_service.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/display_service.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/display_service.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/display_service.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/display_service.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/display_service.cpp