09:55 wlb: weston Merge request !1482 opened by Oleksii Khudobin (alexey.khudobin) Provide changes to seat management in RDP backend https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1482
12:15 zzag: jadahl: MrCooper: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26#note_2320406 a bit of compromise, but what do you think about ignoring subsurface sync state in wp_transactions_v1.commit? i.e. treat subsurfaces desync even though they are effectively sync in wp_transactions_v1.commit
12:15 zzag: - this would make subsurfaces a lot easier to deal with, e.g. what if the subsurface becomes desync or sync after add_surface => this wouldn't matter
12:15 zzag: - if sync subsurface has been committed but it's not part of a transaction, use the normal commit rules, i.e. apply subsurface state when the parent surface's state is committed
12:15 zzag: - on client side, it would make sync subsurfaces a lot nicer to deal with, one wouldn't need to add pesky parent surface commits even though no changes have occurred in the parent
12:15 zzag: also /me wishes we had transactions right from the start
12:16 zzag: then we wouldn't have wl_subsurface.set_desync and set_sync
12:16 zzag: and subsurfaces would be a lot simpler in general
13:45 OPEN___: Hi everyone, I wanted to participate EVoC this year, so i was curious to know that EVoC is happening this year [2024] as i tried to reach at the mailing list but doesn't recieved any response from there ??
13:46 OPEN___: or I am doing something wrong? Any advice or guidance will be appericated !!
13:50 emersion: zzag: i'd prefer protocol error rather than ignore tbh
13:51 zzag: hmm, that's an interesting idea! just to be sure, do you suggest to forbid adding sync subsurfaces to wp_transaction_v1?
13:52 zzag: so they all are desync
13:53 emersion: yeah
13:55 zzag: okay, yeah, that's a good idea!
14:00 zzag: emersion: btw, is the wlroots community interested in the surface transaction protocol? could you ack it? :)
14:01 zzag: fwiw, Qt devs have shown some interest in such a protocol too. /me will poke them
14:02 vyivel: zzag: it's a wp_ protocol so i don't think we can be not interested in it
14:02 zzag: \o/
14:02 emersion: oh yeah definitely, and vyivel has a WIP impl even i think?
14:03 vyivel: i have an ad-hoc transaction protocol impl for testing but it's very similar to what's in the MR iirc
14:03 vyivel: i'm just waiting for a consensus on how it all interacts with subsurfaces
14:04 zzag: ftr I implemented the protocol in the MR, but I would really like to simplify subsurface stuff, so they are treated as desyncc
14:05 vyivel: forbidding adding sync subsurfaces as suggested above sounds fine to me, but there are some tricky cases (subsurfaces can be sync indirectly, and they can become sync after being added to a transaction)
14:06 emersion: ndeed
14:06 emersion: indeed*
14:06 zzag: "and they can become sync after being added to a transaction)" in kwin, this doesn't matter
14:06 zzag: because every transaction is basically a hash table surface -> state
14:06 zzag: and kwin takes a "snapshot" when creating a transaction
14:07 zzag: so if sync state changes later, it doesn't matter
14:07 zzag: state will be still applied as expected
14:07 vyivel: hm
14:08 vyivel: set_desync, add to transaction, set_sync, commit, commit transaction — is the state applied in this case?
14:09 zzag: "set_sync" this should post a protococl error
14:09 zzag: set_desync, add to transaction, commit, commit transaction, set_sync should be fine though
14:10 vyivel: right, we're on the same page then
15:35 MrCooper: then there would also need to be an error if a sub-surface in a transaction becomes implicitly sync due to an ancestor, which might be a bit weird / surprising
17:06 wlb: wayland-protocols Merge request !293 opened by Sebastian Wick (swick) cursor-shape-v1: Make object inert when underlying object is destroyed https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/293