Re: [Spice-devel] [PATCH spice-gtk 1/3] clipboard: accept grab only from the side with keyboard focus
Hey,
On Fri, Mar 15, 2019 at 8:02 PM Marc-André Lureau
wrote:
>
> Hi
>
> On Fri, Mar 15, 2019 at 4:43 PM Jakub Janku wrote:
> >
> > Hi,
> >
> > On Thu, Mar 14, 2019 at 6:18 PM Marc-André Lureau
> > wrote:
> > >
> > > Hi
> > >
> > > On Thu, Feb 28, 2019 at 8:12 PM Jakub Janků wrote:
> > > >
> > > > If two grab messages in opposite directions "meet" on their way
> > > > to their destinations, we end up in a state when both spice-gtk
> > > > and spice-vdagent think that the other component can provide
> > > > clipboard data. As a consequence of this, neither of them can.
> > > >
> > > > This is a bug in the spice-protocol. To mitigate the issue,
> > > > accept grab only from the side that currently has keyboard focus,
> > > > this means:
> > > > (1) spice-gtk has focus ==>
> > > > * accept grabs from vdagent,
> > > > * ignore grabs from other apps running in the host
> > > > (2) spice-gtk doesn't have focus ==>
> > > > * accept grabs from other apps running in the host
> > > > * ignore grabs from vdagent
> > > >
> > > > The check in clipboard_owner_change() is X11-specific,
> > > > because on Wayland, spice-gtk is first notified about the
> > > > owner-change once it gains focus.
> > > >
> > > > The check in clipboard_grab() can be generic.
> > > > Note that on Wayland, calling gtk_clipboard_set_with_owner()
> > > > while not having focus doesn't have any effect anyway,
> > > > only focused clients can set clipboard.
> > > >
> > > > With this patch, the race can still occur around the time
> > > > when focus changes (rare, but possible), on X11 as well as Wayland.
> > > >
> > > > Related: https://gitlab.freedesktop.org/spice/spice-gtk/issues/82
> > > > Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
> > > >
> > > > Signed-off-by: Jakub Janků
> > > > ---
> > > >
> > > > Victor, half of this patch is basically yours,
> > > > so feel free to add signed-off or something,
> > > > in the case this gets upstream :)
> > > >
> > > > ---
> > > > src/spice-gtk-session.c | 13 +
> > > > 1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > > > index b48f92a..7b7370c 100644
> > > > --- a/src/spice-gtk-session.c
> > > > +++ b/src/spice-gtk-session.c
> > > > @@ -680,6 +680,13 @@ static void clipboard_owner_change(GtkClipboard
> > > > *clipboard,
> > > > s->clip_hasdata[selection] = FALSE;
> > > > return;
> > > > }
> > > > +
> > > > +if (GDK_IS_X11_DISPLAY(gdk_display_get_default()) &&
> > > > +spice_gtk_session_get_keyboard_has_focus(self)) {
> > > > +SPICE_DEBUG("%s: spice-gtk has keyboard focus, "
> > > > +"ignoring grab from other app", __FUNCTION__);
> > > > +return;
> > > > +}
> > > > #endif
> > >
> > > This will break clipboard managers interactions, which may take the
> > > clipboard content, save it and/or modify it.
> >
> > Depends on the implementation of the given clipboard manager, I'd say.
> > I tried the "clipboard indicator" you're using. Seems like no problem there
> > :)
>
> without, and with that patch I suppose
Sure
>
> > >
> > > >
> > > > s->clip_hasdata[selection] = TRUE;
> > > > @@ -823,6 +830,12 @@ static gboolean clipboard_grab(SpiceMainChannel
> > > > *main, guint selection,
> > > > cb = get_clipboard_from_selection(s, selection);
> > > > g_return_val_if_fail(cb != NULL, FALSE);
> > > >
> > > > +if (!spice_gtk_session_get_keyboard_has_focus(self)) {
> > > > +SPICE_DEBUG("%s: spice-gtk doesn't have keyboard focus, "
> > > > +"ignoring grab from guest agent", __FUNCTION__);
> > > > +return FALSE;
> > > > +}
> > >
> > >
> > > Beside automation, the cursor alone may easily create a new clipboard
> > > content which won't be available to the client side (the auto-grab may
> > > fail to follow cursor etc).
> > >
> > > It's a bit unclear why it's not X11 specific but for client side
> > > change it is, this could deserve a code comment.
> >
> > Tried to describe that in the commit log. I could add a comment in the
> > code as well.
>
> yes, please
>
> > >
> > > All in all, this feels weak and breaks some legitimate cases.
> > >
> > > I am not very strongly against this, as I understand it may help with
> > > some races we discussed,
> >
> > Is this an ack or nack?
>
> If you ask me, it's a nack at this point, as I don't have a way to
> reproduce the problem at this point and I clearly see problematic case
> created by the patch. Iow, it looks like a regression to me.
>
> > Seems like we're just going round in circles now...
>
> Hopefully I am not the only one reviewing and questioning this patch
>
> > > but it feels like the problem is elsewhere
> >
> > sorry, but that's very vague, I have no idea what you're referring to
>
> Some clipboard managers seem to work fine. So what is klipper doing?
I've already tried to describe that in [0].
[0]
Re: [Spice-devel] [PATCH spice-gtk 1/3] clipboard: accept grab only from the side with keyboard focus
Hi
On Fri, Mar 15, 2019 at 4:43 PM Jakub Janku wrote:
>
> Hi,
>
> On Thu, Mar 14, 2019 at 6:18 PM Marc-André Lureau
> wrote:
> >
> > Hi
> >
> > On Thu, Feb 28, 2019 at 8:12 PM Jakub Janků wrote:
> > >
> > > If two grab messages in opposite directions "meet" on their way
> > > to their destinations, we end up in a state when both spice-gtk
> > > and spice-vdagent think that the other component can provide
> > > clipboard data. As a consequence of this, neither of them can.
> > >
> > > This is a bug in the spice-protocol. To mitigate the issue,
> > > accept grab only from the side that currently has keyboard focus,
> > > this means:
> > > (1) spice-gtk has focus ==>
> > > * accept grabs from vdagent,
> > > * ignore grabs from other apps running in the host
> > > (2) spice-gtk doesn't have focus ==>
> > > * accept grabs from other apps running in the host
> > > * ignore grabs from vdagent
> > >
> > > The check in clipboard_owner_change() is X11-specific,
> > > because on Wayland, spice-gtk is first notified about the
> > > owner-change once it gains focus.
> > >
> > > The check in clipboard_grab() can be generic.
> > > Note that on Wayland, calling gtk_clipboard_set_with_owner()
> > > while not having focus doesn't have any effect anyway,
> > > only focused clients can set clipboard.
> > >
> > > With this patch, the race can still occur around the time
> > > when focus changes (rare, but possible), on X11 as well as Wayland.
> > >
> > > Related: https://gitlab.freedesktop.org/spice/spice-gtk/issues/82
> > > Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
> > >
> > > Signed-off-by: Jakub Janků
> > > ---
> > >
> > > Victor, half of this patch is basically yours,
> > > so feel free to add signed-off or something,
> > > in the case this gets upstream :)
> > >
> > > ---
> > > src/spice-gtk-session.c | 13 +
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > > index b48f92a..7b7370c 100644
> > > --- a/src/spice-gtk-session.c
> > > +++ b/src/spice-gtk-session.c
> > > @@ -680,6 +680,13 @@ static void clipboard_owner_change(GtkClipboard
> > > *clipboard,
> > > s->clip_hasdata[selection] = FALSE;
> > > return;
> > > }
> > > +
> > > +if (GDK_IS_X11_DISPLAY(gdk_display_get_default()) &&
> > > +spice_gtk_session_get_keyboard_has_focus(self)) {
> > > +SPICE_DEBUG("%s: spice-gtk has keyboard focus, "
> > > +"ignoring grab from other app", __FUNCTION__);
> > > +return;
> > > +}
> > > #endif
> >
> > This will break clipboard managers interactions, which may take the
> > clipboard content, save it and/or modify it.
>
> Depends on the implementation of the given clipboard manager, I'd say.
> I tried the "clipboard indicator" you're using. Seems like no problem there :)
without, and with that patch I suppose
> >
> > >
> > > s->clip_hasdata[selection] = TRUE;
> > > @@ -823,6 +830,12 @@ static gboolean clipboard_grab(SpiceMainChannel
> > > *main, guint selection,
> > > cb = get_clipboard_from_selection(s, selection);
> > > g_return_val_if_fail(cb != NULL, FALSE);
> > >
> > > +if (!spice_gtk_session_get_keyboard_has_focus(self)) {
> > > +SPICE_DEBUG("%s: spice-gtk doesn't have keyboard focus, "
> > > +"ignoring grab from guest agent", __FUNCTION__);
> > > +return FALSE;
> > > +}
> >
> >
> > Beside automation, the cursor alone may easily create a new clipboard
> > content which won't be available to the client side (the auto-grab may
> > fail to follow cursor etc).
> >
> > It's a bit unclear why it's not X11 specific but for client side
> > change it is, this could deserve a code comment.
>
> Tried to describe that in the commit log. I could add a comment in the
> code as well.
yes, please
> >
> > All in all, this feels weak and breaks some legitimate cases.
> >
> > I am not very strongly against this, as I understand it may help with
> > some races we discussed,
>
> Is this an ack or nack?
If you ask me, it's a nack at this point, as I don't have a way to
reproduce the problem at this point and I clearly see problematic case
created by the patch. Iow, it looks like a regression to me.
> Seems like we're just going round in circles now...
Hopefully I am not the only one reviewing and questioning this patch
> > but it feels like the problem is elsewhere
>
> sorry, but that's very vague, I have no idea what you're referring to
Some clipboard managers seem to work fine. So what is klipper doing?
>
> > and we need a better solution to prevent the race from happening.
> >
> > I haven't read the bug reports: this kind of workaround needs a
> > description of a broken use case (not a theoretical description of a
> > race that "never" happen in practice).
>
> I described a broken case in the previous email:
> KDE with klipper, "prevent empty clipboard" enabled + slow network
Re: [Spice-devel] [PATCH spice-gtk 1/3] clipboard: accept grab only from the side with keyboard focus
Hi,
On Thu, Mar 14, 2019 at 6:18 PM Marc-André Lureau
wrote:
>
> Hi
>
> On Thu, Feb 28, 2019 at 8:12 PM Jakub Janků wrote:
> >
> > If two grab messages in opposite directions "meet" on their way
> > to their destinations, we end up in a state when both spice-gtk
> > and spice-vdagent think that the other component can provide
> > clipboard data. As a consequence of this, neither of them can.
> >
> > This is a bug in the spice-protocol. To mitigate the issue,
> > accept grab only from the side that currently has keyboard focus,
> > this means:
> > (1) spice-gtk has focus ==>
> > * accept grabs from vdagent,
> > * ignore grabs from other apps running in the host
> > (2) spice-gtk doesn't have focus ==>
> > * accept grabs from other apps running in the host
> > * ignore grabs from vdagent
> >
> > The check in clipboard_owner_change() is X11-specific,
> > because on Wayland, spice-gtk is first notified about the
> > owner-change once it gains focus.
> >
> > The check in clipboard_grab() can be generic.
> > Note that on Wayland, calling gtk_clipboard_set_with_owner()
> > while not having focus doesn't have any effect anyway,
> > only focused clients can set clipboard.
> >
> > With this patch, the race can still occur around the time
> > when focus changes (rare, but possible), on X11 as well as Wayland.
> >
> > Related: https://gitlab.freedesktop.org/spice/spice-gtk/issues/82
> > Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
> >
> > Signed-off-by: Jakub Janků
> > ---
> >
> > Victor, half of this patch is basically yours,
> > so feel free to add signed-off or something,
> > in the case this gets upstream :)
> >
> > ---
> > src/spice-gtk-session.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > index b48f92a..7b7370c 100644
> > --- a/src/spice-gtk-session.c
> > +++ b/src/spice-gtk-session.c
> > @@ -680,6 +680,13 @@ static void clipboard_owner_change(GtkClipboard
> > *clipboard,
> > s->clip_hasdata[selection] = FALSE;
> > return;
> > }
> > +
> > +if (GDK_IS_X11_DISPLAY(gdk_display_get_default()) &&
> > +spice_gtk_session_get_keyboard_has_focus(self)) {
> > +SPICE_DEBUG("%s: spice-gtk has keyboard focus, "
> > +"ignoring grab from other app", __FUNCTION__);
> > +return;
> > +}
> > #endif
>
> This will break clipboard managers interactions, which may take the
> clipboard content, save it and/or modify it.
Depends on the implementation of the given clipboard manager, I'd say.
I tried the "clipboard indicator" you're using. Seems like no problem there :)
>
> >
> > s->clip_hasdata[selection] = TRUE;
> > @@ -823,6 +830,12 @@ static gboolean clipboard_grab(SpiceMainChannel *main,
> > guint selection,
> > cb = get_clipboard_from_selection(s, selection);
> > g_return_val_if_fail(cb != NULL, FALSE);
> >
> > +if (!spice_gtk_session_get_keyboard_has_focus(self)) {
> > +SPICE_DEBUG("%s: spice-gtk doesn't have keyboard focus, "
> > +"ignoring grab from guest agent", __FUNCTION__);
> > +return FALSE;
> > +}
>
>
> Beside automation, the cursor alone may easily create a new clipboard
> content which won't be available to the client side (the auto-grab may
> fail to follow cursor etc).
>
> It's a bit unclear why it's not X11 specific but for client side
> change it is, this could deserve a code comment.
Tried to describe that in the commit log. I could add a comment in the
code as well.
>
> All in all, this feels weak and breaks some legitimate cases.
>
> I am not very strongly against this, as I understand it may help with
> some races we discussed,
Is this an ack or nack?
Seems like we're just going round in circles now...
> but it feels like the problem is elsewhere
sorry, but that's very vague, I have no idea what you're referring to
> and we need a better solution to prevent the race from happening.
>
> I haven't read the bug reports: this kind of workaround needs a
> description of a broken use case (not a theoretical description of a
> race that "never" happen in practice).
I described a broken case in the previous email:
KDE with klipper, "prevent empty clipboard" enabled + slow network
Cheers,
Jakub
>
>
> > +
> > for (n = 0; n < ntypes; ++n) {
> > found = FALSE;
> > for (m = 0; m < SPICE_N_ELEMENTS(atom2agent); m++) {
> > --
> > 2.20.1
> >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>
> --
> Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-common] meson: Remove some useless checks
On 3/13/19 2:24 PM, Frediano Ziglio wrote: > Do not check for functions not used or available in C89 and earlier. > Autoconf check for them to support archaic systems. > > Signed-off-by: Frediano Ziglio > --- > meson.build | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/meson.build b/meson.build > index f451f1c..f69e4bc 100644 > --- a/meson.build > +++ b/meson.build > @@ -77,11 +77,6 @@ endforeach > # check for system functions > # > functions = ['alloca', > - 'dup2', > - 'floor', > - 'fork', > - 'memmove', > - 'memset', > 'sigaction', > 'drand48'] > > Acked-by: Eduardo Lima (Etrunko) -- Eduardo de Barros Lima (Etrunko) Software Engineer - RedHat etru...@redhat.com ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-server v2] Move channel registration to constructed vfunc
On Fri, 2019-03-15 at 05:05 -0400, Frediano Ziglio wrote: > > > > For the Display Channel and the Cursor channel, move the call to > > reds_register_channel() to the _constructed() vfunc rather than > > calling > > it explicitly from RedWorker. This matches what other channels do. > > --- > > Changes in v2: > > - remove cursor channel registration in stream device > > > > Note that I didn't implement a couple other suggestions from > > Frediano's first > > review. Reference > > earlier email reply for justification. > > > > Why this comment? Were you waiting for my reply? > I though was the normal review process and I had no reason to reply. > Did I misunderstand? > No, I was just explaining why I didn't change some things that you had suggested in your first review. It took a little while between my initial patch and this one, so I thought I'd provide a bit more context in case you had forgotten. Jonathon ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-server 2/2] Remove support for 64 bit pointers on protocol
ping
>
> Import "codegen: Remove support for --ptrsize" change from spice-common
> and update code accordingly.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/char-device.c | 2 +-
> server/dcc-send.c| 2 +-
> server/reds.c| 2 +-
> server/smartcard.c | 2 +-
> subprojects/spice-common | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/server/char-device.c b/server/char-device.c
> index 0ebcc2e05..9ee255664 100644
> --- a/server/char-device.c
> +++ b/server/char-device.c
> @@ -903,7 +903,7 @@ void red_char_device_migrate_data_marshall(RedCharDevice
> *dev,
> write_to_dev_size = 0;
> write_to_dev_tokens = 0;
>
> -m2 = spice_marshaller_get_ptr_submarshaller(m, 0);
> +m2 = spice_marshaller_get_ptr_submarshaller(m);
> if (dev->priv->cur_write_buf) {
> uint32_t buf_remaining = dev->priv->cur_write_buf->buf +
> dev->priv->cur_write_buf->buf_used -
> dev->priv->cur_write_buf_pos;
> diff --git a/server/dcc-send.c b/server/dcc-send.c
> index e19ee19c3..326e6fa80 100644
> --- a/server/dcc-send.c
> +++ b/server/dcc-send.c
> @@ -1792,7 +1792,7 @@ static void
> display_channel_marshall_migrate_data_surfaces(DisplayChannelClient
> SpiceMarshaller
> *m,
> int lossy)
> {
> -SpiceMarshaller *m2 = spice_marshaller_get_ptr_submarshaller(m, 0);
> +SpiceMarshaller *m2 = spice_marshaller_get_ptr_submarshaller(m);
> uint32_t num_surfaces_created;
> uint8_t *num_surfaces_created_ptr;
> uint32_t i;
> diff --git a/server/reds.c b/server/reds.c
> index 429f81423..bc0437643 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -1478,7 +1478,7 @@ void reds_marshall_migrate_data(RedsState *reds,
> SpiceMarshaller *m)
> sizeof(VDIChunkHeader));
> spice_marshaller_add_uint8(m, mig_data.agent2client.msg_header_done);
> spice_marshaller_add_uint32(m,
> mig_data.agent2client.msg_header_partial_len);
> -m2 = spice_marshaller_get_ptr_submarshaller(m, 0);
> +m2 = spice_marshaller_get_ptr_submarshaller(m);
> spice_marshaller_add(m2, agent_dev->priv->current_read_buf->data,
> mig_data.agent2client.msg_header_partial_len);
> spice_marshaller_add_uint32(m, mig_data.agent2client.msg_remaining);
> diff --git a/server/smartcard.c b/server/smartcard.c
> index ef99056e1..9ccfbc6b1 100644
> --- a/server/smartcard.c
> +++ b/server/smartcard.c
> @@ -409,7 +409,7 @@ static void
> smartcard_channel_send_migrate_data(RedChannelClient *rcc,
> red_char_device_migrate_data_marshall(RED_CHAR_DEVICE(dev), m);
> spice_marshaller_add_uint8(m, dev->priv->reader_added);
> spice_marshaller_add_uint32(m, dev->priv->buf_used);
> -m2 = spice_marshaller_get_ptr_submarshaller(m, 0);
> +m2 = spice_marshaller_get_ptr_submarshaller(m);
> spice_marshaller_add(m2, dev->priv->buf, dev->priv->buf_used);
> spice_debug("reader added %d partial read size %u",
> dev->priv->reader_added, dev->priv->buf_used);
> }
> diff --git a/subprojects/spice-common b/subprojects/spice-common
> index 92d5dfd4b..302e30ff4 16
> --- a/subprojects/spice-common
> +++ b/subprojects/spice-common
> @@ -1 +1 @@
> -Subproject commit 92d5dfd4bfa7ae4857e96504a6f14c336ed85338
> +Subproject commit 302e30ff43401d9b1e7043a5e5c4f186ca997f66
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH spice-server] reds: Check we don't register a channel twice in reds_register_channel
To avoid possibly regression check it only if extra checks are
enabled.
This allowed to check previous "Move channel registration to constructed
vfunc" commit.
Signed-off-by: Frediano Ziglio
---
server/reds.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/server/reds.c b/server/reds.c
index 429f8142..e182eba7 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -380,6 +380,11 @@ void stat_remove_counter(SpiceServer *reds, RedStatCounter
*counter)
void reds_register_channel(RedsState *reds, RedChannel *channel)
{
spice_assert(reds);
+if (spice_extra_checks) {
+uint32_t this_type, this_id;
+g_object_get(channel, "channel-type", _type, "id", _id,
NULL);
+spice_assert(reds_find_channel(reds, this_type, this_id) == NULL);
+}
reds->channels = g_list_prepend(reds->channels, channel);
// create new channel in the client if possible
main_channel_registered_new_channel(reds->main_channel, channel);
--
2.20.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-server v2] Move channel registration to constructed vfunc
> > For the Display Channel and the Cursor channel, move the call to > reds_register_channel() to the _constructed() vfunc rather than calling > it explicitly from RedWorker. This matches what other channels do. > --- > Changes in v2: > - remove cursor channel registration in stream device > > Note that I didn't implement a couple other suggestions from Frediano's first > review. Reference > earlier email reply for justification. > Why this comment? Were you waiting for my reply? I though was the normal review process and I had no reason to reply. Did I misunderstand? Frediano ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-server v2] Move channel registration to constructed vfunc
>
> For the Display Channel and the Cursor channel, move the call to
> reds_register_channel() to the _constructed() vfunc rather than calling
> it explicitly from RedWorker. This matches what other channels do.
Acked-by: Frediano Ziglio
> ---
> Changes in v2:
> - remove cursor channel registration in stream device
>
> Note that I didn't implement a couple other suggestions from Frediano's first
> review. Reference
> earlier email reply for justification.
>
> server/cursor-channel.c| 12
> server/display-channel.c | 2 ++
> server/red-stream-device.c | 1 -
> server/red-worker.c| 2 --
> 4 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/server/cursor-channel.c b/server/cursor-channel.c
> index 9dd69fa25..4220084f5 100644
> --- a/server/cursor-channel.c
> +++ b/server/cursor-channel.c
> @@ -366,12 +366,24 @@ cursor_channel_finalize(GObject *object)
> G_OBJECT_CLASS(cursor_channel_parent_class)->finalize(object);
> }
>
> +static void
> +cursor_channel_constructed(GObject *object)
> +{
> +RedChannel *red_channel = RED_CHANNEL(object);
> +RedsState *reds = red_channel_get_server(red_channel);
> +
> +G_OBJECT_CLASS(cursor_channel_parent_class)->constructed(object);
> +
> +reds_register_channel(reds, red_channel);
> +}
> +
> static void
> cursor_channel_class_init(CursorChannelClass *klass)
> {
> GObjectClass *object_class = G_OBJECT_CLASS(klass);
> RedChannelClass *channel_class = RED_CHANNEL_CLASS(klass);
>
> +object_class->constructed = cursor_channel_constructed;
> object_class->finalize = cursor_channel_finalize;
>
> channel_class->parser =
> spice_get_client_channel_parser(SPICE_CHANNEL_CURSOR, NULL);
> diff --git a/server/display-channel.c b/server/display-channel.c
> index e68ed10f8..6684135eb 100644
> --- a/server/display-channel.c
> +++ b/server/display-channel.c
> @@ -2304,6 +2304,8 @@ display_channel_constructed(GObject *object)
> red_channel_set_cap(channel, SPICE_DISPLAY_CAP_PREF_COMPRESSION);
> red_channel_set_cap(channel, SPICE_DISPLAY_CAP_PREF_VIDEO_CODEC_TYPE);
> red_channel_set_cap(channel, SPICE_DISPLAY_CAP_STREAM_REPORT);
> +
> +reds_register_channel(reds, channel);
> }
>
> void display_channel_process_surface_cmd(DisplayChannel *display,
> diff --git a/server/red-stream-device.c b/server/red-stream-device.c
> index b9e0827af..78a8c9083 100644
> --- a/server/red-stream-device.c
> +++ b/server/red-stream-device.c
> @@ -701,7 +701,6 @@ stream_device_create_channel(StreamDevice *dev)
> client_cbs.connect = (channel_client_connect_proc)
> cursor_channel_connect;
> client_cbs.migrate = cursor_channel_client_migrate;
> red_channel_register_client_cbs(RED_CHANNEL(cursor_channel),
> _cbs);
> -reds_register_channel(reds, RED_CHANNEL(cursor_channel));
>
> dev->stream_channel = stream_channel;
> dev->cursor_channel = cursor_channel;
> diff --git a/server/red-worker.c b/server/red-worker.c
> index c74ae8886..3cb12b9c2 100644
> --- a/server/red-worker.c
> +++ b/server/red-worker.c
> @@ -1322,7 +1322,6 @@ RedWorker* red_worker_new(QXLInstance *qxl,
> red_channel_init_stat_node(channel, >stat, "cursor_channel");
> red_channel_register_client_cbs(channel, client_cursor_cbs);
> g_object_set_data(G_OBJECT(channel), "dispatcher", dispatcher);
> -reds_register_channel(reds, channel);
>
> // TODO: handle seamless migration. Temp, setting migrate to FALSE
> worker->display_channel = display_channel_new(reds, qxl, >core,
> FALSE,
> @@ -1333,7 +1332,6 @@ RedWorker* red_worker_new(QXLInstance *qxl,
> red_channel_init_stat_node(channel, >stat, "display_channel");
> red_channel_register_client_cbs(channel, client_display_cbs);
> g_object_set_data(G_OBJECT(channel), "dispatcher", dispatcher);
> -reds_register_channel(reds, channel);
>
> return worker;
> }
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
