ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Company has quit [Remote host closed the connection]
gspbirel5687340886706 has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
tzimmermann has joined #wayland
rv1sr has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
zhxt[m] has joined #wayland
<orowith2os[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
<orowith2os[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
<orowith2os[m]>
(compat layer both ways - wayland v1 on v2, and vice versa)
<orowith2os[m]>
just thoughts, and nothing to act on - but might be useful for future plans
Fischmiep_ has quit [Ping timeout: 480 seconds]
Fischmiep has joined #wayland
<orowith2os[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
dcz_ has joined #wayland
<orowith2os[m]>
(assuming there's nothing so breaking that it needs more than just mapping one message to another(
krishbin has quit [Ping timeout: 480 seconds]
krishbin has joined #wayland
<kennylevinsen>
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.
<kennylevinsen>
if you find something problematic, do feel free to report it
krishbin has quit []
<orowith2os[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 :)
<orowith2os[m]>
just searching for "ABI" in the wayland/wayland issue tracker should get you most of it
<orowith2os[m]>
well, now that I think about it...
<orowith2os[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
<orowith2os[m]>
and never use the original core wayland protocol
<orowith2os[m]>
so it's literally just drafting up a wayland-v2.xml
<orowith2os[m]>
what I originally had in mind was a bit more invasive
<orowith2os[m]>
(on top of the protocl-next design)
<orowith2os[m]>
or maybe not?
<orowith2os[m]>
I'll read the issue more tomorrow
<kennylevinsen>
well protocol-next is not a thing, just an issue with notes if it should ever be relevant
<orowith2os[m]>
yeah
<orowith2os[m]>
I at least hope I can bring it up a bit more and think over how it could be relevant
<orowith2os[m]>
and making it relevant for most everyone - even compositors that only have v1, via a compat layer
<orowith2os[m]>
(all just ideas, so keep that in mind)
<orowith2os[m]>
lots of ideas lately
<orowith2os[m]>
I need to stop thinking
<orowith2os[m]>
my head hurts
<kennylevinsen>
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
<orowith2os[m]>
one thing that could be nabbed in a redesign is more protocols, so to speak
<orowith2os[m]>
split the core wayland protocol into smaller ones
<orowith2os[m]>
make it easier to update them separately
<orowith2os[m]>
not entirely sure how useful that would be
<kennylevinsen>
yeah that would probably have been a good idea
sunrise890 has joined #wayland
<kennylevinsen>
But important protocols would still have to move slowly and with a lot of caution
<orowith2os[m]>
definitely
<orowith2os[m]>
but making it easier to move them forward helps
<kennylevinsen>
not sure if we're blocked by that right now, but sure.
<kennylevinsen>
Would have been nice to be able to just remove the wl_shell protocol instead of it being there with a deprecation warning
<orowith2os[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
<orowith2os[m]>
not technically impossible, just in violation of the protocol, probably
<orowith2os[m]>
too. much. thinking.
<orowith2os[m]>
it is almost 3am
<orowith2os[m]>
my head is starting to hurt more
<orowith2os[m]>
I'm out
<orowith2os[m]>
I'll read everything and then consider my thoughts afterwards to see what's useful and what isn't
<orowith2os[m]>
and everyone can shoot it down
pieguy128_ has joined #wayland
pieguy128 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
mblenc has joined #wayland
rgallaispou has joined #wayland
leon-anavi has joined #wayland
<pq>
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.
<orowith2os[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?
<pq>
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.
<pq>
orowith2os[m], not really, no.
<orowith2os[m]>
oh?
<pq>
wl_shell is the main example of the contrary
<pq>
*Every* global advertised through wl_registry is technically optional.
<pq>
however, not implementing e.g. wl_compositor would be very useless
<pq>
since practically everything needs a wl_compositor
<pq>
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.
<pq>
This is also a reason why people have been wanting a database of Wayland extensions, who implements/supports/requires what.
<orowith2os[m]>
something that generates that automatically would be nice...
<orowith2os[m]>
looks like wayland.app is all manual
<pq>
it might be difficult to make the difference between supported and required, unless you just try to run everything and filter out globals
<pq>
but compositor support could be mostly automated
<orowith2os[m]>
that's what I'm thinking, yes
<pq>
however, the idea was also record if a project will never support a thing, or would support but no-one did it yet.
<orowith2os[m]>
some simple CI with a script to print the globals, and it builds the appropriate releases + git
<orowith2os[m]>
maybe some manual intervention for experimental protocols, e.g. GNOME
<pq>
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.
<pq>
wl_registry could advertise a wl_new_design or something, as a new root thing
<pq>
and nothing else, if the compositor is not backwards-compatible
<orowith2os[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
<orowith2os[m]>
v2 on v1 is something that would be nice to think up a storm about, but is less of a worry
<pq>
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.
<orowith2os[m]>
that would work too
<pq>
but it's also less flexible with new extensions
<pq>
and especially with private extensions
<orowith2os[m]>
well, one could also add the ability for compositors to interact with the protocol directly
iomari891 has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
not really a mutually exclusive thing
<pq>
right
<pq>
go wild if you want to, but at least personally I don't think I can participate much :-)
<orowith2os[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
<orowith2os[m]>
(more of the protocols-as-an-api thing would be nice too, but not specific to this)
<orowith2os[m]>
and I'm sure wlroots and smithay already cover that
<kennylevinsen>
pq: well if one had a wire v2 with core v2, we could also change the handshake semantics
<kennylevinsen>
... but I'm fine with v1 for now :P
crazybyte has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
'nother thing
<orowith2os[m]>
wrt backwards compatibility
<orowith2os[m]>
something about 32-bit and 64-bit integers
<kennylevinsen>
64-bit integers would allow for protocols that do not split into lo and hi 32-bit segments
<kennylevinsen>
and that have doubles
<orowith2os[m]>
mm
<orowith2os[m]>
will note as something that would be nice in the draft
<kennylevinsen>
but you won't really be able to map between the two without throwing away precision or wrapping/discarding large values
<kennylevinsen>
so v1 would not have access to such new v2 protocols
<orowith2os[m]>
funny, that probably addresses what I was right about to ask: compatibility between the two
<vyivel>
do we even want floats in the protocol? iirc there was a discussion about it but i don't remember the conclusion
<kennylevinsen>
wl_fixed was disowned by its father, so maybe one day
<orowith2os[m]>
I'd imagine 64-bit ints in a new protocol would make it harder to implement on top of wayland-v1
<kennylevinsen>
or maybe a way larger wl_fixed
<kennylevinsen>
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
<vyivel>
64-bit fixed sounds like it should be enough (famous last words)
<kennylevinsen>
but wayland in general has the attitude of adding new protocols which older clients just don't use
<pq>
the problem with 64-bit message arguments is actually in the libwayland C ABI, and not the protocol format itself
<orowith2os[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
<pq>
union wl_argument that is the basis of all language bindings except the original C one using libffi
<orowith2os[m]>
(e.g. going forward with a "more protocols" design, having optional stuff doesn't feel too nice there)
<orowith2os[m]>
s/there/otherwise
floof58 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
<orowith2os[m]>
will see how that ends up looking
<orowith2os[m]>
I think I've done enough for tonight/this morning
<orowith2os[m]>
it is now 3:47 AM
<orowith2os[m]>
eugh
fmuellner has joined #wayland
iomari891 has quit []
crazybyte has joined #wayland
<orowith2os[m]>
AAAA one more small thing I want to look into: explicit sync
<orowith2os[m]>
(well, not small, but "small")
floof58 has joined #wayland
<orowith2os[m]>
need to bug some WSI folks, I think
<kennylevinsen>
if by small you mean "spanning the entire stack"...
sunrise890 has quit []
<orowith2os[m]>
yes, "small"
kts has joined #wayland
<orowith2os[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
<orowith2os[m]>
but not sure if the story's better for making OpenGL and an explicitly synced Wayland work together
<orowith2os[m]>
and now I actually head to bed
<orowith2os[m]>
will read any responses later
<pq>
the kernel has some fence interop for that
<pq>
relatively recent development
<davidre>
<orowith2os[m]> "some simple CI with a script..." <- That's what wayland.app does atm I think
<davidre>
modulo the build the release
rederick29 has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
<emersion>
orowith2os[m]: there is recent activity re explicit sync, I'd recommend reading the current state in MRs
<MrCooper>
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
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
kenny has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
molinari has joined #wayland
Guest1851 has quit []
cool110 has joined #wayland
cool110 is now known as Guest1922
iomari891 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
molinari has quit [Ping timeout: 480 seconds]
agd5f has quit [Remote host closed the connection]
agd5f has joined #wayland
agd5f has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
agd5f has joined #wayland
leon-anavi has quit [Quit: Leaving]
junaid has joined #wayland
<orowith2os[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
<orowith2os[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?
mblenc has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<i509vcb>
Well you need to have drivers that can do explicit sync to develop explicit sync infrastructure
<i509vcb>
So I guess asahi and xe will be testing grounds for that
<kennylevinsen>
orowith2os[m]: that's not a Wayland 2 thing, it's a "finish the feature across the entire ecosystem" thing
<orowith2os[m]>
kennylevinsen: true, so probably not something to even try and worry about if other explicitly synced drivers already support it, at least "enough"
gspbirel56873408867061 has quit []
gspbirel56873408867061 has joined #wayland
<kennylevinsen>
as a rule of thumb, we can *add* anything within "wayland 1", and no user-space features should need a "wayland 2"
kts has quit [Ping timeout: 480 seconds]
lyubov_ has joined #wayland
anarsoul|2 has joined #wayland
anarsoul has quit [Read error: No route to host]
crazybyte has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
<i509vcb>
I'd probably half expect a dmabuf v2 protocol would probably have explicit sync considered from the start
<i509vcb>
Given there seems to be discussion around that
crazybyte has joined #wayland
d42 has quit [Ping timeout: 480 seconds]
<daniels>
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
carlos_ has joined #wayland
<daniels>
so an additive protocol is totally fine and how we’d do it with a clean slate
d42 has joined #wayland
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #wayland
d42 has quit []
d42 has joined #wayland
iomari892 has joined #wayland
mblenc has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
carlos_ has quit [Remote host closed the connection]
mblenc has quit [Ping timeout: 480 seconds]
d42 has quit []
<MrCooper>
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
d42 has joined #wayland
Brainium has joined #wayland
carlos_ has joined #wayland
<i509vcb>
Was the explicit sync protocol going to use sync fds or something else?
nerdopolis has quit [Ping timeout: 480 seconds]
iomari892 has quit [Ping timeout: 480 seconds]
Guest1922 has quit [Remote host closed the connection]
rv1sr has quit []
lsd|2 has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest1954
rasterman has quit [Quit: Gettin' stinky!]
junaid has quit [Remote host closed the connection]
melonai3 has quit []
melonai3 has joined #wayland
mblenc has joined #wayland
melonai3 has quit []
mblenc1 has quit [Ping timeout: 480 seconds]
melonai3 has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
glennk has quit [Remote host closed the connection]
glennk has joined #wayland
sima has quit [Ping timeout: 480 seconds]
soreau has quit [Ping timeout: 480 seconds]
soreau has joined #wayland
Moprius has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
emersion: is there anything you can comment on wrt. The kernel tearing patches?
<orowith2os[m]>
Looks like someone else has taken over on v4
dcz_ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<emersion>
i509vcb: syncobj
<emersion>
orowith2os[m]: I have no good ideas to make the tearing patches look good and consistent