08:22pq: kchibisov, I don't understand why you would need to know when the compositor is done destroying things. The moment a client sends a destroy request, the protocol object is gone from client perspective. Any incoming event marshalling in the client would drop events coming through the destroyed object, and turn event arguments with the destroyed object to NULL.
08:23pq: kchibisov, not reading the connection is hazarduous; the compositor might even add and remove wl_registry globals enough to overflow the connection buffers.
08:27pq: swick[m], how would a client know which parts of such profile a compositor is applying and which not? Or does it make no difference?
08:27pq: swick[m], hmm, I guess it makes no difference if the client is also using the same image description for its surface.
08:28kchibisov: pq: I might have profiled the issue wrong, but I think my surface was still shown even though I've destoreyed it.
08:28kchibisov: And only roundtrip made it go away.
08:29kchibisov: The issue though is that we can't really destroy the event loop, but we want suspend it after it run for a while.
08:31pq: kchibisov, yes, compositors can keep showing your surface after you have destroyed it, and even after the compositor has fully processes the wl_surface destruction.
08:31pq: but it'll be just a frozen image as the client obviously has no means of updating it anymore, and the compositor has no means of sending e.g. input to it anymore
08:32pq: it's mostly used for window closing animations
08:32kchibisov: But why they show it indefinitely, if everything related to it is gone?
08:32pq: sounds like compositor bug?
08:32pq: or maybe you didn't actually flush the destroy request out?
08:33kchibisov: Hm, that could also be the case.
08:38pq: kchibisov, if you do a protocol dump on the compositor side, that would tell if you forgot to flush.
08:38kchibisov: Yeah, I've added a flush and it worked.
08:39pq: cool
08:40pq: usually a flush cannot be forgotten, because the main event loop always flushes before sleeping
08:40kchibisov: Now I wonder what should I do wrt not reading connection. Maybe I should start a background thread on demand?
08:41pq: Any reason you can't simply let your main event loop sleep and run?
08:42kchibisov: I can't in this case.
08:42pq: why?
08:42kchibisov: API parity.
08:42pq: *facepalm*
08:43pq: well, another approach is to have a separate reading thread always.
08:44kchibisov: it just comes from macOS where you can't destroy the loop. And there's a demand to run event loop for a short period of time and destroy everything when returning from event loop callback.
08:44pq: is this using libwayland-client or something else?
08:44kchibisov: Partially yes.
08:45kchibisov: I suspend the loop only after destroying everything though.
08:45pq: that demand sounds quite wonky
08:46kchibisov: you can't recreate the event loop on macOS.
08:46pq: I'm confused why anyone would even want to destroy the event loop unless the process is exiting.
08:47kchibisov: The don't want to run the event loop on constant basis.
08:47kchibisov: Because they have their own event loop.
08:47pq: why? it just sleeps when there is nothing to do, right?
08:48kchibisov: It's not like you have epoll everywhere, so you have to actually run and listen.
08:48kchibisov: Which they don't want to.
08:48pq: it's conceptually impossible to have two main event loops, and a bad idea to have multiple event loops. They should be properly integrated into one instead.
08:49pq: epoll is not the only way to integrate events loop, though it is likely one of the simplest
08:49pq: *event loops
08:50kchibisov: Be aware that event loop means not display server loop or even Wayland related loop.
08:50pq: I know.
08:50pq: It sounds like home-grown event loops that are not portable enough. Using a proper portable event loop library would solve that, but it also ties one to the library.
08:52pq: Any design where a single thread is expected to spin more than one independent event loop seems like a very bad idea to me. I'm sorry if others have decided to impose that on you.
08:56kchibisov: Are you aware that macOS or Windows event loop can't integrate into anything?
08:56pq: No, but I'm also not surprised: everyone is supposed to use them and nothing else, right?
08:57kchibisov: They simply run macOS loop ondemand, because it's a gui only thing.
08:57kchibisov: And the rest handle with kqueue.
08:57pq: oh, I didn't expect the OS to conflict itself like that. How does it work at all?
08:58kchibisov: At least I've seen things like that...
08:58kchibisov: They have special proprietary stuff for their gui stuff.
08:58kchibisov: It's TCP connection iirc, but it's not near stable.
08:58pq: Do you have to choose a thread being either gfx or non-gfx, and switching or combining is not possible?
08:59pq: or is it even a process-wide decision?
08:59kchibisov: I don't quite understand that, but the thread for GUI is bound to main application thread.
09:00kchibisov: And if you try to touch gui stuff outside of it it sigills.
09:01pq: ok, that sounds extremely painful for any library that would like to be portable
09:01kchibisov: That's the reason I don't look into macOS that much myself.
09:02pq: and the library really odd to use for anyone who hasn't developed for macOS
09:02kchibisov: Well, you can make X11/Wayland behave.
09:03pq: yeah, but the library API has to live by the most restrictive OS it supports, and that would be surprise to a library user who doesn't know the most restrictive OS
09:04pq: imposing restrictions and designs that seem unncessary on everything one knows about
09:04kchibisov: We have alternative event loop APIs. The common one assumes that you run everything from the event loop.
09:05kchibisov: And you can't rerun it.
09:07pq: On one hand, it makes perfect sense to me that all GUI stuff is limited to one thread at a time, and exiting the event loop means closing the display connection. That's how Wayland was supposed to work originally.
09:08kchibisov: The most restrictive is iOS though, but we gave up on idea to design around it.
09:08pq: aha
09:10kchibisov: You simply setup a callback for it and then you pass the entire control flow from your app to ffi function.
09:11kchibisov: The similar situation is on wasm, your code is run async by the browser so you can't just block in `main` and wait for event loop to exit.
09:12kchibisov: So we sort sort of decided that ppl who really want to deal with all of that are on their own and we just try our best to provide robust handling of all of that.
09:13kchibisov: GUI toolkits are expected to wrap all of that mess into something nice, like they could all make a #[my_gui_toolkit:entry] and handle all event loop details for the users.
09:14kchibisov: Such wierd platforms come with an extra glue code you must write inside your main, like setuping subclass of java activity class on android.
09:38wlb: wayland-protocols Issue #151 opened by Simon Ser (emersion) Members meetings https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/151
09:45emersion: drakulix[m]: ^
09:51pq: btw. when I said "all GUI stuff", that excludes actual drawing.
10:03wlb: weston Issue #772 opened by Jim B (d3x0r) WSL2 and xwayland cause weston to crash https://gitlab.freedesktop.org/wayland/weston/-/issues/772
10:04any1: What about adding a new namespace that's like ext but with even lower "priority"? Could be called opt for optional?
10:29wlb: wayland-protocols Merge request !230 opened by Jonas Ådahl (jadahl) xdg-shell: Add edge constraints https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/230 [xdg-shell], [In 30 day discussion period], [Needs acks], [Needs review], [Needs implementations]
10:48wlb: wayland-protocols Merge request !231 opened by Jonas Ådahl (jadahl) Add staging system bell protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/231 [In 30 day discussion period], [New Protocol], [Needs acks], [Needs review], [Needs implementations]
10:51jadahl: drakulix[m]: mind if I edit notes from yesterday to add the part about the known type-to-search bug and the intended fix & action item?
10:52jadahl: oh you added! nm
10:53drakulix[m]: That one should be in there, but no in general I don't mind other people editing it, that is why I added the disclaimer at the top.
10:53jadahl: ah, missed that
10:54jadahl: interesting, can't edit
10:54jadahl: maybe we should use the wiki instead after all
10:55jadahl: which someone would need to enable I guess, I don't have enough super powers
10:56drakulix[m]: I guess you could reply to the comment to add to the notes?
10:57drakulix[m]: The only thing that is annoying with an issue is correcting other people, maybe that is not a huge deal?
10:58jadahl: not super huge, but messier than just collaboratively editing a notes document
10:58drakulix[m]: I am not opposed to use a wiki instead, but I can't enable that either. ^^
10:59jadahl: what I wanted to add was the action item that carlos was going to find the draft protocol change for the type-to-search fix
10:59drakulix[m]: I'll quickly add that, while we discuss moving to a wiki.
11:02jadahl: thanks
11:04drakulix[m]: jadahl: Do you know if GTK does anything with the "tiled_*" xdg-shell state today?
11:05drakulix[m]: Or in general does anyone have any examples for any toolkit for that matter? I can't find the original motivation for these states.
11:05jadahl: it should
11:05vyivel: i think it affects e.g. whether the window corners are rounded
11:05jadahl: it's more or less about not showing shadow on those edges
11:05jadahl: yea that kind of stuff
11:05drakulix[m]: vyivel: It certainly doesn't for GTK.
11:06jadahl: it does *some* things, can't remember what
11:06drakulix[m]: We briefly talked about rounded corners yesterday, is that something we might want to tie more closely to the tiled state?
11:06jadahl: you need gtk 4.9.2 it seems
11:07jadahl: my tiled gtk windows have square corners
11:08drakulix[m]: hmm, gtk4 in fedora should be 4.10, maybe it's an issue on my side then. thanks
11:09jadahl: drakulix[m]: https://i.imgur.com/Dj2oIfB.png as square can be
11:20Max1: drakulix: Chromium doesn't show CSDs on edges that are tiled
11:20Max1: Here's the low-level part: https://source.chromium.org/chromium/chromium/src/+/main:ui/ozone/platform/wayland/host/xdg_toplevel_wrapper_impl.cc;l=292
11:21Max1: And here the high-level part: https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/ui/views/frame/browser_desktop_window_tree_host_linux.cc;l=199
11:33drakulix[m]: thanks!
11:43wlb: weston Issue #773 opened by Baskar R (baskar_forum) weston-screenshooter https://gitlab.freedesktop.org/wayland/weston/-/issues/773
12:20pq: At least I have the power to edit drakulix[m]'s gitlab comment (minutes), so maybe jadahl could have too.
12:21jadahl: pq: I think it's because you have a 'maintainer' role in gitlab. i don't.
12:22pq: surely about role, yeah
12:22pq: Then again, if you want to go for a wiki, I guess that's fine, but then also consider having a git repository with minutes if you want full access control and traceability.
12:23jadahl: a wiki has history
12:25emersion: yeah, i asked about wiki in the meeting, but then ultimately got lazy and opened an issue
12:25emersion: i'll enable the wiki
12:25pq: ah, edit anyone's comments is a Maintainer or Owner power.
12:26pq: make sense
12:31emersion: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings
12:31wlb: wayland-protocols Issue #151 closed \o/ (Members meetings https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/151)
13:14davidre: emersion: Maybe make the meetings separate
13:14davidre: the page is going to be very long very fast
13:15davidre: and gitlab offers no jump labels or anything
13:16daniels: it does add anchors https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings#2023-07-05
13:16emersion: we can always split when need be
13:16davidre: Sensible
13:16emersion: and the most recent meetings are at the top
13:16davidre: 👍️
13:16daniels: you can add a ToC as well https://docs.gitlab.com/ee/user/markdown.html#table-of-contents
13:17davidre: the real gitlab pro there :)
13:17emersion: didn't know, done
13:50emersion: MrCooper: hmm, it seems like my compositor is still stuttering when i run very demanding clients, send them frame callbacks, but don't use their DMA-BUF at all…
13:51emersion: (with a high priority EGL context, on Intel)
13:52emersion: maybe i'm hitting a case where i can't do anything about it, the GPU is busy so my work is delayed even if i don't implicitly wait on buffers…
13:52MrCooper: what clients specifically? The GPU HW/driver/firmware preemption capabilities are limited
13:53emersion: compositor-killer configured so that the work takes >150ms
13:53emersion: right
13:53MrCooper: it works well for me with GpuTest plot3d, but not with pixmark_piano
13:57emersion: i don't get stuttering running gputest plot3d with a naive compositor
13:59MrCooper: did you tweak its parameters as described on https://gitlab.gnome.org/GNOME/mutter/-/issues/1162 ?
13:59MrCooper: the default parameters are light
14:07emersion: thanks, this works!
14:11pq: oh dear, I just found the CTA-861 table whether quantization is limited or full range for each combination of colorimetry and CE vs. IT vide format.
14:12pq: *video format
14:18emersion: a simple flag would've been too much to ask, clearly
15:02swick[m]: how could anyone possibly get any of this wrong
15:05kchibisov: Is tearing control of any use for regular shm clients? I'd assume not really due to the way it works and it can only work for real with the dmabuf?
15:09emersion: it could be used, a CPU->GPU copy is not super different from a GPU->GPU one
15:09emersion: from a tearing PoV
15:17kchibisov: Hm, I was somehow thinking of a case where you are doing direct scanout.
15:21zamundaaa[m]: There is no direct scanout with shm, but you don't need direct scanout for tearing
15:23kchibisov: I mean, that's expected, I was thinking of dmabuf path.
15:27kchibisov: But yeah, given that it's all non-blocking basically it doesn't really matter for the compositon time...
15:28wlb: weston/main: Marius Vlad * clients/window: Update min_allocation for smaller widths/heights https://gitlab.freedesktop.org/wayland/weston/commit/955511809558 clients/window.c
15:28wlb: weston Merge request !1298 merged \o/ (clients/window: Allow smaller pending allocation in clients https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1298)
15:59wlb: weston Issue #774 opened by Kirill Primak (vyivel) NULL pointer dereference when an xdg_surface role object is recreated https://gitlab.freedesktop.org/wayland/weston/-/issues/774
16:23wlb: wayland Merge request !326 opened by Sebastian Wick (swick) server: add const qualifier to function arguments where possible https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/326
16:30dottedmag: Is there a use-case for multiple wl_seats for a typical PC desktop/laptop configuration? Or multiple wl_seats are for embedded/specialized cases?
17:54kchibisov: When reading `wl_data_device::selection` it's very confusing how to even track what it wants.
17:54kchibisov: It says ' The data_offer is valid until a new data_offer or NULL is received or until the client loses keyboard focus'
17:54kchibisov: ' Switching surface with keyboard focus within the same client doesn't mean a new selection will be sent'
17:55kchibisov: So if I have 2 windows how would I even track that to call `destroy` as the spec wants?
17:58kchibisov: For now it all reads like you must check with some debouncing that none of your clients windows got a keyboard focus then you got to you data offers and rip them.
17:58kchibisov: which is just horrible to write in clients.
18:01kchibisov: Or was the intent of the message in the spec to say that I must not try to use that offer once I don't have any keyboard focus in any of my clients windows?
18:01emersion: do you not have only one data device and keyboard, regardless of number of toplevels?
18:01kchibisov: I have, but how do you know that you changed focus from one to another.
18:02kchibisov: my understanding is that there's no guarantee that wl_keyboard::leave and wl_keyboard::enter will arive at the same time.
18:02kchibisov: Like what if the server delivered them with the delay.
18:02kchibisov: And at which point I should run the cleanup logic, I can't run it from the `leave` handler as I wanted for example.
18:03kchibisov: Because leave will arrive before I could get enter, so I have a state during dispatching the callbacks when my client doesn't have a focus at all.
18:06kchibisov: And then we have zwp_primary_selection, with a different wording for the exact same event.
18:07kchibisov: It would be much better if server would just send a NULL once they decide that client lost focus.
18:07vyivel: https://gitlab.freedesktop.org/wayland/wayland/-/issues/330
18:09kchibisov: vyivel: yeah, sort of that. Though, the particular issue could be solved by compositor sending NULL.
18:09kchibisov: Because it "clearly knows when my client lost the focus".
18:15wlb: wayland-protocols Merge request !232 opened by Sebastian Wick (swick) security-context-v1: Document out of band mechanism and clarifications on socket usage https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/232
18:46wlb: wayland Issue #392 opened by Kirill Chibisov (kchibisov) No way to robustly handle `{wl_data,zwp_primary_selection}_device::selection` assumptions https://gitlab.freedesktop.org/wayland/wayland/-/issues/392
19:12wlb: weston/main: Marius Vlad * desktop-shell: Use a common helper to handle surface resizes https://gitlab.freedesktop.org/wayland/weston/commit/ecab79bfb7cd desktop-shell/shell.c
19:12wlb: weston/main: Marius Vlad * desktop-shell: Keep track of shsurf being created/removed https://gitlab.freedesktop.org/wayland/weston/commit/aeabba8e1873 desktop-shell/ shell.c shell.h
19:12wlb: weston/main: Marius Vlad * desktop-shell: Handle all other shsurfs https://gitlab.freedesktop.org/wayland/weston/commit/eefd8ae2e011 desktop-shell/shell.c
19:12wlb: weston Merge request !1299 merged \o/ (desktop-shell: Handle all other shell surfaces in case of an output resize https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1299)
21:08lsd|2: kubuntu 23.04 doesnt wake up from suspend. wayland in use, didnt try on x11 but should survive suspending
21:08lsd|2: any ideas
21:08lsd|2: where to search
21:08lsd|2: commands, pastes?
21:09dottedmag: lsd|2: Please ask in Kubuntu support channel
21:09lsd|2: ok i will thanks
21:17wlb: weston Merge request !1303 opened by Sergio Gómez (SergioGDR) Improve fullscreen handling in Xwayland https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1303