Re: Power-managing devices that are not of interest at some point in time
On Fri, Jul 18, 2014 at 04:16:50PM -0700, Dmitry Torokhov wrote: > [...] > Anyway, even though it is very tempting to declare inhibit a "deeper" state > of > runtime suspend maybe you are right and inhibit should really be separate > from > PM and drivers would have to sort out all the possible state 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... 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power-managing devices that are not of interest at some point in time
(Note: Your email arrived here with lines wrapped in a hard-to-read way, not sure where the problem lies.) On Tue, Jul 22, 2014 at 01:23:14AM +0200, had...@hadess.net wrote: > On 2014-07-19 01:16, Dmitry Torokhov wrote: > > >I'd say no. > > > >Anyway, even though it is very tempting to declare 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... > > 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. > 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power-managing devices that are not of interest at some point in time
(Note: Your email arrived here with lines wrapped in a hard-to-read way, not sure where the problem lies.) On Tue, Jul 22, 2014 at 01:23:14AM +0200, had...@hadess.net wrote: On 2014-07-19 01:16, Dmitry Torokhov wrote: snip I'd say no. Anyway, even though it is very tempting to declare 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... 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. 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. 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power-managing devices that are not of interest at some point in time
On Fri, Jul 18, 2014 at 04:16:50PM -0700, Dmitry Torokhov wrote: [...] Anyway, even though it is very tempting to declare inhibit a deeper state of runtime suspend maybe you are right and inhibit should really be separate from PM and drivers would have to sort out all the possible state 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... 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power-managing devices that are not of interest at some point in time
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> "Quiescing" is the wrong word. "Quiescing a device" means stopping the
> device from doing anything, which isn't what you want. You want to
> ignore any activity the device may generate and reduce the device's
> power consumption as much as 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.
> 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.
> 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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Power-managing devices that are not of interest at some point in time
On Fri, Jul 18, 2014 at 02:43:02AM +0200, Rafael J. Wysocki wrote: > From past discussions on similar topics it followed that there really was > no generic way for individual drivers to quiesce devices on demand as long as > user space was running. Everything we could come up with was racy, this way > 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? > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power-managing devices that are not of interest at some point in time
On Fri, Jul 18, 2014 at 02:43:02AM +0200, Rafael J. Wysocki wrote: From past discussions on similar topics it followed that there really was no generic way for individual drivers to quiesce devices on demand as long as user space was running. Everything we could come up with was racy, this way 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? 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. 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power-managing devices that are not of interest at some point in time
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote: Quiescing is the wrong word. Quiescing a device means stopping the device from doing anything, which isn't what you want. You want to ignore any activity the device may generate and reduce the device's power consumption as much as 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. 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. 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. 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power-managing devices that are not of interest at some point in time
On Thu, Jul 17, 2014 at 01:11:31AM +0200, Rafael J. Wysocki wrote: > Let me try to understand the scenario in the first place. > > To start with, a number of devices is in use (that is, open, there are > applications listening/talking to them etc). Now, an event happens, such > as a laptop lid close 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power-managing devices that are not of interest at some point in time
On Thu, Jul 17, 2014 at 01:11:31AM +0200, Rafael J. Wysocki wrote: Let me try to understand the scenario in the first place. To start with, a number of devices is in use (that is, open, there are applications listening/talking to them etc). Now, an event happens, such as a laptop lid close 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/14] input: cyapa: re-architecture driver to support multi-trackpads in one driver
Hi Dudley, On Mon, Jun 30, 2014 at 05:43:06AM +, Dudley Du wrote: > Attached are the patches files, I sent it firstly. Thanks for the response, I was able to apply the patches now. The attached files lack headers and commit messages though, so I don't have fine-grained history in my git tree for convenient later review. The file names suggest to me that you might just have copy-and-pasted the patches from somewhere. It would be great if you could attach them again in the format produced by "git format-patch", with no further modifications done by hand. (If you feel the need to do modifications, you should modify the actual commits e.g. with "git rebase -i" before using format-patch.) Others can then simply import your changes - including commit messages - into their tree with "git am". Thanks, Patrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/14] input: cyapa: re-architecture driver to support multi-trackpads in one driver
Hi Dudley, On Mon, Jun 30, 2014 at 05:43:06AM +, Dudley Du wrote: Attached are the patches files, I sent it firstly. Thanks for the response, I was able to apply the patches now. The attached files lack headers and commit messages though, so I don't have fine-grained history in my git tree for convenient later review. The file names suggest to me that you might just have copy-and-pasted the patches from somewhere. It would be great if you could attach them again in the format produced by git format-patch, with no further modifications done by hand. (If you feel the need to do modifications, you should modify the actual commits e.g. with git rebase -i before using format-patch.) Others can then simply import your changes - including commit messages - into their tree with git am. Thanks, Patrik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/14] input: cyapa: re-architecture driver to support multi-trackpads in one driver
Hi Dudley, I tried to apply your patchset today, but was not successful: it seems like tabs have been replaced by spaces, and there's a Cypress signature and a winmail.dat file added to every email, making it impossible to apply your patches directly. I've tried to rule out errors on my end. I checked with http://marc.info/?l=linux-input=140203994303131=raw that the original email indeed has all tabs replaced with spaces. Can you fix your email setup so that these things don't happen - there is some documentation in Documentation/SubmittingPatches and Documentation/email-clients.txt - and send the patches again? Alternatively, maybe you could at least send the patches as attachments (as output by git format-patch), so that your email system doesn't mess with them. That's probably not the preferred solution for the general lkml audience, but would work as a short-term solution for me. If I'm mistaken here and someone else was able to apply the patches successfully, please point me in the right direction. Thanks, Patrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/14] input: cyapa: re-architecture driver to support multi-trackpads in one driver
Hi Dudley, I tried to apply your patchset today, but was not successful: it seems like tabs have been replaced by spaces, and there's a Cypress signature and a winmail.dat file added to every email, making it impossible to apply your patches directly. I've tried to rule out errors on my end. I checked with http://marc.info/?l=linux-inputm=140203994303131q=raw that the original email indeed has all tabs replaced with spaces. Can you fix your email setup so that these things don't happen - there is some documentation in Documentation/SubmittingPatches and Documentation/email-clients.txt - and send the patches again? Alternatively, maybe you could at least send the patches as attachments (as output by git format-patch), so that your email system doesn't mess with them. That's probably not the preferred solution for the general lkml audience, but would work as a short-term solution for me. If I'm mistaken here and someone else was able to apply the patches successfully, please point me in the right direction. Thanks, Patrik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
