|
> 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.
Anyway, There was a mis-understanding about dealing with EAGAIN in
wl_display_flush_clients(). All the queued events in connection.out buffer in a
wayland compositor can be flushed to clients as there will be no protocol .
By the way, trying to sending events when we meet EAGAIN error in wl_closure_send()/
wl_close_queue() will cause dropping events. Thus, it's quite intentional not to deal with
EAGAIN error in those functions.
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.
Thank you so much and we'll update if there are any valuable points.
Sung-Jin ![]() |
No File Name 0
Description: Binary data
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
