Bug 14941

Summary:	acpid: ignores events if input event numbering is not contiguous
Product:	Busybox	Reporter:	macmpi <spam>
Component:	Other	Assignee:	unassigned
Status:	NEW ---
Severity:	normal	CC:	busybox-cvs, vda.linux
Priority:	P5
Version:	1.35.x
Target Milestone:	---
Hardware:	All
OS:	Linux
Host:		Target:
Build:

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?