05:32orowith2os: I'd like some input regarding https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6161
05:32orowith2os: Is it valid for a client to force CSDs, even when the compositor says it wants SSDs and enforces that?
05:33orowith2os: The xdg-decoration protocol seems to be a bit lacking on this
05:48vyivel: orowith2os: "A configure event can be sent at any time. The specified mode must be obeyed by the client."
05:48vyivel: i suppose not
05:48vyivel: although, it's not a compositor can check if csd is present
05:49vyivel: it's not like *
05:56psykose: double sd's gang
05:57orowith2os: vyivel alright, thanks
06:14perk11: Hi. Sorry if this is offtopic, let me know. I am new to targeting Wayland and trying to add Wayland support to https://github.com/perk11/runwhenidle. It seems like ext-idle-notify is a perfect match for what I need, but I want to have a binary that is universal for X11 and Wayland, and since not everything supports ext-idle-notify, I'd like to try to fallback to other methods if it's not available on the system.
06:15perk11: I managed to get the .h file that works on my system using wayland-scanner. A couple things I am confused about are 1. How do I check that ext-idle-notify is available during runtime? I am struggling to find documentation on this topic. 2. Do I need to worry about wayland protocol for ext-idle-notify changing? Or if I target the current version it should be future-proof? If someone could point me in the right direction, I'd really appreciate t
06:19vyivel: perk11: 1) during the initial global objects burst, check for ext_idle_notifier_v1; if it's present, the compositor supports this procotol extension
06:21vyivel: 2) targeting the current version (by specifying it in wl_registry_bind()) is future-proof, yes
06:22vyivel: fyi, there's https://github.com/swaywm/swayidle
06:26perk11: vyivel: Thank you so much, this already helps me a lot. Could you please clarify what's "initial global object burst"? I can probably figure this out, but if you could link appropriate documentation, that will save me some time.
06:26perk11: I saw swayidle, it's a bit different from what I'm doing and it's been a great code example
06:28vyivel: when you get the registry (wl_display.get_registry), the compositor sends you a list of globals it has (and wants to expose)
06:29perk11: Got it now, thank you!
06:29vyivel: np
07:06emersion: orowith2os: if you cannot obey the compositor mode, don't use xdg-decoration
07:12orowith2os: emersion it's not a problem of not being able to, but *choosing* not to. I'm not sure which path the GTK devs will take here, but I hope they follow it.
08:54wlb: wayland-protocols Issue #150 opened by Matthias Schiffer (NeoRaider) xdg-activation: guidance needed on intended usage https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/150
11:49wlb: wayland-protocols Merge request !217 opened by Simon Ser (emersion) xdg-decoration: fix configure event summary https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/217
11:49emersion: jadahl: i'm sorry but i'm having a lot of trouble interacting with mclasen here…
11:49emersion: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6161
11:49emersion: please tell me if i should just drop it :S
11:54psykose: someone woke up on the 5th side of the bed eh
11:55emersion: it's been like this every single time i've interacted with them :(
11:57JEEB: ah, this SSD/CSD stuff
12:16emersion: i'm particularily offended by "wayland-protocols is not a standards body"
12:16wlb: wayland-protocols Merge request !218 opened by Mikhail Gusarov (dottedmag) unstable/xdg-decoration: Fix misleading description of configure https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/218
12:16dottedmag: emersion: ^ this should take off one issue. What would be a good place to explain the situation of unstable protocols?
12:18dottedmag: I have learned over time that the only way to work with these people is to go and fix whatever loopholes they find. He emits sounds about "unstable"? Make it clear that "unstable" does not have a semantic meaning.
12:22wlb: wayland-protocols Merge request !219 opened by Mikhail Gusarov (dottedmag) README.md: Explain that "unstable" label is not semantical https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/219
12:22dottedmag: emersion: ^ maybe this should be enough
12:23emersion: "unstable" just means "version n+1 may come sometime", nothing more
12:23emersion: and also, many many unstable protocols are in a situation where version n+1 is very unlikely to ever come
12:26dottedmag: right. If you find a legist, the only way to beat them is by making everything crystal clear in the docs.
12:27wlb: wayland-protocols Merge request !220 opened by Simon Ser (emersion) readme: make it clear that we are a standards body https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/220
12:30dottedmag: emersion: Maybe it's time to also redo the "this protocol is experimental" blurb in protocol description? I'll try to come up with some wording that reflects what you said about unstable, but I'm not involved in standardization work, so I'd be grateful if you could have a look and say if it means what it should mean.
12:31wlb: wayland-protocols Merge request !218 closed (unstable/xdg-decoration: Fix misleading description of configure)
12:50wlb: wayland-protocols Merge request !221 opened by Mikhail Gusarov (dottedmag) unstable: Clarify protocols' status and update rules https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/221
13:33MrCooper: orowith2os: a client can "force" CSD by ignoring the xdg-decoration protocol
13:39emersion: as in, not use it
13:39emersion: (not to be confused with ignoring its events)
14:45kchibisov: It's a bit weird to do runtime switches though, when user of some library will ask to not decorate the window at all. Since you need to unmap/destroy/map again, but I guess it fine.
14:45kchibisov: Since not decorating at all (like even ignoring server side) is usually done by drawing neither csd nor ssd.
14:51kchibisov: Though, I've only heard such a desire to disable all sorts of decorations in client side only decorations environments, since with SSDs you can likely have settings in your compositor for that.
18:22jadahl: emersion: been afk today and will be most of tomorrow too, but will chime in when I get the chance
18:23jadahl: spent half day debugging ancient electrical wiring for a toilet waste pump and concluded the pump itself is toast *sigh*
19:04kennylevinsen: jadahl: sounds like a... shit task
20:31xhivo97: How should I draw the decorations? I am doing everything with software rendering no GPU. Do I need to use subsurface somehow to do this?
20:32kchibisov: xhivo97: that's entirely up to you, you could use subsurfaces.
20:32kchibisov: One way could be to create 4 subsurfaces around the window.
20:33kchibisov: Or you could use one surface and logically decide what is decorations and what not.
20:34xhivo97: Is there any benefit over doing it all on the same surface? The part that is confusing to me is how to treat the buffer if I do subsurfaces, is there a way to share the same buffer? (It's still a bit confusing to me how the allocations happen, do I need to allocate the buffer every frame?)
20:37kchibisov: You don't have to 'allocate' every frame. Unless you attach(NULL) it should work.
20:38kchibisov: You can attach the same buffer to multiple surfaces, I'd suggest to read wl_surface::attach docs.
20:39kchibisov: There's also a libdecor for C clients, it could help.
20:40xhivo97: Thanks! (I kind of wanted to avoid libdecor and do most things from scratch)
20:40kchibisov: Is there any benefit> only downsides from my experience, since you can't e.g. highlight a button without redrawing everything.
20:41xhivo97: How many ways are there to get a buffer to draw to? I followed the example in the wayland book, is that the way to go and is it the only way?
20:41kchibisov: You have either wl_shm or dmabuf.
20:42kchibisov: For software rendering you're using wl_shm most of the time.
20:43kchibisov: The key point here is that you need some shared resources, like shared memory with wl_shm, so compositor can read your buffer.
20:46kchibisov: There're also special protocols like 'single-pixel-buffer' to create buffers, but they are quite niche.
20:46xhivo97: I've never worked with shared resources before, and naively I guessed that the example in the wayland book is allocating every tie it calls the draw_frame function but sounds like I might be missing something
20:48xhivo97: (how does IRC work if I refresh page will my chat history be lost?)
20:48kchibisov: I haven't read the wayland book, but usually how you handle that is that you have shm pool and you ask for buffers from it.
20:49kchibisov: xhivo97: depends on the client, but likely remove the history. But there're public logs for this room.
20:49kchibisov: https://oftc.irclog.whitequark.org/wayland/2023-07-01
20:50xhivo97: Each time they draw they are creating an shm file calling ftruncate, then mmap then wl_shm_create_pool and finally wl_shm_pool_create_buffer. Should I remove any of these and call them just once?
20:51xhivo97: Whoever wrote the wayland book, I like their sense of humor though lol
20:51xhivo97: Really hope they will finish it it was ann enjoyable learning experience
20:56xhivo97: Also, should I handle "subcanvasing" the buffer or does wayland have a some way to get them with correct stride etc? (currently I just make a pointer pointing to where I want my subcanvas to be and calculate a stride, seems to work)
20:57kchibisov: I'm not sure I understand what `subcanvasing` means? Are you talking about using some offset into buffer?
20:58xhivo97: Yeah, a way to treat it as a surface I can draw on it's own with origin 0,0 but in buffer indices terms
21:00xhivo97: I can do that no problem but was wondering if wayland has an equivalent thing I can do that's built in or something but idk if that makes much sense lol
21:01kchibisov: you do all the drawing, you could read the core protocol for details (wayland.app).
21:02xhivo97: Oh wow thanks! I didn't know that site
21:02kchibisov: it's a community hosted one, but it's very convinient.
21:03kchibisov: wrt drawing, you don't need to create shm on each drawing invokation, you usually create an abscration over it and just get a buffers from the offset.
21:05rpigott: I don't think the first example on "wayland-book" really expects to draw more than one frame. It isn't responsive to configures (or close even) and doesn't subscribe to frame events.
21:05rpigott: that's fine really, its just example code.
21:05xhivo97: I'll try and refactor to not do that. Also, wayland has a really interesting design is there a name for it? Do you know why it's built like that?
21:05kchibisov: I'm not sure how to describe it, but basically you allocate e.g. some amount in shm, and then create buffers from it, maintaining some sort of linked list.
21:06kchibisov: Basically you have your small allocator over shm to avoid reallocations.
21:06kchibisov: If you can't reallocate you resize the pool.
21:06kchibisov: err, reallocate → allocate.
21:06xhivo97: @rpigott Actually I followed it through to the end and it does respond to reconfiguration I can move it and resize and close it. But I might have missed something and that might have been something I left behind from the earlier examples
21:07kchibisov:is doing OpenGL most of the time, so can't really help with shm.
21:17xhivo97: (im sorry if you saw that I have no idea how to use IRC, wanted to see if you can ping or reply to someone lol)