05:42RAOF: Hm. Because I'm poking around in our relevant code, how is wp-fifo meant to interact with surfaces that span outputs with possibly-distinct refresh rates (and almost certainly not genlocked, even if they have the same refresh rate)?
05:44RAOF: Or perhaps it doesn't really matter.
07:48daniels: RAOF: same as pres-timing - pick one
08:30MrCooper: and same as frame events, yeah
08:31MrCooper: mutter picks one with the highest refresh rate
09:17ade: guys, is there an alternative to wlroots with good documentation?
09:17ade: cause wlroots seems to have like 0 docs
09:18ade: or something simpler than wlroots
09:18MrCooper: smithay maybe? Not sure (haven't used it myself)
09:19ade: i'd prefer c/c++ :/
09:20llyyr: ade: there's some documentation in the header files, use https://wayland.emersion.fr/wlroots/ if you want
09:21llyyr: there's also simple compositors like dwl to more complex things like sway you can look at
09:21llyyr: I don't believe any other library like it exists that has more documentation
09:22ade: yea, reading a tons of source code is the only way :/
09:24emersion: ade: what kind of documentation exactly are you missing?
09:25ade: like, how to use it?
09:25emersion: there is detailed API documentation (with missing pieces, linked above), high-level architecture (in docs/), and commented example compositor (tinywl)
09:26emersion: the best place to start is probably tinywl
09:27wlb: wayland-protocols Issue #230 opened by () New protocol for testing use cases https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/230
09:30ade: how do i extend tinywl to support server-side decorations?
09:31ade: bascially my end goal is to floating wm similar to mutter with server-side decorations
09:32ade: *to write
09:33ade: im trying to reinvent gnome with server-side decorations :p
09:38kennylevinsen: xdg_decorations + you writing code to draw the type of decorations you want
09:41ade: i've written a client which supports xdg_decorations, you define a global resource `xdg_decoration_manager` use it to get `get_toplevel_decoration`
09:42ade: i imagine it's not the same for compositor side
09:45davidre: you implement it like any other protocol in the compositor
09:45kennylevinsen: these are the helpers wlroots provides: https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master/include/wlr/types - see the wlr_xdg_decoration_v1
09:45davidre: and then you need it to somehow drag decorations
09:45davidre: *draw
09:45kennylevinsen: but you need to do all the work of actually *making* the decorations
09:46ade: i don't even know how to implement ANY protocol
09:46ade: i should probably focus on that than server-side decorations
09:48ade: also thanks again kenny
10:52emersion: jadahl: ah, you're familiar with varlink :)
10:52jadahl: a bit
10:53jadahl: not much though, just on a surface level :)
10:53jadahl: (no pun intended :P)
10:54MrCooper: casual puns are the best
11:18davidre: What is the context of the issue?
11:18davidre: Is it like "I have an app, and want to make sure it behaves correct when run in $compositor" when someone clicks on it?
11:20davidre: testing the actual compositors?
11:20davidre: Testing clicking on a button in an app?
11:25vyivel: testing apps in every compositor kinda contradicts the idea of a standardized protocol
11:26vyivel: it's for testing compositors themselves
11:59kennylevinsen: I can't help but think that a dedicated, automatable test compositor would be the solution for that...
12:01zamundaaa[m]: The use case this came up with at XDC wasn't testing applications
12:01zamundaaa[m]: But testing graphics drivers
12:06kennylevinsen: hmm not sure I understand the involvement of window management then
12:14cmeissl[m]: I am currently trying to add support for wp-commit-timing-v1 in smithay. In set_timestamp the spec mentions "If a timestamp already exists on the surface, a timestamp_exists error is generated.".
12:14cmeissl[m]: Just to make sure I get the expected commit cycle right. The timestamp is consumed on commit to generate the timer barrier for the commit. So only two calls to set_timestamp within a single commit would lead to this error?
12:16cmeissl[m]: So a client, for example a video player, could commit multiple buffers in advance
12:23daniels: yeah, though you need wp_fifo for the queue
12:24daniels: ct lets you target a commit at a particular time, fifo lets you have n>1 commits pending
12:24zamundaaa[m]: daniels: you don't need fifo for that
12:27emersion: kennylevinsen: testing WSI in userspace drivers
12:28ManMower: you don't need fifo for that, but fifo does do that. :)
12:29zamundaaa[m]: Sure, but both syncobj and commit timing also allow you to queue multiple commits
12:30ManMower: nod
12:34cmeissl[m]: <daniels> "yeah, though you need wp_fifo..." <- thanks! makes sense, I already have a mostly working impl of fifo.
12:35cmeissl[m]: another thing I am not 100% sure I got right is what exactly the timestamp targets
12:37cmeissl[m]: From reading the spec it sounds like it targets the estimated vblank timestamp. so every timestamp >= estimated vblank would be unblocked during latching the content for this retrace pahse
12:37ManMower: sounds right to me
12:52cmeissl[m]: thanks!
13:26cmeissl[m]: <zamundaaa[m]> "Sure, but both syncobj and..." <- yeah, I was hoping to replace my obscure logic in a custom gstreamer sink with commit-timing
15:14MrCooper: cmeissl[m]: timestamp <= estimated vblank timestamp, but yeah
15:26ManMower: oh yeah, I read what I want to see instead of what was written. mrcooper is obviously correct.
15:27MrCooper: some slop might be needed as well?
15:29cmeissl[m]: <MrCooper> "cmeissl: timestamp <= estimated..." <- oh yeah, that's what I meant
15:30cmeissl[m]: MrCooper: afaict the MR in mesa does that client side by subtracting 500us
15:30MrCooper: right, let's keep that client-side
15:30ManMower: yeah, client needs a little slop (500us is probably way too much)
15:31ManMower: I think 10us is probably enough to deal with the hidden rounding of times in various components
15:31cmeissl[m]: though iirc I have also seen some slop server side in jay?
15:31MrCooper: that would be bad
15:31MrCooper: slop must be handled either by the client or the compositor, not both
15:32cmeissl[m]: yeah, doing it on both sides probably will mess up
15:32ManMower: server side would violate the "not before" expectation
15:32MrCooper: indeed
15:45cmeissl[m]: can't find it, so maybe it was something else. But keeping it client side makes sense imo