03:02 Tramtrist: hello all.. Is there a way to make a wayland program run 'always on top' ? The program in question is not presenting an app_id in swaywm and Im wondering how to bring it to the front
03:14 soreau: are you not able to see it? I thought sway was a tiling manager with optional floating views
03:14 soreau: but really, this is more a question for #sway on liberachat
03:15 Tramtrist: This particular program doesnt seem to be showing a 'window' at all
03:15 Tramtrist: https://sr.ht/~leon_plickat/wayneko/
03:16 Tramtrist: I'll ask the sway folks why its not presenting an app_id
03:17 soreau: you can also set WAYLAND_DEBUG=1 when running the program to see what might be going on
03:19 Tramtrist: thanks soreau :)
03:19 soreau: hm
03:20 soreau: Tramtrist: it looks like it wants zwlr-layer-shell-unstable-v1 but it's zwlr-layer-shell-v1 now?
03:20 soreau: try `WAYLAND_DEBUG=1 wayneko |& grep zwlr-layer-shell`
03:21 soreau: (those dashes should be underscores)
03:22 soreau: anyway, it doesn't work here either
03:34 Tramtrist: appears because its using layer-shell it doesnt present appid
03:35 danieldg: Tramtrist: change ZWLR_LAYER_SHELL_V1_LAYER_BOTTOM to TOP
03:41 Tramtrist: hah yep that did it
03:41 Tramtrist: i was just going down that path but trying to find out how to change it from 0 to 2 or whatever
03:41 Tramtrist: Thank you very much danieldg
03:41 Tramtrist: The cat has returned
03:45 Tramtrist: Productivity at all time highs now
03:46 Tramtrist: who would have though someone in #sway would also bein #wayland :)
03:46 soreau: meow
03:47 Tramtrist: 🐈‍⬛
03:49 danieldg: 😼
09:23 zezba9000: Hi, I'm trying to solve an issue thats really confusing me. wl_subsurface_set_position doesn't seem to do anything to offset my sub-surface
09:24 zezba9000: The sub-surface is set as wl_subsurface_set_desync and displays in the the top-left corner of the main surface
09:24 zezba9000: Not sure what I'm missing to get the offset from wl_subsurface_set_position to work
09:25 zezba9000: https://github.com/zezba9000/WaylandClientWindow/blob/master/main.c#L164
09:30 zezba9000: I've tried on Ubuntu & PopOS 22.04
09:33 vyivel: zezba9000: subsurface position is treated as a part of the parent surface state
09:33 vyivel: i.e. you must commit the parent surface after sending wl_subsurface.set_position
09:35 zezba9000: Ok nevermind figured it out. Need to call wl_surface_commit on both surfaces after everything is done then call wl_display_flush. So my order of operations was wrong
09:40 zezba9000: Is there a way to request a Wayland window is centered on the screen client size in code?
09:42 vyivel: no
09:46 zezba9000: @vyiel I mean at Window creation time. Say for like a splash screen. This must be possible
09:46 zezba9000: Not moving a Window but requesting its created centered for splashes or game-engine windows
09:49 zezba9000: I can just do with in X11 and centering windows works in XWayland. There must be a way to create a window centered in Wayland to match this behaviour
09:51 zezba9000: Other major thing I'm trying to find docs for is enabling server-side decorations on KDE and ignoring my own
09:56 vyivel: for ssd, see xdg-decoration
09:58 vyivel: a window can't center itself on creation time either
10:05 zezba9000: @vyivel A Window should be able to request it wants to present itself centered like all other operating systems can do. I'm not saying manually set the position. WinRT framework for example allows this request for Window creation without allowing you to get or set a Windows position.
10:06 zezba9000: Otherwise you can't do splash screens for an IDE like CLion, Rider, etc
10:07 vyivel: imho using xdg_toplevels for splash screens is a bad idea anyway
10:07 vyivel: i personally wouldn't want a window appear wherever it wants
10:08 zezba9000: You want a splash screen to appear in the top left of the screen? what??
10:08 vyivel: *i* don't want a splash screen to appear at all, if that's what you're asking
10:08 zezba9000: Also you want a Windowed game to show up in the top left? Like what again man. No one makes software like this.
10:09 vyivel: where a window appears is a compositor's policy
10:09 zezba9000: No its NOT lol
10:09 rolf: That's how I interpreted it as well. Or at least it should be something the user has control over. (but... why even have 'splash' screens?)
10:09 vyivel: it can decide that a window must be centered
10:09 zezba9000: Just no
10:09 vyivel: it can also decide it should be tiled
10:09 vyivel: or maximized from the start
10:09 vyivel: or minimized
10:09 vyivel: or whatever else the user wants
10:09 zezba9000: If I open Rider I want its launcher that lets me select a project to show in the center of my screen BUT I don't want that for every app
10:10 zezba9000: All OSes agree with me here too
10:10 zezba9000: ALso I don't see anything related to get_toplevel_decoration in xdg-shell-client-protocol.h
10:10 vyivel: https://wayland.app/protocols/xdg-decoration-unstable-v1
10:10 vyivel: that's a different protocol
10:11 rolf: I agree with vyivel here; it is up to the window manager to decide, not up to the program.
10:11 emersion: the way splash screens are going to work on wayland is by having the app tell the compositor "this is a splash screen", rather then "put this in the center"
10:11 vyivel: ^
10:11 zezba9000: 99% of the world disagrees sorry
10:11 emersion: see https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/140
10:11 vyivel: splash screens have very different semantics from regular windows
10:11 zezba9000: One size fits all is nonsense
10:12 zezba9000: Again this isn't about Splashscreens
10:12 zezba9000: Its about game windows, selection dialgs etc
10:13 vyivel: as i said, where those are placed is up to compositor
10:13 zezba9000: Splash screen is just one of many things. And its not up to you what a software needs to do
10:13 zezba9000: Yes it is up to the compositor. So is it with WinRT frameworks BUT theirs are done correctly here
10:13 zezba9000: Its a request that doesn't have to be respected
10:14 rolf: Still... it is not up to the program to decide this. I would become incredibly annoying and an a bypass mechanism if software could decide the placement of windows. Next thing you'll know is we end up with "Windows" behaviour like focus stealing.
10:14 emersion: please, don't try to argue that another framework does something so we should do the same
10:14 rolf: ( *It would )
10:14 emersion: this is not how it works
10:14 zezba9000: Wayland needs to support center Window request standards for game Windows at min (this is the field I'm in btw)
10:15 zezba9000: I'll agree how I see fit. Not looking at other approches is utter nonsense
10:15 emersion: your tone is really not helping here
10:15 zezba9000: Particularly ones that are doing the same thing as Wayland but actually expose things for important reasons
10:15 zezba9000: **agrue
10:15 zezba9000: My tone is one of frustration
10:16 zezba9000: I can center my game Window on Wayland if its using X11
10:16 emersion: we looked at other approaches and decided against them
10:16 rolf: "99% of OSses have a Start button, therefor we should have a Start button as well"
10:16 zezba9000: But I can't using Wayland direction? Like what lol
10:16 emersion: that's basically why wayland exists at all
10:16 zezba9000: God you're out of toucch here
10:16 emersion: wayland exists because X11 developers learnt from their mistakes
10:16 zezba9000: Whatever Linux can fall off a cliff here and people will stick to X11 on SteamDeck I guess
10:17 zezba9000: Anyway whatever I guess
10:17 zezba9000: No Wayland did not learn from X11 mistakes as they clearly didn't look at what others were doing and why
10:17 zezba9000: Thats actually learning is learning from others
10:17 emersion: X11 does the same as win32
10:17 emersion: anyways
10:17 zezba9000: You realize Windows and macOS have things they learned Wayland could learn from right
10:18 emersion: i don't think this conversation is going anywhere at this point
10:18 zezba9000: This echo chamber isn't good for anyone
10:18 emersion: let's stop here.
10:18 zezba9000: Sure
10:22 zezba9000: "X11 does the same as win32" FYI this is why I said WinRT. Very different
10:23 zezba9000: I highly recomend looking at WinRT windowing system here. Its pretty much wayland in its security at a client level but allows the hints I'm suggesting. Leaving it hear but want to make that clear. Its worth considering some of the ideas
10:42 rolf: The user can decided how they would like windows to be placed by setting appropriate configuration for the window manager they use. Ie the user may choose to have splashscreens, dialog windows et cetera floating and centered but they can also choose to set specific window types to be tiled, always open on screen #1, always be topleft, et cetera. Personally I have set several window
10:42 rolf: classes to open either centered (floating) or at a specific location. The program can set the window class, the user decides how to display that windwo class.
10:44 soreau: wayfire entertains such wild times
10:44 soreau: it lets xwayland windows place themselves
11:04 zezba9000: The app dev should be able to provide Window hints the compositor can override by user choice. This is the correct ballance between app devs and the OS. It allows for both. App designers design apps to feel and function particular ways. A DE that is tile based might override expectations but at least the option exists for an OS to behave the way they have since the 80s.
11:05 zezba9000: Tiled Window managers are a fraction of a percent of users. Outside touchscreens these only have so much value and its just not how people think in many cases IMO
11:22 zezba9000: Am I wrong in saying Wayland will have a memory leak if a program craches?
11:24 zezba9000: I notice if my Wayland app crashes it will not open again unless I call "shm_unlink" on the shared memory buffers
11:34 JEEB: given that each wayland compositor more or less has their own server-side logic, you would probably be wrong in saying it as a general comment about wayland itself - unless that memory leak is written into the specification
11:35 JEEB: and if it is written into the specification, it is most likely a bug which would get fixed
11:37 emersion: zezba9000: that sounds like a client bug
11:37 emersion: if a client leaks a file, the compositor can't do anything about it
11:37 emersion: the right way to do ot is for the client to unlink the file right after opening it
11:37 emersion: it*
11:38 zezba9000: This is PopOS.
11:38 zezba9000: So same as Ubuntu and Fedora I'd think
11:38 zezba9000: "that sounds like a client bug": Of course. If my app crashes it shouldn't cause a memory leak in Wayland
11:38 zezba9000: But in PopOS it is
11:39 JEEB: depends on whether the buffer or file or whatever is on client side or server side, I guess?
11:40 JEEB: since emersion brought up it being a possibility that the client took a resource and in that case the server would be unrelated
11:40 emersion: zezba9000: this is client memory, left by the client
11:41 emersion: the compositor is not involved in the leak
11:42 zezba9000: Umm if an app crashes on Windows, macOS, ANdroid etc. It doesn't cause a mem leak in the compositor
11:42 emersion: there is no compositor mem leak here
11:42 zezba9000: It doesn't matter if its the clients fault. This would make the OS prone to memory issues
11:42 JEEB: yes, and I think while I took it at face value that you were actually talking about a compositor leak, emersion noted that what you mentioned is a leak on the *client*
11:43 zezba9000: So I can create a buffer without shm_open ?
11:43 emersion: you call shm_open, then right after call shm_unlink
11:43 zezba9000: Ok and if the app crashes before that?
11:43 emersion: see any Wayland client for reference code...
11:44 emersion: if the app crashes exactly between these two calls?
11:44 zezba9000: Isn't this just an easy attack vector at this point?
11:44 emersion: ... attack vector?
11:45 zezba9000: Nevermind, if its not easy to see why I'm not going to have the conversation
11:45 emersion: the memory is accounted for the client
11:45 emersion: not the compositor
11:48 JEEB: I think the thing he might be talking about is someone requesting more and more buffers on purpose without releasing them, but that would only be an issue if those buffers would be in the memory space of the compositor. are they? if they are not, then it's just the client filling up its memory space and the compositor is fine?
11:49 emersion: no, it's client memory
11:49 zezba9000: It just feels like any buffer used on the client should always have a process assosiation. If I and debugging then hit stop and kill the app it doesn't clean up memory. I can't imagine this happening with X11, Win32, Cocoa apps etc? Am I wrong?
11:49 zezba9000: So if process died all memory shared or not gets released.
11:50 zezba9000: This is what happens with OpenGL, Vulkan apps for example
11:50 emersion: your client is doing the same as opening a file on /ymp and not cleaning it up
11:50 emersion: /tmp
11:51 emersion: as I said, the compositor is not even involved in this leak
11:51 zezba9000: Yes but why is Wayland using these buffer types without process association?
11:52 emersion: I would suggest that you read more information about buffer sharing
11:52 emersion: like wayland-book.com
11:54 valy_: directed here from kde-devel: I'm trying to fix one issue with Krusader on wayland, but I don't have that much experience with KDE Libs so -> if the viewer window is already open but minimized or behind the main krusader window it should come to foreground when I open a new tab
11:54 valy_: KWindowSystem::activateWindow(windowHandle()); makes the window blink in the task bar, but I found no refrence for bringing the window to the top
11:55 orowith2os[m]: (director being me) - the main problem is bringing a window to the foreground
11:55 valy_: yep
11:56 orowith2os[m]: I recall it being expected that apps can't force themselves to the foreground, but I think it was possible to do that outside of starting a new app
11:56 orowith2os[m]: or maybe I'm thinking of passing the focus from app to app, which does have a protocol of its own
11:56 soreau: this works in wayfire with focus-request plugin IIRC
11:57 valy_: I think this is the activation token protocol
11:57 valy_: does it make the problem easier if both windows are owned by the same application?
11:57 soreau: my use case is a text editor is open but it's behind a terminal where I run the text editor on a file, it doesn't open a new instance, it just brings the text editor on top and opens the file
11:57 JEEB: anyways, I would actually rather ask that question about shmem usage/freeing from the linux kernel or whatever is implementing shm_open/shm_unlink, rather than wayland. since unless the compositor somehow takes ownership of the shmem, it's still under management of the application. so in theory if your application dies while still being the single owner of that shmem object the manager of these things would
11:57 JEEB: be able to free it.
11:58 orowith2os[m]: valy_: ish, what's important is one window having focus, I think. still trying to find anything in the protocol :v
11:59 soreau: valy_: not if your compositor doesn't support this feature
12:03 zezba9000: Anyway thanks for the info. Got to go to bed. I do think Wayland devs should consider the WinRT center window hint. Kind of annoying not having this for windowed games. I'll have to look more about shm. On Windows I feel like every shared memory buffer like this died with the process but would have to confirm.
12:04 orowith2os[m]: aaaaa
12:04 orowith2os[m]: how the hell does GTK do it?
12:04 JEEB: it could be that posix and/or linux went the file way, and files don't automagically disappear :)
12:04 soreau: looks like in wayfire, it calls the focus_request plugin on map, which decides what should happen
12:05 orowith2os[m]: I looked at Wayfire's plugin, but there's not really anything interesting I can see
12:05 soreau: not much to it https://gitlab.com/wayfireplugins/focus-request/-/raw/main/wf-focus-request.cpp
12:06 soreau: but for xwayland views, it's also called on request_activate
12:06 orowith2os[m]: where does wayfire get a FocusRequest event from?
12:06 orowith2os[m]: wlr-layer-shell?
12:06 soreau: oh I forgot to look at the in tree plugins..
12:06 soreau: it's gtk-shell looks like
12:07 soreau: and xdg-activation
12:07 soreau: and foriegn-toplevel
12:07 orowith2os[m]: xdg-activation makes sense for passing focus between
12:07 soreau: all these protocols are implemented as plugins and call focus_request at some point
12:07 orowith2os[m]: apps
12:08 orowith2os[m]: gtk-shell seems the most interesting, as it actually just brings a window to focus
12:08 soreau: yes, this is really convenient
12:08 orowith2os[m]: valy_: there ya go, take a peek at gtk-shell
12:08 valy_: right, got it
12:08 orowith2os[m]: though, doesn't look like kwin implements it....
12:08 orowith2os[m]: if the wayland.app menu is to be trusted
12:08 orowith2os[m]: aaAAAAAA
12:09 orowith2os[m]: then how does it do it on KDE???
12:10 valy_: KWindowSystem::activateWindow uses the activation token
12:11 valy_: which seems to be the KDE way of doing this
12:11 orowith2os[m]: my brain hurts
12:11 orowith2os[m]: I shall leave you to it
18:22 guacamolie: hello, does anyone know of a small-ish Wayland compositor that I can study which _does not_ use wlroots? nothing against wlroots, but I would like understanding Wayland itself better first. I already created a minimal compositor with the help of https://wayland-book.com, but don't have anythign that actually displays pixels on the screen.
18:23 guacamolie: (I hope this channel is right for asking questions like these, please tell me if otherwise)
18:24 guacamolie: s/understanding/to understand/
18:33 soreau: guacamolie: you might be looking for weston, the wayland reference compositor
18:34 emersion: it's not the reference compositor, soreau
18:35 emersion: weston and wlroots have the same level of complexity, i'd say
18:35 soreau: emersion: when did this change?
18:35 emersion: i don't know of a minimal compositor
18:35 emersion: soreau: a few years ago
18:36 soreau: emersion: so are folks calling something else a reference compositor? or there is none
18:36 emersion: there is none
18:37 soreau: well when I need to refer to something that isn't wlroots, I use weston
18:37 soreau: so in this since, I guess it's still the reference compositor, to me
18:37 soreau: and this won't likely change :)
18:37 soreau: sense*
18:39 guacamolie: hmm, I see
18:39 guacamolie: maybe I could go back in the git history of one of these projects to find an implemention from 'the simpler days'?
18:43 soreau: you could, but you might have to pair it with older dependencies, depending..
18:46 emersion: you'll also find mistakes that were corrected after
18:47 guacamolie: true
18:47 guacamolie: I think it's probably best for me to go with tinywl anyway and try to best understand what wlroots is doing
18:47 emersion: and you'll find pretty old protocol versions
18:47 guacamolie: soreau and emersion: thanks
18:48 soreau: guacamolie: yea I think tinywl is your best bet. If you have further questions about it, check the wlroots headers or ask in #wlroots on libera chat
18:48 guacamolie: will do, thanks!
19:39 Consolatis: orowith2os[m]: gtk-shell is some private "unofficial" wayland protocol. I would not bet on it being implemented by a majority of compositors. The xdg-activation protocol seems like the right solution to your problem, when you have keyboard focus you can request a valid xdg-activation token from the compositor which you can then use in another window to request activation.
19:41 Consolatis: This is done to prevent unwanted focus stealing. Some compositors apparently also have a second use of the protocol in that they use it as an "urgent" hint if the token is not "valid" (e.g. the application didn't have keyboard focus when requested)
20:56 orowith2os[m]: Consolatis: interesting
20:56 orowith2os[m]: I was looking for the "urgent" bit, and I was aware gtk-shell is meant to be "private", so that's great to know
20:58 orowith2os[m]: well, me, and a valy_, wherever they may be
20:58 emersion: compositors will usually mark your window as urgent if you activate with a token which doesn't have focus
20:59 orowith2os[m]: I assumed it was assumed to always be either a protocol error or ignored if the token isn't valid
21:00 orowith2os[m]: seems like a good opportunity to update the docs if that isn't the case
21:00 any1: https://github.com/any1/wayvnc/issues/291 - Any thoughts on this?
21:01 orowith2os[m]: on a related note, what does a token look like? depends on the compositor, I assume, but what does e.g. wlroots or kwin do?
21:01 orowith2os[m]: any1: that seems like a horrible way of seeing if you can force-resize an output
21:01 vyivel: orowith2os[m]: just a random unique string
21:02 any1: orowith2os[m]: It is, but it's the only way as is.
21:02 Consolatis: any1: IMHO the information should not be "is headless" but rather "support custom modes"
21:02 orowith2os[m]: extending wl_output would probably be the best bet
21:05 emersion: any1: why do you need this info?
21:05 any1: emersion: VNC servers can resize the desktop based on the client's window size
21:06 orowith2os[m]: also, I'd recommend other than abusing Wayland for that, look to the RemoteDesktop portal
21:06 orowith2os[m]: and add a "Resize" method
21:06 emersion: right
21:06 any1: If the output is a physical one, we want to disable this feature; otherwise allo users to resize at will
21:06 emersion: any1: when do you need to know?
21:06 emersion: at VNC connect time?
21:06 emersion: VNC client connect time*
21:06 emersion: or after?
21:06 orowith2os[m]: or both?
21:06 orowith2os[m]: though after probably covers that
21:07 any1: Emantor: Actually, just when the client requests a resize
21:07 any1: err, emersion
21:07 any1: soz, Emantor
21:07 emersion: i was going to say that handling failures should be enough
21:07 Consolatis: ^ or maybe have a capabilities bitset in either of the protocols with caps like rotation | custom refresh rate | custom mode | ..
21:07 emersion: but on DRM this will result in weird stuff
21:08 orowith2os[m]: I'd actually love to see if some RemoteDesktop stuff could be sorted out - and looking at the portal website, it could use some touching up to hide "old" methods too :v
21:10 Consolatis: orowith2os[m]: there are compositors out there that do not use / require dbus. For those cases there still needs to be a portal implementation that then has to talk to the compositor via a wayland protocol
21:10 orowith2os[m]: Consolatis: for those compositors, they can use their own special wayland protocol, and build the portal on top of that
21:10 orowith2os[m]: it's not a new thing
21:10 orowith2os[m]: the wlroots portal does that
21:10 Consolatis: any1: xdg-desktop-portal wrapper for wayvnc?
21:12 orowith2os[m]: Consolatis: also, even *if* we had to make a wayland protocol for those compositors, the RemoteDesktop portal still needs to be expanded to support the resizable outputs feature
21:13 orowith2os[m]: so might as well just sort that out ASAP
21:13 orowith2os[m]: especially considering that's how most RDP clients work
21:14 Consolatis: there are already (private) wayland protocols for that, it is how wayvnc works
21:14 any1: wayvnc is a wayland client. It hasn't jumped on the dbus and never will.
21:15 orowith2os[m]: ah, I completely forgot this was in the context of wayvnc. and what its goals were.
21:16 orowith2os[m]: If it's not a feature on the RemoteDesktop portal, I would love to see it there too
21:16 any1: But if someone wants to create some xdg desktop portal thing based on Neat VNC, I might help out.
21:16 emersion: any1: i wonder if some wayland protocol to create and manage virtual outputs would be better
21:17 any1: emersion: Actually, yes, I have considered this
21:17 orowith2os[m]: rather than jumping right to new protocols, why not go to wlr-output-management?
21:17 orowith2os[m]: and just expand that
21:18 emersion: because the use-case is different
21:18 emersion: wlr-output-management is for tools that configure your outputs, like a settings app
21:18 emersion: it's not really designed for the VNC use-case
21:18 orowith2os[m]: is that not what the use case here is? just with some necessary detection of features
21:19 emersion: nope
21:19 orowith2os[m]: would the current protocol not already work for that, actually?
21:19 any1: emersion: A virtual output could even be an ext-image-source-v1 that renders straight into screencopy buffers. ;)
21:20 emersion: that wouldn't be screencopy anymore
21:20 emersion: hm, or maybe it would
21:20 emersion: yeah, i suppose it could work
21:20 any1: Let's not get tied up by the name of the protocol. :)
21:21 emersion: right
21:22 orowith2os[m]: I don't really see why zwlr_output_head_v1 can't have a is_virtual event, being a bool, to see if resizing it to any arbitrary size is appropriate
21:22 orowith2os[m]: since it is an output
21:25 Consolatis: I still don't think that an output being virtual or not is what clients are actually interested in though, so being more specific like "supports any custom mode" seems more appropriate
21:26 orowith2os[m]: in the end, it gets the end result you want: is the output able to support any arbitrary mode?
21:27 emersion: because VNC servers need more ideally
21:27 Consolatis: until somebody else has a different use-case for detecting virtual outputs and then assumes that based on some implementation this assumption always holds for all implementations
21:27 emersion: ideally VNC servers need to be able to create virtual outputs as well
21:28 any1: Consolatis: The DRM backend supports custom modes (I think?). It just fails if the mode isn't actually supported.
21:28 any1: Consolatis: so we don't really want to mess with that. The idea is that physical outputs shouldn't be disrupted
21:29 Consolatis: well, then I'd say it may support custom modes but not *any* custom mode and thus would be false / not set
21:30 Consolatis: a cleaner solution would indeed be to have VNC servers (or related applications) create the virtual output
21:33 any1: emersion: Yeah, we actually have an example script that interacts with swaymsg to create a virtual output when a client connects and disable all physical outputs: https://github.com/any1/wayvnc/blob/master/examples/single-output-sway
21:34 any1: This should really be an integral feature that's enabled by a command line argument.
21:35 any1: And this would work for most wlroots based compositors if there was a protocol for creating virtual outputs.
21:41 any1: But, anyway, I don't think that I'll be pushing yet another protocol until ext-screencopy-v1 is finished
21:48 soreau: finished!
22:56 any1: emersion: https://paste.sr.ht/~andri/69c06251cced8330ef0a8f33156a53a34e36367b
23:36 Consolatis: > Copyright © 2024 - 2030 That Guy Who Won't Stop Pushing New Protocols
23:36 Consolatis: :)
23:49 wlb: weston Merge request !1456 opened by diegonieto (diegonieto) clients/simple-damage: fix exiting message https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1456