From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 Description of problem: I am not exactly sure if this is kernel problem, but I did not manage to find any better category to report this VERY annoying problem. Last weekend I upgraded from FC1 to FC3. Since then my IBM Scrollpoint optical mouse has not worked perfectly at all. Back in FC1 days it worked. The problems I have found: 1) Earlier (FC1) I had mouse in PS/2 port and moving, buttons and stick (the wheel) worked just fine. When I made the FC3 installation I noticed already in graphical installation program that mouse didn't work at all and I had to do the whole installation using keyboard shortcuts. After the installation I tried multiple different settgins in xorg.conf but still mouse didn't work at all. Finally I managed to get mouse working (BUT NOT wheel see 2) when I disconnected mouse from PS/2 port and took away green USB->PS/2 adapter and inserted mouse to the USB port. 2) After I got mouse working otherwise I have been playing HOURS to find out any way to get the scrollpoint to work but I have not been very successfull in my tries. It looks like the scrollpoint messages are dropped or something like that. Anyhow the scollpoint usage is impossible because it may or may not move scrollbar in windows. My InputDevice section in xorg.conf looks now like (after hours of testing I have returned to the original one): Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5" Option "Emulate3Buttons" "no" EndSection Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Connect IBM scrollpoint mouse to USB 2. Start any X-windows program that can scroll wheel 3. scroll bar either moves after many tries or is totally still Actual Results: scroll bar either moves after many tries or is totally still Expected Results: Scrollbar would move smoothly like in FC1 times it used to do. Additional info:
Few more hour spent with the problem and I have learned more over the problem... Now it looks like more "missing native driver" problem than anything else. I recompiled kernel with a patch I found from a mailing list discussion [1]. First I thought that it didn't help at all, but then I played with "xev" command. I learned that I get the events from scrollpoint movement if I push the scrollpoint only slightly towards either direction. If I push it further no events are anymore got. This is difference to how it used to behave when mouse was in PS/2 slot when I still had FC1 installed. I did further studies and added number of buttons to 7 and set the "ZAxisMapping" to value "4 5 6 7". To my surprise the events I mostly got were 6 and 7 and events 4 and 5 were seen only very seldom. The events 4 and 5 I have managed to produce basically only when I changed the scrolling direction, but it seems that these events are send when the scrollpoint is moved veryveryveryvery slightly to either direction. I further added the number of the buttons to 11 but unfortunately mouse do not produce these events at all. Not even when I move scrollpoint to left and right (this device would also support left and right scrolling if Linux/driver would support it). So now I have "ZAxisMapping" set to value "6 7 4 5". Now if I just remember not to push too hard the scrollpoint to either direction the vertical scrolling is working nearly as well as when I had FC1 and mouse in PS/2 port. This requires some finger skills though, but I guess I can manage it until IBM gives the specs out so that someone can really write a native driver for this wonderful device (basically the scrollpoint is best scrolling device there exists when it just works properly like it does in Windows). [1] http://marc.free.net.ph/message/20041026.084528.e2153033.html
Ehem... Better not to have "Buttons" "7" because Mozilla seems to take those 6 and 7 as "Go back/forward one page". So the original setting of 5 buttons and "ZAxisMapping" "4 5" is just OK as long as one remembers to have gentle thouch to the scrollpoint. It is unfortune that the scrolling is then cut when mouse really sends indormation that would be translated by IMPS/2 driver to 6 and 7 button press, but life is never perfect as long as IBM thinks their mouse device protocol (or settings) are top secret ;-).
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I am still on FC3 even though soon to upgrade to FC4. Anyhow I am not sure to which specific problem there might have been solution in kernel-2.6.12-1.1372_FC3, but unfortunately I have to report that the mouse works just like it have been working from the beginning. Naturally I did not do the full installation of FC3, so I can not say if the problem releated to mouse working during installation phase has been fixed. Still if push or drag the scrollpoint more than "a little bit" scrolling stops and in xev I'll get the 6 and 7 button presses. BTW. Where I can find the changelogs telling what have changed in the _FC3 kernels?
This is a mass-update to all currently open Fedora Core 3 kernel bugs. Fedora Core 3 support has transitioned to the Fedora Legacy project. Due to the limited resources of this project, typically only updates for new security issues are released. As this bug isn't security related, it has been migrated to a Fedora Core 4 bug. Please upgrade to this newer release, and test if this bug is still present there. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. Thank you.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
Closing per previous two comments.
I just hit this bug. Seems common for Scrollpoints under linux. This bug still exists in F10. You can get it work somewhat by using: Option "Protocol" "ExplorerPS/2" I don't use the horiz scroll so I don't bother with the ZAxisMapping. If you use the ExplorerPS/2 driver then the "wheel" works, but it works uber fast in most apps, like Firefox, making it unusable. Strangely, in galeon it works much saner (slower) but still quite fast. There are hits on google about patches submitted upstream in 2004 but I see no evidence they ever got accepted.