Make udev optional

[illiliti]

Is it possible to avoid udev dependency by using fixed(not autodetected) configuration for input/output devices ?

---

wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2257

[emersion]

What's your use-case? What are you trying to achieve?

[illiliti]

I'm trying to use mdev[d] as my main device manager. In Xorg is it possible to avoid udev dependecy by using static xorg.conf configuration. Libinput can be also used without udev with this patch https://github.com/kisslinux/repo/blob/master/extra/libinput/patches/libinput-optional-udev.patch

[emersion]

These approaches might be better than static configuration:

1. Write a library that exposes the udev interface but uses mdev under-the-hood
2. Patch wlroots to use mdev instead of udev

[illiliti]

Write a library that exposes the udev interface but uses mdev under-the-hood

There is one - https://github.com/jcnelson/vdev/tree/master/libudev-compat , but it's a bit outdated and doesn't work

Patch wlroots to use mdev instead of udev

mdev[d] does not expose any information about input/output by default. Instead it's relies on /etc/mdev.conf which is depends on user configuration

Would be nice to have static configuration to be independent of device managers at all.

[valpackett]

libudev-devd basically enumerates devices by looking at directories, and only uses devd for hotplug. Should be easy to fork it to not do any hotplug at all and make it work on Linux.

[illiliti]

it wasn't so easy as you said but i did it. i had to reimplement udev api from scratch because libudev-devd depends on bsd specific code. i don't know why wlroots decided to use this over-engineered library, but i can't blame choices. anyway i did it, now it's possible to use wlroots-based compositors with any device manager or without at all! i'm currently working on hotplugging support, so for now you need to restart compositor to hotplug devices. i still hope that wlroots provide ability to disable libudev(i did it through ripping out udev code and using WLR_DRM_DEVICES). also someone reported that mouse doesn't work with libudev-zero but i can't reproduce. suggestions about code, reports about which software works with it, feature requests and bug reports are highly wanted!

https://github.com/illiliti/libudev-zero

[akvadrako]

This is interesting. I run sway in a user namespace (for an unprivileged chroot) and libudev doesn't work in that case because it only allows messages from uid = 0, but real root is mapped to nobody in the namespace. So I patched libudev to allow messages from any uid. This is still secure, but it may not get accepted upstream (see https://github.com/systemd/systemd/pull/16307). So I'm interested in alternatives to libudev.

However, I do want to hotplug monitors. @illiliti Do you know if your libudev-zero would work for me?

If so, would a patch be accepted to sway to build with libudev-zero instead of libsystemd?

[emersion]

If so, would a patch be accepted to sway to build with libudev-zero instead of libsystemd?

Doesn't seem like libudev-zero would require anything from wlroots, it should just work.

[akvadrako]

Ah, I see it just overwrites the libudev libraries. That is not ideal since it'll cause issues when libsystemd is updated, but good enough for now.

[emersion]

I'd like to retract my statement about mandatory udev. I'd personally be open to adding new device enumeration backends to wlroots, but I'd really prefer avoiding a "static" one, because that would leave hotplug unimplemented. For instance, an OpenBSD one which uses hotplug(4) would be nice.

[illiliti]

@emersion Do you know how to programmatically enumerate connected pci/usb devices on OpenBSD? I'm trying to find relevant information how to monitor/enumerate devices on different OS's. Here's what i found:

OS	Monitoring	Enumeration
Linux	NETLINK_KOBJECT_UEVENT netlink(7)	/sys/dev/{block,char} sysfs(5)
NetBSD	DRVGETEVENT drvctl(4)	DRVLISTDEV drvctl(4)
FreeBSD	/var/run/devd.seqpacket.pipe devd(8)	devinfo(3)
OpenBSD	hotplug(4)	?
DragonFlyBSD	devattr(3)	devattr(3)
Illumos	libhotplug	libdevinfo