After applying scaling to the cursor image, it was being positioned on
the display incorrectly due to the hotspot transformation remaining
unscaled and so offseting the cursor slightly.
References: https://bugs.archlinux.org/task/45572
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the kernel doesn't accept the update, then the CRTC remains in its
previous mode i.e. we should not also touch the modesetting serial
stamp.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Force the full reprobe, resetting all the output properties on all
outputs if we detect a status change on hotplug. Rather than simply
translate the kernel mode lists ourselves, use the common functions in
case more settings change.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91929
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since we only update the mode list when the user queries xrandr or upon
a hotplug event, queue a deferred probe for 2s after X starts in order
to fill in the unknown modes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Some display managers, for example mutter, only use
XRRScreenResourcesCurrent() which means they only query the existing
modes on an output. We need to therefore update the list of available
modes after a hotplug event.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
During the hotplug event, we query the current connector status and use
that to trigger an output changed event to the clients. However, since
we know the new status, we can set that on the RROutput immediately.
Note the modelist is left unchanged, and will only be queried when the
user requests it (though we may want to provide that in the hotplug
notify as well).
References: https://bugs.freedesktop.org/show_bug.cgi?id=91929#c2
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to catch transitions between SwapInterval 0 and 1 in the middle
of a flip sequence, we need to reset our swap_limit every time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just in case we want to debug the native vs software paths and allow
switching without recompiling. For the unfortunate
Section "Device"
Identifier "igfx"
Driver "intel"
Option "HWRotation" "off"
EndSection
default is for us to use HW rotation where available (for speed, reduced
resource usage and reduce power usage).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once again I tried to add an event to a pixmap, but only Windows carry
the CRTC tracking information. Stop it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can use the same macro on top of the xorg list.h interloper as well
as the private version, so do so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even though the kernel reports and error and we skip the queuing, we
have information to avoid the roundtrip through the kernel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On a headless or hosted system, we do not have any CRTC on which to
report or queue the vblank. Reporting a BadDrawable is evil (as clients
never expect the error) but is better than crashing the Xserver.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Along the blit swap path, we expect the buffer to not be scanout
compatible and not have the same pitch as the front buffer. The reuse
logic failed to take this into account!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes a regression from
commit 3f128867d9
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Aug 7 15:19:17 2015 +0100
sna: Skip a no-op copy
that forgot that we can flush damage but still have valid contents to
copy from.
Reported-by: Timo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the window may be reparented during its swap lifetime, we may be able
to recreate the backbuffer ready for flipping next swap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the DRI2BufferPtr destruction may be delayed, by the time we do
free it, the state may no longer be accurate. (At this level at least,
there is a later assertion to the same regard just as we think we are
releasing the buffer.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we release the accel backend, we mark the interface as wedged.
However, when we release the modesetting backend we flush the vblank
queue which may want to do rendering. So if we do that first then
disable the accel backend, things we go much smoother.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658#c20
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This so that we permanently exclude the active front buffer from the set
of triple buffer replacements.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Down one particular patch (overlapping render copies) the
scratch.pScreen is dereferenced (to create a temporary Pixmap). Ensure
that we populate it before hand.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To ease tracking of the next swap, stash it on the event (which is then
reused) rather than the back buffer (which changes frequently).
In addition, add debug flags and assertions to track event stages (such
as making sure we do not decouple/free an event that we have sent a
signal back to the client).
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658
References: https://bugs.freedesktop.org/show_bug.cgi?id=70461
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we don't control the vblank for the window, we cannot use the vblank
signal as it ends up being queued as well.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A side effect of commit 4cea803798
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Aug 8 22:10:20 2015 +0100
sna/dri2: Restore caching of fullscreen triple buffers
was that we discovered that we had been inserting the buffer into the
cache list multiple times.
Reported-by: Dan Doel <dan.doel@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658#c5
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the DRI2 copy ends up on the CPU, then we will not have a GPU
request for the operation.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If a client dies with a pending flip, we have to complete it so that the
scanout matches the frontbuffer again. This requires one last flip
following the client disapparance.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Letting GL clients run amok when offscreen (or when hidden) has
unexpected UX behaviour. Instead we can elect to throttle them to the
nearest CRTC and keep the desktop running smoothly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Similarly to the fix for reflection into rotation, make sure we only set
one Rotation bit afterwards.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When reducing a xy reflection to a 180 degree rotation, make sure
only one rotation bit is set. Also by rotating the bit left, we
can support cases where xy reflection happens with 90/270 degree
rotation.
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
[ickle: Interleave comments]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When the client misses a swap, we consider it idle and unlikely to swap
again for a while. We try to take advantage of that and remove the old
back buffers. But it is likely to swap again and so having some of that
cache around would be advantageous.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than just discarding the old buffer, we want to add it to the swap
cache and so hand it back to the client in the near future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Based on further study of behaviour under a compositing manager, always
prefer to upload directly into the flushed bo, with a couple of
exceptions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the batch is being frequently flushed due to Damage+Composite
tracking, we cannot amalgamate the small copies into the destination and
so end up sending thousands and thousands of tiny batches with tiny
render copies hogging the GPU.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91577
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>