On Fri, Jul 18, 2014 at 04:16:50PM -0700, Dmitry Torokhov wrote:
> [...]
> Anyway, even though it is very tempting to declare inhibit a "deeper" state
> of
> runtime suspend maybe you are right and inhibit should really be separate
> from
> PM and drivers would have to sort out all the
(Note: Your email arrived here with lines wrapped in a hard-to-read way,
not sure where the problem lies.)
On Tue, Jul 22, 2014 at 01:23:14AM +0200, had...@hadess.net wrote:
> On 2014-07-19 01:16, Dmitry Torokhov wrote:
>
> >I'd say no.
> >
> >Anyway, even though it is very tempting to declare
(Note: Your email arrived here with lines wrapped in a hard-to-read way,
not sure where the problem lies.)
On Tue, Jul 22, 2014 at 01:23:14AM +0200, had...@hadess.net wrote:
On 2014-07-19 01:16, Dmitry Torokhov wrote:
snip
I'd say no.
Anyway, even though it is very tempting to declare
On Fri, Jul 18, 2014 at 04:16:50PM -0700, Dmitry Torokhov wrote:
[...]
Anyway, even though it is very tempting to declare inhibit a deeper state
of
runtime suspend maybe you are right and inhibit should really be separate
from
PM and drivers would have to sort out all the possible state
On 2014-07-19 01:16, Dmitry Torokhov wrote:
I'd say no.
Anyway, even though it is very tempting to declare inhibit a "deeper"
state of
runtime suspend maybe you are right and inhibit should really be
separate from
PM and drivers would have to sort out all the possible state
permutations.
On 2014-07-19 01:16, Dmitry Torokhov wrote:
snip
I'd say no.
Anyway, even though it is very tempting to declare inhibit a deeper
state of
runtime suspend maybe you are right and inhibit should really be
separate from
PM and drivers would have to sort out all the possible state
permutations.
On Saturday, July 19, 2014 11:21:52 AM Dmitry Torokhov wrote:
> On Saturday, July 19, 2014 01:59:01 PM Alan Stern wrote:
> > On Sat, 19 Jul 2014, Benson Leung wrote:
> > > > This raises an interesting question. Suppose the system gets suspended
> > > > while the lid is closed. At that point,
On Saturday, July 19, 2014 01:59:01 PM Alan Stern wrote:
> On Sat, 19 Jul 2014, Benson Leung wrote:
> > > This raises an interesting question. Suppose the system gets suspended
> > > while the lid is closed. At that point, shouldn't wakeup devices be
> > > enabled, even if they were already
On Sat, 19 Jul 2014, Benson Leung wrote:
> > This raises an interesting question. Suppose the system gets suspended
> > while the lid is closed. At that point, shouldn't wakeup devices be
> > enabled, even if they were already inhibited?
>
> It's possible that this could be a policy decision,
On Sat, Jul 19, 2014 at 7:51 AM, Alan Stern wrote:
> On Fri, 18 Jul 2014, Dmitry Torokhov wrote:
>
>> > The area where it must interact with power management is wakeup, both
>> > remote
>> > wakeup at run time and wakeup from system suspend. In particular, there's
>> > the question whether or
On Fri, 18 Jul 2014, Dmitry Torokhov wrote:
> > The area where it must interact with power management is wakeup, both remote
> > wakeup at run time and wakeup from system suspend. In particular, there's
> > the question whether or not a device ignoring its input should be regarded
> > as a
On Fri, 18 Jul 2014, Dmitry Torokhov wrote:
The area where it must interact with power management is wakeup, both remote
wakeup at run time and wakeup from system suspend. In particular, there's
the question whether or not a device ignoring its input should be regarded
as a wakeup
On Sat, Jul 19, 2014 at 7:51 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 18 Jul 2014, Dmitry Torokhov wrote:
The area where it must interact with power management is wakeup, both
remote
wakeup at run time and wakeup from system suspend. In particular, there's
the question
On Sat, 19 Jul 2014, Benson Leung wrote:
This raises an interesting question. Suppose the system gets suspended
while the lid is closed. At that point, shouldn't wakeup devices be
enabled, even if they were already inhibited?
It's possible that this could be a policy decision, ie,
On Saturday, July 19, 2014 01:59:01 PM Alan Stern wrote:
On Sat, 19 Jul 2014, Benson Leung wrote:
This raises an interesting question. Suppose the system gets suspended
while the lid is closed. At that point, shouldn't wakeup devices be
enabled, even if they were already inhibited?
On Saturday, July 19, 2014 11:21:52 AM Dmitry Torokhov wrote:
On Saturday, July 19, 2014 01:59:01 PM Alan Stern wrote:
On Sat, 19 Jul 2014, Benson Leung wrote:
This raises an interesting question. Suppose the system gets suspended
while the lid is closed. At that point, shouldn't
On Friday, July 18, 2014 04:16:50 PM Dmitry Torokhov wrote:
> On Saturday, July 19, 2014 12:55:09 AM Rafael J. Wysocki wrote:
> > On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote:
> > > On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
> > > > On Friday, July 18, 2014
On Saturday, July 19, 2014 12:55:09 AM Rafael J. Wysocki wrote:
> On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote:
> > On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
> > > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> > > > On Friday, July 18, 2014
On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote:
> On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
> > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> > > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> > > > On Friday, July 18, 2014
On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
> On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > > > On Fri, 18 Jul 2014, Patrik Fimml wrote:
On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > > On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
> > > I'm not sure what the appropriate action for a video
On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > > "Quiescing" is the wrong word. "Quiescing a device" means stopping the
> > > device from doing anything, which isn't what you
On Fri, 18 Jul 2014, Patrik Fimml wrote:
> On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > "Quiescing" is the wrong word. "Quiescing a device" means stopping the
> > device from doing anything, which isn't what you want. You want to
> > ignore any activity the device may
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> "Quiescing" is the wrong word. "Quiescing a device" means stopping the
> device from doing anything, which isn't what you want. You want to
> ignore any activity the device may generate and reduce the device's
> power consumption as
On Fri, 18 Jul 2014, Patrik Fimml wrote:
> 2. Give userspace a way of quiescing a device. Handles to the device
> stay open, but the device will no longer perform its function and,
> if possible, power down.
"Quiescing" is the wrong word. "Quiescing a device" means stopping the
device
On Fri, Jul 18, 2014 at 02:43:02AM +0200, Rafael J. Wysocki wrote:
> From past discussions on similar topics it followed that there really was
> no generic way for individual drivers to quiesce devices on demand as long as
> user space was running. Everything we could come up with was racy, this
On Fri, 18 Jul 2014, Rafael J. Wysocki wrote:
> > > the problem really seems to be that drivers are not
> > > aggressive enough with starting PM transitions (using runtime PM) when
> > > they
> > > see no activity. Thus it seems that when the lid is closed, it'll be good
> > > to switch the
On Fri, Jul 18, 2014 at 02:43:02AM +0200, Rafael J. Wysocki wrote:
From past discussions on similar topics it followed that there really was
no generic way for individual drivers to quiesce devices on demand as long as
user space was running. Everything we could come up with was racy, this way
On Fri, 18 Jul 2014, Patrik Fimml wrote:
2. Give userspace a way of quiescing a device. Handles to the device
stay open, but the device will no longer perform its function and,
if possible, power down.
Quiescing is the wrong word. Quiescing a device means stopping the
device from
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
Quiescing is the wrong word. Quiescing a device means stopping the
device from doing anything, which isn't what you want. You want to
ignore any activity the device may generate and reduce the device's
power consumption as much as
On Fri, 18 Jul 2014, Patrik Fimml wrote:
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
Quiescing is the wrong word. Quiescing a device means stopping the
device from doing anything, which isn't what you want. You want to
ignore any activity the device may generate and
On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
On Fri, 18 Jul 2014, Patrik Fimml wrote:
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
Quiescing is the wrong word. Quiescing a device means stopping the
device from doing anything, which isn't what you want. You want
On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
On Fri, 18 Jul 2014, Patrik Fimml wrote:
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
I'm not sure what the appropriate action for a video camera is
On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
On Fri, 18 Jul 2014, Patrik Fimml wrote:
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
On Fri, 18 Jul 2014, Patrik Fimml wrote:
On
On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote:
On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
On Friday, July 18, 2014 04:09:46 PM Alan
On Saturday, July 19, 2014 12:55:09 AM Rafael J. Wysocki wrote:
On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote:
On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
On Friday, July 18, 2014 02:26:21 PM
On Friday, July 18, 2014 04:16:50 PM Dmitry Torokhov wrote:
On Saturday, July 19, 2014 12:55:09 AM Rafael J. Wysocki wrote:
On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote:
On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
On Friday, July 18, 2014 11:59:18 PM
On Fri, 18 Jul 2014, Rafael J. Wysocki wrote:
the problem really seems to be that drivers are not
aggressive enough with starting PM transitions (using runtime PM) when
they
see no activity. Thus it seems that when the lid is closed, it'll be good
to switch the drivers into a
On Friday, July 18, 2014 03:30:31 AM Rafael J. Wysocki wrote:
> On Thursday, July 17, 2014 05:43:42 PM Dmitry Torokhov wrote:
> > On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:
> > > On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
> > > > On Thursday, July 17, 2014
On Thursday, July 17, 2014 05:43:42 PM Dmitry Torokhov wrote:
> On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:
> > On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
> > > On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
> > > > On Wed, 16 Jul 2014, Dmitry
On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:
> On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
> > On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
> > > On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > > > We are not planning on implementing the policy in
On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
> On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
> > On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > > We are not planning on implementing the policy in kernel, that's
> > > indeed task for userspace; but unless we bring in
On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
> On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > We are not planning on implementing the policy in kernel, that's
> > indeed task for userspace; but unless we bring in the heavy hammer of
> > forcibly unbinding drivers, we do not currently
On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> We are not planning on implementing the policy in kernel, that's
> indeed task for userspace; but unless we bring in the heavy hammer of
> forcibly unbinding drivers, we do not currently have universal
> mechanism of quiescing devices.
We sort of do:
On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
> On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
> > Applications can already check the lid status (through UPower), and with
> > the additional metadata from the kernel, know that the webcam won't be
> > usable when the
On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
Applications can already check the lid status (through UPower), and with
the additional metadata from the kernel, know that the webcam won't be
usable when the lid is
On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
We are not planning on implementing the policy in kernel, that's
indeed task for userspace; but unless we bring in the heavy hammer of
forcibly unbinding drivers, we do not currently have universal
mechanism of quiescing devices.
We sort of do: the
On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
We are not planning on implementing the policy in kernel, that's
indeed task for userspace; but unless we bring in the heavy hammer of
forcibly unbinding drivers, we do not currently have
On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
We are not planning on implementing the policy in kernel, that's
indeed task for userspace; but unless we bring in the heavy
On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:
On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
We are not planning on implementing the policy in kernel,
On Thursday, July 17, 2014 05:43:42 PM Dmitry Torokhov wrote:
On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:
On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
On Friday, July 18, 2014 03:30:31 AM Rafael J. Wysocki wrote:
On Thursday, July 17, 2014 05:43:42 PM Dmitry Torokhov wrote:
On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:
On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
On Thursday, July 17, 2014 10:39:16 AM
On Wed, Jul 16, 2014 at 4:23 PM, Bastien Nocera wrote:
> On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
>> On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
>> > On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
>> > > On Tuesday, July 15, 2014 06:32:06 PM Patrik
On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
> On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
> > On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
> > > > (Re-sending with correct mailing list
On Thu, Jul 17, 2014 at 01:11:31AM +0200, Rafael J. Wysocki wrote:
> Let me try to understand the scenario in the first place.
>
> To start with, a number of devices is in use (that is, open, there are
> applications listening/talking to them etc). Now, an event happens, such
> as a laptop lid
On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
> On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
> > On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
> > > (Re-sending with correct mailing list addresses.)
> > >
> > > Hi,
> > >
> > > When the lid of a laptop is
On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
> > (Re-sending with correct mailing list addresses.)
> >
> > Hi,
> >
> > When the lid of a laptop is closed, certain devices can no longer
> > provide interesting input or
On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
> (Re-sending with correct mailing list addresses.)
>
> Hi,
>
> When the lid of a laptop is closed, certain devices can no longer
> provide interesting input or will even produce bogus input, such as:
>
> - input devices: touchscreen,
On Wed, 2014-07-16 at 14:08 -0400, Alan Stern wrote:
> > I am not so much concerned about userspace, but about reusing of as
> > much of existing PM framework in the drivers. Right now it is very
> > hard to correctly track dependencies between general open/close,
> > system suspend/resume, and
On Wed, Jul 16, 2014 at 11:08 AM, Alan Stern wrote:
>> I am not so much concerned about userspace, but about reusing of as
>> much of existing PM framework in the drivers. Right now it is very
>> hard to correctly track dependencies between general open/close,
>> system suspend/resume, and
On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > The general design of Linux's runtime PM is that the PM core tells
> > drivers when their devices are no longer being used, and it's up to the
> > driver to select an appropriate low-power state. That philosophy
> > doesn't fit well with the
On Wed, Jul 16, 2014 at 7:17 AM, Alan Stern wrote:
>> Various workarounds cover some of these cases, and we have some ugly
>> hacks in ChromeOS to make things work. It would be nice if a userspace
>> power management daemon could listen to the lid-close event, and then
>> have a way to
Hi Alan,
On Wed, Jul 16, 2014 at 7:17 AM, Alan Stern wrote:
> On Tue, 15 Jul 2014, Patrik Fimml wrote:
>
>> (Re-sending with correct mailing list addresses.)
>>
>> Hi,
>>
>> When the lid of a laptop is closed, certain devices can no longer
>> provide interesting input or will even produce bogus
On Tue, 15 Jul 2014, Patrik Fimml wrote:
> (Re-sending with correct mailing list addresses.)
>
> Hi,
>
> When the lid of a laptop is closed, certain devices can no longer
> provide interesting input or will even produce bogus input, such as:
>
> - input devices: touchscreen, touchpad, keyboard
On Tue, 2014-07-15 at 18:32 -0700, Patrik Fimml wrote:
> (Re-sending with correct mailing list addresses.)
>
> Hi,
>
> When the lid of a laptop is closed, certain devices can no longer
> provide interesting input or will even produce bogus input, such as:
> It's somewhat difficult to get the
On Tue, 2014-07-15 at 18:32 -0700, Patrik Fimml wrote:
(Re-sending with correct mailing list addresses.)
Hi,
When the lid of a laptop is closed, certain devices can no longer
provide interesting input or will even produce bogus input, such as:
snip
It's somewhat difficult to get the
On Tue, 15 Jul 2014, Patrik Fimml wrote:
(Re-sending with correct mailing list addresses.)
Hi,
When the lid of a laptop is closed, certain devices can no longer
provide interesting input or will even produce bogus input, such as:
- input devices: touchscreen, touchpad, keyboard
Just
Hi Alan,
On Wed, Jul 16, 2014 at 7:17 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 15 Jul 2014, Patrik Fimml wrote:
(Re-sending with correct mailing list addresses.)
Hi,
When the lid of a laptop is closed, certain devices can no longer
provide interesting input or will even
On Wed, Jul 16, 2014 at 7:17 AM, Alan Stern st...@rowland.harvard.edu wrote:
Various workarounds cover some of these cases, and we have some ugly
hacks in ChromeOS to make things work. It would be nice if a userspace
power management daemon could listen to the lid-close event, and then
have a
On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
The general design of Linux's runtime PM is that the PM core tells
drivers when their devices are no longer being used, and it's up to the
driver to select an appropriate low-power state. That philosophy
doesn't fit well with the problem you
On Wed, Jul 16, 2014 at 11:08 AM, Alan Stern st...@rowland.harvard.edu wrote:
I am not so much concerned about userspace, but about reusing of as
much of existing PM framework in the drivers. Right now it is very
hard to correctly track dependencies between general open/close,
system
On Wed, 2014-07-16 at 14:08 -0400, Alan Stern wrote:
I am not so much concerned about userspace, but about reusing of as
much of existing PM framework in the drivers. Right now it is very
hard to correctly track dependencies between general open/close,
system suspend/resume, and various
On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
(Re-sending with correct mailing list addresses.)
Hi,
When the lid of a laptop is closed, certain devices can no longer
provide interesting input or will even produce bogus input, such as:
- input devices: touchscreen, touchpad,
On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
(Re-sending with correct mailing list addresses.)
Hi,
When the lid of a laptop is closed, certain devices can no longer
provide interesting input or will even
On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
(Re-sending with correct mailing list addresses.)
Hi,
When the lid of a laptop is closed, certain
On Thu, Jul 17, 2014 at 01:11:31AM +0200, Rafael J. Wysocki wrote:
Let me try to understand the scenario in the first place.
To start with, a number of devices is in use (that is, open, there are
applications listening/talking to them etc). Now, an event happens, such
as a laptop lid close
On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
(Re-sending with correct mailing list addresses.)
On Wed, Jul 16, 2014 at 4:23 PM, Bastien Nocera had...@hadess.net wrote:
On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
On Tuesday, July 15, 2014 06:32:06 PM
80 matches
Mail list logo
