If the kernel reports an error from setting the DPMS property, we need
to undo the local changes and propagate back the error to the caller.
Although the latter is prevented by the RandR API, we can at least
restore the backlight.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to allocate new damage boxes, first try collescing the
existing boxes to free up memory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to flush the batch if we run out of space aligning our vertex
buffer - but the test must anticipate the space required for the new
alignment.
Reported-by: Arkadiusz Miskiewicz
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can now check whether the Composite operation will require existing
CPU damage and if not discard it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This bit only exists for gen4+ so avoid setting it on gen2 and gen3,
whilst setting it doesn't seem to cause any harm, there is no reason to
risk it...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Composite operations were presumed to cover their entire width x height
area. However, a few paths submit boxes that do not cover the clip
region and so the optimisation made during prepare to discard completely
overwritten data is incorrect (and leads to corruption - stale data is
seen which the client expected to have been overdrawn). So along these
more unusual paths, we must add a flag to prevent the overzealous
discard. Notably, xfce4 triggers this as it uses a lot of unantialiased
trapezoids in its theme drawing.
References: https://bugs.freedesktop.org/show_bug.cgi?id=69528
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Inspired by (ok, copied from):
xf86-video-ati commit f2a0a5cf6c5a21e2a02280e110a4eb8e6609dace
Author: Michel Dänzer <michel.daenzer@amd.com>
Date: Wed Jan 22 11:04:42 2014 +0900
Don't require the glamoregl module to be pre-loaded with xserver >= 1.15
The issues with loading it on demand have been fixed in xserver 1.15.
Inspired by Jérôme Glisse on IRC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we may end up in a sitation where we show stale contents for a
(sometimes signification) fraction of a second before it is refreshed
with the correct contents.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73842
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Still gen4 is cursed. This should restore the plateau we reached with
2.99.907 by forcing a full GPU flush between every operation.
References: https://bugs.freedesktop.org/show_bug.cgi?id=55500
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The intention was to detect if the gc->pCompositeClip still pointed to
the temporary region. However, the assert failed to accomplish that
goal.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Commit 50a45a1cdd introduced the use of
"struct stat" but doesn't include <sys/stat.h>. Presumably that leaks
in trough some other header on Linux, but on OpenBSD compilation fails
because the struct isn't known.
If the user adds a mode to the VIRTUAL display and then attempts to use
it, add that mode to the remote display.
Reported-by: Christoph Bessei <admin@schwarzwald-falke.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73816
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
An artifact of our kernel/userspace interaction is that under certain
circumstances the kernel will report EAGAIN in order for it to have CPU
time to run its own workqueues before it can process the userspace
request. We can be cooperative and yield ourselves rather than busy-spin
waiting for the scheduler to demote us.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than just assert that we have used the pending update in
wait_for_shadow, discard it first.
Reported-by: Joe Peterson <joe@wildlava.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=70905
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
intel_device.c: In function 'intel_entity_get_devid':
intel_device.c:82:32: warning: declaration of 'index' shadows a global declaration [-Wshadow]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since 2010, DRI2 supports multiple driver names. That was added to ease
selection of appropriate driver by libvdpau. As for today, intel driver
support only DRI2DriverDRI (== 0), but not DRI2DriverVDPAU (== 1).
Although there is no any hardware-specific VDPAU driver for intel video
adapters at the moment, it would be easier to use generic drivers like
libvdpau-va-gl by creating symlink named libvdpau_i965.so.1. That way
appropriate driver will be selected in run time automatically:
libvdpau_i965.so.1 on i965 equipped machines, and libvdpau_nvidia.so.1
on nvidia equipped ones.
[ickle: Whilst I think this is a workaround for a brainfart in libvdpau
that it defaults to libvdpau_nvidia.so rather than first to
libdvpau_${DRI2DriverDRI} and then to a hardcoded libvdpau_backend.so,
I have no better solution, and this does seem in accordance with the
spec.]
Signed-off-by: Rinat <ibragimovrinat@mail.ru>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73507
When we convert a CPU bo into a GPU bo, we need to remove any dangling
shadow pointers we use for devPrivate.ptr. Whilst the bo remains alive
these are incoherent, but if we ever replace the GPU bo (for example to
change tiling for DRI2) then the dangling pointer becomes invalid and
will explode on next use.
Reported-by: Mike Aury <mike.auty@gmail.com>
Reported-by: Marti Raudsepp <marti@juffo.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73351
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than just state that the final pixmap->devPrivate.ptr is
non-NULL, we can assert that it matches the shadow value.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reduce the logging verbosity of DBG so that it only appears in the
logfile by default - makes debugging much more pleasant.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As an extra complication for handling TearFree is that if we attempt to
requeue a swap whilst the pipe is off, that fails. As we have recursed
from the pixmap migration path, we have to abort the blit but still send
the event back to the client so that they unblock.
Reported-by: Harald Judt <h.judt@gmx.at>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73469
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Mark Kettenis
Rinat