>
> Hello Eric,
>
> > A new command may be okay, however,
>
> thanks, I've fix the typos and updated the patch to use an Enum, which
> indeed makes more sense.
>
> I've also updated "spice-query" command to provide the current value
> of the "video-codec" property,
> but it made me wonder if I
The G_PID_FORMAT constant is defined only if GLib does not support it.
The constant was wrongly defined.
Jessie Debian 32 shows this issue (printf format error).
Signed-off-by: Frediano Ziglio
---
server/tests/test-glib-compat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
ping
>
> Instead of having to manually register the file descriptor and
> than need to call dispatcher_handle_recv_read just provide a single
> API to create the watch.
> This has some advantage:
> - replace 2 API with 1;
> - code reuse for handling the event (removed 2 functions);
> - avoid the
ping
>
> The function is called only by red_channel_pipes_new_add.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/red-channel.c | 20
> 1 file changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/server/red-channel.c b/server/red-channel.c
> index 82e522395..4872
ping
>
> ping
>
> >
> > In some configuration _GNU_SOURCE is defined by the compiler
> > and defining again cause a warning.
> > Do not define again to avoid the warning.
> >
> > Signed-off-by: Frediano Ziglio
> > ---
> > server/red-worker.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
>
ping
>
> The 2 callers red_char_device_send_to_client_tokens_set and
> red_char_device_send_to_client_tokens_add are doing mostly
> the same thing so put common code to
> red_char_device_send_to_client_tokens_absorb.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/char-device.c | 42
ping
>
> Just a style change, return earlier to avoid some indentation.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/red-channel-client.c | 37 +++--
> 1 file changed, 15 insertions(+), 22 deletions(-)
>
> diff --git a/server/red-channel-client.c b/server/
ping
>
> ping
>
> >
> > Unused.
> > Also the devices should be able to release themselves.
> >
> > Signed-off-by: Frediano Ziglio
> > ---
> > server/char-device.h | 3 +--
> > server/reds.c| 2 +-
> > server/spicevmc.c| 2 +-
> > 3 files changed, 3 insertions(+), 4 deletions(-)
>
On Fri, Jun 21, 2019 at 9:16 AM Frediano Ziglio wrote:
>
> >
> > Hello Eric,
> >
> > > A new command may be okay, however,
> >
> > thanks, I've fix the typos and updated the patch to use an Enum, which
> > indeed makes more sense.
> >
> > I've also updated "spice-query" command to provide the curr
Signed-off-by: Frediano Ziglio
---
server/dcc-send.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/dcc-send.c b/server/dcc-send.c
index ea2128e27..b14619a2b 100644
--- a/server/dcc-send.c
+++ b/server/dcc-send.c
@@ -1834,7 +1834,7 @@ static void
display_channel_marsh
Drop drm_gem_object from qxl_bo, use the
ttm_buffer_object.base instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 6 +++---
drivers/gpu/drm/qxl/qxl_object.h | 4 ++--
drivers/gpu/drm/qxl/qxl_cmd.c | 4 ++--
drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +-
drivers/gp
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +-
drivers/gpu/drm/qxl/qxl_release.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c
b/drivers/gpu/drm/qxl/qxl_debugfs.c
index 013b938986c7..f30460782f05 100644
--
Drop vma_node from ttm_buffer_object, use the gem struct
(base.vma_node) instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/virtio/virtg
On Tue, 18 Jun 2019, Frediano Ziglio wrote:
> > >
> > > The point of the mmtime timestamps is that they are the same on the
> > > server and client thanks to the client running its own mmtime clock
> > > synchronized, modulo a server-controlled offset, to the server's
>
> Not sure about the "mod
We don't want to maintain more macros than necessary and in the end
the equivalent G_GNUC_XXX macros should be preferred.
Should any project actually depend on these macros they can keep using
them by defining the usual SPICE_DEPRECATED macro until they migrate
away from them or the macros are rein
>
> We don't want to maintain more macros than necessary and in the end
> the equivalent G_GNUC_XXX macros should be preferred.
spice-protocol public header are plain C so suggesting to use Glib is
not correct.
> Should any project actually depend on these macros they can keep using
> them by de
16 matches
Mail list logo
