07:22wlb: wayland Issue #452 opened by Julian Orth (mahkoh) Strings are UTF-8 https://gitlab.freedesktop.org/wayland/wayland/-/issues/452
09:11carbonfiber: Is it possible to launch weston on a specific vt? Similar to how you can do "Xorg :1 vt2" using Xorg? If so, how?
11:31mvlad: carbonfiber, manually no, it used to work with --tty option but that got removed. With a system service you can specify the tty.
11:41wlb: wayland Issue #453 opened by Simon Ser (emersion) Consider dropping since attribute for <enum> from DTD https://gitlab.freedesktop.org/wayland/wayland/-/issues/453
12:16carbonfiber: mvlad: ok. thanks.
12:40wlb: weston Merge request !1487 opened by Michael Olbrich (mol) backend-wayland: don't wait for one frame when starting the repaint loop https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1487 [Nested Wayland backend]
12:50pq: Company, because we cannot version wl_buffer and so cannot add anything in it, it has multiple independent factories. OTOH, a buffer is not inherently transformed, but the content may or may not be. For a square buffer, changing transformation does not imply a re-allocation.
12:51Company: that's a question of your mental model of what a buffer is
12:52Company: ie if you think about it more like vkMemory or more like vkImage
12:53pq: indeed, I think that should answer your question, too
12:55Company: that reminds me: does EGL (or GL) have an equivalent of VkSwapchain.preTransform?
12:59Company: and also, does Vulkan take ownership of the Wayland buffer transform or is that the application's job?
13:04zzag: daniels: gentle reminder about the governance meeting :)
13:04daniels: zzag: oh thanks but I can’t actually make it today in the end
13:04daniels: have fun though :)
13:05zzag: okay no problem :)
13:58tkna: Hi. Someone said this. Is it true? If a certain DAW is made by Wayland, is it not possible to use X11 plug-ins? Or is it very difficult? `you just can't draw a X11 window from inside the Wayland window/app` https://forum.cockos.com/showpost.php?p=2726617&postcount=20
14:03tkna: They state that this does not work. Do you think there is any hope of this being resolved unless each plugin supports Wayland? `* 3rd-party plug-in GUIs` `* Linux-specific plug-in formats (lv2, dssi, vamp)` https://support.presonus.com/hc/en-us/articles/19214558269581-Linux-Getting-Started
14:04kennylevinsen: tkna: If you have Xwayland, you can create entirely unrelated X11 windows but they will have zero association to the wayland windows
14:09wlb: wayland-protocols/main: Xaver Hugl * staging: add alpha-modifier protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/8b8b518df0e0 staging/alpha-modifier/README staging/alpha-modifier/alpha-modifier-v1.xml meson.build
14:09wlb: wayland-protocols Merge request !287 merged \o/ (staging: add alpha-modifier protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/287)
14:09tkna: kennylevinsen: I see. So it is not possible to have direct exchange of audio, MIDI, or other data in general, or to have parent-child relationships for windows, etc.? Perhaps it is inevitable, but it still means that third-party plug-in makers will have to switch to Wayland individually. thanks.
14:10kennylevinsen: tkna: Wayland does not concern itself with anything other than graphics and input, and you cannot have relationships between Wayland and X11 windows
14:10pq: tkna, parent-child window relations are not possible between Wayland-native and X11 windows. I did not expect audio, MIDI or other to go through X11 though, do they?
14:11pq: I mean, they could, but with lots of pain, and why...
14:12mclasen: for whatever reason, DAWs are the stronghold of xembed like approaches
14:12pq: sure, but the they use X11 also for audio for some reason?
14:13pq: *do they
14:13mclasen: not that I know
14:13pq: good
14:13kennylevinsen: that would have been horrifying :)
14:15pq: If it could be done with X11... Maybe not audio data per se, but perhaps routing addresses as window properties or something?
14:15pq: I can actually imagine that
14:16tkna: Even though it is not possible to have a parent-child relationship for windows, Audio and MIDI can be exchanged via JACK, etc., so it would be possible to use Xwayland's DAW to exchange data. It may be very difficult to operate, but not impossible.
14:17pq: pulling virtual audio cables between windows of two different apps, and have them even drawn.
14:18wlb: wayland-protocols Merge request !295 opened by Simon Ser (emersion) Draft: linux-dmabuf, xdg-output: use deprecated-since attribute https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/295
14:18pq: tkna, yes, JACK and everything else not using X11 should work just like before.
14:20tkna: Probably after 2-10 years of use together, the major plug-ins will generally be Wayland. After that, if you still want to use good old X11 plug-ins, you can use XWayland's DAW. That's probably going to be the overall policy or situation.
14:22tkna: I am convinced. We can use them together. It seems I don't have much to fear. Thank you kindly.
14:24jadahl: whats the state of https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/284 ? can that be landed too?
14:25zzag: iiuc https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/284#note_2332568 needs to be resolved
14:26zzag: either by agreeing to add such a new event when it's actually needed
14:26emersion: i don't think it matters too much tbh
14:26emersion: either add the event in a backwards compatible way, either draft a v3
14:26emersion: regardless tablet-v2 is what is widespread today
14:26zzag: ... or address that comment
14:26zzag: emersion: yeah
14:27emersion: what do you mean by "address that comment"?
14:27emersion: i don't want to add anything new in a stabilization MR
14:27jadahl: indeed
14:27zzag: emersion: add a serial argument
14:27zzag: and the frame event
14:27emersion: stabilization should just be about moving files around nothing more
14:27jadahl: either "fix" the non-stable one, then stabilize, or stablize, then fix
14:27jadahl: cant add the serial argument
14:27jadahl: thats a breaking change
14:27emersion: we can't add an arg in a backwards compatible way
14:28emersion: we can't stabilize with breaking changes: a v3 would need to go through staging first
14:35wlb: wayland/main: Manuel Stoeckl * connection: Dynamically resize connection buffers https://gitlab.freedesktop.org/wayland/wayland/commit/d074d5290263 src/connection.c src/wayland-client-core.h src/wayland-client.c src/wayland-private.h src/wayland-server-core.h src/wayland-server.c tests/connection-test.c tests/display-test.c tests/os-wrappers-test.c
14:35wlb: wayland Issue #237 closed \o/ (Mapping a lot of windows at once using wl_shm gets Xwayland killed https://gitlab.freedesktop.org/wayland/wayland/-/issues/237)
14:35wlb: wayland Merge request !188 merged \o/ (Add connection buffer size control https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188)
14:38pq: \o/
14:39ofourdan: woohooot!
14:39kennylevinsen: hah, that came as a surprise!
14:40ifreund: woah, that's crazy!
14:48carbonfiber: I am trying to launch a rootless xwayland in mutter after having launched mutter using --no-x11. why does the following not work? https://paste.linux.chat/?81271c985b140b9b#6fj7DoezFDgESeFrdjNe8VB5ZsCKezeVv1MCu6Z6ejkF
14:48carbonfiber: it doesn't report any error
14:48carbonfiber: but the xterm window is not visible
14:48ofourdan: you cannot run a rootless Xwayland by yourself, only the Wayland compositor can.
14:49ofourdan: (you can run a rootful Xwayland though)
14:49ofourdan: I mean, you *can*, it won't error out, but it won;t do anything as you already found out.
14:51carbonfiber: Why can't I do it manually? (assuming the wayland compositor is already running). I don't understand why I can't just use/write the exact same command that the wayland compositor (mutter) uses.
14:51pq: The Wayland compositor needs to know to connect to the rootless Xwayland to act as its X11 WM. Otherwise no X11 window can be visible.
14:51ofourdan: because Xwayland is a prett ystandard Xserver, and requires a window manager
14:53pq: You cannot use a regular X11 WM with a rootless Xwayland either, because only the Wayland compositor can show windows.
14:59carbonfiber: hmm.
15:02Company: pq: the DAW world works just like the video player world - the client library/plugin hands an XID to the DAW and it does with it what it needs to integrate it
15:03carbonfiber: So my thought process was to start a rootless Xwayland, and then start the mutter x11 window manager (which is automatically used when --no-x11 is NOT specified).
15:03Company: pq: the whole sound setup is using a different channel - the same channel that's used to exchange the XID pretty much
15:03carbonfiber: I thought that the wayland compositor just communicated with Xwayland, with the x11 window manager just being another x11 application. But based on what you have written this seems to not be the case. Does the wayland compositor communicate with Xwayland, or with the "Xwayland window manager", or both?
15:04ofourdan: carbonfiber: fwiw, mutter / GNOME Shell already has Xwayland on demand (i.e. it won;t spawn Xwayland until some X11 client needs it), and also have optionally terminate Xwayland whel X11 cleints are gone (that's an experimental feature tht needs to be explicitely enabled though)
15:04Company: pq: note that this sometimes is in-process and sometimes it's out-of-process - which makes this real funny when you're in-process and your audio plugin draws its UI with GLX while your DAW is using EGL
15:05kennylevinsen: carbonfiber: The Wayland server is the x11 window manager when running X11, as it needs to afford Xwayland some special privileges not normally available to Wayland clients
15:05kennylevinsen: As well as to integrate with the general window management within the Wayland server
15:06pq: Company, that's good. Things could have been worse. I can imagine that some might desire the ability to late windows of virtual devies, and then connect virtual wires between them. Oh, but that would require alpha... no, shaped windows for the wires. Seems doable. :-)
15:06ofourdan: carbonfiber: with Wayland, the X11 window manager is the same process as the Wayland compositor - Xwayland is a pretty standard Wayland client, and as such it doesn't access to global coordinates for example, or stackign of windows, all that X11 mechanisms rely on X11 and as such, it requires to be handled by the Wayland compositor which is the only one with a global vision over both X11 and Wayland
15:06pq: "late"? uhh... "have", I think
15:06ofourdan: surfaces to inter-mix them on screen, as with rootless.
15:07pq: carbonfiber, https://wayland.freedesktop.org/docs/html/ch05.html explains a little bit.
15:08Company: pq: I think they stopped doing that once they had to support multiple sound servers, and that was way before jack, so very long ago
15:09kennylevinsen: clearly what the protocol needs is the ability to attach an arbitrary 3D model onto which the surface will be texture mapped
15:09kennylevinsen: so you can shape your window as a 3d dangling cable
15:09Company: I think the proper way to handle this today with Wayland is the same way browsers do it
15:09pq: Company, I see, I'm just late to the party. So that's what the "late" was! My hands know more than me.
15:10Company: run an embedded nested Wayland server in the DAW
15:10Company: pq: I started my free software career as a GStreamer developer, I still have the scars from that time ;)
15:10pq: yeah, a tall order - why not stick to Xwayland?
15:11Company: I am very sure they are gonna run a nested wayland compositor *with* XWayland
15:11pq: I don't doubt that, but what do they gain from the migration to Wayland?
15:12Company: a better platform
15:13pq: they hate graphical glitches too, or?
15:13Company: no, they use xembed
15:13pq: point
15:14pq: what makes Wayland attractive then?
15:14Company: 1. it's maintained
15:14Company: 2. it has the modern features, like fractional scaling and such
15:15Company: i don't think it's gonna happen quickly, it's not that interesting, but it's gonna happen at some point
15:15pq: right. Do they need to follow the toolkits they use?
15:16Company: as long as they don't want to use external processes
15:16Company: well, that came out wrong
15:17carbonfiber: hmm. when running "mutter --wayland" I have 2 processes running. "/usr/bin/mutter" and "/usr/libexec/mutter-x11-frames", so I thought that "/usr/bin/mutter" was the wayland compositor, and "/usr/libexec/mutter-x11-frames" was the x11 window manager. But know you say that it all runs in a single process. Then why does ps show 2 processes?
15:17pq: just wondering what is mostly producing the pressure, is it a stick or a carrot
15:17Company: there's 2 things they need to weigh: plugins may use the same toolkit
15:17Company: and their UI may want to use newer versions of the toolkit
15:17carbonfiber: but now you say*
15:17Company: at this stage I think it's carrot
15:18ofourdan: /usr/libexec/mutter-x11-frames is just a helper application to reparent X11 windows (i.e. decorate them) usign gtk4
15:18pq: good, a stick would be bad PR
15:18ofourdan: (/usr/libexec/mutter-x11-frames is not an X11 WM, mutter is)
15:18kennylevinsen: carbonfiber: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175, "Mutter is still the WM"
15:19carbonfiber: ok
15:20Company: pq: the GTK DAWs have all updated to GTK4 - unless you count Ardour, which has (first soft, then hard) forked GTK2 and been doing their own UI toolkit
15:20Company: no idea what Qt version the Qt ones are on
15:21carbonfiber: if it is all a single process, then it makes sense why I cannot launch a "mutter Xwayland window manager" afterwards.
15:23carbonfiber: thanks for the help.
15:23ofourdan: np!
15:25MrCooper: pq: FWIW, once upon a time, some people were pushing for making the X server also a sound server, kind of like pipewire from hell :/
15:26ofourdan: hahum, some even managed to make it a print server :)
15:27MrCooper: right, which at least has some overlap with other X functionality :)
15:27ofourdan: lol
15:27ofourdan: I still wonder why it was removed…
15:28MrCooper: people got bored of measuring glxgears performance in pages per minute? ;)
15:29ofourdan: I'm sure that has to do with saving trees or something!
16:10Company: MrCooper: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/231 - the sound server people are already sneaking in!
16:10MrCooper: hehe
16:32carbonfiber: I am trying to use mutter with a rootfull Xwayland now. I am using the following commands: https://paste.linux.chat/?e7590c831c9c3770#AhsoFxETfAJoGvrZxP8uj1qfQQrSVvXDAAz6o9p9yN1A but for some reason I get giant cursors inside of the rootfull Xwayland window: https://pasteboard.co/xuMzkBx7BCgt.png anyone know why?
17:23ofourdan: is that an hidpi screen?
17:29ofourdan: anyway, I think this is mutter setting that cursor (mutter running within the rootful Xwayland instance), I dunno how exactly mutter decides on the size of the cursor.
17:59Company: maybe try running yet another rootful XWayland inside that rootful XWayland?
17:59Company: just to see what the cursor does?
18:00vyivel: 🤔 xwayland in xwayland would be just xx
18:00vyivel: (xephyr)
18:03carbonfiber: ofourdan: not hidpi. it is a 1200x800 screen using the vmware svga driver in virtualbox.
18:11Company: stupid nested wayland compositors don't inherit the large cursor sizes
18:24Company: I get almost the same framerate!
18:24Company: https://i.imgur.com/oTviUZN.png
18:25Company: that's XWayland with mutter as WM running weston running XWayland with mutter as WM running weston running my little benchmark
18:25Company: but mutter gets real confused about sizing and the XWayland window grows way too big
18:26Company: might be related to the cursor issue
18:26carbonfiber: Xception
18:27carbonfiber: a dream inside a dream inside a dream :O
18:27Company: it's a pretty xceptional thing that the dream doesn't slow down time pretty much at all
18:29Company: uh neat
18:29Company: Cairo does run faster inside the XWaylands
18:30Company: it might be that the inside is running at 100% scale factorand not at 200%
18:32Company: and changing the scale factor made things explode :(
18:32carbonfiber: :O
18:32ofourdan: The size of the cursor in mutter is controlled by a setting, maybe try changing that?
18:34ofourdan: org.gnome.desktop.interface cursor-size
18:34ofourdan: e.g. gsettings set org.gnome.desktop.interface cursor-size 16
18:35carbonfiber: that seems likely to also change the cursor size of the "outer mutter instance".
18:36ofourdan: yes, likely
18:36ofourdan: or maybe you need to run gnome-settings-daemon to apply the gsettings
18:36ofourdan: (I mean within the nested Xwayland instance)
18:38ofourdan: ah, my bad, it's started by dbus nowadays
18:39ofourdan: so maybe it's just a matter of running a dbus session in the nested Xwayland instance
18:40ofourdan: (it's what xwayland-run does, btw)
18:41carbonfiber: hmm ok. changed org.gnome.desktop.interface cursor-size to 1 just for fun lol
18:41carbonfiber: did not have the expected results
18:41ofourdan: that's a bit extreme!
18:42carbonfiber: it did not change the cursor size of the "outer mutter instance" at all. but actually made the cursor inside of Xwayland have the same size as the "outer mutter instance". I don't know why that works at all lol.
18:42carbonfiber: so it fixed it haha
18:45ofourdan: fwiw, mutter running in a nested Xwayland rootful instance tendst oappl ythe xrandr config from the host, so you end up with an Xwayladn rootful window as large a your actual physical setup...
18:45ofourdan: anyway, g'night!
18:46carbonfiber: good night
19:38emersion: jadahl, pq: should we plan a new wayland release soon?
19:38emersion: i can send out a tentative release schedule if so
19:39emersion: it's been a while and many pending MRs have been merged or are in a good position to be merged soon
20:10Company: looking at https://www.phoronix.com/review/kde-plasma-6-amd-gaming/2 - the CS2 and GravityMark numbers in gnome-shell, does that look like direct scanout failing? Or is that something else that would be causing it?
20:11Company: I'm mostly wondering if I can assume a ~25% perf drop as a rule of thumb for direct scanout failing on high gpu load
20:12jadahl: emersion: sounds like a good idea
20:16jadahl: Company: could be. not sure why it'd fail. or perhaps kwin is better at retrying
20:16Company: it's shell 42, so who knows
20:17Company: I'm mostly wondering because of GTK's GraphicsOffload and trying to use it for GL
20:18Company: would be a neat way to detect it via the fps
20:19Company: it could also be that source tries drm leasing and then doesn't properly fall back to direct scanout
21:21zamundaaa[m]: Company: direct scanout most definitely doesn't have a 25% perf impact
21:23Company: zamundaaa[m]: any guess what would be causing that difference?
21:25zamundaaa[m]: The best guess I have is that there's lots of things adding together. Like, a worse format+modifier + no direct scanout + probably more, because I wouldn't expect those two things to crack even 10%