This vfunc only has a RedChannelClient * argument, and most of the time,
it operates on RedChannelClient, not on RedChannel. Moreover, the only
time it's used is from RedChannelClient. This commit moves the vfunc to
RedChannelClient, which seems like a better fit for it.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
display variable already contains the DCC_TO_DC(dcc) value so
reuse it.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Now the push is done automatically when a PipeItem is added
(cfr commit 5c460de1a3
"worker: push data when clients can receive them"),
forcing a push cause only network fragmentation and is required
only if you are handling data in a loop instead of using the
default loop.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
To help avoid stream.c and dcc.c to access display-channel private
structure to get the nth Stream structure pointer.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This is causing issues with potential improvements to the logging
system, and I've always found this usage a bit odd anyway.
Using spice_debug(""); was not possible as this triggers
-Wformat-zero-length warnings from our use of -Wall.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The maximum value for a 32 bit variable is UINT32_MAX and not
UINT_MAX. Currently all supported platforms have these two
constants having the same value so this patch don't change
nothing in the generated code but potentially this could
change in a future.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This commit changes all functions returning TRUE/FALSE from having an
'int' return value to 'bool'.
This way it's obvious that such a function is not going to return
anything else than TRUE or FALSE.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
config_socket is configuring the client stream socket.
As is responsibility of RedChannelClient to handle the stream
it make more sense to have the function in this object.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This prepare for the next patch.
The network recieve buffer should be per-client rather than per-channel.
The following patch will make this change, but this common base class
will allow the cursor client and the display client to share a common
implementation.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
[0] SPICE_MSGC_DISPLAY_PREFERRED_VIDEO_CODEC_TYPE
This message provides a list of video codecs based on client's order
of preference.
We duplicate the video codecs array from reds.c and sort it using the
order of codecs as reference.
This message will not change an ongoing streaming but it could change
newly created streams depending the rank value of each video codec
that can be set by spice_server_set_video_codecs()
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
For each channel there are two set of capabilities, one
for the common ones and one for the specific ones.
A single set were almost always passed using 2 arguments,
a number of elements and an array but then before using
these were converted to a GArray.
Use a single structure (already available) to pass all
channel capabilites using a single argument.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Using spice_info() gets in the way of tests using
g_test_expect_message() as all the messages emitted using
a non-debug log level must be listed as expected, otherwise we get a
critical about an expected message not having been logged.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Using X == TRUE is fragile, since the input value is a uint8_t. It would be
surprising if the value was set to 2 or 0xFF and the test failed.
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
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 expects a void * 'parsed' argument,
which will then be cast to the correct type. There is not really a need
to provide distinct handle_parsed/handle_message vfuncs, instead we can
say that if a RedChannel subclass provides a 'parser' vfunc, then it's
'handle_message' vfunc will be called with the parsed message, otherwise
it will be called with unparsed data (ie what handle_message currently
expects).
This makes the code slightly easier to follow as messages will always be
handled by the same vfunc.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
By removing the stream's video encoder we force the stream to send
future frames using the fallback code, that is as regular screen
updates.
However note that we keep the stream object: we have to. Otherwise
future frames would trigger the creation of a new stream object with a
new video encoder which would again try to stream the video and fail
again and again.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Reviewed-by: Victor Toso <victortoso@redhat.com>
The video encoders already have sophisticated bit rate control code that
can react to both stream reports sent by the client, and server frame
drop notifications. Furthermore they can adjust both the frame rate and
the image quality to best match the network conditions.
But if the client cannot send stream reports all this is bypassed and
instead the streaming code performs its own primitive bit rate control
that can only adjust the frame rate.
So this patch removes the code duplication and lets the video encoders
do their job.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The verify macro used currently has some problem
as it raise a warning in RHEL6.
Use new SPICE_VERIFY macro defined in spice-common
to avoid this issue.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Also move the RedClient struct out of the header to avoid accessing the
internals from other files.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
These functions were implementing the same stuff as empty
messages functions provided by RedChannel so reuse them.
The implementation seems a bit different but the result
is the same. Specifically:
- RedEmptyMsgPipeItem::msg is int while RedVerbItem::verb was
uint16_t however this data goes into the message type which
is uint16_t (a 16 bit on the network protocol);
- red_channel_client_send_empty_msg calls
red_channel_client_begin_send_message while red_marshall_verb
does not. However red_marshall_verb is called only by
cursor_channel_send_item and dcc_send_item which always
calls red_channel_client_begin_send_message.
Note that in dcc_send_item when an empty message is sent
red_channel_client_send_message_pending always returns
true;
- when a PipeItem is created red_channel_client_pipe_add_empty_msg
calls red_channel_client_push while red_pipe_add_verb does not.
This actually make very little difference as this kind of item are
never removed from the queue and a push is forced in every case
running the event handler for the stream watch (see
prepare_pipe_add and red_channel_client_event).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This makes red_monitors_config_item_new() and
red_monitors_config_item_free() symmetric.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Convert the RedChannelClient heirarchy into GObjects. Since the existing
constructors could fail and return NULL, I inherited the base channel
client from GInitable, which introduces a dependency on gio.
When using private structs with GObject, there's a maximum size of (I
think) 64k, which was exceeded by some of the private structs. To avoid
this limitation I changed some members to dynamically allocated.
Currently this is simply avoided by the fact that Virgl with 3d means
Unix socket. Once you enable (in Qemu) tcp sockets this message will
be added to all clients (supposing multiple clients) so potentially
will be in all queues. The same check is done for dcc_gl_scanout_item_new.
dcc_gl_scanout_item_new is called when Qemu calls spice_qxl_gl_draw_async.
Technically a client can support SPICE_DISPLAY_CAP_GL_SCANOUT but server
cannot send the DRM prime directly as this require a unix socket so
if the test for SPICE_DISPLAY_CAP_GL_SCANOUT is done here it make sense
to do the check for the socket type too.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
In anticipation of porting to GObject, use casting macros (e.g.
MAIN_CHANNEL_CLIENT()) to cast RedChannelClient types. This will help
reduce the changeset slightly porting to GObject and thus make it easier
to review those upcoming changes.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Instead of using a Ring (and having a ring item link in every pipe
item), store them in a GQueue. This also necesitated changing
RedCharDeviceVDIPort->priv->read_bufs to a GList as well.
Also Optimise client pipe by passing pipe position instead of data.
This avoids having the search the data scanning all the queue changing
the order of these operations from O(n) to O(1).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Move all of the DisplayChannel data memembers into a private struct to
encapsulate things better. This necessitated a few new 'public' methods
and a small bit of refactoring to avoid poking into DisplayChannel
internals from too many places. The DisplayChannel and the
DisplayChannelClient are still far too intertwined to completely avoid
accessing private data, so at the moment the private struct is defined
in display-channel.h and the DisplayChannelClient implementation
still accesses it sometimes.
Both src->stride and src->y are uint32_t
Fixed by making one of them uint64_t
Found by coverity
Signed-off-by: Uri Lublin <uril@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
These need to be introduced at the same time since cache-item.tmpl.c
assumes that both of these classes will have a cache in the same place:
either within the channel client struct itself or (now) within a priv
struct owned by the channel client.
This encapsulates private data and prepares for porting to GObject.
Acked-by: Frediano Ziglio <fziglio@redhat.com
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.
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.
The field is only used by DisplayChannelClient, not by CursorChannelClient
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The function was just calling another function with same parameters
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This reduces the number of arguments that need to be passed to the
function, and also avoids changing a different object within a function
that is supposed to just create a new object
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
