Hi
I want to know that whether all the graphics are rendered in the Spice client
or not. For example, the engine-managed surfaces are rendered in VNC way,
however device-managed surfaces are rendered in Spice way (through cmds:
QXLdrawable).
Thanks in advance
Best Regards!
_
Hi
I want to know that whether all the graphics are rendered in the Spice client
or not. For example, the engine-managed surfaces are rendered in VNC way,
however device-managed surfaces are rendered in Spice way (through cmds:
QXLdrawable).
Thanks in advance
Best Regards!
On Wed, Apr 18, 2012 at 11:12 PM, Alon Levy wrote:
>
> On Wed, Apr 18, 2012 at 03:56:54PM -0600, Noel Van Hook wrote:
> > I am not sure I fully understand the ramifications of having a list of ram
> > headers. Is the intent to have one additional ram header per additional
> > head?
>
> Yes, that
On Thu, Apr 19, 2012 at 03:17:15AM +0200, Marc-André Lureau wrote:
> The remote end receives key press and key release seperately, but this
> can cause extra key repetition between the two event messages:
> - if the network is slow
> - if the server is busy and doesn't handle the events quickly eno
On Wed, Apr 18, 2012 at 07:04:35PM +0200, Marc-André Lureau wrote:
> We might want to make it a property, but having an environemnt variable
> is useful too, to override behaviour.
Do we want to start documenting those environment variables at some
point? Just a thought.
ACK.
> ---
> gtk/channe
On Wed, Apr 18, 2012 at 06:52:55PM +0200, Marc-André Lureau wrote:
ACK Series. Just note you left a FIXME in the last patch, although I'm
not sure why you'd want to assert there.
> ---
> server/snd_worker.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/server/snd_w
On Wed, Apr 18, 2012 at 03:56:54PM -0600, Noel Van Hook wrote:
> I am not sure I fully understand the ramifications of having a list of ram
> headers. Is the intent to have one additional ram header per additional
> head?
Yes, that was the idea.
>
> For multiple heads to work correctly, I belie
The remote end receives key press and key release seperately, but this
can cause extra key repetition between the two event messages:
- if the network is slow
- if the server is busy and doesn't handle the events quickly enough
- if the client is slow or busy
(I think the guest/os couldn't be resp
Currently multiple monitors in Spice is like installing multiple graphics
cards in your physical computer, with one display attached to each card.
>From a practical point of view, what it gets you is a second client window
that you can extend your guest desktop onto.
It is not multi-session.
It
I am not sure I fully understand the ramifications of having a list of ram
headers. Is the intent to have one additional ram header per additional
head?
For multiple heads to work correctly, I believe:
1) the framebuffer must be contiguous
2) the entire framebuffer must be accessible to all heads
Hi
On Wed, Apr 18, 2012 at 7:34 PM, Marc-André Lureau
wrote:
> It would be
> -> QOS_QUERY(nbytes)
> -> nbytes of various messages 1 or n
> <- QOS_ACK
Further questions about this, how can the server really determine the
bandwidth? (I suppose this is the goal)
There might be data queued on the u
On Tue, Apr 17, 2012 at 12:11 PM, Yonit Halperin wrote:
> If the client's channel has SPICE_COMMON_CAP_QOS_QUERY,
> the server's channel can send SPICE_MSG_QOS_QUERY to the client.
> In response, the client is expected to send back SPICE_MSG_QOS_ACK
> immediately after it receives the message foll
We might want to make it a property, but having an environemnt variable
is useful too, to override behaviour.
---
gtk/channel-playback.c |3 ++-
gtk/channel-record.c |6 --
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/gtk/channel-playback.c b/gtk/channel-playback.c
If the client sends messages that don't fit in the receive_data.buf,
we don't want to assert, but instead disconnect the misbehaving client.
I could reproduce this crash by changing the frame size in the spice-gtk
client, but there might be other conditions where it happened, we
shouldn't crash in
---
server/main_channel.h |4 +--
server/red_worker.c |4 +--
server/reds.c | 68 -
server/snd_worker.c | 40 ++---
4 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/server/main_channel.h
---
server/snd_worker.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/snd_worker.c b/server/snd_worker.c
index 7bdd399..9cf1ebb 100644
--- a/server/snd_worker.c
+++ b/server/snd_worker.c
@@ -478,7 +478,7 @@ static void snd_receive(void* data)
}
- Mensaje original -
> Is that really a burden ? libxml2 exists on pretty much every system
> in the world. Even my TV came with a copy of the Libxml2 README and
> LICENSE :-) virt-viewer / libvirt will already be using it too.
It kinda is sad, none of glib/gtk/spice-gtk uses it, afai
On Wed, Apr 18, 2012 at 11:52:25AM -0400, Marc-André Lureau wrote:
>
>
> - Mensaje original -
> > From: "Daniel P. Berrange"
> >
> > The SPICE URI parser did not cope with URI containing
> > raw IPv6 addresses ie
> >
> >spice://[2001:41c8:1:4fd4::2]/?port=5901
> >
> > This replace
- Mensaje original -
> From: "Daniel P. Berrange"
>
> The SPICE URI parser did not cope with URI containing
> raw IPv6 addresses ie
>
>spice://[2001:41c8:1:4fd4::2]/?port=5901
>
> This replaces the custom written URI parser with code that
> calls out to libxml2's URI APIs which ar
From: "Daniel P. Berrange"
The SPICE URI parser did not cope with URI containing
raw IPv6 addresses ie
spice://[2001:41c8:1:4fd4::2]/?port=5901
This replaces the custom written URI parser with code that
calls out to libxml2's URI APIs which are RFC compliant.
NB, libxml2 will not add/remove
On Wed, Apr 18, 2012 at 08:59:20AM -0500, Aric Stewart wrote:
> Signed-off-by: Aric Stewart
ACK. Pushing.
> ---
> common/ssl_verify.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/common/ssl_verify.c b/common/ssl_verify.c
> index e45d26e..2f34c00 100644
> --- a
Signed-off-by: Aric Stewart
---
common/ssl_verify.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/ssl_verify.c b/common/ssl_verify.c
index e45d26e..2f34c00 100644
--- a/common/ssl_verify.c
+++ b/common/ssl_verify.c
@@ -386,9 +386,9 @@ static int verify_subject(X
On Tue, Apr 17, 2012 at 06:24:18PM -0500, Aric Stewart wrote:
> Note, there may be line-ending issues here is we are not careful. This file
> is a msdos formatted file.
>
I've pushed all your fixes, including a commit to update the
spice-common submodule to include your fixes (create_bitmap and
On Wed, Apr 18, 2012 at 07:30:19AM -0500, Aric Stewart wrote:
> As a test I have found that I can convert the line-endings to linux style
> and Visual Studio 2008 still handles the file without issue. Of course if I
> or a future developer make project changes in VC and then save the project
> it w
As a test I have found that I can convert the line-endings to linux
style and Visual Studio 2008 still handles the file without issue. Of
course if I or a future developer make project changes in VC and then
save the project it will by default covert the line endings back to
MSDOS format.
-ar
I wonder if the process of having to include the patch as text into my
e-mail is what is munging the line endings.
I could check if VC can handle a project file with linux style line
endings and then we could normalize to linux line endings and see if
that helps...
-aric
On 4/18/12 6:17 AM,
On Tue, Apr 17, 2012 at 06:24:18PM -0500, Aric Stewart wrote:
> Note, there may be line-ending issues here is we are not careful. This file
> is a msdos formatted file.
>
> There was some inconsistencies in those line-ending that I have normalized.
Aric, this doesn't apply at all, I get a gazi
Hi,
I'm just starting to work on this, wanted to solicit some feedback. I
am thinking that the simplest way to implement multiple heads would be:
Add additional QXLRam headers back to back on the vram bar.
Add a new flag QXL_RAM_FLAG_MORE_HEADS, set it on all but the last
(largest offset
On Tue, Apr 17, 2012 at 12:49:11PM -0500, Aric Stewart wrote:
> Yeah, i am wondering a bit about this also.
>
> I know under c++ sizeof and empty struct will return 1
> gnu c will return 0
> msvc++ fails.
>
> adding a uint8_t padding member will make it always return 1. I am not sure
> if that i
On Wed, Apr 18, 2012 at 11:38:01AM +0300, Alon Levy wrote:
> On Tue, Apr 17, 2012 at 12:42:45PM +0200, nicolas prochazka wrote:
> > Hello,
> > I'm using qemu 1.0-usbredir from hans git.
> > If i'm starting a windows guest with :
> >
> > /usr/local/bin/qemu -name TEST_QXL010 -readconfig
> > /etc
Hello,
No it's no relative with virtio-serial bug.
With and without virtio driver the problem appear.
( however , the new virtio serial driver from vadim corrects all
windows vm guest's freeze )
In this case (vnc + qxl) , it's not a freeze but a segfault.
Regards,
Nicolas
2012/4/18 Alon Levy :
>
On Tue, Apr 17, 2012 at 12:42:45PM +0200, nicolas prochazka wrote:
> Hello,
> I'm using qemu 1.0-usbredir from hans git.
> If i'm starting a windows guest with :
>
> /usr/local/bin/qemu -name TEST_QXL010 -readconfig
> /etc/ich9-ehci-uhci.cfg -device usb-tablet -spice
> addr=10.98.98.1,port=1195
how can understand qxl device?
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
33 matches
Mail list logo
