| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This reverts commit 63bb37276e028ab1b1c156c9e7907bf22b6d5952.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Added api:
QXL interface (3.2)
client_monitors_config
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Then check that we have the right version before accessing the
set_client_capabilities() function.
|
|
|
|
|
|
|
|
| |
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]);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
the spice server shuts down on client disconnect.
|
|
|
|
|
|
|
| |
New api entries:
spice_server_vm_start
spice_server_vm_stop
spice_server_set_seamless_migration
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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 current and age since only additions where done.
new server library is libspice-server.so.1.2.0 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
(cherry picked from commit dd5c995c32cf595d31e59975bd1b3216cf996656)
|
|
|
|
| |
This reverts commit dd5c995c32cf595d31e59975bd1b3216cf996656.
|
| |
|
| |
|
|
|
|
| |
To be used by qemu query-spice / info spice commands.
|
|
|
|
|
|
|
| |
Allow applications to pre-open a file descriptor and have spice listen
on it.
Thanks to Daniel Berrange for his comments
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
RHBZ #788444
CC: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Yonit Halperin <yhalperi@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
when update_area_async is called update_area_complete will be called with
the surfaces dirty rectangle list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
SASL functions will be released with 0.9.0
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
While we are at it: There is no reason for chardev
support to stay in the experimental area, so move it out.
qemu should not need the "spice-experimental.h" file.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
|
|
|
|
|
| |
seamless stays in the experimental area.
comments updates too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a channel event callback to the spice core interface.
This new callback will be called for three events:
(1) A new connection has been established.
(2) The channel is ready (i.e. authentication is done,
link message verification passed all tests, channel
is ready to use).
(3) Channel was disconnected.
Qemu will use this to send notifications to the management app.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When upgrading a cluster of machines you typically do this by
upgrading a set of machines at a time, making the new machines run
the new software version, but in a fashion compatible with the old
versions (in terms of e.g. migration). Then when all machines are
upgrades, any new features in the new version can be enabled.
This API allows qemu to limit the set of features that spice uses to
those compatible with an older version, in order to do an upgrade like
this. Right now it doesn't really do much, since we don't keep compat
with 0.4.0 atm (although that may be added later).
There is no guarantee that any future version of spice support
being compatible with any previous version. However, we will always
support compatibility with the previous major version so that clusters
can be upgraded step by step.
|