summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Release 0.8.10.8.1Hans de Goede2011-04-202-1/+10
|
* client: skip spaces in --host-subjectChristophe Fergeau2011-04-201-1/+8
| | | | | | | | | | | | | | | | | | This fixes fdo bug #32896: "Subject in certificates is stored in following format (values separated by comma and space): grep Subject: server-cert.pem | awk -F": " '{print $2}' O=REDHAT, CN=10.34.58.2 While spicec expects that values in host subject are separated only by comma: spicec --host-subject "O=REDHAT,CN=10.34.58.2" " In this case, ignoring spaces make it much easier to directly copy and paste the subject line from certificates.
* client: add --version cmdline option to spicecChristophe Fergeau2011-04-201-1/+9
| | | | This fixes freedesktop bug #33907
* client: s/AVAILIBLE/AVAILABLE in CmdLineParserChristophe Fergeau2011-04-204-5/+5
| | | | It was mispelt in a CmdLineParser enum.
* server: make sure we clear vdagent and update mouse mode on agent disconnectHans de Goede2011-04-011-3/+0
| | | | | | | | The check this patch removes causes us to not set vdagent to NULL, nor update the mouse mode when the guest agent disconnects when no client is attached. Which leads to a non working mouse, and on agent reconnect a "spice_server_char_device_add_interface: vdagent already attached" message instead of a successful re-add of the agent interface .
* server: ignore SPICE_MSGC_MAIN_AGENT_START messages when there is no agentHans de Goede2011-04-011-1/+1
| | | | | This can happen for example when a SPICE_MSGC_MAIN_AGENT_START message from the client and the vdagent disconnecting race.
* server: hookup agent-msg-filter discard-all functionalityHans de Goede2011-04-011-33/+23
| | | | | | | This ensures that if the client or agent connects to the client-agent "tunnel" while the other side is halfway through sending a multi part message, the rest of the message gets discarded, and the connecting party starts getting data at the beginning of the next message.
* server: add discard all option to agent message filterHans de Goede2011-04-013-18/+26
|
* server: filter all data from clientHans de Goede2011-04-011-11/+11
| | | | | Filter all data from client, even when there is no agent connected to keep filter state correct.
* server: reset read/write filter on agent/client disconnectHans de Goede2011-04-011-0/+2
| | | | | | The agent message filter keeps track of messages as they are being send reset the relevant filter to its initial state when one of the 2 ends of the agent<->client "tunnel" disconnects.
* server: break read_from_vdi_port loop if the guest gets disconnectedHans de Goede2011-04-011-1/+1
| | | | | | | read_from_vdi_port calls dispatch_vdi_port data, which will disconnect the guest agent if it sends invalid data. It would then try to read more data from the disconnected guest agent resulting in a NULL ptr dereference, this patch fixes this.
* server: Don't stop writing agent data to the guest when the client disconnectsHans de Goede2011-04-011-2/+2
| | | | | | | | write_to_vdi_port() was checking for reds->agent_state.connected to determine wether it could write queued data. But agent_state.connected reflects if *both* ends are connected. If the client has disconnected, but the guest agent is still connected and some data is still pending (like a final clipboard release from the client), then this data should be written to the guest agent.
* server: Don't reset agent state when the client disconnectsHans de Goede2011-04-011-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were calling reds_reset_vdp on client disconnect, which is not a good idea. reds_reset_vdp does 3 things: 1) It resets the state related to reading chunks from the spicevmc virtio port. If the client disconnects while the guest agent is in the middle of sending a chunk, this will lead to an inconsistent state, and lots of printing of "dispatch_vdi_port_data: invalid port" messages caused by this inconsistent state sometimes followed by a segfault. This can be triggered by copy and pasting something large (say a screenshot) from the guest to the spice-gtk client, as the spice-gtk client currently has a bug causing it to crash when receiving a multi chunk vdagent messages. Without this patch (and with the spice-gtk bug present) I can consistently reproduce this. 2) It clears any buffered writes from the client to the guest still pending because the virtio port cannot consume data fast enough. Since the agent itself is still running fine, throwing away writes for it because the client has disconnected makes no sense. Esp, since on clean exit the client may very well send a clipboard release message directly before closing the connection, and this may get lost this way. 3) It sets client_agent_started to false, this is the only thing which actually makes sense to do on client disconnect. Note that since we no longer reset the vdp state on client disconnect, we must now reset it on agent disconnect even if we don't have a client. So the reds_reset_vdp call in reds_agent_remove() gets moved to the top, above both the agent_state.connected and reds->peer checks which will both fail in the no client case.
* server: Make copy paste support configurableHans de Goede2011-03-242-3/+14
| | | | | | 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.
* spice-server: Add the ability to filter agent messagesHans de Goede2011-03-244-3/+164
|
* spicec-x11: Work around a bug in xselHans de Goede2011-03-231-1/+3
| | | | | | | | | | | | | | | | | | | | Although ICCCM 2.2. Responsibilities of the Selection Owner: http://tronche.com/gui/x/icccm/sec-2.html#s-2.2 Clearly states (about selection notify events): The owner should set the specified selection, target, time, and property arguments to the values received in the SelectionRequest event. xsel sets the selection notify event target member to the incr atom when it is going to send the clipboard data incremental, rather then setting it to the UTF8_STRING atom (which was the target of the SelectionRequest). Work around this (esp as it is likely other programs may get this wrong too) and accept the incr atom as a valid target in a selection notify event. This fixes Alon's test with running: python -c "print list(range(1000))" | xsel -i -b on the client.
* spicec-x11: Don't crash on apps sending bad atoms as TARGETSHans de Goede2011-03-231-12/+16
| | | | | | | | | Some apps (bad xsel, bad!) send invalid Atoms in their TARGETS property, causing spicec to exit because of an XError. This patch makes spicec survive this scenario. For more info on the xsel bug, see: https://bugzilla.redhat.com/show_bug.cgi?id=690214
* client: Don't handle hotkeys while sticky alt is activeHans de Goede2011-03-111-4/+6
| | | | | | | | | | | | | | | | | In some cases rhev-m changes the hotkey for releasing the mouse grab to ctrl + alt. This makes it impossible to send ctrl + alt + other-key to the guest, even when using sticky alt. What happens is: -press alt until sticky alt activates -release alt (but recorded state stays pressed due to sticky alt) -press ctrl -hotkey code sees ctrl+alt pressed, releases mouse grab -mouse grab release code does an unpress all -> end of sticky state. This patch makes it possible to atleast send ctrl + alt + del (or other key) using sticky alt. Note: even with this patch it is still a bad idea to use ctrl + alt as hotkey combi.
* server/reds: allow call to reds_agent_remove even if it is goneAlon Levy2011-03-081-4/+4
| | | | | | | | | | | | | | | | | | | | | The current assert(reds->agent_state.connected) tiggers if when the agent disconnected there was still data waiting to be sent (for instance if there is a bug in the client handling clipboard and it is killed while a large clipboard transfer is in progress). So first call to reds_agent_remove happens from spice_server_char_device_remove_interface, and then it is called again (triggering the assert) from free_item_data from read_from_vdi_port because of the channel destruction. Other option would be to not call it from one of the paths - but that is suboptimal: * if there is no data in the pipe, the second call never happens. * the second call has to be there anyway, because it may fail during parsing data from the agent. This patch fixes a segfault on this assert when a client starts passing from guest agent to client a large clipboard and dies in the middle. There is still another assert happening occasionally at marshaller which I don't have a fix for (but it doesn't seem to be related).
* client/smartcard: handle the --smartcard-db optionAlon Levy2011-03-081-1/+4
|
* Release 0.8.00.8.0Hans de Goede2011-03-013-3/+10
|
* x11: Use _exit rather then exit on X errors (rhbz#680763)Hans de Goede2011-03-011-2/+2
| | | | | | | This avoids us trying to restore the original resolution when we're fullscreen and an X error happens. As restoring fullscreen is a bad idea then as this involves making more X calls, which can get us stuck (in side an XLockDisplay call for example).
* client: exit nicely for --controller with no SPICE_XPI_SOCKET (rhbz#644292)Uri Lublin2011-03-011-0/+1
| | | | | When starting spicec with --controller, SPICE_XPI_SOCKET environment variable must be defined so spicec and the controller can be connected.
* Fix keyb modifiers not syncing from client to client os (rhbz#679467)Hans de Goede2011-03-011-0/+2
|
* fix spice-server segfault on migrationGerd Hoffmann2011-02-151-0/+4
| | | | | | | spice-server tries to use the migration information without checking whenever this is available in the first place ... Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* Release 0.7.30.7.3Hans de Goede2011-02-113-2/+10
|
* Drop static_title.bmp from windows/Makefile.amHans de Goede2011-02-111-1/+0
|
* update required minimal libcacard to 0.1.2Alon Levy2011-02-101-1/+1
|
* client/smartcard: libcacard dropped ReaderAddResponseAlon Levy2011-02-102-18/+78
| | | | | | | | | | | | uses VSC_Error with code==VSC_SUCCESS instead. This means that the VSC_Error message is overloaded. Instead of the other option of adding a message id, since the connection is TCP so no messages may be dropped or reordered, by having each message followed by a response there is no ambiguity. Still this commit adds a queue for messages that we only have one of which outstanding at a time, i.e. send, wait for response, send the next, etc. This further simplifies the logic, while not adding much overhead since only when spicec starts up it has a situation where it needs to send two events (ReaderAdd and ATR for Card Insert).
* server/smartcard: don't push our own error on reader addAlon Levy2011-02-101-3/+3
| | | | | | | | | | | | | | The device already sends one. There are actually two connections going on: server to client - this is the smartcard channel, it reuses the VSC protocol. server to device - this is an internal connection using VSC too. We generally just passthrough all messages from the client to the device, and from the device to the client. We only rewrite the reader_id because the device knows about a single id (it is actually a card id), and we may manage more then one in the future. Bottom line is that there was an extra VSC_Error message reaching the client.
* client/smartcard: ignore VSC_InitAlon Levy2011-02-101-0/+2
|
* server/smartcard: ignore VSC_Init from clientAlon Levy2011-02-101-0/+3
|
* server/smartcard: print instead of assert on bad reader_id in ↵Alon Levy2011-02-101-1/+3
| | | | smartcard_char_device_on_message_from_device
* server/smartcard: libcacard uses network byte order, so we must tooAlon Levy2011-02-101-6/+19
|
* client/smartcard: s/reader_id_t/uint32_t/ (libcacard changed)Alon Levy2011-02-102-11/+11
|
* server/smartcard: libcacard removed ReaderAddResponseAlon Levy2011-02-101-42/+4
|
* server/smartcard: s/reader_id_t/uint32_t/ (libcacard changed)Alon Levy2011-02-101-6/+6
|
* server/red_worker: fix used but uninitialized warning (gcc 4.6.0)Alon Levy2011-02-071-1/+1
|
* spicec: Remove spice-client watermark (rhbz#662450)Hans de Goede2011-02-029-1060/+2
| | | | | | | | | This patch stops us from drawing the spice client watermark at the top of the virtual machine view. We have had requests through several channels to remove this as it has little added value, and is seen as annoying by some. Given that we now also have a bugzilla for this I think it is time we really remove it. (cherry picked from commit 392ed65dda1a28c85f04ebb09924c6ce83dbdf2b)
* spice-client migration: fix minor for old migration support.Uri Lublin2011-01-272-5/+5
| | | | | | | For not too old spice-migration, minor is 1. For older (ancient) spice-migration, minor is 0. Affects only VM migration while a spice client is connected.
* client/windows: don't allocate console unless requiredAlon Levy2011-01-271-9/+27
|
* client: fix broken vs2008 buildAlon Levy2011-01-272-1/+14
|
* client: --help should not need platform initializationAlon Levy2011-01-272-33/+62
| | | | | | separate initialization into before command line parsing and after, call later only if command line parsing succeeds (in particular, it "fails" if --help is given).
* demarshaller/marshaller fix gcc 4.6.0Alon Levy2011-01-272-9/+21
| | | | | | | | | | python_modules/demarshal.py and marshal.py fixes for gcc 4.6.0 warning about set but unused variables. The fixes disable creating of variables mem_size when they are not used (demarshall) and declaring a src variable when the message doesn't use it (marshal). You need to touch *.proto after applying this (should add a Makefile dependency).
* codegen: avoid creating out if not used (fix gcc 4.6.0 warning)Alon Levy2011-01-271-3/+5
|
* client: gcc 4.6.0: two more unused variable fixesAlon Levy2011-01-272-3/+0
|
* client/cegui: cegui 0.6.0 gcc 4.6.0 related fixAlon Levy2011-01-273-0/+8
| | | | | cegui doesn't include stddef required for ptrdiff_t type, we include it for it.
* client/glz_decoder.cpp: gcc 4.6.0 unused fixesAlon Levy2011-01-271-5/+0
|
* client/display_channel: gcc 4.6.0 unused fixesAlon Levy2011-01-271-6/+12
|
* common/sw_canvas: remove unused error valAlon Levy2011-01-271-2/+1
| | | | | | | | | | | This is the only unused var change I'll want to revisit eventually, I'm submitting anyway since it doesn't change current behavior. I'm talking about ignoring the return value from canvas creation. Adding a print is possible but I didn't test (may be too verbose, also preferable to be a debug print if so, and we don't have that option in the code atm - probably an environment variable will do, or adding some spice_server_set_logging_level api, maybe even spice_server_set_logging_fd?)