On Fri, 20 Oct 2006, Oliver Neukum wrote:
> > Regardless, it would be good if we could get some hard(er) facts on
> > this. Oliver, maybe you could boil this down to some test that any
> > idiot penguin could run.
>
> Yes, I'll implement forced suspend. I am rewriting the patch. It's stupid
> to
Am Donnerstag, 19. Oktober 2006 23:03 schrieb David Brownell:
> On Sunday 15 October 2006 8:54 pm, Dmitry Torokhov wrote:
> >
> > > For what it's worth it sort of works now, however testing with an
> > > MS Intellimouse Explorer I found that I really needed to use a button
> > > to wake it up.
>
On Tuesday 17 October 2006 2:21 pm, Dmitry Torokhov wrote:
> > One approach would be to add a function callback pointer to the input
> > device structure for autosuspend requests. The transport layer would then
> > be responsible for handling these callbacks and carrying out the suspend.
>
> But
On Sunday 15 October 2006 8:54 pm, Dmitry Torokhov wrote:
>
> > For what it's worth it sort of works now, however testing with an
> > MS Intellimouse Explorer I found that I really needed to use a button
> > to wake it up.
>
> I am afraid that this is a showstopper... While it is accepted that b
On Monday 16 October 2006 8:04 am, Alan Stern wrote:
> > > > Do you have mice that do not require button push to wake up?
> > >
> > > It doesn't matter. The mouse descriptors don't specify whether motion is
> > > a wakeup event, so we have to assume that any mouse will send a wakeup
> > > requ
On 10/16/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Oct 2006, Dmitry Torokhov wrote:
>
> > I don't agree. I think that power management should be left to drivers
> > working with hardware and not be placed into input core. There will be
> > different rules and different decisions, based
On Mon, 16 Oct 2006, Dmitry Torokhov wrote:
> I don't agree. I think that power management should be left to drivers
> working with hardware and not be placed into input core. There will be
> different rules and different decisions, based on the type of device
> (USB, PS/2, serial, etc, etc). Inpu
On 10/16/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Oct 2006, Oliver Neukum wrote:
>
> > Am Montag, 16. Oktober 2006 16:34 schrieb Alan Stern:
> > > This intricate strategy points out a fact which should have been mentioned
> > > earlier. For HID devices that are registered with the inp
On Mon, 16 Oct 2006, Oliver Neukum wrote:
> Am Montag, 16. Oktober 2006 16:34 schrieb Alan Stern:
> > This intricate strategy points out a fact which should have been mentioned
> > earlier. For HID devices that are registered with the input core (is that
> > all of them?), autosuspend should no
Am Montag, 16. Oktober 2006 16:34 schrieb Alan Stern:
> This intricate strategy points out a fact which should have been mentioned
> earlier. For HID devices that are registered with the input core (is that
> all of them?), autosuspend should not be initiated by the USB core. It
> should be in
On Mon, 16 Oct 2006, Dmitry Torokhov wrote:
> On 10/16/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Montag, 16. Oktober 2006 05:54 schrieben Sie:
> > > > Both there's agreement in principle that PID devices should not be
> > > > subject
> > > > to autosuspend based on inactivity?
> > >
> >
Am Montag, 16. Oktober 2006 15:20 schrieb Dmitry Torokhov:
> On 10/16/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Montag, 16. Oktober 2006 05:54 schrieben Sie:
> > > > Both there's agreement in principle that PID devices should not be
> > > > subject
> > > > to autosuspend based on inactiv
On 10/16/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Montag, 16. Oktober 2006 05:54 schrieben Sie:
> > > Both there's agreement in principle that PID devices should not be subject
> > > to autosuspend based on inactivity?
> >
> > Hmm, why?
>
> It was my understanding that a PID effect is star
Am Montag, 16. Oktober 2006 05:54 schrieben Sie:
> > Both there's agreement in principle that PID devices should not be subject
> > to autosuspend based on inactivity?
>
> Hmm, why?
It was my understanding that a PID effect is started with a command
describing the effect and its duration. Thus hi
On Friday 13 October 2006 13:16, Oliver Neukum wrote:
> Am Freitag, 13. Oktober 2006 16:33 schrieb Alan Stern:
> > On Fri, 13 Oct 2006, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > I've got a version that basically works but it has some race conditions
> > > left. Right now I do autosuspend on
Am Freitag, 13. Oktober 2006 16:33 schrieb Alan Stern:
> On Fri, 13 Oct 2006, Oliver Neukum wrote:
>
> > Hi,
> >
> > I've got a version that basically works but it has some race conditions
> > left. Right now I do autosuspend on the following conditions:
> > 1. Bound to hid-input
> > 2. Not bound
On Fri, 13 Oct 2006, Oliver Neukum wrote:
> Hi,
>
> I've got a version that basically works but it has some race conditions
> left. Right now I do autosuspend on the following conditions:
> 1. Bound to hid-input
> 2. Not bound to hiddev
> 3. No interrupt out endpoints
>
> Is there a generic way
Hi,
I've got a version that basically works but it has some race conditions
left. Right now I do autosuspend on the following conditions:
1. Bound to hid-input
2. Not bound to hiddev
3. No interrupt out endpoints
Is there a generic way to test whether a device is a PID?
I still have to make sure
18 matches
Mail list logo
