On Wed, 28 Nov 2018 09:49:54 +0900 박성진 <[email protected]> wrote:
> > On Tue, 27 Nov 2018 17:59:16 +0900 > > 박성진 <[email protected]> wrote: > > > > Hi Derek>> On 11/22/18 11:08 PM, Jeonghyun Kang wrote: > > > > > 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 > > > reasonable. > > > 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 > > protocol error. > > > 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 > events. 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. Thanks, pq
pgp20irfmay6x.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
