07:07 <psychon> hi, I just came across the chapter "X11 application support" in the docs: https://wayland.freedesktop.org/docs/html/ch05.html

07:07 <psychon> it says "it is strongly recommended to make all X11 communications asynchronous"

07:08 <psychon> that makes me wonder: how can I asynchronously "talk X11"? let's say I got a window id and what to get the window's size and coordinates - how would I do that?

07:23 <psychon> s/what to/want to/

07:34 <emersion> psychon: xcb without forcing roundtrips maybe?

07:34 <emersion> psychon: this doc has been written a long time ago

07:35 <psychon> yeah, well, xcb_get_geometry() sends the request and xcb_get_geometry_reply() blocks until the reply arrives

07:37 <psychon> I didn't choose this example beforehand, but first search result for "_reply" in wlroots/xwayland/xwm.c is exactly xcb_get_geomtry_reply() and this definitely is synchronous: https://github.com/swaywm/wlroots/blob/master/xwayland/xwm.c#L175

07:37 <psychon> (the request is sent in line 133 and from there to line 175, only xcb_change_window_attributes() is also called, so this is definitely not async)

07:38 <psychon> bummer :(

07:39 <emersion> yes, we aren't good at this in wlroots

07:39 <emersion> tbf, x11 doesn't make it very easy to reduce roundtrips

07:41 <emersion> it would be a bit annoying to asymchronously handle the geometry reply -- would need to delay the xsurface creation a bit

07:43 <emersion> maybe a first good step would be to group sending requests and receiving requests

07:43 <emersion> so that requests get sent in batches

07:43 <emersion> receiving replies*

07:44 <emersion> … tbh maybe a lightweight add-on on top of xcb that adds a wayland-like callback-based API would help make things more async

07:46 <emersion> ^ not sure it's a good idea, just throwing ideas around

07:47 <emersion> ah, and one other thing to note maybe: i'd say that roundtrips during "normal" operations are worse than roundtrips during init

07:47 <emersion> xwm or surface init happen relatively rarely

07:48 <emersion> otoh, roundtrip in logic like clipboard data transfers is pretty bad

07:49 <emersion> "pretty bad" as in "blocks the compositor for substantial (?) amounts of time for no good reason"

07:50 <emersion> i've already seen wlroots' xwm completely blocked on receiving a reply from the x11 server, fwiw

08:07 <psychon> a callback-based X11 API in C likely ends up being ugly since C has no closures... but I guess you already have that pain with wayland (although wayland is better designed for this)

08:08 <psychon> dunno if you already know this, but there is xcb_poll_for_reply() and you can use that to implement something like this... like, having a queue of pending requests and polling the head for a reply

08:11 <psychon> emersion: would you be interested in a PR that removes the string "_reply(" from wlroots/selection/* and replaces that with something callback-based (and likely more ugly than the existing code)?

08:16 <psychon> never mind, my meson is too old for wlroots

08:39 <emersion> xcb_poll_for_reply will still block right?

08:39 <emersion> (i'm assuming its use-case is threads)

08:43 <emersion> hm that's quite a few _reply instances to fix :S

08:46 <psychon> nah, it either sets sets its void** reply argument to the reply, or its xcb_generic_error_t** argument to the reply, or returns 0 if neither a reply or error was not received yet

08:46 <psychon> and it is documented not to block

08:47 <psychon> it is just like xcb_wait_for_reply() (which is all that e.g. xcb_get_geometry_reply() actually does), but additionally can return "nope, no reply yet"

08:47 <psychon> biggest downside with xcb_poll_for_reply() is that you get to mess with void* instead of having xcb_get_geometry_reply() cast the pointer to the correct type...

08:49 <psychon> or put differently (and a bit simplified): xcb_wait_for_reply() / xcb_get_geometry_reply() calls xcb_poll_for_reply() and if that returns "no reply yet", it calls select() to wait for the connection to the X11 server to become readable

08:49 <psychon> (and that begins again from the beginning)

08:49 <emersion> i see

08:52 <psychon> but even sending a request can block if xcb's output buffer is full and that can still lead to deadlocks (or better: every call to xcb_flush() also blocks)

08:59 <emersion> ah yes. https://github.com/swaywm/wlroots/issues/2502

09:10 <psychon> fun :)

09:11 <psychon> ugly hack to get rid of that hang: replace the X11 fd with the result of pipe() and start an extra thread that forwards from the pipe to the server and implements an infinite buffer size ;-)

09:22 <MrCooper> that would be consistent with the X server's unlimited client connection buffers :)

17:14 <wlb> weston Issue #516 opened by Tomasz Kłoczko (kloczek) 60855b15 master: test suite is failing https://gitlab.freedesktop.org/wayland/weston/-/issues/516

17:24 <wlb> weston Issue #517 opened by Tomasz Kłoczko (kloczek) 60855b15 master: weston is not LTO ready https://gitlab.freedesktop.org/wayland/weston/-/issues/517

18:14 <wlb> weston Merge request !657 opened by Pritama Biswas (pritbisw) Cleanup memory allocated to child processes at the time of exit https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/657

21:48 <antaxiom> Hello

21:50 <antaxiom> I've been trying to switch to a wayland compositor for a while, but I have been struggling with getting Xwayland to scale in an acceptable manner (eg. not blurred) for my HiDPi displays. Does anyone have any advice on the matter?