Nice catch. ACK.
Marc-André Lureau wrote:
When resizing desktop to best match, the agent fails to update
it's current mode width/height and then incorrectly report
different total_width/total_height than real screen dimensions,
then scaling input incorrectly results in mouse cursor offset.
Seems like the right hack. ACK.
Marc-André Lureau wrote:
Waiting for a Windows event will not last if it is already set.
For example, the client may send clipboard_release() messages
while we are not waiting in on_clipboard_request(), and this will
SetEvent(clipboard_event)
The following
On 05/24/2012 05:59 PM, Hans de Goede wrote:
Hi,
On 05/24/2012 04:40 PM, Uri Lublin wrote:
Out of v1 patch-set, all patches but one (patch 6) got acked.
This patch-set contains a single patch, which is another solution
for strtok_r missing in mingw. It's a simple implementation of
strtok_r.
Hi,
On 05/28/2012 10:29 AM, Uri Lublin wrote:
On 05/24/2012 05:59 PM, Hans de Goede wrote:
Hi,
On 05/24/2012 04:40 PM, Uri Lublin wrote:
Out of v1 patch-set, all patches but one (patch 6) got acked.
This patch-set contains a single patch, which is another solution
for strtok_r missing in
Hi,
On 05/24/2012 04:40 PM, Uri Lublin wrote:
mingw imlpements neigther strtok_r nor strtok_s.
So here is a simple implementation of strtok_r (for windows).
It assumes the delimiter is a single character, which is
good enough for usbredirfilter.
If we're going to do this I would prefer to do
On Fri, May 25, 2012 at 09:23:13AM +0200, Alexander Larsson wrote:
On Mon, 2012-05-07 at 09:28 +0300, Alon Levy wrote:
Hi,
Currently we support multiple monitors by having:
single pci = single display channel = single client window
The RANDR architecture doesn't lend itself to
On 05/28/2012 11:29 AM, Uri Lublin wrote:
On 05/24/2012 05:59 PM, Hans de Goede wrote:
Hi,
On 05/24/2012 04:40 PM, Uri Lublin wrote:
Out of v1 patch-set, all patches but one (patch 6) got acked.
This patch-set contains a single patch, which is another solution
for strtok_r missing in mingw.
Low latency (and relatively low bandwidth) video streaming can be done with
x264 and xvid (low enough for a 3d game to be playable over the net)
However, it introduces licensing issues and high-ish CPU usage on the host
side :(
On Mon, May 28, 2012 at 11:19 AM, Alon Levy al...@redhat.com wrote:
On Mon, May 28, 2012 at 11:29:23AM +0200, Attila Sukosd wrote:
Low latency (and relatively low bandwidth) video streaming can be done with
x264 and xvid (low enough for a 3d game to be playable over the net)
However, it introduces licensing issues and high-ish CPU usage on the host
side :(
Is that todo on anyone’s immediate radar? I'm certainly not qualified,
but it seems like that could have an major impact on what we're trying
to achieve (regular Office applications hosted on a pure Linux server
across a WAN). So perhaps I need to become qualified :-/.
I have a patchset
On Mon, May 28, 2012 at 12:19:57PM +0300, Alon Levy wrote:
On Thu, May 24, 2012 at 01:24:05PM -0500, Jeremy White wrote:
Actually, for WAN, we require ACK for 40 messages, but we allow sending
up to 80, without getting an ack for the first 40.
From my experience with Windows guest, it
On Mon, 2012-05-28 at 12:59 +0300, Alon Levy wrote:
On Mon, May 28, 2012 at 11:29:23AM +0200, Attila Sukosd wrote:
Low latency (and relatively low bandwidth) video streaming can be done with
x264 and xvid (low enough for a 3d game to be playable over the net)
However, it introduces
On Mon, 2012-05-28 at 12:59 +0300, Alon Levy wrote:
On Mon, May 28, 2012 at 11:29:23AM +0200, Attila Sukosd wrote:
Low latency (and relatively low bandwidth) video streaming can be done with
x264 and xvid (low enough for a 3d game to be playable over the net)
However, it introduces
Oh ,I see it now. Thank you!
2012/5/28 Alon Levy al...@redhat.com
On Mon, May 28, 2012 at 07:59:12PM +0800, wangfeng wangfeng wrote:
Hi,
Thank you for your reply.
But what does client reach a full pipe condition refers to? Maybe I
have
something not understand.
Spice server has a
- Original Message -
From: Charles.Tsai-蔡清海-研究發展部 charles.t...@cloudena.com
To: spice-devel@lists.freedesktop.org
Cc: Jonah.Wu-吳君勉-研究發展部 jonah...@cloudena.com
Sent: Monday, May 28, 2012 10:58:19 PM
Subject: [Spice-devel] A sever bug found in 64-bit WIndows 7 VM
Bug
Thank you for your prompt reply. We will double check power option.
Are you saying that VM must turn off power saving mode?
-Original Message-
From: Andrew Cathrow [mailto:acath...@redhat.com]
Sent: Tuesday, May 29, 2012 11:13 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Jonah.Wu-吳君勉-研究發展部;
Hi，
I have encountered the same situation .
2012/5/29 Charles.Tsai-蔡清海-研究�l展部 charles.t...@cloudena.com
Bug description:
A sever bug was found on 64-bit Windows 7 VM which crashed after running
idle for a while(~ 2-3 hours).
When we checked the kvm process, it was killed from
I disabled power saving mode.
Will check if it is the root cause.
I did try to remove qxl driver and the VM could run without crash.
From: wangfeng wangfeng [mailto:wangfeng.v1.1...@gmail.com]
Sent: Tuesday, May 29, 2012 12:07 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-devel@lists.freedesktop.org;
Bug description:
A sever bug was found on 64-bit Windows 7 VM which crashed after running idle
for a while(~ 2-3 hours).
When we checked the kvm process, it was killed from the system.
Drivers installed:
Qxl,
Virtioserail
Vdagent
Qemu Spice:
19 matches
Mail list logo
