On Thu, Feb 01, 2007 at 11:59:43AM -0500, Alan Stern wrote:
> > > We should write sysfs_add_to_group(), so that these two
> > > attributes can be added to the existing device/power
> > > subdirectory. (sysfs_remove_from_group() doesn't seem to
> > > be needed, but it could be written as we
Greg, see below...
On Thu, 1 Feb 2007, Oliver Neukum wrote:
> Am Donnerstag, 1. Februar 2007 15:51 schrieb Alan Stern:
> > On Wed, 31 Jan 2007, Oliver Neukum wrote:
> >
> > > This would call mod_timer() for every completed in-URB. Are you
> > > sure this is better than an approach maintaining a
Hi!
> > > > You should have /proc/acpi/battery/*/state ; it shows current power
> > > > consumption.
> > >
> > > Yes, that works. Cool :-)
> >
> > Good... so how much power is it saving for you?
>
> Nothing USB:
> present rate:1874 mA
>
> Mouse in use:
> present rate:20
Hi1
> > Measurements on x60:
>
> What strange architectures is that?
It is thinkpad x60. i386 architecture.
> > Feb 1 15:58:14 amd kernel: Added idle timer for firing in 10 seconds
> > ^[ Feb 1 15:58:24 amd kernel: state is 0
> > Feb 1 15:58:24 amd kernel: Modded idle timer for firing in 10
Am Donnerstag, 1. Februar 2007 15:51 schrieb Alan Stern:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > This would call mod_timer() for every completed in-URB. Are you
> > sure this is better than an approach maintaining a periodical timer
> > and check for IO in the meantime?
>
> I think we c
Am Donnerstag, 1. Februar 2007 15:43 schrieb Pavel Machek:
> Hi!
>
> > > You should have /proc/acpi/battery/*/state ; it shows current power
> > > consumption.
> >
> > Yes, that works. Cool :-)
>
> Good... so how much power is it saving for you?
>
Am Donnerstag, 1. Februar 2007 16:03 schrieb Pavel Machek:
> Measurements on x60:
What strange architectures is that?
[..]
> When I actually use the mouse
>
> Feb 1 15:58:14 amd kernel: Added idle timer for firing in 10 seconds
> ^[ Feb 1 15:58:24 amd kernel: state is 0
> Feb 1 15:58:24 amd
Hi!
>
> this preliminary patch should suspend your mouse, if it supports remote
> wakeup. In fact it should do this to all devices which are HID, claimed by
> the input layer and support remote wakeup.
>
> It works for me with my mouse. I've tested letting it autosuspend and
> resume. It survives
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> This would call mod_timer() for every completed in-URB. Are you
> sure this is better than an approach maintaining a periodical timer
> and check for IO in the meantime?
I think we can have it both ways. Add an atomic bitflag to the usb_device
structur
On Wed 2007-01-31 16:54:39, Alan Stern wrote:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > > timer whenever there is any activity, and when the timer expires you know
> > > the device has been idle long enough that you should suspend it. That's
> > > exactly how the autosuspend infrastructur
Hi!
> > You should have /proc/acpi/battery/*/state ; it shows current power
> > consumption.
>
> Yes, that works. Cool :-)
Good... so how much power is it saving for you?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(
02/01/2007 11:22 AM, Oliver Neukum wrote/a écrit:
> Am Donnerstag, 1. Februar 2007 11:09 schrieb Eric Piel:
>
>> Hi,
>>
>> I can report success for my mouse automatically turning off (and waking
>> up when I click). However I wonder how good it is in a pure user
>> interface view: suddenly the m
Am Donnerstag, 1. Februar 2007 11:09 schrieb Eric Piel:
> Hi,
>
> I can report success for my mouse automatically turning off (and waking
> up when I click). However I wonder how good it is in a pure user
> interface view: suddenly the mouse turns off. That needs to be more
> configurable and
01/31/2007 04:56 PM, Oliver Neukum wrote/a écrit:
> Hi,
>
> this preliminary patch should suspend your mouse, if it supports remote
> wakeup. In fact it should do this to all devices which are HID, claimed by
> the input layer and support remote wakeup.
>
> It works for me with my mouse. I've tes
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> > timer whenever there is any activity, and when the timer expires you know
> > the device has been idle long enough that you should suspend it. That's
> > exactly how the autosuspend infrastructure works.
>
> This would call mod_timer() for every comp
Am Mittwoch, 31. Januar 2007 20:25 schrieb Alan Stern:
> > How do I find out whether the device is idle?
> > The mouse is not idle if it has been moved (or buttons clicked)
> > To find out whether it has been moved the device must not be suspended.
> > At which point in time then should I check? Ar
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> > > Furthermore that work should be queued only if pm_usage_cnt==0,
> > > which cannot be allowed if the device isn't idle.
> >
> > Isn't that what you want? Surely you aren't trying to start an
> > autosuspend timer while the device is busy?
>
> How
Am Mittwoch, 31. Januar 2007 17:44 schrieb Pavel Machek:
> You should have /proc/acpi/battery/*/state ; it shows current power
> consumption.
Yes, that works. Cool :-)
Regards
Oliver
-
Take Surveys. E
Am Mittwoch, 31. Januar 2007 17:55 schrieb Jiri Kosina:
> A first example that comes to mind - suppose that you have two keyboards,
> at least one of them being HID. Now when the timer expires, the HID
> keyboard will be suspended. Then when you hit a capslock/numlock/...
> (basically anything c
Am Mittwoch, 31. Januar 2007 18:07 schrieb Alan Stern:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > Am Mittwoch, 31. Januar 2007 17:11 schrieb Alan Stern:
> >
> > > This looks more complicated than it should be. In particular, the
> > > addition of a new "idle" timer should not be needed.
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> Am Mittwoch, 31. Januar 2007 17:11 schrieb Alan Stern:
>
> > This looks more complicated than it should be. In particular, the
> > addition of a new "idle" timer should not be needed.
> >
> > We already have an autosuspend timer: the one embedded in
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> In fact it should do this to all devices which are HID, claimed by the
> input layer and support remote wakeup.
>From a quick look, in addition to Alan's comments, it seems to me that you
don't handle a case in which the hid driver decides to send an
Hi!
> this preliminary patch should suspend your mouse, if it supports remote
> wakeup. In fact it should do this to all devices which are HID, claimed by
> the input layer and support remote wakeup.
>
> It works for me with my mouse. I've tested letting it autosuspend and
> resume. It survives g
Am Mittwoch, 31. Januar 2007 17:11 schrieb Alan Stern:
> This looks more complicated than it should be. In particular, the
> addition of a new "idle" timer should not be needed.
>
> We already have an autosuspend timer: the one embedded in the autosuspend
> delayed_work struct inside struct usb
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> Hi,
>
> this preliminary patch should suspend your mouse, if it supports remote
> wakeup. In fact it should do this to all devices which are HID, claimed by
> the input layer and support remote wakeup.
>
> It works for me with my mouse. I've tested let
Am Mittwoch, 31. Januar 2007 16:47 schrieb Jiri Kosina:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > this preliminary patch should suspend your mouse, if it supports remote
> > wakeup. In fact it should do this to all devices which are HID, claimed
> > by the input layer and support remote
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> this preliminary patch should suspend your mouse, if it supports remote
> wakeup. In fact it should do this to all devices which are HID, claimed
> by the input layer and support remote wakeup.
Thanks for the patch; you probably made some trivial mist
27 matches
Mail list logo
