Am Dienstag, 11. Oktober 2011, 13:04:21 schrieb Henrik Rydberg: > On Tue, Oct 11, 2011 at 06:10:12AM +0200, Oliver Neukum wrote: > > Am Dienstag, 11. Oktober 2011, 02:11:03 schrieb Matthew Garrett: > > > > > Ah, right, sorry - I wasn't trying to use the device after it had been > > > closed. In an ideal world we'd really want to be able to indicate that > > > we don't want a remote wakeup in that situation. Otherwise, the patch > > > looks good. Thank you! > > > > It looks like we had exactly that capability until > > 48826626263d4a61d06fd8c5805da31f925aefa0 > > removed it. > > Hm. Throwing in another related question below. > > Problem: the hid keyboard driver refuses to suspend while a key is > pressed, which is fine per se, but there is no indication presented to the power layer, > resulting in a failed suspend and (due to complex reasons it seems) disabled autosuspend. That is a bug. Autosuspend at a later date should happen. > Question: If the hid interrupt handler were to actually prevent > suspend during keypress, what would be the natural way to do it? Firstly we must prevent autosuspension when a key is pressed because most keyboards do not generate a wakeup upon key release which is then lost. Secondly a key pres triggers the mark_busy. We could do an async get on every key press and an async put on every key release. But you cannot beat the principal race here because the operation happen in interrupt and must therefore be async. You must be prepared for the window to be hit and return an error code. Regards Oliver -- 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
