09:09 emersion: daniels, can i add your ack for https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/194 ?
09:16 daniels: emersion: I’m sad the event is gone, but yeah Ab - let’s see what it’s like in the real world and if we really need it then we can add it in v2
09:16 any1: I wonder how long it will take for cursor-shape to be adopted by gtk and qt
09:18 any1: This is how it should have been done from the start. ;)
09:30 d_ed[m]: merge requests for Qt will be up soonish
09:35 d_ed[m]: what clients are written with Smithay?
09:37 zzag: It was mentioned that it's used by winit, so I believe alacritty and things as such will use it
09:37 emersion: alacritty
09:50 wlb: wayland/main: Simon Ser * util: simplify wl_fixed_to_double() https://gitlab.freedesktop.org/wayland/wayland/commit/0e0ae7e290f2 src/wayland-util.h
09:50 wlb: wayland Merge request !314 merged \o/ (util: simplify wl_fixed_to_double() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/314)
09:56 wlb: wayland/main: Simon Ser * server: stop wl_display_run() on dispatch error https://gitlab.freedesktop.org/wayland/wayland/commit/8f2a33cffcdf src/wayland-server.c
09:56 wlb: wayland Merge request !310 merged \o/ (server: stop wl_display_run() on dispatch error https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/310)
09:57 wlb: wayland Merge request !293 closed (releasing: update and convert to Markdown)
09:59 wlb: wayland/main: Simon Ser * build: override wayland-scanner dep https://gitlab.freedesktop.org/wayland/wayland/commit/2aec19ce41bb src/meson.build
09:59 wlb: wayland Merge request !313 merged \o/ (build: override wayland-scanner dep https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/313)
10:00 wlb: wayland-protocols Merge request !210 opened by Simon Ser (emersion) tablet-v2: fix typo in set_cursor serial description https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/210 [tablet]
10:05 wlb: wayland Merge request !315 opened by Simon Ser (emersion) protocol: refer to wl_surface.offset in set_cursor https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/315
11:25 wlb: wayland-protocols/main: Simon Ser * tablet-v2: fix typo in set_cursor serial description https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/18aa7b27f7ef unstable/tablet/tablet-unstable-v2.xml
11:25 wlb: wayland-protocols Merge request !210 merged \o/ (tablet-v2: fix typo in set_cursor serial description https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/210)
11:58 zzag: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90#note_1112190 can somebody explain what you mean by "user memory fence" in that discussion? is it a special kind of a fence?
11:58 emersion: yeah
11:58 emersion: right now fences are managed by the kernel
11:59 emersion: e.g. to signal a fence, one needs to context-switch to the kernel
11:59 emersion: same for waiting
11:59 emersion: or querying
11:59 emersion: with UMF you can do these things from user-space
12:00 emersion: i'd recomment just going forward with drm_syncobj
12:01 emersion: the UMF stuff has been stuck for a very long time and no indication of it getting unstuck
12:01 emersion: recommend*
12:02 zzag: is it attached to the graphics memory somehow? or its the only crucial point is that you can signal/wait for it in the user space without context switching?
12:02 zzag: I'm confused by "user memory" in the name
12:03 emersion: "user" as in user-space
12:03 emersion: i'm not sure how it works exactly
12:03 emersion: maybe gfxstrand can provide more details
12:05 emersion: by any chance does anybody know what formats PIXMAN_yuy2 and PIXMAN_yv12 are?
12:06 emersion: nothing in the git log, the access functions are just an unreadable mess
12:07 pq: I don't know those two.
12:08 pq: Try fishing on #xorg-devel or the Cairo channel where ever that is?
12:10 emersion: good idea
12:10 emersion: cairo doesn't use these though
12:11 pq: no, but in the freenode days pixman people were on the cairo channel if anywhere
12:13 wlb: wayland Merge request !316 opened by Sebastian Wick (swick) protocol: specify the exact form of premultiplication https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/316
12:24 mceier: emersion: kernel documentation mentions yuy2 and yv12: https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-yuv-planar.html?highlight=yv12#id23 and https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-packed-yuv.html?highlight=yuy2#id1 I would assume PIXMAN_yuy2 and PIXMAN_yv12 refer to them.
12:24 pq: pixman predates drm_fourcc though, depends on when they were added
12:25 pq: pixman uses machine-endian formats while drm_fourcc uses little-endian definitions, so at least that is different
12:26 pq: oh, that's v4l, not drm_fourcc
12:26 pq: no idea about v4l
14:20 any1: I think yuy2 is another name for yuyv, which is single plane interleaved 422
14:28 emersion: someone linked to https://learn.microsoft.com/en-us/windows-hardware/drivers/display/4-2-0-video-pixel-formats
15:43 emersion: pq, how do you plan to represent the TFs in Weston, if you don't use an enum?
15:44 emersion: just raw integers?
17:05 JoshuaAshton: daniels: If I have QueuePresent in Wayland with FIFO right now and a present that takes longer than my refresh rate (ie. spans multiple frame callbacks), what prevents it from being overriden by another QueuePresent that took much less time directly after?
17:05 JoshuaAshton: Seems like this is broken in practice too fwiw
17:06 JoshuaAshton: As the QueuePresent blocking for frame event bodge in Mesa doesn't actually mean that the compositor is going to present with the buffer we submitted on the CPU side as it may not be done on the GPU side.
17:09 JoshuaAshton: I was speaking to emersion and maybe we should use presentation-time for FIFO? What is preventing that?
17:09 emersion: daniels: i just realized we might be able to use this to address the vulkan presentation thread issue? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26
17:10 JoshuaAshton: The alternative is that on our side we only send the frame callback once we get a new buffer from the client rather than unconditionally on every refresh cycle
17:10 emersion: we need to send wl_surface.commit immediately when presenting, but this proto would let us lock it, and unlock it later on in a separate thread
17:11 emersion: jadahl: btw any news on that protocol?
17:14 jadahl: emersion: it got refresh in my head not long ago, need to addres MrCooper's raised issues which kind of defines a "transaction" that covers both subsurfaces wp_transaction and the buffer-readiness stuff
17:14 jadahl: what is the presentation thread issue?
17:16 emersion: jadahl: mesa cannot delay wl_surface.commit in vkQueuePresent when implementing VkPresentModes
17:17 emersion: vulkan clients expect vkQueuePresent to commit the surface
17:17 emersion: IOW: changing the surface pending state after vkQueuePresent() should not be included in the commit
17:18 emersion: jadahl: "covers both subsurfaces wp_transaction and the buffer-readiness stuff" → but we don't need to define this here though?
17:19 emersion: i mean, transactions is just one thing that can hold back a commit
17:19 JoshuaAshton: I guess really want we probably want is to be able to define a serial on a buffer so a compositor can go thru them in order. Any other solution such as unlocking from the clientside would introduce bubbles of latency.
17:19 emersion: there are others, like sub-surfaces and buffer readyness
17:36 jadahl: emersion: don't need to cover readiness perhaps, but needs to define a "transaction" that maybe includes (or invalidates) subsurface synchronization
17:36 emersion: i don't really agree
17:37 emersion: i don't see why we would want this
17:39 jadahl: MrCooper: did we only talk about hte transaction stuff on IRC? because I find nothing on gitlab, but still have memory of you raising concerns about how things were formulated
17:40 emersion: i mean there's no harm saying that the compositor might hold off commits for longer
17:40 emersion: or that a synchronized sub-surface might hold off commits for longer
17:40 emersion: but i'd rather not change any existing behavior
17:41 jadahl: it's more about how to define a transaction, that can coexist with subsurface synchronization, that still makes buffer readiness implementable
17:41 emersion: it's an additive thing
17:42 emersion: each one of these things holds off the commit for a bit longer
17:42 MrCooper: JoshuaAshton: sounds like gamescope might not implement frame events correctly; a frame event is supposed to mark the point after which attaching a new buffer to the surface can no longer prevent a previously attached buffer from getting presented to the user, which is what's needed for FIFO
17:42 emersion: that's an incorrect interpretation
17:43 emersion: wl_surface.frame indicates when it's a good time to start drawing the next frame
17:43 emersion: it might be immediately, that's up to the compositor
17:43 MrCooper: I think the spec is pretty explicit about that
17:43 emersion: https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/protocol/wayland.xml#L1543
17:44 MrCooper: "frame event communicates a good time to start drawing" is folklore at this point, clients may need to start earlier than that to sustain full frame rate
17:45 MrCooper: jadahl: possibly, don't really remember details about that :(
17:45 JoshuaAshton: MrCooper: I took a look at other compositors and they were just sending the frame callback without regard for this on every surface every refresh cycle
17:46 emersion: in any case, there is no such guarantee
17:46 MrCooper: "If the client commits an update earlier than that, it is likely that some updates will not make it to the display"
17:46 emersion: "likely"
17:49 jadahl: MrCooper: too bad, because you had a bunch of good points that forced me to revaluate all the wording, but didn't write anything down :(
17:50 MrCooper: emersion: there's a small chance the second update will cross the wire at the same time as the frame event, in which case it may make it to the display
17:51 emersion: this still doesn't say anything about your assumption
17:52 MrCooper: pq seemed to agree with my interpretation
17:53 emersion: frame events are for clients with simple rendering loops
17:53 emersion: if you want to implement FIFO, it's not the right tool
17:53 swick[m]: it's almost like the frame event is not suitable for implementing FIFO
17:53 MrCooper: anyway, you can avoid this ambiguity with presentation-time, but then you'll more likely need to start working on the next frame before the event arrives
17:53 emersion: sure
17:53 swick[m]: yeah, presentation-time doesn't make anything better
17:54 emersion: with transactions, you can
17:54 swick[m]: probably but that seems like a hack
17:54 MrCooper: with transactions you can what?
17:54 swick[m]: if we want fifo behavior we should define a protocol to get fifo behavior
17:55 MrCooper: yep
17:55 emersion: we've seen how that went in the past
17:55 emersion: we've like 5 proposals for this now
17:55 swick[m]: not really
17:55 swick[m]: I have not seen a single one
17:55 swick[m]: present-timing maybe
17:57 emersion: i was speaking about presentation in general
17:58 MrCooper: jadahl: mainly I think the interactions between transactions and synchronized sub-surfaces are tricky and need to be well thought through and documented (and ideally tested)
17:58 emersion: these interactions are not tricky at all in my implementation
17:58 MrCooper: e.g. if a synchronized sub-surface is part of a transaction but its parent is not, or vice versa
17:59 emersion: sync sub-surfaces use the same internal mechanism as transactions and buffer readyness
18:09 jadahl: MrCooper: yea
18:12 MrCooper: emersion: I agree something like that should work, just need to make sure the spec spells it out unambiguously
18:12 emersion: +1 for spelling things out explicitly
18:12 MrCooper: calling it a day, bbl
23:01 ahmadraniri[m]: Hello, I'm trying some examples of qt wayland compositior (from qtwayland5-examples package). It's launchable both from TTY or nested. I notice that if I launch the compositor from TTY, my keyboard input become double, like if I type "l", the output become "ll". It doesn't happen when I launch it as nested compositor. Any clue ? Thanks... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/VjyIVaYBKyvoehNbtvARLoVh>)