If the xlib/xcb library has pulled events from the fd, then a poll on
that fd will block until new events arrive. If none do, we fail to
process the currently waiting events in a timely fashion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When attaching to a target display, disable the builtin screen blanking
(equivalent to xset -d :8 s off, or setting
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
in the target xorg.conf). Then listen to the ScreenSaver notify events
on the host and forward the activations/resets to the targets. This
should then keep all the screen blanking in sync.
Reported-by: Raffael Herzog <herzog@raffael.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93562
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the destination screen is exposed (for example screensavers), we need
to redraw. So enable the ExposeEvent on the target and synthesize
damage to any clones on that display in order to trigger a redraw.
Reported-by: Raffael Herzog <herzog@raffael.ch>
References: https://bugs.freedesktop.org/show_bug.cgi?id=93562
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When using a fixed mode, e.g. a Display without RandR support like
Xnest, we have to remember to hook up the connection during
recofiguration of VIRTUAL outputs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We only need a single copy of the cursor image, from which we can create
all the cloned cursors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Using xcb, we cannot simply call xcb_dri3_query_version() without it
terminating the connection if DRI3 is not enabled on the target display.
Oops.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89172
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
virtual.c:1081:6: warning: variable 'width' is used uninitialized
whenever 'if' condition is true [-Wsometimes-uninitialized]
if (clone->dst.mode.id == 0) {
^~~~~~~~~~~~~~~~~~~~~~~
virtual.c:1092:6: note: uninitialized use occurs here
if (width == clone->width && height == clone->height)
^~~~~
virtual.c:1081:2: note: remove the 'if' if its condition is always false
if (clone->dst.mode.id == 0) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
virtual.c:1079:11: note: initialize the variable 'width' to silence this warning
int width, height;
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Third one-line patch to fix copying from the tainted user argument into
the socket's path buffer. This time, give in and just use snprintf() as
it guarrantees that it will not write more than 'n' characters and that
the last is a NUL byte.
Suggested-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Somebody (me) confused it with snprintf() and put the string length in
the wrong location. Also note that strncpy() does not NUL terminate long
strings.
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having the pkgconfig present doesn't always necessarily imply the
headers are installed correctly - just fail over gracefully for xinerama
and intel-virtual-output
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Original patch by main.haarp:
"A verbose switch is quite useful for debugging, it shouldn't require
editing and recompilation to gain more useful output. I added it."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80664
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the image inherits its width/height from the clone, we need to set
those first on the clone.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79994
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rerun a detection cycle after claiming the virtual output so that it is
hidden again.
References: https://bugs.freedesktop.org/show_bug.cgi?id=78293
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is fortunately a no-op, as it gets initialized to zero already
(that is the pixmap is writeable). However, we may as well do the right
thing...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to disable the remote output during initialisation, copy the
current configuration in order to try and keep the bookkeeping in order.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to prevent a subsequent BadAccess when we try to use it as a
ShmPixmap, we need to mark the segment as writeable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.freedesktop.org/show_bug.cgi?id=78293
Creating a ShmPixmap may cause an asynchronous BadAccess error, so wrap
the construction with XSync and check for an error before proceeding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.freedesktop.org/show_bug.cgi?id=78293
Only mark an output as disabled if we do successfully disable it. This
will require a little more work to make sure that such errors are
cleanly propagated back to the host...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sigh. A serious mixup of integer promotion rules and wraparound caused
the damage computation for small regions to be completely bogus.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When iterating over the active list to mark the current damage, we need
to chase the ->active pointer rather than ->next or else we walk the
wrong list from the wrong starting point.
Reported-by: Kirill Müller <mail@kirill-mueller.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76271
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we walk the output lists in the same order as they are listed by
RandR, we are more likely to hit favourable priority sorting. E.g. the
user is likely to setup the outputs in the same order as listed, meaning
fewer CRTC transitions etc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For whatever reason, presumably to do with the switch between CRTCs, we
need to disable the panning before setting the mode in order for our
desired CRTC position to take effect.
Reported-by: Jeff Katz <bugzilla@kraln.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76146
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>