I've only just recently tried running 2.6.24 on my main machine.
And it appears that I'll have to go back to 2.6.23,
because the USB mouse is not working correctly.
Single-clicking on things with 2.6.24 very frequently gives a "double-click".
This does not happen with 2.6.23.8.
I wonder what broke it?
I've grabbed mousedev.c from 2.6.23 and inserted that in place
of the updated 2.6.24 source, but no change. So it's not that file.
?????
Mark Lord wrote:
> I've only just recently tried running 2.6.24 on my main machine.
> And it appears that I'll have to go back to 2.6.23,
> because the USB mouse is not working correctly.
>
> Single-clicking on things with 2.6.24 very frequently gives a
> "double-click".
> This does not happen with 2.6.23.8.
>
> I wonder what broke it?
>
> I've grabbed mousedev.c from 2.6.23 and inserted that in place
> of the updated 2.6.24 source, but no change. So it's not that file.
...
Mmm.. reverting the entire drivers/hid directory to that from 2.6.23
seems to have fixed the problem, so we now know it's in there somewhere.
Jiri: do you have any suggestions that might be more specific than that ?
Thanks
Mark Lord wrote:
> Mark Lord wrote:
>> I've only just recently tried running 2.6.24 on my main machine.
>> And it appears that I'll have to go back to 2.6.23,
>> because the USB mouse is not working correctly.
>>
>> Single-clicking on things with 2.6.24 very frequently gives a
>> "double-click".
>> This does not happen with 2.6.23.8.
>>
>> I wonder what broke it?
>>
>> I've grabbed mousedev.c from 2.6.23 and inserted that in place
>> of the updated 2.6.24 source, but no change. So it's not that file.
> ...
>
> Mmm.. reverting the entire drivers/hid directory to that from 2.6.23
> seems to have fixed the problem, so we now know it's in there somewhere.
>
> Jiri: do you have any suggestions that might be more specific than that ?
..
Here's my USB mouse:
Bus 005 Device 004: ID 046d:c016 Logitech, Inc. M-UV69a Optical Wheel Mouse
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc016 M-UV69a Optical Wheel Mouse
bcdDevice 3.40
iManufacturer 1 Logitech
iProduct 2 Optical USB Mouse
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Devices
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 52
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)
On Sun, 02 Dec 2007 12:04:45 -0500
Mark Lord <[email protected]> wrote:
> Mark Lord wrote:
> > Mark Lord wrote:
> >> I've only just recently tried running 2.6.24 on my main machine.
> >> And it appears that I'll have to go back to 2.6.23,
> >> because the USB mouse is not working correctly.
> >>
> >> Single-clicking on things with 2.6.24 very frequently gives a
> >> "double-click".
> >> This does not happen with 2.6.23.8.
> >>
> >> I wonder what broke it?
> >>
> >> I've grabbed mousedev.c from 2.6.23 and inserted that in place
> >> of the updated 2.6.24 source, but no change. So it's not that
> >> file.
> > ...
> >
> > Mmm.. reverting the entire drivers/hid directory to that from 2.6.23
> > seems to have fixed the problem, so we now know it's in there
> > somewhere.
> >
just making sure.. this is while running an untainted kernel without
something like vmware loaded, right?
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
Arjan van de Ven wrote:
> On Sun, 02 Dec 2007 12:04:45 -0500
> Mark Lord <[email protected]> wrote:
>
>> Mark Lord wrote:
>>> Mark Lord wrote:
>>>> I've only just recently tried running 2.6.24 on my main machine.
>>>> And it appears that I'll have to go back to 2.6.23,
>>>> because the USB mouse is not working correctly.
>>>>
>>>> Single-clicking on things with 2.6.24 very frequently gives a
>>>> "double-click".
>>>> This does not happen with 2.6.23.8.
>>>>
>>>> I wonder what broke it?
>>>>
>>>> I've grabbed mousedev.c from 2.6.23 and inserted that in place
>>>> of the updated 2.6.24 source, but no change. So it's not that
>>>> file.
>>> ...
>>>
>>> Mmm.. reverting the entire drivers/hid directory to that from 2.6.23
>>> seems to have fixed the problem, so we now know it's in there
>>> somewhere.
>>>
>
>
> just making sure.. this is while running an untainted kernel without
> something like vmware loaded, right?
..
Absolutely.
But thanks for reminding me.. I need to re-run vmware-config.pl now.
Mark Lord wrote:
> Mark Lord wrote:
>> Mark Lord wrote:
>>> I've only just recently tried running 2.6.24 on my main machine.
>>> And it appears that I'll have to go back to 2.6.23,
>>> because the USB mouse is not working correctly.
>>>
>>> Single-clicking on things with 2.6.24 very frequently gives a
>>> "double-click".
>>> This does not happen with 2.6.23.8.
>>>
>>> I wonder what broke it?
>>>
>>> I've grabbed mousedev.c from 2.6.23 and inserted that in place
>>> of the updated 2.6.24 source, but no change. So it's not that file.
>> ...
>>
>> Mmm.. reverting the entire drivers/hid directory to that from 2.6.23
>> seems to have fixed the problem, so we now know it's in there somewhere.
>>
>> Jiri: do you have any suggestions that might be more specific than that ?
> ..
>
> Here's my USB mouse:
>
>
> Bus 005 Device 004: ID 046d:c016 Logitech, Inc. M-UV69a Optical Wheel Mouse
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 8
> idVendor 0x046d Logitech, Inc.
> idProduct 0xc016 M-UV69a Optical Wheel Mouse
> bcdDevice 3.40
> iManufacturer 1 Logitech
> iProduct 2 Optical USB Mouse
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 34
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xa0
> (Bus Powered)
> Remote Wakeup
> MaxPower 100mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 3 Human Interface Devices
> bInterfaceSubClass 1 Boot Interface Subclass
> bInterfaceProtocol 2 Mouse
> iInterface 0
> HID Device Descriptor:
> bLength 9
> bDescriptorType 33
> bcdHID 1.10
> bCountryCode 0 Not supported
> bNumDescriptors 1
> bDescriptorType 34 Report
> wDescriptorLength 52
> Report Descriptors:
> ** UNAVAILABLE **
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0004 1x 4 bytes
> bInterval 10
> Device Status: 0x0000
> (Bus Powered)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
My USB mouse recently started giving me phantom scrolls (movements of
the mouse wheel, even I made sure the wheel was in a resting position)
in recently kernels. It happened too infrequently for me to care.
Bus 001 Device 004: ID 045e:0047 Microsoft Corp. IntelliMouse Explorer 3.0
My USB keyboard also occasionally loses all contact with the number pad.
Other keys continue to work as expected. Unplug/replug sometimes
helps. Reboot /always/ fixes the issue.
Bus 001 Device 005: ID 045e:000b Microsoft Corp. Natural Keyboard Elite
USB HID is a fun place to be.
Whee...
Jeff
Am Sonntag, 2. Dezember 2007 17:21:32 schrieb Mark Lord:
> I've grabbed mousedev.c from 2.6.23 and inserted that in place
> of the updated 2.6.24 source, but no change. ?So it's not that file.
Are you really using mousedev and not true hid?
Do you see any other malfunction?
Regards
Oliver
On Sun, 2 Dec 2007, Mark Lord wrote:
> > Single-clicking on things with 2.6.24 very frequently gives a
> > "double-click". This does not happen with 2.6.23.8. I wonder what
> > broke it? I've grabbed mousedev.c from 2.6.23 and inserted that in
> > place of the updated 2.6.24 source, but no change. So it's not that
> > file.
> Mmm.. reverting the entire drivers/hid directory to that from 2.6.23
> seems to have fixed the problem, so we now know it's in there somewhere.
> Jiri: do you have any suggestions that might be more specific than that ?
Could you please run evtest on the mouse device and send me what is
reported when these false double-clicks happen? Also providing debug
output of usbhid might or might not be helpful (*)
There were not that many changes in USB HID apart from adding per-device
quirks for specific broken devices. Could you please try reverting
c01d50d18, 933e3187, 82eb1219 to see if any of them makes this go away?
(*) this means compiling with CONFIG_HID_DEBUG and modprobing hid module
with 'debug=1'.
Thanks,
--
Jiri Kosina
On Sun, 2 Dec 2007, Jeff Garzik wrote:
> My USB mouse recently started giving me phantom scrolls (movements of
> the mouse wheel, even I made sure the wheel was in a resting position)
> in recently kernels. It happened too infrequently for me to care.
Did this also start in 2.6.24, as in Mark's case?
> USB HID is a fun place to be.
Yes, especially with tons of USB HID devices violating the specs in many
creative ways :(
Thanks,
--
Jiri Kosina
Jiri Kosina wrote:
> On Sun, 2 Dec 2007, Mark Lord wrote:
>
>>> Single-clicking on things with 2.6.24 very frequently gives a
>>> "double-click". This does not happen with 2.6.23.8. I wonder what
>>> broke it? I've grabbed mousedev.c from 2.6.23 and inserted that in
>>> place of the updated 2.6.24 source, but no change. So it's not that
>>> file.
>> Mmm.. reverting the entire drivers/hid directory to that from 2.6.23
>> seems to have fixed the problem, so we now know it's in there somewhere.
...
Mmmm.. an update here:
Reverting the drivers/hid directory does seem to improve behaviour.
But right now I have a "make -j4" happening in the background
and the mouse is ever so erratic again, despite the drivers/hid reversion.
So it's a timing thing, somewhere.
Maybe a scheduling thing?
Jiri: I know nothing about how mouse clicks are interpreted,
or even *where* or *how* double-click detection happens.
Until this started happening, I didn't even know which module
was the driver for my mouse (it's usbhid).
Can you give a short tutorial, to help us understand possible causes ?
Mark Lord wrote:
> Jiri Kosina wrote:
>> On Sun, 2 Dec 2007, Mark Lord wrote:
>>
>>>> Single-clicking on things with 2.6.24 very frequently gives a
>>>> "double-click". This does not happen with 2.6.23.8. I wonder what
>>>> broke it? I've grabbed mousedev.c from 2.6.23 and inserted that in
>>>> place of the updated 2.6.24 source, but no change. So it's not that
>>>> file.
>>> Mmm.. reverting the entire drivers/hid directory to that from 2.6.23
>>> seems to have fixed the problem, so we now know it's in there somewhere.
> ...
>
> Mmmm.. an update here:
>
> Reverting the drivers/hid directory does seem to improve behaviour.
>
> But right now I have a "make -j4" happening in the background
> and the mouse is ever so erratic again, despite the drivers/hid reversion.
..
Ghad.. now that the "make -j4" has finished, the mouse is *still* screwy,
whereas it was mostly fine before the "make -j4" started.
Time to reboot (for the new kernel, as well as to try and fix the mouse).
On Sun, 2 Dec 2007, Mark Lord wrote:
> Reverting the drivers/hid directory does seem to improve behaviour. But
> right now I have a "make -j4" happening in the background and the mouse
> is ever so erratic again, despite the drivers/hid reversion.
> So it's a timing thing, somewhere. Maybe a scheduling thing?
Thanks a lot for your report Mark. Before we start digging deeply here --
Dmitry, do you think that this could be caused by your input-locking
patches somehow? From Mark's report:
- it didn't happen with 2.6.23
- when drivers/hid is put back into 2.6.23 state, the problem still
persists in some sense
So there must have been some change elsewhere (USB, Input, something
completely different) that introduced this problem.
> Jiri: I know nothing about how mouse clicks are interpreted, or even
> *where* or *how* double-click detection happens. Until this started
> happening, I didn't even know which module was the driver for my mouse
> (it's usbhid). Can you give a short tutorial, to help us understand
> possible causes ?
First it would be really helpful to see if
- the HID driver really obtains two click events from USB stack. This
could be easily seen from HID debug output. I have written in previous
mail how to obtain this
- the output of evtest for the mouse device in /dev/input/event? (for
determinign the correcnt event number corresponding to your mouse, see
/proc/bus/input/devices)
Thanks,
--
Jiri Kosina
SUSE Labs
Jiri Kosina wrote:
...
> First it would be really helpful to see if
>
> - the HID driver really obtains two click events from USB stack. This
> could be easily seen from HID debug output. I have written in previous
> mail how to obtain this
..
That's in the queue.. :)
> - the output of evtest for the mouse device in /dev/input/event? (for
> determinign the correcnt event number corresponding to your mouse, see
> /proc/bus/input/devices)
..
Here's a *single* button click (press/release quickly):
Event: time 1196621063.612542, type 1 (Key), code 272 (LeftBtn), value 1
Event: time 1196621063.612553, type 0 (Reset), code 0 (Reset), value 0
Event: time 1196621063.620504, type 1 (Key), code 272 (LeftBtn), value 0
Event: time 1196621063.620512, type 0 (Reset), code 0 (Reset), value 0
Event: time 1196621063.628497, type 1 (Key), code 272 (LeftBtn), value 1
Event: time 1196621063.628502, type 0 (Reset), code 0 (Reset), value 0
Event: time 1196621063.684524, type 1 (Key), code 272 (LeftBtn), value 0
Event: time 1196621063.684531, type 0 (Reset), code 0 (Reset), value 0
Event: time 1196621063.700532, type 1 (Key), code 272 (LeftBtn), value 1
Event: time 1196621063.700538, type 0 (Reset), code 0 (Reset), value 0
Event: time 1196621063.764540, type 1 (Key), code 272 (LeftBtn), value 0
Event: time 1196621063.764550, type 0 (Reset), code 0 (Reset), value 0
Here's another one, except I held the button firmly down for a second or so,
and then released it:
Event: time 1196621197.179635, type 1 (Key), code 272 (LeftBtn), value 1
Event: time 1196621197.179645, type 0 (Reset), code 0 (Reset), value 0
Event: time 1196621198.323607, type 1 (Key), code 272 (LeftBtn), value 0
Event: time 1196621198.323616, type 0 (Reset), code 0 (Reset), value 0
I'll go work on the CONFIG_HID_DEBUG thing next.
Mark Lord wrote:
>
> Here's a *single* button click (press/release quickly):
>
> Event: time 1196621063.612542, type 1 (Key), code 272 (LeftBtn), value 1
> Event: time 1196621063.612553, type 0 (Reset), code 0 (Reset), value 0
> Event: time 1196621063.620504, type 1 (Key), code 272 (LeftBtn), value 0
> Event: time 1196621063.620512, type 0 (Reset), code 0 (Reset), value 0
> Event: time 1196621063.628497, type 1 (Key), code 272 (LeftBtn), value 1
> Event: time 1196621063.628502, type 0 (Reset), code 0 (Reset), value 0
> Event: time 1196621063.684524, type 1 (Key), code 272 (LeftBtn), value 0
> Event: time 1196621063.684531, type 0 (Reset), code 0 (Reset), value 0
> Event: time 1196621063.700532, type 1 (Key), code 272 (LeftBtn), value 1
> Event: time 1196621063.700538, type 0 (Reset), code 0 (Reset), value 0
> Event: time 1196621063.764540, type 1 (Key), code 272 (LeftBtn), value 0
> Event: time 1196621063.764550, type 0 (Reset), code 0 (Reset), value 0
..
Note that, much of the time, a single mouse click looks like this:
Event: time 1196621357.073485, type 1 (Key), code 272 (LeftBtn), value 1
Event: time 1196621357.073494, type 0 (Reset), code 0 (Reset), value 0
Event: time 1196621357.201482, type 1 (Key), code 272 (LeftBtn), value 0
Event: time 1196621357.201492, type 0 (Reset), code 0 (Reset), value 0
So the first one I posted was probably the same kind of sequence
that leads to the unwanted double-clicks I'm reporting here.
This information may also be relevant:
The mouse is plugged into a USB2 hub, and appears as IRQ19:
19: 34776 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5
Cheers
On Sun, 2 Dec 2007, Mark Lord wrote:
> > Here's a *single* button click (press/release quickly):
> > Event: time 1196621063.612542, type 1 (Key), code 272 (LeftBtn), value 1
> > Event: time 1196621063.612553, type 0 (Reset), code 0 (Reset), value 0
> > Event: time 1196621063.620504, type 1 (Key), code 272 (LeftBtn), value 0
> > Event: time 1196621063.620512, type 0 (Reset), code 0 (Reset), value 0
> > Event: time 1196621063.628497, type 1 (Key), code 272 (LeftBtn), value 1
> > Event: time 1196621063.628502, type 0 (Reset), code 0 (Reset), value 0
> > Event: time 1196621063.684524, type 1 (Key), code 272 (LeftBtn), value 0
> > Event: time 1196621063.684531, type 0 (Reset), code 0 (Reset), value 0
> > Event: time 1196621063.700532, type 1 (Key), code 272 (LeftBtn), value 1
> > Event: time 1196621063.700538, type 0 (Reset), code 0 (Reset), value 0
> > Event: time 1196621063.764540, type 1 (Key), code 272 (LeftBtn), value 0
> > Event: time 1196621063.764550, type 0 (Reset), code 0 (Reset), value 0
> ..
Thanks. This definitely is bogus. In fact three clicks are reported.
> Note that, much of the time, a single mouse click looks like this:
> Event: time 1196621357.073485, type 1 (Key), code 272 (LeftBtn), value 1
> Event: time 1196621357.073494, type 0 (Reset), code 0 (Reset), value 0
> Event: time 1196621357.201482, type 1 (Key), code 272 (LeftBtn), value 0
> Event: time 1196621357.201492, type 0 (Reset), code 0 (Reset), value 0
Yes, this is correct.
> This information may also be relevant:
> The mouse is plugged into a USB2 hub, and appears as IRQ19:
> 19: 34776 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5
Just a random shot into the dark -- if you remove the ehci-hcd module,
does anything change?
Thanks,
--
Jiri Kosina
SUSE Labs
Jiri Kosina wrote:
> On Sun, 2 Dec 2007, Mark Lord wrote:
>
>>> Here's a *single* button click (press/release quickly):
>>> Event: time 1196621063.612542, type 1 (Key), code 272 (LeftBtn), value 1
>>> Event: time 1196621063.612553, type 0 (Reset), code 0 (Reset), value 0
>>> Event: time 1196621063.620504, type 1 (Key), code 272 (LeftBtn), value 0
>>> Event: time 1196621063.620512, type 0 (Reset), code 0 (Reset), value 0
>>> Event: time 1196621063.628497, type 1 (Key), code 272 (LeftBtn), value 1
>>> Event: time 1196621063.628502, type 0 (Reset), code 0 (Reset), value 0
>>> Event: time 1196621063.684524, type 1 (Key), code 272 (LeftBtn), value 0
>>> Event: time 1196621063.684531, type 0 (Reset), code 0 (Reset), value 0
>>> Event: time 1196621063.700532, type 1 (Key), code 272 (LeftBtn), value 1
>>> Event: time 1196621063.700538, type 0 (Reset), code 0 (Reset), value 0
>>> Event: time 1196621063.764540, type 1 (Key), code 272 (LeftBtn), value 0
>>> Event: time 1196621063.764550, type 0 (Reset), code 0 (Reset), value 0
>> ..
>
> Thanks. This definitely is bogus. In fact three clicks are reported.
>
>> Note that, much of the time, a single mouse click looks like this:
>> Event: time 1196621357.073485, type 1 (Key), code 272 (LeftBtn), value 1
>> Event: time 1196621357.073494, type 0 (Reset), code 0 (Reset), value 0
>> Event: time 1196621357.201482, type 1 (Key), code 272 (LeftBtn), value 0
>> Event: time 1196621357.201492, type 0 (Reset), code 0 (Reset), value 0
>
> Yes, this is correct.
>
>> This information may also be relevant:
>> The mouse is plugged into a USB2 hub, and appears as IRQ19:
>> 19: 34776 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5
>
> Just a random shot into the dark -- if you remove the ehci-hcd module,
> does anything change?
..
No, just as jumpy as ever.
Right now it's double-clicking just about everything.
If I unplug/replug it, things behave for a while.
Still want the HID_DEBUG output? (rebooting shortly)
On Sun, 2 Dec 2007, Mark Lord wrote:
> Right now it's double-clicking just about everything. If I unplug/replug
> it, things behave for a while. Still want the HID_DEBUG output?
> (rebooting shortly)
Yes, definitely. I currently don't have an idea what might be causing it,
and I am unable to reproduce it here.
If HID DEBUG doesn't reveal anything interesting, we would probably need
usbmon dump too.
--
Jiri Kosina
SUSE Labs
Jiri Kosina wrote:
> On Sun, 2 Dec 2007, Mark Lord wrote:
>
>> Right now it's double-clicking just about everything. If I unplug/replug
>> it, things behave for a while. Still want the HID_DEBUG output?
>> (rebooting shortly)
>
> Yes, definitely. I currently don't have an idea what might be causing it,
> and I am unable to reproduce it here.
>
> If HID DEBUG doesn't reveal anything interesting, we would probably need
> usbmon dump too.
..
Okay. I've got to leave the computer for a while now,
so I'll post again whenever I have something new here.
Leave it with me for now. Thanks for helping!
Cheers
[ linux-usb-devel added to CC ]
On Sun, 2 Dec 2007, Mark Lord wrote:
> Okay. I've got to leave the computer for a while now, so I'll post
> again whenever I have something new here.
Thanks. To sum up this longish thread:
- 2.6.24-rcX exposes the problem with sometimes multiple clicks being
generated as a response for one click on USB mouse (evtest shows that
really mutliple LeftBtn events arrive). 2.6.23 behaves correctly
- reverting the state of drivers/hid to 2.6.23 state doesn't make the
problem go away, so the problem is elsewhere (Input? USB?)
- Mark seems to be able to reproduce the problem quite easily; I was not
successful reproducing this no matter how hard I tried, and I also
didn't receive any similar bugreports from anyone else
- we are currently waiting for Mark to provide HID_DEBUG (and preferably
also usbmon) output from the situation where multiple clicks are
being generated incorrectly
--
Jiri Kosina
SUSE Labs
Jiri Kosina wrote:
> [ linux-usb-devel added to CC ]
>
> On Sun, 2 Dec 2007, Mark Lord wrote:
>
>> Okay. I've got to leave the computer for a while now, so I'll post
>> again whenever I have something new here.
>
> Thanks. To sum up this longish thread:
>
> - 2.6.24-rcX exposes the problem with sometimes multiple clicks being
> generated as a response for one click on USB mouse (evtest shows that
> really mutliple LeftBtn events arrive). 2.6.23 behaves correctly
> - reverting the state of drivers/hid to 2.6.23 state doesn't make the
> problem go away, so the problem is elsewhere (Input? USB?)
> - Mark seems to be able to reproduce the problem quite easily; I was not
> successful reproducing this no matter how hard I tried, and I also
> didn't receive any similar bugreports from anyone else
> - we are currently waiting for Mark to provide HID_DEBUG (and preferably
> also usbmon) output from the situation where multiple clicks are
> being generated incorrectly
..
Well, I've rebuilt the kernel with HID_DEBUG, DEBUG_FS, and USBMON.
And I've written a nifty script to make usbmon tracing effortless for this.
And now I'm waiting.. things are currently behaving perfectly.
Go figure. It did seem to arrive in bursts before.
So, don't beat yourselves over this one for now.
I'll track it down here and post again next time it starts happening.
Mmmm...
Jiri Kosina ha scritto:
>> My USB mouse recently started giving me phantom scrolls (movements of
>> the mouse wheel, even I made sure the wheel was in a resting position)
>> in recently kernels. It happened too infrequently for me to care.
> Did this also start in 2.6.24, as in Mark's case?
It happens to me, too.
Wireless mouse, gives some "wheel up" signals when going into powersave
state. Kernel is 2.6.22-tmb-laptop-2mdv (Mandriva Cooker).
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=062a ProdID=0000 Rev= 0.00
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=10ms
Maybe a more-or-less undocumented sequence to tell the host it's going
to sleep?
BYtE,
Diego.
On Thu, 6 Dec 2007, Diego Zuccato wrote:
> It happens to me, too. Wireless mouse, gives some "wheel up" signals
> when going into powersave state. Kernel is 2.6.22-tmb-laptop-2mdv
> (Mandriva Cooker).
Is this a regression for you? Are you able to say which kernel first
exposed this behavior in your case?
> Maybe a more-or-less undocumented sequence to tell the host it's going
> to sleep?
usbmon and/or HID_DEBUG output would be interesting to see (how to produce
HID debugging output has been explained earlier in this thread, for usbmon
please look in Documentation/usb/usbmon.txt).
Thanks,
--
Jiri Kosina
SUSE Labs
On Dec 2, 2007 2:07 PM, Jiri Kosina <[email protected]> wrote:
> Thanks. To sum up this longish thread:
>
> - Mark seems to be able to reproduce the problem quite easily; I was not
> successful reproducing this no matter how hard I tried, and I also
> didn't receive any similar bugreports from anyone else
> - we are currently waiting for Mark to provide HID_DEBUG (and preferably
> also usbmon) output from the situation where multiple clicks are
> being generated incorrectly
Okay, I'm having a problem with 2.6.24-rc4 that I didn't with 2.6.23-rc6.
When the problem hits, my mouse (synaptics touchpad) is randomly
moving about and clicking things whenever I have my finger on the
trackpad. This behavior will persists for five to ten minutes (is
happening now), and seems to be triggered by load (watching online
videos in flash player, for example -- this matches Mark's experience
with a make -j4).
I *think* the touchpad is connected via ps2, which looks like it'd
clear usb of any blame. It's /dev/input/event6 at any rate.
This has been happening about once a day, and seems to start because
of high CPU usage. ONce the CPU is idle, it still happens though, so
I'm not sure why it clears up.
Any clues for where I should hunt from here?
Hi,
On Dec 7, 2007 12:59 PM, Ray Lee <[email protected]> wrote:
> On Dec 2, 2007 2:07 PM, Jiri Kosina <[email protected]> wrote:
> > Thanks. To sum up this longish thread:
> >
> > - Mark seems to be able to reproduce the problem quite easily; I was not
> > successful reproducing this no matter how hard I tried, and I also
> > didn't receive any similar bugreports from anyone else
> > - we are currently waiting for Mark to provide HID_DEBUG (and preferably
> > also usbmon) output from the situation where multiple clicks are
> > being generated incorrectly
>
> Okay, I'm having a problem with 2.6.24-rc4 that I didn't with 2.6.23-rc6.
>
> When the problem hits, my mouse (synaptics touchpad) is randomly
> moving about and clicking things whenever I have my finger on the
> trackpad. This behavior will persists for five to ten minutes (is
> happening now), and seems to be triggered by load (watching online
> videos in flash player, for example -- this matches Mark's experience
> with a make -j4).
>
> I *think* the touchpad is connected via ps2, which looks like it'd
> clear usb of any blame. It's /dev/input/event6 at any rate.
>
> This has been happening about once a day, and seems to start because
> of high CPU usage. ONce the CPU is idle, it still happens though, so
> I'm not sure why it clears up.
>
> Any clues for where I should hunt from here?
>
Can you try replacing drivers/input/ and include/linux/input.h from
2.6.23-rc6 and see if it works or not? That should give us idea if
input locking changes are to blame.
Thanks.
--
Dmitry
On Dec 7, 2007 10:32 AM, Dmitry Torokhov <[email protected]> wrote:
> On Dec 7, 2007 12:59 PM, Ray Lee <[email protected]> wrote:
> > On Dec 2, 2007 2:07 PM, Jiri Kosina <[email protected]> wrote:
> > > Thanks. To sum up this longish thread:
> > >
> > > - Mark seems to be able to reproduce the problem quite easily; I was not
> > > successful reproducing this no matter how hard I tried, and I also
> > > didn't receive any similar bugreports from anyone else
> > > - we are currently waiting for Mark to provide HID_DEBUG (and preferably
> > > also usbmon) output from the situation where multiple clicks are
> > > being generated incorrectly
> >
> > Okay, I'm having a problem with 2.6.24-rc4 that I didn't with 2.6.23-rc6.
> >
> > When the problem hits, my mouse (synaptics touchpad) is randomly
> > moving about and clicking things whenever I have my finger on the
> > trackpad. This behavior will persists for five to ten minutes (is
> > happening now), and seems to be triggered by load (watching online
> > videos in flash player, for example -- this matches Mark's experience
> > with a make -j4).
> >
> > I *think* the touchpad is connected via ps2, which looks like it'd
> > clear usb of any blame. It's /dev/input/event6 at any rate.
> >
> > This has been happening about once a day, and seems to start because
> > of high CPU usage. ONce the CPU is idle, it still happens though, so
> > I'm not sure why it clears up.
> >
> > Any clues for where I should hunt from here?
> >
>
> Can you try replacing drivers/input/ and include/linux/input.h from
> 2.6.23-rc6 and see if it works or not? That should give us idea if
> input locking changes are to blame.
I'm hitting a number of build errors, trying to compile a hybrid
between the two.
git checkout v2.6.24-rc4
git checkout v2.6.23 include/linux/input.h drivers/input
make
# fails with kconfig issues
git checkout v2.6.24-rc4 drivers/input/misc/Kconfig
make
# fails
...adding to include/linux/input.h:
#define KEY_CNT (KEY_MAX+1)
takes the build a little farther until it dies on more missing
definitions. Doing a checkout of 2.6.24-rc4's include/linux/input.h
leads to different build errors.
Looking at git log for drivers/input, it appears the patches you're
talking about are the ones starting with 8006479c9b? If so, perhaps I
should just build the revision right before that commit and test that?
Ray
On Dec 7, 2007 4:23 PM, Ray Lee <[email protected]> wrote:
>
> On Dec 7, 2007 10:32 AM, Dmitry Torokhov <[email protected]> wrote:
> > On Dec 7, 2007 12:59 PM, Ray Lee <[email protected]> wrote:
> > > On Dec 2, 2007 2:07 PM, Jiri Kosina <[email protected]> wrote:
> > > > Thanks. To sum up this longish thread:
> > > >
> > > > - Mark seems to be able to reproduce the problem quite easily; I was not
> > > > successful reproducing this no matter how hard I tried, and I also
> > > > didn't receive any similar bugreports from anyone else
> > > > - we are currently waiting for Mark to provide HID_DEBUG (and preferably
> > > > also usbmon) output from the situation where multiple clicks are
> > > > being generated incorrectly
> > >
> > > Okay, I'm having a problem with 2.6.24-rc4 that I didn't with 2.6.23-rc6.
> > >
> > > When the problem hits, my mouse (synaptics touchpad) is randomly
> > > moving about and clicking things whenever I have my finger on the
> > > trackpad. This behavior will persists for five to ten minutes (is
> > > happening now), and seems to be triggered by load (watching online
> > > videos in flash player, for example -- this matches Mark's experience
> > > with a make -j4).
> > >
> > > I *think* the touchpad is connected via ps2, which looks like it'd
> > > clear usb of any blame. It's /dev/input/event6 at any rate.
> > >
> > > This has been happening about once a day, and seems to start because
> > > of high CPU usage. ONce the CPU is idle, it still happens though, so
> > > I'm not sure why it clears up.
> > >
> > > Any clues for where I should hunt from here?
> > >
> >
> > Can you try replacing drivers/input/ and include/linux/input.h from
> > 2.6.23-rc6 and see if it works or not? That should give us idea if
> > input locking changes are to blame.
>
> I'm hitting a number of build errors, trying to compile a hybrid
> between the two.
>
> git checkout v2.6.24-rc4
> git checkout v2.6.23 include/linux/input.h drivers/input
> make
> # fails with kconfig issues
> git checkout v2.6.24-rc4 drivers/input/misc/Kconfig
> make
> # fails
> ...adding to include/linux/input.h:
> #define KEY_CNT (KEY_MAX+1)
>
> takes the build a little farther until it dies on more missing
> definitions. Doing a checkout of 2.6.24-rc4's include/linux/input.h
> leads to different build errors.
>
> Looking at git log for drivers/input, it appears the patches you're
> talking about are the ones starting with 8006479c9b? If so, perhaps I
> should just build the revision right before that commit and test that?
>
Yes doing this and then buildig
b9d2d110b10f7b4788d0fdd328cf57e34b767817s shoulds isolate msot input
core changes.
--
Dmitry