I tried /dev/input/mice earlier, but it didn't recover from
disconnect/connect either. But I've just seen your May 2 patch and
will try that now.
What's causing the timeout messages issued by uhci-hub-debug? That
doesn't seem right.
Lincoln
Vojtech Pavlik writes:
> On Sun, May 07, 2000 at 07:14:59PM -0700, Dunlap, Randy wrote:
>
> > > The subject line says it all. When I suspend/resume with a USB
> > > mouse, the mouse device gets detached from /dev/input/mouse0 and
> > > reattached to /dev/input/mouse1. Needless to say, this confuses X
> > > tremendously.
> >
> > This seems to say to me that the input module isn't told about
> > the disconnect (from the suspend), so the resume (=> connect)
> > allocates another input/mouseN.
>
> The problem is that the driver doesn't know the mouse that it sees
> connecting is the same mouse that was disconnected, and the mouse0
> device is still busy (open by X), so it has to allocate a new device
> that is not busy - mouse1. The disconnect is handled correctly.
>
> I'd suggest using the 'mice' device in this case, until X can handle
> disconnects, too.
>
> > > I'm using standard APM. Oddly enough, the old development USB driver
> > > in the 2.2.14 kernel worked quite well across suspend/resume. I got
> > > greedy and wanted to use the scroll wheel in the intellimouse!
> >
> > Is use of the scroll wheel documented somewhere?
>
> I don't think so, you just set the protocol to IMPS/2 and the wheel
> should work.
>
> --
> Vojtech Pavlik
> SuSE Labs
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
========================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
