Hey,
On Mon, Aug 29, 2016 at 03:47:44PM +0300, Yedidyah Bar David wrote:
> From: Lev Veyde
>
> This is done, so that the version will be easily visible in the
> oVirt Manager under the Applications, because the oVirt Guest Agent
> returns only Display Names, but not the versions.
Seems fairly c
>
> This patch updates the display configurations only when needed.
> Currently vdagent updates the display configurations almost on every
> "VD_AGENT_MONITORS_CONFIG" request, this approach is redundant as some
> "VD_AGENT_MONITORS_CONFIG" requests don't apply any change to the
> display configur
>
> Don't touch the rcc struct directly. Improve encapsulation to help
> prepare for separating RedChannelClient to a separate file.
> ---
> Changes since v1:
> - changed a couple more cases where the stream was accessed directly
>
> server/dcc.c | 4 ++--
> server/spicevmc.c | 2 +-
> 2 f
>
> More preparation for separating RedChannelClient into a separate file.
> Rename function slightly for improved readability:
> red_channel_client_blocked() -> red_channel_client_is_blocked()
> ---
> server/red-channel.c | 14 +++---
> server/red-channel.h | 2 +-
> 2 files changed, 8
>
> Encapsulate the structure a bit more and avoid poking into it from other
> class implementations. Getting ready to split RedChannelClient out to a
> separate file.
> ---
> server/red-channel.c | 12 +++-
> server/red-channel.h | 2 ++
> server/spicevmc.c| 2 +-
> 3 files changed
>
> Don't poke into the structure to get the channel
>
> This prepares for encapsulating RedChannelClient a bit more and
> separating it into its own source file.
> ---
> server/cursor-channel.c| 4 ++--
> server/dcc-send.c | 10 +
> server/dcc.c |
>
> Instead of having all other classes poke into the RedChannelClient
> struct to get the RedClient associated with the channel client, call the
> accessor function. This commit allows us to encapsulate RedChannelClient
> and move it to its own file soon.
> ---
> server/dcc.c |
Don't touch the rcc struct directly. Improve encapsulation to help
prepare for separating RedChannelClient to a separate file.
---
Changes since v1:
- changed a couple more cases where the stream was accessed directly
server/dcc.c | 4 ++--
server/spicevmc.c | 2 +-
2 files changed, 3 inser
Shouldn't this be merged with patch 14 somehow as it is introducing
these #ifdef USE_FRAMEBUFFER in the first place?
Christophe
On Tue, Aug 09, 2016 at 06:31:06PM +0300, Sameeh Jubran wrote:
> From: Dmitry Fleytman
>
> Framebuffer should only be used in VGA mode,
> however the mode is only know
Hey,
For what it's worth, these 2 attached patches allow to compile on el6
(at least few weeks ago, did not try again just now).
Christophe
On Thu, Aug 18, 2016 at 06:38:12PM +0200, Francois Gouget wrote:
>
> The commit below causes compilation errors on RHEL 6.8 :-(
> (gcc 4.4.7)
>
> CC
Instead of having all other classes poke into the RedChannelClient
struct to get the RedClient associated with the channel client, call the
accessor function. This commit allows us to encapsulate RedChannelClient
and move it to its own file soon.
---
server/dcc.c | 9 +
se
Don't touch the rcc struct directly. Improve encapsulation to help
prepare for separating RedChannelClient to a separate file.
---
server/spicevmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/spicevmc.c b/server/spicevmc.c
index 4e9dd0d..c79e7bb 100644
--- a/server/
Don't poke into the structure to get the channel
This prepares for encapsulating RedChannelClient a bit more and
separating it into its own source file.
---
server/cursor-channel.c| 4 ++--
server/dcc-send.c | 10 +
server/dcc.c | 4 ++--
server/dc
More preparation for separating RedChannelClient into a separate file.
Rename function slightly for improved readability:
red_channel_client_blocked() -> red_channel_client_is_blocked()
---
server/red-channel.c | 14 +++---
server/red-channel.h | 2 +-
2 files changed, 8 insertions(+), 8
Since the previous patchset included a bunch of large changes that were hard to
review, I'm sending out a few smaller cleanup patches prior to moving
RedChannelClient to its own separate file. Hopefully these should make
following patches smaller and easier to review. More cleanups will probably
co
Encapsulate the structure a bit more and avoid poking into it from other
class implementations. Getting ready to split RedChannelClient out to a
separate file.
---
server/red-channel.c | 12 +++-
server/red-channel.h | 2 ++
server/spicevmc.c| 2 +-
3 files changed, 14 insertions(+),
>
> Signed-off-by: Sameeh Jubran
> Signed-off-by: Dmitry Fleytman
> ---
> qxldod/QxlDod.h | 2 +-
> qxldod/driver.cpp | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/qxldod/QxlDod.h b/qxldod/QxlDod.h
> index 9bc0bdb..19d172f 100755
> --- a/qxldod/QxlDod.h
> +++ b/
>
> From: Sandy Stutsman
>
> ---
> qxldod/QxlDod.cpp | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
> index 3139092..74cd259 100755
> --- a/qxldod/QxlDod.cpp
> +++ b/qxldod/QxlDod.cpp
> @@ -4488,11 +4488,10 @@ NTSTATUS
> QxlD
>
> From: Sandy Stutsman
>
> ---
> qxldod/QxlDod.cpp | 52 ++--
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
> index a328d2d..e6c4ada 100755
> --- a/qxldod/QxlDod.cpp
> +++ b/qxldod/Qx
>
> From: Sandy Stutsman
>
> Implement the escapes for the qxl driver and add some debug output for
> multiple monitor support
> ---
> qxldod/QxlDod.cpp| 162
> ++-
> qxldod/QxlDod.h | 11 ++-
> qxldod/include/qxl_windows.h |
This patch updates the display configurations only when needed.
Currently vdagent updates the display configurations almost on every
"VD_AGENT_MONITORS_CONFIG" request, this approach is redundant as some
"VD_AGENT_MONITORS_CONFIG" requests don't apply any change to the
display configurations.
A go
Differences from previous version:
* Fixed a bug where virt-manager keeps flickering every second
when one monitor on and the other is off.
Sameeh Jubran (1):
Update the displays only when needed
vdagent/vdagent.cpp | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
--
That's true, I'll fix it thanks :)
On Tue, Aug 30, 2016 at 3:38 PM, Frediano Ziglio wrote:
> >
> > This patch updates the display configurations only when needed.
> > Currently vdagent updates the display configurations almost on every
> > "VD_AGENT_MONITORS_CONFIG" request, this approach is red
>
> From: Sandy Stutsman
>
> This interrupt is used for asynchronous present calls.
Could you split this? It's not clear the rationale of this.
> Fixed the interrupt mask to reflect currently used interrupts.
> ---
> qxldod/QxlDod.cpp | 22 +++---
> 1 file changed, 11 insertio
>
> From: Sandy Stutsman
>
> ---
> qxldod/QxlDod.cpp | 66
> ---
> 1 file changed, 34 insertions(+), 32 deletions(-)
>
> diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
> index ec960e5..9d13934 100755
> --- a/qxldod/QxlDod.cpp
> +++ b/qxl
Hi
- Original Message -
> >
> > Hi
> >
> > - Original Message -
> > > Hi
> > >
> > > - Original Message -
> > > > >
> > > > > From: Marc-André Lureau
> > > > >
> > > > > There is no strong need for keypress-delay on local connection (not
> > > > > verified: unless the
>
> The buffers and buffer sizes should be initialized and allocated. This
> patch fixes a possible case where vdagent can get stuck, as the
> function _pfnQueryDisplayConfig can return ERROR_INVALID_PARAMETER
> if the buffers aren't intialized.
> The call to free_config_buffers is superfluous bec
>
> Hi
>
> - Original Message -
> > Hi
> >
> > - Original Message -
> > > >
> > > > From: Marc-André Lureau
> > > >
> > > > There is no strong need for keypress-delay on local connection (not
> > > > verified: unless the system is heavily loaded, in which case the VM
> > > > w
The buffers and buffer sizes should be initialized and allocated. This
patch fixes a possible case where vdagent can get stuck, as the
function _pfnQueryDisplayConfig can return ERROR_INVALID_PARAMETER
if the buffers aren't intialized.
The call to free_config_buffers is superfluous because it is ca
>
> This patch updates the display configurations only when needed.
> Currently vdagent updates the display configurations almost on every
> "VD_AGENT_MONITORS_CONFIG" request, this approach is redundant as some
> "VD_AGENT_MONITORS_CONFIG" requests don't apply any change to the
> display configur
>
> The buffers and buffer sizes should be initialized and allocated. This
> patch fixies a possible case where vdagent can get stuck, as the
fixes
> function _pfnQueryDisplayConfig can return ERROR_INVALID_PARAMETER
> if the buffers aren't intialized.
> The call to free_config_buffers is superf
On Tue, Aug 30, 2016 at 11:45:06AM +, Marc-André Lureau wrote:
> Hi
>
> On Tue, Aug 30, 2016 at 3:24 PM Christophe Fergeau
> wrote:
>
> > Another option would be to ship pkg.m4 from pkg-config 0.29 in
> > spice-gtk/m4/, though I don't understand how AC_SUBST was made unneeded,
> > so maybe t
> On Thu, Aug 18, 2016 at 6:48 PM, Frediano Ziglio < fzig...@redhat.com >
> wrote:
> > >
>
> > > The Direct3D 9 API operates on either the Windows XP display driver
>
> > > model (XPDM) or the Windows Vista display driver model (WDDM), depending
>
> > > on the operating system installed.
>
> >
Can anyone review the rest of the patches? (8 - 26)
On Wed, Aug 24, 2016 at 4:22 PM, Sameeh Jubran wrote:
> Can you please review the rest of the patches so I can send v2?
>
> On Tue, Aug 9, 2016 at 6:28 PM, Sameeh Jubran wrote:
>
>> This series contains the latest patches to support Windows 10
The buffers and buffer sizes should be initialized and allocated. This
patch fixies a possible case where vdagent can get stuck, as the
function _pfnQueryDisplayConfig can return ERROR_INVALID_PARAMETER
if the buffers aren't intialized.
The call to free_config_buffers is superfluous becuase it is c
This patch saves unncessary calls to set_displays, which updates the
display configurations. This patch enhance user experience as
updating the display configurations causes the screen to blackout
temporarily.
Tested on both Windows 10 and Wdindows XP.
Sameeh Jubran (1):
Update the displays onl
This patch updates the display configurations only when needed.
Currently vdagent updates the display configurations almost on every
"VD_AGENT_MONITORS_CONFIG" request, this approach is redundant as some
"VD_AGENT_MONITORS_CONFIG" requests don't apply any change to the
display configurations.
A go
Hi
On Tue, Aug 30, 2016 at 3:24 PM Christophe Fergeau
wrote:
> Another option would be to ship pkg.m4 from pkg-config 0.29 in
> spice-gtk/m4/, though I don't understand how AC_SUBST was made unneeded,
> so maybe that's not enough (?)
>
m4 should be enough, however it seems that AC_SUBST of _CFL
On Tue, Aug 30, 2016 at 07:25:37AM -0400, Marc-André Lureau wrote:
> Imho, it's acceptable if it's has a programmer environment issue.
We'll have to disagree here ;)
> And 0.29 is almost a year old.
This is not really relevant. 0.29 was first available in Fedora 24 and
Ubuntu 16.04. Which are b
Hi
- Original Message -
> On Tue, Aug 30, 2016 at 07:01:48AM -0400, Marc-André Lureau wrote:
> > Hi
> >
> > - Original Message -
> > > On Fri, Aug 19, 2016 at 09:35:09PM +0400, marcandre.lur...@redhat.com
> > > wrote:
> > > > From: Marc-André Lureau
> > > >
> > > > So we can dro
Another option would be to ship pkg.m4 from pkg-config 0.29 in
spice-gtk/m4/, though I don't understand how AC_SUBST was made unneeded,
so maybe that's not enough (?)
Christophe
On Tue, Aug 30, 2016 at 12:52:43PM +0200, Christophe Fergeau wrote:
> On Fri, Aug 19, 2016 at 09:35:09PM +0400, marcand
On Tue, Aug 30, 2016 at 07:01:48AM -0400, Marc-André Lureau wrote:
> Hi
>
> - Original Message -
> > On Fri, Aug 19, 2016 at 09:35:09PM +0400, marcandre.lur...@redhat.com wrote:
> > > From: Marc-André Lureau
> > >
> > > So we can drop the AC_SUBST for _CFLAGS & _LIBS variable (since 0.24
Hi
- Original Message -
> On Fri, Aug 19, 2016 at 09:35:09PM +0400, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau
> >
> > So we can drop the AC_SUBST for _CFLAGS & _LIBS variable (since 0.24
> > but there is no clean way to check that before PKG_PREREQ in 0.29,
> > relea
On Fri, Aug 19, 2016 at 09:35:09PM +0400, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> So we can drop the AC_SUBST for _CFLAGS & _LIBS variable (since 0.24
> but there is no clean way to check that before PKG_PREREQ in 0.29,
> released last year)
>
> Signed-off-by: Marc-André
On 2016年08月29日 19:08, Marc-André Lureau wrote:
Hi
- Original Message -
On 2016年08月29日 17:03, Marc-André Lureau wrote:
hi
- Original Message -
Hi all,
I tried to use virtio-gpu to do some test, the glmark2 works, but when I
ran heaven benchmark in Guest,
the application c
GTK on its own is not enough to ensure libX11 is properly linked with
libspice-client-gtk. This patch adds X11_LIBS to SPICE_GTK_LIBADD_COMMON
(and X11_CFLAGS to a relevant section as well) in src/Makefile.am, and
performs an approriate pkg-config based check to determine the correct
values in con
-- 转发的邮件 --
发件人："Kop Yiddish"
日期：2016年8月25日 21:20
主题：Question from a chinese programmer
收件人：
抄送：
hi, sir,
How are you?
I'm a programmer from china ,i have some questions about your patchwork in
SPICE project. May I make bold to disturb you for some minitues ?
I recently encounter
Hi
- Original Message -
> Hi
>
> - Original Message -
> > >
> > > From: Marc-André Lureau
> > >
> > > There is no strong need for keypress-delay on local connection (not
> > > verified: unless the system is heavily loaded, in which case the VM will
> > > probably be stuck too a
Hi
- Original Message -
> >
> > From: Marc-André Lureau
> >
> > There is no strong need for keypress-delay on local connection (not
> > verified: unless the system is heavily loaded, in which case the VM will
> > probably be stuck too and may or not repeat the key when running).
> >
>
>
> From: Marc-André Lureau
>
> Channel users (such as spice widget) may want to know some connection
> details. Instead of exposing various connection properties, we may as
> well just have a GSocket property, with a strong warning on usage.
>
Could be quite dangerous to expose it (well, that
>
> From: Marc-André Lureau
>
> There is no strong need for keypress-delay on local connection (not
> verified: unless the system is heavily loaded, in which case the VM will
> probably be stuck too and may or not repeat the key when running).
>
> The benefit of removing keypress-delay is that
51 matches
Mail list logo
