With lots of updates by Christopher James Halse Rogers as he updated the
XMir API - but now supposedly frozen!
"<RAOF> ickle: I think the xmir api should be pretty much stable now,
barring people coming up with more awesome ways of doing things."
Signed-off-by: Christopher James Halse Rogers <raof@ubuntu.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Now that the WriteThrough ABI is upstream, we can rely on runtime
detection of the current interface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Like it's sibling sna_pixmap_move_to_gpu(), it helps to know the private
sna_pixmap after the operation rather than just a boolean success/fail
result, and make it more robust in the process.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The latest proposal for passing swap_interval==0 is through the normal
ScheduleSwap() call, so we can remove the specialised function.
Link: http://lists.x.org/archives/xorg-devel/2013-September/037661.html
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When falling back to using XSync rather than XSendEvent it is imperative
that we remember to clear the flag so that we don't keep on performing
the synchronous RTT every time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As there is an XID inside the ShmSegmentInfo we cannot share one between
both endpoints, or else it gets clobbered and rendering is lost (unless
by happy coincidence the last XID is available in both Xservers).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The 'output-is-changed' flags was accidentally initialised to 01 rather
than 0, causing all attached outputs to be considered to have changed
everytime.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the Display doesn't support the more recent non-forced-detection
GetScreenResources, use the older version instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
bumbledeed will shutdown its Xserver when the last connection to it
closes. For the moment, leak the control socket so that the display
stays alive. However, we will want to attach to any Xservers created by
bumblebee as opposed to creating them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the flush may queue work that causes the timer to be reactivated
prior to draining the queue, we need to flush first then turn off the
timer if idle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For whatever reason, Xfixes uses "unsigned long" in its protocol
definition for the cursor pixels.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Make sure we are not responding to cursor motion on other screens, by
checking for our root window.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can't place the record fd at after the displays as we may wish to
clone more displays later and use the simplification that they are in a
linear, contiguous block at the end of the fd array.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With Xinerama, we do not support reconfiguration of the target's CRTCs
but we can still paint!
This will require some more work to try and minimise the incompatibility
between configuring Randr displays locally and the static arrangement
remotely. But you can paint!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When calling XNextEvent() you must provide it with space for any event,
i.e. XEvent, and not be tempted to pass in the specific type you are
waiting for!
Reported-by: Philipp Adolf
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we install a fake mode on the output, we have to perform a
round-trip for a reprobe. During that time, some other client (such as
gnome-shell) will be notify of the change in output status and may
attempt to configure it. This leaves us unable to delete the mode as it
is currently active - so first disable the new head and then delete the
mode.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may call the ->detect() routines during the fallback initial
probing, we need to handle the case where the output callbacks are
called before RandR is setup.
Regresion from
commit 8ecb758697
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Aug 31 19:44:50 2013 +0100
sna: Expand the array of fake outputs if the last is used
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68843
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sometimes the window size is not a simple box, but a full region. In
which case we do need to process it and not just assert that it is a
box!
Reported-by: Jiri Slaby <jirislaby@gmai.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When updating pointers to point into the new memory block after a
realloc, it helps to pass the new locations around rather than the old.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If reallocs gives us a new memory block, we need to update everything
that pointed into the old blocks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the user tries to use multiple commands to combine multiple displays,
reroute those to the first instance.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When converting to the auto-extending arrays, I forgot to include room
for the extra connection for the recording Display. By using an
explicit variable within the global state it is a little more clear.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And prevent cloning the localhost! The caveat is that the transport
string (Display name) must match, so it still would be possible to
connect to the same display with different transports (local sockets and
TCP sockets for socket) and so cause confusion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we try to create VirtualHeads, gnome-shell tries to enable them.
Leading to a lot of flashing and extraneous modes appearing. Without
being able to grab the screen configuration for the duration of our
pruning, there does not seem much we can do other than try and squelch
the worst of the errors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Now that we allocate VirtualHeads on the fly, we can query the list of
available outputs on the target display and clone them all, rather than
manually passingthe list of outputs to clone.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Aligning a 16-bpp image to a 32-byte boundary is tricky, apparently. Or
at least I make it look so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Always maintain one spare so that we can reconfigure for any number of
desired outputs on the fly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid up-converting to a depth-24 image and wasting extra bandwidth if
either end-point is only using depth-16.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Support rendering between mixed depths by using Render to stage the
transfer into our x8r8g8b8 image. An improvement would be to use the gcd
intermediate depth so we don't waste bw unecessarily.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we find that the headers for the tools are not available on the
system, simply disable building them as they are not essential features
of the driver.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Based on the original implementation (hybrid-screenclone) by
Tomáš Janoušek, and Bumblebee integration by Kevin Puetz.
intel-virtual-output utilizes local VirtualHeads to present a contiguous
desktop to the local display manager, but maps the drawing on those
outputs to the remote display, and provides bidirectional RandR proxy so
that you can resize the remote display and configure it within your
desktop. The remote display should also send hotplug events back to the
local desktop, for reconfiguration on the fly.
Ideally the remote display is a discrete GPU on the same host so that we
can use local Shared Memory transport and avoid sending data over the
wire (though it will work in that setup). Ideally you would have userptr
support to provide zero-copy rendering between the GPUs, or have dma-buf
(in which case you would be using PRIME). For remote rendering, no
compression is done so this fares worse than VNC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson