compositor-drm: disable hardware cursors

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>