replicant-frameworks_native/services/surfaceflinger/EventThread.cpp

328 lines
12 KiB
C++
Raw Normal View History

/*
* Copyright (C) 2011 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#define ATRACE_TAG ATRACE_TAG_GRAPHICS
#include <stdint.h>
#include <sys/types.h>
#include <cutils/compiler.h>
#include <gui/BitTube.h>
#include <gui/IDisplayEventConnection.h>
#include <gui/DisplayEventReceiver.h>
#include <utils/Errors.h>
#include <utils/String8.h>
#include <utils/Trace.h>
#include "EventThread.h"
#include "SurfaceFlinger.h"
// ---------------------------------------------------------------------------
namespace android {
// ---------------------------------------------------------------------------
EventThread::EventThread(const sp<SurfaceFlinger>& flinger)
: mFlinger(flinger),
mVSyncTimestamp(0),
mUseSoftwareVSync(false),
mVSyncCount(0),
mDebugVsyncEnabled(false) {
}
void EventThread::onFirstRef() {
run("EventThread", PRIORITY_URGENT_DISPLAY + PRIORITY_MORE_FAVORABLE);
}
sp<EventThread::Connection> EventThread::createEventConnection() const {
return new Connection(const_cast<EventThread*>(this));
}
status_t EventThread::registerDisplayEventConnection(
const sp<EventThread::Connection>& connection) {
Mutex::Autolock _l(mLock);
mDisplayEventConnections.add(connection);
SF could get stuck waiting for vsync when turning the screen off When turning the screen off we could have 2 waiters on the vsync condition: The main vsync waiter as well as one in onScreenReleased(). We were only signaling the condition though, so it it would be possible to wake onScreenReleased() without waking the main vsync thread which would then be stuck in .wait(). We fix this by just using broadcast() when receiving a vsync event. We also add a broadcast() to signal when the state of mUseSoftwareVSync changes. This is important particularly for the transition from hardware to software vsync because the main vsync waiter might have observed mUseSoftwareVSync == false and decided to block indefinitely pending a hardware vsync signal that will never arrive. Removed a potentially deadlocking wait for a signal in onScreenReleased(). The function was trying to wait for the last vsync event from the hardware to be delivered to clients but there was no guarantee that another thread would signal it to wake up again afterwards. (As far as I can tell, the only other other thread that might wake it up at this point would be a client application issuing a vsync request.) We don't really need to wait here anyhow. It's enough to set the mUseSoftwareVSync flag, wake up the thread loop and go. If there was a pending vsync timestamp from the hardware, then the thread loop will grab it and use it then start software vsync on the next iteration. Bug: 6672102 Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
2012-06-15 06:39:35 +00:00
mCondition.broadcast();
return NO_ERROR;
}
void EventThread::removeDisplayEventConnection(
const wp<EventThread::Connection>& connection) {
Mutex::Autolock _l(mLock);
mDisplayEventConnections.remove(connection);
}
void EventThread::setVsyncRate(uint32_t count,
const sp<EventThread::Connection>& connection) {
if (int32_t(count) >= 0) { // server must protect against bad params
Mutex::Autolock _l(mLock);
const int32_t new_count = (count == 0) ? -1 : count;
if (connection->count != new_count) {
connection->count = new_count;
SF could get stuck waiting for vsync when turning the screen off When turning the screen off we could have 2 waiters on the vsync condition: The main vsync waiter as well as one in onScreenReleased(). We were only signaling the condition though, so it it would be possible to wake onScreenReleased() without waking the main vsync thread which would then be stuck in .wait(). We fix this by just using broadcast() when receiving a vsync event. We also add a broadcast() to signal when the state of mUseSoftwareVSync changes. This is important particularly for the transition from hardware to software vsync because the main vsync waiter might have observed mUseSoftwareVSync == false and decided to block indefinitely pending a hardware vsync signal that will never arrive. Removed a potentially deadlocking wait for a signal in onScreenReleased(). The function was trying to wait for the last vsync event from the hardware to be delivered to clients but there was no guarantee that another thread would signal it to wake up again afterwards. (As far as I can tell, the only other other thread that might wake it up at this point would be a client application issuing a vsync request.) We don't really need to wait here anyhow. It's enough to set the mUseSoftwareVSync flag, wake up the thread loop and go. If there was a pending vsync timestamp from the hardware, then the thread loop will grab it and use it then start software vsync on the next iteration. Bug: 6672102 Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
2012-06-15 06:39:35 +00:00
mCondition.broadcast();
}
}
}
void EventThread::requestNextVsync(
const sp<EventThread::Connection>& connection) {
Mutex::Autolock _l(mLock);
if (connection->count < 0) {
connection->count = 0;
SF could get stuck waiting for vsync when turning the screen off When turning the screen off we could have 2 waiters on the vsync condition: The main vsync waiter as well as one in onScreenReleased(). We were only signaling the condition though, so it it would be possible to wake onScreenReleased() without waking the main vsync thread which would then be stuck in .wait(). We fix this by just using broadcast() when receiving a vsync event. We also add a broadcast() to signal when the state of mUseSoftwareVSync changes. This is important particularly for the transition from hardware to software vsync because the main vsync waiter might have observed mUseSoftwareVSync == false and decided to block indefinitely pending a hardware vsync signal that will never arrive. Removed a potentially deadlocking wait for a signal in onScreenReleased(). The function was trying to wait for the last vsync event from the hardware to be delivered to clients but there was no guarantee that another thread would signal it to wake up again afterwards. (As far as I can tell, the only other other thread that might wake it up at this point would be a client application issuing a vsync request.) We don't really need to wait here anyhow. It's enough to set the mUseSoftwareVSync flag, wake up the thread loop and go. If there was a pending vsync timestamp from the hardware, then the thread loop will grab it and use it then start software vsync on the next iteration. Bug: 6672102 Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
2012-06-15 06:39:35 +00:00
mCondition.broadcast();
}
}
void EventThread::onScreenReleased() {
Mutex::Autolock _l(mLock);
if (!mUseSoftwareVSync) {
SF could get stuck waiting for vsync when turning the screen off When turning the screen off we could have 2 waiters on the vsync condition: The main vsync waiter as well as one in onScreenReleased(). We were only signaling the condition though, so it it would be possible to wake onScreenReleased() without waking the main vsync thread which would then be stuck in .wait(). We fix this by just using broadcast() when receiving a vsync event. We also add a broadcast() to signal when the state of mUseSoftwareVSync changes. This is important particularly for the transition from hardware to software vsync because the main vsync waiter might have observed mUseSoftwareVSync == false and decided to block indefinitely pending a hardware vsync signal that will never arrive. Removed a potentially deadlocking wait for a signal in onScreenReleased(). The function was trying to wait for the last vsync event from the hardware to be delivered to clients but there was no guarantee that another thread would signal it to wake up again afterwards. (As far as I can tell, the only other other thread that might wake it up at this point would be a client application issuing a vsync request.) We don't really need to wait here anyhow. It's enough to set the mUseSoftwareVSync flag, wake up the thread loop and go. If there was a pending vsync timestamp from the hardware, then the thread loop will grab it and use it then start software vsync on the next iteration. Bug: 6672102 Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
2012-06-15 06:39:35 +00:00
// disable reliance on h/w vsync
mUseSoftwareVSync = true;
mCondition.broadcast();
}
}
void EventThread::onScreenAcquired() {
Mutex::Autolock _l(mLock);
SF could get stuck waiting for vsync when turning the screen off When turning the screen off we could have 2 waiters on the vsync condition: The main vsync waiter as well as one in onScreenReleased(). We were only signaling the condition though, so it it would be possible to wake onScreenReleased() without waking the main vsync thread which would then be stuck in .wait(). We fix this by just using broadcast() when receiving a vsync event. We also add a broadcast() to signal when the state of mUseSoftwareVSync changes. This is important particularly for the transition from hardware to software vsync because the main vsync waiter might have observed mUseSoftwareVSync == false and decided to block indefinitely pending a hardware vsync signal that will never arrive. Removed a potentially deadlocking wait for a signal in onScreenReleased(). The function was trying to wait for the last vsync event from the hardware to be delivered to clients but there was no guarantee that another thread would signal it to wake up again afterwards. (As far as I can tell, the only other other thread that might wake it up at this point would be a client application issuing a vsync request.) We don't really need to wait here anyhow. It's enough to set the mUseSoftwareVSync flag, wake up the thread loop and go. If there was a pending vsync timestamp from the hardware, then the thread loop will grab it and use it then start software vsync on the next iteration. Bug: 6672102 Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
2012-06-15 06:39:35 +00:00
if (mUseSoftwareVSync) {
// resume use of h/w vsync
mUseSoftwareVSync = false;
mCondition.broadcast();
}
}
void EventThread::onVSyncReceived(const wp<IBinder>&, nsecs_t timestamp) {
Mutex::Autolock _l(mLock);
mVSyncTimestamp = timestamp;
mVSyncCount++;
SF could get stuck waiting for vsync when turning the screen off When turning the screen off we could have 2 waiters on the vsync condition: The main vsync waiter as well as one in onScreenReleased(). We were only signaling the condition though, so it it would be possible to wake onScreenReleased() without waking the main vsync thread which would then be stuck in .wait(). We fix this by just using broadcast() when receiving a vsync event. We also add a broadcast() to signal when the state of mUseSoftwareVSync changes. This is important particularly for the transition from hardware to software vsync because the main vsync waiter might have observed mUseSoftwareVSync == false and decided to block indefinitely pending a hardware vsync signal that will never arrive. Removed a potentially deadlocking wait for a signal in onScreenReleased(). The function was trying to wait for the last vsync event from the hardware to be delivered to clients but there was no guarantee that another thread would signal it to wake up again afterwards. (As far as I can tell, the only other other thread that might wake it up at this point would be a client application issuing a vsync request.) We don't really need to wait here anyhow. It's enough to set the mUseSoftwareVSync flag, wake up the thread loop and go. If there was a pending vsync timestamp from the hardware, then the thread loop will grab it and use it then start software vsync on the next iteration. Bug: 6672102 Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
2012-06-15 06:39:35 +00:00
mCondition.broadcast();
}
bool EventThread::threadLoop() {
DisplayEventReceiver::Event vsync;
Vector< sp<EventThread::Connection> > signalConnections;
signalConnections = waitForEvent(&vsync);
// dispatch vsync events to listeners...
const size_t count = signalConnections.size();
for (size_t i=0 ; i<count ; i++) {
const sp<Connection>& conn(signalConnections[i]);
// now see if we still need to report this VSYNC event
status_t err = conn->postEvent(vsync);
if (err == -EAGAIN || err == -EWOULDBLOCK) {
// The destination doesn't accept events anymore, it's probably
// full. For now, we just drop the events on the floor.
// Note that some events cannot be dropped and would have to be
// re-sent later. Right-now we don't have the ability to do
// this, but it doesn't matter for VSYNC.
} else if (err < 0) {
// handle any other error on the pipe as fatal. the only
// reasonable thing to do is to clean-up this connection.
// The most common error we'll get here is -EPIPE.
removeDisplayEventConnection(signalConnections[i]);
}
}
return true;
}
// This will return when (1) a vsync event has been received, and (2) there was
// at least one connection interested in receiving it when we started waiting.
Vector< sp<EventThread::Connection> > EventThread::waitForEvent(
DisplayEventReceiver::Event* event)
{
Mutex::Autolock _l(mLock);
size_t vsyncCount;
nsecs_t timestamp;
Vector< sp<EventThread::Connection> > signalConnections;
do {
// latch VSYNC event if any
bool waitForVSync = false;
vsyncCount = mVSyncCount;
timestamp = mVSyncTimestamp;
mVSyncTimestamp = 0;
// find out connections waiting for events
size_t count = mDisplayEventConnections.size();
for (size_t i=0 ; i<count ; i++) {
sp<Connection> connection(mDisplayEventConnections[i].promote());
if (connection != NULL) {
if (connection->count >= 0) {
// we need vsync events because at least
// one connection is waiting for it
waitForVSync = true;
if (timestamp) {
// we consume the event only if it's time
// (ie: we received a vsync event)
if (connection->count == 0) {
// fired this time around
connection->count = -1;
signalConnections.add(connection);
} else if (connection->count == 1 ||
(vsyncCount % connection->count) == 0) {
// continuous event, and time to report it
signalConnections.add(connection);
}
}
}
} else {
// we couldn't promote this reference, the connection has
// died, so clean-up!
mDisplayEventConnections.removeAt(i);
--i; --count;
}
}
// Here we figure out if we need to enable or disable vsyncs
if (timestamp && !waitForVSync) {
// we received a VSYNC but we have no clients
// don't report it, and disable VSYNC events
disableVSyncLocked();
} else if (!timestamp && waitForVSync) {
// we have at least one client, so we want vsync enabled
// (TODO: this function is called right after we finish
// notifying clients of a vsync, so this call will be made
// at the vsync rate, e.g. 60fps. If we can accurately
// track the current state we could avoid making this call
// so often.)
enableVSyncLocked();
}
// note: !timestamp implies signalConnections.isEmpty(), because we
// don't populate signalConnections if there's no vsync pending
if (!timestamp) {
// wait for something to happen
if (waitForVSync) {
// This is where we spend most of our time, waiting
// for vsync events and new client registrations.
//
// If the screen is off, we can't use h/w vsync, so we
// use a 16ms timeout instead. It doesn't need to be
// precise, we just need to keep feeding our clients.
//
// We don't want to stall if there's a driver bug, so we
// use a (long) timeout when waiting for h/w vsync, and
// generate fake events when necessary.
bool softwareSync = mUseSoftwareVSync;
nsecs_t timeout = softwareSync ? ms2ns(16) : ms2ns(1000);
if (mCondition.waitRelative(mLock, timeout) == TIMED_OUT) {
if (!softwareSync) {
ALOGW("Timed out waiting for hw vsync; faking it");
}
mVSyncTimestamp = systemTime(SYSTEM_TIME_MONOTONIC);
mVSyncCount++;
}
} else {
// Nobody is interested in vsync, so we just want to sleep.
// h/w vsync should be disabled, so this will wait until we
// get a new connection, or an existing connection becomes
// interested in receiving vsync again.
mCondition.wait(mLock);
}
}
} while (signalConnections.isEmpty());
// here we're guaranteed to have a timestamp and some connections to signal
// (The connections might have dropped out of mDisplayEventConnections
// while we were asleep, but we'll still have strong references to them.)
// fill in vsync event info
event->header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;
event->header.timestamp = timestamp;
event->vsync.count = vsyncCount;
return signalConnections;
}
void EventThread::enableVSyncLocked() {
if (!mUseSoftwareVSync) {
// never enable h/w VSYNC when screen is off
mFlinger->eventControl(SurfaceFlinger::EVENT_VSYNC, true);
mPowerHAL.vsyncHint(true);
}
mDebugVsyncEnabled = true;
}
void EventThread::disableVSyncLocked() {
mFlinger->eventControl(SurfaceFlinger::EVENT_VSYNC, false);
mPowerHAL.vsyncHint(false);
mDebugVsyncEnabled = false;
}
status_t EventThread::readyToRun() {
ALOGI("EventThread ready to run.");
return NO_ERROR;
}
void EventThread::dump(String8& result, char* buffer, size_t SIZE) const {
Mutex::Autolock _l(mLock);
result.appendFormat("VSYNC state: %s\n",
mDebugVsyncEnabled?"enabled":"disabled");
result.appendFormat(" soft-vsync: %s\n",
mUseSoftwareVSync?"enabled":"disabled");
result.appendFormat(" numListeners=%u,\n events-delivered: %u\n",
mDisplayEventConnections.size(), mVSyncCount);
for (size_t i=0 ; i<mDisplayEventConnections.size() ; i++) {
sp<Connection> connection =
mDisplayEventConnections.itemAt(i).promote();
result.appendFormat(" %p: count=%d\n",
connection.get(), connection!=NULL ? connection->count : 0);
}
}
// ---------------------------------------------------------------------------
EventThread::Connection::Connection(
const sp<EventThread>& eventThread)
: count(-1), mEventThread(eventThread), mChannel(new BitTube())
{
}
EventThread::Connection::~Connection() {
// do nothing here -- clean-up will happen automatically
// when the main thread wakes up
}
void EventThread::Connection::onFirstRef() {
// NOTE: mEventThread doesn't hold a strong reference on us
mEventThread->registerDisplayEventConnection(this);
}
sp<BitTube> EventThread::Connection::getDataChannel() const {
return mChannel;
}
void EventThread::Connection::setVsyncRate(uint32_t count) {
mEventThread->setVsyncRate(count, this);
}
void EventThread::Connection::requestNextVsync() {
mEventThread->requestNextVsync(this);
}
status_t EventThread::Connection::postEvent(
const DisplayEventReceiver::Event& event) {
ssize_t size = DisplayEventReceiver::sendEvents(mChannel, &event, 1);
return size < 0 ? status_t(size) : status_t(NO_ERROR);
}
// ---------------------------------------------------------------------------
}; // namespace android