X always sends MappingNotify events (there is no way for the client
to ignore them). In particular, MappingNotify would be sent after a VT
switch, and this would knock out our ability to track the cursor..
Reported-by: Raul Dias <raul@dias.com.br>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75115
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If all the outputs are off, we try to resize the screen to 1x1, which is
typically illegal. So, just keep the existing screen and xfer buffer for
next time it is enabled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
This reverts commit abf1a16914.
We need to track visibility over all clones on a display, not just the
last.
Regression from
commit abf1a16914 [2.99.906]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Nov 8 17:09:35 2013 +0000
intel-virtual-output: Only track the most recent visibility status of the curso
Reported-by: Kirill Müller <mail@kirill-mueller.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71838
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we modify the outputs and end up with a different screen size, we
need to actually tell the display to resize with an explicit
XRRSetScreenSize.
Reported-by: Jethro Beekman <freedesktop-bugs@jbeekman.nl>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71441
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
XPending() reports if there are any events pending and does not perform
any dequeuing itself - ergo for a remote display while (XPending()) ;
becomes an infinite loop should there be an event pending.
References: https://bugs.freedesktop.org/show_bug.cgi?id=71345
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst we want to take over and hide the cursor on the remote displays,
on the source we need to not interfere with the host.
Reported-by: Jethro Beekman <freedesktop-bugs@jbeekman.nl>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71439
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to track rendering using ShmCompletionEvents and begin to
drop frames, insert an explicit XSync.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we ourselves only track the BBox of damage on the virtual outputs, we
can ask X to amalgamate the damage events as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Some versions of the Xserver lose Damage tracking across the modeset,
causing a loss of damage notifications and repainting to cease on the
virtual outputs. We can workaround this by reattaching the damage every
time we receive notification that the local Screen configuration
changes.
Reported-and-tested-by: Severin Strobl <fd@severin-strobl.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68987
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The timer will be enabled if a reconfiguration actually takes place and
we mark the damaged region to be redrawn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After processing the Damage notification, we need to send a message back
to the Xserver to clear the pending damage before we will be sent more
events. To make sure that message is sent we need to flush the output,
as we may never flush the output queue otherwise.
Reported-by: Severin Strobl <fd@severin-strobl.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68987
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For the frequent operations, such as moving the cursor or updating
damage, it is more efficient to walk the list of active outputs (as the
discrete GPUs support lots of outputs!)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Kirill Müller
Zdenek Kabelac