On Mon, Feb 23, 2009 at 3:53 PM, Rafael J. Wysocki [off-list ref] wrote:

On Tuesday 24 February 2009, Arve Hjønnevåg wrote:

quoted

On Sat, Feb 21, 2009 at 12:20 PM, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Saturday 21 February 2009, Arve Hjønnevåg wrote:

quoted

On Sat, Feb 21, 2009 at 1:47 AM, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Saturday 21 February 2009, Arve Hjønnevåg wrote:

quoted

On Fri, Feb 20, 2009 at 3:57 PM, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Saturday 21 February 2009, Arve Hjønnevåg wrote:

quoted

On Fri, Feb 20, 2009 at 7:56 AM, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Friday 20 February 2009, Arve Hjønnevåg wrote:

quoted

On Fri, Feb 20, 2009 at 2:49 AM, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Friday 20 February 2009, Arve Hjønnevåg wrote:

quoted

On Thu, Feb 19, 2009 at 2:08 PM, Alan Stern [off-list ref] wrote:

[--snip--]

quoted

quoted

quoted

quoted

The idea is to have both /sys/power/state and /sys/power/sleep at the same
time, where /sys/power/state will work just like it does right now.  Sure,
there must be mutual exclusion between the two, but that's a matter of
implementation IMO.

If you want to only prevent suspend though one interface, you have to
also pass information to the driver about its suspend hook is being
called so it can conditionally return -EBUSY. The wakelock interface
requires less code in each driver.

Well, I don't think so.  Moreover, it requires you to spread wakelocks all
over the place if you don't use the timeouted ones which, let's face it, is
hardly acceptable.

Your method does not reduce the number of places that has to be
modified. Any component where we add a wakelock, you have to add a
suspend handler to abort suspend when we would have held a wakelock.

Well, maybe not, but it doesn't introduce entirely new API for device drivers.
Instead, it extends the existing interfaces which I think is more appropriate.

The existing interfaces require polling. I don't think extending these
interfaces to make the polling faster is a better solution than adding
an interface to avoid polling.

Also, with your solution, how would you modify evdev.c to prevent
suspend while the event queue is not empty. This code does not have
any suspend hooks and the queue is not tied to any thread.

Well, why do you need to modify evdev.c in the first place?

It is the only code that knows that there are unprocessed input events.

-- 
Arve Hjønnevåg