On Tue, Feb 14, 2017 at 12:14:56PM -0600, Jonathon Jongsma wrote:
> To be honest, I could go either way on this one. I like the
> consistency, but I don't like the fact that it makes things like "git
> blame" less useful. I'll leave the decision to others ;)
I've pushed the series without this pat
Acked-by: Jonathon Jongsma
On Tue, 2017-02-14 at 15:51 +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/red-channel.c | 4
> 1 file changed, 4 insertions(+)
>
> Ping.
>
> diff --git a/server/red-channel.c b/server/red-channel.c
> index e70c46b..3599c3b 10064
On Tue, 2017-02-14 at 15:51 +, Frediano Ziglio wrote:
> Allows to see compressed/uncompressed ratio
>
> Signed-off-by: Frediano Ziglio
> ---
> server/spicevmc.c | 17 +
> 1 file changed, 17 insertions(+)
>
> Ping.
>
> diff --git a/server/spicevmc.c b/server/spicevmc.c
> ind
On Tue, 2017-02-14 at 15:51 +, Frediano Ziglio wrote:
> Use new structures and functions to implement statistic code.
> Instead of using macro use inline functions.
> Inline functions are more type safe.
> If statistics are disabled structure and functions became empty;
> this allow the code to
On Tue, 2017-02-14 at 15:55 +0100, Christophe Fergeau wrote:
> On Mon, Feb 13, 2017 at 11:03:19AM +, Frediano Ziglio wrote:
> > Most channel don't need to do specific settings for the
> > client socket so provide a default implementation to
> > make easier to setup the client channnel.
> >
> >
On Tue, 2017-02-14 at 15:55 +0100, Christophe Fergeau wrote:
> On Mon, Feb 13, 2017 at 11:03:19AM +, Frediano Ziglio wrote:
> > Most channel don't need to do specific settings for the
> > client socket so provide a default implementation to
> > make easier to setup the client channnel.
> >
> >
Francois did an hard job finding good parameters.
For instance for H264 he disabled B frames to avoid to wait for a future
frame and add slices to make bandwidth usage and CPU usage more regular.
Finding the right combination of flags to get good quality without
spending too much CPU or adding lot
To be honest, I could go either way on this one. I like the
consistency, but I don't like the fact that it makes things like "git
blame" less useful. I'll leave the decision to others ;)
Jonathon
On Tue, 2017-02-14 at 15:17 +0100, Christophe Fergeau wrote:
> It was sometimes named self, sometime
On Tue, 2017-02-14 at 15:17 +0100, Christophe Fergeau wrote:
> They no longer contain any vfuncs, so calling them "handler" does not
> make a lot of sense. This commit renames them to
> OutgoingMessageHandler/IncomingMessageHandler.
Typo here: OutgoingMessageBuffer instead of OutgoingMessageHandle
gdk_cursor_new has been deprecated since Gtk 3.16
Create the cursor when the widget is realized
Also allow to hide the cursor under Wayland
Acked-by: Victor Toso
---
src/spice-widget.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/src/spice-widge
Hi,
this is a follow up to Francois's patches which avoided some deprecated
warnings in the SpiceDisplay widget. (Also it seems that the client behavior
under Wayland is better (reported by Christophe), there are still some issues
with server mouse mode -
https://bugzilla.redhat.com/show_bug.cgi?
gdk_display_warp_pointer has been deprecated since Gtk 3.0
Acked-by: Victor Toso
---
src/spice-widget.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/spice-widget.c b/src/spice-widget.c
index c39373c..f3fa911 100644
--- a/src/spice-widget.c
+++ b/
gdk_window_get_pointer has been deprecated since Gtk 3.0
Introduce helper functions for getting the display's pointing
device and modifiers to keep the update_mouse_mode simple
---
src/spice-widget.c | 42 --
1 file changed, 32 insertions(+), 10 deletions(-
gdk_pointer_grab() was deprecated in 3.0 for gdk_device_grab()
but that was also deprecated for gdk_seat_grab() in 3.20
Acked-by: Victor Toso
---
src/spice-widget.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/src/spice-widget.c b/src/spice-wi
gdk_keyboard_grab() was deprecated in 3.0 for gdk_device_grab()
but that was also deprecated for gdk_seat_grab() in 3.20
---
src/spice-widget.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/spice-widget.c b/src/spice-widget.c
index f3fa911..9d99c80 100644
---
GtkVBox is deprecated since Gtk 3.2, GtkBox is going to be
deprecated. Just use the GtkContainer api.
---
Per the commit bc3d12efb20423d5b1ebd490658f687c4bd323fd the class is considered
final,
so this shouldn't be an ABI break
If we consider it as the ABI break we can just use the GtkContainer ap
On Mon, 2017-02-13 at 05:10 -0500, Frediano Ziglio wrote:
> >
> > On Wed, Feb 08, 2017 at 12:54:44PM -0600, Jonathon Jongsma wrote:
> > > On Tue, 2017-02-07 at 11:59 +0100, Christophe Fergeau wrote:
> > > > Similarly to the previous commits, this removes an indirection
> > > > level,
> > > > Incom
I think I would change the summary to something like:
Remove an unnecessary wrapper function
Acked-by: Jonathon Jongsma
On Fri, 2017-02-10 at 14:30 +, Frediano Ziglio wrote:
> smartcard_channel_client_pipe_add_push was just calling
> red_channel_client_pipe_add_push without any cast or ot
Acked-by: Jonathon Jongsma
On Fri, 2017-02-10 at 14:02 +, Frediano Ziglio wrote:
> This was always set to vec_buf.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/red-channel-client-private.h | 3 +--
> server/red-channel-client.c | 2 --
> 2 files changed, 1 insertion(+), 4 de
Acked-by: Jonathon Jongsma
On Fri, 2017-02-10 at 14:02 +, Frediano Ziglio wrote:
> Do not make it assume vec contains IOV_MAX elements.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/red-channel-client.c | 12 +++-
> server/red-channel-client.h | 4 ++--
> server/red-channel.
On Mon, Feb 13, 2017 at 03:49:44PM +0200, Snir Sheriber wrote:
> Remove handling with failures in the SASL authentication
> process to separate function and display the error message
> as reported by the SASL client (could also display SASL
> server error message if error number was sent to the cli
Hey, can you make sure the email subject indicates that it's a spice-gtk
patch?
Christophe
On Mon, Feb 13, 2017 at 03:49:43PM +0200, Snir Sheriber wrote:
> These patches splits the handling of failed authentication into 2
> separate patches: one for sasl authentication failure and the
> other one
>
> red_channel_client_parse() currently does roughly:
>
> if (klass->parser) {
> parsed = klass->parser(msg, msg_size, &parsed_size);
> klass->handle_parsed(rcc, parsed_size, msg_type, parsed);
> } else {
> klass->handle_message(rcc, msg_type, msg, msg_size);
> }
>
> The handle_pars
On Tue, Feb 14, 2017 at 10:02:01AM -0500, Frediano Ziglio wrote:
> >
> > Similarly to the previous commits, this removes an indirection level,
> > IncomingHandlerInterface stores pointers to
> > alloc_recv_buf/release_recv_buf vfuncs, but these are always set to
> > RedChannel::alloc_recv_buf/RedC
On Tue, Feb 14, 2017 at 09:54:40AM -0500, Frediano Ziglio wrote:
> >
> > Have the RedChannelClient callback call into a RedChannel callback
> > rather than doing the opposite. This will be useful in some subsequent
> > refactoring of this code.
> >
> > Signed-off-by: Christophe Fergeau
>
> Patc
Signed-off-by: Frediano Ziglio
---
server/red-channel.c | 4
1 file changed, 4 insertions(+)
Ping.
diff --git a/server/red-channel.c b/server/red-channel.c
index e70c46b..3599c3b 100644
--- a/server/red-channel.c
+++ b/server/red-channel.c
@@ -103,6 +103,7 @@ struct RedChannelPrivate
Use new structures and functions to implement statistic code.
Instead of using macro use inline functions.
Inline functions are more type safe.
If statistics are disabled structure and functions became empty;
this allow the code to work and compile with either statistic
disabled or enabled not requ
Allows to see compressed/uncompressed ratio
Signed-off-by: Frediano Ziglio
---
server/spicevmc.c | 17 +
1 file changed, 17 insertions(+)
Ping.
diff --git a/server/spicevmc.c b/server/spicevmc.c
index 9bcbada..174a04a 100644
--- a/server/spicevmc.c
+++ b/server/spicevmc.c
@@ -1
On Tue, Feb 14, 2017 at 09:47:05AM -0500, Frediano Ziglio wrote:
> >
> > It was probably meant to be used as a "user_data" argument for the
> > various callbacks, but turns out not to be used.
> >
> > Signed-off-by: Christophe Fergeau
>
> For me
>
> Acked-by: Frediano Ziglio
>
> I think usin
On Tue, Feb 14, 2017 at 10:16:43AM -0500, Frediano Ziglio wrote:
> >
> > On Mon, Feb 13, 2017 at 11:03:17AM +, Frediano Ziglio wrote:
> > > Non blocking flag is set for all connection inside reds.c so
> > > there's no need to set again for the single client channel.
> > >
> > > Signed-off-by:
>
> On Mon, Feb 13, 2017 at 11:03:17AM +, Frediano Ziglio wrote:
> > Non blocking flag is set for all connection inside reds.c so
> > there's no need to set again for the single client channel.
> >
> > Signed-off-by: Frediano Ziglio
>
> I'd move that code in a RedsStream helper while at it,
>
> On Mon, Feb 13, 2017 at 11:03:18AM +, Frediano Ziglio wrote:
> > TCP_NODELAY flag is set by default for all connection inside
> > reds.c so there's no need to set again for the single
> > client channel.
> >
> > Note that there are still some call to setsockopt to set this
> > option but
On Mon, Feb 13, 2017 at 11:03:17AM +, Frediano Ziglio wrote:
> Non blocking flag is set for all connection inside reds.c so
> there's no need to set again for the single client channel.
>
> Signed-off-by: Frediano Ziglio
I'd move that code in a RedsStream helper while at it, I can send a
pat
>
> It was sometimes named self, sometimes rcc, use rcc everywhere.
>
> Signed-off-by: Christophe Fergeau
> ---
> server/red-channel-client.c | 138
> ++--
> 1 file changed, 69 insertions(+), 69 deletions(-)
>
> diff --git a/server/red-channel-client.c
>
> They no longer contain any vfuncs, so calling them "handler" does not
> make a lot of sense. This commit renames them to
> OutgoingMessageHandler/IncomingMessageHandler.
>
> Signed-off-by: Christophe Fergeau
> ---
> server/red-channel-client.c | 84
> ++-
>
> Nothing outside of RedChannelClient needs access to data contained in
> RedChannelClientPrivate, so we can move all the type definitions to the
> .c file to make it fully opaque rather than relying on a private header.
>
> Signed-off-by: Christophe Fergeau
> ---
> server/Makefile.am
>
> It's only used by red-channel-client.c
>
> Signed-off-by: Christophe Fergeau
> ---
> server/red-channel-client-private.h | 22 ++
> server/red-channel.h| 22 --
> 2 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/ser
On Mon, Feb 13, 2017 at 11:03:18AM +, Frediano Ziglio wrote:
> TCP_NODELAY flag is set by default for all connection inside
> reds.c so there's no need to set again for the single
> client channel.
>
> Note that there are still some call to setsockopt to set this
> option but in this case the
>
> This commit removes what remains of IncomingHandlerInterface. The
> remaining function pointers were pointing to RedChannel vfuncs.
> Moreover the IncomingHandlerInterface abstraction is unused, ie the
> codebase only has a single implementation for it, so we can directly
> call the relevant m
>
> This commit removes IncomingHandlerInterface::on_error and
> IncomingHandlerInterface::on_input. As with previous commits, these
> vfuncs are always calling the method, and RedChannel::init sets them to
> point to RedChannelClient methods, which RedChannelClient is then going
> to call indirec
>
> Similarly to the previous commits, this removes an indirection level,
> IncomingHandlerInterface stores pointers to
> alloc_recv_buf/release_recv_buf vfuncs, but these are always set to
> RedChannel::alloc_recv_buf/RedChannel::release_recv_buf, which are also
> vfuncs which can be overridden i
On Mon, Feb 13, 2017 at 11:03:19AM +, Frediano Ziglio wrote:
> Most channel don't need to do specific settings for the
> client socket so provide a default implementation to
> make easier to setup the client channnel.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/inputs-channel.c | 6
On Mon, Feb 13, 2017 at 11:03:16AM +, Frediano Ziglio wrote:
> Avoid possible dandling pointers.
'dangling', though let's delay that after my patch series doing changes
in that area (I can rebase/queue your patch there).
Christophe
signature.asc
Description: PGP signature
__
>
> RedChannel uses OutgoingHandlerInterface to provide constant pointers to
> RedChannelClient methods. This OutgoingHandlerInterface structure is
> then used in RedChannelClient to indirectly call these methods.
>
> The OutgoingHandlerInterface abstraction is unused, ie the codebase
> only has
>
> Have the RedChannelClient callback call into a RedChannel callback
> rather than doing the opposite. This will be useful in some subsequent
> refactoring of this code.
>
> Signed-off-by: Christophe Fergeau
Patch is fine however I think the signal comment on 04/14
should be moved to this pat
>
> It was probably meant to be used as a "user_data" argument for the
> various callbacks, but turns out not to be used.
>
> Signed-off-by: Christophe Fergeau
For me
Acked-by: Frediano Ziglio
I think using an alternate way to provide dispatcher
would be better as a follow up.
Note that Jon
It's only used by red-channel-client.c
Signed-off-by: Christophe Fergeau
---
server/red-channel-client-private.h | 22 ++
server/red-channel.h| 22 --
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/server/red-channel-clien
Have the RedChannelClient callback call into a RedChannel callback
rather than doing the opposite. This will be useful in some subsequent
refactoring of this code.
Signed-off-by: Christophe Fergeau
---
server/red-channel-client.c | 2 ++
server/red-channel.c| 9 ++---
server/red-chan
They no longer contain any vfuncs, so calling them "handler" does not
make a lot of sense. This commit renames them to
OutgoingMessageHandler/IncomingMessageHandler.
Signed-off-by: Christophe Fergeau
---
server/red-channel-client.c | 84 ++---
1 file chang
It was sometimes named self, sometimes rcc, use rcc everywhere.
Signed-off-by: Christophe Fergeau
---
server/red-channel-client.c | 138 ++--
1 file changed, 69 insertions(+), 69 deletions(-)
diff --git a/server/red-channel-client.c b/server/red-channel-c
There is only one implementation of IncomingHandler which relies
IncomingHandler::opaque to be a RedChannlClient. This commit makes this
explicit. This allows to get rid of the IncomingHandler::opaque data
member.
This renames red_peer_handle_incoming() to
red_channel_client_handle_incoming() as t
Similarly to the previous commits, this removes an indirection level,
IncomingHandlerInterface stores pointers to
alloc_recv_buf/release_recv_buf vfuncs, but these are always set to
RedChannel::alloc_recv_buf/RedChannel::release_recv_buf, which are also
vfuncs which can be overridden if needed. Thi
There is only one implementation of OutgoingHandler which relies
OutgoingHandler::opaque being a RedChannelClient. This commit makes this
explicit in order to get rid of the OutgoingHandler::opaque data member.
This renames red_peer_handle_outgoing() to
red_channel_client_handle_outgoing() as the
The methods previously used by OutgoingHandlerInterface and
IncomingHandlerInterface are no longer used as generic callbacks,
but are directly called from RedChannelClient code. We can be explicit
about the type of their first argument (RedChannelClient *) rather than
using a generic void * pointer
RedChannel uses OutgoingHandlerInterface to provide constant pointers to
RedChannelClient methods. This OutgoingHandlerInterface structure is
then used in RedChannelClient to indirectly call these methods.
The OutgoingHandlerInterface abstraction is unused, ie the codebase
only has a single implem
Nothing outside of RedChannelClient needs access to data contained in
RedChannelClientPrivate, so we can move all the type definitions to the
.c file to make it fully opaque rather than relying on a private header.
Signed-off-by: Christophe Fergeau
---
server/Makefile.am | 1 -
red_channel_client_parse() currently does roughly:
if (klass->parser) {
parsed = klass->parser(msg, msg_size, &parsed_size);
klass->handle_parsed(rcc, parsed_size, msg_type, parsed);
} else {
klass->handle_message(rcc, msg_type, msg, msg_size);
}
The handle_parsed implementation expec
It was probably meant to be used as a "user_data" argument for the
various callbacks, but turns out not to be used.
Signed-off-by: Christophe Fergeau
---
server/inputs-channel.c | 2 +-
server/main-channel.c | 2 +-
server/red-channel.c| 6 +-
server/red-channel.h| 2 +-
server/red
Hey,
Series grew a few more patches since the first iteration after the review
comments, the most notable change would be the addition of
"channel: Remove RedChannel::handle_parsed" which addresses the issue with
red_channel_client_parse() return value which Jonathon pointed out. This changes
the
This commit removes what remains of IncomingHandlerInterface. The
remaining function pointers were pointing to RedChannel vfuncs.
Moreover the IncomingHandlerInterface abstraction is unused, ie the
codebase only has a single implementation for it, so we can directly
call the relevant methods and ma
This commit removes IncomingHandlerInterface::on_error and
IncomingHandlerInterface::on_input. As with previous commits, these
vfuncs are always calling the method, and RedChannel::init sets them to
point to RedChannelClient methods, which RedChannelClient is then going
to call indirectly through t
On Tue, Feb 14, 2017 at 08:33:09AM -0500, Marc-André Lureau wrote:
> Hi
>
> - Original Message -
> > >
> > > Allow easier processing by scripts and csv editors
> > > ---
> > > Also it renders nicely on github
> > > https://github.com/xerus/spice-gtk/blob/keymap/src/keymaps.csv
> > > From
On Tue, 2017-02-14 at 08:33 -0500, Marc-André Lureau wrote:
> Hi
>
> - Original Message -
> > >
> > > Allow easier processing by scripts and csv editors
> > > ---
> > > Also it renders nicely on github
> > > https://github.com/xerus/spice-gtk/blob/keymap/src/keymaps.csv
> > > From that ^
Hi
- Original Message -
> >
> > Allow easier processing by scripts and csv editors
> > ---
> > Also it renders nicely on github
> > https://github.com/xerus/spice-gtk/blob/keymap/src/keymaps.csv
> > From that ^ table is obvious which values are missing
>
> With
>
> git diff HEAD^ --w
On Tue, 2017-02-14 at 07:07 -0500, Frediano Ziglio wrote:
> >
> > Allow easier processing by scripts and csv editors
> > ---
> > Also it renders nicely on github
> > https://github.com/xerus/spice-gtk/blob/keymap/src/keymaps.csv
> > From that ^ table is obvious which values are missing
>
> With
>
> Allow easier processing by scripts and csv editors
> ---
> Also it renders nicely on github
> https://github.com/xerus/spice-gtk/blob/keymap/src/keymaps.csv
> From that ^ table is obvious which values are missing
With
git diff HEAD^ --word-diff --word-diff-regex='[^[:space:]]'
you can ea
Allow easier processing by scripts and csv editors
---
Also it renders nicely on github
https://github.com/xerus/spice-gtk/blob/keymap/src/keymaps.csv
From that ^ table is obvious which values are missing
---
src/keymaps.csv | 702
1 file
One thing I started to discuss last Wed is how video encoding may also require
/ introduce a lag on its own. The reason is that some video encodings use
predictive (P) or bidirectional (B) frames that are relative to surrounding
frames. Only a small fraction of the frames, the intracoded frames
On Thu, Feb 09, 2017 at 11:33:41AM -0600, Jonathon Jongsma wrote:
>
> Same comment as for the OutgoingHandler struct: removing these callback
> funcs means that the IncomingHandler name is no longer a very good fit.
> It's not so much a 'handler' as it is a collection of memory buffers
> and state
69 matches
Mail list logo
