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 A0986228D; Tue, 29 Jul 2025 07:30:07 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 52EAA2240; Tue, 29 Jul 2025 07:30:04 +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-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) by atuin.qyliss.net (Postfix) with ESMTPS id 176D0223E for ; Tue, 29 Jul 2025 07:30:03 +0000 (UTC) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id 4FB36EC024A; Tue, 29 Jul 2025 03:30:01 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Tue, 29 Jul 2025 03:30:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=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=fm2; t=1753774201; x=1753860601; bh=doXHEjdg2v JxCQxLYO7VN7p8nbP5OrVdRivpKzZ/Lts=; b=p2waiot3PneL6D6oTbL9BHtHcA uS91OeOyAMcKCiKmondRN/1/dFcfdED9aZdJ2xtmoq3CkRyW17CW/mWF5Pt6rbbG qLG20YmyjeaFFYEaCV4N9m5ttWzZY88mxzI4ryyyBK9GV7jhv0AVoyn4a2luRFAu D15CBvi/qSB61CaUwKirr1AkCvtHdGmiqgqM7v/LzczoNJ7niLZEBff50IET9nn3 IJEFIAphsu7S0kx4NtuGevjNSGkG+ctZOk09UUoRAYGUuNvTEFWikIGEVTQvRdV5 HhFxgMMmu+CTyJxS+bYCkj0R+thdWOtcLpo0UhzucraGDPK5pN5auVPqRO6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; t= 1753774201; x=1753860601; bh=doXHEjdg2vJxCQxLYO7VN7p8nbP5OrVdRiv pKzZ/Lts=; b=BR+DZ7SFh79iD4uSh2zIhB5lhlxwF3AnxgklW/pED12/NnmfEOv FyQMlIfdCz/wN2u8wHmtL08lPKvlUSfE6kuqZjg+VLfbvRZvR8q9AeHrT0B/0k4l 5veDBZKAEtu1lP7WWbOWaI9XB7uvFfcV8hFZcC9lAkL8JFdjYtMba4zQqENrjGtX w1xWt7Drz6YllTzzRsEHitl/7WZfWR4j2OmM+m8LRcqeFA4SxKL1csmsDZx3D1Zh TwEDLrN6bxJrcuPOVpFSG2jMpVKCXU7fBHRiDFRMUsHUMEN5sHIOHohO+Vyayhss /djYD/QKPfFWRg5Y7uNmeY+MNl5/c0/wEBQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdelgeegiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvffujghffffkgggtsehgtderredttdejnecuhfhrohhmpeetlhihshhsrgcutfho shhsuceohhhisegrlhihshhsrgdrihhsqeenucggtffrrghtthgvrhhnpefgtdefteehie ehvdefkeekkeejfeetveegtdefheffhfefveehffduueefueelheenucffohhmrghinhep ghgvnhhtohhordhorhhgpdhfrhgvvgguvghskhhtohhprdhorhhgpdhfrhgvvggsshgurd horhhgpdhgihhthhhusgdrtghomhdptghrhihpthhprggurdhfrhenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehhihesrghlhihsshgrrdhish dpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepuggv mhhiohgsvghnohhurhesghhmrghilhdrtghomhdprhgtphhtthhopeguvghvvghlsehsph gvtghtrhhumhdqohhsrdhorhhg X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 29 Jul 2025 03:30:00 -0400 (EDT) Received: by sf.qyliss.net (Postfix, from userid 1000) id 5B5472D8F1BD6; Tue, 29 Jul 2025 09:29:47 +0200 (CEST) From: Alyssa Ross To: Demi Marie Obenour , Spectrum OS Development Subject: Re: Switching to udev? In-Reply-To: References: <2f8aaac8-0407-41f8-86c1-caa5f8b2543e@gmail.com> <87pldnfeq8.fsf@alyssa.is> Date: Tue, 29 Jul 2025 09:29:39 +0200 Message-ID: <87ikjbe9p8.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: VM6ZVHTYHCVYN5VIWOKOJPHVU5WCQ4SA X-Message-ID-Hash: VM6ZVHTYHCVYN5VIWOKOJPHVU5WCQ4SA 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 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 Demi Marie Obenour writes: > On 7/26/25 06:06, Alyssa Ross wrote: >> Demi Marie Obenour writes: >>=20 >>> On 7/23/25 13:34, Demi Marie Obenour wrote: >>> From https://wiki.gentoo.org/wiki/Mdev: >>> >>> - udev is needed to load firmware for AMD Radeon GPUs. >>> - libusb will not see USB devices unless deprecated kernel >>> configuration options are set. >>> >>> From https://wayland.freedesktop.org/libinput/doc/latest/architecture.h= tml: >>> >>> - Wayland compositors use udev (via libinput) to support >>> device hotplugging. This is needed for USB keyboard >>> and/or mouse support, which is a hard requirement for >>> desktops that don't have PS/2 connectors (almost all of >>> them I believe). >>> - libinput relies on udev to determine what kind of device >>> an input device is. >>> >>> FreeBSD also switched to udev for Mutter. >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271824#c4 >>> states that for Wayland, udev is essentially required. Even >>> Gentoo uses udev, though systemd is not the default init >>> system. >>> >>> I think avoiding udev is a losing battle in the long run, >>> except possibly for VMs that will never ever have physical >>> hardware attached to them. That would require configuring >>> VMs with and without physical hardware separately, which >>> I would strongly prefer to avoid. If the memory >>> consumption or disk space requirements of udev are >>> excessive, I think this would be better addressed as part >>> of a broader debloating effort. >>> >>> libudev-zero does exist, but it doesn't work with PipeWire >>> (https://github.com/illiliti/libudev-zero/issues/26, still >>> unfixed despite being closed) and there are other problems >>> with it as shown by its issue tracker. Alpine's wiki doesn't >>> recommend it for desktop environments, and while Spectrum VMs >>> don't run full desktop environments they do run desktop >>> software. Such software requires udev more and more nowadays. >>=20 >> Broadly it seems like no libudev at all (which was never on the table) >> is being conflated with not using udevd (but using something like >> libudev-zero) here. To my knowledge, everything you've outlined should >> work with libudev-zero, with the exception of PipeWire as you point out, >> and possibly Radeon firmware loading =E2=80=94 I'm very surprised udev w= ould be >> involved at all in that process so wondering if the wiki is very out of >> date or something. We have USB input working on the host using >> libudev-zero, for example. >>=20 >> The PipeWire compatibility problems do seem like blockers, but reading >> the PipeWire issue about it[1], I'm not sure they're fundamental. It >> sounds like PipeWire might be willing to accomodate a fix, the last >> activity on the issue was only a month ago, and it doesn't sound like >> that big of a change is necessary for it to work. I wouldn't be >> surprised if PipeWire is among the software that has the most complex >> interaction patterns with udev, and given it might be on the verge of >> being fixed, I'd prefer to wait and see a bit longer. If that means >> that we don't have working audio hotplug or whatever in the meantime, >> that's okay. I've put the PipeWire issue on the upstream bug tracking >> board[2]. If months go by and no solution is found, I think it would >> make sense to evaluate switching to systemd-udevd then, but I don't want >> to do the switch, and then find a weak later that the only firm reason >> we had for doing it has been solved. If you know about other software >> that depends on custom udev properties, and isn't on the verge of being >> fixed like PipeWire is, or if I'm wrong about Radeon, we could also take >> that into account now, but so far all we know for sure is that PipeWire >> doesn't work, but might do quite soon. >>=20 >> [1]: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2398#note= _2897989 >> [2]: https://cryptpad.fr/kanban/#/2/kanban/view/yLtGXWLV6U7X5+Z1ay+oXKZM= rSacqQe+51nXZYRh3ck/ > > I think libudev-zero can work fine in the VMs that have no physical > hardware, especially with flatpaks that can't access udev at all. > It's the host and VMs with physical hardware we don't have, and thus > cannot test, that I am concerned about. systemd-udevd is much more > likely to have gotten a patch from someone else to fix an issue we > would never run into ourselves, and which might well cost us a user. Does udev upstream quirk a lot of hardware, then? That wasn't mentioned so far. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRV/neXydHjZma5XLJbRZGEIw/wogUCaIh4YwAKCRBbRZGEIw/w ouI2AQCO7o0Lo7SpomqO2b63N/vYCJvuIZzA01Br7W3IXyAKDAEAg4RPnR/780l5 7bJq7rl5u0Ixl6wxDulLfq9tSA7/zgE= =i8dv -----END PGP SIGNATURE----- --=-=-=--