summaryrefslogtreecommitdiffstats
path: root/server/spice.h
Commit message (Collapse)AuthorAgeFilesLines
* Split spice.hMarc-André Lureau2014-11-271-566/+33
| | | | Make it easier to read the Spice server API.
* spice.h: remove redundant declarationsMarc-André Lureau2014-11-271-5/+1
| | | | Those are already declared in <spice/qxl_dev.h>.
* chardev: remove write pollingMarc-André Lureau2014-11-251-2/+7
| | | | | | | | | | | | In an effort to reduce the wakeups per second, get rid of the "write_to_dev" timer when the implementation supports SPICE_CHAR_DEVICE_NOTIFY_WRITABLE. When this flag is set, the frontend instance is responsible for calling spice_char_device_wakeup() when the device is ready to perform IO. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=912763
* spice.h: Don't use 48kHz for playback/recording ratesChristophe Fergeau2014-08-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | When adding Opus support, SPICE_INTERFACE_PLAYBACK_FREQ and SPICE_INTERFACE_RECORD_FREQ in the public header 'spice.h' were changed from 44100 to 48000. However, this was not really useful as these constants are not used in spice-server, but only by users of spice-server (ie QEMU). It turns out changing these values is actually harmful. QEMU uses these constants in 2 situations: 1. when it's a version of QEMU with this commit, but we are compiling against older spice-server headers (before Opus support was added) 2. when it's a version of QEMU without commit 795ca114d35 which added what is needed for Opus support When we are in the second situation, having 48000 in the public header will actually cause issues as spice-server will know QEMU does not support Opus, so internally spice-server will be using a 44100 rate for audio. However, QEMU will be using SPICE_INTERFACE_.*_FREQ and think it should use a 48000 rate, which will cause distorsions as experienced in bug https://bugzilla.redhat.com/show_bug.cgi?id=1129961 Reverting these constants back to 44100 will fix audio in the 'new spice-server/old QEMU' scenario, and won't cause issues either when both support Opus as in this case these constants are not used.
* Add support for the Opus codecJeremy White2014-01-021-5/+10
| | | | Signed-off-by: Jeremy White <jwhite@codeweavers.com>
* server: mark deprecated symbolsMarc-André Lureau2013-10-071-22/+29
|
* server: Add support for filtering out agent file-xfer msgs (rhbz#961848)Hans de Goede2013-06-061-1/+2
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server: Add public spice_qxl_driver_unload methodHans de Goede2013-04-241-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | With a SPICE_DISPLAY_CAP_MONITORS_CONFIG capable client, the client needs to know what part of the primary to use for each monitor. If the guest driver does not support this, the server sends messages to the client for a single monitor spanning the entire primary. As soon as the guest calls spice_qxl_monitors_config_async once, we set the red_worker driver_has_monitors_config flag and stop doing this. This is a problem when the driver gets unloaded, for example after a reboot or when switching to a text vc with usermode mode-setting under Linux. To reproduce this start a multi-mon capable Linux guest which uses usermode mode-setting and then once X has started switch to a text vc. Note how the client window does not only not resize, if you try to resize it manually you always keep blackborders since the aspect is wrong. This patch is the spice-server side of fixing this, it adds a new spice_qxl_driver_unload method which clears the driver_has_monitors_config flag. The other patch needed to fix this is in qemu, and will calls this new method from qxl_enter_vga_mode. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server: add "port" channel supportMarc-André Lureau2012-12-051-1/+4
| | | | | | | | | | | | | | | | | A Spice port channel carry arbitrary data between the Spice client and the Spice server. It may be used to provide additional services on top of a Spice connection. For example, a channel can be associated with the qemu monitor for the client to interact with it, just like any qemu chardev. Or it may be used with various protocols, such as the Spice Controller. A port kind is identified simply by its fqdn, such as org.qemu.monitor, org.spice.spicy.test or org.ovirt.controller... The channel is based on Spicevmc which simply tunnels data between client and server, with a few additional messages. See the description of the channel protocol in spice-common history.
* server: bump SPICE_SERVER_VERSION to 0.12.2Marc-André Lureau2012-12-051-1/+1
|
* Revert "server: add websockets support via libwebsockets"Alon Levy2012-11-041-7/+0
| | | | This reverts commit 63bb37276e028ab1b1c156c9e7907bf22b6d5952.
* release 0.12.1Alon Levy2012-10-251-1/+1
|
* server: add websockets support via libwebsocketsAlon Levy2012-10-251-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New API: spice_server_set_ws_ports This adds an optional dependency on libwebsockets. You need to get my patched 0.0.3 version here: git://people.freedesktop.org/~alon/libwebsockets There is no qemu patches yet, to test change in reds.c the default value of spice_ws_port to 5959 (for the default of spice-html5). For testing there is an online client at http://spice-space.org/spice-html5/spice.html Known issues: 1. The tester (server/tests/test_display_no_ssl) gets into dropping all data after a few seconds, I think it's an issue with the implemented watches, but haven't figured it out. 2. libwebsocket's read interface is inverted to what our code expects, i.e. there is no libwebsocket_read, so there is an additional copy involved (see RedsWebSocket). This can be fixed. 3. Listening on a separate port. Since the headers are different, we could listen on the same port (first three bytes RED/GET). I don't know if we want to? Todos: 1. SSL not implemented yet. Needs some thought as to how. 2. Serve spice-html5 when accessed as a http server. Nice to have.
* Release 0.12.0v0.12.00.12.0Alon Levy2012-09-151-1/+1
|
* spice-server 0.11.5Alon Levy2012-09-131-1/+1
| | | | | | Added api: QXL interface (3.2) client_monitors_config
* server: add QXLInterface::client_monitors_configAlon Levy2012-09-131-3/+9
| | | | | | | | | | | | | | | | | | | | | | Used to implement guest monitor configuration change similarly to real hardware in conjunction with the new qemu interrupt QXL_INTERRUPT_CLIENT_MONITORS_CONFIG. client_monitors_config is also used to probe the support by the interface. If it is not supported we send the message to the guest agent. This makes a linux qxl driver similar to existing kms drivers. The logic is: For every received VDAgentMonitorsConfig: if client_monitors_config(NULL): write client configuration to pci rom BAR. send interrupt to guest guest kernel reads configuration from rom BAR. guest kernel issues event to user space user space reads (libdrm) and reconfigures (libXRandr) else: (current implementation) write message to guest agent guest agent issues reconfiguration via XRandr / windows Escape ioctl to kernel
* Bump SPICE_INTERFACE_QXL_VERSION_MINORSøren Sandmann Pedersen2012-09-111-1/+1
| | | | | Then check that we have the right version before accessing the set_client_capabilities() function.
* Bump spice.h version number to 0.11.4Søren Sandmann Pedersen2012-09-071-1/+1
| | | | | | | | No new symbols are added, but there is an addition to QXLInterface: void (*set_client_capabilities)(QXLInstance *qin, uint8_t client_present, uint8_t caps[58]);
* Add new set_client_capabilities() interface to QXLInstanceSøren Sandmann Pedersen2012-09-061-0/+3
| | | | | | | | | | | | | | | | | | | | | A new interface set_client_capabilities (QXLInstance *qin, uint8_t client_present, uint8_t caps[58]); is added to QXLInstance, and spice server is changed to call it whenever a client connects or disconnects. The QXL device in response is expected to update the client capability bits in the ROM of the device and raise the QXL_INTERRUPT_CLIENT interrupt. There is a potential race condition in the case where a client disconnects and a new client with fewer capabilities connects. There may be commands in the ring that the new client can't handle. This case is handled by first changing the capability bits, then processing all commands in the ring, and then start forwarding commands to the new client. As long as the guest obeys the capability bits, the new client will never see anything it doesn't understand.
* Implement spice_server_set_exit_on_disconnect to enable an option whereby ↵Jeremy White2012-09-051-0/+1
| | | | the spice server shuts down on client disconnect.
* bump version to 0.11.2Yonit Halperin2012-08-271-1/+1
| | | | | | | New api entries: spice_server_vm_start spice_server_vm_stop spice_server_set_seamless_migration
* spice.h: add spice_server_set_seamless_migrationYonit Halperin2012-08-271-0/+2
| | | | | | | | | | This new call is used in order to identify whether qemu, or the management (e.g. libvirt), support seamless migration. If it is supported, qemu spice cmd-line configuration should have seamless-migration=on. In addition, we disable seamless migration support if multiple clients are allowed. Currently, only one client is supported.
* spice_server_vm_start/stop: notify red_dispatcher on vm start/stopYonit Halperin2012-08-271-2/+4
| | | | | | | Till now, red_worker was notfied about vm status changes via QXLWorker->start/stop (or spice_qxl_start/stop). Newer qemu, that supports calling spice_server_vm_start/stop, will call only these routines, and won't call QXLWorker->start/stop.
* spice.h: add entries for tracking vm stateYonit Halperin2012-08-271-0/+3
| | | | | | | | | When vm state changes (started/stopped), we notify all the attached SpiceCharDeviceStates about the change. This is mainly required for avoiding writing/reading to/from the device during the non-live stage of migration. spice version will be bumped in one of the following patches.
* bump version to 0.11.1 for new spice_qxl_monitors_config_asyncAlon Levy2012-07-231-1/+1
| | | | | bump current and age since only additions where done. new server library is libspice-server.so.1.2.0 .
* server: add monitors_config supportAlon Levy2012-07-221-0/+3
| | | | | | | | | | | | | | | | a SpiceMsgDisplayMonitorsConfig is sent on two occasions: * as a result of a spice_qxl_monitors_config_async * whenever a client connects and there is a previously set monitors config Sending the new message is protected by a new cap, SPICE_DISPLAY_CAP_MONITORS_CONFIG More elaborately: spice_qxl_monitors_config_async receives a QXLPHYSICAL address of a QXLMonitorsConfig struct and reads it, caching it in the RedWorker, and sending it to all clients. Whenever a new client connects it receives a SpiceMsgDisplayMonitorsConfig message as well.
* spice.h: bump SPICE_SERVER_VERSION for release 0.11.0Alon Levy2012-06-271-1/+1
| | | | (cherry picked from commit dd5c995c32cf595d31e59975bd1b3216cf996656)
* Revert "spice.h: bump SPICE_SERVER_VERSION for release 0.11.0"Alon Levy2012-06-271-1/+1
| | | | This reverts commit dd5c995c32cf595d31e59975bd1b3216cf996656.
* spice.h: bump SPICE_SERVER_VERSION for release 0.11.0Alon Levy2012-06-211-1/+1
|
* server/spice.h: s/Pleaes/Please/Alon Levy2012-06-051-1/+1
|
* server: export spice_server_is_server_mouse predicateAlon Levy2012-03-261-1/+3
| | | | To be used by qemu query-spice / info spice commands.
* server: listen on a pre-opened file descriptorNahum Shalman2012-03-121-0/+1
| | | | | | | Allow applications to pre-open a file descriptor and have spice listen on it. Thanks to Daniel Berrange for his comments
* Send name & uuid to capable clientsMarc-André Lureau2012-03-051-1/+4
| | | | | | | | | Add spice_server_set_name() and spice_server_set_uuid() that allows the client to identify a Spice server (useful to associate settings with a particular server) The SPICE_MSG_MAIN_NAME and SPICE_MSG_MAIN_UUID messages are only sent to capable clients, announcing SPICE_MAIN_CAP_NAME_AND_UUID.
* server: support IPV6 addresses in channel events sent to qemuYonit Halperin2012-02-121-0/+6
| | | | | | | | | RHBZ #788444 CC: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Yonit Halperin <yhalperi@redhat.com>
* Release 0.10.1Hans de Goede2012-01-231-1/+1
|
* Allow auth to be skipped when attaching to pre-accepted clientsDaniel P. Berrange2012-01-091-2/+2
| | | | | | | | | | | When an applications passes in a pre-accepted socket for a client, they may well have already performed suitable authentication out of band. They should thus have the option to request that any spice authentication is skipped. * server/reds.c, spice.h: Add flag for skipping auth Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Add APIs for injecting a client connection socketDaniel P. Berrange2012-01-091-0/+3
| | | | | | | | | | | Allow applications to pass a pre-accepted client socket file descriptor in. The new APIs are spice_server_add_ssl_client and spice_server_add_client * server/reds.c: Implement new APIs * server/spice.h: Define new APIs Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* server/spice.h: semi-seamless migration interface, RHBZ #738266Yonit Halperin2011-11-021-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | semi-seamless migration details: migration source side --------------------- (1) spice_server_migrate_connect (*): tell client to link to the target side - send SPICE_MSG_MAIN_MIGRATE_BEGIN. This should be called upon client_migrate_info cmd. client_migrate_info is asynchronous. (2) Complete spice_server_migrate_connect only when the client has been connected to the target - wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) or a timeout. (3) spice_server_migrate_end: tell client migration it can switch to the target - send SPICE_MSG_MAIN_MIGRATE_END. (4) client cleans up all data related to the connection to the source and switches to the target. It sends SPICE_MSGC_MAIN_MIGRATE_END. migration target side --------------------- (1) the server identifies itself as a migraiton target since the client is linked with (connection_id != 0) (2) server doesn't start the channels' logic (channel->link) till it receives SPICE_MSGC_MAIN_MIGRATE_END from the client. * After migration starts, the target qemu is blocked and cannot accept new spice client connections. Thus, we trigger the connection to the target upon client_migrate_info command. (cherry picked from commit 6e56bea67c5648b0c81990171d4bc0cf1a402043 branch 0.8) Conflicts: server/spice.h
* server: add public spice_server_get_num_clientsAlon Levy2011-08-231-0/+3
|
* Bump version in server/spice,h to 0.9.1Hans de Goede2011-07-261-1/+1
| | | | | | | | It is a bit early to bump, since a 0.9.1 release is not happening yet, but this allows me to test if the vdagent SpiceCharInterface state callback fixes are present or not in qemu code, and thus disabling the ugly vdagent specific workaround from spice-qemu-char.c when compiling against a new enough spice-server.
* server/spice.h: bump QXL_MINOR because of QXLWorker and QXLInterface changesAlon Levy2011-07-201-1/+1
|
* server: add QXLWorker.flush_surfaces_async for S3/S4 supportAlon Levy2011-07-201-0/+2
| | | | | | | | | | | This does the following, all to remove any referenced memory on the pci bars: flush_all_qxl_commands(worker); flush_all_surfaces(worker); red_wait_outgoing_item((RedChannel *)worker->display_channel); red_wait_outgoing_item((RedChannel *)worker->cursor_channel); The added api is specifically async, i.e. it calls async_complete when done.
* server: add QXLInterface::update_area_complete callbackAlon Levy2011-07-201-0/+3
| | | | | when update_area_async is called update_area_complete will be called with the surfaces dirty rectangle list.
* server: add async io supportAlon Levy2011-07-201-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | The new _ASYNC io's in qxl_dev listed at the end get six new api functions, and an additional callback function "async_complete". When the async version of a specific io is used, completion is notified by calling async_complete, and no READY message is written or expected by the dispatcher. update_area has been changed to push QXLRects to the worker thread, where the conversion to SpiceRect takes place. A cookie has been added to each async call to QXLWorker, and is passed back via async_complete. Added api: QXLWorker: update_area_async add_memslot_async destroy_surfaces_async destroy_primary_surface_async create_primary_surface_async destroy_surface_wait_async QXLInterface: async_complete
* server: api: add spice_qxl_* calls based on QXLWorker contentsAlon Levy2011-07-201-0/+20
| | | | | | | | | For each callback in QXLWorker, for example QXLWorker::update_area, add a direct call named spice_qxl_update_area. This will (a) remove the pointless indirection and (b) make shared library versioning alot easier as we'll get new linker symbols which we can tag with the version they appeared in the shared library.
* sndworker: add AudioVolume/AudioMute messagesMarc-André Lureau2011-06-221-2/+8
| | | | | | | | | | | | | | | | | | | These messages allow the guest to send the audio device volume to the client. It uses an arbitrary scale of 16bits, which works good enough for now. Save VolumeState in {Playback,Record}State, so that we can send the current volume on channel connection. Note about future improvements: - add exact dB support - add client to guest volume change Updated since v2: - bumped record and playback interface minor version to allow conditional compilation Updated since v1: - sync record volume on connection too
* server: bump SPICE_SERVER_VERSION to 0.9.0Marc-André Lureau2011-05-081-1/+1
| | | | SASL functions will be released with 0.9.0
* server: Make copy paste support configurableHans de Goede2011-03-241-1/+2
| | | | | | Also bump SPICE_SERVER_VERSION to 0x000801 as 0.8.1 will be the first version with the new API for this, and we need to be able to detect the presence of this API in qemu.
* server: add SASL supportMarc-André Lureau2011-02-281-0/+2
| | | | | | | | | | | | We introduce 2 public functions to integrate with the library user. spice_server_set_sasl() - turn on SASL spice_server_set_sasl_appname() - specify the name of the app (It is used for where to find the default configuration file) The patch for QEMU is on its way. https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server: Update SPICE_SERVER_VERSIONHans de Goede2010-12-171-1/+1
|