Bug 10131 - acpid should monitor /sys/class/input for new devices
Summary: acpid should monitor /sys/class/input for new devices
Status: NEW
Alias: None
Product: Busybox
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All Linux
: P5 enhancement
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-26 02:05 UTC by Clayton Craft
Modified: 2020-04-20 23:46 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Clayton Craft 2017-07-26 02:05:27 UTC
Currently, acpid will read in /sys/class/input/eventX devices on startup and will not detect any new ones. This is problematic for two reasons:

1) If a new input device is added and the user wants to manage events from it with acpid, they would have to restart acpid (they may not always have the privileges required for this)

2) I have a device which, for one reason or another, actually starts acpid before the kernel has finished modprobing/enabling input devices, so quite a few buttons/switches events are never handled by acpid unless acpid is restarted.


On the busybox mailing list, it was suggested that using inotify might be one option, since big acpid apparently uses it. I wrote a patch that basically polls for new devices in the existing main loop in acpid, but I haven't been able to test it for completely unrelated-to-busybox reasons.. so I'm refraining from sharing it here unless there is interest.
Comment 1 macmpi 2020-04-20 23:46:29 UTC
That would be very useful indeed, or else it requires udev rule to stop/start service each time an input comes-up: quite circumvoluted !

Also, it turns-out acpid just crashes when input goes away (BusyBox v1.31.1 on Alpine 3.11).
Would your patch address the 2 aspects?

Thanks!