On Fri, 2018-02-23 at 12:36 +0100, Christophe de Dinechin wrote:
> > On 22 Feb 2018, at 19:05, Lukáš Hrázký <lhrazky@xxxxxxxxxx> wrote:
> >
> > On Thu, 2018-02-22 at 18:51 +0100, Christophe de Dinechin wrote:
> > > > On 21 Feb 2018, at 10:45, Lukáš Hrázký <lhrazky@xxxxxxxxxx>
> > > > wrote:
> > > >
> > > > On Tue, 2018-02-20 at 16:41 +0100, Christophe de Dinechin
> > > > wrote:
> > > > > > On 20 Feb 2018, at 15:29, Lukáš Hrázký <lhrazky@xxxxxxxxxx>
> > > > > > wrote:
> > > > > >
> > > > > > On Fri, 2018-02-16 at 17:15 +0100, Christophe de Dinechin
> > > > > > wrote:
> > > > > > > From: Christophe de Dinechin <dinechin@xxxxxxxxxx>
> > > > > > >
> > > > > > > - 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 <dinechin@xxxxxxxxx
> > > > > > > m>
> > > > > > > ---
> > > > > > > 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.
I think the problem is that you have a typename Payload and a typename
PayloadArgs. But you call the concrete variable of type PayloadArgs
"payload", and you call the variable of type Payload "msg". Here's a
shortened version of your code:
template <typename Payload, typename Info>
struct Message
{
template <typename ...PayloadArgs>
Message(PayloadArgs... payload)
...
Payload msg;
};
If it was instead changed to something like this, it would be less
confusing:
template <typename Payload, typename Info>
struct Message
{
template <typename ...PayloadArgs>
Message(PayloadArgs... payload_args) // or just "args"?
...
Payload msg; // or "payload"?
};
Does that make sense? I found it a bit confusing when reading your code
as well, though I'm not sure that my confusion is the same as Lukáš's
>
> >
> > > >
> > > > > >
> > > > > > > + : 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@xxxxxxxxxxxxxxxxxxxxx
> > > > > > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > Spice-devel mailing list
> > > > Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> > > > https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel