Re: KVM mice issues
I think Alexey was having similar issues, and may have some non-production quality patches for you to try. On Sun, Mar 23, 2003 at 09:57:36AM -0600, Chip Norkus wrote: Greetings hackers, I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse, and I've found that while FreeBSD properly detects the mouse and all its functionality (buttons, scrollwheel, etc) upon boot if I switch to another port on the KVM and then switch back my mouse loses its functionality. After spending a while trying to figure out this problem (and reading PRs on the issue (esp. i386/25463)) I found that a solution was not immediately available, but might be somewhat easy to achieve. In particular, for my mouse, the mouse driver can and does detect invalid packets, and invalid packets are always received after a return to my FreeBSD system via the KVM. I found that doing a reinitialization of the device would fix the mouse, but that doing it from the interrupt handler (in sys/isa/psm.c around line 2170) caused some intermediate problems. Normally the mouse would just bounce around and generate click events for a while and then settle down, but occasionally the driver (or maybe mouse?) would lock solid and I'd have to reboot the system. Anyways, I'd like to work further on this problem and hopefully find a solution, but I'm having some trouble understanding where and what I should do. I'm not a novice C hacker, but I *am* a very novice kernel hacker and would appreciate help from anyone with knowledge of the psm (and atkbdc) code. I've considered maybe adding an ioctl to reset the mouse and adding a signal handler to moused to force a reset, but that seems kind of silly when the kernel driver can detect the problem itself and resolve it. On the other hand, maybe that's the right way to go? Advice would be greatly appreciated. -chip -- chip norkus; renaissance hacker;[EMAIL PROTECTED] question = (to) ? be : !be; --Shakespeare http://telekinesis.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: KVM mice issues
hi, Yep. In order to avoid moused(8) getting something crazy (after console switch) I just forced psm reset after synchronization error detection. It can be achieved by changing changing of PSM_SYNCERR_THRESHOLD1 define from 20 to 0 (in file sys/isa/psm.c). Please try to do it and let me know result, if you're also happy with solution -- I'll cleanup and commit my patch which forces such behaviour using sysctl(8). On Mon, Mar 24, 2003 at 12:50:24PM +0200, Ruslan Ermilov wrote: I think Alexey was having similar issues, and may have some non-production quality patches for you to try. On Sun, Mar 23, 2003 at 09:57:36AM -0600, Chip Norkus wrote: Greetings hackers, I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse, and I've found that while FreeBSD properly detects the mouse and all its functionality (buttons, scrollwheel, etc) upon boot if I switch to another port on the KVM and then switch back my mouse loses its functionality. After spending a while trying to figure out this problem (and reading PRs on the issue (esp. i386/25463)) I found that a solution was not immediately available, but might be somewhat easy to achieve. In particular, for my mouse, the mouse driver can and does detect invalid packets, and invalid packets are always received after a return to my FreeBSD system via the KVM. I found that doing a reinitialization of the device would fix the mouse, but that doing it from the interrupt handler (in sys/isa/psm.c around line 2170) caused some intermediate problems. Normally the mouse would just bounce around and generate click events for a while and then settle down, but occasionally the driver (or maybe mouse?) would lock solid and I'd have to reboot the system. Anyways, I'd like to work further on this problem and hopefully find a solution, but I'm having some trouble understanding where and what I should do. I'm not a novice C hacker, but I *am* a very novice kernel hacker and would appreciate help from anyone with knowledge of the psm (and atkbdc) code. I've considered maybe adding an ioctl to reset the mouse and adding a signal handler to moused to force a reset, but that seems kind of silly when the kernel driver can detect the problem itself and resolve it. On the other hand, maybe that's the right way to go? Advice would be greatly appreciated. -chip -- chip norkus; renaissance hacker;[EMAIL PROTECTED] question = (to) ? be : !be; --Shakespeare http://telekinesis.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Ruslan ErmilovSysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: KVM mice issues
On Monday 24 March 2003 06:33 am, you wrote: hi, Hi Alxey, Yep. In order to avoid moused(8) getting something crazy (after console switch) I just forced psm reset after synchronization error detection. It can be achieved by changing changing of PSM_SYNCERR_THRESHOLD1 define from 20 to 0 (in file sys/isa/psm.c). Please try to do it and let me know result, if you're also happy with solution -- I'll cleanup and commit my patch which forces such behaviour using sysctl(8). I tried this. Unfortunately it didn't work for my particular problem. I went back to my original solution (which seems to be pretty MouseMan+ centric unfortunately) of reinitializing the mouse after a protocol error, and I think I have something that works at least as well as the Windows driver. The optimal solution (for me) is to reset the mouse on protocol error and also to set PSM_SYNCERR_THRESHOLD1 to 0 (I get a lot of sync errors after I do a reset.. I imagine I'm doing something incorrectly here :). So far this solution seems to work well, at least I haven't lost my mouse wheel after switching to/from another port on the KVM. When I switch back my mouse acts a bit odd for a moment (the sync errors) and then resets itself and seems to work fine. I'm much happier with a momentarily flaky mouse *with* a mousewheel than a non-flaky mouse without one. If you're interested I can send you the patch I've got. Thanks for your help! -chip -- chip norkus; renaissance hacker;[EMAIL PROTECTED] question = (to) ? be : !be; --Shakespeare http://telekinesis.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
KVM mice issues
Greetings hackers, I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse, and I've found that while FreeBSD properly detects the mouse and all its functionality (buttons, scrollwheel, etc) upon boot if I switch to another port on the KVM and then switch back my mouse loses its functionality. After spending a while trying to figure out this problem (and reading PRs on the issue (esp. i386/25463)) I found that a solution was not immediately available, but might be somewhat easy to achieve. In particular, for my mouse, the mouse driver can and does detect invalid packets, and invalid packets are always received after a return to my FreeBSD system via the KVM. I found that doing a reinitialization of the device would fix the mouse, but that doing it from the interrupt handler (in sys/isa/psm.c around line 2170) caused some intermediate problems. Normally the mouse would just bounce around and generate click events for a while and then settle down, but occasionally the driver (or maybe mouse?) would lock solid and I'd have to reboot the system. Anyways, I'd like to work further on this problem and hopefully find a solution, but I'm having some trouble understanding where and what I should do. I'm not a novice C hacker, but I *am* a very novice kernel hacker and would appreciate help from anyone with knowledge of the psm (and atkbdc) code. I've considered maybe adding an ioctl to reset the mouse and adding a signal handler to moused to force a reset, but that seems kind of silly when the kernel driver can detect the problem itself and resolve it. On the other hand, maybe that's the right way to go? Advice would be greatly appreciated. -chip -- chip norkus; renaissance hacker;[EMAIL PROTECTED] question = (to) ? be : !be; --Shakespeare http://telekinesis.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
