I built and tested this with VS2013. That required updating the *.sln file but
the project built and ran fine.
-Sandy
- Original Message -
From: "Christophe Fergeau"
To: spice-de...@freedesktop.org
Sent: Thursday, March 12, 2015 1:01:44 PM
Subject: Re: [Spice-devel] [vdagent-win 0/3] A
Ping!
I've got a few more reviews that I sent out a while ago. I'll forward them
again.
Thanks for your attention.
-S
- Forwarded Message -
From: sstut...@redhat.com
To: sst...@gmail.com
Cc: "Sandy Stutsman"
Sent: Monday, March 9, 2015 1:32:59 PM
Subject: [vd
- Forwarded Message -
From: sstut...@redhat.com
To: spice-devel@lists.freedesktop.org
Cc: "Sandy Stutsman"
Sent: Wednesday, March 11, 2015 1:35:35 PM
Subject: [spice-gtk PATCH] Single headed monitor updates should start at 0,0
From: Sandy Stutsman
For Windows VMs, each
- Forwarded Message -
From: sstut...@redhat.com
To: spice-devel@lists.freedesktop.org
Cc: "Sandy Stutsman"
Sent: Wednesday, March 11, 2015 1:35:34 PM
Subject: [spice-protocol PATCH] Add an escape handler to generate a Spice
Server monitors_config message
From: Sandy Stutsman
- Forwarded Message -
From: sstut...@redhat.com
To: spice-devel@lists.freedesktop.org
Cc: "Sandy Stutsman"
Sent: Wednesday, March 11, 2015 1:35:33 PM
Subject: [qxl-win PATCH 1/2] Add a driver escape to pass monitor positions to
Spice Server
From: Sandy Stutsman
Add an esca
- Forwarded Message -
From: sstut...@redhat.com
To: spice-devel@lists.freedesktop.org
Cc: "Sandy Stutsman"
Sent: Wednesday, March 11, 2015 1:35:33 PM
Subject: [qxl-win PATCH 1/2] Add a driver escape to pass monitor positions to
Spice Server
From: Sandy Stutsman
Add an esca
to normalize
_display_pos which sets the left-most display to 0. This call is required to
keep the mouse coordinates in sync with the client. It is also this call which
can cause the primary display to be non zero.
-S
- Original Message -
From: "Marc-André Lureau"
To: "
the escape, the driver
doesn't have any position information. This results in the spice server sending
monitor_config messages with 0,0 as the position, which the client then sends
back to the guest.
- Original Message -
From: "Marc-André Lureau"
To: "Sandy Stutsma
ot;Marc-André Lureau"
To: "Sandy Stutsman"
Cc: spice-de...@freedesktop.org
Sent: Monday, March 23, 2015 7:55:54 AM
Subject: Re: [Spice-devel] Fwd: [spice-gtk PATCH] Single headed monitor updates
should start at 0, 0
Hi,
On Sat, Mar 21, 2015 at 12:07 AM, Sandy Stutsman wrote:
&g
Locking the individual calls that access the pixmap cache in fill_bits is
not adequately thread safe. Often a windows guest with multiple monitors
will be sending the same image via different threads. Both threads can
be in fill_bits at the same making changes to the cache for the same
image. This
Windows guests with multi-monitors will often send down the same image
via different channels. If these instances are not counted, one channel
can delete an image before all the rest of the channels are finished with
it. In this case, the client will hang.
Addresses bug: https://bugzilla.redhat.c
Hello
- Original Message -
> From: "Marc-André Lureau"
> To: "Sandy Stutsman"
> Cc: spice-devel@lists.freedesktop.org
> Sent: Friday, June 19, 2015 6:58:36 PM
> Subject: Re: [Spice-devel] [spice-gtk PATCH] This adds reference counting to
> cach
al Message -
> From: "Marc-André Lureau"
> To: "Sandy Stutsman"
> Cc: spice-devel@lists.freedesktop.org
> Sent: Monday, June 22, 2015 11:27:26 AM
> Subject: Re: [Spice-devel] [spice-gtk PATCH] This adds reference counting to
> cached images.
>
>
&
Missing useful information.
---
xddm/display/res.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xddm/display/res.c b/xddm/display/res.c
index bfb3571..84f9756 100644
--- a/xddm/display/res.c
+++ b/xddm/display/res.c
@@ -2005,7 +2005,7 @@ static BOOL CacheSizeTest(PDev *pdev,
---
xddm/miniport/qxl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xddm/miniport/qxl.c b/xddm/miniport/qxl.c
index f5d6b48..85e4fcf 100644
--- a/xddm/miniport/qxl.c
+++ b/xddm/miniport/qxl.c
@@ -1261,7 +1261,7 @@ BOOLEAN StartIO(PVOID dev_extension,
PVIDEO_REQUEST_PACKET p
Add missing information
---
%u is better than %d !
---
xddm/display/res.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xddm/display/res.c b/xddm/display/res.c
index bfb3571..6864e51 100644
--- a/xddm/display/res.c
+++ b/xddm/display/res.c
@@ -2005,7 +2005,7 @@ static BOOL Ca
Locking the individual calls that access the pixmap cache in fill_bits is
not adequately thread safe. Often a windows guest with multiple monitors
will be sending the same image via different threads. Both threads can
be in fill_bits at the same making changes to the cache for the same
image. This
Locking the individual calls that access the pixmap cache in fill_bits is
not adequately thread safe. Often a windows guest with multiple monitors
will be sending the same image via different threads. Both threads can
be in fill_bits at the same making changes to the cache for the same
image. This
Locking the individual calls that access the pixmap cache in fill_bits is
not adequately thread safe. Often a windows guest with multiple monitors
will be sending the same image via different threads. Both threads can
be in fill_bits at the same making changes to the cache for the same
image. This
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1202419
A monitors_config message needs to be sent from the guest to the client
when monitors are ordered with the "Set Resolution" applet.
---
I think it is best to keep the Windows driver escape structures together
in the qxl_windows.h fil
When a Windows guest uses the "Set Resolution" applet to change
resolutions and/or monitor positions, this escape sends the new monitor
configurations to the client via a new QXL driver escape.
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1202419
---
Change from v1:
* Add call to update
Sorry for the duplicate. I was getting a bogus "mail not sent" message.
-S
- Original Message -
> From: "Sandy Stutsman"
> To: spice-devel@lists.freedesktop.org
> Sent: Monday, June 22, 2015 5:44:28 PM
> Subject: [Spice-devel] [spice PATCH] Lock th
Hm. I've been using tortoisegit on my windows machine. I'll look into it.
-S
- Original Message -
> From: "Christophe Fergeau"
> To: "Sandy Stutsman"
> Cc: spice-devel@lists.freedesktop.org
> Sent: Tuesday, June 23, 2015 5:20:09 AM
> Subj
Locking the individual calls that access the pixmap cache in fill_bits is
not adequately thread safe. Often a windows guest with multiple monitors
will be sending the same image via different threads. Both threads can
be in fill_bits at the same making changes to the cache for the same
image. Th
Windows guests with multi-monitors will often send down the same image
via different channels. If these instances are not counted, one channel
can delete an image before all the rest of the channels are finished with
it. In this case, the client will hang.
This can happen, for instance, when th
Provides correct monitor locations when specified via the guest
"Screen Resolution" applet.
Addresses:https://bugzilla.redhat.com/show_bug.cgi?id=1202419
---
Changes from v1 and v2
Remove misc typo fixes
Reuse existing QXLHead structure instead driver specific escape structure
---
xddm/displa
New escape for sending monitor position information from guest to client
---
Changes since v2:
Remove specific escape structure in favor of using QXL_HEAD
---
spice/qxl_windows.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/spice/qxl_windows.h b/spice/qxl_windows.h
index d1df684..bc2ceff
When a Windows guest uses the "Set Resolution" applet to change
resolutions and/or monitor positions, this escape sends the new monitor
configurations to the client via a new QXL driver escape.
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1202419
---
Changes for v2
Removed call to se
Each monitor on a Windows guest is represented as a separate, single-headed
device with its own framebuffer. When there are multiple monitors, all
monitors but one will have a non-zero xy config position. But even in
these cases the whole area (frame-buffer) of each monitor should be
updated.
A
Hi.
- Original Message -
> From: "Fabiano Fidêncio"
> To: "Sandy Stutsman"
> Cc: spice-devel@lists.freedesktop.org
> Sent: Thursday, June 25, 2015 6:50:11 AM
> Subject: Re: [Spice-devel] [spice-gtk PATCH v2] This adds reference counting
> to cache
Hello
- Original Message -
> From: "Marc-André Lureau"
> To: "Sandy Stutsman"
> Cc: spice-devel@lists.freedesktop.org
> Sent: Thursday, June 25, 2015 7:12:33 AM
> Subject: Re: [Spice-devel] [spice-gtk PATCH] Handle single headed monitors
> th
Locking the individual calls that access the pixmap cache in fill_bits is
not adequately thread safe. Often a windows guest with multiple monitors
will be sending the same image via different threads. Both threads can
be in fill_bits at the same time making changes to the cache for the same
image
t mean it isn't happening. I'm not sure what
would happen other than some (transient ?) rendering artifacts.
-S
On 6/26/2015 9:14 AM, Christophe Fergeau wrote:
> Hey,
>
> On Tue, Jun 23, 2015 at 05:47:14PM -0400, Sandy Stutsman wrote:
>> Locking the individual calls that access
Works for me.
- Original Message -
> From: "Christophe Fergeau"
> To: "Sandy Stutsman"
> Cc: spice-devel@lists.freedesktop.org
> Sent: Monday, June 29, 2015 8:56:18 AM
> Subject: Re: [Spice-devel] [vd_agent PATCH V3] Add monitors_config driver
> e
Windows guests with multi-monitors will often send down the same image
via different channels. If these instances are not counted, one channel
can delete an image before all the rest of the channels are finished with
it. In this case, the client will hang.
This can happen, for instance, when the
Hi All.
On 6/25/2015 10:58 AM, Sandy Stutsman wrote:
> Hello
>
> - Original Message -
>> From: "Marc-André Lureau"
>> To: "Sandy Stutsman"
>> Cc: spice-devel@lists.freedesktop.org
>> Sent: Thursday, June 25, 2015 7:12:33 AM
>>
Hi Again.
On 7/17/2015 5:43 AM, Victor Toso wrote:
> Hi,
>
> On Thu, Jul 09, 2015 at 10:29:14AM -0400, Sandy Stutsman wrote:
>> Hi All.
>>
>> On 6/25/2015 10:58 AM, Sandy Stutsman wrote:
>>> Hello
>>>
>>> - Original Message -
&g
Add capability to allow Windows guests to determine if the client
supports a monitors_config message from a multi-monitor guest that is not
multi-hat.
This addresses RHBZ#1248189
---
src/channel-main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/channel-main.c b/src/channel-main.c
i
Add capability to allow Windows guests to determine if the client
supports a monitors_config message from a multi-monitor guest that is not
multi-hat.
This addresses RHBZ#1248189
--
This one should be formatted correctly
---
src/channel-main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a
Updated clients will set this capability allowing windows guest to issue
MONITORS_CONFIG messages to the client.
Addresses: rhbz#1248189 and rhbz#1248196
---
spice/vd_agent.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/spice/vd_agent.h b/spice/vd_agent.h
index edc31ca..445
If the client hasn't been updated to handle non multi-hat monitors_config,
vd_agent will won't issue the MONITORS_CONFIG driver escape.
This addresses: rhbz#1248196
---
vdagent/desktop_layout.cpp | 4
vdagent/desktop_layout.h | 5 +++--
vdagent/vdagent.cpp| 4
3 files changed,
Opps. Forgot to use the external editor on this.
Please disregard. Better one on the way.
-S
On 7/29/2015 5:12 PM, Sandy Stutsman wrote:
> Add capability to allow Windows guests to determine if the client
> supports a monitors_config message from a multi-monitor guest that is not
>
If the client hasn't been updated to handle multi-monitor configurations
that are not multi-hat, vd_agent won't issue the MONITORS_CONFIG driver
escape.
These changes will insure that the new MONITORS_CONFIG escape in commit:
6023630562fd129433aef1eaddcf6fbee3f03e50 will not break with an older
cl
This indicates the client's ability to handle multi-monitor
configurations that are not multi-hat.
This commit addresses:
https://bugzilla.redhat.com/show_bug.cgi?id=1248196
https://bugzilla.redhat.com/show_bug.cgi?id=1248189
---
Changed from V1: removed reference to local commit
---
spice/vd_age
This will allow Windows guests to determine if the client supports a
monitors_config message from a multi-monitor guest that is not
multi-hat.
It keeps commit:8b0cd321d5a4d08ccba5845c5f2206e6f8032c1d
from breaking if an updated win-qxl driver is paired with an older client.
This resolves: https:/
This will allow Windows guests to determine if the client supports a
monitors_config message from a multi-monitor guest that is not
multi-hat.
It keeps commit:8b0cd321d5a4d08ccba5845c5f2206e6f8032c1d
from breaking if an updated win-qxl driver is paired with an older client.
This resolves: https:/
The distinction is between multi-hat where a single instance of the graphics
driver handles multiple monitors and, say, the windows driver where there is a
separate driver instance for each monitor.
- Original Message -
> From: "Marc-André Lureau"
> To: "Sandy S
A change to spice-protocol adds spice/macros.h to the QXL driver build,
causing some macros to be redefined. The resulting compiler warnings
break the build. Adding undef statements before the actual macro
definitions fixes the warnings.
---
xddm/display/quic.c | 1 +
xddm/display/utils.h | 9 +
Only one or two of the macro's are causing the warnings right but if
spice/macros.h should add/remove macros, this would break the build again.
- Original Message -
> From: "Marc-André Lureau"
> To: "Sandy Stutsman"
> Cc: spice-devel@lists.freedeskto
This will allow Windows guests to determine if the client supports a
monitors_config message from a multi-monitor guest that is not
multi-headed, i.e., that has one monitor per driver.
It keeps commit:8b0cd321d5a4d08ccba5845c5f2206e6f8032c1d
from breaking if an updated win-qxl driver is paired wi
A change to spice-procotol adds spice/macros.h to the qxl build. This
causes a few macros to be redefined, resulting in warnings that break the
build.
Explicitly including the spice/macros.h file in place of the
redundant macros fixes the warnings.
---
xddm/display/quic.c | 2 --
xddm/display/
Modes are returned in a buffer from qemu with IDs in increasing but not
necessarily consecutive order. (Some modes may be omitted if they don't fit
into the framebuffer.) Two custom modes are appended to the local buffer to
support arbitrary resolutions. The first custom id must be set to +1 of th
Hey.
On 9/17/2015 11:06 AM, Uri Lublin wrote:
> On 09/17/2015 02:40 PM, Christophe Fergeau wrote:
>> On Wed, Sep 16, 2015 at 03:27:49PM -0400, Sandy Stutsman wrote:
>>> Modes are returned in a buffer from qemu with IDs in increasing but not
>>> necessarily consecutiv
It compiles and and is functionally the same as the prior versions, but cleaner.
-S
On 9/22/2015 5:08 AM, Christophe Fergeau wrote:
> I see this has been pushed now, but I'd still go with this follow-up
> patch (not even compile tested :-(
>
> From c148234cb8eb0b64dcff27c3c16df4f27cf79ba9 Mon Sep
54 matches
Mail list logo
