02:29 wlb: wayland Merge request !319 opened by Alex Yang (aycyang) debug: Replace "@<id>" with "#<id>" https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/319
07:04 wlb: weston Issue #753 closed \o/ (sunxi lima driver weston doesn't work https://gitlab.freedesktop.org/wayland/weston/-/issues/753)
07:12 pq: emersion, yes please, do post changes to presentation-time extension instead of taking the liberty of silently sending events that are clearly against the wording. This seems to be another example of abusing low-level mechanics for something it was not intended, just because it happens to work on anything you tried with.
07:24 pq: what's misleading in presentation-time for fixed refresh rate?
07:24 pq: The quoted sentence is definitely about VRR and not about headless.
07:25 pq: it is also about things like USB displays that transmit whatever they have bandwidth for, meaning they take variable times for different updates
07:33 MrCooper: pq: I think he meant misleading as in: If the client workload doesn't allow hitting the next refresh cycle anyway, the client can't just use the presentation-time feedback refresh value for its simulation time, similar to how it can't just use what wlroots sends there with VRR
07:33 wlb: wayland/main: Sebastian Wick * protocol: specify the exact form of premultiplication https://gitlab.freedesktop.org/wayland/wayland/commit/f3026c916ef9 protocol/wayland.xml
07:33 wlb: wayland Merge request !316 merged \o/ (protocol: specify the exact form of premultiplication https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/316)
07:34 pq: MrCooper, well, if it doesn't hit the next, then it may hit the next after. But yes, there is a very strong assumption that clients are able to complete drawing in less than one refresh period for optimal results.
07:35 pq: The design for presentation-time is: draw on frame callback, use presentation-time feedback to estimate when that drawing will be shown.
07:35 pq: And if a compositor delays sending frame callbacks, it makes clients more likely to miss their expectations.
07:36 pq: but also reduce latency for super-fast clients
07:37 pq: Any more smart timings like a client delaying its own start of drawing are simply left for other extension or future additions to take care of.
07:37 pq: That's all it was designed for, and it still seems to achieve that design goal, and no further.
07:53 wlb: weston Merge request !1246 opened by Michael Tretter (m.tretter) backend-drm: fail initialization only if all outputs failed https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1246
08:03 wlb: weston Issue #755 closed \o/ ([weston 11.0.1] QT button is not released https://gitlab.freedesktop.org/wayland/weston/-/issues/755)
08:46 wlb: weston Merge request !1247 opened by Michael Tretter (m.tretter) backend-pipewire: minor cleanup https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1247
09:46 emersion: swick[m], jadahl: i am not sure how to make https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68 progress anymore
09:47 emersion: it seems stuck with no way to unstuck
09:47 emersion: i should probably just give up on the whole security thing
09:48 emersion: all clients can use privileged protocols and i should just leave it at that
09:50 emersion: zzag: you wouldn't be interested in security by any chance?
09:51 d_ed[m]: on the KDE side we are interested in finding something
09:51 d_ed[m]: but it's not definite in any direction, using the cgroup of the connection owner is also on the cards
09:52 emersion: i see (that's not something i'll be implementing)
09:52 emersion: i'll just close that MR saying that no consensus could be found
09:55 emersion: pq, i don't have the resources to discuss the VRR stuff any more
09:59 jadahl: emersion: IIRC the last time I looked, what I didn't like was that every piece of metadata was undefined without any way to discover what it may mean without googling around hopefully finding documentation defining things elsewhere.
09:59 jadahl: d_ed[m]: how does crash recovery and reconnecting work with !68 btw?
10:01 d_ed[m]: We would have to pass FDs to our long-lasting helper and restore them
10:01 qyliss: jadahl: what's the alternative? encoding every sandbox mechanism that could possibly exist into the spec?
10:01 d_ed[m]: it'd be more code, but doable
10:01 d_ed[m]: (probably, I haven't implemented !68)
10:03 d_ed[m]: Or maybe a oneliner in flatpak to look for a different FLATPAK_WAYLAND_DISPLAY first and then have the helper implement the server side of !68
10:03 d_ed[m]: client side it'd make no difference
10:03 pq: emersion, good, because presentation-time was simply not designed for VRR. It only acknowledges VRR enough to step out of the way and say "I don't know".
10:04 emersion: i have no intention to change my compositor, fwiw
10:05 pq: as usual
10:06 pq: just don't go telling people that presentation-time as-is can be used for something it was never meant for
10:07 pq: if someone wants to use it for new things, they can propose the protocol version bump to let it happen
10:07 MrCooper: emersion: a problem with wlroots' behaviour is that the client may incorrectly assume there's a fixed refresh rate, and extrapolate based on that
10:08 MrCooper: (incorrectly but legitimately, based on the spec)
10:10 pq: If something is unspecified, we can argue which way it should be, but when it's explicitly written down as "must be zero", there is really no excuse to do something else.
10:13 MrCooper: agreed
10:14 pq: We know a lot more about frame scheduling today than we did at the time presentation-time was designed, so protocol development should continue to explicitly incorporate and define new things. The old interface is just not enough.
10:16 wlb: weston Issue #756 opened by Marius Vlad (mvlad) cleanup after cairo / xwayland / font map hash table detroy https://gitlab.freedesktop.org/wayland/weston/-/issues/756
10:34 swick[m]: emersion: I'm just not convinced that we can safely accept on a listening fd provided by the client. For me that's the blocking thing and I need a clear explanation of why it is safe to do. I also don't really have the time to dick into it far enough to provide that explanation myself.
10:35 emersion: sigh
10:36 swick[m]: I know...
10:36 swick[m]: d_ed: looking up the cgroup from a connection is just as racy as looking up anything else
10:38 swick[m]: I have a kernel patch laying around for pidfd support which can be used to get rid of the race but then the question becomes: what are you going to do with the cgroup?
10:39 swick[m]: I guess it gives you the same information as the !68 right now
10:40 swick[m]: but it is very linux specific
10:41 emersion: i think your comment about /dev/fd/ was about BSDs
10:41 emersion: the re-open trick only works on Linux
10:41 emersion: but:
10:41 emersion: - i don't care about clients changing flags, i care about BSDs
10:41 emersion: - you don't care about non-Linux, and you care about clients changing flags
10:41 emersion: so we're all good?
10:42 swick[m]: mh, maybe
10:43 swick[m]: like I said, I can't tell if this is sufficient to be safe
10:43 emersion: i don't understand what you request
10:45 swick[m]: that's the problem: I'm not sure. it seems risky and I don't know enough to say this is fine.
10:45 swick[m]: with pidfd+cgroup I'm at least reasonable sure that it's safe
10:46 emersion: it's not the same kind of safety issue
10:47 emersion: we're talking about safety against clients outside of sandboxes here
10:47 emersion: which can echo malware >>~/.bashrc anyways
10:47 emersion: switching flags is the least of my worries
10:50 swick[m]: I'm not going to nack anything here fwiw
10:56 MrCooper: emersion pq: for VRR, an interval in which the next refresh may happen might work, instead of a single value
10:57 pq: perhaps, I'm not sure how I'd use it in a client
11:04 swick[m]: we're not even getting things right for FRR right now yet everyone talks about VRR :s
11:22 jadahl: qyliss: outsource it to the document that was added and if you want some super special secret sandbox engine then just spell it out how that it's not limited to the documented cases
11:23 qyliss: but the document is already there?
11:24 qyliss: or by last time you looked, did you mean before the document was added?
11:27 emersion: sandboxes are just like app_ids
11:27 jadahl: qyliss: the document is there, but protocol documentation doesn't mention it, and just effectively makes everything undefined
11:27 emersion: we don't have a registry for app_id
11:27 jadahl: that's not really true
11:31 emersion: from my PoV it is
11:33 pq: which statement?
11:38 kennylevinsen: I don't think we currently have a trend of documenting used identifiers (e.g. app_id), but we could make example uses and suggest possible ways to derive them
11:42 kennylevinsen: the document with some extra detail also lives right by the protocol, so it's not hard to find
11:50 jadahl: kennylevinsen: it's not easy to find unless you're browsing the git repo, which I wouldn't say is the or should be the primary way one consumes protocol documentation
11:50 jadahl: kennylevinsen: even an app id has more meaning (it should map to a .desktop file)
11:51 jadahl: but sandbox engine is completely opaque, while the current way it is used in compositors that actually use sandbox app ids it adds various extra meaning to e.g. the toplevel app id
11:51 kennylevinsen: yeah for xdg_shell's set_api it may (but does not have to) match the id from a desktop entry
11:51 kennylevinsen: I think similar suggestion would be fine here
11:55 kennylevinsen: re: doc location, if we start to have docs beside xml files it should be in distro packages as well, so ti'll be for every way you browse protocols
11:55 kennylevinsen: not just git
11:56 kennylevinsen: jadahl: if we do something similar to xdg_shell (which suggests a way to set it, and suggests compostior use), would that be enough without a registry of values?
11:56 jadahl: I think a lot of people browse online on e.g. https://wayland.app
11:56 kennylevinsen: yeah that is a nice site
11:56 kennylevinsen: if we end up having docs beside protocols, we could (should?) probably also have them visible there
11:56 jadahl: kennylevinsen: plain suggestions makes it useless for flatpak which needs an actual specification how to use it
11:57 kennylevinsen: but that's no different than xdg_shell's app_id though?
11:57 kennylevinsen: why is this different?
11:57 jadahl: what do you mean? I can't really see the similarity
11:58 jadahl: the sandbox engine gives meaning to the metadata passed, and when it has meaning, compositors can use the metadata for anything other than dumb opaque grouping, e.g. finding .desktop files, looking up entries in the permission store, etc
11:59 kennylevinsen: A primary purpose for the compositor would be similar to that of xdg_shell's app_id, yes?
11:59 kennylevinsen: i.e., identify and group applications
11:59 kennylevinsen: (possibly now also permission store stuff as it can be trusted)
11:59 jadahl: without specified meaning to the metadata, it's not really useful for anything other than being able to know that clients "inside" that sandbox can't themself open new security contexts
12:00 kennylevinsen: xdg_shell's set_app_id suggests the use of the desktop entry specification. It does not - and cannot - require that it comes from there, as not all xdg_toplevels have .desktop files in the first place.
12:01 kennylevinsen: it does make a demand for d-bus activatable applications
12:01 kennylevinsen: ("For D-Bus activatable applications, the app ID is used as the D-Bus service name.
12:02 kennylevinsen: would specification to the same extend be sufficient? I believe app_id's worked fine so far?
12:03 kennylevinsen: maybe with the addition that it should be persistent and unqiue, to specifically cater to the permission thing
12:03 jadahl: kennylevinsen: if you define/suggest what 'app_id' means, how does that help if it's more strictly specified for a sandbox engine? and how would you document instance id?
12:04 jadahl: app_id from xdg-shell is quite unreliable, so wouldn't say it's a very good success story, but that's primarily a client issue I guess
12:05 qyliss: Instance ID might as well be opaque, right? It's just a way to identify that two instances of the same application are in different sandboxes.
12:05 kennylevinsen: it is fine if a sandbox engine choses to define formats more strictly as it choses the value, protocol should just be as strict as needed to serve the purpose.
12:05 kennylevinsen: I'm not sure I fully follow the intent or need for instance_id
12:06 kennylevinsen: we definitely need a few more words in the spec as to what it is for
12:06 jadahl: qyliss: for the protocol everything is opaque, but for flatpak, instance ID has meaning
12:06 qyliss: kennylevinsen: instance ID is important because if I have two instances of the same application open, I want to be able to identify that
12:06 qyliss: think about a Qubes-like system where different instances get differently coloured window decorations, for example
12:07 qyliss: "work" and "personal" instances of Firefox, or something
12:09 qyliss: jadahl: right, yeah. to do anything useful with instance ID apart from treating it as an opaque token you'd need sandbox-specific integration.
12:10 jadahl: yes, and what is insisted on is that the specificatioun not should define or link to sandbox specific documentation
12:10 qyliss: gotcha
12:11 qyliss: imo it would make sense to link to the docs
12:11 qyliss: specifications have non-normative stuff in them all the time
12:17 kennylevinsen: "The sandbox engine may further specify the format and meaning of the (application|instance) id."?
12:18 kennylevinsen: linking to flatpak from documentation that flatpak devs reference to implement the protocol and write the docs would be a bit weird and... cyclic. :P
12:19 kennylevinsen: maintaining an unofficial list is an option, but suggesting that the sandbox engine devs should provide the info seem fine?
12:20 qyliss: oh yeah
13:56 wlb: wayland Issue #382 opened by Veldora (Veldora) "Error 71 (Protocol error) dispatching to Wayland display" - when moving thunderbird from monitor with low scaling (e.g. 100 %) to monitor with higher scaling (e.g. 125 %). https://gitlab.freedesktop.org/wayland/wayland/-/issues/382
13:59 MrCooper: emersion: re https://emersion.fr/blog/2023/status-update-53/, why is an intermediate buffer for blending required for non-8-bit output formats?
13:59 emersion: MrCooper: 8-bit formats have an _SRGB variant in vulkan, which transparently encodes/decodes
14:00 emersion: for other formats you need to manually do the encoding/decoding in a shader
14:00 emersion: so, when rendering to a non-8-bit format, you need to have a second subpass to encode to sRGB
14:03 MrCooper: I see
14:15 pq: emersion, it sounds like you intend to do color transformations after blending? But for blending you would first need to get everything into a single common colorspace. How do you envision that working?
14:15 emersion: it's easy to add color operations before blending
14:16 pq: ok, so just not highlighted in the post, cool
14:16 emersion: yes, it's something we already have
14:26 wlb: wayland Issue #382 closed \o/ ("Error 71 (Protocol error) dispatching to Wayland display" - when moving thunderbird from monitor with low scaling (e.g. 100 %) to monitor with higher scaling (e.g. 125 %). https://gitlab.freedesktop.org/wayland/wayland/-/issues/382)
14:45 Company: I had another thought wrt yesterday's discussion about threaded rendering in GTK
14:45 Company: we have a Cairo renderer in GTK
14:46 Company: so I can prototype the Wayland parts without having to think about GL
14:47 Company: and easily do the "make the render thread hand off the wl_buffer to the main thread" thing for example
14:47 Company: also, the Cairo renderer is slower, so the gains are more visible, yay!
15:07 d_ed[m]: FWIW, Qt has threaded GL rendering. We might be able to help if you have specific questions or need a reference implementation.