| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
rename types - we use _proc suffix mostly to indicate function pointer types,
use it for some function pointers that were missing it.
s/channel_handle_migrate_flush_mark/channel_handle_migrate_flush_mark_proc/
s/channel_handle_migrate_data_get_serial/channel_handle_migrate_data_get_serial_proc/
s/channel_handle_migrate_data/channel_handle_migrate_data_proc/
|
| |
|
|
|
|
|
|
|
|
| |
This allows later to have the callback table under RedChannel when
the callbacks actually get used by RedChannelClient. Since the cb's
are identical for different clients of the same channel it makes sense
to store the callback pointers in one place per channel. The rest of
the incoming and outgoing struct just gets moved to RedChannelClient.
|
|
|
|
| |
replace channel_release_res in red_worker with red_channel_disconnect.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is useful during the channel specific channel_send_pipe_item_proc
callback, it allows altering or reader the header being sent.
|
|
|
|
|
|
| |
Use in main_channel. This is just for backward portability later
when multiple clients are introduced - needs to be considered (which
sockets do we want to export from libspiceserver?)
|
| |
|
|
|
|
|
| |
use in config_socket, this makes the stream internal to the RedChannel
implementation that will change later for multiple client support.
|
|
|
|
|
|
|
|
|
|
| |
Handling done in red_channel instead of per channel, using call backs
for the channel specific part.
Intended to reduce furthur reliance of channels on RedChannel struct.
The commit makes the code harder to understand because of the artificial
get_serial stuff, should later be fixed by having a joint migration
header with the serial (since all channels pass it).
|
|
|
|
|
|
|
| |
For ussage in the send_item callback. It's only valid during this
time anyway (should make it return NULL in other occasions?)
No more direct usage of RedChannel.send_data.marshaller by channels.
|
| |
|
| |
|
|
|
|
| |
ready the way for handling ack messages in RedChannel.
|
| |
|
|
|
|
|
|
|
|
| |
This is stylish change again. We are talking about a RedStream object,
so let's just name the variable "stream" everywhere, to avoid
confusion with a non existent RedPeer object.
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=34795
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
for later use in red_worker
|
| |
|
|
|
|
| |
from red_worker
|
|
|
|
| |
for later usage with red_worker
|
|
|
|
|
|
|
|
| |
MAX_SEND_VEC was 100 for DisplayChannel's RedChannel implementation which is being replaced
with RedChannel in red_channel. So changing from 50 to 100 in red_channel
(make this configurble?) - effectively increased memory usage by:
(100-50)*sizeof(iovec)*(num_of_channels-2) ==(arch 64bit) 50*16*6 ~ 5k
Not terrible.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hold_item called on init_send_data, matching release.
This is not the behavior of red_worker - we ref++ (==hold_item) when
sending the item, and --refs when releasing it, instead of only holding
if the send is blocked.
Note 1: Naming: hold_pipe_item is the proc name, the variable is called
hold_item, this is similar to release_item/release_pipe_item naming.
Note 2: All channels have empty implementation, we later use this when
red_worker get's RedChannelized.
|
| |
|
| |
|
| |
|
|
|
|
| |
error handlers for later inputs/main channel usage
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
letancy -> latency
compund -> compound
SpicedSubMessage -> SpiceSubMessage
modifaiers -> modifiers
massage -> message
outgoiong -> outgoing
AlphaBlnd -> AlphaBlend
remoth -> remote
modifires -> modifiers
secore -> secure
|
|
|
|
| |
move over content to spice.h
|
| |
|
| |
|
|
|
|
|
|
| |
This is an automatic change using:
$ find -name "*.[ch]" | xargs ../spice-protocol/rename-identifiers.sh ../spice-protocol/renames
$ find -name "*.cpp" | xargs ../spice-protocol/rename-identifiers.sh ../spice-protocol/renames
|
|
|