| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This is not supported currently anyway and was not generated before.
|
| |
|
|
|
|
|
|
|
| |
Protocol is 0 (auto), 1 (old), or 2 (new). This is (apart from 0) the
same as the major number for the stable protocol. However, the current major
is ~(-1) to signify it being unstable, so don't use the major number as source
for setting or comparing protocol.
|
|
|
|
|
| |
* Correctly check for existing canvas 0
* Don't try to unlock the screen size if there is no active screen
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This is required to support multiple versions
|
|
|
|
|
|
|
| |
This is required because we don't want to free messages that just
refer to the unparsed message (like SpiceMsgData).
Also, in the future we might need it for more complex demarshalling.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The OpenGL renderer isn't really useful right now, its not quite up
to date, its not really faster than software and it only supports a limited
subset of drivers. So, lets disable it for now.
Long term opengl rendering of the 2d part of spice is important if we want
to combine 2d and 3d rendering (say if spice adds opengl support in the
protocol). But until then this is isn't useful for normal use.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
We move all message structs from spice-protocol to spice as
we want to be able to change these as needed internally. The
on-network format is no longer defined by these structures anyway,
but rather by the spice protocol description.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a message has been read from the network we now pass it into
the generated demarshaller for the channel. The demarshaller converts
the network data to in-memory structures that is passed on to the
spice internals.
Additionally it also:
* Converts endianness
* Validates sizes of message and any pointers in it
* Localizes offsets (converts them to pointers)
* Checks for zero offsets in messages where they are not supported
Some of this was previously done using custom code in the client, this
is now removed.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
1) add an option to determine if a bitmap can be sent lossy to the client
2) when required, replacing lossy cache items with their correspending
lossless bitmaps
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
severty -> severity
SpiceResorceID -> SpiceResourceID
SpiceResorceList -> SpiceResourceList
resorces -> resources
ped_size -> pad_size
postition -> position
|
| |
|
|
|
|
| |
This reverts commit 08927fabe57c17086fe3bce3a9ca166e2309349e.
|
| |
|
|
|
|
|
| |
The command line option is renamed from "cairo" to "sw", and
similarly all filenames and types from Cairo to Sw (and similar).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is useful because we can e.g. create pixmaps in the same format as
a window.
|
| |
|
|
|
|
|
|
|
|
| |
We need to know the format for other drawables too (like for instance
the native format of a window), so we're pushing this down.
This changes a bunch of references to be RedDrawable::, but not all.
The the old RedPixmap:: references still work, but will be phased out.
|
|
|
|
|
|
|
|
|
|
|
| |
We now support 16bit format pixmaps as well as the old ones. Including
both 555 and 565 modes.
We drop the palette argument for pixmap construction as it was only
used for black/white anyway.
Canvas creation is simplified so that there is no separate set_mode
state. Canvases are already created in the right mode and never change.
|
| |
|
|
|
|
|
|
|
|
|
| |
The current glx code is looking for a rgb32 visual and always failing
if there is none. This means not even software rendering starts up
on e.g. 16bit visuals. This commit makes it pick software fallbacks
on 16bit visuals.
Long term we need to fix the gl implementation to do 16bpp too.
|
| |
|
|
|
|
|
|
| |
The previous way XShm detection worked failed at least for me, and is
not the standard way. We now just use XShmQueryExtension and
XShmQueryVersion.
|
| |
|