08:09 <emersion> pq: interesting to hear a hw driver dev say that hw shouldn't dictate how standard APIs look like :)

08:20 <pq> emersion, I know, right!

08:21 <pq> awesome!

08:22 <emersion> indeed!

08:22 <pq> swick, cool, thanks - what's there now (and already landed) were pretty mechanical, but I'm writing a new story that will need more serious review when it's out as a MR.

08:44 <ofourdan> emersion: hey, do you have anything else in the pipe for libxcvt? if not, I'll make a 0.1.1 release.

08:44 <emersion> ofourdan: i can't think of anything else, feel free to release away :)

08:44 <ofourdan> coo, thanks!

08:44 <ofourdan> *cool

08:57 <wlb> weston Merge request !691 merged \o/ (screen-share: Add option to start screen sharing on weston startup https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/691)

08:57 <wlb> weston/main: Marek Vasut * screen-share: Add option to start screen sharing on weston startup https://gitlab.freedesktop.org/wayland/weston/commit/b02149e43b79 compositor/screen-share.c man/weston.ini.man weston.ini.in

09:06 <wlb> weston/main: Manuel Stoeckl * gl-renderer: add support for (a|x)bgr2101010 shm formats https://gitlab.freedesktop.org/wayland/weston/commit/c7fbc971201c libweston/renderer-gl/ gl-renderer-internal.h gl-renderer.c

09:06 <wlb> weston Merge request !709 merged \o/ (gl-renderer: add support for (a|x)bgr2101010 shm formats https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/709)

09:23 <wlb> weston Merge request !712 merged \o/ (pipewire: Drop support for 0.2 API https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/712)

09:23 <wlb> weston/main: Emmanuel Gil Peyrot * pipewire: Drop support for 0.2 API https://gitlab.freedesktop.org/wayland/weston/commit/d4a208c2b1d2 pipewire/ meson.build pipewire-plugin.c

09:24 <emersion> ofourdan: the motivation for https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/775 is that the latest released xserver files conflict with libxcvt

09:24 <emersion> so can't have both installed

09:24 <emersion> besides, some distributions don't even have libxcvt packaged yet, so building xserver is painful

09:24 <ofourdan> which part, the "cvt" utiluty I guess?

09:24 <emersion> plus some man pages

09:25 <ofourdan> yeah, the cvt.1 mostlikely

09:25 <ofourdan> fwiw, I'm fine with xorg/server!775

09:25 <ofourdan> I'll make that clear in the mr :)

09:25 <emersion> ah cool

09:48 <wlb> wayland Issue #247 opened by () Notes for protocol-next design https://gitlab.freedesktop.org/wayland/wayland/-/issues/247 [Protocol-next]

09:56 <ofourdan> emersion: fwiw, in fedora, the binary package is split into the library (and devel) and the cvt utility, with the latter being set to confict with the current xserver so you can install the lib independently

09:59 <emersion> arch doesn't do split packages

10:01 <jadahl> ofourdan: afaik, rpm passes --wrap-mode nodownload by default

10:03 <ofourdan> jadahl, not sure I'm following, rpm doesn't have such an option, does it?

10:04 <emersion> --wrap-mode is a meson flag

10:05 <ofourdan> right, so rpmbuild

10:06 <ofourdan> waynay, all I mean is that, by splitting the package, we could get the lib installed along with the current xserver package :)

10:06 <ofourdan> *anyway

10:06 <emersion> yeah, but splitting or not splitting is a distro policy decision

10:07 <ofourdan> sure

10:07 <emersion> some do, some don't

10:07 <jadahl> ofourdan: the %meson macro is expanded to pass that to meson

13:46 <wlb> weston Issue #556 opened by () Rotary encoder Knobe (Joystick) with Wayland-EGL platform not working https://gitlab.freedesktop.org/wayland/weston/-/issues/556

19:27 <zubzub> It seems the resize functionality in weston is broken by design if you resize where a move is required, ie resizing from topleft corner.

19:28 <zubzub> there seems to be a race where the resize grab is released before the last resized buffer is committed

19:28 <zubzub> what happens is that the surface is no longer moved and instead resized from the bottom right

19:29 <zubzub> you can see it subtly if you do a topleft resize and release mouse button while moving

19:30 <zubzub> it's especially noticable if the client is slow to respond

20:06 <DemiMarieObenour[m]> Has anyone here thought of having a “Foo over Wayland” protocol for various values of “Foo”? And are there any cases where this would actually be useful?

20:07 <DemiMarieObenour[m]> I can think of quite a few bad examples (such as “TCP over Wayland”), but I am wondering there are any good ones. The first one that comes to mind is actually X11 over Wayland, for use by XWayland.

20:07 <qyliss> apart from PipeWire? :P

20:08 <DemiMarieObenour[m]> Do you mean “send PipeWire messages as Wayland arrays”?

20:08 <qyliss> yeah, I think that could be cool

20:09 <qyliss> I'm working in virtualized environments not dissimilar to yours (although different enough to be incompatible), and handling Wayland is already a requirement

20:09 <qyliss> so being able to send other things over wayland is very appealing

20:10 <DemiMarieObenour[m]> Can you go into details? There might be room for collaboration here.

20:10 <qyliss> although I haven't looked into it at all, really, so probably it would be killed by latency

20:11 <qyliss> sure, I'm working on a compartmentalized operating system called Spectrum (https://spectrum-os.org/)

20:11 <qyliss> it's still very early development

20:11 <qyliss> my plan is to use the Wayland-over-virtio-gpu stuff that Google is developing for Chromium OS

20:11 <DemiMarieObenour[m]> OH you’re Alyssa Ross!

20:11 <qyliss> in previous prototypes i've used virito-wl

20:11 <qyliss> I am :)

20:12 <DemiMarieObenour[m]> Nice to meet you! I’m Demi Marie Obenour and I work on Qubes OS.

20:13 <qyliss> I know!

20:13 <DemiMarieObenour[m]> 🙂

20:13 <qyliss> I've been following your work here and in #sway-devel for the past little while :)

20:14 <DemiMarieObenour[m]> Thanks! I actually originally tried writing the compositor in Rust using Smithay, but Smithay turned out to not be ready yet.

20:14 <qyliss> that's sadly the impression I got too

20:15 <DemiMarieObenour[m]> That is expected to change, though. Smithay seems to be quite actively developed.

20:17 <qyliss> yeah

20:17 <DemiMarieObenour[m]> What are your thoughts on the attack surface of Wayland + virtio-gpu?

20:18 <qyliss> my thoughts are that it's not great, but there's not much I can do about it, and I don't have much in the way of alternatives

20:19 <qyliss> but I do like that Google is shipping it in products, because that means there's at least lots of eyes on it

20:19 <qyliss> (or rather, I assume they're gonig to be shipping it in products at some point soon-ish)

20:22 <DemiMarieObenour[m]> I mean there is the “security at all costs” approach of pure software rendering + a custom GUI protocol. That is the route Qubes OS took and I still think it was the correct one, given the Qubes OS threat model. But if one needs multi-tenancy on commodity GPUs then I am not aware of a better solution yet (there is work on changing that).

20:23 <qyliss> Yeah, I agree 100% that Qubes made the right decision for Qubes

20:24 <DemiMarieObenour[m]> Thankfully some people are working on leveraging the virtualization support in recent Intel GPUs to make secure multi-tenancy possible.

20:25 <qyliss> I recently wrote a report about the possibilities for GPU multi-tenancy in Spectrum, perhaps you'd find it interesting: https://spectrum-os.org/lists/archives/spectrum-discuss/20211026200434.w6yzfnl6duhqjgig@x220.qyliss.net/

20:25 <qyliss> I was just reading about the virt stuff in recent Intel — AIUI there's not even support in Linux for it yet?

20:26 <qyliss> if you know where I can follow developments on Intel GPU virt I'd love to know

20:31 <DemiMarieObenour[m]> Most of the recent work that I am aware of is in https://libvf.io from Arc Compute.

20:31 <qyliss> Oh somebody sent that to me the other day!

20:31 <qyliss> I'll keep a closer look on it, thanks!

20:32 <DemiMarieObenour[m]> You’re welcome!

22:25 <wlb> wayland Issue #248 opened by () can't close client in client created listener https://gitlab.freedesktop.org/wayland/wayland/-/issues/248