05:41wlb: weston Issue #812 opened by Rob Kramer (teegee) Two rotated 4k screens: atomic: couldn't commit new state: Invalid argument https://gitlab.freedesktop.org/wayland/weston/-/issues/812
06:48orowith2os[m]: fair warning/heads up that I'll be reading up on the possible ABI breaks that were listed in the past for Wayland, and bugging yall with questions and "what-if"s
06:49orowith2os[m]: basically addressing the concerns, changing stuff to work a bit better (e.g. fractional scaling baked in always) and seeing if a compat layer would be feasible
06:49orowith2os[m]: (compat layer both ways - wayland v1 on v2, and vice versa)
06:50orowith2os[m]: just thoughts, and nothing to act on - but might be useful for future plans
06:53orowith2os[m]: I could probably see if I can hack something together to actually put it in practice, but I've got other stuff to work on
07:00orowith2os[m]: (assuming there's nothing so breaking that it needs more than just mapping one message to another(
07:19kennylevinsen: orowith2os[m]: Edits to existing messages are usually minor clarification, otherwise it's usually new messages. Behavior is also controlled by the bound interface version.
07:20kennylevinsen: if you find something problematic, do feel free to report it
07:23orowith2os[m]: kennylevinsen: this is more stuff that was noted that shouldn't have been in the core protocol, or should've been done. But I'll 100% note anything I see that could be improved without breaking things too :)
07:25orowith2os[m]: just searching for "ABI" in the wayland/wayland issue tracker should get you most of it
07:26orowith2os[m]: this might be the specific issue I have in mind: https://gitlab.freedesktop.org/wayland/wayland/-/issues/247
07:26orowith2os[m]: well, now that I think about it...
07:27orowith2os[m]: one could just make their own Wayland protocol, built on top of the wire format that's used already, at first glance on my end
07:27orowith2os[m]: and never use the original core wayland protocol
07:27orowith2os[m]: so it's literally just drafting up a wayland-v2.xml
07:28orowith2os[m]: what I originally had in mind was a bit more invasive
07:28orowith2os[m]: (on top of the protocl-next design)
07:30orowith2os[m]: or maybe not?
07:30orowith2os[m]: I'll read the issue more tomorrow
07:30kennylevinsen: well protocol-next is not a thing, just an issue with notes if it should ever be relevant
07:31orowith2os[m]: yeah
07:31orowith2os[m]: I at least hope I can bring it up a bit more and think over how it could be relevant
07:32orowith2os[m]: and making it relevant for most everyone - even compositors that only have v1, via a compat layer
07:33orowith2os[m]: (all just ideas, so keep that in mind)
07:33orowith2os[m]: lots of ideas lately
07:33orowith2os[m]: I need to stop thinking
07:33orowith2os[m]: my head hurts
07:33kennylevinsen: it's a hypothetical, it is unlikely that anyone wants it to move forward anytime soon unless something major is blocked by the current design
07:34orowith2os[m]: one thing that could be nabbed in a redesign is more protocols, so to speak
07:34orowith2os[m]: split the core wayland protocol into smaller ones
07:34orowith2os[m]: make it easier to update them separately
07:34orowith2os[m]: not entirely sure how useful that would be
07:35kennylevinsen: yeah that would probably have been a good idea
07:35kennylevinsen: But important protocols would still have to move slowly and with a lot of caution
07:35orowith2os[m]: definitely
07:36orowith2os[m]: but making it easier to move them forward helps
07:36kennylevinsen: not sure if we're blocked by that right now, but sure.
07:37kennylevinsen: Would have been nice to be able to just remove the wl_shell protocol instead of it being there with a deprecation warning
07:38orowith2os[m]: one very minor potentnial use case I have in mind for "more protocols" is implementing only what's relevant for a bare minimum compositor. I might not need all of core, and to be considered Wayland-compliant I don't want to implement all of it - so just implement what I want, and clients figure out what they want and go from there
07:38orowith2os[m]: not technically impossible, just in violation of the protocol, probably
07:39orowith2os[m]: too. much. thinking.
07:39orowith2os[m]: it is almost 3am
07:39orowith2os[m]: my head is starting to hurt more
07:39orowith2os[m]: I'm out
07:40orowith2os[m]: I'll read everything and then consider my thoughts afterwards to see what's useful and what isn't
07:41orowith2os[m]: and everyone can shoot it down
08:09pq: orowith2os[m], there isn't actually any rigid spec of what is "Wayland core" nor saying that you don't deserve to say you do Wayland if you don't do this and that.
08:10orowith2os[m]: pq: isn't "Wayland core" what's in wayland.xml, and what can safely (until I came along :P) be assumed to ALWAYS be available, in EVERY compositor?
08:10pq: orowith2os[m], it's more about what majority of applications cannot live without in a generic category of environments. E.g. desktop apps have lots of requirements before they work well or at all.
08:10pq: orowith2os[m], not really, no.
08:10orowith2os[m]: oh?
08:10pq: wl_shell is the main example of the contrary
08:11pq: *Every* global advertised through wl_registry is technically optional.
08:11pq: however, not implementing e.g. wl_compositor would be very useless
08:12pq: since practically everything needs a wl_compositor
08:13pq: it's a Wayland compositor developers responsibility to figure out what they need to implement to have the apps work that they care about, and it is the app developers responsibility to think which interfaces they can hard-require while being able to work on systems they care about.
08:15pq: This is also a reason why people have been wanting a database of Wayland extensions, who implements/supports/requires what.
08:17orowith2os[m]: something that generates that automatically would be nice...
08:17orowith2os[m]: looks like wayland.app is all manual
08:18pq: it might be difficult to make the difference between supported and required, unless you just try to run everything and filter out globals
08:19pq: but compositor support could be mostly automated
08:19orowith2os[m]: that's what I'm thinking, yes
08:19pq: however, the idea was also record if a project will never support a thing, or would support but no-one did it yet.
08:19orowith2os[m]: some simple CI with a script to print the globals, and it builds the appropriate releases + git
08:20orowith2os[m]: maybe some manual intervention for experimental protocols, e.g. GNOME
08:21pq: orowith2os[m], re: using old wire protocol with new messages; the problem there is that there is no initial version negotiation. Both sides assume wl_display v1 exists at ID 1 with the interface given in wayland.xml, and that's where everything is derived from, mainly through wl_registry.
08:22pq: wl_registry could advertise a wl_new_design or something, as a new root thing
08:23pq: and nothing else, if the compositor is not backwards-compatible
08:25orowith2os[m]: might be easier to just have compositors do the "new" protocol, and have a shim that implements v1 on v2 with another, separate, socket
08:26orowith2os[m]: v2 on v1 is something that would be nice to think up a storm about, but is less of a worry
08:27pq: maybe, or maybe compositors should be written against an API rather than protocol bindings directly, so that the compat layer could just call the API instead of re-serializing.
08:27orowith2os[m]: that would work too
08:28pq: but it's also less flexible with new extensions
08:28pq: and especially with private extensions
08:28orowith2os[m]: well, one could also add the ability for compositors to interact with the protocol directly
08:29orowith2os[m]: not really a mutually exclusive thing
08:29pq: right
08:30pq: go wild if you want to, but at least personally I don't think I can participate much :-)
08:31orowith2os[m]: at most it's a fun side project to think about, and I can bring it up in a more official context if I feel it's actually worth it
08:31orowith2os[m]: (more of the protocols-as-an-api thing would be nice too, but not specific to this)
08:32orowith2os[m]: and I'm sure wlroots and smithay already cover that
08:36kennylevinsen: pq: well if one had a wire v2 with core v2, we could also change the handshake semantics
08:36kennylevinsen: ... but I'm fine with v1 for now :P
08:40orowith2os[m]: 'nother thing
08:40orowith2os[m]: wrt backwards compatibility
08:40orowith2os[m]: something about 32-bit and 64-bit integers
08:41kennylevinsen: 64-bit integers would allow for protocols that do not split into lo and hi 32-bit segments
08:41kennylevinsen: and that have doubles
08:41orowith2os[m]: mm
08:41orowith2os[m]: will note as something that would be nice in the draft
08:41kennylevinsen: but you won't really be able to map between the two without throwing away precision or wrapping/discarding large values
08:42kennylevinsen: so v1 would not have access to such new v2 protocols
08:42orowith2os[m]: funny, that probably addresses what I was right about to ask: compatibility between the two
08:42vyivel: do we even want floats in the protocol? iirc there was a discussion about it but i don't remember the conclusion
08:42kennylevinsen: wl_fixed was disowned by its father, so maybe one day
08:42orowith2os[m]: I'd imagine 64-bit ints in a new protocol would make it harder to implement on top of wayland-v1
08:43kennylevinsen: or maybe a way larger wl_fixed
08:43kennylevinsen: orowith2os[m]: it's very hard to say what the compatibility game for something that does not even exist as an idea yet would be
08:43vyivel: 64-bit fixed sounds like it should be enough (famous last words)
08:43kennylevinsen: but wayland in general has the attitude of adding new protocols which older clients just don't use
08:43pq: the problem with 64-bit message arguments is actually in the libwayland C ABI, and not the protocol format itself
08:44orowith2os[m]: good thing it's not much of a concern here - there are more fundamental breaks I'm laying out anyways that make it seem small in comparison
08:45pq: union wl_argument that is the basis of all language bindings except the original C one using libffi
08:45orowith2os[m]: (e.g. going forward with a "more protocols" design, having optional stuff doesn't feel too nice there)
08:45orowith2os[m]: s/there/otherwise
08:46orowith2os[m]: will see how that ends up looking
08:46orowith2os[m]: I think I've done enough for tonight/this morning
08:47orowith2os[m]: it is now 3:47 AM
08:47orowith2os[m]: eugh
08:52orowith2os[m]: AAAA one more small thing I want to look into: explicit sync
08:52orowith2os[m]: (well, not small, but "small")
08:53orowith2os[m]: need to bug some WSI folks, I think
08:53kennylevinsen: if by small you mean "spanning the entire stack"...
08:53orowith2os[m]: yes, "small"
08:56orowith2os[m]: I don't have much context for implicit vs explicit sync, so it'll definitely be an experience, but one that should be looked into - iirc trying to get explicit sync, Vulkan, to interact nicely with implicit sync, Wayland, isn't too nice
08:56orowith2os[m]: but not sure if the story's better for making OpenGL and an explicitly synced Wayland work together
08:58orowith2os[m]: and now I actually head to bed
08:58orowith2os[m]: will read any responses later
08:59pq: the kernel has some fence interop for that
08:59pq: relatively recent development
09:19davidre: <orowith2os[m]> "some simple CI with a script..." <- That's what wayland.app does atm I think
09:19davidre: modulo the build the release
09:39emersion: orowith2os[m]: there is recent activity re explicit sync, I'd recommend reading the current state in MRs
11:14wlb: weston Issue #807 closed \o/ (unable to bind rdp socket https://gitlab.freedesktop.org/wayland/weston/-/issues/807)
12:22MrCooper: orowith2os[m]: Vulkan works fine in general with implicit sync in Wayland, except for some special use cases; OpenGL can also work fine with explicit sync in Wayland, though there's little point if the drivers support implicit sync
16:07orowith2os[m]: MrCooper: is there any specific preference, or is it just whatever? Even if it's just a thought, and probably won't go anywhere, if a "Wayland 2" makes it easier to use explicit sync down the road, it would be nice
16:07orowith2os[m]: Though I remember there being some alternative for explicit sync drivers to get implicit sync stuff working - iirc Asahi and the Xe drivers do that?
16:25i509vcb: Well you need to have drivers that can do explicit sync to develop explicit sync infrastructure
16:25i509vcb: So I guess asahi and xe will be testing grounds for that
16:31kennylevinsen: orowith2os[m]: that's not a Wayland 2 thing, it's a "finish the feature across the entire ecosystem" thing
16:33orowith2os[m]: kennylevinsen: true, so probably not something to even try and worry about if other explicitly synced drivers already support it, at least "enough"
16:39kennylevinsen: as a rule of thumb, we can *add* anything within "wayland 1", and no user-space features should need a "wayland 2"
17:43i509vcb: I'd probably half expect a dmabuf v2 protocol would probably have explicit sync considered from the start
17:43i509vcb: Given there seems to be discussion around that
17:51daniels: not really, no - dmabuf is for buffer import/export which happens rarely (basically 3x per surface if you don’t resize or reconfigure) - sync is per-frame
17:51daniels: so an additive protocol is totally fine and how we’d do it with a clean slate
18:38MrCooper: orowith2os[m]: the main challenge for explicit sync in Wayland is the protocol vs output state tracking in the compositor, the protocol itself is pretty straightforward
19:00i509vcb: Was the explicit sync protocol going to use sync fds or something else?
23:01orowith2os[m]: emersion: is there anything you can comment on wrt. The kernel tearing patches?
23:03orowith2os[m]: Looks like someone else has taken over on v4
23:56emersion: i509vcb: syncobj
23:56emersion: orowith2os[m]: I have no good ideas to make the tearing patches look good and consistent
23:57emersion: (with the non-tearing codepath)