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]
jhweruyuw has quit [Remote host closed the connection]
<romangg>
pq, emersion: thank you for your input on the compositor configuration question. I'm on the road today but I saved your conversation and will ask you about it some more later this week. :)
leon-p has joined #wayland
tzimmermann has joined #wayland
dcz_ has joined #wayland
spstarr has joined #wayland
spstarr has quit [Remote host closed the connection]
shashank1202 has joined #wayland
hardening has joined #wayland
muhomor has joined #wayland
danvet has joined #wayland
Lyude has joined #wayland
Lyude has quit []
Lyude has joined #wayland
mooff has quit [Remote host closed the connection]
mooff has joined #wayland
rgallaispou has joined #wayland
<ofourdan>
Humm, I was looking into https://gitlab.freedesktop.org/xorg/xserver/-/issues/1222 yesterday, basically with wl_shm mapping a lot of surfaces at once ends up flooding the socket and Xwayland gets killed (or at least the connectio nto the Wayland compositor) - I am not sure what to do from the client (Xwayland) perspective here, most of it happens behinds our back between libwayland and the Wayland compos
<ofourdan>
itor. What do you reckon?
dcz_ has quit [Ping timeout: 480 seconds]
<ofourdan>
To add to the problem, even waiting in libwayland won;t solve the issue as we'll end up in a deadlock situation, the Wayland compositor being an X11 client as well…
<DemiMarieObenour[m]>
ofourdan: What if everything was asynchronous and non-blocking?
<emersion>
what kind of message is flooding the socket?
<emersion>
DemiMarieObenour[m]: this is the case
<ofourdan>
emersion: wl_shm_create_pool() seems to be what triggers the issue
<emersion>
so… wl_shm_create_pool() takes time for some reason in the compositor (mmap?)
<ofourdan>
possibly yes
<ofourdan>
I do not know exactly what takes time in the compositor, but mappign an X11 window requires quite a few ops in the X11 WM
<emersion>
would be nice to investigate
<ofourdan>
(fwiw, it fails the same in weston which uses XCB)
rasterman has joined #wayland
<emersion>
oh okay, so it's not a compositor bug at least
<ofourdan>
thing is, we can try to work around the issue but it won't solve the problem at its core
<DemiMarieObenour[m]>
I think this is a libwayland limitation. libwayland should either offer fallible functions that return `-EAGAIN` or just queue the outgoing messages.
<emersion>
well, i was thinking if the compositor does a bad list traversal or something which ends up being O(n²), that outcome would be expected
<ofourdan>
same happens with weston, sway, etc.
<ofourdan>
DemiMarieObenour[m]: I tend to agree, yes
<emersion>
there's an issue about full sockets on the wayland issue tracker
<emersion>
i've assumed you've read it?
<emersion>
i assume*
<ofourdan>
yes, I have, I even mention your last comment :)
<DemiMarieObenour[m]>
emersion: not that I can remember but I will look
<emersion>
ah yeah
<emersion>
well i don't think there's a magical solution here
<ofourdan>
oh, even if not magical :)
<emersion>
growing the socket buffer unbounded is a bad idea, as discussed
<jadahl>
growing the queue indefinitely in libwayland-client could maybe be an option? it doesn't have the same implications as doing so in libwayland-server
<DemiMarieObenour[m]>
jadahl: Not a huge fan tbh; I prefer explicitly returning `-EAGAIN` so that clients can handle it in their event loops
<jadahl>
DemiMarieObenour[m]: that would be rather invasive in the clients
<DemiMarieObenour[m]>
It is always possible to avoid blocking the event loop
<ofourdan>
DemiMarieObenour[m]: how would you handle a client doing an XSync() then?
<DemiMarieObenour[m]>
ofourdan: From my perspective a Wayland compositor that does XSync() is buggy.
<DemiMarieObenour[m]>
Especially since I envision a future in which there is one X server per sandbox, and the X servers are considered untrusted.
<emersion>
this isn't practical sadly
<emersion>
X11 wasn't designed this way
<ofourdan>
Maybe, maybe not, but remember that Xwayland is for legacy applications that won;t be ported to Wayland native ever, precisely those you won't rewrite…
<ofourdan>
so not realistic
<DemiMarieObenour[m]>
ofourdan: Of course normal X clients can and will use XSync() as they wish. I am specifically referring to XWayland implementations in Wayland compositors. Those should, IMO, be changed to not use XSync().
<DemiMarieObenour[m]>
There is already a warning somewhere about doing this.
<ofourdan>
there are points of synchronization in Xlib itself
columbarius has joined #wayland
<ofourdan>
so you'd need torewrite Xlib :)
<DemiMarieObenour[m]>
ofourdan: Or throw it out in favor of either a hardened XCB or x11rb 😄
<ofourdan>
anyway, I'd rather we discuss practical and realistic ways to solve the issue
<ofourdan>
I do not want to rewrite half of the graphics stack in the process
co1umbarius has quit [Ping timeout: 480 seconds]
<DemiMarieObenour[m]>
What about moving all XCB work in compositors to a separate thread?
<emersion>
yeah, no
<emersion>
we said "realistic" :P
<emersion>
and also it'd be… not pretty
<emersion>
(the XWM shares a lot of state with the wayland compositor)
<DemiMarieObenour[m]>
<emersion> "Demi Marie Obenour: functions..." <- Functions queueing messages don’t return errors *today*, but they can be made to with just one API function: a call on a `wl_display` that puts libwayland in a fallible mode. Then clients can set `errno` to 0 before making a call, and check that `errno` is 0 after the call returns.
<emersion>
and do this for each and every call
<DemiMarieObenour[m]>
yes
<DemiMarieObenour[m]>
or use autogenerated wrappers
<emersion>
that doesn't sound fun at all
<emersion>
libwayland does generate wrappers…
<emersion>
wayland-scanner*
<DemiMarieObenour[m]>
emersion: use return values and `-fwarn-unused-result`, and the compiler will catch the bugs
<DemiMarieObenour[m]>
Is a per-sandbox instance of Xwayland a good idea in the future?
<jadahl>
an ever growing client side buffer sounds much less annoying tbh
<DemiMarieObenour[m]>
All the way until the OOM killer bytes
<ofourdan>
I think unbound socket for the client might be our best bet here as jadahl suggested!
<jadahl>
DemiMarieObenour[m]: indee
<jadahl>
d
<ofourdan>
DemiMarieObenour[m]: the number of X11 resources is not unbound, so we''l reach a limit at some point ofc, just a lot later that now
<DemiMarieObenour[m]>
you mean users won’t like having to handle the case where the connection is full and they must throttle themselves?
<jadahl>
it's less of an issue than an ever growing buffer server side
<emersion>
jadahl: agreed
<DemiMarieObenour[m]>
yes, but network services still manage to avoid it
<emersion>
maybe pq has thoughts on this
<jadahl>
DemiMarieObenour[m]: was going to say Wayland clients are not network services, but then remembered we're talking about Xwayland :D
<ofourdan>
I can file an issue to keep a trace of the discussions if you will, I don;t think this is a dupe of issue #159
<jadahl>
agreed, it's not the same as 159
<ofourdan>
jadahl: Xwayland doesn't listen to tcp either :)
<jadahl>
it's similar, but not the same
<jadahl>
ofourdan: maybe it should!
<DemiMarieObenour[m]>
jadahl: The point about bounding buffers and checking return codes still stands.
<ofourdan>
I do have patches from several years ago to allow for it :)
<ofourdan>
(tcp, I mean)
<DemiMarieObenour[m]>
In the compositor ⇒ client case, the main source of events (as far as I can tell) is the user, who is human and so cannot be throttled 🤣
<DemiMarieObenour[m]>
jadahl: also, clients who *want* to throttle themselves should be able to do so
<jadahl>
maybe so
<DemiMarieObenour[m]>
and I can very much imagine good reasons for this ― consider a network client that receives events from a server at a steady rate, and needs to know how much it should batch them.
<DemiMarieObenour[m]>
I used to work on Rust network services, where backpressure and denial-of-service prevention is absolutely critical.
<jadahl>
not sure DoS management is relevant here. here the OOM killer will do its job, and the compositor should handle illicit behavior in its own way e.g. by terminating clients doing excessive things
<DemiMarieObenour[m]>
jadahl: to elaborate: clients might very well *want* to queue messages, but they need to have the option to do so or not.
<DemiMarieObenour[m]>
jadahl: It isn’t relevant per se, since the compositor is trusted, but it shows that writing backpressure-aware code is possible and practical.
shashank1202 has quit [Quit: Connection closed for inactivity]
<DemiMarieObenour[m]>
<romangg> "Demi Marie Obenour: "I have..." <- That is basically the case, though I would not be able to use your library due to programming language differences.
andreas has joined #wayland
andreas has quit []
<jadahl>
DemiMarieObenour[m]: i see why it could be useful to get EAGAIN errors when trying to send requests, but probably not what e.g. xwayland wants to do
<DemiMarieObenour[m]>
jadahl: Could Xwayland throttle its own clients?
<jadahl>
it can "pause" clients. the drm lease MR does this for example to avoid xwayland doing a roundtrip
<ofourdan>
the Xserver has the notion of priority for X11 clients
<jadahl>
is priority the same as throttle?
<jadahl>
as in low priority will slow ti down?
<ofourdan>
well, it's designed to avoid one single client to take all the xserver busy for itself
<jadahl>
then a single client will not really get throttled if its the only one being noisy
<ofourdan>
would that be enough to avoid the issue, I am not sure
<emersion>
libwayland should already do it i think?
<emersion>
(not just flush, copy libwayland's buffer to the socket before that)
<jadahl>
ofourdan: poll on the fd and flush the lib side buffers when space is available. but I guess it should already do that
<emersion>
grumble grumble gitlab adding avatars in commit messages and messing up copy-pastes
<SardemFF7>
Happen ".patch" to the commit URL?
<SardemFF7>
Append*
<ofourdan>
so what happens with the variable-connection branch is 1. On weston (using XCB) it dies with the exact same error "request could not be marshaled: can't send file descripton", on g-s (using Xlib) it deadlocks
<ofourdan>
*descriptor
<DemiMarieObenour[m]>
emersion: grumble grumble not everyhing using signed commits and distrusting the infrastructure
<SardemFF7>
(WTH happened to my English…)
<MrCooper>
ofourdan: same error indicates there are still places erroring out instead of queuing?
<ofourdan>
I believe it errors out at the exact same place, the error beign the same
<ofourdan>
There is however something weird there, there is another error that wasn't there in the current code, "(EE) Unknown parameter: ?2004"
<ofourdan>
could be a bug in the branch as well
jgrulich has joined #wayland
bgs has quit [Remote host closed the connection]
bgs has joined #wayland
<ofourdan>
even with the variable-connection branch we still get to a EAGAIN in wl_connection_flush() calling sendmsg()
<emersion>
that's expected, but the branch is supposed to handle this case and grow the send buffer as needed?
<ofourdan>
emersion: except thios is with the branch, so might be that it doesn;t account for all cases maybe… Filling an issue now, so we can continue in gitlab and not lose the discussion
<pq>
DemiMarieObenour[m], when libwayland API was designed, there was a quite deliberate choice that request sending functions cannot fail gracefully, instead they disconnect. It would be unimaginable pain to be able to handle everything single request potentially fail to send, it just not realistic combined with the fact that Wayland design depends on reliable message delivery and strict ordering.
<pq>
DemiMarieObenour[m], also, if sending a message succeeded, you cannot roll back, and restart your higher level operation. You would need to restart at that exact message that failed to send.
<pq>
ofourdan, as you already found out, it's not just bytes that can overflow, but fds as well, I think.
<pq>
and wl_shm_create_pool sends an fd
<emersion>
oh right
<ofourdan>
that's exactly that
<emersion>
hm but libwayland should handle this case already with its 4096 byte buffer?
<pq>
fds are not bytes
<pq>
not at the socket level at least
<emersion>
yea
<pq>
maybe the kernel socket buffer refuses to hold very many fds? or maybe the fd vs. bytes accounting is not as pessimistic as the test case here
<pq>
in libwayland
<DemiMarieObenour[m]>
<pq> "Demi Marie Obenour, when..." <- I take it that did not account for the backpressure situation?
<pq>
DemiMarieObenour[m], probably not - what do you mean by backpressure situation?
d_ed has joined #wayland
<kennylevinsen>
DemiMarieObenour[m]: the general intention was that request rate is limited and not servicing your buffer, or spamming the compositor was always a fatal client bug and should just be killed
<kennylevinsen>
And if you were even near the limit you were broken
<kennylevinsen>
Backpressure in this case would just allow you to sustain such a condition, which would always have been erroneous
<kennylevinsen>
Now we have high speed input events (mice primarily) which have a fun issue where backpressure is needed from compositor to client, and Xwayland is a legitimate case for needing backpressure as it proxies many clients...
<kennylevinsen>
But a client spamming the compositor is probably best killed regardless instead of giving it ways to sustain a DoS...
<pq>
that is a good point, especially as the libwayland-server has no way to prioritise or throttle client serving
<kennylevinsen>
Also, signed commits are too much work. Signed tags is where it's at. Only releases truly matter anyway...
<pq>
signed commits also do not quite work with the rebase-based workflow
<pq>
Ideally, commits would be signed by reviewers as well, if we went for signing commits.
<kennylevinsen>
Or email-based workflows (there are TENS of us!)
<kennylevinsen>
Maybe for something like pijul/darcs it would work, but then you need to validate every patch in the history.
<pq>
It doesn't matter who the author is, it matters more who the reviewers are and who merged the thing.
bodiccea_ has quit [Quit: Leaving]
<pq>
What is the concept of "backpressure" in IPC?
<pq>
*It doesn't matter *for the project*... for the author itself it might matter than no-one can impersonate him
<kennylevinsen>
No one can't impersonate me. My bugs are too unique to replicate.
<kennylevinsen>
I should patent bug-fingerprinting
<jadahl>
sounds like the south park about emoji fingerprinting :P
<jadahl>
*episode
pboxx has joined #wayland
<pboxx>
hi, I am having a problem and I can't start gnome. the error doesn't say much: "something has gone wrong. the system can't recover". I checked the logs and I think it may be related to this error: kernel: gnome-shell[2927]: segfault at 18 ip 00007fe2604d7e8c sp 00007ffc69189f20 error 4 in libffi.so.7.1.0[7fe2604d3000+6000]
<kennylevinsen>
pq: backpressure would be that the client ultimately stops/slows events when the server fails to process fast enough, waiting to gracefully recover from the situation. Basically what we want to do compositor-side for high-speed input-events to not murder clients when using 1 gajillion DPI mice
<pboxx>
can anyone help me?
<jadahl>
pboxx: sounds like a gnome issue; either head to #gnome-shell on irc.gnome.org or file a bug on mutter
<pboxx>
ok I tried on #gnome but will try on #gnome-shell
<pboxx>
thanks
d_ed has quit []
d_ed has joined #wayland
slattann has joined #wayland
<pq>
kennylevinsen, ok, thanks. Sounds like for window updates we have that in check already with frame callbacks, but input in the opposite direction is indeed open.
dcz_ has joined #wayland
slattann has quit []
jgrulich has quit [Ping timeout: 480 seconds]
leon-p_ has joined #wayland
leon-p has quit [Ping timeout: 480 seconds]
bodiccea has joined #wayland
Lucretia has quit []
Lucretia has joined #wayland
<zzag>
jadahl: how does mutter handle input on a separate thread? is it simply gathering input events in that thread and after some interval synchronizes with the main thread? or does mutter do something more sophisticated?
<zzag>
been wondering what can be done against "Libinput: client bug: timer event25 debounce short: scheduled expiry is in the past (-2ms), your system is too slow"
<emersion>
stop blocking in your compositor probably
<zzag>
heh, I don't think it's possible
<emersion>
why not?
<emersion>
if something is blocking and has a good reason to block (e.g. computes stuff), it's a good idea to put that thing in a thread
pnowack has quit [Quit: pnowack]
<emersion>
but the main thread blocking is a bad idea in general, and putting libinput in a thread is a workaround
<zzag>
because the main thread is a somewhat busy place, e.g. it performs rendering, processes wayland events, etc; it's worth investigating why it blocks for so long
<zzag>
but I've seen that warning message with other compositors as well
<zzag>
(sway is one of them)
<emersion>
could be because the system is slow in general
pnowack has joined #wayland
<emersion>
e.g. a game is pumping up all of the CPU time
<emersion>
a thread won't help at all in that case
<zzag>
that doesn't seem to be the case, I have "Intel i7-9700F (8) @ 4.700GHz" and there is no any cpu-bound process that could hog precious computing resources
<emersion>
well, it'd be a good idea to investigate what happens exactly then
<emersion>
2ms seems like a long time
<emersion>
another thing to note, i know sway isn't very good at not blocking, for instance shm uploads are blocking
<emersion>
this is somewhat of a GL limitation, but there are extensions to improve this
<zzag>
right, uploading stuff from shm buffers is something that can sink performance
<jadahl>
zzag: libinput lives in a thread, internal events are generated and eventually queued to the main thread. there are some changes to how event compression is done, but it is somewhat blocked on libwayland-server allowing us to handle the outbound socket being full
<zzag>
jadahl: hmm, mutter does pretty much the same what kwin does. oh, well, I'll continue debugging
<ofourdan>
top
<ofourdan>
oops
<ofourdan>
(wrong window)
koevet has joined #wayland
leon-p_ has quit [Remote host closed the connection]
<swick>
pq: was there anything interesting in the last w3c hdr session?
<swick>
was hiking that day
leon-p has joined #wayland
<pq>
swick, it was less interesting. It was mostly about how do the web elements work and blend inside a compositor, with the added twist that the browser cannot tell the page script the display capabilities (without end user opt-in) because display capabilities are client fingerprinting material.
<swick>
daniels: wanted to watch your presentation timing talk at LPC. was is moved to another slot or did it just not happen?
<pq>
other than that, browsers seems to have pretty much the same compositing problems as Wayland compositors. Sometimes just made harder due to internal and CSS design decisions.
<pq>
err, how do the web elements work and blend inside the *browser*
<swick>
ah yeah, browsers really have a bit of a harder problem with leaking as little information as possible
<pq>
there seemed to be an assumption that a browser could deliver multiple SDR and HDR layers to the winsys for compositing, or do it all itself.
* emersion
didn't even realize LPC was going on
<pq>
..which is fine as we have sub-surfaces - now only if we had defined blending rules between sub-surfaces
<swick>
I suspect that browsers are going to do both to some degree
<pq>
yup
<swick>
but yeah, nothing new really
<swick>
emersion: there was a dma heap talk ;)
<pq>
they were also concerned about an SDR web page having a thousand tiny HDR elements making life hard :-)
<swick>
if they're all the same kind of HDR that shouldn't really matter?
<swick>
as soon as they have different properties it might become a problem
<pq>
depends on how they are layered, does it result in a thousand more layers
<swick>
oh yeah, that too
<pq>
also CSS blending is defined to be in sRGB non-linear, which is going to be fun to fit with HDR elements
<pq>
because cannot regress all the existing web sites in the world
<swick>
heh, yeah, they'll have to do some weird roundtriÃps there
<swick>
but IIRC there was some talk about blending in other spaces?
<swick>
same with gradients
<pq>
an interesting issue they will have is text rendering with WCG/HDR colors into sRGB SDR page
<pq>
because CSS makes all kinds weird combos possible
leandrohrb0 has quit []
fahien24 has joined #wayland
leandrohrb3 has joined #wayland
<pq>
well, yeah, the choice of the color space makes a difference to blending and interpolation, one space doesn't fit all
<pq>
I'm *so* glad Wayland does not spec anything about blending or interpolation. :-D
<pq>
yet, at least
<swick>
in some way not having anything specified about color makes our lives a bit easier now
<pq>
yup, we can paint ourselves into a corner later ;-)
<swick>
daniels: the one thing I noticed when working on the present timing stuff is that it's really hard to reason about all the moving parts
<swick>
and it's also really hard to change things across the stack
<swick>
it would be extremely useful to have some kind of timing simulation of display hardware, kms, compositors and clients
<emersion>
interesting twist, ofourdan
<ofourdan>
emersion: yeah, I start to have my doubts on the fixability of that issue in Xwayland itself :)
<emersion>
likely window decorations right?
<ofourdan>
or just reparenting
<ofourdan>
g-s is a reparenting window manager
<ofourdan>
so when it gets 500 MapRequest from the X11 client it will in turn as many X11 toplevel windows to reparent the client windows
<ofourdan>
in turn *create
<emersion>
right
<ofourdan>
is sway a reparenting window manager?
koevet has quit []
<emersion>
nope
koevet has joined #wayland
JoshuaAshton has quit [Ping timeout: 480 seconds]
<daniels>
swick: that got rearranged at the last minute because of other cascading scheduling changes, so we took in the cgroups-for-GPU-resources/runtime talk; looking at the audience who was there, tbh there wouldn't have been any useful discussion around pres-time, whereas we actually got a lot from the cgroup discussion
<daniels>
swick: re timing simulation - yes, absolutely
<daniels>
I mean diagrams are vaguely useful but one thing that jumped into my mind was Jasper's old writeups of X11 which included interactive bits
<daniels>
being able to expose + adjust + visualise would be super powerful I think