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