The Spice server administrator can specify the encoder and codec
preferences to optimize for CPU or bandwidth usage. Preferences are
described in a semi-colon separated list of encoder:codec pairs.
The server has a default preference list which can explicitly be
selected by specifying 'auto'.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Primary surface, as additional surfaces, can be used to access
host memory from the guest using invalid parameters.
The removed warning is not enough to prevent all cases. Also a warning
is not enough to stop an escalation to happen.
The red_validate_surface do different checks to make sure surface
request is valid and not cause possible buffer/integer overflows:
- format is valid;
- width is not large to cause overflow compared to stride;
- stride is not -2^31 (a number which negate is still <0);
- stride * height does not overflow.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1312980.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This fixes a regression introduced by
4028fb1c79, where clients_num
was not updated correctly anymore.
There is no reason to cache the number of elements on that list,
as the expected number of clients is quite small.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Avoid converting from RedChannelClient* to DisplayChannelClient* and
DisplayChannelClient* to RedChannelClient* just to use RedChannelClient*
('display_channel->clients' is a list of RedChannelClients).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Rename red_record_dev_input_primary_surface_create to
red_record_primary_surface_create.
Name is more concise and was not clear what "dev_input" was supposed
to specify.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Remove global/static from red_record_qxl.c.
Defined a structure and use it to hold record state.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The existence of this class can be hidden to user of CursorChannel class
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This function was handling mainly CursorChannel state
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Instead of using a Ring, use a GList to store the list of channel
clients. This allows us to iterate the clients without poking inside of
the client struct to get the channel_link. This is required in order to
make the RedChannelClient struct private.
The include directory is specified with the -I which is the directory
used directly by #include<>.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
We want the cursor to be initialized even if there is no canvas,
especially when using a GL scanout. This solves some client warnings
when using qemu with GL scanout-only (patches under review on qemu ML).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
CursorChannel and DisplayChannel was initialized half in red_worker_new
and half in red_dispatcher_init using some accessor for RedWorker
(red_worker_get_cursor_channel and red_worker_get_display_channel).
Moving directly into red_worker_new make easier to follow code path.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
All other messages (even empty ones) have a structure defined.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Add red_qxl_ methods wrapping the QXLInterface vfuncs. This allows to
remove most of the qxl_get_interface() use outside of red-qxl.c
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This seems to make more sense this way, QXLInstance is the 'main' object
with QXLState being its private data. External users then use QXLInstance
rather than passing a pointer to the private data to red-qxl.h methods.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Get the server variable from the QXLState instead of using the
global variable
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Considering that:
- QXLState is the state of QXLInstance implementation;
- RedDispatcher is the implementation of QXL;
- qif (QXLInterface*) field can be computed really easy from QXLInstance;
- most of its state is private.
Make all structure private and use QXLState instead of RedDispatcher.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
RedDispatcher is basically implementing QXLInstance.
After some internal discussion we decided to use QXLState structure
and red_qxl_ as function prefix.
This is the first of 3 patches that rename functions, structure
and files.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Rename this struct to make it clear that it's only the base class for
graphics channels (e.g. display and cursor), not all channels.
Also renamed CommonChannelClient to CommonGraphicsChannelClient.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Was not used by CursorChannelClient but only by DisplayChannelClient.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
They are now carried in the appropriate command through
QXLReleaseInfoExt, so we don't need to pass them around explicitly.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Now it no longer needs external state in order to destroy the
RedDrawable instance when needed, so we can remove this from the
prototype.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Storing a QXLReleaseInfoExt rather than a QXLReleaseInfo in RedDrawable
gives us a place to store group_id for free. Since we are building a
QXLReleaseInfoExt from QXLReleaseInfo and group_id when destroying a
RedDrawable instance, this is a move in the right direction.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's only used in a few debug printfs. If we want these stats, we'll
have to find a better way than forcing a dependency on a high-level
class in a lower-level _unref method just to maintain the stats.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
CommonChannel does not need to know about RedWorker.
This reduce a bit dependencies between objects.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Create an async, and marshall the GL_DRAW message. Count number of
clients, and wait until gl_draw_async_count is 0 to complete the async.
The count is going to be updated in the following patch when the client
is done with the draw.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
[removed unused sent field; move gl_draw_async_count to DisplayChannel
- Frediano Ziglio]
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Go through dispatcher and marshall scanout message. Since the marshaller
and the QXL state are manipulated from different threads, add a mutex to
protect the current scanout.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Instead of using CPU time use a timer depending on real times.
Currently that time in the record log is not used.
However if we want to reproduce problems with stream would be useful
to have real times instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Now that processing is correctly restored there is no need to keep
polling to avoid main loop hangs. Reduce the polling count to 1
(just try once).
This reduce cpu usage if guests are mainly idle.
If you consider 100 guests waiting to login with cursor blinking
and considering the polling was done 200 times every 10ms (maximum)
just the cursor blinking was causing 10100 loop iterations per second
while now only 200 are needed (considering cursor blinking every
second).
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make sure we process commands after we can send data to client.
If during processing we detected that there was too much data in the
clients queues the processing of commands just stop till the next
iteration.
However if all data are pushed in a single iteration of the loop
and commands were already processed there was the (remote) possibility
that the loop hangs till a separate event (like a screen resize on
client window) arrive.
I manage to reproduce and after half an hour no events arrived.
This patch detect that processing was stuck and now we can process new
commands and force a new iteration.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
During every iteration of the main worker loop, outgoing data was pushed to
the client. However, there was no guarantee that the loop would be woken up
in every situation. So there were some conditions where the loop would stop
iterating until a new event was sent.
Currently, the events that can wake up the main worker loop include:
- data from dispatcher (including wakeups from the guest)
- data from clients
- timeouts on a stream
- other timeouts
- polling
This patch adds a new wakeup event: when we have items that are queued to
be sent to a client, we set up a watch event for writing data to the
client. If no items are waiting to be sent, this watch will be disabled.
This allows us to remove the explicit push from the main worker loop.
This has some advantages:
- it could lower latency as we don't have to wait for a polling timeout.
From my experiments using a tight loop (so not really the ideal
condition to see the improvements) the total time was reduced by 2-3%)
- helps reduce the possibility of hanging loops
- avoids having to scan all clients to detect which one can accept data.
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
