Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751859AbbEGREN (ORCPT ); Thu, 7 May 2015 13:04:13 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:44739 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751023AbbEGREL (ORCPT ); Thu, 7 May 2015 13:04:11 -0400 Date: Thu, 7 May 2015 18:03:36 +0100 From: One Thousand Gnomes To: Chirantan Ekbote Cc: Alan Stern , "Rafael J. Wysocki" , John Stultz , Olof Johansson , Bastien Nocera , Linux Kernel Mailing List , snanda@chromium.org, Tomeu Vizoso , Linux PM list Subject: Re: A desktop environment[1] kernel wishlist Message-ID: <20150507180336.77b44005@lxorguk.ukuu.org.uk> In-Reply-To: References: Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1462 Lines: 33 > You are, of course, correct. Ultimately the only requirement we have > is that there exists a way for userspace to determine if the system > woke up because of a user-triggered event. The actual mechanism by No. That is irrelevant. You need a way to ascertain if a user triggered event has occurred since you suspended. The two are not the same thing. If your box wakes up due to something like a wireless card deciding it needs to poke the base station and the user hits a key a microsecond after wakeup then you want the display on. The question is never "did the user wake the machine" the question is "did the user do something that takes me out of 'lucid sleep/snooze/whatever' since I suspended". Every user event could equally occur a microsecond after a wakeup from a non user source, so every time you must ask the "since suspend" question. In fact if you had some kind of hypoethetical event counter incremented by the device on it causing a wakeup event *or* an event while active (and no way to tell them apat) that would provide a correct race free interface to figure out if the display ought to be on It doesn't solve the powering off as a key is hit race but that's a different beast. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/