Bug 14941 - acpid: ignores events if input event numbering is not contiguous
Summary: acpid: ignores events if input event numbering is not contiguous
Status: NEW
Alias: None
Product: Busybox
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.35.x
Hardware: All Linux
: P5 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-06 13:19 UTC by macmpi
Modified: 2022-08-18 20:54 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description macmpi 2022-08-06 13:19:50 UTC 
Have noticed a problem with busybox acpid input scan in /dev/input/event*
All is fine as long as event numbering is contiguous, but if there is a "hole" in-between, acpid does not take inputs after the hole.

Exemple below on Alpine 3.16 where fuser shows event0 and event1 are handled, but event3 is ignored (event2 missing), despite restarting acpid.

$ service acpid status
 * status: started

$ ls /dev/input/
event0  event1  event3  mice    mouse0

$ pidof acpid
4530

$ fuser /dev/input/event3

$ fuser /dev/input/event0
4530 

$ fuser /dev/input/event1
4530 

$ service acpid restart
 * Stopping busybox acpid ...                                                                            [ ok ]
 * Starting busybox acpid ...                                                                            [ ok ]
$ fuser /dev/input/event3
$ fuser /dev/input/event0
4613

This is quite annoying in situations where devices may come & go (like bluetooth keyboards, AVRCP,...), and therefore create such holes in event numbering.
Comment 1 macmpi 2022-08-18 20:54:52 UTC 
Looking quickly at code lines 316-320, it seems one while/break may abusively escape monitoring some events in cases where /dev/input/events are not contiguous.
Thoughts?