Power-managing devices that are not of interest at some point in time
(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
- sensors: ambient light sensor, accelerometer, magnetometer
- a video camera mounted on the lid
- display backlight
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 temporarily power off these devices, potentially through sysfs.
I've been discussing this with Dmitry and Benson (cc'd), and we've been wondering whether we could come up with a generic solution that could benefit multiple device classes.
There's some overlap with runtime PM here. The action to be taken in such a situation would probably be similar to a runtime suspend. The match is not perfect though, since devices with more than two power states might want to enter different states depending on the situation.
It's somewhat difficult to get the semantics right, since handles to such devices might still be open. It might be easier to implement behavior specific to device classes. On the other hand, it would be nice to have a uniform way of shutting devices down, and not introduce another possible path for a device to enter a power-saving state.
Rafael, can you give us your opinion on this?
Kind regards,
Patrik
Quoted 6 lines · Patrik Fimml
(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>
Quoted 7 lines
It's somewhat difficult to get the semantics right, since handles to such devices might still be open. It might be easier to implement behavior specific to device classes. On the other hand, it would be nice to have a uniform way of shutting devices down, and not introduce another possible path for a device to enter a power-saving state.
Rafael, can you give us your opinion on this?
Ditto the "tablet mode" of some devices such as the Thinkpad X41, or the newer Lenovo Yoga, which should have their keyboards and touchpads disabled.
If we used something like UPower to enable/disable those inaccessible devices, we'd need a way of enumerating which devices won't be accessible in those modes. Turning them off and back on should be easy enough.
Cheers
Quoted 8 lines · Patrik Fimml
(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 to be clear: The laptop's internal keyboard can't be used, but external keyboards can. The same goes for touchscreens and touchpads.
Quoted 1 line
- sensors: ambient light sensor, accelerometer, magnetometer
Why can't the accelerometer or magnetometer be used when the lid is closed?
Quoted 2 lines
- a video camera mounted on the lid
- display backlight
I can think of one possible use for a video camera mounted inside the lid. It's the modern analog of the age-old question: Does the refrigerator light go out when the door is closed? Using the video camera, users will be able to check whether the display backlight goes out when the lid is closed. :-)
Quoted 5 lines
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 temporarily power off these devices, potentially through sysfs.
Isn't it common for laptops to go into system suspend when the lid is closed?
Quoted 9 lines
I've been discussing this with Dmitry and Benson (cc'd), and we've been wondering whether we could come up with a generic solution that could benefit multiple device classes.
There's some overlap with runtime PM here. The action to be taken in such a situation would probably be similar to a runtime suspend. The match is not perfect though, since devices with more than two power states might want to enter different states depending on the situation.
Quoted 5 lines
It's somewhat difficult to get the semantics right, since handles to such devices might still be open. It might be easier to implement behavior specific to device classes. On the other hand, it would be nice to have a uniform way of shutting devices down, and not introduce another possible path for a device to enter a power-saving state.
What's the difference between shutting a device down and entering a power-saving state? That is, why shouldn't the first be considered an example of the second?
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 want to solve, because you want to turn off devices even when they _are_ still in use.
A separate sysfs interface might work out better.
Alan Stern
Hi Alan,
Quoted 6 lines · Alan Stern
Quoted 4 lines · Patrik Fimml
(Re-sending with correct mailing list addresses.)
Hi,
Quoted 7 lines
Quoted 4 lines
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 to be clear: The laptop's internal keyboard can't be used, but external keyboards can. The same goes for touchscreens and touchpads.
Right, we are talking about internal keyboards here, although there are other scenarios where userspace may want to inhibit certain devices. I think the common pattern with phones is to disable touchscreen while phone is held close to your ear to avoid accidental gestures.
Quoted 5 lines
Quoted 2 lines
- sensors: ambient light sensor, accelerometer, magnetometer
Why can't the accelerometer or magnetometer be used when the lid is closed?
It may or it may not, it depends on the application.
Quoted 9 lines
Quoted 3 lines
- a video camera mounted on the lid
- display backlightI can think of one possible use for a video camera mounted inside the lid. It's the modern analog of the age-old question: Does the refrigerator light go out when the door is closed? Using the video camera, users will be able to check whether the display backlight goes out when the lid is closed. :-)
;) The most common case though is not to use such device (or not present it to user/upper layers). When you are about to start video chat you do not want to have your integrated camera be first in the list of devices to be used when your lid is closed.
Quoted 9 lines
Quoted 6 lines
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 temporarily power off these devices, potentially through sysfs.
Isn't it common for laptops to go into system suspend when the lid is closed?
Not necessarily, depends on user/policy and that is what we want userspace to be able to define. I'd say we expect laptop to go to system suspend when you close lid while undocked. If laptop is docked then I just want to shut off screen and make my external monitor primary one.
Quoted 20 lines
Quoted 10 lines
I've been discussing this with Dmitry and Benson (cc'd), and we've been wondering whether we could come up with a generic solution that could benefit multiple device classes.
There's some overlap with runtime PM here. The action to be taken in such a situation would probably be similar to a runtime suspend. The match is not perfect though, since devices with more than two power states might want to enter different states depending on the situation.
Quoted 5 lines
It's somewhat difficult to get the semantics right, since handles to such devices might still be open. It might be easier to implement behavior specific to device classes. On the other hand, it would be nice to have a uniform way of shutting devices down, and not introduce another possible path for a device to enter a power-saving state.
What's the difference between shutting a device down and entering a power-saving state? That is, why shouldn't the first be considered an example of the second?
Quoted 5 lines
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 want to solve, because you want to turn off devices even when they _are_ still in use.
This does not sound quite right to me. We can tell PM core when devices absolutely can not go to low power mode, but certain devices can go into lower power state and wake up themselves even if there are
users: i.e. mice and keyboards with autosuspend. I guess it depends what you define as being "in use".
Quoted 3 lines
A separate sysfs interface might work out better.
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 runtime-PM transitions. Adding yet another PM mechanism into the mix will just add more complexity.
Thanks,
Dmitry
Quoted 11 lines · Dmitry Torokhov
Quoted 5 lines
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 want to solve, because you want to turn off devices even when they _are_ still in use.
This does not sound quite right to me. We can tell PM core when devices absolutely can not go to low power mode, but certain devices can go into lower power state and wake up themselves even if there are
users: i.e. mice and keyboards with autosuspend. I guess it depends what you define as being "in use".
True. Right now the PM core relies on subsystems and drivers to tell it when a device is or isn't in use.
Quoted 8 lines
Quoted 2 lines
A separate sysfs interface might work out better.
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 runtime-PM transitions. Adding yet another PM mechanism into the mix will just add more complexity.
Would it make sense to unbind the drivers for these devices when the lid is closed? With the drivers gone, there would naturally be no I/O interactions with the hardware and the class devices would disappear.
The respective subsystems could then use their own runtime PM mechanisms to power down the driverless devices. (Except for PCI, unfortunately, which has a policy of leaving driverless devices at full power. I was told this is a relic from the days before in-kernel mode switching for displays was common, when user programs like the X server would drive displays directly, without using a kernel driver.)
Alan Stern
Quoted 9 lines · Alan Stern
Quoted 5 lines
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 runtime-PM transitions. Adding yet another PM mechanism into the mix will just add more complexity.
Would it make sense to unbind the drivers for these devices when the lid is closed? With the drivers gone, there would naturally be no I/O interactions with the hardware and the class devices would disappear.
FWIW, per your earlier recommendation[1], that is the approach that my group has been using to disable various host controllers when Linux is running (not suspended) but certain power-hungry peripherals are not needed. It has mostly worked out OK; each driver typically implements its own special PHY init/shutdown procedure, and calls into the common clk_* functions to enable/disable the appropriate clocks.
Obviously the application needs to be able to cope with disappearing devices, and you wouldn't want to have any filesystems mounted on top of them when the unbind event happens.
Our devices are on an SoC's internal bus, not PCI.
[1] http://lists.linuxfoundation.org/pipermail/linux-pm/2012-April/033976.html
Quoted 9 lines · Alan Stern
Quoted 4 lines
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 runtime-PM transitions. Adding
yet
Quoted 1 line
another PM mechanism into the mix will just add more complexity.
Would it make sense to unbind the drivers for these devices when the lid is closed? With the drivers gone, there would naturally be no
No, because I don't want settings of my devices to disappear. You can do that only for stateless devices. And I doubt you can tell in general which devices are stateless.
Regards
Oliver
Quoted 8 lines · Alan Stern
Quoted 5 lines
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 temporarily power off these devices, potentially through sysfs.
Isn't it common for laptops to go into system suspend when the lid is closed?
It's common, but it does not cover all possible cases. As was mentioned by Dmitry, the user may dock his laptop, close his lid and use external display, keyboard, and mouse. In that case, the internal devices should be disabled or else they may send bogus input when the laptop's B panel couples with the touchpad, for example.
Even in the case where system suspend happens, we don't want to depend on that state change to disable these devices. It may take some time before the system enters suspend, and in the meantime the input devices with the lid closed may inadvertently cancel suspend by generating a pm_wakeup_event(), which is not what we want.
Other scenarios outside of lid close where such a feature would be helpful would be for transforming form-factors such as Yoga style laptops where the screen can fold back into tablet mode, and the C panel touchpad and keyboard should be disabled.
Signature · 3 lines
Benson Leung Software Engineer, Chrom* OS [email protected]
Quoted 27 lines · Patrik Fimml
(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
- sensors: ambient light sensor, accelerometer, magnetometer
- a video camera mounted on the lid
- display backlightVarious 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 temporarily power off these devices, potentially through sysfs.
I've been discussing this with Dmitry and Benson (cc'd), and we've been wondering whether we could come up with a generic solution that could benefit multiple device classes.
There's some overlap with runtime PM here. The action to be taken in such a situation would probably be similar to a runtime suspend. The match is not perfect though, since devices with more than two power states might want to enter different states depending on the situation.
Quoted 7 lines
It's somewhat difficult to get the semantics right, since handles to such devices might still be open. It might be easier to implement behavior specific to device classes. On the other hand, it would be nice to have a uniform way of shutting devices down, and not introduce another possible path for a device to enter a power-saving state.
Rafael, can you give us your opinion on this?
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 and you want some of those devices, but possibly not all of them, to quiesce themselves and go into low-power states.
Is that correct?
Rafael
Quoted 36 lines · Rafael J. Wysocki
Quoted 27 lines · Patrik Fimml
(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
- sensors: ambient light sensor, accelerometer, magnetometer
- a video camera mounted on the lid
- display backlightVarious 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 temporarily power off these devices, potentially through sysfs.
I've been discussing this with Dmitry and Benson (cc'd), and we've been wondering whether we could come up with a generic solution that could benefit multiple device classes.
There's some overlap with runtime PM here. The action to be taken in such a situation would probably be similar to a runtime suspend. The match is not perfect though, since devices with more than two power states might want to enter different states depending on the situation.
Quoted 7 lines
It's somewhat difficult to get the semantics right, since handles to such devices might still be open. It might be easier to implement behavior specific to device classes. On the other hand, it would be nice to have a uniform way of shutting devices down, and not introduce another possible path for a device to enter a power-saving state.
Rafael, can you give us your opinion on this?
Quoted 8 lines
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 and you want some of those devices, but possibly not all of them, to quiesce themselves and go into low-power states.
Is that correct?
FWIW, I wouldn't build all this complication into the kernel, I would expect:
- the kernel to make it easy to detect which of those devices are internal to the machine
- make it easy to detect the state of the whole machine (for some laptops like the Yoga, there's no SW_TABLET reporting)
- let well-behaved user-space handle the combined information (eg. it's an internal device + lid is closed = shouldn't be used)
For input devices for example, I'd build this into gnome-settings-daemon or gnome-shell directly, both of which have knowledge about input devices used. I'd expect other desktop environments to do similar things.
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 closed. Switching to external webcam, a webcam on the outside of the case, or switch off the video stream would then be the expected behaviour.
Quoted 60 lines · Bastien Nocera
Quoted 36 lines · Rafael J. Wysocki
Quoted 27 lines · Patrik Fimml
(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
- sensors: ambient light sensor, accelerometer, magnetometer
- a video camera mounted on the lid
- display backlightVarious 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 temporarily power off these devices, potentially through sysfs.
I've been discussing this with Dmitry and Benson (cc'd), and we've been wondering whether we could come up with a generic solution that could benefit multiple device classes.
There's some overlap with runtime PM here. The action to be taken in such a situation would probably be similar to a runtime suspend. The match is not perfect though, since devices with more than two power states might want to enter different states depending on the situation.
Quoted 7 lines
It's somewhat difficult to get the semantics right, since handles to such devices might still be open. It might be easier to implement behavior specific to device classes. On the other hand, it would be nice to have a uniform way of shutting devices down, and not introduce another possible path for a device to enter a power-saving state.
Rafael, can you give us your opinion on this?
Quoted 8 lines
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 and you want some of those devices, but possibly not all of them, to quiesce themselves and go into low-power states.
Is that correct?
FWIW, I wouldn't build all this complication into the kernel, I would expect:
- the kernel to make it easy to detect which of those devices are internal to the machine
- make it easy to detect the state of the whole machine (for some laptops like the Yoga, there's noSW_TABLETreporting)
- let well-behaved user-space handle the combined information (eg. it's an internal device + lid is closed = shouldn't be used)For input devices for example, I'd build this into gnome-settings-daemon or gnome-shell directly, both of which have knowledge about input devices used. I'd expect other desktop environments to do similar things.
Quoted 5 lines
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 closed. Switching to external webcam, a webcam on the outside of the case, or switch off the video stream would then be the expected behaviour.
Well, is the scenario I described correct or not? If not, then what exactly is the scenario you want to be able to handle?
Rafael
Quoted 46 lines · Rafael J. Wysocki
Quoted 45 lines · Bastien Nocera
Quoted 44 lines · Rafael J. Wysocki
Quoted 27 lines · Patrik Fimml
(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
- sensors: ambient light sensor, accelerometer, magnetometer
- a video camera mounted on the lid
- display backlightVarious 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 temporarily power off these devices, potentially through sysfs.
I've been discussing this with Dmitry and Benson (cc'd), and we've been wondering whether we could come up with a generic solution that could benefit multiple device classes.
There's some overlap with runtime PM here. The action to be taken in such a situation would probably be similar to a runtime suspend. The match is not perfect though, since devices with more than two power states might want to enter different states depending on the situation.
Quoted 7 lines
It's somewhat difficult to get the semantics right, since handles to such devices might still be open. It might be easier to implement behavior specific to device classes. On the other hand, it would be nice to have a uniform way of shutting devices down, and not introduce another possible path for a device to enter a power-saving state.
Rafael, can you give us your opinion on this?
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 and you want some of those devices, but possibly not all of them, to quiesce themselves and go into low-power states.
Is that correct?
<snip>
Quoted 2 lines
Well, is the scenario I described correct or not? If not, then what exactly is the scenario you want to be able to handle?
I don't expect devices to have to know about the lid status, no. Patrik might feel differently, but I think that all that's being asked is already possible through existing user-space mechanisms, it's just missing metadata to be able to implement it.
Quoted 39 lines · Bastien Nocera
Quoted 38 lines · Rafael J. Wysocki
Quoted 37 lines · Bastien Nocera
Quoted 36 lines · Rafael J. Wysocki
Quoted 34 lines · Patrik Fimml
(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
- sensors: ambient light sensor, accelerometer, magnetometer
- a video camera mounted on the lid
- display backlightVarious 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 temporarily power off these devices, potentially through sysfs.
I've been discussing this with Dmitry and Benson (cc'd), and we've been wondering whether we could come up with a generic solution that could benefit multiple device classes.
There's some overlap with runtime PM here. The action to be taken in such a situation would probably be similar to a runtime suspend. The match is not perfect though, since devices with more than two power states might want to enter different states depending on the situation.
It's somewhat difficult to get the semantics right, since handles to such devices might still be open. It might be easier to implement behavior specific to device classes. On the other hand, it would be nice to have a uniform way of shutting devices down, and not introduce another possible path for a device to enter a power-saving state.
Rafael, can you give us your opinion on this?
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
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 and you want some of those devices, but possibly not all of them, to quiesce themselves and go into low-power states.
Is that correct?
Pretty much, although the devices would not listen to events themselves but rather there will be an entity listening for various events and requesting certain devices to quiesce themselves in response for such events.
Quoted 8 lines
<snip>
Quoted 2 lines
Well, is the scenario I described correct or not? If not, then what exactly is the scenario you want to be able to handle?
I don't expect devices to have to know about the lid status, no. Patrik might feel differently, but I think that all that's being asked is already possible through existing user-space mechanisms, it's just missing metadata to be able to implement it.
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.
Thanks,
Dmitry
Quoted 4 lines · Dmitry Torokhov
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 ->freeze() callback. But it wasn't intended for this kind of use; drivers may very well expect that userspace will already be frozen when the callback runs. Besides, ->freeze() is supposed to quiesce devices without powering them down, whereas you want to do both.
What you're asking for is different from anything the PM subsystem has done before. Given this fact, I don't see any alternatives to adding a new API or repurposing an existing API. Either one would be somewhat painful.
For example, we could arrange to invoke ->suspend(). However, since the circumstances would be unusual (userspace is still running, ->prepare() was not called beforehand, ->suspend_irq() won't be called afterward), subsystems and drivers may very well react inappropriately.
Alan Stern
Quoted 11 lines · Alan Stern
Quoted 4 lines · Dmitry Torokhov
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 ->freeze() callback. But it wasn't intended for this kind of use; drivers may very well expect that userspace will already be frozen when the callback runs. Besides, ->freeze() is supposed to quiesce devices without powering them down, whereas you want to do both.
Right.
Quoted 3 lines
What you're asking for is different from anything the PM subsystem has done before.
Right.
Quoted 8 lines
Given this fact, I don't see any alternatives to adding a new API or repurposing an existing API. Either one would be somewhat painful.
For example, we could arrange to invoke ->suspend(). However, since the circumstances would be unusual (userspace is still running, ->prepare() was not called beforehand, ->suspend_irq() won't be called afterward), subsystems and drivers may very well react inappropriately.
I do not think anybody expects that drivers would not have to be modified to support this functionality; I expect drivers would have to declare themselves "queiscable" and therefore would assert that they will act according to whatever rules we set up. I only want to make sure that this new state is added to existing list of PM states rather than creating completely new facility, so that driver authors have a chance to understand PM state transitions that involve their driver.
Thanks,
Dmitry
Quoted 30 lines · Dmitry Torokhov
Quoted 11 lines · Alan Stern
Quoted 4 lines · Dmitry Torokhov
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 ->freeze() callback. But it wasn't intended for this kind of use; drivers may very well expect that userspace will already be frozen when the callback runs. Besides, ->freeze() is supposed to quiesce devices without powering them down, whereas you want to do both.
Right.
Quoted 3 lines
What you're asking for is different from anything the PM subsystem has done before.
Right.
Quoted 8 lines
Given this fact, I don't see any alternatives to adding a new API or repurposing an existing API. Either one would be somewhat painful.
For example, we could arrange to invoke ->suspend(). However, since the circumstances would be unusual (userspace is still running, ->prepare() was not called beforehand, ->suspend_irq() won't be called afterward), subsystems and drivers may very well react inappropriately.
Quoted 7 lines
I do not think anybody expects that drivers would not have to be modified to support this functionality; I expect drivers would have to declare themselves "queiscable" and therefore would assert that they will act according to whatever rules we set up. I only want to make sure that this new state is added to existing list of PM states rather than creating completely new facility, so that driver authors have a chance to understand PM state transitions that involve their driver.
If you're referring to runtime PM, it doesn't use "states". It uses status values (you can think of them as metastates) which are "active", "suspended" or in-transit from one to the other. There's no room for more of these in the design, I'm afraid.
Moreover, .runtime_suspend() can only be called when the device is quiescent already. [That also applies to .suspend_late() and .suspend_irq() for system suspend and the freezing of tasks is requisite for the .prepare() and .suspend() callbacks (and the corresponding hibernation-related ones).]
Quoted 1 line
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 or another. That is the reason for using the freezer during system suspend. In other words, if you want drivers to quiesce devices by force, you need to quiesce user space by force to start with - for example by freezing it.
For runtime PM, on the other hand, the underlying observation is that drivers should be able to detect when devices are already quiescent and initialize power transitions at those points. It's role is to help with that, but not with quiescing things.
That said, in the "laptop lid closed" scenario (assuming that the system is not supposed to suspend in response to that, which in my opinion is the best approach) 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 "more aggressive runtime PM mode" in which they will use any opportunity to start a power transition without worrying about extra latencies resulting from that. In that mode they should also disable remote wakeup. I think this should be sufficient to address the use case at hand.
Rafael
Quoted 56 lines · Rafael J. Wysocki
Quoted 29 lines · Dmitry Torokhov
Quoted 11 lines · Alan Stern
Quoted 4 lines · Dmitry Torokhov
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 ->freeze() callback. But it wasn't intended for this kind of use; drivers may very well expect that userspace will already be frozen when the callback runs. Besides, ->freeze() is supposed to quiesce devices without powering them down, whereas you want to do both.
Right.
Quoted 2 lines
What you're asking for is different from anything the PM subsystem has done before.
Right.
Quoted 8 lines
Given this fact, I don't see any alternatives to adding a new API or repurposing an existing API. Either one would be somewhat painful.
For example, we could arrange to invoke ->suspend(). However, since the circumstances would be unusual (userspace is still running, ->prepare() was not called beforehand, ->suspend_irq() won't be called afterward), subsystems and drivers may very well react inappropriately.
Quoted 7 lines
I do not think anybody expects that drivers would not have to be modified to support this functionality; I expect drivers would have to declare themselves "queiscable" and therefore would assert that they will act according to whatever rules we set up. I only want to make sure that this new state is added to existing list of PM states rather than creating completely new facility, so that driver authors have a chance to understand PM state transitions that involve their driver.
If you're referring to runtime PM, it doesn't use "states". It uses status values (you can think of them as metastates) which are "active", "suspended" or in-transit from one to the other. There's no room for more of these in the design, I'm afraid.
Moreover, .runtime_suspend() can only be called when the device is quiescent already. [That also applies to .suspend_late() and .suspend_irq() for system suspend and the freezing of tasks is requisite for the .prepare() and .suspend() callbacks (and the corresponding hibernation-related ones).]
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 or another. That is the reason for using the freezer during system suspend. In other words, if you want drivers to quiesce devices by force, you need to quiesce user space by force to start with - for example by freezing it.
Quoted 8 lines
For runtime PM, on the other hand, the underlying observation is that drivers should be able to detect when devices are already quiescent and initialize power transitions at those points. It's role is to help with that, but not with quiescing things.
That said, in the "laptop lid closed" scenario (assuming that the system is not supposed to suspend in response to that, which in my opinion is the best approach)
This is default approach that works for many, but not necessarily all use cases. I believe docked with lid closed scenario was mentioned already.
Quoted 8 lines
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 "more aggressive runtime PM mode" in which they will use any opportunity to start a power transition without worrying about extra latencies resulting from that. In that mode they should also disable remote wakeup. I think this should be sufficient to address the use case at hand.
OK, so how do we let the drivers know that they should start being aggressive with PM and that they should disable remote wakeup? I'd rather not add subsystem-specific interface for this, that is why we are reaching out in the first place.
Thanks,
Dmitry
Quoted 78 lines · Dmitry Torokhov
Quoted 56 lines · Rafael J. Wysocki
Quoted 29 lines · Dmitry Torokhov
Quoted 11 lines · Alan Stern
Quoted 4 lines · Dmitry Torokhov
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 ->freeze() callback. But it wasn't intended for this kind of use; drivers may very well expect that userspace will already be frozen when the callback runs. Besides, ->freeze() is supposed to quiesce devices without powering them down, whereas you want to do both.
Right.
Quoted 2 lines
What you're asking for is different from anything the PM subsystem has done before.
Right.
Quoted 8 lines
Given this fact, I don't see any alternatives to adding a new API or repurposing an existing API. Either one would be somewhat painful.
For example, we could arrange to invoke ->suspend(). However, since the circumstances would be unusual (userspace is still running, ->prepare() was not called beforehand, ->suspend_irq() won't be called afterward), subsystems and drivers may very well react inappropriately.
Quoted 7 lines
I do not think anybody expects that drivers would not have to be modified to support this functionality; I expect drivers would have to declare themselves "queiscable" and therefore would assert that they will act according to whatever rules we set up. I only want to make sure that this new state is added to existing list of PM states rather than creating completely new facility, so that driver authors have a chance to understand PM state transitions that involve their driver.
If you're referring to runtime PM, it doesn't use "states". It uses status values (you can think of them as metastates) which are "active", "suspended" or in-transit from one to the other. There's no room for more of these in the design, I'm afraid.
Moreover, .runtime_suspend() can only be called when the device is quiescent already. [That also applies to .suspend_late() and .suspend_irq() for system suspend and the freezing of tasks is requisite for the .prepare() and .suspend() callbacks (and the corresponding hibernation-related ones).]
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 or another. That is the reason for using the freezer during system suspend. In other words, if you want drivers to quiesce devices by force, you need to quiesce user space by force to start with - for example by freezing it.
Quoted 8 lines
For runtime PM, on the other hand, the underlying observation is that drivers should be able to detect when devices are already quiescent and initialize power transitions at those points. It's role is to help with that, but not with quiescing things.
That said, in the "laptop lid closed" scenario (assuming that the system is not supposed to suspend in response to that, which in my opinion is the best approach)
This is default approach that works for many, but not necessarily all use cases. I believe docked with lid closed scenario was mentioned already.
Quoted 8 lines
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 "more aggressive runtime PM mode" in which they will use any opportunity to start a power transition without worrying about extra latencies resulting from that. In that mode they should also disable remote wakeup. I think this should be sufficient to address the use case at hand.
Quoted 4 lines
OK, so how do we let the drivers know that they should start being aggressive with PM and that they should disable remote wakeup? I'd rather not add subsystem-specific interface for this, that is why we are reaching out in the first place.
For disabling remote wakeup we have a PM QoS flag that I'm not entirely happy with, so I guess we can replace it with something saner (I talked about that with Alan during the last year's LinuxCon, but then didn't have the time to get to that).
For the whole thing I guess we can add a sysfs attribute under devices/.../power that will need to be exposed by drivers supporting that feature. I'm not sure how to call it, though.
Rafael
Quoted 84 lines · Rafael J. Wysocki
Quoted 78 lines · Dmitry Torokhov
Quoted 56 lines · Rafael J. Wysocki
Quoted 29 lines · Dmitry Torokhov
Quoted 11 lines · Alan Stern
Quoted 4 lines · Dmitry Torokhov
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 ->freeze() callback. But it wasn't intended for this kind of use; drivers may very well expect that userspace will already be frozen when the callback runs. Besides, ->freeze() is supposed to quiesce devices without powering them down, whereas you want to do both.
Right.
Quoted 2 lines
What you're asking for is different from anything the PM subsystem has done before.
Right.
Quoted 8 lines
Given this fact, I don't see any alternatives to adding a new API or repurposing an existing API. Either one would be somewhat painful.
For example, we could arrange to invoke ->suspend(). However, since the circumstances would be unusual (userspace is still running, ->prepare() was not called beforehand, ->suspend_irq() won't be called afterward), subsystems and drivers may very well react inappropriately.
Quoted 7 lines
I do not think anybody expects that drivers would not have to be modified to support this functionality; I expect drivers would have to declare themselves "queiscable" and therefore would assert that they will act according to whatever rules we set up. I only want to make sure that this new state is added to existing list of PM states rather than creating completely new facility, so that driver authors have a chance to understand PM state transitions that involve their driver.
If you're referring to runtime PM, it doesn't use "states". It uses status values (you can think of them as metastates) which are "active", "suspended" or in-transit from one to the other. There's no room for more of these in the design, I'm afraid.
Moreover, .runtime_suspend() can only be called when the device is quiescent already. [That also applies to .suspend_late() and .suspend_irq() for system suspend and the freezing of tasks is requisite for the .prepare() and .suspend() callbacks (and the corresponding hibernation-related ones).]
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 or another. That is the reason for using the freezer during system suspend. In other words, if you want drivers to quiesce devices by force, you need to quiesce user space by force to start with - for example by freezing it.
Quoted 8 lines
For runtime PM, on the other hand, the underlying observation is that drivers should be able to detect when devices are already quiescent and initialize power transitions at those points. It's role is to help with that, but not with quiescing things.
That said, in the "laptop lid closed" scenario (assuming that the system is not supposed to suspend in response to that, which in my opinion is the best approach)
This is default approach that works for many, but not necessarily all use cases. I believe docked with lid closed scenario was mentioned already.
Quoted 8 lines
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 "more aggressive runtime PM mode" in which they will use any opportunity to start a power transition without worrying about extra latencies resulting from that. In that mode they should also disable remote wakeup. I think this should be sufficient to address the use case at hand.Quoted 4 lines
OK, so how do we let the drivers know that they should start being aggressive with PM and that they should disable remote wakeup? I'd rather not add subsystem-specific interface for this, that is why we are reaching out in the first place.
Quoted 8 lines
For disabling remote wakeup we have a PM QoS flag that I'm not entirely happy with, so I guess we can replace it with something saner (I talked about that with Alan during the last year's LinuxCon, but then didn't have the time to get to that).
For the whole thing I guess we can add a sysfs attribute under devices/.../power that will need to be exposed by drivers supporting that feature. I'm not sure how to call it, though.
Or we could add an "aggressive" value to the devices/.../power/control attribute, but then it will be difficult for user space to verify whether or not it is supported for the given device.
Rafael
Quoted 14 lines · Rafael J. Wysocki
Quoted 9 lines
Quoted 8 lines
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 "more aggressive runtime PM mode" in which they will use any opportunity to start a power transition without worrying about extra latencies resulting from that. In that mode they should also disable remote wakeup. I think this should be sufficient to address the use case at hand.Quoted 4 lines
OK, so how do we let the drivers know that they should start being aggressive with PM and that they should disable remote wakeup? I'd rather not add subsystem-specific interface for this, that is why we are reaching out in the first place.
Quoted 4 lines
For disabling remote wakeup we have a PM QoS flag that I'm not entirely happy with, so I guess we can replace it with something saner (I talked about that with Alan during the last year's LinuxCon, but then didn't have the time to get to that).
Right. We discussed changing .../power/wakeup so that it could contain "enabled", "disabled", or "off", where "off" would mean remote wakeup should be disabled even during runtime suspend.
Quoted 3 lines
For the whole thing I guess we can add a sysfs attribute under devices/.../power that will need to be exposed by drivers supporting that feature. I'm not sure how to call it, though.
"runtime_mode"?
Will this really be capable of doing what Dmitry wants? I don't know how the drivers in question work. But if a driver increments the runtime usage count each time the device file is opened, forcibly setting the usage count back to 0 won't be easy.
Also, would putting the camera into runtime suspend prevent it from showing up on a list of available video devices? I doubt it. More likely, the video driver would have to unregister the class device while remaining bound to the physical device. Probably other drivers would have to do the same sort of thing. (I don't know whether doing this would retain the settings as Oliver wants, though.)
Alan Stern
Quoted 6 lines · Rafael J. Wysocki
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 or another. That is the reason for using the freezer during system suspend. In other words, if you want drivers to quiesce devices by force, you need to quiesce user space by force to start with - for example by freezing it.
Can you give me some pointers?
Quoted 5 lines
For runtime PM, on the other hand, the underlying observation is that drivers should be able to detect when devices are already quiescent and initialize power transitions at those points. It's role is to help with that, but not with quiescing things.
Quoted 9 lines
That said, in the "laptop lid closed" scenario (assuming that the system is not supposed to suspend in response to that, which in my opinion is the best approach) 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 "more aggressive runtime PM mode" in which they will use any opportunity to start a power transition without worrying about extra latencies resulting from that. In that mode they should also disable remote wakeup. I think this should be sufficient to address the use case at hand.
Let me try to clear things up a little.
Of course, in most cases, a laptop would enter suspend after closing the lid. But you can think of scenarios where the laptop would stay on:
- Your laptop is docked, and you use an external monitor, but you don't want to have your laptop open (maybe due to lack of space).
- You have your laptop in your backpack and use it as a music player.
In those scenarios, you wouldn't want to see bogus input (our worst-case example is the mouse pointer being over the 1-Click Buy button on Amazon - stray clicks that result from the laptop lid interfering with the touchpad wouldn't be a good thing).
Now there are basically two approaches with pros and cons:
1. Get userspace to close handles to all such devices while the lid is closed, and
1a. Have drivers with sufficiently aggressive PM so that devices are
actually going to a low-power/off state when userspace doesn't have any handles open.
This can be done with the infrastructure that we have in the kernel today, although drivers might have to be improved in order to actually get devices to power off.
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.
For input devices, this makes a lot of sense in my opinion.
The notable difference to runtime PM as we have it today is that with runtime PM, a device typically goes to a low-power state because it is idle. In our scenario, we want to forcibly quiesce it even if it is not idle (and if it continues to provide events in a low-power mode, we want to ignore them instead of passing them on). So maybe integration with runtime PM is not the best fit.
Perhaps the best way to go forward would be to add a new property for all devices that support quiescing so userspace has a uniform way of doing things, but have subsystems (and potentially the device driver) decide what action is appropriate to quiesce a device. Some subsystems might be able to provide a default implementation (e.g. input could just skip all events that are reported from the device driver).
Regards,
Patrik
Quoted 3 lines · Patrik Fimml
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 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 possible. A better word would be "deactivating".
Quoted 1 line
For input devices, this makes a lot of sense in my opinion.
I agree.
Quoted 7 lines
The notable difference to runtime PM as we have it today is that with runtime PM, a device typically goes to a low-power state because it is idle. In our scenario, we want to forcibly quiesce it even if it is not idle (and if it continues to provide events in a low-power mode, we want to ignore them instead of passing them on). So maybe integration with runtime PM is not the best fit.
Quoted 6 lines
Perhaps the best way to go forward would be to add a new property for all devices that support quiescing so userspace has a uniform way of doing things, but have subsystems (and potentially the device driver) decide what action is appropriate to quiesce a device. Some subsystems might be able to provide a default implementation (e.g. input could just skip all events that are reported from the device driver).
You mentioned that handles to the device would remain open. So when the user opens the lid again, the old handles would start functioning, right?
This has the disadvantage that the class device could not be unregistered, because doing so would invalidate the open handles. Under such circumestances, how would a userspace video program know not to list a camera built into the lid among the possible video sources (an example given earlier in this discussion)? The program would have to make an explicit test of the "deactivate" property -- it wouldn't automatically become aware that the camera wasn't available.
Would it sometimes be okay to unregister the class device and invalidate the old handles, forcing programs to open new handles when the lid is opened? This would reduce the number of changes user programs would need.
Alan Stern
Quoted 5 lines · Alan Stern
"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 possible. A better word would be "deactivating".
Yeah, I agree that terminology is a bit tricky here, and we have some words conveying a specific idea already ("suspend"). To me, deactivating suggests a more permanent condition. FWIW, I've used "inhibit" in this context before and think it captures the idea well, to add another choice to the list.
Quoted 3 lines
You mentioned that handles to the device would remain open. So when the user opens the lid again, the old handles would start functioning, right?
That's the idea, yes, and I think this would be desirable for the input device class at least.
Quoted 8 lines
This has the disadvantage that the class device could not be unregistered, because doing so would invalidate the open handles. Under such circumestances, how would a userspace video program know not to list a camera built into the lid among the possible video sources (an example given earlier in this discussion)? The program would have to make an explicit test of the "deactivate" property -- it wouldn't automatically become aware that the camera wasn't available.
Quoted 4 lines
Would it sometimes be okay to unregister the class device and invalidate the old handles, forcing programs to open new handles when the lid is opened? This would reduce the number of changes user programs would need.
I guess we could potentially leave this for the device class to decide.
I'm not sure what the appropriate action for a video camera is anyway. Should it go away completely, including its device? Should it be there, but certainly not be the default choice when there is an external camera? I'm thinking along the lines of some application's settings dialog here, where it might be desirable to still be able to select the internal camera for future recordings.
Of course, userspace could still decide simply not to quiesce|deactivate|inhibit the device if that was desired.
Regards,
Patrik
Quoted 7 lines · Patrik Fimml
Quoted 5 lines · Alan Stern
"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 possible. A better word would be "deactivating".
Quoted 5 lines
Yeah, I agree that terminology is a bit tricky here, and we have some words conveying a specific idea already ("suspend"). To me, deactivating suggests a more permanent condition. FWIW, I've used "inhibit" in this context before and think it captures the idea well, to add another choice to the list.
Well, you can always reactivate a device after it has been deactivated. But "inhibit" is good too.
Quoted 6 lines
Quoted 3 lines
You mentioned that handles to the device would remain open. So when the user opens the lid again, the old handles would start functioning, right?
That's the idea, yes, and I think this would be desirable for the input device class at least.
For the input class, it may not matter. For example, the X server should deal well with a touchpad that effectively gets hot-unplugged and then hot-plugged later.
Quoted 8 lines
Quoted 8 lines
This has the disadvantage that the class device could not be unregistered, because doing so would invalidate the open handles. Under such circumestances, how would a userspace video program know not to list a camera built into the lid among the possible video sources (an example given earlier in this discussion)? The program would have to make an explicit test of the "deactivate" property -- it wouldn't automatically become aware that the camera wasn't available.
Quoted 6 lines
Quoted 4 lines
Would it sometimes be okay to unregister the class device and invalidate the old handles, forcing programs to open new handles when the lid is opened? This would reduce the number of changes user programs would need.
I guess we could potentially leave this for the device class to decide.
Makes sense.
Quoted 9 lines
I'm not sure what the appropriate action for a video camera is anyway. Should it go away completely, including its device? Should it be there, but certainly not be the default choice when there is an external camera? I'm thinking along the lines of some application's settings dialog here, where it might be desirable to still be able to select the internal camera for future recordings.
Of course, userspace could still decide simply not to quiesce|deactivate|inhibit the device if that was desired.
There's some question about how much of userspace needs to get involved. Just the daemon that manages these configuration changes, or other programs as well? I guess that's not really our problem...
In the end, it sounds like you're suggesting a new pair of PM
callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and ->uninhibit(). Plus an optional (?) sysfs interface for invoking the callbacks.
Alan Stern
Quoted 21 lines · Alan Stern
Quoted 7 lines · Patrik Fimml
Quoted 5 lines · Alan Stern
"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 possible. A better word would be "deactivating".
Quoted 5 lines
Yeah, I agree that terminology is a bit tricky here, and we have some words conveying a specific idea already ("suspend"). To me, deactivating suggests a more permanent condition. FWIW, I've used "inhibit" in this context before and think it captures the idea well, to add another choice to the list.
Well, you can always reactivate a device after it has been deactivated. But "inhibit" is good too.
Quoted 4 lines
Quoted 3 lines
You mentioned that handles to the device would remain open. So when the user opens the lid again, the old handles would start functioning, right?
Quoted 6 lines
Quoted 2 lines
That's the idea, yes, and I think this would be desirable for the input device class at least.
For the input class, it may not matter. For example, the X server should deal well with a touchpad that effectively gets hot-unplugged and then hot-plugged later.
I thin kit would be nice if we could differentiate between unplugged (physically gone) and disabled devices. If we shut off the touchpad does it mean that user can't use UI to activate edge scrolling vs. two-finger scrolling because our implementation made device to vanish?
Quoted 25 lines
Quoted 9 lines
Quoted 9 lines
This has the disadvantage that the class device could not be unregistered, because doing so would invalidate the open handles. Under such circumestances, how would a userspace video program know not to list a camera built into the lid among the possible video sources (an example given earlier in this discussion)? The program would have to make an explicit test of the "deactivate" property -- it wouldn't automatically become aware that the camera wasn't available.
Quoted 6 lines
Quoted 4 lines
Would it sometimes be okay to unregister the class device and invalidate the old handles, forcing programs to open new handles when the lid is opened? This would reduce the number of changes user programs would need.
I guess we could potentially leave this for the device class to decide.
Makes sense.
Quoted 7 lines
I'm not sure what the appropriate action for a video camera is anyway. Should it go away completely, including its device? Should it be there, but certainly not be the default choice when there is an external camera? I'm thinking along the lines of some application's settings dialog here, where it might be desirable to still be able to select the internal camera for future recordings.
Quoted 6 lines
Quoted 2 lines
Of course, userspace could still decide simply not to quiesce|deactivate|inhibit the device if that was desired.
There's some question about how much of userspace needs to get involved. Just the daemon that manages these configuration changes, or other programs as well? I guess that's not really our problem...
We need to provide means of implementing policy; the policy itself is not really our concern ;)
Quoted 5 lines
In the end, it sounds like you're suggesting a new pair of PM
callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and ->uninhibit(). Plus an optional (?) sysfs interface for invoking the callbacks.
We do need sysfs interface so that userspace can talk to the devices in question; and we also need to make sure that PM core is aware of the new callbacks and provides guarantees about their interactions with system- and runtime-PM callbacks so that individual drivers do not have to sort it out on their own.
Thanks,
Dmitry
Quoted 3 lines · Dmitry Torokhov
Quoted 2 lines · Alan Stern
Quoted 1 line · Patrik Fimml
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
Quoted 23 lines
Quoted 7 lines
Quoted 7 lines
I'm not sure what the appropriate action for a video camera is anyway. Should it go away completely, including its device? Should it be there, but certainly not be the default choice when there is an external camera? I'm thinking along the lines of some application's settings dialog here, where it might be desirable to still be able to select the internal camera for future recordings.
Quoted 6 lines
Quoted 2 lines
Of course, userspace could still decide simply not to quiesce|deactivate|inhibit the device if that was desired.
There's some question about how much of userspace needs to get involved. Just the daemon that manages these configuration changes, or other programs as well? I guess that's not really our problem...
We need to provide means of implementing policy; the policy itself is not really our concern ;)
Quoted 5 lines
In the end, it sounds like you're suggesting a new pair of PM
callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and ->uninhibit(). Plus an optional (?) sysfs interface for invoking the callbacks.
Quoted 5 lines
We do need sysfs interface so that userspace can talk to the devices in question; and we also need to make sure that PM core is aware of the new callbacks and provides guarantees about their interactions with system- and runtime-PM callbacks so that individual drivers do not have to sort it out on their own.
A step back, please.
I have no idea why those need to be PM callbacks.
What you need really seems to be a way to tell a driver "ignore input from this device from now on as it is most likely bogus". A natural reaction of the driver to that might be to stop processing input from the device and then runtime suspend it (and prevent it from generating remote wakeup as that may be bogus as well), but I don't see why the PM core needs to be involved in that at all.
Rafael
Quoted 39 lines · Rafael J. Wysocki
Quoted 3 lines · Dmitry Torokhov
Quoted 2 lines · Alan Stern
Quoted 1 line · Patrik Fimml
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
Quoted 24 lines
Quoted 9 lines
Quoted 9 lines
I'm not sure what the appropriate action for a video camera is anyway. Should it go away completely, including its device? Should it be there,
but certainly not be the default choice when there is an external camera? I'm thinking along the lines of some application's settings dialog here, where it might be desirable to still be able to select the
internal camera for future recordings.Quoted 6 lines
Quoted 2 lines
Of course, userspace could still decide simply not to quiesce|deactivate|inhibit the device if that was desired.
There's some question about how much of userspace needs to get involved. Just the daemon that manages these configuration changes, or other programs as well? I guess that's not really our problem...
We need to provide means of implementing policy; the policy itself is not really our concern ;)
Quoted 4 lines
In the end, it sounds like you're suggesting a new pair of PM
callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and ->uninhibit(). Plus an optional (?) sysfs interface for invoking the callbacks.Quoted 6 lines
We do need sysfs interface so that userspace can talk to the devices in question; and we also need to make sure that PM core is aware of the new callbacks and provides guarantees about their interactions with system- and
runtime-PM callbacks so that individual drivers do not have to sort it out on their own.A step back, please.
Quoted 8 lines
I have no idea why those need to be PM callbacks.
What you need really seems to be a way to tell a driver "ignore input from this device from now on as it is most likely bogus". A natural reaction of the driver to that might be to stop processing input from the device and then runtime suspend it (and prevent it from generating remote wakeup as that may be bogus as well), but I don't see why the PM core needs to be involved in that at all.
So that we do not need to handle cases like:
- I am already in idle state and request comes to inhibit, what do I do (in driver) or:
- I inhibited the device, now system suspend comes, what do I do? Also what do I do at resume? I'd rather not have driver checks host of flags to figure out the end state if PM core could spell it out for me. We already have to sort out open/close and suspend/resume iteractions (i.e what one needs to do to suspend or resume device that has not been opened, and if it is different from devices that have been opened).
Thanks,
Dmitry
Quoted 49 lines · Dmitry Torokhov
Quoted 39 lines · Rafael J. Wysocki
Quoted 3 lines · Dmitry Torokhov
Quoted 2 lines · Alan Stern
Quoted 1 line · Patrik Fimml
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
Quoted 24 lines
Quoted 9 lines
Quoted 9 lines
I'm not sure what the appropriate action for a video camera is anyway. Should it go away completely, including its device? Should it be there,
but certainly not be the default choice when there is an external camera? I'm thinking along the lines of some application's settings dialog here, where it might be desirable to still be able to select the
internal camera for future recordings.Quoted 6 lines
Quoted 2 lines
Of course, userspace could still decide simply not to quiesce|deactivate|inhibit the device if that was desired.
There's some question about how much of userspace needs to get involved. Just the daemon that manages these configuration changes, or other programs as well? I guess that's not really our problem...
We need to provide means of implementing policy; the policy itself is not really our concern ;)
Quoted 4 lines
In the end, it sounds like you're suggesting a new pair of PM
callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and ->uninhibit(). Plus an optional (?) sysfs interface for invoking the callbacks.Quoted 6 lines
We do need sysfs interface so that userspace can talk to the devices in question; and we also need to make sure that PM core is aware of the new callbacks and provides guarantees about their interactions with system- and
runtime-PM callbacks so that individual drivers do not have to sort it out on their own.A step back, please.
Quoted 8 lines
I have no idea why those need to be PM callbacks.
What you need really seems to be a way to tell a driver "ignore input from this device from now on as it is most likely bogus". A natural reaction of the driver to that might be to stop processing input from the device and then runtime suspend it (and prevent it from generating remote wakeup as that may be bogus as well), but I don't see why the PM core needs to be involved in that at all.
Quoted 4 lines
So that we do not need to handle cases like:
- I am already in idle state and request comes to inhibit, what do I do (in driver) or:
I'm not sure why being "suspended" or not matters here. The PM core doesn't know what physical state the device is in anyway and the driver or subsystem (or another layer such as ACPI) has to track that.
Also it seems that it should be perfectly fine to ignore input from the device without suspending it as well as it is perfectly fine to be suspended while you are generally not ignoring the input (just because there is no input at the moment, for example).
Yes, it make sense to suspend the device when you know you'll ignore input going forward, but then if the real goal is to prevent bogus input from reaching applications, then this isn't a power management problem even.
Quoted 3 lines
- I inhibited the device, now system suspend comes, what do I do? Also what do I do at resume? I'd rather not have driver checks host of flags to figure out the end state if PM core could spell it out for me.
Well, how will the new PM callbacks help here, exactly?
Quoted 4 lines
We already have to sort
out open/close and suspend/resume iteractions (i.e what one needs to do to suspend or resume device that has not been opened, and if it is different from devices that have been opened).
I guess it would help if you gave an example.
Rafael
Quoted 59 lines · Rafael J. Wysocki
Quoted 49 lines · Dmitry Torokhov
Quoted 39 lines · Rafael J. Wysocki
Quoted 3 lines · Dmitry Torokhov
Quoted 2 lines · Alan Stern
Quoted 1 line · Patrik Fimml
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
Quoted 24 lines
Quoted 9 lines
Quoted 9 lines
I'm not sure what the appropriate action for a video camera is anyway. Should it go away completely, including its device? Should it be there,
but certainly not be the default choice when there is an external camera? I'm thinking along the lines of some application's settings dialog here, where it might be desirable to still be able to select the
internal camera for future recordings.Quoted 6 lines
Quoted 2 lines
Of course, userspace could still decide simply not to quiesce|deactivate|inhibit the device if that was desired.
There's some question about how much of userspace needs to get involved. Just the daemon that manages these configuration changes, or other programs as well? I guess that's not really our problem...
We need to provide means of implementing policy; the policy itself is not really our concern ;)
Quoted 4 lines
In the end, it sounds like you're suggesting a new pair of PM
callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and ->uninhibit(). Plus an optional (?) sysfs interface for invoking the callbacks.Quoted 6 lines
We do need sysfs interface so that userspace can talk to the devices in question; and we also need to make sure that PM core is aware of the new callbacks and provides guarantees about their interactions with system- and
runtime-PM callbacks so that individual drivers do not have to sort it out on their own.A step back, please.
Quoted 8 lines
I have no idea why those need to be PM callbacks.
What you need really seems to be a way to tell a driver "ignore input from this device from now on as it is most likely bogus". A natural reaction of the driver to that might be to stop processing input from the device and then runtime suspend it (and prevent it from generating remote wakeup as that may be bogus as well), but I don't see why the PM core needs to be involved in that at all.
Quoted 4 lines
So that we do not need to handle cases like:
- I am already in idle state and request comes to inhibit, what do I do (in driver) or:
I'm not sure why being "suspended" or not matters here. The PM core doesn't know what physical state the device is in anyway and the driver or subsystem (or another layer such as ACPI) has to track that.
Quoted 8 lines
Also it seems that it should be perfectly fine to ignore input from the device without suspending it as well as it is perfectly fine to be suspended while you are generally not ignoring the input (just because there is no input at the moment, for example).
Yes, it make sense to suspend the device when you know you'll ignore input going forward, but then if the real goal is to prevent bogus input from reaching applications, then this isn't a power management problem even.
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 source.
Rafael
Quoted 82 lines · Rafael J. Wysocki
Quoted 81 lines · Rafael J. Wysocki
Quoted 65 lines · Dmitry Torokhov
Quoted 52 lines · Rafael J. Wysocki
Quoted 3 lines · Dmitry Torokhov
Quoted 2 lines · Alan Stern
Quoted 1 line · Patrik Fimml
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
Quoted 31 lines
Quoted 13 lines
Quoted 13 lines
I'm not sure what the appropriate action for a video camera is anyway.
Should it go away completely, including its device? Should it be there,
but certainly not be the default choice when there is an external
camera? I'm thinking along the lines of some application's settings
dialog here, where it might be desirable to still be able to select
the
internal camera for future recordings.Quoted 7 lines
Quoted 2 lines
Of course, userspace could still decide simply not to quiesce|deactivate|inhibit the device if that was desired.
There's some question about how much of userspace needs to get involved. Just the daemon that manages these configuration changes, or
other programs as well? I guess that's not really our problem...We need to provide means of implementing policy; the policy itself is not
really our concern ;)Quoted 5 lines
In the end, it sounds like you're suggesting a new pair of PM
callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and ->uninhibit(). Plus an optional (?) sysfs interface for invoking the
callbacks.Quoted 10 lines
We do need sysfs interface so that userspace can talk to the devices in
question; and we also need to make sure that PM core is aware of the new
callbacks and provides guarantees about their interactions with system-
and
runtime-PM callbacks so that individual drivers do not have to sort it out
on their own.A step back, please.
I have no idea why those need to be PM callbacks.
Quoted 11 lines
What you need really seems to be a way to tell a driver "ignore input from
this device from now on as it is most likely bogus". A natural reaction of
the driver to that might be to stop processing input from the device and
then runtime suspend it (and prevent it from generating remote wakeup as
that may be bogus as well), but I don't see why the PM core needs to be
involved in that at all.Quoted 6 lines
So that we do not need to handle cases like:
- I am already in idle state and request comes to inhibit, what do I do (in
driver) or:
I'm not sure why being "suspended" or not matters here. The PM core doesn't know what physical state the device is in anyway and the driver or subsystem (or another layer such as ACPI) has to track that.
Also it seems that it should be perfectly fine to ignore input from the device without suspending it as well as it is perfectly fine to be suspended while you are generally not ignoring the input (just because there is no input at the moment, for example).
Quoted 8 lines
Quoted 3 lines
Yes, it make sense to suspend the device when you know you'll ignore input going forward, but then if the real goal is to prevent bogus input from reaching applications, then this isn't a power management problem even.
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 source.
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.
Considering input devices:
input_open(): check if device is inhibited, if so do nothing. Otherwise try waking up itself and parent (via pm_runtime_get_sync() on itself), this will power up the device. Do additional configuration if needed.
input_close(): check if device is inhibited, if not do pm_runtime_put (_sync? to make sure we power off properly and not leave device up and running? or should we power down manually not waiting for runtime PM)?
inhibit(): check if device is opened, if opened do pm_runtime_put_sync().
uninhibit(): if device is opened do pm_runtime_get_sync(), let runtime PM bring up the device. Do additional config if needed -> very similar to input_open(), different condition.
runtime_suspend(): power down the device. If not inhibited enable as wakeup source.
runtime_resume(): power up the device if device is opened and not inhibited.
system_suspend(): check if device is opened, not inhibited and not in runtimesuspend already; power down.
system_resume(): power up the device if it is opened and not inhibited. I guess it's OK to wake up device that shoudl be runtime-PM-idle since it will go to back sleep shortly.
Ugh.. This is complicated...
Thanks,
Dmitry
Quoted 100 lines · Dmitry Torokhov
Quoted 82 lines · Rafael J. Wysocki
Quoted 81 lines · Rafael J. Wysocki
Quoted 65 lines · Dmitry Torokhov
Quoted 52 lines · Rafael J. Wysocki
Quoted 3 lines · Dmitry Torokhov
Quoted 2 lines · Alan Stern
Quoted 1 line · Patrik Fimml
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
Quoted 31 lines
Quoted 13 lines
Quoted 13 lines
I'm not sure what the appropriate action for a video camera is anyway.
Should it go away completely, including its device? Should it be there,
but certainly not be the default choice when there is an external
camera? I'm thinking along the lines of some application's settings
dialog here, where it might be desirable to still be able to select
the
internal camera for future recordings.Quoted 7 lines
Quoted 2 lines
Of course, userspace could still decide simply not to quiesce|deactivate|inhibit the device if that was desired.
There's some question about how much of userspace needs to get involved. Just the daemon that manages these configuration changes, or
other programs as well? I guess that's not really our problem...We need to provide means of implementing policy; the policy itself is not
really our concern ;)Quoted 5 lines
In the end, it sounds like you're suggesting a new pair of PM
callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and ->uninhibit(). Plus an optional (?) sysfs interface for invoking the
callbacks.Quoted 10 lines
We do need sysfs interface so that userspace can talk to the devices in
question; and we also need to make sure that PM core is aware of the new
callbacks and provides guarantees about their interactions with system-
and
runtime-PM callbacks so that individual drivers do not have to sort it out
on their own.A step back, please.
I have no idea why those need to be PM callbacks.
Quoted 11 lines
What you need really seems to be a way to tell a driver "ignore input from
this device from now on as it is most likely bogus". A natural reaction of
the driver to that might be to stop processing input from the device and
then runtime suspend it (and prevent it from generating remote wakeup as
that may be bogus as well), but I don't see why the PM core needs to be
involved in that at all.Quoted 6 lines
So that we do not need to handle cases like:
- I am already in idle state and request comes to inhibit, what do I do (in
driver) or:
I'm not sure why being "suspended" or not matters here. The PM core doesn't know what physical state the device is in anyway and the driver or subsystem (or another layer such as ACPI) has to track that.
Also it seems that it should be perfectly fine to ignore input from the device without suspending it as well as it is perfectly fine to be suspended while you are generally not ignoring the input (just because there is no input at the moment, for example).
Quoted 8 lines
Quoted 3 lines
Yes, it make sense to suspend the device when you know you'll ignore input going forward, but then if the real goal is to prevent bogus input from reaching applications, then this isn't a power management problem even.
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 source.
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.
Considering input devices:
Quoted 7 lines
input_open(): check if device is inhibited, if so do nothing. Otherwise try waking up itself and parent (viapm_runtime_get_sync()on itself), this will power up the device. Do additional configuration if needed.
input_close(): check if device is inhibited, if not dopm_runtime_put(_sync? to make sure we power off properly and not leave device up and running? or should we power down manually not waiting for runtime PM)?
pm_runtime_put_sync() should be sufficient here I think.
Quoted 8 lines
inhibit(): check if device is opened, if opened dopm_runtime_put_sync().
uninhibit(): if device is opened dopm_runtime_get_sync(), let runtime PM bring up the device. Do additional config if needed -> very similar toinput_open(), different condition.
runtime_suspend(): power down the device. If not inhibited enable as wakeup source.
User space may not want it to be a wakeup source even if not inhibited (it may not want it to wake up from system suspend, for example, like I do with my cordless mouse).
Quoted 4 lines
runtime_resume(): power up the device if device is opened and not inhibited.
system_suspend(): check if device is opened, not inhibited and not in runtimesuspend already; power down.
I think you only need to know if the device has been powered down already here regardless of the reason.
Quoted 5 lines
system_resume(): power up the device if it is opened and not inhibited. I guess it's OK to wake up device that shoudl be runtime-PM-idle since it will go to back sleep shortly.Ugh.. This is complicated...
If runtime PM and system suspend shared the status, we might simplify this somewhat. Problem is, there are drivers that don't support runtime PM, but support system suspend.
Rafael
Quoted 6 lines · Dmitry Torokhov
Quoted 4 lines
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 source.
I'd say no.
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?
Alan Stern
Quoted 7 lines · Alan Stern
Quoted 5 lines · Dmitry Torokhov
Quoted 4 lines
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 source.
Quoted 5 lines
Quoted 1 line
I'd say no.
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, whether power/wakeup is set to enabled for those devices or not. However, I'd say that there's only one policy that makes sense in that case : wakeups should be disabled while suspended.
If we inhibited the device during runtime to prevent stray input events from being generated, it wouldn't make sense to allow the device to potentially generate an accidental wakeup while suspended.
Quoted 4 lines · Benson Leung
Quoted 3 lines
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?
Quoted 8 lines
It's possible that this could be a policy decision, ie, whether power/wakeup is set to enabled for those devices or not. However, I'd say that there's only one policy that makes sense in that case : wakeups should be disabled while suspended.
If we inhibited the device during runtime to prevent stray input events from being generated, it wouldn't make sense to allow the device to potentially generate an accidental wakeup while suspended.
That doesn't really make sense. If you're afraid of a device generating spurious wakeup events when the lid is closed, you should never enable it for wakeup. After all, one of the first things that people often do after suspending their laptop is close the lid.
Alan Stern
Quoted 10 lines · Alan Stern
Quoted 9 lines · Benson Leung
Quoted 3 lines
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, whether power/wakeup is set to enabled for those devices or not. However, I'd say that there's only one policy that makes sense in that case : wakeups should be disabled while suspended.
Quoted 8 lines
Quoted 3 lines
If we inhibited the device during runtime to prevent stray input events from being generated, it wouldn't make sense to allow the device to potentially generate an accidental wakeup while suspended.
That doesn't really make sense. If you're afraid of a device generating spurious wakeup events when the lid is closed, you should never enable it for wakeup. After all, one of the first things that people often do after suspending their laptop is close the lid.
That's a fair point, and I think should be done by default. But that does not change what Benson said - I think if we inhibited the device it should stay inhibited across system suspend, including being disabled as wakeup source even if it could be enabled as such.
Thanks,
Dmitry
Quoted 20 lines · Dmitry Torokhov
Quoted 10 lines · Alan Stern
Quoted 9 lines · Benson Leung
Quoted 3 lines
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, whether power/wakeup is set to enabled for those devices or not. However, I'd say that there's only one policy that makes sense in that case : wakeups should be disabled while suspended.
Quoted 8 lines
Quoted 3 lines
If we inhibited the device during runtime to prevent stray input events from being generated, it wouldn't make sense to allow the device to potentially generate an accidental wakeup while suspended.
That doesn't really make sense. If you're afraid of a device generating spurious wakeup events when the lid is closed, you should never enable it for wakeup. After all, one of the first things that people often do after suspending their laptop is close the lid.
Quoted 4 lines
That's a fair point, and I think should be done by default. But that does not change what Benson said - I think if we inhibited the device it should stay inhibited across system suspend, including being disabled as wakeup source even if it could be enabled as such.
This seems to be the best approach to me too.
Rafael
On 2014-07-19 01:16, Dmitry Torokhov wrote:
<snip>
Quoted 27 lines
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.
Considering input devices:
input_open(): check if device is inhibited, if so do nothing. Otherwise try waking up itself and parent (viapm_runtime_get_sync()on itself), this will power up the device. Do additional configuration if needed.
input_close(): check if device is inhibited, if not dopm_runtime_put(_sync? to make sure we power off properly and not leave device up and running? or should we power down manually not waiting for runtime PM)?
inhibit(): check if device is opened, if opened dopm_runtime_put_sync().
uninhibit(): if device is opened dopm_runtime_get_sync(), let runtime PM bring up the device. Do additional config if needed -> very similar toinput_open(), different condition.
runtime_suspend(): power down the device. If not inhibited enable as wakeup source.
runtime_resume(): power up the device if device is opened and not inhibited.
Quoted 8 lines
system_suspend(): check if device is opened, not inhibited and not in runtimesuspend already; power down.
system_resume(): power up the device if it is opened and not inhibited. I guess it's OK to wake up device that shoudl be runtime-PM-idle since it will go to back sleep shortly.Ugh.. This is complicated...
Seriously complicated. The compositor and/or X.org can handle most of that for input devices already. For the camera, you want the application to know that the device is present, but not usable, instead of making it vanish or rendering it unusable. And if you wanted to implement this in the kernel, even with the aid of a user-space daemon, you're still missing the most important part, the device tagging.
Once you've tagged the devices which would need to be left alone when the lid is closed, or the laptop is in tablet mode, see if the problem can be solved within user-space alone. I'm fairly certain it wouldn't take too long to fix Xorg or a state-of-the-art compositor to behave properly.
All I see right now is making it harder to write devices drivers with no real benefits.
Cheers
(Note: Your email arrived here with lines wrapped in a hard-to-read way, not sure where the problem lies.)
Quoted 51 lines · On Tue, Jul 22, 2014 at 01:23:14AM +0200, [email protected] wrote:
On 2014-07-19 01:16, Dmitry Torokhov wrote:
<snip>Quoted 41 lines
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.Considering input devices:
input_open(): check if device is inhibited, if so do nothing. Otherwise try
waking up itself and parent (viapm_runtime_get_sync()on itself), this will
power up the device. Do additional configuration if needed.
input_close(): check if device is inhibited, if not dopm_runtime_put(_sync?
to make sure we power off properly and not leave device up and running? or
should we power down manually not waiting for runtime PM)?
inhibit(): check if device is opened, if opened dopm_runtime_put_sync().
uninhibit(): if device is opened dopm_runtime_get_sync(), let runtime PM
bring up the device. Do additional config if needed -> very similar toinput_open(), different condition.
runtime_suspend(): power down the device. If not inhibited enable as wakeup
source.
runtime_resume(): power up the device if device is opened and not inhibited.
system_suspend(): check if device is opened, not inhibited and not in runtimesuspend already; power down.Quoted 7 lines
system_resume(): power up the device if it is opened and not inhibited. I
guess it's OK to wake up device that shoudl be runtime-PM-idle since it will
go to back sleep shortly.Ugh.. This is complicated...
Quoted 11 lines
Seriously complicated. The compositor and/or X.org can handle most of that for
input devices already. For the camera, you want the application to know that
the device is present, but not usable, instead of making it vanish or rendering
it unusable. And if you wanted to implement this in the kernel, even with the aid
of a user-space daemon, you're still missing the most important part, the device
tagging.
I agree that the behaviour for e.g. the camera is debatable. Our primary concern is input devices for now, but we were trying to see whether such a functionality might be desired for other device classes as well.
Quoted 7 lines
Once you've tagged the devices which would need to be left alone when the lid is
closed, or the laptop is in tablet mode, see if the problem can be solved within
user-space alone. I'm fairly certain it wouldn't take too long to fix Xorg
or a state-of-the-art compositor to behave properly.
This would not allow you to power down the touchscreen more than to a "idle" state without further modifications to drivers.
We also want to make sure that the kernel ignores input from these devices for S3 suspend, so that stray touch inputs do not abort a suspend that is about to happen.
And also, I think Xorg is not necessarily the proper layer for this. It's a bit theoretical, but: If there were other users of the input device, they would also want to ignore the events.
Quoted 2 lines
All I see right now is making it harder to write devices drivers with no real benefits.
I don't see this problem at all. Just like drivers don't have to implement runtime PM, they wouldn't be required to implement inhibit() and its counterpart. But if they do implement such functionality, we give them a standard interface to expose it.
If we stick with the example of input devices, we can even have a simple default implementation in the device class (skipping any generated events) and bring the basic behaviour to unmodified drivers for free.
Even if you did not have the "inhibit" interface, if you wanted to power down the touchscreen completely when it's not accessible, this would require very similar driver modifications.
Regards,
Patrik
Quoted 26 lines · Dmitry Torokhov
[...]
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.Considering input devices:
input_open(): check if device is inhibited, if so do nothing. Otherwise try waking up itself and parent (viapm_runtime_get_sync()on itself), this will power up the device. Do additional configuration if needed.
input_close(): check if device is inhibited, if not dopm_runtime_put(_sync? to make sure we power off properly and not leave device up and running? or should we power down manually not waiting for runtime PM)?
inhibit(): check if device is opened, if opened dopm_runtime_put_sync().
uninhibit(): if device is opened dopm_runtime_get_sync(), let runtime PM bring up the device. Do additional config if needed -> very similar toinput_open(), different condition.
runtime_suspend(): power down the device. If not inhibited enable as wakeup source.
runtime_resume(): power up the device if device is opened and not inhibited.
Quoted 8 lines
system_suspend(): check if device is opened, not inhibited and not in runtimesuspend already; power down.
system_resume(): power up the device if it is opened and not inhibited. I guess it's OK to wake up device that shoudl be runtime-PM-idle since it will go to back sleep shortly.Ugh.. This is complicated...
There might be more elegant ways to implement this. It might make sense to factor out power transitions. One could have a function that derives the appropriate power state given the circumstances (i.e. suspend/inhibit/runtime suspend) and then performs the needed transition. This is something one would have to see when actually implementing this, I might experiment with this approach a bit.
Regards,
Patrik
Quoted 10 lines · Rafael J. Wysocki
Quoted 5 lines · Bastien Nocera
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 closed. Switching to external webcam, a webcam on the outside of the case, or switch off the video stream would then be the expected behaviour.
Well, is the scenario I described correct or not? If not, then what exactly is the scenario you want to be able to handle?
Well, I think you need to add that you want user space to tell the kernel that devices should not do remote wakeup under some conditions. And I think this should not be limited to lid closure. And thus it does not belong into the kernel.
A good example would be mice. From the kernel side runtime power management works just fine. In practice it is rarely usable because remote wakeup doesn't work well enough in common mice. It would be good enough if the screen saver were working.
So I think lacking is the ability to model that remote wakeup capabilities are
- dependent on external events
- binary capable or incapable
And we might introduce a system similar to rfkill that tells devices that they are useless and hence idle due to external factors (the internal webcam, keyboard, touchscreen ...)
Putting this into user space is difficult because you cannot really fully close a keyboard.
Regards
Oliver
Quoted 8 lines · Rafael J. Wysocki
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 and you want some of those devices, but possibly not all of them, to quiesce themselves and go into low-power states.
Is that correct?
Yes, that is accurate.
The primary example is a laptop with an external monitor and mouse attached which you're using with the lid closed. You want the mouse to work, but input from the touchpad that might result from the lid being close to it should be skipped. Also, the touchpad should enter a low-power state.
We think that triggering this is probably best done in userspace, but we would need a way of telling devices to quiesce themselves.
And as Oliver has pointed out, it might be desirable to preserve some state/settings of devices. And it's probably undesirable to go through the whole process of completely unregistering the device and then probing/resetting/configuring it again.
Kind regards,
Patrik