summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* fix more inverted memset parametersHans de Goede2011-08-252-6/+6
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* fix leak in do_jpeg_encodeChristophe Fergeau2011-08-251-0/+4
| | | | | | | | Issue found by the Coverity scanner. HDG: Fixup don't free RGB24_line if it was not allocated by do_jpeg_encode Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* fix memory leak in error pathChristophe Fergeau2011-08-251-1/+2
| | | | Issue found by the Coverity scanner
* fix inverted memset parametersChristophe Fergeau2011-08-251-1/+1
| | | | Issue found by the Coverity scanner.
* Rename usbredir channel code to spicevmcHans de Goede2011-08-254-65/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While discussing various things with Alon in Vancouver, it came up that having a channel which simply passes through data coming out of a qemu chardev frontend unmodified, like the usbredir channel does, can be used for a lot of other cases too. To facilitate this the usbredir channel code will be turned into a generic spicevmc channel, which is just a passthrough to the client, from the spicevmc chardev. This patch renames usbredir.c to spicevmc.c and changes the prefix of all functions / structs to match. This should make clear that the code is not usbredir specific. Some examples of why having a generic spicevmc pass through is good: 1) We could add a monitor channel, allowing access to the qemu monitor from the spice client, since the monitor is a chardev frontend we could re-use the generic spicevmc channel server code, so all that is needed to add this (server side) would be reserving a new channel id for this. 2) We could allow users to come up with new channels of their own, without requiring qemu or server modification. The idea is to allow doing something like this on the qemu startup cmdline: -chardev spicevmc,name=generic,channelid=128 To ensure these new "generic" channels cannot conflict with newly added official types, they must start at the SPICE_CHANNEL_USER_DEFINED_START value (128). These new user defined channels could then either be used with a special modified client, with client plugins (if we add support for those), or by exporting them on the client side for use by an external ap, see below. 3) We could also add support to the client to make user-defined channels end in a unix socket / pipe, allowing handling of the data by an external app, we could for example have a new spice client cmdline argument like this: --custom-channel unixsocket=/tmp/mysocket,channelid=128 This would allow for something like: $random app on guest -> virtio-serial -> spicevmc chardev -> -> spicevmc channel -> unix socket -> $random app on client 4) On hind sight this could also have been used for the smartcard stuff, with a 1 channel / reader model, rather then the current multiplexing code where we've our own multiplexing protocol wrapper over the libcacard smartcard protocol. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* usbredir: Merge UsbRedirState and UsbRedirChannelHans de Goede2011-08-251-33/+18
| | | | | | | Now that the Channel struct is gone and the RedChannel has the same lifetime as the chardev interface there is no need to have these 2 separate. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* usbredir: Fix crash caused by MC changesHans de Goede2011-08-251-0/+1
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* usbredir: Ensure that our msg_rcv_buf is not used re-entrantlyHans de Goede2011-08-251-0/+12
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* red_channel: Fix msg buf memleak on parser errorHans de Goede2011-08-251-0/+1
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* client: setting monitors resolution before resizing screens, RHBZ #728252Yonit Halperin2011-08-252-12/+33
| | | | fix for "client: fix endless recursion in rearrange_monitors, RHBZ #692976"
* server: add tester and todo for multiple client supportAlon Levy2011-08-232-0/+137
|
* server/snd_worker.c: add reference counting to SndChannelAlon Levy2011-08-231-3/+28
| | | | | | | | | | Fixes a valgrind discovered possible bug in spice-server - valgrind on test_playback saw it, didn't see it happen with qemu. The problem is that the frames buffers returned by spice_server_playback_get_buffer are part of the malloc'ed SndChannel, whose lifetime is smaller then that of SndWorker. As a result a pointer to a previously returned spice_server_playback_get_buffer could remain and be used after SndChannel has been freed because the client disconnected.
* server/reds: reds_client_disconnect: remove wrong check for ↵Alon Levy2011-08-231-9/+5
| | | | | | | | reds_main_channel_connected The "channel->disconnecting" parameter already protects against recursion. Removed fixed TODOs.
* server/reds: fix reds_main_channel_connectedAlon Levy2011-08-233-1/+7
| | | | | instead of checking just for reds->main_channel check that there is at least one client as well.
* server: add public spice_server_get_num_clientsAlon Levy2011-08-234-0/+16
|
* server/snd_worker.c: add red_channel_client_destroy_dummyAlon Levy2011-08-233-15/+23
|
* server/red_channel: release channel allocated message bufferAlon Levy2011-08-231-0/+1
| | | | | handler->cb->release_msg_buf was not being called except in the error path, causing a memory leak.
* server/main_channel: reduce verbose agent data commandAlon Levy2011-08-231-1/+2
| | | | by using the new SPICE_DEBUG_LEVEL.
* drawables count for debugYonit Halperin2011-08-231-10/+32
|
* server: registering RedChannel in reds, instead of ChannelYonit Halperin2011-08-2315-812/+856
| | | | | | | | | | | | | | | | | | | | | | | Merging the functionality of reds::channel, into RedChannel. In addition, cleanup and fix disconnection code: before this patch, red_dispatcher_disconnect_display_client could have been called from the red_worker thread (and it must be called only from the io thread). RedChannel holds only connected channel clients. RedClient holds all the channel clients that were created till it is destroyed (and then it destroys them as well). Note: snd_channel still doesn't use red_channel, however it creates dummy channel and channel clients, in order to register itself in reds. server/red_channel.c: a channel is connected if it holds at least one channel client Previously I changed RedChannel to hold only connected channel clients and RedClient, to hold all the channel clients as long as it is not destroyed. usbredir: multichannel has not been tested, it just compiles.
* server/red_channel.c inroducing client_cbsYonit Halperin2011-08-232-2/+79
| | | | | client_cbs are supposed to be called from client context (reds). This patch will be used in future patches for relacing reds::Channel with RedChannel in order to eliminate redundancy.
* server/red_channel.c: pack all channel callbacks to ChannelCbsYonit Halperin2011-08-238-141/+127
|
* server/red_worker: add ref counting to RedDrawableAlon Levy2011-08-232-13/+30
| | | | | | | | introduces ref_red_drawable and put_red_drawable (rename from free_red_drawable) RedDrawable is already references by Drawable and RedGlzDrawable, with a hack to NULL the drawable field in RedGlzDrawable to indicate RedGlzDrawable is the last reference holder. Using an explicit reference count instead.
* server/red_worker: add stream_count (for debug purposes)Alon Levy2011-08-231-0/+3
|
* server/red_worker: validate_surface: print paniced surface_idAlon Levy2011-08-231-1/+4
|
* server/red_worker: no panic on double destroy primaryAlon Levy2011-08-231-1/+5
|
* server/red_worker: DEBUG_CURSORSAlon Levy2011-08-231-0/+13
| | | | | Add cursor allocation debugging code that is turned off as long as DEBUG_CURSORS is not defined.
* server/red_worker: on_new_display_channel_client: push ack, cleanupAlon Levy2011-08-231-4/+3
| | | | small cleanup patch, only functional change is sending a set ack message.
* server/red_worker: add cursor_channel_client_disconnectAlon Levy2011-08-231-1/+10
| | | | | makes RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT disconnect only a single client.
* server/red_worker: remove forced disconnect on connectAlon Levy2011-08-231-2/+0
|
* server/red_worker.c: fix CursorPipeItem leakYonit Halperin2011-08-231-4/+35
| | | | | | | CursorPipeItems and their corresponding cursor_item were not freed when they were removed from the pipe without sending them. In addition cursor_channel_hold_pipe_item used wrong conversion to (CursorItem*) for a (CursorPipeItem*).
* server/red_worker: split cursor pipe item from cursor itemAlon Levy2011-08-231-26/+34
| | | | | | | | | | Required to support multiple clients. Also changes somewhat the way we produce PIPE_ITEM_TYPE_LOCAL_CURSOR. Btw, I haven't managed to see when we actually produce such an item during my tests. Previously we had a single pipe item per CursorItem, this is impossible with two pipes, which happens when we have two clients.
* server/red_worker: whitespace fixesAlon Levy2011-08-231-2/+1
|
* server/reds: add RedsState.allow_multiple_clientsAlon Levy2011-08-231-1/+12
| | | | | Currently set by environment variable SPICE_DEBUG_ALLOW_MC (any value means to allow multiple connections). Later will be set by spice api from qemu.
* server/red_channel: introduce client ring in RedChannelAlon Levy2011-08-234-327/+811
| | | | | | | | | | | | | | | | | Also adds Drawable pipes and glz rings. main_channel and red_worker had several locations that still accessed rcc directly, so they had to be touched too, but the changes are minimal. Most changes are in red_channel: drop the single client reference in RedChannel and add a ring of channels. Things missing / not done right in red_worker: * StreamAgents are in DCC - right/wrong? * GlzDict is multiplied - multiple compressions. We still are missing: * remove the disconnect calls on new connections
* server/red_channel: add pipe_size helpersAlon Levy2011-08-233-7/+33
|
* server/red_worker: remove more direct access to RedChannelClient.rccAlon Levy2011-08-231-36/+51
|
* server/red_worker.c: make dictionary and cache different per clientYonit Halperin2011-08-231-23/+31
| | | | | | | | | There is no inter-client shared dictionary and cache yet. At this point the display channel can be used by multiple clients. You can still crash on lack of Drawables or CursorItems due to the slower clients pipe growing uncontrollably.
* server/red_worker: multiple client support - base splitAlon Levy2011-08-235-808/+1014
| | | | | | | | | | | | | | | | | | This patch compiles but breaks spice. Split both display and cursor channels to a client part and channel part. Introduce DisplayChannelClient, CursorChannelClient, CommonChannelClient. don't disconnect channel on client disconnect. Move all caches to the ChannelClient's. Remove reference counting of the channel. No new functionality introduced. NOTE: Introduces a crash in disconnections, a regression, resulting from incorrect thread access, that is fixed in the patch titled: "server: registering RedChannel in reds, instead of Channel"
* server/red_worker: cleanupAlon Levy2011-08-231-30/+49
|
* server/smartcard: support multiple clientsAlon Levy2011-08-231-34/+46
| | | | | | | | | each client supplying a smartcard channel gets it's own smartcard. If there are not enough smartcards provided by the server (read: qemu) then it will be as though there are none. currently disabled - later patches that enable smartcard don't make this channel available to any but the first client.
* server/red_tunnel_worker: trivial multi client supportAlon Levy2011-08-233-128/+134
| | | | | | | | | | | | s/TunnelChannel/TunnelChannelClient/ That's about it. this is probably the wrong way to do it. Not tested at all. What do we want, a separate interface per client? same interface for all clients? probably the later. This doesn't do that. Not tested, so probably doesn't even work. changes red_channel_pipe_item_is_linked to red_channel_client_pipe_item_is_linked, since tunnel channel is the only user, must be done in patch to not break compilation.
* server/inputs_channel: support multiple clientsAlon Levy2011-08-231-28/+29
| | | | | from server events are broadcast - leds change. The rest is client to server, so it is just passed on.
* server/main_channel: support multiple clientsAlon Levy2011-08-234-164/+209
| | | | | | | | | | | | | | | | The main channel deals with connecting new clients, announcing mouse mode changes, and the agent channel. The implementation is currently done without any changes to the protocol, so everything has to be either broadcast or to a specific client. channels list - specific client mouse mode - broadcast agent - broadcast notify - broadcast (should have two modes, and use the appropriate) Notable TODOs: * migration testing * agent tokens are wrongly sent (or did I fix that? check)
* server/red_channel: introduce pipes functionsAlon Levy2011-08-232-8/+69
| | | | | | | | | | Introduce functions to add (via producer method) the same item to multiple pipes, all for the same channel. Note: Right now there is only a single channel, but the next patches will do the per-channel breakdown to channel and channel_client before actually introducing a ring in RedChannel, this makes it easier to make smaller changes - the channel->rcc link will exist until removed in the ring introducing patch.
* server/red_channel: ignore error if already shutdownAlon Levy2011-08-231-0/+3
| | | | | | on red_channel_peer_on_incoming_error, if we are already shutdown, do not call the channel's error handler. Since the channel has been shutdown, we assume this is a second or later error, and handling has already occured.
* server/main_channel: move connection_id from redsAlon Levy2011-08-233-20/+40
| | | | | | | | | | Expose additional api to find a client given a connection_id. The connection_id is first set when the first channel connects, which is the main channel. It could also be kept in the RedClient instead, not sure. TODO: multiple todo's added for multiclient handling. I don't remember why I wrote them exactly, and besides if I did any migration tests. So: TODO.
* server/main_channel: move ping here from reds.Alon Levy2011-08-233-51/+56
| | | | | | | | | | | | | cleanup only. Note that the ping function is half used since the opt parameter stopped being called with anything but NULL, should be returned at some point, specifically when we drop the 250kbyte ping on start and do a continuous check for latency and bandwidth. See: 81945d897 - server: add new vd interface QTerm2Interface, Yaniv Kamay introducing the usage of ping with a non NULL opt 3f7ea8e7a - zap qterm interfaces, Gerd Hoffman removing it
* server/main_channel: move latency and bitrate to channel clientAlon Levy2011-08-237-40/+96
| | | | | | | | | | | | They were globals before. This introduces api for other channels to query the low bandwidth status. The queries themselves are still done from the wrong context (channel and not channel client) but that's because the decoupling of channel and channel client will be done in the following patches. Note that snd_worker.c got two copied function declarations that belong to main_channel.h but can't be easily dragged into snd_worker.c since it still uses it's own RedChannel struct.
* server/reds: add concept of secondary channelsAlon Levy2011-08-231-4/+26
| | | | | | | | | | | | | | | | | | Secondary channels are those that don't support multiple clients. The support added in this patch just doesn't let the second or more connected client receive the unsupported channels in the channels list sent by the server to the client. This doesn't handle the situation where: client A connects (gets all channels) client B connects (gets supported multiple client channels) client A disconnects (Suboptimal 1: B doesn't get new channels at this point) client C connects (Suboptimal 2: C doesn't get the full list of channels, but the partial one) Specifically the channels that only support a single client are: sound (both playback and record channels) smartcard tunnel
generated by cgit (git 2.34.1) at 2025-10-02 02:42:27 +0000