On Nov 01 2017 or thereabouts, Hans de Goede wrote: > 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. > Hi Hans, I roughly had a look at the series, and I am wondering, can't we at least take the cleanup patches (1/4 2/4 as far as i can tell)? Cheers, Benjamin > 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
