ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
swick_ has joined #wayland
swick has quit [Quit: Page closed]
swick_ has quit []
swick has joined #wayland
soerenm has quit [Remote host closed the connection]
swick has quit [Quit: WeeChat 1.6]
swick has joined #wayland
swick has quit []
swick has joined #wayland
leandrohrb has joined #wayland
shashank1202 has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
raoni has quit [Ping timeout: 480 seconds]
specunix has joined #wayland
specunix has quit []
shashank1202 has quit [Quit: Connection closed for inactivity]
remanifest has quit []
zebrag has quit [Quit: Konversation terminated!]
slattann has joined #wayland
slattann has quit []
leon-p has joined #wayland
slattann has joined #wayland
dcz_ has joined #wayland
slattann has quit []
slattann has joined #wayland
AJ_Z0 has quit [Read error: Connection reset by peer]
AJ_Z0 has joined #wayland
hardening has joined #wayland
jgrulich has joined #wayland
pnowack has joined #wayland
tzimmermann has joined #wayland
slattann has quit []
slattann has joined #wayland
slattann1 has joined #wayland
danvet has joined #wayland
slattann has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
WhizzWr has quit [Quit: Bye!]
slattann1 has quit [Ping timeout: 480 seconds]
slattann1 has joined #wayland
WhizzWr has joined #wayland
slattann has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
slattann1 has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
slattann has quit []
rasterman has quit [Quit: Gettin' stinky!]
hendursa1 has joined #wayland
slattann has joined #wayland
hendursaga has quit [Ping timeout: 480 seconds]
yoslin_ has quit []
yoslin has joined #wayland
<DemiMarieObenour[m]>
I know that there are several problems with `wl_registry`. Can a `wl_fixes` interface be added? It would expose versioning information that would allow new requests to be added to `wl_display` and `wl_registry`.
slattann has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
<DemiMarieObenour[m]>
Specifically, a server supporting `wl_fixes` would provide a few things:
<DemiMarieObenour[m]>
- A destructor request for `wl_registry` objects.
<DemiMarieObenour[m]>
- Some way of handling removed global objects.
<emersion>
clients would need to create a (leaky) v1 wl_display to figure out they can bind to v2
<emersion>
so it doesn't really help
rasterman has joined #wayland
<SardemFF7>
Maybe a second socket, WAYLAND2_DISPLAY=wayland2-XXXX
<DemiMarieObenour[m]>
<emersion> "clients would need to create a..." <- Are you sure? The idea is that there is a new request defined for `wl_registry`. Clients will know that if the server exposes a `wl_fixes` global, they can use it.
<emersion>
change the wl_registry version at runtime? sounds terifying'
<DemiMarieObenour[m]>
no, just lie about it
<emersion>
i'd prefer to keep a clean API instead
<emersion>
we've found a workaround for the registry remove, and the leak exists but isn't so bad
<emersion>
i don't feel like adding huge hacks around is a good way forward
<DemiMarieObenour[m]>
emersion: I still want the leak fixed, and I think `wl_fixes` is the best way to do so.
<emersion>
why do you want the leak fixed?
<emersion>
does it cause an issue?
<emersion>
if it's just for perfection's sake…
<DemiMarieObenour[m]>
more generally, `wl_fixes` allows unfreezing `wl_display` and `wl_registry`
<DemiMarieObenour[m]>
their version numbers are now “whatever `wl_fixes` says they are” rather than being stuck at 1 forever
<emersion>
and you can't figure the version out before receiving the global event
<emersion>
so depending on the time at which the client interacts with the display/registry, its version might just magically change
<DemiMarieObenour[m]>
future changes would need to be 100% backwards compatible, but adding a destructor request certainly is
<pq>
wl_registry is created from wl_display with no way to set the version, so it inherits the wl_display version which is always 1. There is no API to force-change an existing object's version in libwayland, which means that seeing wl_fixes and attempting to send a v2 request will be cought by libwayland as illegal.
<DemiMarieObenour[m]>
hence the alternative approach of just not changing the version
<emersion>
your suggestion will just add exceptions and workarounds
<DemiMarieObenour[m]>
if I added a destructor event to `wl_registry` would anything break?
<emersion>
and will make the API harder to reason about
<emersion>
yes, old clients would
<DemiMarieObenour[m]>
s/event/request/
<emersion>
then old compositors would
<DemiMarieObenour[m]>
but they would not expose `wl_fixes`
<DemiMarieObenour[m]>
so clients would know not to use it
<dottedmag>
DemiMarieObenour[m]: Could you please describe the actual need behind the change? Something that clients or compositors could not do before it, and will be able to do after.
<emersion>
it seems like you're trying to fix a non-existing issue
<pq>
I think first you have to make a good case for why unfreezing wl_registry version has so significant advantages that it would be worth the complexity. Unfreezing wl_display is a whole another matter.
<dottedmag>
DemiMarieObenour[m]: "do" in the sense delivering any value to the user, not in the sense "speaking another request on the wire"
<emersion>
the awkwardless and cost just isn't worth it rn
<DemiMarieObenour[m]>
right now Mesa creates a secondary `wl_registry` object
<pq>
and as I said, "just do the new thing when you see wl_fixes" does not work I believe
<DemiMarieObenour[m]>
if `wl_registry` was a singleton there would be no problems
<emersion>
but there are no problems right now
<emersion>
we just have one or two extra objects leaked
<DemiMarieObenour[m]>
imagine there were a bunch of libraries like Mesa, all being loaded and unloaded.
<dottedmag>
DemiMarieObenour[m]: So the problem is extra output/input events sent to Mesa, and a few allocations?
<emersion>
these libs don't exist, yet
<dottedmag>
DemiMarieObenour[m]: I'm sorry, but you really need to back it up with observable data.
<pq>
unloading libs does not seem to happen much in practise, because it is so full of caveats even just from the dynamic linker perspective
<DemiMarieObenour[m]>
dottedmag emersion: yes, this is very much perfection for perfection’s sake
<dottedmag>
musl just gives up and does not unload libs at all.
<emersion>
ok, so not worth it imho
<jadahl>
would one "disable" (not unload) a lib that gets its wl_registry, it seems more sensible to work around the leak by caching it some how in that library
<DemiMarieObenour[m]>
pq: what would happen if the XML changed without changing the version number?
<pq>
what we should ensure, if it's not already, is that the "leaked" objects are freed when the client wl_display is destroyed. For the server that already works due to disconnecting.
<emersion>
jadahl: interesting… and i think this can work…
<emersion>
jadahl: hm, not quite
<emersion>
well
<emersion>
depends how it's done
<jadahl>
yea, it depends on this theoretical lib that doesn't exist
<DemiMarieObenour[m]>
Could libwayland-client provide an API that allowed multiple libs to use a single wl_registry?
<emersion>
but a wl_display could be destroyed and re-allocated with the same addr
<emersion>
yet talk to a different socket
<jadahl>
the lib would need to "attach" itself and be told to clear its cache if the wl_display went away
<pq>
DemiMarieObenour[m], lots of confusion followed by kabooms.
<DemiMarieObenour[m]>
pq: The actual wl_registry would be entirely encapsulated in libwayland-client; libraries would register callbacks for events on it.
<pq>
DemiMarieObenour[m], I think not bumping the version in XML would open a trivial way for any Wayland client to crash the server at will.
<DemiMarieObenour[m]>
pq: how?
<pq>
DemiMarieObenour[m], a client sending the new request to a compositor that does not advertise wl_fixes.
<DemiMarieObenour[m]>
how would that crash the server?
<dottedmag>
This sounds like a particularly shaky server. Buggy and malicious clients may send whatever they want.
<pq>
if you don't bump the version, then libwayland-server will not see that the requets is illegal and attempt to call a function pointer containing garbage.
<dottedmag>
Ugh. This means libwayland-server can't be used at all.
<pq>
dottedmag, wrong.
<pq>
dottedmag, this happens *only* if you deliberately break the protocol design by not bumping the version when adding a new request.
<DemiMarieObenour[m]>
how does libwayland-server handle versioning?
<pq>
DemiMarieObenour[m], with the same rules as Wayland protocol in general.
<pq>
it also leaks into each compositor, too
<DemiMarieObenour[m]>
OH I see I had not considered the case of a new libwayland-server and an old compositor binary
<dottedmag>
pq: Not sure I follow. Imagine the change only happens on the client: someone changed an XML file, rebuilt the client and the client sends imaginary wl_fixes request. How would a compositor using libwayland-server react?
<pq>
dottedmag, if the compositor is using an old libwayland-server, the request is seen as illegal, since it's unrecognized.
<DemiMarieObenour[m]>
I usually use Rust, where this simply can’t happen: even if one uses dynamic linking, a program must use the exact same Rust library at runtime it was compiled against.
<pq>
dottedmag, invalid opcode, not present in the interface.
<dottedmag>
pq: Ah, you mean a discrepancy between libwayland-server and the compositor?
<pq>
dottedmag, yes. libs can be updated without updating the programs using them. That's kind of the point of stable ABI.
<DemiMarieObenour[m]>
…which Rust (the language I use 99+% of the time) has no concept of.
<pq>
indeed
<DemiMarieObenour[m]>
(by design, at least so far, and for some very, very good reasons)
<dottedmag>
pq: I'd say the hash of the protocol (maybe with comments stripped) should be a part of ABI version then.
<dottedmag>
*of the protocol definition
<pq>
dottedmag, I can't imagine how that would work.
<DemiMarieObenour[m]>
It would work if one required cascading rebuilds, as Rust, Haskell, Go, OCaml, and probably many other languages already do.
<pq>
we do want and *have to* keep libwayland libs upgradable without rebuilding their users.
<DemiMarieObenour[m]>
Not having worked on a proprietary project in years has probably spoiled me ― the assumption for me has been that one can always recompile the world at will.
<DemiMarieObenour[m]>
What would happen if the wl_registry version was bumped? Obviously clients would need wl_fixes or similar to be notified of that fact.
<pq>
I doubt it would be always feasible even if everything was FOSS, libwayland is so near the bottom of the software stack.
<DemiMarieObenour[m]>
And not everything is an immutable container.
<pq>
you have the versioning problem as I said
<dottedmag>
DemiMarieObenour[m]: *Having* worked on a proprietary project has spoiled me too: having the world in a single monorepo rebuildable in minutes makes one forget such troubles. (versioning in network protocols is different story)
<DemiMarieObenour[m]>
pq: I thought wl_registry was entirely internal to libwayland.
<pq>
DemiMarieObenour[m], the server side implementation is, client side is not.
<DemiMarieObenour[m]>
In which case only libwayland would need to change, and libwayland can’t be ABI-incompatible with itself!
<pq>
you cannot assume that server and client are using the same libwayland version
<DemiMarieObenour[m]>
pq: this would only cause problems on the server side, but that isn’t a problem
<DemiMarieObenour[m]>
pq: old libwayland-client versions would never send the new request no matter what the server version is, because they would not know it existed.
<DemiMarieObenour[m]>
old libwayland-server versions would reject the request as invalid
<pq>
Sorry, but I really have no time to continue this discussion.
<pq>
You're free to experiment, but if you cannot come up with tangible benefits from fixing wl_registry versioning then I cannot find the time to review anything about it.
<DemiMarieObenour[m]>
Acknowledged
<pq>
others are totally free to discuss and whatever they like, of course, but I have to bow out.
<DemiMarieObenour[m]>
valid
slattann has quit [Ping timeout: 480 seconds]
bittin has joined #wayland
bittin has quit [Remote host closed the connection]
slattann has joined #wayland
rgallaispou has joined #wayland
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #wayland
tzimmermann has quit [Remote host closed the connection]