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
Lucretia has quit []
fmuellner has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
shashank1202_ has quit [Quit: Connection closed for inactivity]
rasterman has quit [Quit: Gettin' stinky!]
agners has quit [Remote host closed the connection]
agners has joined #wayland
boistordu_old has joined #wayland
boistordu_ex has quit [Ping timeout: 480 seconds]
c7s has quit [Ping timeout: 480 seconds]
c7s has joined #wayland
<DemiMarieObenour[m]>
Is weston-desktop-shell flexible enough to do most of what an X11 window manager can do?
leon-p has quit [Ping timeout: 480 seconds]
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #wayland
c7s has quit [Ping timeout: 480 seconds]
<DemiMarieObenour[m]>
Nevermind, the answer is no.
shashank1202_ has joined #wayland
lmat has quit [Remote host closed the connection]
lmat has joined #wayland
sadlerap has quit [Remote host closed the connection]
ManMower has quit [Remote host closed the connection]
sadlerap has joined #wayland
zebrag has quit [Remote host closed the connection]
ManMower has joined #wayland
pnowack has joined #wayland
novakane has joined #wayland
danvet has joined #wayland
leon-p has joined #wayland
jgrulich has joined #wayland
dcz_ has joined #wayland
mbalmer has joined #wayland
hardening has joined #wayland
rgallaispou has joined #wayland
hendursa1 has joined #wayland
<pq>
DemiMarieObenour[m], I don't understand how you can imagine that "X11 over Wayland" would help anything.
<DemiMarieObenour[m]>
pq: if there were issues due to X11 and Wayland protocol messages being reordered it could help XWayland. Of course this would be specific to XWayland and be unusable by any other client.
hendursaga has quit [Ping timeout: 480 seconds]
<DemiMarieObenour[m]>
The only purpose of this is to establish a total order between the X11 and Wayland messages being sent between XWayland and the compositor.
<DemiMarieObenour[m]>
No, I am not foolish enough to try to implement an X server in a Wayland compositor or any other nonsense like that.
<pq>
emersion, I don't have anything in mind for a wayland release, no. Release whenever you like.
<MrCooper>
DemiMarieObenour[m]: Xwayland doesn't use X11 itself, only Wayland, so I'm as puzzled as pq
<MrCooper>
I don't remember ever seeing or hearing about anything using X11 and Wayland at the same time
<emersion>
i… am guilty of an abomination like this
<emersion>
use X11 for everything, except YUV buffer imports which go through Wayland…
<pq>
MrCooper, the XWM in any Wayland compositor.
<pq>
DemiMarieObenour[m], if you shovel X11 messages as Wayland messages, then any code doing a blocking wait on a X11 reply will necessarily block all Wayland messaging forever, because a) you can't dispatch anything Wayland because you need the X11 reply first, and b) there is no way to "peek ahead" the Wayland message queue, there is only dispatch.
<MrCooper>
pq: O_o that uses the Wayland protocol?
<pq>
The only solution is to architect the code such that it "never" needs blocking waits for replies.
<pq>
MrCooper, of course: Xwayland and compositor talk to each using both Wayland and X11.
<DemiMarieObenour[m]>
pq: I don’t see a compositor using libX11 or libxcb being able to use this without significant improvements to the respective libraries. A compositor written in Rust using x11rb probably could, though, as IIRC that library is 100% asynchronous.
<pq>
wl_surface and content come via Wayland, and window state comes via X11 - othen times one needs both before the XWM in the compositor can act.
<pq>
*often
<DemiMarieObenour[m]>
yes, but one can write a state machine that handles that case
<SardemFF7>
can’t libxcb be used in a 100% async way? it is a bit tricky but doable IIRC
<pq>
DemiMarieObenour[m], if you can rework all code to be async, then you have no problem anymore: no need for X11 over Wayland.
<DemiMarieObenour[m]>
pq: are there cases where “which message came first” matters?
<DemiMarieObenour[m]>
because that is the one I am worried about
<pq>
DemiMarieObenour[m], between related X11 and Wayland messages? No in general, by definition, because the two streams are async wrt. each other.
<pq>
The problem is for example when the compositor needs to fetch state from the X server, and does that X11 roundtrip in a blocking way (i.e. bad code architecture).
pochu has joined #wayland
<pq>
if the X server is blocked for any reason, then the compositor is blocked as well, and the whole desktop freezes.
<pq>
Depending what the X server is blocking on, that stall could be temporary or forever (deadlock).
<pq>
SardemFF7, I think it can.
<pq>
the hard part is architecting the XWM such that you never block waiting for X11 replies
<DemiMarieObenour[m]>
I partly blame C for this. Rust makes this kind of stuff so much easier.
<DemiMarieObenour[m]>
It can be done in C but it is harder.
<pq>
sure
<pq>
We can even forget about Xwayland completely. A Wayland compositor should never (during normal operation) block waiting for anything, because that always means the display and input are frozen for that time.
<pq>
Even simple file I/O to disk could be a problem.
<jadahl>
sync file disk I/O can be much worse than sync X11
rasterman has joined #wayland
<DemiMarieObenour[m]>
<pq> "Even simple file I/O to disk..." <- Does that mean a compositor should do `mlockall()`? Because otherwise it could be blocked by the kernel at any time to page in stuff from disk.
<pq>
if you care about that, yes
<pq>
or run without swap
<pq>
(and disable dropping program text from memory)
Lucretia has joined #wayland
<pq>
that is triggered by an OOM situation usually, I was more thinking of accessing regular files in a compositor process.
<emersion>
like, xkb files for instance? :)
<pq>
yup
<pq>
Weston isn't perfect, but I think it's fairly close.
<pq>
shader compiling is another
<pq>
that could hit disk as well in the form of the shader cache
<DemiMarieObenour[m]>
Precompiled shaders using Vulkan?
<pq>
GLSL
<pq>
I don't know about Vulkan, but I suppose it might have a cache too
<pq>
Mesa has a on-disk compiled shader cache behind the scenes.
<pq>
so it's not something the app (compositor) needs to opt-in
<pq>
AFAIU
adia2 has joined #wayland
adia has quit [Read error: Connection reset by peer]
<DemiMarieObenour[m]>
Still, that should not be an issue if all shaders are compiled at startup.
<pq>
true
<pq>
Weston though still probably have a thousand or more different fragment shaders, and we're not going to compile them all at start-up, since most of them are never needed.
<pq>
s/still/will/
<pq>
Weston's shader complication is done in a blocking fashion anyway
<DemiMarieObenour[m]>
<pq> "Weston though still probably..." <- 1000?????? Wow!
<DemiMarieObenour[m]>
<pq> "Weston's shader complication..." <- Should they be compiled asynchronously on a worker thread?
<kennylevinsen>
Wasn't the plan to move to a mega shader or something?
<kennylevinsen>
DemiMarieObenour: that's a mesa implementation detail specific to the driver in use. Mesa creates a bunch of threads for compilation, disk cache management and what not.
<kennylevinsen>
I don't really like those threads, especially when applications don't swap shaders, but eh
dcz_ has quit [Ping timeout: 480 seconds]
<pq>
kennylevinsen, yes, we already have a single shader source, but we build it multiple times with different build-time constants.
<pq>
the combinatorial explosion of those constants is what I expect to lead to around a thousand different variants.
<emersion>
vulkan shaders aren't pre-compiled for the target hw
<emersion>
they are some IR
<emersion>
the driver still needs to compile that to the GPU ISA
<pq>
DemiMarieObenour[m], Weston lacks the infrastructure to postpone scenegraph changes arbitrarily, so a thread would not win anything anyway, the shader is needed immediately for the already-started repaint.
<pq>
what we could do is kick off the shader compilation earlier and let Mesa thread it under the hood by not asking for the result immediately.
<pq>
that is, instantiate shaders at the time a... hmm. color transformation object is created. But we don't create those ahead of time. Oh well.
dcz_ has joined #wayland
flacks has quit [Quit: Quitter]
flacks has joined #wayland
<DemiMarieObenour[m]>
<pq> "that is, instantiate shaders..." <- Could those be created ahead of time?
<daniels>
you could opportunistically pre-compile all the shaders for every possible combination ahead of time, but then you've burnt startup time (and memory) compiling 1000 shaders ...
<DemiMarieObenour[m]>
daniels: Could the shaders be made to instead use run-time branches? Or would that be too slow? All of the branches would go the same way for a given shader run, so there would be no problems with warp divergence.
<DemiMarieObenour[m]>
Slightly silly idea I had: a rootless compositor with a Wayland backend, whose job is to basically turn a barebones compositor into a full-featured one.
<daniels>
DemiMarieObenour[m]: they could, if that was a problem to optimise for, but you're going to use very few variants at actual runtime, which are quick to compile, and when they compile it's invariably associated with a state change like a new window, where you don't have an instant response anyway
<daniels>
if it was causing random runtime hitches during what should otherwise be steady-state smooth animation and timings, that would be a problem to fix, but currently I don't see how that would solve any real problem
shashank1202_ has quit [Quit: Connection closed for inactivity]
fmuellner has joined #wayland
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
shashank1202_ has joined #wayland
Lucretia has quit []
Lucretia has joined #wayland
<swick>
it would also be possible to generate a uber-shader variant which could be used if a particular variant has not been compiled yet but again... not really a problem right now
<swick>
I have been wondering how much of a benefit rusts async programming model would be
<swick>
it would at least make it much easier to get rid of most blocking but in practice most blocking in compositors right now is not a big deal
* hardening
thinking of waht could be a UBER shader...
<jadahl>
swick: couldn't that cause issues with too fat shaders that some arm devices wouldn't be able to fit?
dcz_ has joined #wayland
<swick>
the current weston shader is still really small as an uber shader but yeah, it obviously makes it harder to run than a specific variant
<MrCooper>
could fall back to what we're doing now if the übershader doesn't compile?
shashank1202_ has quit [Quit: Connection closed for inactivity]
<DemiMarieObenour[m]>
For Wayland v2 and/or for something enabled with `wl_fixes`: Would a `wl_display.rename_object` event (with corresponding `wl_display.delete_id` acknowledgement) be a good idea? The purpose of this is to compact the object ID table. The old ID would still be usable until the event was acknowledged, avoiding races.
<DemiMarieObenour[m]>
Or perhaps have both client and server be responsible for compacting objects they created.
<DemiMarieObenour[m]>
This would go along with a mandatory `destructor=` on destructor events, allowing the client to ack (via `wl_display.delete_id`) every time an object is deleted.
jgrulich has quit [Remote host closed the connection]
<kennylevinsen>
DemiMarieObenour[m]: not sure if we have any actual use case for defragmentation
<DemiMarieObenour[m]>
kennylevinsen: avoiding memory leaks in certain cases
<DemiMarieObenour[m]>
Levans helpfully pointed out that a `wl_map` that handled fragmented object maps without wasting memory would be slower in the common case, so I came up with defragmentation as an alternative. Of course, it would be handled internally by client and server libraries.
<kennylevinsen>
That only matters if a client has a massive peak number of objects and never goes up there again, but fair
<kennylevinsen>
Well more specifically, has a massive peak of temporary objects and a permanent objects allocated at the peak, after which the temporary objects are deallocated.
<kennylevinsen>
So it's a bit specific
<dottedmag>
Why ever touch the protocol for a trivial problem in client library?
<DemiMarieObenour[m]>
kennylevinsen: yes, it is a bit specific, but I think it is at least worth queueing for “what would we do the next time around”
<dottedmag>
This is a complication for a single client library that can't deal with non-contiguous IDs efficiently? Sounds like a bug to file for client library and fix it there, not push it to the wire where *every* implementation in the world has to deal with this.
<DemiMarieObenour[m]>
dottedmag: right now, object ID lookups are just a bounds check and array subscript. To efficiently support non-contiguous object IDs, one would need to use a B-tree or similar ordered map.
<dottedmag>
Hash map gives you amortized O(1).
<dottedmag>
What else?
<DemiMarieObenour[m]>
dottedmag: yes, but it is much slower than bounds check + array subscript.
<DemiMarieObenour[m]>
Especially if one doesn’t want to be vulnerable to HashDoS
<dottedmag>
Do you have ANY data to back it up that it's a problem?
<DemiMarieObenour[m]>
Also, a hash table might not allow compatibility with existing servers, due to the “must pick first free object” requirement
<DemiMarieObenour[m]>
and this affects every client AND server library I am aware of, not just libwayland-{client,server}
hendursa1 has quit []
hendursaga has joined #wayland
<DemiMarieObenour[m]>
This would require explicit opt-in on both sides, since currently implementations are allowed to assume object IDs never change.
<dottedmag>
Ugh, tracking free objects would require a heap, and that's O(logN).
<DemiMarieObenour[m]>
Exactly!
<DemiMarieObenour[m]>
Whereas compaction is O(1) and can be incremental
leon-p has quit [Quit: leon-p]
<dottedmag>
That ("first free object") is a very unfortunate wording in spec, I'd say.