On Wed, 28 Nov 2018 09:49:54 +0900
Post by Pekka Paalanen
On Tue, 27 Nov 2018 17:59:16 +0900
Post by Derek Foreman
What if it's a frame event that gets dropped and not an input event? Or
a resource destroy?
Instead of destroying a connection, destroying a resource seems to be more
No, you cannot do that either. It too will cause the client and the
server to get out of sync, which may eventually lead to a fatal
Really, the only thing you can do is either disconnect the client or
halt its connection until it drains. Halting would require explicit
support throughout the compositor to avoid sending any events, so
disconnecting is the only thing that libwayland-server can do by itself.
Oops ! Actually I had to say "removing/re-creating resources like
wl_touch interface by updating capabilities via wl_seat capabilities
event seems better than destroying the client." As we have an
electronic whiteboard products that can be drawn with 4 pens
simultaneouly in high resolution, killing an important app that draws
trajectories of each pen may not be the best option.
That is going to be difficult as well, because to revoke a capability
you need to send an event and only then the compositor can decide to
stop sending the related input events. Sending an event will be hard
when the send buffers are already full.
It would also just remove one kind of event source from the client, but
you still have lots of other event sources that you cannot revoke this
way, and they also need to continue working. That will be very hard when
the send buffers are already full.
What you are thinking of here is just a tiny piece of the "halt the
connection" approach, and I very much doubt it alone would do any good.
Also, removing capabilities might prevent disconnects, but it will
still have the app misbehave from a user perspective, making the system
look broken in any case. I think it would be better to primarily avoid
ending up with overflowing messages, and secondary when it happens,
make it very obvious it happened so you get clear error reports, and
then recover by e.g. re-connecting if possible. I don't think papering
over the issue and obfuscating the symptoms would be a good idea.
Now we're going to do the further analysis about how many events are
coming from kernel/compositor and how fast the client can process the
Keep your messages as small as possible, and return to your main event
loop to flush and read the socket as often as possible. That's the only
general advice coming to my mind.
Everything else will be kind of case by case, e.g. you might be
able to compress pointer motion events in the compositor if the input
device is sends too many too fast. Of course, compressing motion events
means that the client no longer sees the true trajectory but some
approximation of it.
Sometimes you may have to change your protocol design. If you need to
send a lot of data in one go, consider using shared memory instead of
many and/or big messages.