summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPekka Paalanen <pekka.paalanen@collabora.co.uk>2015-05-19 09:53:16 +0300
committerPekka Paalanen <pekka.paalanen@collabora.co.uk>2015-05-19 11:41:11 +0300
commit6858383d51b12632481370fdc7d886a1e6bb4ebd (patch)
treec78aa7143fe275906fdaa4b96a40645074f0290d
parentc4cfe85d3af007e9fa30f10d10fa502ca1336fa6 (diff)
compositor-drm: disable hardware cursors
With the recent universal plane and atomic modeset / nuclear pageflip development in the kernel, cursor content updates on Intel are currently causing an extra wait for vblank. This drops Weston's framerate to a fraction by 2 when cursor contents update. This combined with the damage tracking bug in Weston which causes cursor content updates on every frame the cursor moves makes using hw cursors really bad. It is possible that the Intel DRM driver will get fixed and cursor updates there revert to their old behaviour on the contemporary KMS API. However, it is hardware dependant whether cursor updates can happen immediately. Some other hardware, especially ARM-related, may not be able to do immediate updates. Therefore it is better to just not even try - we should rely only on the lowest common denominator behaviour between hardware and drivers as there is no and will not be any way to reliably detect it. Note, that while having different drivers do different things (immediate update vs. update that gets latched on the next vblank), we cannot rearrange the contemporary KMS API calls such that it would always work fine. Either some hardware would update the cursor too early, or other hardware would update the cursor too late and perhaps cause the framerate decimation. Mark hardware cursors broken by default. This avoids using them, and works around the immediate problem of framerate issues in Weston. This follows the same reasoning why hardware overlay planes have been disabled by default for a long time. This disablement will be removed once the current code for hardware planes and cursors is replaced with code using the atomic KMS API. The Intel driver change that exposed this problem is https://github.com/torvalds/linux/commit/38f3ce3af5742eb5a3e9b01997f5ab85109c5762 which is first included in Linux 4.0-rc1. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Cc: nerdopolis <bluescreen_avenger@verizon.net> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Giulio Camuffo <giuliocamuffo@gmail.com> Reviewed-By: David FORT <contact@hardening-consulting.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
-rw-r--r--src/compositor-drm.c12
1 files changed, 10 insertions, 2 deletions
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 313860bd..0a9af5d6 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -2817,9 +2817,17 @@ drm_compositor_create(struct wl_display *display,
if (ec == NULL)
return NULL;
- /* KMS support for sprites is not complete yet, so disable the
- * functionality for now. */
+ /*
+ * KMS support for hardware planes cannot properly synchronize
+ * without nuclear page flip. Without nuclear/atomic, hw plane
+ * and cursor plane updates would either tear or cause extra
+ * waits for vblanks which means dropping the compositor framerate
+ * to a fraction.
+ *
+ * These can be enabled again when nuclear/atomic support lands.
+ */
ec->sprites_are_broken = 1;
+ ec->cursors_are_broken = 1;
section = weston_config_get_section(config, "core", NULL, NULL);
if (get_gbm_format_from_section(section,