00:39 <daniels> emersion: yeah, whot's inputfd protocol was basically that - would be awesome to revive it. I suspect with some of bentiss's eBPF additions, it would be easier to deal with the main blocker of 'the compositor should only wake up when you press $vendor button rather than for every stick twitch'.

00:40 <daniels> you're absolutely right to say that the compositor does still need to listen at some level for gamepad events, but not _all_

00:41 <daniels> but having that there isn't necessary for an inputfd protocol existing

02:24 <tommybomb> I am designing my compositor to work with gamepads (and the other input methods) so I would prefer if it was supported so that everything operates in the same methodology. Perhaps I'll try to use inputfd, but if not many applications adopt it it's kind of moot

02:25 <tommybomb> Does anyone know the reason why `memset(event, 0, sizeof(*event));` is done for the input tutorial on the pointer input? https://wayland-book.com/seat/example.html

02:25 <tommybomb> Sorry, https://wayland-book.com/seat/example.html#rigging-up-pointer-events

02:26 <tommybomb> I want to know if there is a particular reason; is it safe to continue to use after teh fra

02:26 <tommybomb> ...after the frame method is used?

02:26 <tommybomb> I assume it's nothing and just house keeping.

02:28 <daniels> no, it's not safe to use after the frame event, because subsequent events may overwrite it

02:28 <daniels> if you want to use it afterwards, you should either make a copy when you receive the frame event, or use a staging area for everything before the frame event

02:29 <daniels> both have the same effect - anything before the frame event is only visible to Wayland event handlers, and anything after the frame event is only visible to the client app

02:29 <tommybomb> i'm wondering if i can just the latest values out of it like X and Y for updating a graphic on screen

02:29 <tommybomb> doesn't seem like a problem in my situation

02:34 <tommybomb> Thanks, I will play around with various setups.

11:28 <pq> tommybomb, you might not be able to see problems if you basically ignore the frame events, but it would still be not quite right. You might interpret a diagonal motion as two motions, one in x and one in y, as a simplest example.

11:30 <pq> tommybomb, this is actually recurring design pattern in Wayland, because Wayland is completely asynchronous: you collect data over several messages, and once you get the message that says "go", you know your data record is complete and can handle it. Until "go" the data is incomplete.

11:31 <pq> wl_pointer.frame, wl_surface.commit, wl_output.done, xdg_surface.configure are all examples of such "go" messages.

17:56 <tommybomb> pq, thanks! I have discovered this in practice now :)