No subject

Thu Jun 25 05:52:11 EDT 2020

in the past few weeks, I think I can tell you what's happening here.
One (there are more) of the problems is that gpio-keys module gets loaded
even before the procd enters its "preinit" phase (the module is part of 
/etc/modules-boot.d/30-gpio-button-hotplug). And the bad news is that
even once procd hits the preinit phase, it intentionally forwards everything
to the failsafe button events script:

|	[ "if",
|		[ "eq", "SUBSYSTEM", "button" ],
|		[ "exec", "/etc/rc.button/failsafe" ]
|  ]


/etc/rc.button/failsafe itself is also very telling:

|[ "${TYPE}" = "switch" ] || echo ${BUTTON} > /tmp/failsafe_button
|return 0

The long and short of this is that initial switch state event is
generated but it has no change of getting processed properly
at the time the driver is loaded as the system isn't ready.

Note: If it was loaded later when procd is in the "init" phase,
then it works because events are then processed by hotplug.json,
which does:
	[ "if",
		[ "and",
			[ "has", "BUTTON" ],
			[ "eq", "SUBSYSTEM", "button" ]
		[ "button", "/etc/rc.button/%BUTTON%" ]


Then everything would work as you expect.
so, it's not the driver that lets you down here, because it can't
do much about these userspace antics.

(Note: OpenWrt's gpio-button-hotplug.c uses the BUTTON subsystem
event type for both EV_KEY (button) and EV_SW (switches) events.
So don't let this confuse you).


openwrt-devel mailing list
openwrt-devel at

More information about the openwrt-devel mailing list