| 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/vsync_service.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/vsync_service.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/vsync_service.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/vsync_service.h
|