06:41wlb: wayland Issue #511 closed \o/ (wayland-util: There will be deviations when fixing floating point numbers using wl_fixed_from_double() https://gitlab.freedesktop.org/wayland/wayland/-/issues/511)
08:16wlb: wayland-protocols/main: Simon Ser * linux-dmabuf: link to kernel docs https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/bd6289c14148 stable/linux-dmabuf/linux-dmabuf-v1.xml
08:16wlb: wayland-protocols Merge request !364 merged \o/ (linux-dmabuf: link to kernel docs https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/364)
10:08mdb977: Hi There, I'm on an embedded device using Weston and currently fiddling with SELinux. If I connect a physical keyboard, Weston crashes with 'file descriptor expected, object (21), message keymap(uhu)' and 'Fatal error: invalid argument'. Everything is fine without SELinux enforcing. Unfortunately, the audit log shows no clue. Does anybody have a tip on which direction to look at?
10:11vyivel: mdb977: wl_keyboard.keymap carries a keymap fd, perhaps selinux prevents it from being passed over the unix socket connection for some reason?
12:01pq: zamundaaa[m], by the test app you mean https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_2722732 ? (somehow I never got the notification of that comment.)
12:02zamundaaa[m]: pq: yes
12:10pq: mdb977, are you sure it's Weston crashing? To me that looks like a client error message. Anyway, vyivel has a good quess.
12:19pq: zamundaaa[m], yeah, sounds good enough to me. Maybe check with swick, too.
12:26riteo: hi people, I'm a bit on a shaky connection so sorry if I quit-join
12:27riteo: so libdecor still has this whole visibility-change-does-not-work thing with SSDs and I looked around to see what other clients do
12:27riteo: it looks like people just assume that xdg-decoration-manager == SSDs? Is that even in spec?
12:28riteo: Like, the protocol description goes "This interface allows a compositor to announce support for server-side decorations.", not "This interface announces support for server-side decorations."
12:29riteo: could somebody please help me how I should go forward?
12:30davidre: the compositor will tell you the mode you should use
12:30riteo: ye but you have to configure a whole toplevel first
12:30zamundaaa[m]: riteo: imo that's an oversight in the spec text
12:31riteo: zamundaaa[m]: what do you mean?
12:31riteo: (btw, if some of you have dejavu I already talked about this a year or so ago)
12:31zamundaaa[m]: The assumption is that if the global is supported, the compositor also does support SSD
12:31riteo: and is that assumption correct?
12:31zamundaaa[m]: Of course, with window rules or whatnot, it might still tell you to do CSD instead
12:32davidre: libdecor also follows the mode
12:32davidre: if the compositor says CSD it will do CSD
12:32riteo: yea but libdecor does not allow hiding SSD decorations
12:32riteo: like, if I want a borderless window on KDE I just... can't
12:32davidre: You can't
12:32riteo: it depends on a protocol update that never got merged
12:32riteo: or implemented
12:33davidre: There's a trick
12:33zamundaaa[m]: riteo: It does not
12:33davidre: you destroy the xdg_toplevel_decoration
12:33davidre: so the compositor doesnt know that you can handle SSD
12:33zamundaaa[m]: libdecor could very much request CSD, and that would work just fine
12:33davidre: But of course the compositor can always double decorate CSD clients
12:34davidre: But the compositor can do what it wants in general
12:34riteo: zamundaaa[m]: that's what the current code does, I'm not sure why it does like that but right now it explicitly checks for this non-implemented version
12:34riteo: zamundaaa[m]: so all versions of libdecor are currently broken on SSDs
12:34davidre: https://gitlab.gnome.org/jadahl/libdecor/-/blob/master/src/libdecor.c?ref_type=heads#L595
12:34mdb977: @vyivel Thanks, yes, rule for memfd:weston-shared was missing.
12:35riteo: davidre: sorry, I'm not really sure I understand what you're proposing
12:36davidre: There's no reason the libdecor code requires v2
12:36riteo: like, I already call that method but the xdg_decoration parts are guarded by an "is xdg_decoration_manager version 2 or up"
12:36davidre: as there's no v2
12:36riteo: ye but that code is effectively dead
12:36riteo: and the client I'm working on (godot) needs to allow borderless windows on SSDs
12:36zamundaaa[m]: riteo: see https://gitlab.freedesktop.org/libdecor/libdecor/-/merge_requests/147
12:36davidre: Then fix libdecor
12:36davidre: or do not use it
12:36riteo: zamundaaa[m]: that never got merged either :(
12:37riteo: davidre: there's an MR but it got stuck
12:37riteo: and CSDs on godot are still WIP
12:37riteo: that's why I'm asking here
12:37riteo: is the best solution really just to assume that xdg_decoration_manager == SSDs available?
12:38riteo: and hope for the best
12:38davidre: you could destroy the libdecor object to the same effect
12:38riteo: well that would unmap the window
12:38riteo: which is not exactly ideal
12:39davidre: Oh it does manage the whole window for you?
12:39riteo: yep it's a whole wrapper
12:40riteo: BTW I'm asking this as I just found out about https://wiki.libsdl.org/SDL3/SDL_HINT_VIDEO_WAYLAND_PREFER_LIBDECOR which implies exactly that assumption
12:40riteo: but it just feels... wrong
12:41zamundaaa[m]: riteo: linking that MR wasn't to show you that nothing can be done, but that if you want to fix it, it's not very complicated
12:41riteo: I mean, isn't it already fixed in that MR?
12:42riteo: sorry I'm not sure what you meant then
12:42riteo: are you saying that I should, like, vendor the library in and patch it myself?
12:43zamundaaa[m]: You can open a MR with that comment Jonas wanted, or ping misyl to add it, or vendor it if you really really really want to
12:44riteo: I see
12:45riteo: so, end of line, the assumption that xdg_decoration == SSDs is indeed not a good idea and libdecor must be fixed
12:46zamundaaa[m]: You can make that assumption in practice too, but it's not a proper fix
12:47riteo: All right. I guess I might do that as a stopgap and push to get libdecor fixed.
12:47riteo: Thank you all!
12:50riteo: I'll quit for now but I'll still take a look at the logs if anyone wants to add anything. Cya!
13:58wlb: weston Issue #606 closed \o/ (How to implement PQ and HLG curves https://gitlab.freedesktop.org/wayland/weston/-/issues/606)
15:50wlb: weston/main: Daniel Stone * 27 commits https://gitlab.freedesktop.org/wayland/weston/compare/c01a1f7c641ae4c44a1fb835082c4e31024e4e18...7f872684746feb6a08e0d25a8323dd517bae4c31
15:50wlb: weston Merge request !1595 merged \o/ (Improve read-back: Renderbuffers (1/3) https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1595)
15:57bitblt: hello!
15:58bitblt: is this a good chat to ask questions about wayland client implementations?
16:03ifreund: sure
16:05bitblt: so, I've read the wayland-book (https://wayland-book.com/) along with some other similar practical wayland guides (e.g. https://bugaevc.gitbooks.io/writing-wayland-clients/) and I have a nice little working wayland client
16:06bitblt: I have some questions about the api usage though that neither the above, nor the official api documentation (https://wayland.app/protocols/) where explicit about
16:08bitblt: question no1: when binding the global objects with wl_registry_bind, should I use hardcoded interface versions? why shouldn't i use the version param of the wl_registry_listener.global callback?
16:09zamundaaa[m]: bitblt: you should use `min(highest_version_you_support, version_from_callback)`
16:10zamundaaa[m]: If you just use the version from the callback, you might be opting into behavior that changed with newer versions vs. from what you implemented
16:10bitblt: ah I see
16:11bitblt: I suppose this behavior might change, but the callbacks / types / function will remain the same?
16:11bitblt: I thought that versioning was actually implemented with different protocol (definitions) xmls
16:11wlb: wayland Issue #523 opened by Tobias Hänel (tobias-haenel) Segmentation fault in destroy_queued_closure https://gitlab.freedesktop.org/wayland/wayland/-/issues/523
16:12ifreund: adding events and requests to a protocol is a backwards compatible change
16:12bitblt: Is there any example of why I should use `min(highest_version_you_support, version_from_callback)` for the version?
16:12ifreund: if you tell the server to send events for a version that your client doesn't actually support, your client will get killed by libwayland as it does not recognize the newer events
16:14bitblt: ok I suppose that means I should be specific in the version of libwayland-client I'm linking into, and check what versions are the globals in this libwayland-client and use these in the registry_global_handler
16:17ifreund: bitblt: this has nothing do with the version of libwayland client you are linking, it has to do with what version of the protocol interfaces your client implements
16:18ifreund: (aside: libwayland makes this much more of a footgun than it needs to be, zig-wayland makes it impossible to write this bug)
16:19ifreund: I require the user to specify the maximum version of each global interface they implement at build time and only generate requests/events/interfaces up to that version, and then generate the min(supported, advertised) automatically on bind
16:21bitblt: ok, I need to wrap my head around this a bit more, but I think I have the info I need for this
16:21bitblt: onto the next question
16:22bitblt: question no2: when should I do a `wl_display_roundtrip(wl_display)` instead of a `while (wl_display_dispatch(display) != -1){}`?
16:23bitblt: as far as I understand both kinda force requests/events up to this point to be handled (either by the server/client or both)
16:24bitblt: and I've seen a simple example that both are used for similar purpose: https://github.com/emersion/hello-wayland/blob/master/main.c#L180 https://github.com/emersion/hello-wayland/blob/master/main.c#L201
16:24ifreund: in practice, wl_display_roundtrip() should only be used once on startup and maybe once on shutdown if you need to ensure the server gets a request before exiting
16:25ifreund: in case you're not clear on the difference: wl_display_roundtrip() is an abstraction over the wl_display.sync request
16:26ifreund: and has different semantics from a "normal" fully async dispatch
16:26wlb: wayland Merge request !449 opened by Daniel Stone (daniels) ci: Update ci-templates https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/449
16:26ifreund: see the libwayland doc comments or implementation for details
16:26ifreund: and perhaps the docs for the wl_display.sync request
16:30bitblt: how is wl_display.sync different from looping over a wl_display_dispatch until the event queue is exausted? I suppose the main difference is that the second one will block and await for events when empty?
16:34ifreund: bitblt: wl_display_roundtrip waits for the server's reply to the wl_display.sync request
16:34ifreund: since events/requests are processed in order, the client knows that once the server has replied to the sync request, the server has also recieved all requests sent prior to the wl_display.sync request
16:35ifreund: since it does not make a wl_display.sync request, wl_display_dispatch() gives no such guarantees
16:35bitblt: ah I see
16:36bitblt: ok last question for today:
16:37bitblt: I'm pretty confused about how xdg_surface_listener.configure and xdg_surface_ack_configure work, along with rendering and wl_surface_commit
16:39bitblt: As far as I understand various events before xdg_surface_listener.configure will arive, in which wayland server tells the wayland client what surface size, decorations etc he should ideally have
16:40bitblt: when the xdg_surface_listener.configure arrives it is like a 'commit' request from the server for these preferences
16:41bitblt: I don't see a reason that xdg_surface_ack_configure should exist, I mean the wayland client could just take his time, render the new surface and commit it after that .configure event?
16:43ifreund: bitblt: since the protocol is asynchronous, the server needs a way to know if the client received a given configure event before it made the wl_surface.commit request
16:43ifreund: ack_configure is this mechanism
16:44bitblt: aha yeah that makes sense
16:45bitblt: so because the order of the requests from the client is guranteed, this means that the server can know that the configure was handled before the commit, because the ack will arrive before the commit in this case
16:45ifreund: indeed
16:45bitblt: is there any specific example that this is useful for the wayland server?
16:47ifreund: it's necessary for frame perfection in many cases
16:47ifreund: for example during interactive resize with server-side decorations
16:47ifreund: or when resizing multiple clients at once in a tiled layout
16:49soreau: if the client has a min/max size, it might not attach a new buffer
16:49wlb: wayland Merge request !449 merged \o/ (ci: Update ci-templates https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/449)
16:49wlb: wayland/main: Daniel Stone * ci: Update ci-templates https://gitlab.freedesktop.org/wayland/wayland/commit/597a6b94f52d .gitlab-ci.yml
16:50bitblt: I think I have the basic unanswered questions covered, thanks ifreund !
16:50ifreund: no problem!
16:51bitblt: (btw river is a great idea, I want to migrate from bspwm to this at some point when there is no blurryness caused by fractional scaling)
16:57ifreund: bitblt: sounds like you hit https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3793
17:14bitblt: yes I'm pretty sure this is it, I was learning wayland to make a poc client just to understand / solve this if I can
17:15bitblt: another similar issue is this: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3705
19:13wlb: weston Merge request !1674 opened by Marius Vlad (mvlad) gitlab-ci.yml: Bump CI templates and use FDO_DISTRIBUTION_PLATFORM https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1674 [CI]
19:39wlb: weston/main: Marius Vlad * gitlab-ci.yml: Bump CI templates and use FDO_DISTRIBUTION_PLATFORM https://gitlab.freedesktop.org/wayland/weston/commit/d17e61546eee .gitlab-ci.yml
19:39wlb: weston/main: Marius Vlad * meson.build: Bump to C11 with GNU extensions https://gitlab.freedesktop.org/wayland/weston/commit/cfbf49d7e012 libweston/backend-rdp/rdp.h meson.build
19:39wlb: weston Merge request !1674 merged \o/ (gitlab-ci.yml: Bump CI templates and use FDO_DISTRIBUTION_PLATFORM https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1674)
21:45Fya: Does wayland-client objects store function pointers? Like the proxy->object.interface?
21:46Fya: I'm segfaulting when hot-reloading which usually happens when function pointers are unloaded through dlclose.
22:23Fya: Nevermind I figured it out.