| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
VDInterface has been renamed to SpiceBaseInterface. Dropped base_version
element, shlib versioning should be used instead. Dropped id element,
it is passed to spice_server_add_interface() instead. Now
SpiceBaseInterface has static information only, multiple interface
instances can share it.
Added SpiceBaseInstance struct for maintaining per-instance state
information. Adapted spice_server_{add,remove}_interface() functions
to the new world.
|
| | |
|
| |
|
|
|
|
| |
Make the timer interface largely look like the watch interface.
Simliar naming convention for the functions (timer_*) and a
opaque SpiceTimer type.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new file handle watch interface to libspice, featuring
three callbacks:
(1) watch_add() -- create a new file watch.
(2) watch_update_mask() -- change event mask. spice frequently
enables/disables write notification.
(3) watch_remove() -- remove a file watch.
libspice users must implement these functions to allow libspice
monitoring file handles.
The old interface (set_file_handlers) doesn't explicitly express the
lifecycle of a watch. Also it maps 1:1 to a qemu-internal function.
In case the way qemu implements file watches changes (someone sayed
QemuIONotifier?) this will break horribly. Beside that it is very
bad style.
Follwing patches will switch over users one by one to the new interface
and finally zap the old one.
|
| | |
|
| |
|
|
|
| |
Was used to print stuff to the qemu monitor.
Fundamentally incompatible with QMP. Remove.
|
| |
|
|
| |
old way to handle monitor, obsolete.
|
| |
|
|
|
| |
spice_server_add_interface() and spice_server_remove_interface()
can be used instead.
|
| |
|
|
|
|
|
| |
Interfaces must be registered after spice_server_init().
The "next" callback is used to discover interfaces
registered before spice_server_init(). Which is a empty
list and thus pretty pointless. Remove it.
|
| |
|
|
|
|
|
|
| |
- drop spice_channel_name_t enum, use spice-protocol defines instead.
- switch spice_server_set_channel_security() channel parameter from
enum to string.
- drop spice_server_set_default_channel_security(), use
spice_server_set_channel_security with channel == NULL instead.
|
| |
|
|
| |
First step to throw out the old interface.
|
| | |
|
| | |
|
| |
|
|
|
| |
Cyclic dependencies between surfaces mustn't occur. They can cause invalid rendering -
recent drawables might be rendered before older ones.
|
| | |
|
| |
|
|
|
|
|
| |
This patch allows people to build the spice-client on any 32bit/64bit
architecture.
by Bryan Stillwell <bryan@bokeoa.com>
|
| |
|
|
|
| |
The command line option is renamed from "cairo" to "sw", and
similarly all filenames and types from Cairo to Sw (and similar).
|
| |
|
|
|
| |
The framebuffer is not used as a source for alpha blends, so we never
need to scan it for alpha bytes.
|
| |
|
|
|
|
|
|
| |
Adds sanity check to iovec setup. In theory this should never ever
trigger. In practice guest driver bugs can make it trigger. This
patch avoids qemu burning cpu in a endless loop, instead we'll print a
message and abort. Not sure whenever there is a more graceful way to
handle the situation ...
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We just use pixman_image_t as the "information about image data" structure.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Pixman sometimes sets the ignored high byte to 0xff during alpha
blending. This is correct according to pixman specs, as the high
byte is ignored. However its not what windows expects, and it causes
unnecessary regions with non-zero high byte, causing us to
send rgba data instead of rgb which compresses worse.
So, we detect this and clear the high byte.
|
| | |
|
| | |
|
| |
|
|
|
| |
The win32 driver makes all 32bit surfaces be xRGB now, so we
can remove this old workaround.
|
| | |
|
| | |
|
| |
|
|
|
| |
If we don't then alpha is lost which is problematic if the surface
is later used as with alpha_blend and SRC_SURFACE_HAS_ALPHA.
|
| | |
|
| |
|
|
| |
This is needed since they always decode to 32bit mode.
|
| | |
|
| |
|
|
|
|
|
|
| |
Surface creation now specifies the exact format, not only the bit depth
of each surface which is used for rendering.
Additionally we now actually store the surfaces in that format, instead
of converting everything to 32bpp when drawing or e.g. handling palettes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to be able to support 16bit canvases on 32bit screens and 32bit
canvases on 16bit screens we need to handle format conversion when drawing
RedPixmaps.
The way this works now for X11 is that we only have one PIXELS_SOURCE_TYPE
for pixmaps, which always has a pixman_image_t for the data, but additionally
it has an XImage (shared mem or not) if the screen the pixmap was created
for (i.e. an explicit one or the default screen) has the same format as
the pixmap.
When we draw a pixmap on a drawable we have two variants. If the pixmap
has a XImage and it matches the format of the target drawable then we
just X(Shm)PutImage it to the drawable. If the formats differ, then we
create a temporary XImage and convert into that before drawing it to
the screen.
Right now this is a bit inefficient, because we always allocate a new
temporary image when converting. We want to add some caching here, but
at least this lets things work again.
|
| | |
|
| | |
|
| |
|
|
|
| |
This way we don't have to convert when drawing to it, or drawing it to
the dc.
|
| |
|
|
|
| |
Being copy compatible means the format are identical except
that some bits in the source may be ignored in the destination.
|
