Bug 211066
Summary: | Logitech mouse + KVM Switch + Kernel 2.6.18-1.2200.fc5smp | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jafaruddin Lie <jafaruddin.lie> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | CC: | dtor, pfrields, triage, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | bzcl34nup | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-05-06 16:29:28 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jafaruddin Lie
2006-10-17 04:14:16 UTC
*** Bug 211067 has been marked as a duplicate of this bug. *** does it work better if you boot with psmouse.proto=exps ? No go :) Still showing the same behaviour. Can I please see ouput of "cat /proc/bus/input/devices" from working and non- working kernels? I'm not the original reporter, but I see exactly the same problem. It is really like multiple buttons are pressed; when I scroll up in xterm in a problem kernel, it scrolls, but it also marks (which it shouldn't do and doesn't do in an okay kernel). Here's the requested output from my system: $ uname -r 2.6.17-1.2174_FC5 $ cat /proc/bus/input/devices I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/class/input/input0 H: Handlers=kbd event0 B: EV=120013 B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0002 Product=0006 Version=0000 N: Name="ImExPS/2 Generic Explorer Mouse" P: Phys=isa0060/serio1/input0 S: Sysfs=/class/input/input1 H: Handlers=mouse0 event1 B: EV=7 B: KEY=1f0000 0 0 0 0 0 0 0 0 B: REL=103 I: Bus=0010 Vendor=001f Product=0001 Version=0100 N: Name="PC Speaker" P: Phys=isa0061/input0 S: Sysfs=/class/input/input2 H: Handlers=kbd event2 B: EV=40001 B: SND=6 $ uname -r 2.6.18-1.2224.fc5 $ cat /proc/bus/input/devices I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/class/input/input0 H: Handlers=kbd event0 B: EV=120013 B: KEY=4 2000000 3802078 f840d001 feffffdf ffefffff ffffffff fffffffe B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0002 Product=0006 Version=0000 N: Name="ImExPS/2 Generic Explorer Mouse" P: Phys=isa0060/serio1/input0 S: Sysfs=/class/input/input1 H: Handlers=mouse0 event1 B: EV=7 B: KEY=1f0000 0 0 0 0 0 0 0 0 B: REL=143 I: Bus=0010 Vendor=001f Product=0001 Version=0100 N: Name="PC Speaker" P: Phys=isa0061/input0 S: Sysfs=/class/input/input2 H: Handlers=kbd event2 B: EV=40001 B: SND=6 Ok, I think it is caused by Intellimouse Explorer 4.0 support that was added recently. psmouse.proto=imps should disable explorer protocol... Can you guys compile your own kernels? Otherwise Dave will have to revert commits b0c9ad8e0ff154f8c4730b8c4383f49b846c97c4 and 90414be9523208f0b667fd58c22e26b8db0594de and roll out test image... Thanks Dmitry. That seems to help for now, and I am not losing any mouse functionality that I noticed of anyway. this has been the only report of this failing so far. If it was a widespread problem, I'd back those changes out in the next update, but as there's a workaround, I'm tempted to leave it as it stands, and hope that this gets fixed when we rebase to a later kernel version. Reverts have this horrible habit of staying around in vendor kernels longer than they need to even when stuff has been fixed upstream, so I'm usually reluctant to back stuff out instead of fixing it. Dmitry, I don't see any other notable commits to psmouse-base since the above commits you referenced, so I guess this isn't going to be fixed when we rebase to 2.6.19 either ? I have 2 reports including yours but then I do not actively monitor distributions' bugzillas and not all users are filing bugs anyways... At the moment we should either revert Intellimouse 4.0 support or keep it, I am leaning towards keeping it in for at least 2.6.19. Unfortunately we do not know [yet] of a way to query whether device supports 4.0 protocol so we assume that if it supports 2.0 then 4.0 magic knock will not break it. Works out reasonably well if not for these pesky KVMs. Can I please get wheel datastream from the "clickety" mouse - boot with i8042.debug=1 and make sure your log buffer is of decent size scroll the wheel couple of times and send me dmesg or /var/log/messages. You may want to edit out keyboard data from the log as I can see your password there. Sorry guys, I've moved to FC6 and have replaced my switch, so I can't really give you any more data for now. FC6 itself would have the same problem so as long as you did not throw away your old switch and have couple of minutes I would still like to see that datastream. Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |