From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 6C5C65A01 for ; Fri, 18 Jul 2025 10:20:00 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 4FC3B59D7; Fri, 18 Jul 2025 10:19:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) by atuin.qyliss.net (Postfix) with ESMTPS id 1196D58F7 for ; Fri, 18 Jul 2025 10:19:58 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 2952DEC0166; Fri, 18 Jul 2025 06:19:57 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Fri, 18 Jul 2025 06:19:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1752833997; x=1752920397; bh=K3LvkFcG8y JzS8144xW6Tw1fqDd0WdUzuQ3YkrB6w0o=; b=QWXTcflRvwD4ANw7JpoAQeLZiW 833eh9ZIHIwfhRmX8qh4I4oewoueqN9FewfRC+j7tgMeQ5dFMwA0w7BOoxEkINHB qE0uLnhj9ahVyfrrv5XFMoa9eFb6sWlPOThk8IEpEGZwKm/HAjCj6Ktg7rZgChVo mJu1Li4E93h/Rv3XKfYBaAJosUIjwrLtpWsZpMOQjeHembRzKfgZ36gCEEB+wO1L o48eXCctL+mUzp6QPgnvA+sgDsQze3RY+m+VZiN1Q22M4YZ+M8icLCv1iks0XQHm lFU3p9omrp3J6O8ngqelOGz9OynSU1KKq+4GWyIFHSxbHSehRMarw/u16b3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1752833997; x=1752920397; bh=K3LvkFcG8yJzS8144xW6Tw1fqDd0WdUzuQ3 YkrB6w0o=; b=mSwN/fjCCKN8ZE81T/Nm3uEPxgcVMa7v630aw5cDiaM5mYKXNoT xtb3evCLuTOXMPGmPRoOlJ0SvKirOF/hTXo+5HYYFajq5XcW0ZVOoRcA3qbcDhhl JYQWYBnemewjP6kdBr6y7I4DHNodUaNY5W3RapJGZIehIV7tg3MdR+xz2c5645gL 2SSBWCz88tIZ7xQXPlBqWQ4d0xLPSfPlB0HfVCkpe+2siXgm6h/RYwS1dQmUGga+ +qcc68TlXtYAbXrdnbn9HbNQ6lMRiSsy79l4Mh4JqElcwEADOXdbl0zgYOlykhTc Acttm88sFKGmyCGZ+wSaJrIpG2U2apL/9Dw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdeifedvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgesghdtreertddtjeenucfhrhhomheptehlhihsshgrucft ohhsshcuoehhihesrghlhihsshgrrdhisheqnecuggftrfgrthhtvghrnhepteejtefgve efgedugeeukeehjeeuffelhfetgeehfeejleethfeflefgvdevgedvnecuffhomhgrihhn pegslhhuvgiirdhsvggrthdpmhhiughirdhnohenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehhihesrghlhihsshgrrdhishdpnhgspghrtghp thhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepuggvmhhiohgsvghnoh hurhesghhmrghilhdrtghomhdprhgtphhtthhopeguvghvvghlsehsphgvtghtrhhumhdq ohhsrdhorhhg X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Jul 2025 06:19:50 -0400 (EDT) Received: by sf.qyliss.net (Postfix, from userid 1000) id 028212B73210F; Fri, 18 Jul 2025 12:19:35 +0200 (CEST) From: Alyssa Ross To: Demi Marie Obenour Subject: Re: [PATCH v3] Run PipeWire and WirePlumber in the VMs In-Reply-To: <87tt39stoz.fsf@alyssa.is> References: <638beeaa-2351-4f51-81a6-bc58883930c2@gmail.com> <87seiyg6w2.fsf@alyssa.is> <87tt39stoz.fsf@alyssa.is> Date: Fri, 18 Jul 2025 12:19:33 +0200 Message-ID: <87qzydsswa.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: AUGOPUV4RNJI6PD4N2JI525FTCAIHX7Z X-Message-ID-Hash: AUGOPUV4RNJI6PD4N2JI525FTCAIHX7Z X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Spectrum OS Development X-Mailman-Version: 3.3.9 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alyssa Ross writes: > Demi Marie Obenour writes: > >> On 7/14/25 10:54, Alyssa Ross wrote: >>> Demi Marie Obenour writes: >>>=20 >>>> WirePlumber is completely overkill as a session manager here, and >>>> ideally a trivial session manager would be used instead. I did build a >>>> Spectrum OS image and found that PipeWire and WirePlumber both >>>> successfully started. PipeWire is configured to listen on the >>>> PulseAudio socket, so PulseAudio compatibility works. This does inject >>>> a large number of completely unnecessary files into the VM, notably for >>>> libcamera and Bluetooth support. >>>=20 >>> Yeah, I saw this in the log: >>>=20 >>> N 14:27:54.810067 wp-internal-comp-l ../lib/wp/private/internal-comp-lo= ader.c:588:on_component_loaded: optional component 'sup= port.logind [module: libwireplumber-module-logind]' failed to load: failed = to start systemd logind monitor: -2 (No such file or directory) >>> N 14:27:54.811299 wp-internal-comp-l ../lib/wp/private/internal-comp-lo= ader.c:640:wp_component_array_load_task_execute_step: s= kipping component 'monitor.bluez.seat-monitoring [virtual]' because some of= its dependencies were not loaded >>> E 14:27:54.851210 spa.dbus ../spa/plugins/support/dbus.c:333:= impl_connection_get: Failed to connect to system bus: Failed to connect to = socket /run/dbus/system_bus_socket: No such file or directory >>> E 14:27:54.852143 spa.bluez5 ../spa/plugins/bluez5/bluez5-dbus.= c:6632:impl_init: failed to get dbus connection >>> N 14:27:54.855904 wp-device ../lib/wp/device.c:710:wp_spa_devi= ce_new_from_spa_factory: SPA handle 'api.bluez5.enum.dbus' could not be loa= ded; is it installed? >>> N 14:27:54.856657 s-monitors bluez.lua:411:createMonitor: PipeW= ire's BlueZ SPA plugin is missing or broken. Bluetooth devices will not be = supported. >>> E 14:27:54.859091 spa.bluez5.midi ../spa/plugins/bluez5/midi-enum.c:= 805:impl_init: Creating GDBus connection failed: Could not connect: No such= file or directory >>> N 14:27:54.859810 wp-device ../lib/wp/device.c:710:wp_spa_devi= ce_new_from_spa_factory: SPA handle 'api.bluez5.midi.enum' could not be loa= ded; is it installed? >>> N 14:27:54.860524 s-monitors bluez-midi.lua:95:createMonitor: P= ipeWire's BlueZ MIDI SPA missing or broken. Bluetooth not supported. >>> E 14:27:54.861346 spa.bluez5.midi.no ../spa/plugins/bluez5/midi-node.c:= 1989:impl_init: failed to get dbus connection: Could not connect: No such f= ile or directory >>> E 14:27:54.862435 pw.resource ../src/pipewire/resource.c:255:pw_= resource_errorf_id: can't create node: Input/output error >>> W 14:27:54.863275 wp-node ../lib/wp/node.c:913:wp_impl_node_= new_from_pw_factory: failed to create node from factory 'spa-node-factory' >>> N 14:27:54.863965 s-monitors bluez-midi.lua:130:createServers: = Failed to create BLE MIDI server. >>> [0:00:01.314658075] [123] INFO IPAManager ipa_manager.cpp:137 libcamer= a is not installed. Adding '/nix/store/src/ipa' to the IPA search path >>> [0:00:01.321611889] [123] INFO Camera camera_manager.cpp:326 libcamera= v0.5.0 >>>=20 >>> Can we set something in a config file or something to disable this extra >>> stuff? >> >> I started work on a v4 patch, but before sending it I decided to test >> that not only did PipeWire and WirePlumber start, but also that I >> could actually play sound to a virtio-sound device I had attached >> to the VM. This failed rather miserably, and I finally figured out >> the culprit: PipeWire relies on udev for device discovery, and without >> udev it doesn't detect any devices. >> >> It appears possible to create devices in PipeWire via the PipeWire CLI >> or via the configuration file. The former would allow them to be >> created by mdevd, while the latter would be appropriate if the devices >> were known to be ready before PipeWire started. >> >> I strongly recommend using either systemd-udevd (with systemd) or eudev >> (without systemd) in the host and in any VM that will have real hardware >> attached to it. udev rules are where all the upstream work on uevent >> processing is happening, so it fits with Spectrum's "upstream first" >> mindset. Something simpler like mdevd might be appropriate for VMs that >> will only ever see virtual hardware with known behavior and do not need >> to deal with the quirks of real hardware. > > No real objection to udev in VMs. On the host I'm less sure, because > ideally the host shouldn't really be interacting with hardware very > much, so it comes down to whether there are things in scope for the host > where the kernel doesn't do the right thing by default. > >> For the host, I think systemd is probably the right solution. It's >> complicated, but that is because it solves a complicated problem. >> Without systemd, Spectrum will wind up needing to reimplement a lot of >> configuration that has already been written for systemd. Also, systemd >> has fantastic TPM support. > > systemd is very modular. I'm not sure you need much of the rest of > systemd to use the TPM stuff, for example. The value I'd see in systemd > would be all the sandboxing stuff for services. It's annoying because > none of that has to be part of a single unified service manager either = =E2=80=94 > it could largely easily be done by modular chainloaders =E2=80=94 but giv= en > nobody is implementing it outside of systemd there might not be a > reasonable other choice. So I'm not really opposed to this either, and > I guess it probably means we need udev on the host anyway. I don't know > when I'd be able to prioritise making the switch, though=E2=80=A6 Although at that point we're introducing lots of sockets and global buses and things that we've so far been very keen to avoid on the host. I'm really not sure all that additional surface is actually a good tradeoff compared to doing what defense in depth sandboxing measures we can easily do ourselves. The set of software that has to run on the code is very tightly constrained, so it's a very different situation to what we'd find in VMs, where we need to be compatible with arbitrary stuff=E2=80=A6 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRV/neXydHjZma5XLJbRZGEIw/wogUCaHoftQAKCRBbRZGEIw/w opPjAP9r7aLUcQrvQSQ4fKrqdaZ0XOP8Sqh8zZ8uZRCgJK4f8AD/TB5M6xD6eeBz arOF0OK+0177kLEmsUoU/FXYM1tVHw8= =g2kT -----END PGP SIGNATURE----- --=-=-=--