| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure we process the XFixesSetSelectionOwnerNotify event caused by
us setting the clipboard owner to none, directly after setting the owner
to none. Otherwise we may end up changing the clipboard owner to none, after
it has already been re-owned because the XFixesSetSelectionOwnerNotify event
to owner none is event is still pending when we set the new owner, and
then changes the owner back to none once processed messing up our clipboard
ownership state tracking.
I saw this happening when doing copy twice in succession inside the guest.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Request targets from new clipboard owner, rather then assuming UTF-8
(not entirely complete yet, the last pieces will be in another patch).
Atleast as important this code unifies the selection getting code
for incr and non incr getting of selection data so that it can be
used for both getting regular selection data and for getting targets
selection data.
This also fixes a big bug in the (I believe untested sofar) incr support
code which was interpreting the contents of PropertyNotify events as
XSelectionEvents rather then as XpropertyEvents which are completely
differen structs!
|
|
|
|
|
|
|
| |
Instead of keeping a flag, we can and should simply check wether the
new owner reported in the event it us or not. Also check for the
new owner being none and send a clipboard_release when that is the
case (through set_clipboard_owner(owner_none)).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given that all clipboard handling is async, it is possible to for
example receive a request for clipboard data from the agent
while the client no longer owns the clipboard (ie a
VD_AGENT_CLIPBOARD_RELEASE message is in transit to the agent).
Thus it is necessary to keep track of our notion of clipboard ownership
and check received clipboard messages (both from other apps on the client
machine and from the agent) to see if they match our notion and if not
drop, or in case were a counter message is expected nack the clipboard
message.
|
|
|
|
|
|
|
|
|
|
| |
Rename the 4 platform clipboard functions which get called
upon receival of an agent clipboard message to on_clipboard_*
The old set_clipboard_* names were confusing as they suggest being
a class property setter (like set_event_listener) rather then
event handler, and set_clipboard_owner was causing a name conflict
with the next patch in this series.
|
|
|
|
|
|
|
|
|
|
| |
This way the events will always get generated and other things
(such as clipboard ownership administration, see the next patches)
can be done in repsonse to the events, even though no message will be send.
This patch also removes the !_agent_caps check from the capability
checks, this is not needed as VD_AGENT_HAS_CAPABILITY checks _agent_caps_size
which will be 0 when _agent_caps is NULL.
|
|
|
|
|
|
|
|
|
| |
Currently we send a VD_AGENT_CLIPBOARD_RELEASE when we receive a
VD_AGENT_CLIPBOARD_REQUEST with a type which we do not support. This is not
correct, as this means given up clipboard ownership while we may be able
to answer requests with different types. The correct response is to
nack the request by sending a VD_AGENT_CLIPBOARD (data) message with a type
of VD_AGENT_CLIPBOARD_NONE.
|
|
|
|
|
|
|
| |
A clipboard owner can indicate that it can supply the data the clipboard
owns in multiple formats, so make the data passed with a
VD_AGENT_CLIPBOARD_GRAB message an array of types rather then a single
type.
|
|
|
|
|
| |
We call XFixesSelectSelectionInput with the clipboard_atom, so we musr
initialize the atoms before calling XFixesSelectSelectionInput.
|
|
|
|
|
| |
send_selection_notify used the clipboard_event, so set it before calling
send_selection_notify.
|
|
|
|
|
| |
XGetAtomName() throws X11 errors when called on a None atom, so wrap
it catching the None case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-includes most of Hans' review fixes (up to the SelectionRequest comment [4]) & X11 wips sent by Hans (10x!)
-use the VD_AGENT_CLIPBOARD_* types in the platform code
-add ifs for VD_AGENT_CAP_CLIPBOARD_BY_DEMAND in both sides
-support the GRAB/REQUEST/DATA/RELEASE verbs in both ways
-pasting clipboard data is now "only-by-demand" from both sides (client and agent), whose behavior is symmetric
-client and agent don't read or send the contents of the clipboard unnecessarily (e.g. copy, internal paste, repeating paste, focus change)
-set client as clipboard listener instead of application
-add atexit(cleanup) in win platform
linux:
-instead of clipboard atom selection instead of XA_PRIMARY
-enable USE_XRANDR_1_2 and support clipboard in MultyMonScreen
-send utf8 with no null termination, remove ++size
-add xfixes in configure.ac & Makefile.am
windows:
-bonus: support image cut & paste, currently only on windows
not done yet:
-clipboards formats are still uint32_t, not mime types stores as strings
-platform_win is still used, not the root window
-not replaced the ugly windows CF_DIB in agent/winclient
|
| |
|
| |
|
|
|
|
|
| |
This is a temporary fix as this will be fixed for real when
the cut and paste patches land.
|
|
|
|
| |
This was disabled by mistake before.
|
|
|
|
|
| |
-lrt is already included in SPICE_NONPKGCONFIG_LIBS if needed so no
need to add it to the command line manually.
|
| |
|
|
|
|
|
| |
config.h should be availible everywhere, so move its inclusion
to the top of common.h.
|
| |
|
|
|
|
| |
Seems the OSX gcc warns on saveRight not being initialzied.
|
| |
|
|
|
|
|
| |
This isn't what other apps do, and it had issues in the OSX port,
so just remove this.
|
|
|
|
|
| |
The OSX compiler warns about uninitialized variable, so we change
a bit how size is initialized.
|
| |
|
|
|
|
|
|
| |
When drawing a drawable with a NULL src bitmap that means we should
be using the previously generated self_bitmap. Not doing this causes
a segfault due to accessing the NULL.
|
|
|
|
| |
A NULL src bitmap means self_bitmap, which is not a stream, so abort.
|
|
|
|
|
|
|
| |
The self_bitmap is the size of self_bitmap_area, not the bbox.
This is especially important since we later copy the self_bitmap_area
into the new bitmap, and if that is larger than bbox then we will
overwrite random memory.
|
|
|
|
|
| |
red_put_image() needs to free the chunks for QUIC images, as we
allocate these when creating the image.
|
|
|
|
|
| |
Resetting the transform is done by setting it to the identity
transform, not passing in NULL. Passing in NULL causes a crash.
|
|
|
|
|
|
| |
We really need to flush the ring to ensure that we push something on the
release ring. If we don't do this and the ring is not pushed for other
reasons we will timeout in the guest driver waiting for the ring.
|
|
|
|
|
|
|
|
| |
We've changed how resources are released so they are now being
freed continuosly, rather than on OOM, since we want to free as early
possible to avoid fragmentation. So, OOM situations should be a bit
less common now and signify a real memory shortage, so we should try
to free up more resources.
|
|
|
|
|
| |
spice 0.4 guests pass 16bpp palette colors when running in
a 16bpp video mode. Convert them to 32bpp.
|
|
|
|
|
| |
spice 0.4 guests pass 16bpp colors for brushes when running in
a 16bpp video mode. Convert them to 32bpp.
|
|
|
|
|
| |
Pass through command flags to the qxl parser, so we can hide all
compat bits for spice 0.4 within the qxl parser.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When handling an xrandr event the event_listener->on_monitors_change()
callback destroys and re-creates the monitor object(s) which results
in the DynamicScreen or MultyMonconstructor being called, which triggers
more xrandr events. This causes a never ending event handling loop making
spicec hang, and eventually making the X-server crash as a backlog
of events builds up and it oom's.
This patches this by explictly processing the xrandr event caused
by the constructor inside the constructor surrounded by the already
present guard code against recursive xrandr events.
|
|
|
|
| |
could have caused ASSERT(!drawable->stream) in red_create_stream
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When scaling part of an image we need to specify the source
coordinates in transformed coordinates. For large magnifications this
means we will get pretty large values.
Now, if e.g. src_x * transform is larger than 32765, then the
coordinate ends up outside the pixman 16bit image size, so the
rendering will not work.
The fix is to make the src_x/y offset part of the transformation.
This means its automatically transformed by the correct scaling, and
the coordinates passed into pixman are not (typically) over 16bit.
|
|
|
|
| |
This reverts commit e13be77f33609cb3fdae354ce1f2686ae865f9e0.
|
| |
|
| |
|
|
|
|
|
|
|
| |
pipe if it depends on surfaces.
This will prevent: 1) rendering problems (commands sent to the client in the wrong order)
2) sending commands for surfaces that haven't been created yet on the client side.
|
|
|
|
|
|
|
|
|
| |
This used to be a callback for the vdi_port "data ready" interrupt,
which did indicate either data ready to read or data ready to write, but
this is no longer the case now that virtio-serial is used.
This seemingly simple fix prevents a race that needs to be fixed with
another patch, see freedesktop bz #29903
|
| |
|
|
|
|
|
|
|
|
|
| |
not empty
The vdi_port_write_timer_started flag was not being reset, which prevented
another vdi_port_write_timer_start from actually starting the timer. Fix
is to change order of lines. This happens in the callback of the timer, so
no chance of double timer set.
|
| |
|