Skip to main content
Topic: Why is Artix using eudev? (Read 734 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Why is Artix using eudev?

Hi all, I'm just wondering why is Artix using eudev (which is also lacking behind udev) instead of something like skarnet's mdevd or suckless's nldev/smdev (with mdev-like-a-boss) combined with KISS's libudev-zero or the BSD's libudevd-devd/libudev-fbsd?

Is it not possible? I've heard KISS managed to get a working Xorg/Wayland setup with libudev-zero, shouldn't this also be possible on Artix?

Re: Why is Artix using eudev?

Reply #1
In general, Artix tries to be as Arch-compatible as possible, only removing systemd.
I've managed run Artix with nldev+smdev for a long time (you can search -noudev packages in AUR which i've created for it, i've also created a topic "Udev alternatives in Artix"). It is possible but there are some drawbacks:
1) kbd xorg driver is used. It worked fine for me on x86_64 machine but on arm64 only basic keys worked on my keyboard with it (even arrow keys didn't work). I've forced evdev driver for keyboard in xorg.conf but this breaks hotplug capabilities
2) recently i've found that scanner doesn't work w/o udev
However, i've used nldev with stock libudev, maybe other implementations can solve issues.
At some point i've tried to create some tool to send libudev messages but this wasn't enough
ARMtix

Re: Why is Artix using eudev?

Reply #2
That's nice, did you document your journey, or is it just a bunch of scattered posts?

Also I think if you've gone with mdevd (with mdev-like-a-boss) and libudev-zero you would've gotten xorg, wayland and libinput to work.

Re: Why is Artix using eudev?

Reply #3
That's nice, did you document your journey, or is it just a bunch of scattered posts?
The main aspects are reflected there. In general, nldev, smdev (reconfigured) and init scripts (openrc/runit) are also on AUR. I've rebuilt xorg to make it work but this didn't work for wayland. Maybe i'll return to it in future and check if libudev-zero solves the problems
ARMtix

Re: Why is Artix using eudev?

Reply #4
There is also a xudev alternative in the repos, which is extracted from systemd source, ie its systemd's udev standalone.

Re: Why is Artix using eudev?

Reply #5
The main aspects are reflected there. In general, nldev, smdev (reconfigured) and init scripts (openrc/runit) are also on AUR. I've rebuilt xorg to make it work but this didn't work for wayland. Maybe i'll return to it in future and check if libudev-zero solves the problems
Maybe with mdevd (+ mdev-like-a-boss), s6 and libudev-zero, it'll finally be possible to come up with a working alternative.

There is also a xudev alternative in the repos, which is extracted from systemd source, ie its systemd's udev standalone.
How is xudev any different from eudev?

Re: Why is Artix using eudev?

Reply #6
Maybe with mdevd (+ mdev-like-a-boss), s6 and libudev-zero, it'll finally be possible to come up with a working alternative.
I've tried to read (lib)udev sources to get the idea about what's wrong. To me it seems that in order to make udev alternative work one has to provide libudev events and udev database to libudev clients. So, i think correct libudev (and maybe some triggered script) should do a trick and then it will be possible to do with any alternative
ARMtix

Re: Why is Artix using eudev?

Reply #7
I've tried to read (lib)udev sources to get the idea about what's wrong. To me it seems that in order to make udev alternative work one has to provide libudev events and udev database to libudev clients. So, i think correct libudev (and maybe some triggered script) should do a trick and then it will be possible to do with any alternative
Exactly, and libudev-zero should fill that gap nicely and could finally enable us to use other alternatives, but I've yet to see anyone test it thoroughly other than KISS (and it's working fine for them).

Maybe you could try experimenting with libudev-zero, mdevd/nldev/nlmon/nltrigger/smdev, and s6?



Re: Why is Artix using eudev?

Reply #10
It would've been easier to say that they're two different things...

If I understood correctly, then xudev is closer to upstream (or is the upstream udev) compared to eudev which is lagging behind.

Re: Why is Artix using eudev?

Reply #11
systemd has udev in its source tree. You can actually build udev by itself without any systemd. That's what xudev is. eudev is the gentoo fork.

Re: Why is Artix using eudev?

Reply #12
systemd has udev in its source tree. You can actually build udev by itself without any systemd. That's what xudev is. eudev is the gentoo fork.
Why is artix using eudev then and not xudev?

Re: Why is Artix using eudev?

Reply #13
Why is artix using eudev then and not xudev?
Because when we started it wasn't possible to separate udev from systemd: it wouldn't run without being PID1. And I bet it still wouldn't be possible if not for the existence of eudev.

Now, since eudev is a Gentoo project, which is reliable (and because we don't exactly trust the systemd developers), eudev stays until further notice (i.e. Gentoo deprecates it). People in want of xudev can compile it themselves.

Re: Why is Artix using eudev?

Reply #14
Because when we started it wasn't possible to separate udev from systemd: it wouldn't run without being PID1. And I bet it still wouldn't be possible if not for the existence of eudev.

Now, since eudev is a Gentoo project, which is reliable (and because we don't exactly trust the systemd developers), eudev stays until further notice (i.e. Gentoo deprecates it). People in want of xudev can compile it themselves.
we provide xudev... is in our repo and I use xudev on m computer.