> On 22 Feb 2018, at 19:05, Lukáš Hrázký <lhra...@redhat.com> wrote:
>
> On Thu, 2018-02-22 at 18:51 +0100, Christophe de Dinechin wrote:
>>> On 21 Feb 2018, at 10:45, Lukáš Hrázký <lhra...@redhat.com> wrote:
>>>
>>> On Tue, 2018-02-20 at 16:41 +0100, Christophe de Dinechin wrote:
>>>>> On 20 Feb 2018, at 15:29, Lukáš Hrázký <lhra...@redhat.com> wrote:
>>>>>
>>>>> On Fri, 2018-02-16 at 17:15 +0100, Christophe de Dinechin wrote:
>>>>>> From: Christophe de Dinechin <dinec...@redhat.com>
>>>>>>
>>>>>> - The Stream class now deals with locking and sending messages
>>>>>> - The Message<> template class deals with the general writing mechanisms
>>>>>> - Three classes, FormatMessage, FrameMessage and X11CursorMessage
>>>>>> represent individual messages
>>>>>>
>>>>>> The various classes should be moved to separate headers in a subsequent
>>>>>> operation
>>>>>>
>>>>>> The design uses templates to avoid any runtime overhead. All the calls
>>>>>> are static.
>>>>>
>>>>> All in all, a nice way to encapsulate the sending of messages. What I
>>>>> worked on, actually, was the receiving of messages, as that is actually
>>>>> more important for separating the code (as seen later in the problem
>>>>> you had with client_codecs and streaming_requested static variables).
>>>>>
>>>>> I am now wondering how to merge it with your changes and whether the
>>>>> same Message class hierarchy could be used (without making a mess out
>>>>> of it). We should discuss it later.
>>>>
>>>> Do you have your WIP stuff in a private branch I could look at? Maybe I
>>>> can help with the rebasing.
>>>
>>> I'll push it somewhere so you can have a look, but I can manage the
>>> rebase myself :) It would still be an effort to find out what you did
>>> during the rebase.
>>>
>>>> I would probably keep input and output messages in separate classes. I
>>>> can’t see much commonality between the two. Using the same CRTP for input
>>>> messages, and maybe rename Message as OutputMessage…
>>>
>>> Agreed, probably...
>>>
>>>>>
>>>>>> Signed-off-by: Christophe de Dinechin <dinec...@redhat.com>
>>>>>> ---
>>>>>> src/spice-streaming-agent.cpp | 250
>>>>>> ++++++++++++++++++++----------------------
>>>>>> 1 file changed, 117 insertions(+), 133 deletions(-)
>>>>>>
>>>>>> diff --git a/src/spice-streaming-agent.cpp
>>>>>> b/src/spice-streaming-agent.cpp
>>>>>> index a989ee7..c174ea4 100644
>>>>>> --- a/src/spice-streaming-agent.cpp
>>>>>> +++ b/src/spice-streaming-agent.cpp
>>>>>> @@ -48,24 +48,6 @@ namespace spice
>>>>>> namespace streaming_agent
>>>>>> {
>>>>>>
>>>>>> -struct FormatMessage
>>>>>> -{
>>>>>> - StreamDevHeader hdr;
>>>>>> - StreamMsgFormat msg;
>>>>>> -};
>>>>>> -
>>>>>> -struct DataMessage
>>>>>> -{
>>>>>> - StreamDevHeader hdr;
>>>>>> - StreamMsgData msg;
>>>>>> -};
>>>>>> -
>>>>>> -struct CursorMessage
>>>>>> -{
>>>>>> - StreamDevHeader hdr;
>>>>>> - StreamMsgCursorSet msg;
>>>>>> -};
>>>>>> -
>>>>>> class Stream
>>>>>> {
>>>>>> public:
>>>>>> @@ -79,24 +61,131 @@ public:
>>>>>> {
>>>>>> close(streamfd);
>>>>>> }
>>>>>> - operator int() { return streamfd; }
>>>>>>
>>>>>> int have_something_to_read(int timeout);
>>>>>> int read_command_from_device(void);
>>>>>> int read_command(bool blocking);
>>>>>>
>>>>>> +
>>>>>> + template <typename Message, typename ...PayloadArgs>
>>>>>> + bool send(PayloadArgs... payload)
>>>>>> + {
>>>>>> + Message message(payload...);
>>>>>> + std::lock_guard<std::mutex> stream_guard(mutex);
>>>>>> + size_t expected = message.size(payload...);
>>>>>> + size_t written = message.write(*this, payload...);
>>>>>> + return written == expected;
>>>>>> + }
>>>>>
>>>>> Do you purposefully avoid throwing exceptions here, returning a bool?
>>>>
>>>> You really love exceptions, don’t you ;-)
>>>
>>> Well... I don't always get errors, but when I do, I use exceptions to
>>> handle them. :D
>>>
>>> Really, that's what it is. Error = exception.
>>
>> No. C++CG E2 "Throw an exception to signal that a function can't perform its
>> assigned task”.
>>
>> Examples of errors that are not exceptions: FP NaN and infinities, compiler
>> errors (and more generally parsing errors), etc. A parser error is not an
>> exception because it’s the job of the parser to detect the error…
>>
>> I could also give examples of exceptions that are not errors, though it’s
>> more subtle and OT. Consider a C++ equivalent of an interrupted system call.
>> Also, is bad_alloc an “error" or a limitation? (one could argue that the
>> error would be e.g. to give you some memory belonging to someone else ;-)
>
> If you put it this way, sure.
>
>>> That's what they teach
>>> you at the uni and what we've always done at my previous job. It's the
>>> language's designated mechanism to deal with errors, standard library
>>> uses them, ...
>>>
>>> You brought new light into the topic for me, but I still don't know how
>>> to deal with it... Though the fact that you are the author of the
>>> exception handling implementation and you are reluctant to use the
>>> exception really speaks volumes :)
>>>
>>>> I usually reserve exceptions for cases which are truly “catastrophic”,
>>>> i.e. going the long way and unwindig is the right way to do it. Unwinding
>>>> the stack is a very messy business, takes a lot of time, and if you can
>>>> just return, it’s about one and a half gazillion times faster, generates
>>>> smaller code, etc etc.
>>>>
>>>> In this specific case, though, I think that unwinding could be seen as
>>>> appropriate, since ATM we have nothing better than error + abort when it
>>>> happens. Plus this might avoid a scenario where you could write twice if
>>>> the first write fails. So I’m sold, I think this is the right thing to do.
>>>>
>>>>> The error and exception could actually be checked as low as at the end
>>>>> of the write_all() method, avoiding all the latter size returning and
>>>>> checking?
>>>>>
>>>>>> +
>>>>>> size_t write_all(const void *buf, const size_t len);
>>>>>> - int send_format(unsigned w, unsigned h, uint8_t c);
>>>>>> - int send_frame(const void *buf, const unsigned size);
>>>>>> - void send_cursor(uint16_t width, uint16_t height,
>>>>>> - uint16_t hotspot_x, uint16_t hotspot_y,
>>>>>> - std::function<void(uint32_t *)> fill_cursor);
>>>>>>
>>>>>> private:
>>>>>> int streamfd = -1;
>>>>>> std::mutex mutex;
>>>>>> };
>>>>>>
>>>>>> +
>>>>>> +template <typename Payload, typename Info>
>>>>>
>>>>> "Info" is quite an unimaginative name :) I understand it's the message
>>>>> itself here and also find it curiously hard to come up with something
>>>>> better :) "TheMessage" not very good, is it? Still better than "Info"?
>>>>> Maybe a comment referencing the CRTP to help readers understand?
>>>>
>>>> I used ‘Info’ here because that’s the information about the message.
>>>
>>> I kind of understood that, but still... very vague for me…
>>
>> Will stay that way for the moment, unless you give me a really better name,
>> sorry.
>>
>>>
>>>> I can add the CRTP comment, could not remember the acronym when I wrote
>>>> the class ;-)
>>>>
>>>>>
>>>>>> +struct Message
>>>>>
>>>>> Any reason to not stick with the "class" keyword instead of "struct”?
>>>>
>>>> Not really, more a matter of habit, using struct when it’s really about
>>>> data and everything is public. But there, “Message” evolved far away from
>>>> POD to warrant using ‘class’.
>>>
>>> I do like to take the shortcut using struct to spare myself the 'public:'
>>> line at the top, but I'd think it would be considered an inconsistency by
>>> others... :)
>>
>> That’s not the reason. I tend to use it to mark a struct as “mostly data”,
>> even if it has C++isms in it. Here, I initially saw the message is mostly
>> data, i.e. I would not have minded the data members being public. But that’s
>> no longer the case. Will change it.
>>
>>>
>>>>>
>>>>>> +{
>>>>>> + template <typename ...PayloadArgs>
>>>>>> + Message(PayloadArgs... payload)
>>>>>
>>>>> "PayloadArgs... payload_args", we have something called "Payload" here
>>>>> too, getting a bit confusing.
>>>>
>>>> But that’s the same thing. Payload is initialized with PayloadArgs, so it
>>>> makes sense.
>>>>
>>>> Initially, I had “PayloadConstructorArgs”, but then I started using it
>>>> outside of the ctor.
>>>
>>> I don't think it's the same, here Payload is the message class and
>>> PayloadArgs is the content/args. So naming the objects accordingly IMO
>>> helps clarity.
>>
>> The Payload is defined from the PayloadArgs, i.e. its constructor is
>> Payload(PayloadArgs…). What is the problem with that?
>
> The problem is Payload(PayloadArgs... payload).
What is the problem with initializing something called a payload with something
called payload args?
I’m sorry for being dense here, but I really don’t get your objection.
>
>>>
>>>>>
>>>>>> + : hdr(StreamDevHeader {
>>>>>> + .protocol_version = STREAM_DEVICE_PROTOCOL,
>>>>>> + .padding = 0, // Workaround GCC bug "sorry: not
>>>>>> implemented"
>>>>>> + .type = Info::type,
>>>>>> + .size = (uint32_t) (Info::size(payload...) - sizeof(hdr))
>>>>>> + }),
>>>>>> + msg(Info::make(payload...))
>>>>>> + { }
>>>>>
>>>>> I find it redundant that you pass the "payload..." (the args :)) to
>>>>> Info::size() and Info::make() here and then also to Info::write() in
>>>>> Stream::send().
>>>>
>>>> I’m not sure “redundant” is the correct word. I could stash the
>>>> information in Message, but then the compiler would have a much harder
>>>> time inlining the actual expression, which is always very simple.
>>>> Unfortunately, we have three different expressions that take different
>>>> input, hence the CRTP and the passing of arguments.
>>>>
>>>>
>>>>> In the three messages below, you also showcase three
>>>>> distinct ways of serializing them, caused by this redundancy (I
>>>>> understand it is partially given by the payload of the messages).
>>>>
>>>> It is *entirely* given by the payload, which I assume is a given, since
>>>> it’s in the protocol. What else could come into play?
>>>
>>> What I mean is that the place you create the data for serialization is
>>> only partially given by the payload. Because for example with the
>>> FormatMessage, you place the data in the class as a member, but you
>>> could have also created them on the stack at the beginning of the
>>> write() method. And unless I'm missing something, you could do it this
>>> way for all the cases, therefore unify the approach. For the
>>> FrameMessage, you are constructing an empty msg member…
>>
>> I tell you that I don’t want to copy, say, 70K of frame data if I can avoid
>> it, and you are suggesting I allocate 70K of stack instead? I think you did
>> miss something, yes.
>
> No, I am not telling you that.
Then, I have not understood what you mean. What do you mean with “created them
on the stack at the beginning of the write function”? What is “them”? The
format message?
Is your suggestion that FormatMessage could be split in two writes like the
others, and that this would make the code more generic (if a tiny bit less
efficient for that specific message)? If that’s what you are saying, then the
problem is that the second part is distinct in all three cases anyway, so I’m
not getting anything out of this, but I’m making the FormatMessage case less
efficient…
Sorry, I read and re-read your explanations, I’m afraid I still don’t get it.
Maybe with a code outline?
>
>> (if that clarifies, that frame is given to me by the capture, I did not ask
>> the capture to use some buffer I pre-allocated)
>>
>>>
>>>>>
>>>>> See comments under each class, which all relate to this (hope it's not
>>>>> too confusing).
>>>>>
>>>>>> +
>>>>>> + StreamDevHeader hdr;
>>>>>> + Payload msg;
>>>>>> +};
>>>>>> +
>>>>>> +
>>>>>> +struct FormatMessage : Message<StreamMsgFormat, FormatMessage>
>>>>>> +{
>>>>>> + FormatMessage(unsigned w, unsigned h, uint8_t c) : Message(w, h, c)
>>>>>> {}
>>>>>> + static const StreamMsgType type = STREAM_TYPE_FORMAT;
>>>>>
>>>>> Could the type actually be part of the template? As in:
>>>>> struct FormatMessage : Message<STREAM_TYPE_FORMAT, StreamMsgFormat,
>>>>> FormatMessage>
>>>>
>>>> Sure, but I find it more consistent the way I wrote it. Also easier to
>>>> read, because you have “type = TYPE” instead of just <TYPE>, but that’s
>>>> really a personal preference.
>>>>
>>>>>
>>>>>> + static size_t size(unsigned width, unsigned height, uint8_t codec)
>>>>>> + {
>>>>>> + return sizeof(FormatMessage);
>>>>>> + }
>>>>>> + static StreamMsgFormat make(unsigned w, unsigned h, uint8_t c)
>>>>>> + {
>>>>>> + return StreamMsgFormat{ .width = w, .height = h, .codec = c,
>>>>>> .padding1 = {} };
>>>>>> + }
>>>>>> + size_t write(Stream &stream, unsigned w, unsigned h, uint8_t c)
>>>>>> + {
>>>>>> + return stream.write_all(this, sizeof(*this));
>>>>>> + }
>>>>>> +};
>>>>>
>>>>> This message has static size, so you construct it in make() and then
>>>>> write this whole object.
>>>>
>>>> The message body has static size, yes. (Header is fixed size in all three
>>>> cases).
>>>>
>>>>>
>>>>>> +
>>>>>> +
>>>>>> +struct FrameMessage : Message<StreamMsgData, FrameMessage>
>>>>>> +{
>>>>>> + FrameMessage(const void *frame, size_t length) : Message(frame,
>>>>>> length) {}
>>>>>> + static const StreamMsgType type = STREAM_TYPE_DATA;
>>>>>> + static size_t size(const void *frame, size_t length)
>>>>>> + {
>>>>>> + return sizeof(FrameMessage) + length;
>>>>>> + }
>>>>>> + static StreamMsgData make(const void *frame, size_t length)
>>>>>> + {
>>>>>> + return StreamMsgData();
>>>>>> + }
>>>>>> + size_t write(Stream &stream, const void *frame, size_t length)
>>>>>> + {
>>>>>> + return stream.write_all(&hdr, sizeof(hdr)) +
>>>>>> stream.write_all(frame, length);
>>>>>> + }
>>>>>> +};
>>>>>
>>>>> Here the message is actually only the frame data and so you construct
>>>>> an empty message in make(). In write() you just write the stream data
>>>>> passed to it.
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>>> +
>>>>>> +struct X11CursorMessage : Message<StreamMsgCursorSet, X11CursorMessage>
>>>>>> +{
>>>>>> + X11CursorMessage(XFixesCursorImage *cursor)
>>>>>> + : Message(cursor),
>>>>>> + pixels(new uint32_t[pixel_size(cursor)])
>>>>>> + {
>>>>>> + fill_pixels(cursor);
>>>>>> + }
>>>>>> + static const StreamMsgType type = STREAM_TYPE_CURSOR_SET;
>>>>>> + static size_t pixel_size(XFixesCursorImage *cursor)
>>>>>> + {
>>>>>> + return cursor->width * cursor->height;
>>>>>> + }
>>>>>> + static size_t size(XFixesCursorImage *cursor)
>>>>>> + {
>>>>>> + return sizeof(X11CursorMessage) + sizeof(uint32_t) *
>>>>>> pixel_size(cursor);
>>>>>> + }
>>>>>> + static StreamMsgCursorSet make(XFixesCursorImage *cursor)
>>>>>> + {
>>>>>> + return StreamMsgCursorSet
>>>>>> + {
>>>>>> + .width = cursor->width,
>>>>>> + .height = cursor->height,
>>>>>> + .hot_spot_x = cursor->xhot,
>>>>>> + .hot_spot_y = cursor->yhot,
>>>>>> + .type = SPICE_CURSOR_TYPE_ALPHA,
>>>>>> + .padding1 = { },
>>>>>> + .data = { }
>>>>>> + };
>>>>>> + }
>>>>>> + size_t write(Stream &stream, XFixesCursorImage *cursor)
>>>>>> + {
>>>>>> + return stream.write_all(&hdr, sizeof(hdr)) +
>>>>>> stream.write_all(pixels.get(), hdr.size);
>>>>>
>>>>> You are not writing the msg data here, might be the reson for the
>>>>> missing cursor.
>>>>
>>>> Ah, good catch. I thought of not writing *this because of the extra pixels
>>>> field, but then wrote the wrong class.
>>>>
>>>>>
>>>>>> + }
>>>>>> + void fill_pixels(XFixesCursorImage *cursor)
>>>>>> + {
>>>>>> + uint32_t *pixbuf = pixels.get();
>>>>>> + unsigned count = cursor->width * cursor->height;
>>>>>> + for (unsigned i = 0; i < count; ++i)
>>>>>> + pixbuf[i] = cursor->pixels[i];
>>>>>> + }
>>>>>> +private:
>>>>>> + std::unique_ptr<uint32_t[]> pixels;
>>>>>> +};
>>>>>
>>>>> (note in this class some methods could be private and some arguments
>>>>> const)
>>>>
>>>> Yes. Good idea.
>>>>
>>>>>
>>>>> Here you add a private member pixels, which you fill in constructor. In
>>>>> make(), you create the static part of the message. In write(), you
>>>>> write them.
>>>>>
>>>>> So, I ask, could you not actually construct all the data to write in
>>>>> write(), and perhaps even remove the Message::msg member and the make()
>>>>> method?
>>>>
>>>> Yes, but that would require to copy the frames data, which I considered an
>>>> expensive-enough operation to try and avoid it. For cursor pixels, it’s
>>>> less of an issue a) because we need to copy anyway, due to format
>>>> conversion, and they happen much less frequently.
>>>
>>> I don't think you would need to copy the data? What I propose actually
>>> doesn't mean any change for this method in particular?
>>>
>>>>>
>>>>> That would make the classes a bit simpler?
>>>>
>>>> Simpler, yes but much less efficient in the important case, which is
>>>> sending frames, where it would add one malloc / copy / free for each
>>>> frame, which the present code avoids at the “mere” cost of passing the
>>>> payload args around ;-)
>>>>
>>>>
>>>> Thanks a lot.
>>>>
>>>>>
>>>>> Cheers,
>>>>> Lukas
>>>>>
>>>>>> +
>>>>>> }} // namespace spice::streaming_agent
>>>>>>
>>>>>>
>>>>>> @@ -201,66 +290,6 @@ size_t Stream::write_all(const void *buf, const
>>>>>> size_t len)
>>>>>> return written;
>>>>>> }
>>>>>>
>>>>>> -int Stream::send_format(unsigned w, unsigned h, uint8_t c)
>>>>>> -{
>>>>>> - const size_t msgsize = sizeof(FormatMessage);
>>>>>> - const size_t hdrsize = sizeof(StreamDevHeader);
>>>>>> - FormatMessage msg = {
>>>>>> - .hdr = {
>>>>>> - .protocol_version = STREAM_DEVICE_PROTOCOL,
>>>>>> - .padding = 0, // Workaround GCC "not implemented" bug
>>>>>> - .type = STREAM_TYPE_FORMAT,
>>>>>> - .size = msgsize - hdrsize
>>>>>> - },
>>>>>> - .msg = {
>>>>>> - .width = w,
>>>>>> - .height = h,
>>>>>> - .codec = c,
>>>>>> - .padding1 = { }
>>>>>> - }
>>>>>> - };
>>>>>> - syslog(LOG_DEBUG, "writing format\n");
>>>>>> - std::lock_guard<std::mutex> stream_guard(mutex);
>>>>>> - if (write_all(&msg, msgsize) != msgsize) {
>>>>>> - return EXIT_FAILURE;
>>>>>> - }
>>>>>> - return EXIT_SUCCESS;
>>>>>> -}
>>>>>> -
>>>>>> -int Stream::send_frame(const void *buf, const unsigned size)
>>>>>> -{
>>>>>> - ssize_t n;
>>>>>> - const size_t msgsize = sizeof(FormatMessage);
>>>>>> - DataMessage msg = {
>>>>>> - .hdr = {
>>>>>> - .protocol_version = STREAM_DEVICE_PROTOCOL,
>>>>>> - .padding = 0, // Workaround GCC "not implemented" bug
>>>>>> - .type = STREAM_TYPE_DATA,
>>>>>> - .size = size /* includes only the body? */
>>>>>> - },
>>>>>> - .msg = {}
>>>>>> - };
>>>>>> -
>>>>>> - std::lock_guard<std::mutex> stream_guard(mutex);
>>>>>> - n = write_all(&msg, msgsize);
>>>>>> - syslog(LOG_DEBUG,
>>>>>> - "wrote %ld bytes of header of data msg with frame of size %u
>>>>>> bytes\n",
>>>>>> - n, msg.hdr.size);
>>>>>> - if (n != msgsize) {
>>>>>> - syslog(LOG_WARNING, "write_all header: wrote %ld expected
>>>>>> %lu\n",
>>>>>> - n, msgsize);
>>>>>> - return EXIT_FAILURE;
>>>>>> - }
>>>>>> - n = write_all(buf, size);
>>>>>> - syslog(LOG_DEBUG, "wrote data msg body of size %ld\n", n);
>>>>>> - if (n != size) {
>>>>>> - syslog(LOG_WARNING, "write_all header: wrote %ld expected %u\n",
>>>>>> - n, size);
>>>>>> - return EXIT_FAILURE;
>>>>>> - }
>>>>>> - return EXIT_SUCCESS;
>>>>>> -}
>>>>>> -
>>>>>> /* returns current time in micro-seconds */
>>>>>> static uint64_t get_time(void)
>>>>>> {
>>>>>> @@ -304,47 +333,6 @@ static void usage(const char *progname)
>>>>>> exit(1);
>>>>>> }
>>>>>>
>>>>>> -void
>>>>>> -Stream::send_cursor(uint16_t width, uint16_t height,
>>>>>> - uint16_t hotspot_x, uint16_t hotspot_y,
>>>>>> - std::function<void(uint32_t *)> fill_cursor)
>>>>>> -{
>>>>>> - if (width >= STREAM_MSG_CURSOR_SET_MAX_WIDTH ||
>>>>>> - height >= STREAM_MSG_CURSOR_SET_MAX_HEIGHT)
>>>>>> - return;
>>>>>> -
>>>>>> - const uint32_t cursor_msgsize =
>>>>>> - sizeof(CursorMessage) + width * height * sizeof(uint32_t);
>>>>>> - const uint32_t hdrsize = sizeof(StreamDevHeader);
>>>>>> -
>>>>>> - std::unique_ptr<uint8_t[]> storage(new uint8_t[cursor_msgsize]);
>>>>>> -
>>>>>> - CursorMessage *cursor_msg =
>>>>>> - new(storage.get()) CursorMessage {
>>>>>> - .hdr = {
>>>>>> - .protocol_version = STREAM_DEVICE_PROTOCOL,
>>>>>> - .padding = 0, // Workaround GCC internal / not
>>>>>> implemented compiler error
>>>>>> - .type = STREAM_TYPE_CURSOR_SET,
>>>>>> - .size = cursor_msgsize - hdrsize
>>>>>> - },
>>>>>> - .msg = {
>>>>>> - .width = width,
>>>>>> - .height = height,
>>>>>> - .hot_spot_x = hotspot_x,
>>>>>> - .hot_spot_y = hotspot_y,
>>>>>> - .type = SPICE_CURSOR_TYPE_ALPHA,
>>>>>> - .padding1 = { },
>>>>>> - .data = { }
>>>>>> - }
>>>>>> - };
>>>>>> -
>>>>>> - uint32_t *pixels = reinterpret_cast<uint32_t
>>>>>> *>(cursor_msg->msg.data);
>>>>>> - fill_cursor(pixels);
>>>>>> -
>>>>>> - std::lock_guard<std::mutex> stream_guard(mutex);
>>>>>> - write_all(storage.get(), cursor_msgsize);
>>>>>> -}
>>>>>> -
>>>>>> static void cursor_changes(Stream *stream, Display *display, int
>>>>>> event_base)
>>>>>> {
>>>>>> unsigned long last_serial = 0;
>>>>>> @@ -363,12 +351,8 @@ static void cursor_changes(Stream *stream, Display
>>>>>> *display, int event_base)
>>>>>> continue;
>>>>>>
>>>>>> last_serial = cursor->cursor_serial;
>>>>>> - auto fill_cursor = [cursor](uint32_t *pixels) {
>>>>>> - for (unsigned i = 0; i < cursor->width * cursor->height;
>>>>>> ++i)
>>>>>> - pixels[i] = cursor->pixels[i];
>>>>>> - };
>>>>>> - stream->send_cursor(cursor->width, cursor->height,
>>>>>> - cursor->xhot, cursor->yhot, fill_cursor);
>>>>>> + if (!stream->send<X11CursorMessage>(cursor))
>>>>>> + syslog(LOG_WARNING, "FAILED to send cursor\n");
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> @@ -422,7 +406,7 @@ do_capture(Stream &stream, const char *streamport,
>>>>>> FILE *f_log)
>>>>>>
>>>>>> syslog(LOG_DEBUG, "wXh %uX%u codec=%u\n", width, height,
>>>>>> codec);
>>>>>>
>>>>>> - if (stream.send_format(width, height, codec) ==
>>>>>> EXIT_FAILURE)
>>>>>> + if (!stream.send<FormatMessage>(width, height, codec))
>>>>>> throw std::runtime_error("FAILED to send format
>>>>>> message");
>>>>>> }
>>>>>> if (f_log) {
>>>>>> @@ -434,7 +418,7 @@ do_capture(Stream &stream, const char *streamport,
>>>>>> FILE *f_log)
>>>>>> hexdump(frame.buffer, frame.buffer_size, f_log);
>>>>>> }
>>>>>> }
>>>>>> - if (stream.send_frame(frame.buffer, frame.buffer_size) ==
>>>>>> EXIT_FAILURE) {
>>>>>> + if (!stream.send<FrameMessage>(frame.buffer,
>>>>>> frame.buffer_size)) {
>>>>>> syslog(LOG_ERR, "FAILED to send a frame\n");
>>>>>> break;
>>>>>> }
>>>>>
>>>>> _______________________________________________
>>>>> Spice-devel mailing list
>>>>> Spice-devel@lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Spice-devel mailing list
>>> Spice-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
