4 ms·

> input events you're injecting will... you know... go over the Wayland socket This may be my least favorite part of the current wayland architecture. I really

> input events you're injecting will... you know... go over the Wayland socket This may be my least favorite part of the current wayland architecture. I really wish potentially high frequency input events depending on user action wouldn't be mixed up with the regular wayland events. I think it should be up to the consumer to choose how often to wake up and see if the user has done anything it cares about. Forcing the wayland socket to be activated every $MOUSE_POLLRATE is just a big waste, and it also leaves a risk if the consumer isn't fast enough for some reason because when the socket buffer it full it will be closed and the app likely crash. A better solution would have been a ringbuffer of set size, potentially with a consumer set policy of how to handle overflow. This is a lesson the telecom industry have learned a long time ago - don't mix signaling and bulk traffic.

jchw 3y ago
From what I understand, how it works in Win32 is that it is throttled based on how fast the app is reading the event loop. That is, if you get 3 or 4 mouse events while processing another mouse event, they will be "coalesced" as much as possible. And at least for the newer WM_POINTER APIs, it's possible for an app that cares enough, e.g. a digital painting app, to query for the events that have been coalesced, too. This seems OK to me and seems to cover the bases well enough. I don't think any compositor does this, but at least in theory it seems like you could do this using Wayland too, by just silently coalescing events when the client is behind on reading them. There's already a frame ID for input events, so in theory adding a protocol to go back and grab coalesced events using the frame ID seems like something you could do. I wouldn't be surprised if there's already some kind of solution like this somewhere, but at least it doesn't seem too hard to do if not. The one thing I will say is that Windows also had the concept of events having priority in addition.

jchw 3y ago

From what I understand, how it works in Win32 is that it is throttled based on how fast the app is reading the event loop. That is, if you get 3 or 4 mouse events while processing another mouse event, they will be "coalesced" as much as possible. And at least for the newer WM_POINTER APIs, it's possible for an app that cares enough, e.g. a digital painting app, to query for the events that have been coalesced, too. This seems OK to me and seems to cover the bases well enough. I don't think any compositor does this, but at least in theory it seems like you could do this using Wayland too, by just silently coalescing events when the client is behind on reading them. There's already a frame ID for input events, so in theory adding a protocol to go back and grab coalesced events using the frame ID seems like something you could do. I wouldn't be surprised if there's already some kind of solution like this somewhere, but at least it doesn't seem too hard to do if not. The one thing I will say is that Windows also had the concept of events having priority in addition.