Comment by jcelerier
9 days ago
> there is no tangible or important dependency on the use of systemd as init for those functions.
How do you catch device events on very early startup (e.g., between start of pid1 and when processes start to fire?) if the thing that manages the devices isn't integrated with pid1 at a deep level?
logind does not "manage devices", it just provides an API for your display server to open privileged I/O devices and get a file descriptor, and have these file descriptors revoked later.
The difference with a plain `open` is that logind will allow only one process at a time to have access, and only for sessions that logged in physically (tracked using PAM), and does not require the process to have direct file access (which could enable key-logging). It will also revoke the file descriptors when switching sessions.
logind's other random features like dock and power button triggers can be done whenever logind is running and ready - the underlying API reports levels and are not timing critical.
The only thing logind really uses at runtime from systemd is temporary storage of file descriptors that it can get back after restart for graceful upgrades.
Projects like elogind and eudev exists that painstakingly strip out the systemd portions while retaining the functionality, but it's an uphill battle to constantly redo every time there's a change.