This file was hand generated until now, resulting in the wierd situation where
it is different for spice-gtk and spice-server even though they both use the
same spice-common and spice-protocol (or at least close) versions.
This patch generates the enums.h files from spice-common. While that file is
actually in the spice-protocol submodule, it cannot be generated from
spice-protocol since it lacks access to spice.proto and spice_codegen.py. So in
affect whenvever it will differ the spice-protocol module will become dirty and
hence hopefully commited with the new enums.h.
enums.h is generated from spice.proto is a superset of that generated from spice1.proto.
Define different enums that have a SPICE_ prefix to not conflict with same
value enums from libcacard/vsccard_common.h, and continue to use the same
SPICE_MSG_SMARTCARD_DATA and SPICE_MSGC_SMARTCARD_DATA enum that is used by the
server and clients (spice-gtk, spicec) alike.
Fixes the resulting enums.h from the invocation of:
./spice_codegen.py --generate-enums spice.proto spice-protocol/spice/enums.h
Right now any enum will contain None as the enum members, with this fix
it will contain the real enum members, i.e. SPICE_FOO.
rhbz #813826, #815426
Add SPICE_MSG_DISPLAY_STREAM_DATA_SIZED, for stream_data message
that also contains the size and destination box of the data.
The server can send such messages only to clients with
SPICE_DISPLAY_CAP_SIZED_STREAM.
Empty structures are undefined in C, gcc handles them without issue
assigning a size of 0. However MSVC++ generates a hard error (C2015)
this allows messages.h to be included in c files compiled by MSVC++.
Signed-off-by: Aric Stewart <aric@codeweavers.com>
During switch-host migration, only PUBKEY verification is required.
Couldn't it just load the certificate again for the new session?
perhaps, but that's they way the code used to work until I introduced
a regression in spice commit d46f9d3f4e006d3bca9b99fac25169b17e7ac803.
The quic code has been changed recently this way:
- ASSERT(encoder->usr, line);
+ if (line == NULL) {
+ spice_warn_if_reached();
+ return QUIC_ERROR;
+ }
It appears that the only caller of quic_encode() gives a NULL line and
rely on the more_lines() callback to return new lines instead.
Adjust the code accordingly, adding a few more checks to verify the
caller gives/returns correct values.
It turned out the demarshaller wasn't allocating enough space to
memcpy the name. In order to take into account the size of a variable
array, it needs to be marked with the @end tag so that the
"extra_size" is added to the allocated memory.
It would be nice if the demarshaller would somehow fail if this wasn't
set explicitly, or do the right thing by default.
@end the name so that demarshaller
We don't want to conditionally compile the smartcard messages
depending on whether USE_SMARTCARD is set or not, we can now use
the @ifdef attribute for that.
Before this patch, if a channel is defined conditionally in spice.proto
(because it depends on external headers like the smartcard channel),
spice_codegen would write an entry to the channels array in
spice_get_*_channel_parser which would only take up a place in the array
if the ifdef condition is true, thus moving up all other intializers
one place when it is not true. This was causing issues (crashes) when building
spice-gtk with the combination of usbredir support enabled and smartcard
support disabled.
This patch fixes this by adding #else { NULL, 0 }, to the generated code.
Thanks to coolper chen <lixin.chen@saicocch.com> for reporting this!
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We want to be able to add an @ifdef annotation to optional messages
For example, we want to compile in the smartcard messages only if
libcacard is available
