In certain cases, such as the shutdown sequence, the driver may
blank itself without any direction from SurfaceFlinger.
In such cases the HWC should make sure that no further updates on
the display occur.
Handle events from driver in a more generic way to include blank
events and leave room for any other events that need to be polled
on from the driver.
Change-Id: Iabc91a70e71b42d3a7319504ae70b96908acbffe
CRs-fixed: 627814
When an fd is opened for the first time, poll always succeeds
without a notify from the driver. This gives us invalid data from
the driver, which actually has the right value only when it calls
sysfs_notify. Do a first read for the vsync fds to avoid this.
Change-Id: I47e7bb0a3f91ccb90b1cf36fe5e7d75de1085b62
- cleans up external library
- add separate library for virtual display
- process virtual updates in its separate path
in hwc.
- Acquire blank mutex lock for one complete drawing
cycle
Change-Id: Ib984c578464a131ecdb27ee48960f58d68b7a5a7
SurfaceFlinger can enable HDMI vsync through event control.
Poll for HDMI vsync events and report them to SurfaceFlinger.
Change-Id: I301f1dffbab56b3b5a3dda5a59c37721688d7849
poll on the vsync file descriptor. This prepares the ground for
multiple vsync updates without adding additional threads.
Change-Id: I30ef0fb34816d438501475cd3e4967775fcb1d19
The vsync enable ioctl is called in a separate thread in a
recent change
Hence it was now possible that vsync could be disabled but
SurfaceFlinger still received a vsync. With this check we make
sure that doesn't happen.
Change-Id: I459c0b98ab9ce972d86a361c5ecdfe0c1a2d0e74
Sometimes vsync would not be disabled before the display is
blanked.
This was due to the vsync disable ioctl being kicked off in a
thread different from the event control which surfaceflinger
called. So, while the calls from surfaceflinger are in order, the
order of execution wasn't always the same. Hence, making sure
ioctls are called in the same context to ensure order.
Also
- Make blanking/unblanking logs show the operation as a string.
- Add a debug property to dump vsync timestamps (needs framework
reboot)
- Remove a log which showed delay in reading vsync. This log was
unreliable when vsync is disabled and we're still reading from
the sysfs node.
Change-Id: Ibec04e9ffebd0ac6e1d32b7031e3668abd9390ff
CRs-fixed: 443113
The driver returns EBUSY if it is unable to complete the frame
within a timeout - this is a recoverable error
Change-Id: Ifde01c1d7515598a82d032c0ba869fa658b050a9
Can be set for debugging, valgrind, board bringup etc.
Also - we fail reading the sysfs vsync, we fall back and fake it.
Bug: 7301591
Change-Id: I9509fd7aa8862d5af7d521e29fe32bef9654168c
Signed-off-by: Iliyan Malchev <malchev@google.com>
Conflicts:
libhwcomposer/hwc_vsync.cpp
Read can return fail when the panel is off.
When read fails do not exit from the vsync thread,
continue with the vsync signal, as later there will
be correct vsync event from the driver
Change-Id: I0f145b93fe5d365eafb6b9e7661160f00f84db40
Acked-by: Arun Kumar K.R<akumarkr@codeaurora.org>
(cherry picked from commit ef93ede83eba15252a5e902981c491bf8ed228cc)
Earlier, the sysfs node was created in the driver for the
first time in dsi_video_on. This has now been moved to probe
so this node can be opened to the start of the thread.
Bug: 7305728
Change-Id: I01230e4fdc2bddd160ce0d84e153f1f8c179b8df
Signed-off-by: Iliyan Malchev <malchev@google.com>
We are seeing errors where a device's hwcVsyncThread is not present for some
reason. The surface flinger has not crashed, so either the thread never got
created, or it exited withouth throwing an error. This patch adds some more
verbose on-error logging to the HWC as an attempt to verify the theory that the
thread does not get created, or fails in pthread_create. While we're at it, we
add the same logging at pthread_create() for hwcUeventThread, as well.
Also, replace the lseek()+read() with a pread() combo in the vsync thread.
Change-Id: I555d786a7d66ff4ef1dbfd95947a7d9341e56f11
related-to-bug: 7305728
Signed-off-by: Iliyan Malchev <malchev@google.com>
-- numHwLayers==1 means that there is only the FB_TARGET which HWC shouldn't
draw. Also check for blank in set. Checking for this in prepare prevents us
from acquiring pipes.
-- add null check for private handle
-- print out vsync timestamp data on error
bug: 7274417
related-to-bug: 7288769
Change-Id: I8dae0d0748c5226fdc33ed8f5cc5259835dec2de
Signed-off-by: Iliyan Malchev <malchev@google.com>
Fix some race conditions between hwc_eventControl and the hwcVsyncThread.
Bug: 7274951
Change-Id: Ic71d65918303b4cef6a379ff5397702b2b578373
Signed-off-by: Iliyan Malchev <malchev@google.com>
* Read sysfs entries to get vsync timestamp from kernel.
* External display continues to use uevents for hotplug events
* A new thread, vsyncThread is created to read and send vsync
timestamps to HAL.
* Disable H/W VSYNC for MDP 5.x targets until kernel changes are
complete.
* Synchronization is needed to make sure read() is not called
by hwcVsyncThread when VSYNC is disabled.
Change-Id: Iab0a94a3cfce9142b8867859f2a7d9bcaecb0996
Acked-by: Neti Ravi Kumar <ravineti@codeaurora.org>
