09:03 pq: soreau, you need the simple-shm buffer logic. There is no guarantee that the compositor releases the shm buffer you posted until you have committed another update to the same surface. Even then it's not a (timely) guarantee, so you might need even a third buffer sometimes.
09:04 soreau: pq: but that's not what vyivel indicated :P
09:05 pq: soreau, particularly Weston with Pixman-renderer won't give you an early release.
09:05 soreau: and that's what I was thinking when reading through simple-shm.c
09:05 pq: soreau, re-using wl_buffers is highly desirable and intended. Destroying and creating shm buffers has a potentially significant cost.
09:05 vyivel: you can reuse buffer on release
09:05 vyivel: if it's not released you can't reuse it
09:06 soreau: ah
09:06 soreau: I'm only updating max 1fps so far, so I guess it's not a problem
09:06 pq: therefore you usually have a pool of buffers that starts with one buffer, adds new buffers as needed, and keeps track of which ones are free to be re-used.
09:07 pq: fps is irrelevant
09:08 pq: Weston with Pixman-renderer will keep your shm buffer in use, until you post another one or destroy/unmap the surface. No matter how many hours you take.
09:08 soreau: when you create the pool, does the size need to be twice as large to accommodate for two buffers?
09:08 pq: I mean the concept of a pool, not a literal wl_shm_pool. But of course you could implement it with a large wl_shm_pool.
09:09 soreau: pq: ok, thanks for the input
09:09 soreau: so far, it just reuses the wl_buffer without regard to release events, and it seems to work ok FTM
09:10 pq: yeah, that's luck
09:11 soreau: well if the server is running at a 'normal' rate and the client is reusing at 1fps, I think it releases by then anyway.. but yea, could be a race
09:11 soreau: which is why I asked the question in the first place
09:11 pq: If your compositor is GPU-accelerated, it probably copies the shm buffer contents into its own copy very soon, and your next frame modifications do not get read too early.
09:12 soreau: but I just got wayfire working headless on a lowly box, so we'll see
09:12 pq: well, Weston with Pixman-renderer won't release, and that's what the protocol allows.
09:12 soreau: I was thinking of dumbing down the headless refresh rate, but maybe 15fps is too dumb
09:13 soreau: pq: I see
09:13 pq: if you have a compositor with a non-GL non-Vulkan software renderer, there is a good chance it won't release until post another buffer
09:13 soreau: hm
09:14 zamundaaa[m]: KWin doesn't release the shm buffers with the OpenGL renderer either
09:14 zamundaaa[m]: It always keeps the last buffer on the surface
09:15 soreau: but if you reuse the buffer before release.. what happens?
09:15 soreau: UB?
09:15 pq: unknown
09:16 pq: the compositor might be reading the buffer while you are writing to it, meaning the compositor gets garbage or inconsistent pixels
09:16 soreau: well I want this client to be an example widget and example pywayland client (for myself and others) so I will likely 'fix' it to simple-shm specs
09:16 pq: cool
09:17 soreau: pq: yea that's the whole point of implementing the epoll custom loop
09:17 soreau: because I don't want to potentially read/write to variables when updating weather stuff, for example
09:17 soreau: so instead I use eventfd write/reads
09:18 pq: oh, yeah, avoiding races in general, good
09:19 soreau: yes
09:19 soreau: even when handling sigint, I write to a 'close_fd' and handle it in the event loop
09:19 soreau: because threads are sticky in python, and I need ^C to work
09:20 soreau: and ofc, do the same thing on xdg close event
11:51 yppy: the pointer-constraints and relative-pointer protocols seem to be 10 years old, widely used, and implemented in every desktop compositor, is there a reason they are marked as unstable instead of staging?
11:53 vyivel: yppy: https://gitlab.freedesktop.org/wayland/wayland-protocols/#legacy-protocol-phases
11:53 vyivel: i.e. it means nothing
11:53 yppy: i saw that but is the unstable class now treated the same as staging
11:54 vyivel: more like stable i feel
11:55 yppy: as the documentation says explicitly they will break
11:55 soreau: basically it would mean tons of churn for little or no gain?
12:02 yppy: if that is the case i think it should be stated somewhere
12:02 yppy: or they should just be moved to staging
12:02 vyivel: moving them would be a breaking change
12:06 yppy: the old path can be kept (it seems like this is what happens anyway?), unless there is a different reason it is breaking
12:07 yppy: but either way i think the documentation should not be wrong
15:33 OctopusET: https://matrix.to/#/!qORmtlkPruZOLXhqII:matrix.org?via=matrix.org
15:34 OctopusET: text-input discussion room