| fac407407e30c70da44a7a8ae1b13bf1ef9c05b7 |
|
09-May-2017 |
Hendrik Wagenaar <hendrikw@google.com> |
DO NOT MERGE 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
Merged-In: 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
|