On Fri, Jul 26 2013, Christophe Fergeau wrote:
> And this was working before the installation of the guest drivers? I'm
> surprised these interact with -usb.
Hi Christophe,
Yes.
> I'd check in the device manager if drivers for the various virtio* devices
> are still there, and remove them by h
---
display/brush.c | 4 +++-
display/driver.c | 2 ++
display/pointer.c | 8
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/display/brush.c b/display/brush.c
index 0b9400d..fe94f1c 100644
--- a/display/brush.c
+++ b/display/brush.c
@@ -235,10 +235,12 @@ BOOL APIENTRY D
When we want to disconnect the main channel from a callback, it is
safer to use red_channel_client_shutdown, instead of directly
destroying the client. It is also more consistent with how other
channels treat errors.
red_channel_client_shutdown will trigger socket error in the main channel.
Then, m
Fixes rhbz#918169
Some channels make direct calls to reds/main_channel routines. If
these routines try to read/write to the socket, and they get socket
error, main_channel_client_on_disconnect is called, and triggers
red_client_destroy. In order to prevent accessing expired references
to RedClient
---
server/red_channel.c | 9 ++---
server/snd_worker.c | 7 ---
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 9b5e314..89b4092 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -1109,6 +1109,7 @@ static voi
The snd channels has one reference as long as their socket is active.
The playback channel has an additional reference for each frame that is
currently filled by the sound device.
Once the channel is disconnected (the socket has been freed and the
first reference is released) snd_disconnect_channel
When the sequence of calls bellow occurs, the PlaybackChannel
is not released (snd_channel_put is not called for the
samples that refer to the channel).
spice_server_playback_get_buffer
snd_channel_disconnect
spice_server_playback_put_samples
---
server/snd_worker.c | 9 -
1 f
---
server/main_dispatcher.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/server/main_dispatcher.c b/server/main_dispatcher.c
index e7a451a..bf160dd 100644
--- a/server/main_dispatcher.c
+++ b/server/main_dispatcher.c
@@ -97,6 +97,7 @@ static void main_dispatcher_handl
---
server/red_channel.c | 23 ---
server/red_channel.h | 17 +++--
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index a35da9b..9b5e314 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -19
Fixes: leaks of pipe items & "red_client_destroy: assertion
`rcc->send_data.size == 0'"
red_channel_disconnect clears the pipe. It is called only once. After,
it was called, not items should be added to the pipe.
An example of when this assert can occur:
on_new_cursor_channel (red_worker.c), pus
> > >I guess gio/gvfs should be able to
> > > fetch files from http[s] (no libcurl please ;). Is it what you
> > >(Dietmar) are looking for?
> >
> > Why gvfs? libcurl look much simpler.
>
> libcurl would look a bit alien in the rest of the code base, and if we ever
> want to do the download async
On Wed, Jul 17, 2013 at 11:53:25AM -0700, Marc-André Lureau wrote:
> commit fc1de85b499759576fa52dfd20496bfb887c8295
> Author: Marc-Andr?? Lureau
> Date: Wed Jul 17 20:49:01 2013 +0200
>
> Fix wrong size_t printf format
>
> vdagent/desktop_layout.cpp:121:763: warning: format '%u' e
On Fri, Jul 26, 2013 at 08:38:36AM -0400, Marc-André Lureau wrote:
>
>
> - Mensaje original -
> > Hey,
> >
> > These patches do not seem to have been sent to spice-devel@ before commit?
>
>
> They are build fixes, or trivial runtime fixes
Do we have a 'trivial rule' policy for commits
- Mensaje original -
>
>
> - Mensaje original -
> > Hey,
> >
> > These patches do not seem to have been sent to spice-devel@ before commit?
>
>
> They are build fixes, or trivial runtime fixes (unlike the feature
> implementation that was committed before without review)
My
- Mensaje original -
> Hey,
>
> These patches do not seem to have been sent to spice-devel@ before commit?
They are build fixes, or trivial runtime fixes (unlike the feature
implementation that was committed before without review)
Feel free to review/fix the commits now.
Hey,
These patches do not seem to have been sent to spice-devel@ before commit?
Christophe
On Wed, Jul 17, 2013 at 11:53:25AM -0700, Marc-André Lureau wrote:
> spice-protocol |2 -
> vdagent/desktop_layout.cpp |4 +--
> vdagent/display_setting.cpp |2 -
> vdagent/file_
On Fri, Jul 26, 2013 at 11:26:24AM +, Dietmar Maurer wrote:
> > In my opinion, we could support running 'remote-viewer
> > https://proxmox.example.com/myvm.vv',
>
> Well, but we need to handle basic auth.
Couldn't an auth dialog be popped up when needed?
>
> >I guess gio/gvfs should be abl
On Fri, Jul 26, 2013 at 11:26:24AM +, Dietmar Maurer wrote:
> > In my opinion, we could support running 'remote-viewer
> > https://proxmox.example.com/myvm.vv',
>
> Well, but we need to handle basic auth.
>
> >I guess gio/gvfs should be able to
> > fetch files from http[s] (no libcurl please
> In my opinion, we could support running 'remote-viewer
> https://proxmox.example.com/myvm.vv',
Well, but we need to handle basic auth.
>I guess gio/gvfs should be able to
> fetch files from http[s] (no libcurl please ;). Is it what you (Dietmar) are
> looking for?
Why gvfs? libcurl look much
Hey,
On Thu, Jul 18, 2013 at 12:15:10PM +0200, Peter Münster wrote:
> I've installed spice-guest-tools
> (http://spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-0.59.exe)
> on my Win-XP guest (qemu running on GNU/Linux). But unfortunately USB is
> no more working: whenever I s
On Thu, Jul 25, 2013 at 06:56:20AM -0400, Marc-André Lureau wrote:
> > Sure. Then I have to maintain/install a script and remote-viewer, and I want
> > to avoid that.
> >
> > Why is the ovirt code included? I guess it is just convenient.
>
> I haven't used the ovirt support, but my impression wa
21 matches
Mail list logo
