Hi,
On 30-10-17 21:48, Dmitry Torokhov wrote:
<snip>
So both for consistency and because a timeout is racy I believe
that having the power button not send KEY_POWER after resume is
the proper solution here.
Note that I've made this configurable and that soc_button_array
is the only driver getting this enabled, making the power-button
behavior on PC like devices consistent, without impacting any
other devices.
I'd rather we did not make assumption in the kernel about behavior of
userspace we happen to run on. The "PC like" devices change all the
time, and one could even say that failure to deliver events by ACPI
drivers on resume is a bug.
Please teach userspace how to handle events coming during resume phase
and what to do about them, and be done with it. One option is to say (in
whatever implements your power policy) "we want to ignore next KEY_POWER
event for the next NNN msec". You will need it ianyway if you decide to
put your userspace onto, let's say, ASUS Flip (an ARM device using
gpio-keys for power button and volume up/down buttons on the side of the
case).
Ok, I've written and submitted patches for this for gnome:
https://bugzilla.gnome.org/show_bug.cgi?id=789771
That still leaves the same issue for KDE, XFCE, mate, etc. though,
note I've no intention of fixing those.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
