The only fragment in xf86-input-evdev that requires libudev is (from src/evdev.c, with some changes in whitespaces):
Is it really the only place in Xorg that depends on libudev? I'd think it would be much, much more entangled with libudev than this. Because if it's that single piece of code, it's indeed very easy to replace... at least from a technical standpoint. From a political standpoint, it's a wholly different matter. The problem is that "people" - I don't know exactly who, but kernel folks seem to be in on this - have decided that applications should never access sysfs directly, and instead they should contact an "intermediary layer" that is the only one allowed to interact with sysfs. In theory that makes sense, and the reason why kernel folks are behind it is it allows them to more or less break sysfs at will. Linus has said, multiple times, that sysfs wasn't supposed to be a stable interface, so applications should just not access sysfs. The problem is that it basically requires the intermediary layer to fully duplicate the sysfs data in userspace, and provide users with a way to access the cached data. That is exactly what udevd and libudev do, and from a software design point, it's a terrible idea: - it duplicates data, and duplication leads to inconsistencies - it introduces a SPOF in the form of udevd - it politically enforces libudev as the de facto standard that everyone needs to use, whether you like it or not (this is the vendor lock-in I'm talking about) - the presence of a wrapper layer generally introduces more bloat than it solves problems; sysfs has not changed interfaces to the point of breaking stuff in 12 years and counting - ... So, yeah. If you want a patch for xf86-input-evdev that will make it stop depend on libudev, I can write one in an hour. But that patch will likely never go upstream, because it goes against policy; and complying with the policy would basically amount to rewriting libudev and making a new udevd. Which I believe I'm quite able to do, and better than the existing ones, but it would still be bad software design, and I have no interest in contributing to the problem. -- Laurent