05:36wlb: weston Issue #823 closed \o/ (Weston crashes when starting Warcraft III in wine-wayland https://gitlab.freedesktop.org/wayland/weston/-/issues/823)
05:36wlb: weston/main: Derek Foreman * input: avoid crash by using surface directly https://gitlab.freedesktop.org/wayland/weston/commit/e622be7423c8 libweston/input.c
05:37wlb: weston Merge request !1372 merged \o/ (input: avoid crash by using surface directly https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1372)
05:49wlb: weston Issue #824 opened by Himanshu Bhavani (himanshu.d) [imx8mp]Weston-rdp screen share issue https://gitlab.freedesktop.org/wayland/weston/-/issues/824
08:22WhyNotHugo: When my client owns the clipboard selection and another client wants to paste I get an fd. Is it safe to change that fd to non-blocking, or could this cause problems on the other side?
08:47ascent12: WhyNotHugo: It's fine to set it to nonblocking.
08:47ascent12: How something reads from a pipe doesn't affect the writing side (outside of not reading the data at all)
08:48Company: I'm wondering if there is any rules on what fd you can send
08:48WhyNotHugo: ascent12: thanks! I think I need to study more on the subject, but I'm not sure I have good material for this specific topic.
08:49Company: like, a file manager could send an fd to a regular file to dump an image paste straight into a file
08:49WhyNotHugo: Company: The protocol doesn't restrict this much, and I've seen different applications send blocking and non-blocking fds.
08:50WhyNotHugo: An fd that points to a regular file would mess up the selection owner, since writing to a file in non-blocking mode is still blocking :(
08:50WhyNotHugo: So if a file manager does this and you paste a huge file into a network mount, then the selection owner will freeze for a while
08:50Company: to be clear: I'm not aware of anyone doing it
08:51WhyNotHugo: Doing so is asking for things to break.
08:51ascent12: The compositor is the one opening the pipe. The spec mentions it, but I don't think it's truly a hard requirement
08:51Company: but this is Linux, so somebody somewhere...
08:51ascent12: But also, the compositor isn't going to do random dumb stuff to mess with clients for no reason
08:52Company: ascent12: the compositor doesn't open the pipe, the app doing the request does
08:52ascent12: Actually yeah, I think I'm misremembering that
08:52ascent12: Not the part of the spec I'm the most familiar with
08:52WhyNotHugo: Yeah, the receiving client opens the fd, see wl_data_offer::receive
08:52Company: I wrote that code for GTK4
08:53WhyNotHugo: The spec just says: The transfer happens through the passed file descriptor (typically created with the pipe system call).
08:53Company: but I didn't think too much about it, I had to make an abstraction for X11 work
08:55Company: I've argued a bunch with Nautilus devs (also about that file dropping thing), and the conclusion was that it's not worth it with the extra amount of pain you could get from trying it
08:58WhyNotHugo: Company: So Nautilus uses a pipe?
08:58Company: every GTK4 app uses a pipe
08:59WhyNotHugo: Good to know. Thanks for your work on that!
09:00Company: GTK4 has a framework that optimizes in-app copies, so the fd usage only happens at the end of that, and because of that nobody can influence how data is transferred
09:01Company: plus, only wayland uses fds, X11 uses window properties and Windows uses COM or shm, so that wouldn't be portable
10:24pq: Riolku, in protocol designs where you would need a unique token in order to know which event matches which request it is a common design pattern to create a new object instead to deliver the event. The protocol object ID then acts as the unique token, and the protocol library takes care of allocating, tracking and freeing it correctly.
10:25pq: Riolku, it also makes it easy if you decide to not want the event after all, the protocol library takes care to ignore the event for you.
10:33pq: vyivel, updating protocol READMEs would be nice even if they might be often forgotten. Though when someone explicitly cc's eeryone mentioned, if someone does not want to be on that list anymore, they'd notice to remove themselves.
12:17wlb: weston/main: Derek Foreman * headless: Enable use as a secondary backend https://gitlab.freedesktop.org/wayland/weston/commit/e3a509236b36 libweston/backend-headless/headless.c
12:17wlb: weston Merge request !1364 merged \o/ (headless: Enable use as a secondary backend https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1364)
16:29wlb: weston Merge request !1019 merged \o/ (ivi-shell: activate desktop surface https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1019)
16:29wlb: weston/main: Tomohito Esaki * ivi-shell: Properly handle seat hotplugging https://gitlab.freedesktop.org/wayland/weston/commit/ec3e2d2d3600 ivi-shell/ ivi-shell.c ivi-shell.h
16:29wlb: weston/main: Tomohito Esaki * ivi-shell: activate desktop surface https://gitlab.freedesktop.org/wayland/weston/commit/0e082315d75a ivi-shell/ ivi-layout-export.h ivi-layout-private.h ivi-layout-shell.h ivi-layout.c ivi-shell.c ivi-shell.h
16:29wlb: weston/main: Tomohito Esaki * hmi-controller: activate and deactivate sruface https://gitlab.freedesktop.org/wayland/weston/commit/7dbb166de6fb ivi-shell/hmi-controller.c
16:29wlb: weston/main: Tomohito Esaki * ivi-shell-user-interface: change timing to create the launcher surface https://gitlab.freedesktop.org/wayland/weston/commit/608e1ee86d3d clients/ivi-shell-user-interface.c
16:57wlb: weston Merge request !1373 opened by Marius Vlad (mvlad) build: bump to version 12.0.91 for the alpha release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1373
17:02wlb: weston/main: Marius Vlad * build: bump to version 12.0.91 for the alpha release https://gitlab.freedesktop.org/wayland/weston/commit/5d7412c1bd0c meson.build
17:02wlb: weston Merge request !1373 merged \o/ (build: bump to version 12.0.91 for the alpha release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1373)
17:06wlb: weston New tag: 12.0.91 https://gitlab.freedesktop.org/wayland/weston/tags/12.0.91
19:47wlb: wayland-protocols Merge request !256 opened by Derek Foreman (derekf) commit-queue-v1: Add new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256
19:57wlb: wayland.freedesktop.org Merge request !64 opened by Marius Vlad (mvlad) releases: add weston 12.0.91 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/64
19:58wlb: wayland.freedesktop.org/main: Marius Vlad * releases: add weston 12.0.91 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/d6d192fad152 releases/weston-12.0.91.tar.xz releases/weston-12.0.91.tar.xz.sig releases.html
19:58wlb: wayland.freedesktop.org Merge request !64 merged \o/ (releases: add weston 12.0.91 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/64)
20:03wlb: wayland.freedesktop.org Merge request !65 opened by Marius Vlad (mvlad) releases.html: Fix release announcement link https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/65
20:04wlb: wayland.freedesktop.org Merge request !65 merged \o/ (releases.html: Fix release announcement link https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/65)
20:04wlb: wayland.freedesktop.org/main: Marius Vlad * releases.html: Fix release announcement link https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/e4073b505682 releases.html
22:04emersion: pq: hm if i want to blend in linear space, i need to un-do the alpha premult before srgb decoding and then re-do it before blending?
22:04emersion: kwin does that, weston seems (?) to do that, sway doesn't
22:04emersion: s/sway/wlroots/
22:04emersion: (cc mstoeckl)
22:21Company: or you need to do srgb decoding in premultiplied space
22:21Company: no idea how hard that is though, I never tried to do the math
23:18DemiMarie: I now know why (to the best of my knowledge) nobody has written a rootless Wayland compositor before: it is really hard.
23:21danieldg: how do you define rootless?
23:22bookworm: other than the obvious?
23:22DemiMarie: In the sense of rootful vs rootless Xwayland
23:22DemiMarie: There is probably a better term that I am not aware of
23:22bookworm: setuid essentially
23:22DemiMarie: no
23:23danieldg: I'm not familiar enough with X to know how that would matter when translated to wayland compositors
23:23DemiMarie: By “rootless,” I mean a nested compositor where each Wayland toplevel and popup becomes a window in the outer compositor (which might be using a different rendering protocol)
23:24danieldg: oh, for nested servers; I didn't get that part
23:24danieldg: waypipe seems to kinda do that, though likely not as you want
23:24DemiMarie: Now imagine a nested compositor with a backend that is effectively a subset of X11
23:24ids1024: Come to think of it, it is a bit suboptimal that "rootless XWayland" and "rootless X" use "rootless" to mean different things.
23:26DemiMarie: It isn’t possible to implement a conformant rootless Wayland compositor with an X11 backend
23:26danieldg: I wouldn't think it would be much harder than writing an X11 client that throws pixels at the device plus a wayland server that grabs them
23:26DemiMarie: Other way around
23:26ids1024: I guess the RDP backend of Weston (as used for Wayland support in WSL2) is a bit like that.
23:26DemiMarie: no, actually you got it right
23:26DemiMarie: @_oftc_danieldg:matrix.org: the hard parts are handling window resizes and Xwayland
23:27DemiMarie: The real backend protocol is not X11, but rather something Qubes OS-specific; it is, however, based on X11.
23:27danieldg: sure, you'd have tearing issues and maybe non-working presentaiton feedback
23:28DemiMarie: Also both the X11 WM and the Wayland client think their idea of the surface size is authoritative.
23:29danieldg: sure; you'll have a bad frame during resize but wayland servers can tell the client to change size too
23:30DemiMarie: yeah, now I just need to figure out how to express that with wlroots
23:31danieldg: 'send a reconfigure' I guess. sway does something when you do 'swaymsg resize ...'
23:44Company: I would expect most compositors need to do that when the output changes
23:45danieldg: sure, but that produces a lot more changes than just a server-initiated resize op
23:48DemiMarie: yeah
23:48DemiMarie: It isn’t impossible, just tedious