Overview Description: This seems to be a problem with various models of Logitech mouse. The mouse will sometimes jump across screen, along with clicking and dragging items. Seems to be reproducable throughout most WMs, including KDE and fluxbox. Steps to Reproduce: 1) StartX 2) Work normally, I've noticed that the use of CTRL and ALT trigger the event more than normal. Build Date & Platform: June 05, 2004 - gentoo-dev-sources-2.6.5-rc3 - x86 Additional Builds and Platforms: - Also Occurs On development-sources-2.6.6-rc3 XFree86-4.3.0-r5 and XFree86-4.3.0-r2 KDE-3.2.2 FluxBox-0.9.9
Can you paste your XF86Config or xorg.conf file to confirm the correct setup. Is this a USB mouse? Is there anything simliar in other logitech models that can link them together to better evaluate the problem?
Created attachment 33724 [details] XF86Config File here's my XF86Config file, also the mouse is a USB Mouse, the model I currently use is the Logitech Dual Optical Mouseman.
Also, it seems to only affect optical mice, and the presence of a wheel doesn't seem to matter, as one of the cases, the mouse does not have a wheel.
# Baudrate and SampleRate are only for some Logitech mice. In # almost every case these lines should be omitted. # Option "BaudRate" "9600" # Option "SampleRate" "150" I see this under logitech, I'd check the docs on XF86Config to see if it's related. Also, is it possibly the surface you're using? Is the surface porous or distorts light? I notice this can cause some optical mouses to fritz. My guess would be to try the Baud/Sample rate as described by the docs and see if it helps the problem.
The presence of a wheel may or may not have an affect on this issue. I was the one who said I had the problem and had no mouse-wheel, but that was just a brain-fart that made me thing the wheel was the mouse ball. "An optical mouse with a mouse wheel?" I thought, "Of course not!"
I am not using a surface that refects light in any odd manner, as the mouse worked perfectly in Windows, using the same mousing surface. Also it wouldn't be the mousing surface as to the fact that it not only skips around it also has problems where it would randomly click and hold, i.e. open programs due to random clicking, move windows, etc. I will however look into the baud rate for the mouse, although that sounds like something that would be more for serial mice and not a USB or even PS/2 mouse. Any other ideas?
kloeri in #gentoo-bugs recommended trying to change the Protocol you're using from IMPS/2 to something different. Auto may help to find a better protocol, if not that, check on the XF86 docs to see what the other values are. There may be something vender specific in there.
This problem also occuring for me with Logitech MX-500 wheel mouse. I have replaced the mouse. I have tried the protocols, ExplorerPS/2, and evdev in X, xfree and xorg, and both 2.4 and 2.6 kernels. Happens when connected via USB or the PS/2 adapter. What is common?
I haven't tried it in X.org, but seems everything else is common, I've tried those protocols also, with no avail.... I wish i knew what the problem was, but doesn't seem to be going away any time soon. I'm currently using fluxbox as a WM and it still has the problem in fluxbox. you should CC yourself to this bug, and post your XF86Config file, if you're still using xfree, so we can compare...
Is this happening entirely with logitech optical mice or has anyone yet confirmed the same actions with a non-optical? just curious.
Something like this used to happen to me with a non-logitech optical mouse and a USB to PS/2 converter. Once I started using the mouse on a different computer, it pretty much stopped.
Donnie, what were both these computers running and what type of mouse was this?
I
I´ve the same problems with my Mouse. * xorg-x11-6.7.0-r1 * Logitech optical Mouse, with mouse wheel * gentoo-dev-sources-2.6.8-r1 * Xfce4 and KDE 3.2.3 Sporadic the mouse goes really crazy and clicks just around. ( until now I´m happy, that it hasn´t deleted nothing in konqueror.) The surface of my mouse pad is OK. I´ve just resently migrated to 2.6er Kernel, since then it´s really bad. Can´t remeber any Problems with that under a 2.4er Kernel. I will try this default settings in Xorg.conf you have suggested. My actual settings in xorg.conf are: Identifier "Mouse1" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/psaux" Option "ZAxisMapping" "4 5" Option "Emulate3Buttons" Option "Emulate3Timeout" "50"
just a little notice: gpm-1.20.1 works on console with these settings without any trouble for me: MOUSE=imps2 MOUSEDEV=/dev/psaux
Section "InputDevice" # Identifier and driver Identifier "USB_Mouse" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/input/mice" Option "Buttons" "5" Option "InputFashion" "Mouse" Option "Emulate3Buttons" "true" Option "ZAxisMapping" "4 5" EndSection Is what I have here for my Logitech MX 500 Duo (usb dongley thingy for mouse + keyb)... Works fine here so maybe try te inputfashion option.
I have this option activated ( x reloaded ), but without success: Option "BaudRate" "9600" Option "SampleRate" "150" now I will try this: Option "InputFashion" "Mouse"
I just had forgotten... during this "Mouse Rodeo" event I got messages like this in my Syslog: 22:28:18 Gentoo psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. Aug 23 22:59:28 Gentoo psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. Aug 23 23:15:57 Gentoo psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away.
First I thought, this one would have made it better : Option "InputFashion" "Mouse" but it doesn
First I thought, this one would have made it better : Option "InputFashion" "Mouse" but it doesn´t. I still have the same Problem with my Mouse. Now I will change back to a 2.4er Kernel, just to see if Problem still exists. ( This can take a few days, as the Problem is sporadic and I haven`t got a glue how to reproduse it yet, if I need to. )
have a look here, cause it seems other than mee have the same Problems: http://forums.gentoo.org/viewtopic.php?p=1487814
ok I had switched back to a 2.4er Kernel (gentoo-sources ). Since then all weird thing disappears. Same Hardware and same config else. What I will try now is to go back to 2.6er ( gentoo-dev-sources ) and change back to a "normal" mouse with a ball, to check if if it
ok I had switched back to a 2.4er Kernel (gentoo-sources ). Since then all weird thing disappears. Same Hardware and same config else. What I will try now is to go back to 2.6er ( gentoo-dev-sources ) and change back to a "normal" mouse with a ball, to check if if it´s a Logitech / optical related problem or a Kernel|Xorg /dev/psaux related problem.
it definitly _does not_ depend on the mouse I use ! So I guess it
it definitly _does not_ depend on the mouse I use ! So I guess it´s something in the Kernel or somenthing in combination with Xorg. Please can somebody have a look at this ? If somebody need any further Information I would be pleased to help. TIA
curious, those that have the problem, do you have non-intel chipsets?
Yes. I do have a VIA Apollo KX 133 Chipset
sometimes it seems the "whole inputsystem freezes". This means the keyboard produces only uppercase letters and mouse behaves as if shift were pressed. But it is not. To get out of this, I have to log in a console. during the first loging on console the keyboard is also "uppercase". Therefor I hit Caps lock and try to log in. This aborts with the error "Failed login" After this I can turn off caps lock and login as usual and also the iputsystem under X is normal again. My Keyboad is also ps/2, like my mouse. So I guess the problem is s.th. with this port or it
sometimes it seems the "whole inputsystem freezes". This means the keyboard produces only uppercase letters and mouse behaves as if shift were pressed. But it is not. To get out of this, I have to log in a console. during the first loging on console the keyboard is also "uppercase". Therefor I hit Caps lock and try to log in. This aborts with the error "Failed login" After this I can turn off caps lock and login as usual and also the iputsystem under X is normal again. My Keyboad is also ps/2, like my mouse. So I guess the problem is s.th. with this port or it´s protocol ! ??
I have the same issue happening. It *only* happens when Rhythmbox or XMMS switch songs. Hardware: Nforce2 chipset (onboard audio) ATi Radeion Logitech Cordless Elite Duo Mouse Software: development-sources 2.6.8.1 kernel XFree86 4.3.0-r6 XF86Config Mouse section: # ********************************************************************** # Core Pointer's InputDevice section # ********************************************************************** Section "InputDevice" # Identifier and driver Identifier "Mouse1" Driver "mouse" Option "Protocol" "ImPS/2" Option "ZAxisMapping" "4 5" Option "Device" "/dev/mouse" # When using XQUEUE, comment out the above two lines, and uncomment # the following line. # Option "Protocol" "Xqueue" # Baudrate and SampleRate are only for some Logitech mice. In # almost every case these lines should be omitted. # Option "BaudRate" "9600" # Option "SampleRate" "150" # Emulate3Buttons is an option for 2-button Microsoft mice # Emulate3Timeout is the timeout in milliseconds (default is 50ms) # Option "Emulate3Buttons" # Option "Emulate3Timeout" "50" # ChordMiddle is an option for some 3-button Logitech mice # Option "ChordMiddle" EndSection Notes: dmesg output... psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly. atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly. atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly. atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly. atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. eth0: Promiscuous mode enabled. device eth0 entered promiscuous mode device eth0 left promiscuous mode psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away. (eth0 is ntop starting...) Note this did not happen on my previous kernel (2.6.0-pre6, yeah I am lazy...). Let me know if you need anything else! SP
Doing a bit more research, I have found it seems to be a rather common problem (http://www.google.com/search?hl=en&ie=UTF-8&q=psmouse.c%3A+Explorer+Mouse+at+isa0060%2Fserio1%2Finput0+lost+synchronization%2C+throwing+3+bytes+away&btnG=Google+Search) Anyway, to summarize the google search, the commonality between them seem to be a 2.6.2+ Kernel and Logitech mice. Some people mentioned load as a factor while others did not. Chipsets vary. No mention of the new xorg version of X but many XFree mentions. I am guessing the bug lies somewhere between the 2.6 kernel and X. One bug link at mandrakesoft mentioned using "append=psmouse_noext" in lilo.conf (I use Grub and work on seeing if this solves the problem. If so, then it seems it would lie in that handling routine. SP
I would like to try this "append=psmouse_noext", too. I also use grub. How do I add this to grub ?
http://forums.gentoo.org/viewtopic.php?p=1559668&sid=ef7bc4b3279f8e0f12f110f963b80957#1559668
I have this same problem. For me it definitely only happens when the system is under load. Any kind of emerge really makes it act up. I'm on Xorg 6.8.0-r1 and I didn't have this problem until I upgraded. I'm on a 2.4 kernel and the mouse is just a laptop touchpad.
I'm not sure if this is related. But sometimes when the system is under heavy load, the same type of load that usually seems to accompany the mouse problems, I also notice keyboard issues such as key events delayed, repeated (as if i was holding the key in), etc. Sometimes when typing, characters will repeat even after another character has already been typed. I'm wondering if there is some more low-level/general IO or interrupt issue at the root of all this?
Got exactly the same prob with a MS IntelliMouse 1.1 on PS/2 port ... but I got a really funny way to make this behavior stop: I press the "power button" [don't ask me why i did this...] Nope, it didn't kill everything (it's a ACPI one...) - after one small hit on it, the mouse returns to normal mode... tryied to disable ACPI in kernel or thru "acpi=noirq" or "acpi=off" but it didn't help (or i didn't disable it well... still possible...) Dunno if it can help somebody to find a sol or if even work for others...
My latest experiences: I have tried serveral Mouse Prtocols: Option "Protocol" "auto" Seems to be the worst for me. The number of failures is the highest. Option "Protocol" "IMPS/2" It is "medium". The failures are less then with auto but the failure also appear when the cpu is at low load. Option "Protocol" "ExplorerPS/2" This seems to be the "best" to me. Best means the failures only happen when the cpu is under heavy load. I also tried to assign acpi=off to the Kernel. The problem I have with this, the PC doesn
My latest experiences: I have tried serveral Mouse Prtocols: Option "Protocol" "auto" Seems to be the worst for me. The number of failures is the highest. Option "Protocol" "IMPS/2" It is "medium". The failures are less then with auto but the failure also appear when the cpu is at low load. Option "Protocol" "ExplorerPS/2" This seems to be the "best" to me. Best means the failures only happen when the cpu is under heavy load. I also tried to assign acpi=off to the Kernel. The problem I have with this, the PC doesn´t turn off anymore. Sidenote: If you check the forums, there are a quite a lot people having this issue.
If you're on a 2.6 kernel, try adding this kernel parameter at boot time, e.g. in your grub.conf file: psmouse.proto=imps
Thanks for the tip, the GRUB boot parameter was the solution for me. My mouse problems are gone now. My mouse works okay for almost a week now, with kernel 2.6.9-gentoo-r13 and 2.6.10-gentoo-r4.
Same problem with a Logitech MX1000 mouse (plugged on the PS2 port), X.org 6.8.0-r4 and kernel 2.6.10-r6. The mouse goes crazy mainly on disk accesses, and move vertically, clicking and dragging very fast. I didn't had the problem with X.org 6.7.0. I'll try the kernel argument stuff. (I'm not on my computer at the moment) The mobo chipset is a SiS 741. (ASRock K7S41)
I too have been experiencing the same problem for a while now, and have gone through all the usual rigamarole (recompiling X, changing mouse protocol, disabling acpi and apic, disabling freq scaling, grub parameters etc etc). Adding the grub psmouse.proto=imps made the mouse usable on the desktop, but the problem still occurs when the system is under heavy load (typically during games like UT). Disabling other kernel functions (acpi, apic, freq scaling etc) don't seem to have an effect at all, so I've left them enabled for now. There used to be a boot param (psmouse_noext) that some people had used to solve the problem, but AFAICT it's removed in 2.6.10. Judging by the posts on LKML, it seems to be a bug in the 2.6 event/input handler, and seems especially prevalent with people who use KVM's or USB->PS/2 adaptors (like me). FWIW, hardware is an AMD64, MSI K8N Neo2 Plat (1.4 BIOS, same prob occurs under 1.3) and an MS Intellimouse Explorer 3.0 running through an adaptor. I'll post more info as and when I find it...
I'm not sure if this will help any of you, (I've never had the problem in Linux... only in Windows with my MX 300) Some PS/2 ports are multiplexed... especially on laptops. Those "lost synchronization" messages could be due to multiplexing issues. Gentoo-WIKI's Synaptics page says the following: -- grep dmesg for "i8042" and if you get the following line, you are near by the answer of your problem: "i8042.c: Detected active multiplexing controller, rev 1.1." Your PS/2 Port multiplexes the signals of the keyboard and the touchpad. You can disable this feature by one of the following two ways: If you have build-in the psmouse module in your kernel use the "i8042_nomux=1" parameter for loading the module. If not use "i8042.nomux" as a boot parameter for your kernel. (This hint was found on http://notebookforums.com) --
Please reopen if this remains an issue in modular X and following the advice in comment #33.
(In reply to comment #38) > Please reopen if this remains an issue in modular X and following the advice in > comment #33. > Some time ago i found a link where it was explained very well. It is defently NOT X related (although i don
(In reply to comment #38) > Please reopen if this remains an issue in modular X and following the advice in > comment #33. > Some time ago i found a link where it was explained very well. It is defently NOT X related (although i don´t have modular X right now). The reason for this problems is, they have taken the inputsystem from User-Space to Kernel-Space in Linux 2.6 and therefor all the drivers have to be reimplemented in Kernel-Space. I´ll check to find the link again
here is it: http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/
