Mike Hinz wrote:
On Sun, 2011-10-02 at 14:03 -0500, Mike Hinz wrote:
On Sun, 2011-10-02 at 11:01 +0200, Arnon Gilboa wrote:
Hi Mike,
Can you please:
1. net stop vdservice
2. delete vdservice.log & vdagent.log from %windir%\temp
3. net start vdservice
4. copy a text in the guest, paste i
Can connect a linux client (spicy) with Virtualized Windows / Linux to
a office printer?
We have developping a infraestructure with SPICE where the clients are
very far from CPD.
Maybe with a CUPS remote can be posible, although I ask for a usbredir
or similar.
--
Antonio Pérez-Aranda Alcaide
ap
On Sun, 2011-10-02 at 14:03 -0500, Mike Hinz wrote:
> On Sun, 2011-10-02 at 11:01 +0200, Arnon Gilboa wrote:
> > Hi Mike,
> > Can you please:
> > 1. net stop vdservice
> > 2. delete vdservice.log & vdagent.log from %windir%\temp
> > 3. net start vdservice
> > 4. copy a text in the guest, paste in
Ack series
On 10/05/2011 03:17 PM, Christophe Fergeau wrote:
---
client/x11/platform.cpp | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/client/x11/platform.cpp b/client/x11/platform.cpp
index 670912c..f7f72cd 100644
--- a/client/x11/platform.cpp
+++ b/cl
XMonitor::do_restore (called for example when going out of
fullscreen) restore the screen resolution to its previous state,
but it doesn't take care of repositioning the screen to their
previous position, which is one of the advantages of using randr
1.2.
Since MultyMonScreen::restore handles all o
MultyMonScreen::restore changes the X11 Screen resolution, but it
doesn't use MultyMonScreen::set_size. This means
MultyMonScreen::_width and MultyMonScreen::_height don't get
updated to reflect the new resolution settings, which could cause
issues later on. Until now this was safe since the only c
---
client/x11/platform.cpp | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/client/x11/platform.cpp b/client/x11/platform.cpp
index 670912c..f7f72cd 100644
--- a/client/x11/platform.cpp
+++ b/client/x11/platform.cpp
@@ -1147,8 +1147,8 @@ protected:
private:
Hi
- Original Message -
> I) doesn't benefit it. Thread pools for long CPU tasks however are
^^ I meant IO.
Btw, it was also very easy to turn a traditional blocking code into a coroutine
code. I didn't have to think about what needs locks etc.. It was basically the
same code, but imp
Hi
- Original Message -
>
> Hi,
> With spicec, on client side, each channel is a different thread. I
> know that with the new client this is not true. I would like to know
> how spice-gtk handles the different channels.
Spice-Gtk uses coroutines for all IO. This makes writing async code
Hi,
With spicec, on client side, each channel is a different thread. I know that
with the new client this is not true. I would like to know how spice-gtk
handles the different channels.
Thanks.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.o
Hi,
Thanks for the review!
On 10/05/2011 12:03 AM, Marc-André Lureau wrote:
+static void spice_gtk_session_init(SpiceGtkSession *gtk_session)
+{
+SpiceGtkSessionPrivate *s;
+
+SPICE_DEBUG("New gtk session (compiled from package " PACKAGE_STRING ")");
Well we already have version in
11 matches
Mail list logo