[PATCH weston] compositor-drm: disable hardware cursors

[Hardening]

Le 19/05/2015 09:26, Pekka Paalanen a écrit :
> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> 
> 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 at collabora.co.uk>
> Cc: nerdopolis <bluescreen_avenger at verizon.net>
> Cc: Daniel Stone <daniel at fooishbar.org>
> Cc: Giulio Camuffo <giuliocamuffo at gmail.com>
> ---
> 
> There are no bug reports or emails to be referenced here, are there?
> At least I couldn't find any.
> 
> Thanks,
> pq
> 
>  src/compositor-drm.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 313860b..0a9af5d 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,
> 
Perhaps it would be nice if the most adventurous of us could re-enable
the cursors using a configuration file option...

Except this non blocking remark,
Reviewed-By: David FORT <contact at hardening-consulting.com>


-- 
David FORT
website: http://www.hardening-consulting.com/