History log of /frameworks/native/libs/vr/libvrflinger/display_surface.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
00d9bb3cf81ccf78fec80c04bdb7250bed9607a2 17-Aug-2017 Corey Tabaka <eieio@google.com> Fix VR surface attributes not being read on surface create.

The API to create VR surfaces allows attributes to be passed during
creation. Attributes can also be set/unset after creation. This CL
fixes an issue where visible and z-order attributes are not honored
when passed during creation, only when set after creation. This
required redundant IPCs and confused a lot of people using this
API.

Bug: 64127728
Test: dvr_api-test
Change-Id: Ife319bcca86115ba1bd2ece0ae93f71f15c0dd0e
/frameworks/native/libs/vr/libvrflinger/display_surface.h
b5e8b5dda33818caaf178b477cd20ee9ab853a97 03-Aug-2017 TreeHugger Robot <treehugger-gerrit@google.com> Merge "Add metadata in direct display surface to support ANativeWindow use cases." into oc-mr1-dev
f60f307b3fcd229de891edf1970519f450dd6bb3 29-Jul-2017 rongliu <rongliu@google.com> Add metadata in direct display surface to support ANativeWindow use cases.

When direct display surface is used with metadata, ComsumerQueue dequeue
reports error because metadata size is hardcoded as 0. It breaks
ANativeWindow case because it has a metadata on the fly.

Create a metadata structure, which could be read and used in the future.

Bug: 64155181
Test: Manual
Change-Id: Ieb35a69d26213769497c6afc7151dd135150c795
/frameworks/native/libs/vr/libvrflinger/display_surface.h
cf02372a00d4e04066e51747d6bd6636e4aae955 29-Jul-2017 Corey Tabaka <eieio@google.com> Fix missing check on buffer import.

Fix a missing check on the success of importing buffers into the
ConsumerQueue. There is a race condition where the producer can
invalidate its buffers, for example by resizing, before the consumer
has a chance to import the previous buffers. The missing check
causes a crash in SurfaceFlinger and VrCore, which are both
consumers of application VR surface buffers.

Also fix a missing lock around the consumer queues in VR surfaces
found during the analysis of this bug.

Bug: 64042620
Test: Ran test.apk before and after the fix. Observe stable operation
after applying the fix.

Change-Id: I416df3ca47978404dcdb53599ddeec9b4bd6fb1a
/frameworks/native/libs/vr/libvrflinger/display_surface.h
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/display_surface.h
656f406fcb0c45fd3c729a513bdd3f353cc6ec1f 22-May-2017 Jiwen 'Steve' Cai <jwcai@google.com> DvrWriteBufferQueue: support buffer resizing

Currently, the buffer resising is implemented at the C API's
implementation level, i.e. it's a pure client side logic out of the core
BufferHubQueue C++/PDX implementation. The logic is similar to
BufferHubQueueProducer's buffer resizing logic.

Other minor changes:
1/ Use ProducerQueueConfig in DisplaySurface as well, and plumb default
width, height, and format to bufferhubd when a BufferHubQueue is created
through a Display Surface.
2/ Added detailed dvr_buffer_queue comments.
3/ Since we now have more and more logic in dvr_buffer_queue, refactored
Dvr{Read,Write}BufferQueue to be C++-styled class.

Bug: 38324405
Test: buffer_hub_queue_producer-test, buffer_hub_queue-test, dvr_api-test
Change-Id: I7186fc04e84eafda46eca316a94739bb3b5c07ca
/frameworks/native/libs/vr/libvrflinger/display_surface.h
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/display_surface.h
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_surface.h
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_surface.h
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_surface.h
1455342db3009c21a5c167ba23089505ee8f04c3 21-Mar-2017 Jiwen 'Steve' Cai <jwcai@google.com> Fix janky pose

It's introduced through ag/1980993, where render_buffer_index_ was not
managed after the refactor.

Bug: 36194745
Test: Build and flash, pose is no longer janky.
Change-Id: I6ef86625dbc1c1afd2725614062f5e40e1b7f60a
/frameworks/native/libs/vr/libvrflinger/display_surface.h
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_surface.h
5c46fc496a2e9537f318efef9a08d1e76f5e7a5f 10-Mar-2017 Jiwen 'Steve' Cai <jwcai@google.com> Remove dvrDisplayManagerClientGetSurfaceBuffers

This should be replaced with BufferHubQueue

Bug: 36033302
Test: Build device targets
Change-Id: I658514e1b56b0bdbd523d3fa322f0f2b6a1fc7e8

Signed-off-by: Jiwen 'Steve' Cai <jwcai@google.com>
/frameworks/native/libs/vr/libvrflinger/display_surface.h
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_surface.h