Hi,
(can't answer all spice questions, but parts of this with some qemu
background).
> Scan-out is a terminology quite similar to the old frame buffer, right?
> I think is meant to distinguish buffers to hold texture or other 3d stuff
> and buffers rendered to a screen.
Yes.
> I imagine the S
On Do, 2015-12-17 at 06:34 -0500, Marc-André Lureau wrote:
> Hi
>
> - Original Message -
> > > What happen with multiple monitors? Is it just not supported or a single
> > > scan-out is used for multiple monitors? Would be sensible to add the
> > > number
> > > of the scan-out to support
On Do, 2015-12-17 at 10:53 -0500, Marc-André Lureau wrote:
> Hi
>
> > > How whould that be compatible with the spice MonitorConfig messages? I
> > > don't think it's necessary, and it could easily be added later if needed.
> >
> > Ahem, scratch that. MonitorConfig isn't going to fly with virtio-
Hi,
> > But it is different from how multihead works on physical hardware these
> > days. Experience shows that usually it works better long-term when you
> > model virtual hardware as close as possible to physical hardware.
>
> I though multi-monitor (on same gpu) was more often done in hw wi
On Fr, 2015-12-18 at 03:47 -0500, Marc-André Lureau wrote:
> Hi
>
> - Original Message -
> > >
> > > If you create a "primary" surface with surface_create, that's
> > > basically all you need to start displaying. It could quite easily
> > > learn to take a shm fd while keeping the rest of
> > Which VGA? Workflow is quite different on qxl and anything else.
> > With qxl we'll go send the guests qxl render commands over to the
> > client, and the client renders it. On the qemu/server side there is no
> > rendered primary surface, unless someone asks for it and we kick the
> > local
Hi,
> The protocol can be the same of the GL case, actually being the frame buffer
> format
> being used by QXL very standard I think that GL buffer can be used for the
> same
> purpose. The problem is that the frame buffer is allocate into the virtual
> card
> memory by the guest (the guest
Hi,
> > Sure, we can move the rendering to the server side and provide just the
> > final result in a shared memory block to the local client (when a client
> > supporting that connects). I think it makes sense to use new commands
> > (be it extended gl-scanout or something else) for this. I'd
Hi,
> Then we realize in order to achieve X or Y, we need to do things
> slightly differently. What is our escape plan there? Do we have an easy
> way out without breaking older clients?
It's all guarded by the capability. So, yes, there is a sane backup
plan.
If we figure later we screwed up
Hi,
> Changes from v7:
> * When the client has support for GStreamer video codecs it now
> checks the presence of each supported codec before advertising support
> for it.
... and the server picks one codec which is supported by both client and
gstreamer, with the codec priorities being
Hi,
> > ... and the server picks one codec which is supported by both client and
> > gstreamer, with the codec priorities being configurable, is that
> > correct? So things keep working if gstreamer happens to have no h264
> > support (due to the patent mess) on either side?
>
> Yes.
[ ... lo
Hi,
> About virtio-gpu using virgl3d project for 3d hw acceleration support
> and is what I mainly watching for its large gpu choice/support, seems
> any gpu that have a drm driver in host kernel is supported by virgl, or
> I'm wrong?
You need a mesa driver too. But, yes, pretty much any mo
On Di, 2016-02-02 at 10:24 +0100, Christophe Fergeau wrote:
> Hey,
>
> On Tue, Feb 02, 2016 at 06:10:28PM +0900, Sunny Shin wrote:
> > I have a few questions about udp version of spice protocol.
> >
> > Is there a plan to support udp in spice protocol?
> >
> > If we support udp, what do we need
On Mi, 2016-02-03 at 13:27 +0900, Sunny Shin wrote:
> I heard that iptv uses udp multicast, so I thought that performance
> might be better if we use udp for video streaming.
spice != tv. No multicast here. Oh, and udp/multicast doesn't improve
performance, it reduces the bandwidth needed.
> W
From: Marc-André Lureau
Spice server will clear the cursor on resize. QXL driver reset it after
resize, however, virtio and other devices do not. Teach qemu to set it
back.
Signed-off-by: Marc-André Lureau
Signed-off-by: Gerd Hoffmann
---
ui/spice-display.c | 14 --
1 file
Adds helpers to open a drm render node and create a opengl
context for it. Also add a helper to export a texture as
dma-buf.
Signed-off-by: Gerd Hoffmann
---
include/ui/egl-helpers.h | 13 +
ui/egl-helpers.c | 129 +++
2 files changed
Keep track of gl_block state (added in bba19b8 console: block rendering
until client is done) in QemuConsole and allow to query it. This way
we can avoid state inconsistencies in case different code paths make use
of this.
Signed-off-by: Gerd Hoffmann
---
include/ui/console.h | 1 +
ui
ote too is planned (by feeding the dma-bufs into
gpu-assisted video encoder), but not there yet.
gl mode is turned off by default, use "-spice gl=on,$otherargs" to
enable it.
Signed-off-by: Gerd Hoffmann
---
include/ui/spice-display.h | 18 +++
qemu-options.hx| 4
virtio-gpu driver is loaded)
too.
This should improve performance even using spice (with gl=on) with
non-accelerated stdvga because we stop squeezing all display updates
through a unix/tcp socket and basically using a shared memory transport
instead.
Signed-off-by: Gerd Hoffmann
---
include/ui
be squashed into the previous
patch, or dropped after fixing things on the spice side.
Signed-off-by: Gerd Hoffmann
---
ui/spice-display.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/ui/spice-display.c b/ui/spice-display.c
index b222984..54702bb 100644
--- a/ui/spice
Adjust message levels, make messages more verbose.
Signed-off-by: Gerd Hoffmann
---
ui/spice-display.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/ui/spice-display.c b/ui/spice-display.c
index 17a71ce..264ecdb 100644
--- a/ui/spice-display.c
+++ b/ui/spice
Set CONFIG_OPENGL_DMABUF in case both mesa and libepoxy are
new enough to have support for dma-buf import/export.
Signed-off-by: Gerd Hoffmann
---
configure | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 0aa249b..0c0472a
Hi,
This patch series adds support for opengl and dma-buf passing to spice.
With this in place you can use virtio-gpu in 3d (virgl) mode with spice.
Not fully clear whenever the last patch (tagged as RfC) is actually
needed.
please review,
Gerd
Gerd Hoffmann (7):
configure: add dma-buf
with
spice-server. I expect they will go into a separate pull request.
Patch #12 will be squashed, either patch #11 or patch #9, depending
on the merge ordering, so I kept it separate for now.
please review,
Gerd
Gerd Hoffmann (11):
spice: init dcl before registering qxl interface
conf
Adds helpers to open a drm render node and create a opengl
context for it. Also add a helper to export a texture as
dma-buf.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Marc-André Lureau
---
include/ui/egl-helpers.h | 13 +
ui/egl-helpers.c | 129
Set CONFIG_OPENGL_DMABUF in case both mesa and libepoxy are
new enough to have support for dma-buf import/export.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Marc-André Lureau
---
configure | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/configure b
From: Marc-André Lureau
Spice server will clear the cursor on resize. QXL driver reset it after
resize, however, virtio and other devices do not. Teach qemu to set it
back.
Signed-off-by: Marc-André Lureau
Signed-off-by: Gerd Hoffmann
---
ui/spice-display.c | 14 --
1 file
Signed-off-by: Gerd Hoffmann
---
ui/spice-display.c | 4
1 file changed, 4 insertions(+)
diff --git a/ui/spice-display.c b/ui/spice-display.c
index 34e6d51..806851f 100644
--- a/ui/spice-display.c
+++ b/ui/spice-display.c
@@ -922,6 +922,10 @@ static void spice_gl_switch
Without this spice might callback into qemu before ssd->dcl.con is
initialized, resulting in a segfault due to NULL pointer dereference.
Signed-off-by: Gerd Hoffmann
---
ui/spice-display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ui/spice-display.c b/ui/sp
virtio-gpu driver is loaded)
too.
This should improve performance even using spice (with gl=on) with
non-accelerated stdvga because we stop squeezing all display updates
through a unix/tcp socket and basically using a shared memory transport
instead.
Signed-off-by: Gerd Hoffmann
---
include/ui
be squashed into the previous
patch, or dropped after fixing things on the spice side.
Signed-off-by: Gerd Hoffmann
---
ui/spice-display.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/ui/spice-display.c b/ui/spice-display.c
index 15d7906..96beb02 100644
--- a/ui/spice
Adjust message levels, make messages more verbose.
Signed-off-by: Gerd Hoffmann
---
ui/spice-display.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/ui/spice-display.c b/ui/spice-display.c
index d6e31e4..242ab5f 100644
--- a/ui/spice-display.c
+++ b/ui/spice
Signed-off-by: Gerd Hoffmann
---
include/ui/spice-display.h | 1 +
ui/spice-display.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/include/ui/spice-display.h b/include/ui/spice-display.h
index dd9cf6f..f9388c2 100644
--- a/include/ui/spice
ote too is planned (by feeding the dma-bufs into
gpu-assisted video encoder), but not there yet.
gl mode is turned off by default, use "-spice gl=on,$otherargs" to
enable it.
Signed-off-by: Marc-André Lureau
Signed-off-by: Gerd Hoffmann
---
include/ui/spice-display.h | 15
Pure debug aid, print a warning in case unblocking
doesn't happen within one second.
Signed-off-by: Gerd Hoffmann
---
include/ui/spice-display.h | 1 +
ui/spice-display.c | 16
2 files changed, 17 insertions(+)
diff --git a/include/ui/spice-display.h b/inclu
Keep track of gl_block state (added in bba19b8 console: block rendering
until client is done) in QemuConsole and allow to query it. This way
we can avoid state inconsistencies in case different code paths make use
of this.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Marc-André Lureau
On Mi, 2016-03-02 at 14:32 +, Frediano Ziglio wrote:
> If you have hardware cursor and you are reconnecting the VNC client
> you need to send the cursor. Failing to do so make the cursor invisible
> till is changed.
>
> Signed-off-by: Frediano Ziglio
added to ui patch queue.
thanks,
Gerd
On Fr, 2016-03-11 at 21:50 +0100, Marc-André Lureau wrote:
> 3.16 is the minimal version for GtkGLArea widget, used in following
> patches.
> - 3.0) GTK_REQUIRED=2.91.3
> + 3.0) GTK_REQUIRED=3.16
That puts the bar pretty high. 3.16 is only one year old and hasn't yet
found its way into LTS and
On Mo, 2016-03-14 at 12:03 -0400, Marc-André Lureau wrote:
> Hi
>
> - Original Message -
> > On Fr, 2016-03-11 at 21:50 +0100, Marc-André Lureau wrote:
> > > 3.16 is the minimal version for GtkGLArea widget, used in following
> > > patches.
> >
> > > - 3.0) GTK_REQUIRED=2.91.3
> > > + 3
Hi,
> > Dropping wayland isn't an option I think. Is it possible to build
> > with/without glarea support (depending on the installed gtk version) and
> > hiding that from applications without too much fuss? I.e. with the
> > glarea widget being a child of the new gtkstack widget, can we swap
On Fr, 2016-02-19 at 10:14 +0100, Gerd Hoffmann wrote:
> Current spice client expects we create a primary surface,
> even if we do display updates using dma-bufs exclusively.
>
> So just do that to get things going.
>
> Not fully clear whenever that is intentional or a bug o
On Fr, 2016-03-18 at 14:45 +0100, Marc-André Lureau wrote:
> Hi
>
> On Fri, Mar 18, 2016 at 2:17 PM, Gerd Hoffmann wrote:
> > Ping Marc? Any comment on this?
>
>
> Could you send a rebased series, for the patches that lead to the
> issue?
Update pushed to https://w
On Di, 2015-06-09 at 09:49 +0100, Frediano Ziglio wrote:
> This patch allow to limit number of heads using qxl driver. By default
> qxl driver is not limited on any kind on head use so can decide to use
> as much heads.
There is a hard limit of 16 monitors in the qxl device ...
> Main question an
On Di, 2015-06-09 at 10:26 +0100, Frediano Ziglio wrote:
> 2015-06-09 10:12 GMT+01:00 Gerd Hoffmann :
> > On Di, 2015-06-09 at 09:49 +0100, Frediano Ziglio wrote:
> >> This patch allow to limit number of heads using qxl driver. By default
> >> qxl driver is not limited
On Do, 2015-06-11 at 10:38 +0100, Frediano Ziglio wrote:
> libvirt has this as a video card parameter (actually set to 1 but not
> used). This parameter will allow to limit setting a use can do (which
> could be confusing).
Hmm. So heads is '1' by default but ignored today. When this starts to
b
On Do, 2015-06-11 at 12:04 +0200, Christophe Fergeau wrote:
> Hey,
>
> On Wed, Jun 10, 2015 at 03:37:09PM -0700, Mike wrote:
> > I'm trying to get 2K+ resolutions to work with SPICE/QXL and QEMU 2.2
> > (Ubuntu Vivid) on the host and Ubuntu Trusty on the guest. Currently the
> > highest resolution
On Do, 2015-06-11 at 08:58 -0700, Mike wrote:
> Hi Christophe,
>
> I was using just "spicec" as the viewer in full screen mode, but trying
> remote-viewer doesn't seem to make any difference (full-screen or
> windowed mode), it just scales the guest display (and results in blurry
> text)
Hi,
> > Has there been much progress with 3D support, if so, is there any
> > experimental spice build that I could try out? Do you think we'll
> > ever see gaming through spice?
>
> This depends more on QEMU-side by having the right bits upstream [0]
> but it will probably take while.
>
> [0]
Hi,
> > This patch rely on some change in spice-protocol which are not still
> > accepted. See
> > http://lists.freedesktop.org/archives/spice-devel/2015-June/020221.html.
What is the upstream status here? accepted meanwhile?
cheers,
Gerd
___
Sp
Hi,
[ context for spice folks: patch was added to qemu increasing usb-audio
default buffer size ]
> > What bothers me is that you have no qualms about making latency on
> > everyone's system worse.
>
> How do you know it makes sound on other people's systems worse? If you have
> actually do
Hi,
> > Higher chance is with video playback. lip sync issues might show up,
> > although you probably still have to watch carefully to actually notice.
>
> Regarding the video playback workload: video playback is not a
> low-latency audio use case. That's why you won't notice any difference
Hi,
Resuming to work on this after 2.6 freeze break ...
> I have done some more testing and sent a series for spice-gtk fixing
> display with gl scanout-only case. And a minor patch to spice server
> to solve a cursor initialization when there is no canvas. Your series
> works ok with that, onl
On Mo, 2016-05-23 at 16:03 +0200, Marc-André Lureau wrote:
> Hi
>
> On Mon, May 23, 2016 at 3:52 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> > Resuming to work on this after 2.6 freeze break ...
> >
> >> I have done some more testing and sent a series
Store MemoryRegion and offset instead of a pointer for each qxl memory
slot, so we can easily figure in which memory region an qxl object
stored.
Signed-off-by: Gerd Hoffmann
---
hw/display/qxl.c | 15 +++
hw/display/qxl.h | 3 ++-
2 files changed, 13 insertions(+), 5 deletions
(linux kms driver does that).
https://bugzilla.redhat.com/show_bug.cgi?id=1235732
Signed-off-by: Gerd Hoffmann
---
hw/display/qxl.c| 37 +
hw/display/trace-events | 2 +-
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/hw/display
New helper function which translates a qxl physical address into
memory slot and offset. Also applies sanity checks. Factored out
from qxl_phys2virt. No functional change.
Signed-off-by: Gerd Hoffmann
---
hw/display/qxl.c | 59
1 file
Hi,
> Yes you want to use EGL here, I think we could probably put more code in qemu
> to help with this case.
Sure, if anything is needed we'll get that sorted ;)
I suspect spice-server needs access to the gl context helpers
(dpy_gl_ctx_*) if it wants use opengl.
Possibly it also wasn't the m
On Fr, 2016-07-15 at 14:49 +0100, Frediano Ziglio wrote:
> This patch is an improve to last one. There are still many work
> to be done. The main reason I'm posting is to discuss the Qemu
> API changes ("Define a new interface for Qemu to pass texture"
> patch). This code add dependency to EGL dire
Hi,
> > What is the state of the hardware supported encoding?
> > How can we pass buffers to the hardware encoder?
>
> The state here is a bit of a mess.
> One reason to pass texture instead of dma buffers is that we use gstreamer
> and gstreamer for hardware acceleration uses VAAPI and one wa
Hi,
> > Hmm. The guest will not give us 2-3 frames though. We'll have either
> > one or two, depending on whenever the guest uses page-flips or not. So
> > implementing a buffering scheme as outlined above requires us to copy
> > (or let the gpu copy) the frames.
> Probably 2 are enough, 1 I
On Mi, 2016-11-02 at 18:00 +0100, Christophe Fergeau wrote:
> The use of drm_cvt_mode() in qxl_add_monitors_config_modes() means that
> the resolutions we are going to present to user-space are going to be
> rounded down to a multiple of 8. In the QXL arbitrary resolution case,
> this is not useful
On Do, 2016-11-03 at 12:41 +0100, Christophe Fergeau wrote:
> On Thu, Nov 03, 2016 at 09:53:48AM +0100, Gerd Hoffmann wrote:
> > On Mi, 2016-11-02 at 18:00 +0100, Christophe Fergeau wrote:
> > > The use of drm_cvt_mode() in qxl_add_monitors_config_modes() means that
> >
Hi,
> I think we should try it an see,
Ok, lets try. I'll go pick them up and prepare a pull with this and
some virtio-gpu bits,
Gerd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spi
On Mo, 2016-11-07 at 09:00 +0100, Christophe Fergeau wrote:
> Hey,
>
> Same series as v2 except that I removed the use of camel case in patch 6/7.
> Now it's only using an anonymous enum + int.
Can you please not drop the "PATCH" from $subject?
thanks,
Gerd
___
On Fr, 2016-12-02 at 17:44 +, Dr. David Alan Gilbert wrote:
> Hi Gerd,
> I've got a moderately repeatable crash with spice playing
> a video + postcopy. Some of the time I just get a warning
> (that I also get in precopy) but sometimes it turns into
> a backtrace;
>
> This is:
> f24 guest
Hi,
> >> On a quick glance I'd blame the guest for sending corrupted commands.
> >> Strange though that it happens on migration only, so there could be
> >> a host issue too. Or a timing issue triggered by migration.
> >>
> >> Which migration phase?
> >
> > This is the point at which it switche
Hi,
Yep, spice worker thread ...
> Thread 7 (Thread 0x7fbe7f9ff700 (LWP 22383)):
> #0 0x7fc0aa42f49d in read () from /lib64/libpthread.so.0
> #1 0x7fc0a8c36c01 in spice_backtrace_gstack () from
> /lib64/libspice-server.so.1
> #2 0x7fc0a8c3e4f7 in spice_logv () from /lib64/libspi
On Mi, 2017-01-04 at 15:40 +0100, Behrooz Shabani wrote:
> Hi Gerd,
>
>
> I hope you are doing well.
>
>
> I watched one of your talks about virgl and spice, great work!
>
>
> Currently, I am busy with my specialization at Saxion university which
> is about virtualization of graphic cards.
>
Hi,
> Note also that under Linux currently all these protocol limitations allows
> to support only a single device with multiple output, which is a problem for
> vGPU. Under Windows we support multiple devices but all devices are limited
> to one monitor. Extending Linux using the same limitatio
Hi,
> "we only support" seems to just state the use cases before adding
> vGPU but we are trying to support vGPU cases.
> If even we decide that for vGPU cards we always have monitor_id == 0
Yes, we want this for sure. One channel per display.
> (that is multiple DisplayChannels for each vGPU
Hi,
> There's not a new channel type, but there is a new channel, because
> there are two devices. Both the QXL device and the vGPU have their own
> Display channels.
> * channel #0 is the QXL device and only displays stuff at boot time
>(or when switching to a VT)
> * channel #1 is the n
Hi,
> 1. The logic used to switch something for something and when - You need
> to define somehow you have this QXL device that is showing the boot in
> client display 1 and then you start X and want to replace client
> display 1 with X monitor 1. Then the user switches VTs and you need to
> swi
Hi,
> Note that if all we want to support with the associated QXL device is
> text console, we may perhaps just drop the QXL device and use
> console/VT directly using spice ports, like I proposed in virt-viewer
> "[PATCH 00/22] Add QEMU-like UI: VT console & basic VM state" series.
Not going t
Hi,
> > Long-term there should be no need to have a separate QXL device for
> > boot messages.
>
> Interesting, why do you think so?
Well, there is the vnc console for the nvidia vgpu. Which wasn't
mentioned in this thread yet, how does it fit into the picture btw? I
guess there will be two
On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> On Thu, 2018-08-23 at 22:42 +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > "we only support" seems to just state the use cases before adding
> > > vGPU but we are trying to support vGPU c
Hi,
> > Yes, we want this for sure. One channel per display.
>
> Maybe you cut too much context. Who is "we" in the above sentence?
> Why "we want"?
See other reply.
> > Yes. *That* is the underlying problem. There is no guest-visible link
> > between display device and spice channel. Exc
On Fri, Aug 24, 2018 at 09:16:09AM -0400, Frediano Ziglio wrote:
> >
> > On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> > > > Yes, we want this for sure. One channel per display.
> > >
> > > For sure? This deserves a justification.
> >
> > That is the way modern display archite
On Fri, Aug 24, 2018 at 03:38:07PM +0200, Lukáš Hrázký wrote:
> On Fri, 2018-08-24 at 14:25 +0200, Gerd Hoffmann wrote:
> > On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> > > On Thu, 2018-08-23 at 22:42 +0200, Gerd Hoffmann wrote:
> > > > Hi,
>
Hi,
> > > Having a single frame buffer for channel is a current implementation
> > > limit which can be relaxed.
> >
> > But I don't think this is possible without changing spice protocol and
> > qxl device. Which opens the question whenever this is worth the trouble
> > or whenever we should
Hi,
> > Hmm, why? I fail to see the point given that qxl wouldn't be able to
> > use it unless you change it too, and all other qemu display devices are
> > either single-head anyway (stdvga, cirrus, ...) or use one channel per
> > head.
>
> To support streaming of multiple outputs with a sing
Hi,
> > Is there a high-level overview of the changes planned? For starters I'm
> > mostly interested in spice-protocol and qxl guest interface changes. We
> > need to get the concepts right before implementing the stuff. And I
> > think its easier if we bundle the changes into one protocol u
Hi,
> > > > Really? Can you describe how the guest could read that? Thanks.
> > >
> > > It's QXLRom->id (see /usr/include/spice-1/spice/qxl_dev.h).
> >
> > That's from the driver, right?
>
> Yes.
Scratch that. It's a different ID. In a typical setup they happen to
be equal by pure luck, bu
Hi,
> 1. The IDs sent from the client in VDAgentMonitorsConfig and
> MousePosition messages are equal to either `channel_id + monitor_id` or
> `channel_id ? channel_id : monitor_id`. This is under the assumption
> that there is either only one display_channel or more display channels
> each with
Hi,
> +typedef struct SpiceMsgcMousePositionV2 {
> +uint32_t x;
> +uint32_t y;
> +uint32_t buttons_state;
> +uint32_t channel_id;
> +uint32_t monitor_id;
> +} SpiceMsgcMousePositionV2;
When touching the mouse messages anyway I'd suggest to design it more
like the linux input
Hi,
> +/* Message containing information about the stream, sent when a new stream
> is created.
> + */
> +typedef struct StreamMsgInfo {
> +/* The xrandr output ID (index of the output in the list) that is being
> + * streamed, 0-based.
> + */
> +uint32_t guest_output_id;
> +} S
On Mon, Aug 27, 2018 at 03:34:54PM +0200, Lukáš Hrázký wrote:
> On Mon, 2018-08-27 at 14:27 +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > 1. The IDs sent from the client in VDAgentMonitorsConfig and
> > > MousePosition messages are equal to either `channel_id +
> struct {
> ...
> uint8_t channel_id:4;
> uint8_t monitor_id:4;
> ...
> };
>
> at this point however both the client and server have to be changed,
Server side yes, because it assigns the numbers.
Why the client side too?
> this new schema is just introducing a limitation (16 channels a
On Mon, Aug 27, 2018 at 05:08:43PM +0200, Lukáš Hrázký wrote:
> On Fri, 2018-08-24 at 13:49 +0200, Gerd Hoffmann wrote:
> >
> > Well, there is the vnc console for the nvidia vgpu. Which wasn't
> > mentioned in this thread yet, how does it fit into the picture btw? I
&
Hi,
> This would work for the channel_id + monitor_id formula, but not for
> the channel_id ? channel_id : monitor_id one. AFAIK channel_id ?
> channel_id : monitor_id is used only in spice-gtk and channel_id +
> monitor_id is used in virt-viewer and spicy.
[ ... ]
> And we still need to fix t
On Mon, Aug 27, 2018 at 12:13:47PM -0400, Frediano Ziglio wrote:
> >
> > Hi,
> >
> > > +typedef struct SpiceMsgcMousePositionV2 {
> > > +uint32_t x;
> > > +uint32_t y;
> > > +uint32_t buttons_state;
> > > +uint32_t channel_id;
> > > +uint32_t monitor_id;
> > > +} SpiceMsgcMous
Hi,
> > Well, "vnc console" is how the nvidia guys name it, the term doesn't
> > really match. It's basically a simple framebuffer where the nvidia
> > driver renders the guest display, and a vfio interface for qemu to
> > access it. From spice point of view it looks very simliar to the qemu
>
Hi,
> Well, so instead of tagging messages the protocol is tagging single fields,
> something like the difference between a plain text and XML (although there's
> no hierarchy in evdev schema). Is possible but this suggestion is more about
> base protocol change.
Yes.
If we have to add Mouse*V
> > > Ok, that makes some sense. You do however need some synchronization
> > > mechanism between the different framebuffers? (Imagine a video playing
> > > across two displays)
> >
> > The linux kernel kms drivers support atomic page flips for both
> > displays, and wayland actually uses that.
>
> > > Now I'm mostly guessing here, but from what I understand, we could send
> > > the frames of multiple monitors in sync over a single display channel,
> > > but if we use multiple channels, they are not synchronized and would
> > > arrive rather arbitrarily on the client?
> >
> > With a single
On Tue, Aug 28, 2018 at 05:26:15PM +0200, Lukáš Hrázký wrote:
> On Fri, 2018-08-24 at 17:21 +0200, Gerd Hoffmann wrote:
> > On Fri, Aug 24, 2018 at 03:38:07PM +0200, Lukáš Hrázký wrote:
> > > At this moment, the agent has no idea about channel_ids,
> >
> > I t
On Tue, Sep 18, 2018 at 02:52:27PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Mon, Sep 17, 2018 at 5:24 PM Yuri Benditovich
> wrote:
> >
> > This series of patches adds ability to share ISO files or
> > local CD devices with guest system using USB redirection
> > by emulation of USB CD device.
>
Hi,
> > Hmm, so it isn't only usb emulation, but also scsi emulation duplicated
> > in spice-client. Why this route? Wouldn't it be simpler to run nbd
> > over spice-chardev, then hook up the iso as blockdev in qemu? Which
> > you then can attach to any cdrom emulation (ide/sata/scsi/usb) in
Hi,
> this is the reworked second version of the Monitor ID series.
Ping. What is the status here? v3 coming?
Another lousely related thing: While debugging another issue I've
noticed that QXLMonitorsConfig has a surface_id field. What this is
intended for? Map non-primary surface to a he
Hi,
> > Can you summarize the reasons to discard the approach?
> >
>
> I will try.
>
> The POC of nbd-based cd sharing was on the table. It needed some
> unclear rework to avoid breaking ABI with mainstream spice-server.
--verbose please.
> The solution requires updates in qemu and spice on
Hi,
> - We're going to try to implement you suggestion of identifying the
> monitors in the guest basically according to your outline in
> https://lists.freedesktop.org/archives/spice-devel/2018-August/045465.html
Ok. I'll stay tuned. Cc'ing me on patches you send out would be great.
> > Ano
1 - 100 of 964 matches
Mail list logo
