summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* build: depends on spice-protocol 0.9.1Marc-André Lureau2011-12-191-1/+1
|
* Support semi-seamless migrationMarc-André Lureau2011-12-194-16/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Yonit Halperin described the flow, that I followed: (1) when client_migrate_info is called SPICE_MSG_MAIN_MIGRATE_BEGIN is sent to the client. Then, the client should link to the target server (SpiceLinkMess), i.e., connect all the channels, but it shouldn't poll from the target, only from the source. You can refer to RedClient::Migrate class. The connection id in the link message should be the id of the connection to the source server. (2) The client sends to the source server SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) (3) When migration completes SPICE_MSG_MAIN_MIGRATE_(END|CANCEL) is sent to the client. (3.1) In case of SPICE_MSG_MAIN_MIGRATE_CANCEL, the client closes the connections to the target. (3.2) In case of SPICE_MSG_MAIN_MIGRATE_END, the client should reset all the data that is related to the connection to the source and complete the transition to the target server (without sending ATTACH_CHANNELS, and without guest display initialization via agent). Then, the client sends SPICE_MSG_MAIN_MIGRATE_END to the target.
* main: Handle semi-seamless MIGRATION_BEGINMarc-André Lureau2011-12-191-8/+23
|
* display: try to reuse exisiting primary surfaceMarc-André Lureau2011-12-191-23/+42
|
* Add channel_reset methodMarc-André Lureau2011-12-1910-26/+192
| | | | | This new private method is to reset the channel to its initial state, used by semi-seamless migration
* gio-coroutine: add a few more run-time checksMarc-André Lureau2011-12-191-0/+13
|
* Update protocol and messages for semi-seamless migrationMarc-André Lureau2011-12-192-3/+8
|
* windows: initialize co->ret to not randomly release fiberMarc-André Lureau2011-12-191-0/+1
|
* add explicit links against libraries that are directly usedFrédéric Péters2011-12-182-0/+8
|
* spice-channel: cleanup, remove spice_channel_send_msg()Hans de Goede2011-12-161-19/+4
| | | | | | | | | There are only 2 callers, both of which want it to do a different thing, making the callers do this directly allows us to remove spice_channel_send_msg(); and gets rid of the weirdness where we've a function which can be called in both co-routine and system context. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* spice-channel: Move read only check to spice_channel_write_msg()Hans de Goede2011-12-161-6/+6
| | | | | | | | | This is a preparation patch for removing spice_channel_send_msg(). Note that this means that buffered writes won't get checked until they are actually send by the co-routine. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* spice-channel: Move setting of header->size to spice_channel_write_msg()Hans de Goede2011-12-161-4/+2
| | | | | | Just a small cleanup patch. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* spice-channel: replace the xmit buf by a queue of SpiceOutMsg-sHans de Goede2011-12-162-73/+34
| | | | | | | | | | This has a number of advantages: -It significantly simplifies the code -It avoids memcpy-ing all the write data one more time -It avoids malloc / realloc / free of the xmit buffer (this gets replaced by gslice alloc / free for the queue elements) Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Make sure spice_channel_iterate_write() always flushes *all* pending writesHans de Goede2011-12-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This patch changes 1 line, and fixes 2 bugs in this one line: 1) We keep the xmit_buffer around for reuse (re-filling) later, so checking if we've a xmit_buffer to determine wether we should do a write is wrong, instead we should check if the xmit_buffer has data in it. 2) If the write blocks, and we switch to another co-routine context, this context may queue more writes, we check for this and throw away the buffer we've been consuming when this happens, since the other context will then have allocated a new buffer. But when this happens, we do *not* consume the new buffer. So the queued data will not get transmitted until the co-routine gets woken up by either another write, or by receiving data to read. This patch fixes this by changing the if to a while. Note that the code in question gets completely removed by the next patch in this series. As I noticed this while rewriting the code in question, still I decided to do a separate patch to fix this to: 1) Document this issue in the old code 2) Otherwise the move from the if to the while will happen in the new code which may confuse readers of that patch. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* spice_msg_out[_send_internal]: Take ownership of the passed SpiceMsgOutHans de Goede2011-12-168-28/+3
| | | | | | | | | | | | | All callers of spice_msg_out[_send_internal] unref the message immediately after calling spice_msg_out[_send_internal]. This patch changes the semantics so that spice_msg_out[_send_internal] takes ownership and it is responsible for unref-ing the passed in SpiceMsgOut. This is a preparation patch for changing the buffered write code to use a queue of SpiceMsgOut-s, rather then memcpy the message contents into an intermediate buffer. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* channel-smartcard: unref in flight messages as soon as they are sentHans de Goede2011-12-161-3/+9
| | | | | | | This is a preparation patch for making spice_msg_out_send() take ownership of the passed in msg. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* smartcard_message_complete_in_flight cleanup error checkingHans de Goede2011-12-151-4/+1
| | | | | | | smartcard_message_complete_in_flight should never get called if there is no message in flight (priv->in_flight_message != NULL). Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* spice-channel: cleanup, get rid of wait_interruptible variableHans de Goede2011-12-142-9/+1
| | | | | | | The private wait_interruptible channel variable is not used anywhere, except in one test, which is useless since it never gets set. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Disable mouse accelleration when grabbing the mouse (in server mode)Hans de Goede2011-12-141-0/+33
| | | | | | | | Otherwise accel will be applied twice, once by the client and then once more by the guest. Unfortunately there seems to be no gdk / gtk API for this so this patch uses direct libX11 calls. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* windows: fix broken left shiftMarc-André Lureau2011-12-131-0/+1
| | | | On Windows, the received key when pressing left shift is VK_SHIFT 0x10
* Wrap in window, because windows doens't receive mouse events outside itMarc-André Lureau2011-12-131-11/+15
|
* windows: clip pointer when grabbed, so it stays inside widgetMarc-André Lureau2011-12-131-1/+15
|
* Fix crash on mouse server mode grab with gtk2Marc-André Lureau2011-12-121-1/+1
| | | | | | With gtk3 gdk_cursor_unref = g_object_unref. But not with older version. Let's be consitent with the rest of the code and use cursor_unref().
* build: add missing smartcard manager in python bindingMarc-André Lureau2011-12-121-0/+2
| | | | Probably broken since the manually edited defs files have been removed
* spice-widget: rename mouse_update to update_mouse_mode.Hans de Goede2011-12-101-4/+4
| | | | | | | | | We already have update_mouse_pointer and update_mouse_grab, so having a mouse_update function without specifying what "part" of the mouse handling it exactly updates is confusing, rename it to update_mouse_mode to reflect what it does and to match the other names. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* spice-widget: cleanup mouse handling.Hans de Goede2011-12-101-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some background on this patch, we currently behave as follows in server mouse mode: 1) When spicy first connects, a frozen guest cursor is shown (no mouse events are send to the guest) and the client cursor is set to the standard right pointer, 2) When one clicks on / inside the spice-widget, the mouse is grabbed, the client cursor is hidden and the guest pointer becomes alive (gets events). 3) On ungrab we move back to state 1) Which is fine, but the code implementing it is somewhat convoluted. We have update_mouse_pointer(), which does more then just update the mouse pointer, it also calls try_mouse_grab(), and we've update_mouse_grab(), which calls update_mouse_pointer() rather then try_mouse_grab(). * I. lets look at what we currently have in update_mouse_pointer(): * case SPICE_MOUSE_MODE_SERVER: if (!d->mouse_grab_active) { if (gdk_window_get_cursor(window) != NULL) gdk_window_set_cursor(window, NULL); } else { try_mouse_grab(display); } break; Now lets invert the test to make it more readable: case SPICE_MOUSE_MODE_SERVER: if (d->mouse_grab_active) { try_mouse_grab(display); } else { if (gdk_window_get_cursor(window) != NULL) gdk_window_set_cursor(window, NULL); } break; Hmm, so if we're grabbing the mouse, we try to grab the mouse -> does not make sense, esp not since try_mouse_grab() has: if (d->mouse_grab_active) return; So we can drop the else block. But why the if? Well that would be because when we're grabbing the windows should have a blank cursor. But where does that get set? The blank cursor gets set in do_pointer_grab(), by specifying a blank cursor as the cursor to show as long as the grab is active. Since that cursor will be active as long as we're grabbing, so we can drop the if (!d->mouse_grab_active) check as well. And with the mouse_grab_active check gone, we no longer need to call update_mouse_pointer() from try_mouse_ungrab(). * II. lets look at update_mouse_grab() * So currently when the mouse should be grabbed according to the mouse-grab and disable-inputs properties, update_mouse_grab() calls update_mouse_pointer(), which as discussed above does nothing with the grab, as the code path calling try_mouse_grab() is dead code. The right thing to do would of course be to have update_mouse_grab() call try_mouse_grab() in this case. But, that would mean that as soon as the property is changed the cursor will get torn away from whereever it is and get grabbed, which may not always be desirable. To fix this this patch also moves the mouse_have_pointer and keyboard_have_focus checks from mouse_update() to try_mouse_grab() Signed-off-by: Hans de Goede <hdegoede@redhat.com> foo
* build: fix build issue because of double declarationMarc-André Lureau2011-12-091-2/+0
| | | | | | Patch based on Mageia, provided by Olav Vitters. https://bugzilla.freedesktop.org/show_bug.cgi?id=43457
* use "connection" instead of "connexion"Michael Chudobiak2011-12-091-1/+1
|
* Take the grab when mouse switching to client modeMarc-André Lureau2011-12-091-1/+11
| | | | Only when the widget has the focus and the pointer is over the widget
* Do not send ungrab key sequence to the serverMarc-André Lureau2011-12-091-11/+10
|
* Don't leak cursor shape objectsMarc-André Lureau2011-12-091-0/+20
|
* Refresh mouse shape/visibility when changing mouse modeMarc-André Lureau2011-12-091-4/+3
| | | | This fixes the dynamic mode changing when running/quitting the agent.
* Correctly hide client pointer (in server mode)Marc-André Lureau2011-12-091-2/+7
| | | | | | | | | The hide cursor event happen when the widget is not yet realized. Forcing realize may fail if the widget is not yet embedded for example. Instead, let's update the cursor whenever there is a draw(). v2: do not call gdk_window_set_cursor() with the same cursor
* Document the pointer ungrab for drag-n-drop in multiheadMarc-André Lureau2011-12-091-1/+9
|
* Draw mouse with cairo in server modeMarc-André Lureau2011-12-093-56/+88
|
* Ignore the first mouse click when taking the grabMarc-André Lureau2011-12-091-6/+10
|
* Grab on the display tooMarc-André Lureau2011-12-091-0/+10
| | | | | Without this additional grab, the pointer grab was effective for the whole application
* Add a get_blank_cursor() helperMarc-André Lureau2011-12-091-4/+9
|
* Use the border margin from recalc_geometry()Marc-André Lureau2011-12-092-8/+3
|
* Do not send pointer motion of 0x0Marc-André Lureau2011-12-091-0/+3
|
* Warn with the connect connect socket errorMarc-André Lureau2011-12-091-0/+2
|
* Fix controller with newer valaMarc-André Lureau2011-12-091-4/+4
|
* build: vapi bindings only available if HAVE_INTROSPECTIONMarc-André Lureau2011-12-051-0/+2
|
* controller: use SPICE_XPI_NAMEDPIPE firstMarc-André Lureau2011-12-051-2/+5
|
* build: do not clean spice-client-glib-2.0.depsMarc-André Lureau2011-12-021-5/+9
|
* build: fix linking with -Wl,--as-needed -Wl,--no-undefined etc..Marc-André Lureau2011-12-022-1/+2
| | | | | | | | | | | Mageia is using linker flags and miss symbols when linking. The error can be reproduced with: make LDFLAGS="-Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags" Based on patch by Christophe Fergeau. https://bugs.freedesktop.org/show_bug.cgi?id=43416
* usb-device-manager: Don't g_warning on autoconnect failureHans de Goede2011-12-021-1/+1
| | | | | | | | | We already emit a signal for this, either the app using spice-client-glib listens to this signals and does something with it, or it is not interested in this happening, at which point logging a g_warning for it is not really useful. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* spicy: Don't show an error dialog on a cancelled device openHans de Goede2011-12-021-0/+3
| | | | | | | | | | | | | If for example the user plugs in a new device, then gets the policykit agent authentication dialog and then unplugs the device, spice-gtk will cancel the acl-helper request, which in turn will dismiss the policykit agent authentication dialog. Which is all a nice and smooth user experience, except that when this happens spicy throws a dialog with an error that the open was cancelled. Since a cancel usually is done deliberately (such as on the user unpluging the device) no error dialog should be thrown for it. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* channel-usbredir: Call the acl helper without first trying to open the deviceHans de Goede2011-12-022-23/+32
| | | | | | | | | | | | | | | | | | | | | Normally opening the USB device without first calling the helper will fail, except when the process using spice-gtk is running as root. So the current code which first tries to open the USB device before calling the helper is optimizing for an exception rather then for the default code path. More over it also causes libusb to print the following errors to stderr: libusb:error [op_open] libusb couldn't open USB device /dev/bus/usb/002/017: Permission denied. libusb:error [op_open] libusb requires write access to USB device nodes. So this patch changes things to first call the helper and only then try to open the device node. This patch also modifies the helper to not call policykit when called by a root process, since the set_facl which it will do, if policykit says it is ok, is a no-op for root anyways. Instead it directly returns a success status without doing anything when called by a root process. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* string formatting fixesMarc-André Lureau2011-12-022-3/+3
| | | | | | Patch based on Mageia, provided by Olav Vitters. https://bugs.freedesktop.org/show_bug.cgi?id=43456
generated by cgit (git 2.34.1) at 2025-10-03 08:28:06 +0000