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
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 going to a te
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
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 going to a te
29 matches
Mail list logo
