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 :)