d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
20d21fe9ef
freebsd-nq/sys/isa/psm.c

3132 lines
90 KiB
C
Raw Normal View History

Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/*-
* Copyright (c) 1992, 1993 Erik Forsberg.
* Copyright (c) 1996, 1997 Kazutaka YOKOTA.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* THIS SOFTWARE IS PROVIDED BY ``AS IS'' AND ANY EXPRESS OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
* NO EVENT SHALL I BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
/*
* Ported to 386bsd Oct 17, 1992
* Sandi Donno, Computer Science, University of Cape Town, South Africa
* Please send bug reports to sandi@cs.uct.ac.za
*
* Thanks are also due to Rick Macklem, rick@snowhite.cis.uoguelph.ca -
* although I was only partially successful in getting the alpha release
* of his "driver for the Logitech and ATI Inport Bus mice for use with
* 386bsd and the X386 port" to work with my Microsoft mouse, I nevertheless
* found his code to be an invaluable reference when porting this driver
* to 386bsd.
*
* Further modifications for latest 386BSD+patchkit and port to NetBSD,
* Andrew Herbert <andrew@werple.apana.org.au> - 8 June 1993
*
* Cloned from the Microsoft Bus Mouse driver, also by Erik Forsberg, by
* Andrew Herbert - 12 June 1993
*
* Modified for PS/2 mouse by Charles Hannum <mycroft@ai.mit.edu>
* - 13 June 1993
*
* Modified for PS/2 AUX mouse by Shoji Yuen <yuen@nuie.nagoya-u.ac.jp>
* - 24 October 1993
*
* Hardware access routines and probe logic rewritten by
* Kazutaka Yokota <yokota@zodiac.mech.utsunomiya-u.ac.jp>
* - 3, 14, 22 October 1996.
* - 12 November 1996. IOCTLs and rearranging `psmread', `psmioctl'...
* - 14, 30 November 1996. Uses `kbdio.c'.
* - 13 December 1996. Uses queuing version of `kbdio.c'.
* - January/February 1997. Tweaked probe logic for
* HiNote UltraII/Latitude/Armada laptops.
* - 30 July 1997. Added APM support.
* - 5 March 1997. Defined driver configuration flags (PSM_CONFIG_XXX).
* Improved sync check logic.
* Vendor specific support routines.
*/
Use __FBSDID().
2003-06-11 00:34:37 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
#include "opt_psm.h"
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/kernel.h>
#include <sys/module.h>
#include <sys/bus.h>
#include <sys/conf.h>
#include <sys/poll.h>
#include <sys/syslog.h>
Bring the 'new-bus' to the i386. This extensively changes the way the i386 platform boots, it is no longer ISA-centric, and is fully dynamic. Most old drivers compile and run without modification via 'compatability shims' to enable a smoother transition. eisa, isapnp and pccard* are not yet using the new resource manager. Once fully converted, all drivers will be loadable, including PCI and ISA. (Some other changes appear to have snuck in, including a port of Soren's ATA driver to the Alpha. Soren, back this out if you need to.) This is a checkpoint of work-in-progress, but is quite functional. The bulk of the work was done over the last few years by Doug Rabson and Garrett Wollman. Approved by: core
1999-04-16 21:22:55 +00:00
#include <machine/bus.h>
* Add hooks to allow the X server to access I/O ports and memory. * Update drivers to the latest version of the bus interface. The ISA drivers' use of the new resource api is minimal. Garrett has some much cleaner drivers which should be more easily shared between i386 and alpha. This has only been tested on cia based machines. It should work on lca and apecs but I might have broken something.
1998-11-15 18:25:17 +00:00
#include <sys/rman.h>
select() DKI is now in <sys/selinfo.h>.
2001-01-09 04:33:49 +00:00
#include <sys/selinfo.h>
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
#include <sys/sysctl.h>
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
#include <sys/time.h>
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
#include <sys/uio.h>
Deprecate machine/limits.h in favor of new sys/limits.h. Change all in-tree consumers to include <sys/limits.h> Discussed on: standards@ Partially submitted by: Craig Rodrigues <rodrigc@attbi.com>
2003-04-29 13:36:06 +00:00
#include <sys/limits.h>
Initiate deorbit burn sequence for <machine/mouse.h>. Replace all in-tree uses with <sys/mouse.h> which repo-copied a few moments ago from src/sys/i386/include/mouse.h by peter. This is also the appropriate fix for exo-tree sources. Put warnings in <machine/mouse.h> to discourage use. November 15th 2000 the warnings will be converted to errors. January 15th 2001 the <machine/mouse.h> files will be removed.
2000-10-09 08:08:36 +00:00
#include <sys/mouse.h>
* Add hooks to allow the X server to access I/O ports and memory. * Update drivers to the latest version of the bus interface. The ISA drivers' use of the new resource api is minimal. Garrett has some much cleaner drivers which should be more easily shared between i386 and alpha. This has only been tested on cia based machines. It should work on lca and apecs but I might have broken something.
1998-11-15 18:25:17 +00:00
#include <machine/resource.h>
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
#include <isa/isavar.h>
Update the alpha port to use the new syscons. Submitted by: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> (partly)
1999-01-23 16:53:30 +00:00
#include <dev/kbd/atkbdcreg.h>
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/*
* Driver specific options: the following options may be set by
* `options' statements in the kernel configuration file.
*/
/* debugging */
#ifndef PSM_DEBUG
#define PSM_DEBUG 0 /* logging: 0: none, 1: brief, 2: verbose */
#endif
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
#ifndef PSM_SYNCERR_THRESHOLD1
#define PSM_SYNCERR_THRESHOLD1 20
#endif
#ifndef PSM_INPUT_TIMEOUT
#define PSM_INPUT_TIMEOUT 2000000 /* 2 sec */
#endif
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* end of driver specific options */
Refine ACPI/PnP BIOS probe/attach routines a bit. - Add workaround for the problematic PnP BIOS which does not assign irq resource for the PS/2 mouse device node; if there is no irq assigned for the PS/2 mouse node, refer to device.hints for an irq number. If we still don't find an irq number in the hints database, use a hard-coded value. - Delete unused ivars. - Bit of clean up in probe/attach. - Add PnP ID for the PS/2 mouse port on some IBM ThinkPad models.
2001-09-15 04:38:20 +00:00
#define PSM_DRIVER_NAME "psm"
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
#define PSMCPNP_DRIVER_NAME "psmcpnp"
Refine ACPI/PnP BIOS probe/attach routines a bit. - Add workaround for the problematic PnP BIOS which does not assign irq resource for the PS/2 mouse device node; if there is no irq assigned for the PS/2 mouse node, refer to device.hints for an irq number. If we still don't find an irq number in the hints database, use a hard-coded value. - Delete unused ivars. - Bit of clean up in probe/attach. - Add PnP ID for the PS/2 mouse port on some IBM ThinkPad models.
2001-09-15 04:38:20 +00:00
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* input queue */
#define PSM_BUFSIZE 960
#define PSM_SMALLBUFSIZE 240
/* operation levels */
#define PSM_LEVEL_BASE 0
#define PSM_LEVEL_STANDARD 1
#define PSM_LEVEL_NATIVE 2
#define PSM_LEVEL_MIN PSM_LEVEL_BASE
#define PSM_LEVEL_MAX PSM_LEVEL_NATIVE
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
/* Logitech PS2++ protocol */
#define MOUSE_PS2PLUS_CHECKBITS(b) \
((((b[2] & 0x03) << 2) | 0x02) == (b[1] & 0x0f))
#define MOUSE_PS2PLUS_PACKET_TYPE(b) \
(((b[0] & 0x30) >> 2) | ((b[1] & 0x30) >> 4))
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* some macros */
#define PSM_UNIT(dev) (minor(dev) >> 1)
#define PSM_NBLOCKIO(dev) (minor(dev) & 1)
#define PSM_MKMINOR(unit,block) (((unit) << 1) | ((block) ? 0:1))
/* ring buffer */
typedef struct ringbuf {
int count; /* # of valid elements in the buffer */
int head; /* head pointer */
int tail; /* tail poiner */
unsigned char buf[PSM_BUFSIZE];
} ringbuf_t;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
/* data buffer */
typedef struct packetbuf {
unsigned char ipacket[16]; /* interim input buffer */
int inputbytes; /* # of bytes in the input buffer */
} packetbuf_t;
#ifndef PSM_PACKETQUEUE
#define PSM_PACKETQUEUE 128
#endif
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* driver control block */
struct psm_softc { /* Driver status information */
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
int unit;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
struct selinfo rsel; /* Process selecting for Input */
unsigned char state; /* Mouse driver state */
int config; /* driver configuration flags */
int flags; /* other flags */
KBDC kbdc; /* handle to access the keyboard controller */
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
struct resource *intr; /* IRQ resource */
void *ih; /* interrupt handle */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
mousehw_t hw; /* hardware information */
mousemode_t mode; /* operation mode */
mousemode_t dflt_mode; /* default operation mode */
mousestatus_t status; /* accumulated mouse movement */
ringbuf_t queue; /* mouse status queue */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
packetbuf_t pqueue[PSM_PACKETQUEUE]; /* mouse data queue */
int pqueue_start; /* start of data in queue */
int pqueue_end; /* end of data in queue */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
int button; /* the latest button state */
Recognize Interlink VersaPad. `Tap' action will be recognized as the button 4. Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
1999-08-17 12:14:13 +00:00
int xold; /* previous absolute X position */
int yold; /* previous absolute Y position */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
int syncerrors; /* XXX: KILL ME! */
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
struct timeval inputtimeout;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
struct timeval lastsoftintr; /* time of last soft interrupt */
struct timeval lastinputerr; /* time last sync error happened */
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
int watchdog; /* watchdog timer flag */
struct callout_handle callout; /* watchdog timer call out */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
struct callout_handle softcallout; /* buffer timer call out */
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
struct cdev *dev;
struct cdev *bdev;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
int lasterr;
int cmdcount;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
};
Fix some easy, global, lint warnings. In most cases, this means making some local variables static. In a couple of cases, this means removing an unused variable.
2003-04-30 12:57:40 +00:00
static devclass_t psm_devclass;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
#define PSM_SOFTC(unit) ((struct psm_softc*)devclass_get_softc(psm_devclass, unit))
/* driver state flags (state) */
#define PSM_VALID 0x80
#define PSM_OPEN 1 /* Device is open */
#define PSM_ASLP 2 /* Waiting for mouse data */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
#define PSM_SOFTARMED 4 /* Software interrupt armed */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* driver configuration flags (config) */
#define PSM_CONFIG_RESOLUTION 0x000f /* resolution */
#define PSM_CONFIG_ACCEL 0x00f0 /* acceleration factor */
#define PSM_CONFIG_NOCHECKSYNC 0x0100 /* disable sync. test */
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
#define PSM_CONFIG_NOIDPROBE 0x0200 /* disable mouse model probe */
#define PSM_CONFIG_NORESET 0x0400 /* don't reset the mouse */
#define PSM_CONFIG_FORCETAP 0x0800 /* assume `tap' action exists */
#define PSM_CONFIG_IGNPORTERROR 0x1000 /* ignore error in aux port test */
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
#define PSM_CONFIG_HOOKRESUME 0x2000 /* hook the system resume event */
#define PSM_CONFIG_INITAFTERSUSPEND 0x4000 /* init the device at the resume event */
- Add a hack for "psmintr: out of sync.." This is NOT a fix, but a hack! Add `flags 0x8000' to the psm driver to enable it. The psm driver will try to get out of out-of-sync situation by disabling the mouse and immediately enable it again. If you are seeing this out-of-sync problem because of an incompetent(?!) KVM switch, this hack will NOT be good for you. However, if you are occasionally seeing the problem because of lost mouse interrupt, this might help.
2000-12-01 05:26:24 +00:00
#define PSM_CONFIG_SYNCHACK 0x8000 /* enable `out-of-sync' hack */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
#define PSM_CONFIG_FLAGS (PSM_CONFIG_RESOLUTION \
| PSM_CONFIG_ACCEL \
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
| PSM_CONFIG_NOCHECKSYNC \
- Add a hack for "psmintr: out of sync.." This is NOT a fix, but a hack! Add `flags 0x8000' to the psm driver to enable it. The psm driver will try to get out of out-of-sync situation by disabling the mouse and immediately enable it again. If you are seeing this out-of-sync problem because of an incompetent(?!) KVM switch, this hack will NOT be good for you. However, if you are occasionally seeing the problem because of lost mouse interrupt, this might help.
2000-12-01 05:26:24 +00:00
| PSM_CONFIG_SYNCHACK \
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
| PSM_CONFIG_NOIDPROBE \
| PSM_CONFIG_NORESET \
| PSM_CONFIG_FORCETAP \
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
| PSM_CONFIG_IGNPORTERROR \
| PSM_CONFIG_HOOKRESUME \
| PSM_CONFIG_INITAFTERSUSPEND)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* other flags (flags) */
Recognize Interlink VersaPad. `Tap' action will be recognized as the button 4. Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
1999-08-17 12:14:13 +00:00
#define PSM_FLAGS_FINGERDOWN 0x0001 /* VersaPad finger down */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* for backward compatibility */
#define OLD_MOUSE_GETHWINFO _IOR('M', 1, old_mousehw_t)
#define OLD_MOUSE_GETMODE _IOR('M', 2, old_mousemode_t)
#define OLD_MOUSE_SETMODE _IOW('M', 3, old_mousemode_t)
typedef struct old_mousehw {
int buttons;
int iftype;
int type;
int hwid;
} old_mousehw_t;
typedef struct old_mousemode {
int protocol;
int rate;
int resolution;
int accelfactor;
} old_mousemode_t;
/* packet formatting function */
Remove __P.
2002-03-20 05:14:42 +00:00
typedef int packetfunc_t(struct psm_softc *, unsigned char *,
int *, int, mousestatus_t *);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* function prototypes */
Remove __P.
2002-03-20 05:14:42 +00:00
static void psmidentify(driver_t *, device_t);
static int psmprobe(device_t);
static int psmattach(device_t);
static int psmdetach(device_t);
static int psmresume(device_t);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static d_open_t psmopen;
static d_close_t psmclose;
static d_read_t psmread;
static d_ioctl_t psmioctl;
static d_poll_t psmpoll;
Remove __P.
2002-03-20 05:14:42 +00:00
static int enable_aux_dev(KBDC);
static int disable_aux_dev(KBDC);
static int get_mouse_status(KBDC, int *, int, int);
static int get_aux_id(KBDC);
static int set_mouse_sampling_rate(KBDC, int);
static int set_mouse_scaling(KBDC, int);
static int set_mouse_resolution(KBDC, int);
static int set_mouse_mode(KBDC);
static int get_mouse_buttons(KBDC);
static int is_a_mouse(int);
static void recover_from_error(KBDC);
static int restore_controller(KBDC, int);
static int doinitialize(struct psm_softc *, mousemode_t *);
static int doopen(struct psm_softc *, int);
static int reinitialize(struct psm_softc *, int);
static char *model_name(int);
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
static void psmsoftintr(void *);
Remove __P.
2002-03-20 05:14:42 +00:00
static void psmintr(void *);
static void psmtimeout(void *);
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
static int timeelapsed(const struct timeval *,
int, int, const struct timeval *);
static void dropqueue(struct psm_softc *);
static void flushpackets(struct psm_softc *);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* vendor specific features */
Remove __P.
2002-03-20 05:14:42 +00:00
typedef int probefunc_t(struct psm_softc *);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
Remove __P.
2002-03-20 05:14:42 +00:00
static int mouse_id_proc1(KBDC, int, int, int *);
static int mouse_ext_command(KBDC, int);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static probefunc_t enable_groller;
static probefunc_t enable_gmouse;
static probefunc_t enable_aglide;
static probefunc_t enable_kmouse;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
static probefunc_t enable_msexplorer;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static probefunc_t enable_msintelli;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
static probefunc_t enable_4dmouse;
static probefunc_t enable_4dplus;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static probefunc_t enable_mmanplus;
Recognize Interlink VersaPad. `Tap' action will be recognized as the button 4. Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
1999-08-17 12:14:13 +00:00
static probefunc_t enable_versapad;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
static int tame_mouse(struct psm_softc *, packetbuf_t *, mousestatus_t *, unsigned char *);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static struct {
int model;
unsigned char syncmask;
int packetsize;
probefunc_t *probefunc;
} vendortype[] = {
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/*
* WARNING: the order of probe is very important. Don't mess it
* unless you know what you are doing.
*/
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{ MOUSE_MODEL_NET, /* Genius NetMouse */
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
0x08, MOUSE_PS2INTELLI_PACKETSIZE, enable_gmouse, },
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{ MOUSE_MODEL_NETSCROLL, /* Genius NetScroll */
0xc8, 6, enable_groller, },
{ MOUSE_MODEL_MOUSEMANPLUS, /* Logitech MouseMan+ */
0x08, MOUSE_PS2_PACKETSIZE, enable_mmanplus, },
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
{ MOUSE_MODEL_EXPLORER, /* Microsoft IntelliMouse Explorer */
0x08, MOUSE_PS2INTELLI_PACKETSIZE, enable_msexplorer, },
{ MOUSE_MODEL_4D, /* A4 Tech 4D Mouse */
0x08, MOUSE_4D_PACKETSIZE, enable_4dmouse, },
{ MOUSE_MODEL_4DPLUS, /* A4 Tech 4D+ Mouse */
0xc8, MOUSE_4DPLUS_PACKETSIZE, enable_4dplus, },
{ MOUSE_MODEL_INTELLI, /* Microsoft IntelliMouse */
0x08, MOUSE_PS2INTELLI_PACKETSIZE, enable_msintelli, },
{ MOUSE_MODEL_GLIDEPOINT, /* ALPS GlidePoint */
0xc0, MOUSE_PS2_PACKETSIZE, enable_aglide, },
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{ MOUSE_MODEL_THINK, /* Kensignton ThinkingMouse */
0x80, MOUSE_PS2_PACKETSIZE, enable_kmouse, },
Recognize Interlink VersaPad. `Tap' action will be recognized as the button 4. Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
1999-08-17 12:14:13 +00:00
{ MOUSE_MODEL_VERSAPAD, /* Interlink electronics VersaPad */
0xe8, MOUSE_PS2VERSA_PACKETSIZE, enable_versapad, },
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{ MOUSE_MODEL_GENERIC,
0xc0, MOUSE_PS2_PACKETSIZE, NULL, },
};
Fix GENERIC_MOUSE_ENTRY. Submitted by: Graham Wheeler <gram@cequrux.com> and gibbs
2000-07-28 03:48:46 +00:00
#define GENERIC_MOUSE_ENTRY ((sizeof(vendortype) / sizeof(*vendortype)) - 1)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* device driver declarateion */
static device_method_t psm_methods[] = {
/* Device interface */
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
DEVMETHOD(device_identify, psmidentify),
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
DEVMETHOD(device_probe, psmprobe),
DEVMETHOD(device_attach, psmattach),
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
DEVMETHOD(device_detach, psmdetach),
- Add the device resume method. It supercedes the existing resume routine which hooks the apm driver. - Rename the PSM_HOOKAPM option to PSM_HOOKRESUME. - Delete unnecessary #include.
1999-12-15 10:04:05 +00:00
DEVMETHOD(device_resume, psmresume),
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{ 0, 0 }
};
static driver_t psm_driver = {
Refine ACPI/PnP BIOS probe/attach routines a bit. - Add workaround for the problematic PnP BIOS which does not assign irq resource for the PS/2 mouse device node; if there is no irq assigned for the PS/2 mouse node, refer to device.hints for an irq number. If we still don't find an irq number in the hints database, use a hard-coded value. - Delete unused ivars. - Bit of clean up in probe/attach. - Add PnP ID for the PS/2 mouse port on some IBM ThinkPad models.
2001-09-15 04:38:20 +00:00
PSM_DRIVER_NAME,
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
psm_methods,
sizeof(struct psm_softc),
};
This commit should be a extensive NO-OP: Reformat and initialize correctly all "struct cdevsw". Initialize the d_maj and d_bmaj fields. The d_reset field was not removed, although it is never used. I used a program to do most of this, so all the files now use the same consistent format. Please keep it that way. Vinum and i4b not modified, patches emailed to respective authors.
1999-05-30 16:53:49 +00:00
static struct cdevsw psm_cdevsw = {
Device megapatch 4/6: Introduce d_version field in struct cdevsw, this must always be initialized to D_VERSION. Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
2004-02-21 21:10:55 +00:00
.d_version = D_VERSION,
.d_flags = D_NEEDGIANT,
Gigacommit to improve device-driver source compatibility between branches: Initialize struct cdevsw using C99 sparse initializtion and remove all initializations to default values. This patch is automatically generated and has been tested by compiling LINT with all the fields in struct cdevsw in reverse order on alpha, sparc64 and i386. Approved by: re(scottl)
2003-03-03 12:15:54 +00:00
.d_open = psmopen,
.d_close = psmclose,
.d_read = psmread,
.d_ioctl = psmioctl,
.d_poll = psmpoll,
.d_name = PSM_DRIVER_NAME,
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
};
/* debug message level */
static int verbose = PSM_DEBUG;
/* device I/O routines */
static int
enable_aux_dev(KBDC kbdc)
{
int res;
res = send_aux_command(kbdc, PSMC_ENABLE_DEV);
if (verbose >= 2)
log(LOG_DEBUG, "psm: ENABLE_DEV return code:%04x\n", res);
return (res == PSM_ACK);
}
static int
disable_aux_dev(KBDC kbdc)
{
int res;
res = send_aux_command(kbdc, PSMC_DISABLE_DEV);
if (verbose >= 2)
log(LOG_DEBUG, "psm: DISABLE_DEV return code:%04x\n", res);
return (res == PSM_ACK);
}
static int
get_mouse_status(KBDC kbdc, int *status, int flag, int len)
{
int cmd;
int res;
int i;
switch (flag) {
case 0:
default:
cmd = PSMC_SEND_DEV_STATUS;
break;
case 1:
cmd = PSMC_SEND_DEV_DATA;
break;
}
empty_aux_buffer(kbdc, 5);
res = send_aux_command(kbdc, cmd);
if (verbose >= 2)
log(LOG_DEBUG, "psm: SEND_AUX_DEV_%s return code:%04x\n",
(flag == 1) ? "DATA" : "STATUS", res);
if (res != PSM_ACK)
return 0;
for (i = 0; i < len; ++i) {
status[i] = read_aux_data(kbdc);
if (status[i] < 0)
break;
}
if (verbose) {
log(LOG_DEBUG, "psm: %s %02x %02x %02x\n",
(flag == 1) ? "data" : "status", status[0], status[1], status[2]);
}
return i;
}
static int
get_aux_id(KBDC kbdc)
{
int res;
int id;
empty_aux_buffer(kbdc, 5);
res = send_aux_command(kbdc, PSMC_SEND_DEV_ID);
if (verbose >= 2)
log(LOG_DEBUG, "psm: SEND_DEV_ID return code:%04x\n", res);
if (res != PSM_ACK)
return (-1);
/* 10ms delay */
DELAY(10000);
id = read_aux_data(kbdc);
if (verbose >= 2)
log(LOG_DEBUG, "psm: device ID: %04x\n", id);
return id;
}
static int
set_mouse_sampling_rate(KBDC kbdc, int rate)
{
int res;
res = send_aux_command_and_data(kbdc, PSMC_SET_SAMPLING_RATE, rate);
if (verbose >= 2)
log(LOG_DEBUG, "psm: SET_SAMPLING_RATE (%d) %04x\n", rate, res);
return ((res == PSM_ACK) ? rate : -1);
}
static int
set_mouse_scaling(KBDC kbdc, int scale)
{
int res;
switch (scale) {
case 1:
default:
scale = PSMC_SET_SCALING11;
break;
case 2:
scale = PSMC_SET_SCALING21;
break;
}
res = send_aux_command(kbdc, scale);
if (verbose >= 2)
log(LOG_DEBUG, "psm: SET_SCALING%s return code:%04x\n",
(scale == PSMC_SET_SCALING21) ? "21" : "11", res);
return (res == PSM_ACK);
}
/* `val' must be 0 through PSMD_MAX_RESOLUTION */
static int
set_mouse_resolution(KBDC kbdc, int val)
{
int res;
res = send_aux_command_and_data(kbdc, PSMC_SET_RESOLUTION, val);
if (verbose >= 2)
log(LOG_DEBUG, "psm: SET_RESOLUTION (%d) %04x\n", val, res);
return ((res == PSM_ACK) ? val : -1);
}
/*
* NOTE: once `set_mouse_mode()' is called, the mouse device must be
* re-enabled by calling `enable_aux_dev()'
*/
static int
set_mouse_mode(KBDC kbdc)
{
int res;
res = send_aux_command(kbdc, PSMC_SET_STREAM_MODE);
if (verbose >= 2)
log(LOG_DEBUG, "psm: SET_STREAM_MODE return code:%04x\n", res);
return (res == PSM_ACK);
}
static int
get_mouse_buttons(KBDC kbdc)
{
int c = 2; /* assume two buttons by default */
int status[3];
/*
* NOTE: a special sequence to obtain Logitech Mouse specific
* information: set resolution to 25 ppi, set scaling to 1:1, set
* scaling to 1:1, set scaling to 1:1. Then the second byte of the
* mouse status bytes is the number of available buttons.
* Some manufactures also support this sequence.
*/
if (set_mouse_resolution(kbdc, PSMD_RES_LOW) != PSMD_RES_LOW)
return c;
if (set_mouse_scaling(kbdc, 1) && set_mouse_scaling(kbdc, 1)
&& set_mouse_scaling(kbdc, 1)
&& (get_mouse_status(kbdc, status, 0, 3) >= 3)) {
if (status[1] != 0)
return status[1];
}
return c;
}
/* misc subroutines */
/*
* Someday, I will get the complete list of valid pointing devices and
* their IDs... XXX
*/
static int
is_a_mouse(int id)
{
#if 0
static int valid_ids[] = {
PSM_MOUSE_ID, /* mouse */
PSM_BALLPOINT_ID, /* ballpoint device */
PSM_INTELLI_ID, /* Intellimouse */
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
PSM_EXPLORER_ID, /* Intellimouse Explorer */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
-1 /* end of table */
};
int i;
for (i = 0; valid_ids[i] >= 0; ++i)
if (valid_ids[i] == id)
return TRUE;
return FALSE;
#else
return TRUE;
#endif
}
static char *
model_name(int model)
{
static struct {
int model_code;
char *model_name;
} models[] = {
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
{ MOUSE_MODEL_NETSCROLL, "NetScroll" },
{ MOUSE_MODEL_NET, "NetMouse/NetScroll Optical" },
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{ MOUSE_MODEL_GLIDEPOINT, "GlidePoint" },
{ MOUSE_MODEL_THINK, "ThinkingMouse" },
{ MOUSE_MODEL_INTELLI, "IntelliMouse" },
{ MOUSE_MODEL_MOUSEMANPLUS, "MouseMan+" },
Recognize Interlink VersaPad. `Tap' action will be recognized as the button 4. Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
1999-08-17 12:14:13 +00:00
{ MOUSE_MODEL_VERSAPAD, "VersaPad" },
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
{ MOUSE_MODEL_EXPLORER, "IntelliMouse Explorer" },
{ MOUSE_MODEL_4D, "4D Mouse" },
{ MOUSE_MODEL_4DPLUS, "4D+ Mouse" },
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{ MOUSE_MODEL_GENERIC, "Generic PS/2 mouse" },
{ MOUSE_MODEL_UNKNOWN, NULL },
};
int i;
for (i = 0; models[i].model_code != MOUSE_MODEL_UNKNOWN; ++i) {
if (models[i].model_code == model)
return models[i].model_name;
}
return "Unknown";
}
static void
recover_from_error(KBDC kbdc)
{
/* discard anything left in the output buffer */
empty_both_buffers(kbdc, 10);
#if 0
/*
* NOTE: KBDC_RESET_KBD may not restore the communication between the
* keyboard and the controller.
*/
reset_kbd(kbdc);
#else
/*
* NOTE: somehow diagnostic and keyboard port test commands bring the
* keyboard back.
*/
if (!test_controller(kbdc))
log(LOG_ERR, "psm: keyboard controller failed.\n");
/* if there isn't a keyboard in the system, the following error is OK */
if (test_kbd_port(kbdc) != 0) {
if (verbose)
log(LOG_ERR, "psm: keyboard port failed.\n");
}
#endif
}
static int
restore_controller(KBDC kbdc, int command_byte)
{
empty_both_buffers(kbdc, 10);
if (!set_controller_command_byte(kbdc, 0xff, command_byte)) {
log(LOG_ERR, "psm: failed to restore the keyboard controller "
"command byte.\n");
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
empty_both_buffers(kbdc, 10);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return FALSE;
} else {
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
empty_both_buffers(kbdc, 10);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return TRUE;
}
}
/*
* Re-initialize the aux port and device. The aux port must be enabled
* and its interrupt must be disabled before calling this routine.
* The aux device will be disabled before returning.
* The keyboard controller must be locked via `kbdc_lock()' before
* calling this routine.
*/
static int
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
doinitialize(struct psm_softc *sc, mousemode_t *mode)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{
KBDC kbdc = sc->kbdc;
int stat[3];
int i;
switch((i = test_aux_port(kbdc))) {
case 1: /* ignore this error */
case PSM_ACK:
if (verbose)
log(LOG_DEBUG, "psm%d: strange result for test aux port (%d).\n",
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->unit, i);
Replace various spelling with FALLTHROUGH which is lint()able
2002-08-25 13:23:09 +00:00
/* FALLTHROUGH */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
case 0: /* no error */
break;
case -1: /* time out */
default: /* error */
recover_from_error(kbdc);
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
if (sc->config & PSM_CONFIG_IGNPORTERROR)
break;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
log(LOG_ERR, "psm%d: the aux port is not functioning (%d).\n",
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->unit, i);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return FALSE;
}
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
if (sc->config & PSM_CONFIG_NORESET) {
/*
* Don't try to reset the pointing device. It may possibly be
* left in the unknown state, though...
*/
} else {
/*
* NOTE: some controllers appears to hang the `keyboard' when
* the aux port doesn't exist and `PSMC_RESET_DEV' is issued.
*/
if (!reset_aux_dev(kbdc)) {
recover_from_error(kbdc);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
log(LOG_ERR, "psm%d: failed to reset the aux device.\n", sc->unit);
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
return FALSE;
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
/*
* both the aux port and the aux device is functioning, see
* if the device can be enabled.
*/
if (!enable_aux_dev(kbdc) || !disable_aux_dev(kbdc)) {
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
log(LOG_ERR, "psm%d: failed to enable the aux device.\n", sc->unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return FALSE;
}
empty_both_buffers(kbdc, 10); /* remove stray data if any */
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
if (sc->config & PSM_CONFIG_NOIDPROBE) {
i = GENERIC_MOUSE_ENTRY;
} else {
/* FIXME: hardware ID, mouse buttons? */
/* other parameters */
for (i = 0; vendortype[i].probefunc != NULL; ++i) {
if ((*vendortype[i].probefunc)(sc)) {
if (verbose >= 2)
log(LOG_ERR, "psm%d: found %s\n",
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->unit, model_name(vendortype[i].model));
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
break;
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
}
sc->hw.model = vendortype[i].model;
sc->mode.packetsize = vendortype[i].packetsize;
/* set mouse parameters */
if (mode != (mousemode_t *)NULL) {
if (mode->rate > 0)
mode->rate = set_mouse_sampling_rate(kbdc, mode->rate);
if (mode->resolution >= 0)
mode->resolution = set_mouse_resolution(kbdc, mode->resolution);
set_mouse_scaling(kbdc, 1);
set_mouse_mode(kbdc);
}
/* request a data packet and extract sync. bits */
if (get_mouse_status(kbdc, stat, 1, 3) < 3) {
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
log(LOG_DEBUG, "psm%d: failed to get data (doinitialize).\n",
sc->unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
sc->mode.syncmask[0] = 0;
} else {
sc->mode.syncmask[1] = stat[0] & sc->mode.syncmask[0]; /* syncbits */
/* the NetScroll Mouse will send three more bytes... Ignore them */
empty_aux_buffer(kbdc, 5);
}
/* just check the status of the mouse */
if (get_mouse_status(kbdc, stat, 0, 3) < 3)
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
log(LOG_DEBUG, "psm%d: failed to get status (doinitialize).\n",
sc->unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return TRUE;
}
static int
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
doopen(struct psm_softc *sc, int command_byte)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{
int stat[3];
/* enable the mouse device */
if (!enable_aux_dev(sc->kbdc)) {
/* MOUSE ERROR: failed to enable the mouse because:
* 1) the mouse is faulty,
* 2) the mouse has been removed(!?)
* In the latter case, the keyboard may have hung, and need
* recovery procedure...
*/
recover_from_error(sc->kbdc);
#if 0
/* FIXME: we could reset the mouse here and try to enable
* it again. But it will take long time and it's not a good
* idea to disable the keyboard that long...
*/
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
if (!doinitialize(sc, &sc->mode) || !enable_aux_dev(sc->kbdc)) {
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
recover_from_error(sc->kbdc);
#else
{
#endif
restore_controller(sc->kbdc, command_byte);
/* mark this device is no longer available */
sc->state &= ~PSM_VALID;
log(LOG_ERR, "psm%d: failed to enable the device (doopen).\n",
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return (EIO);
}
}
if (get_mouse_status(sc->kbdc, stat, 0, 3) < 3)
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
log(LOG_DEBUG, "psm%d: failed to get status (doopen).\n", sc->unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* enable the aux port and interrupt */
if (!set_controller_command_byte(sc->kbdc,
kbdc_get_device_mask(sc->kbdc),
(command_byte & KBD_KBD_CONTROL_BITS)
| KBD_ENABLE_AUX_PORT | KBD_ENABLE_AUX_INT)) {
/* CONTROLLER ERROR */
disable_aux_dev(sc->kbdc);
restore_controller(sc->kbdc, command_byte);
log(LOG_ERR, "psm%d: failed to enable the aux interrupt (doopen).\n",
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return (EIO);
}
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* start the watchdog timer */
sc->watchdog = FALSE;
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->callout = timeout(psmtimeout, (void *)(uintptr_t)sc, hz*2);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return (0);
}
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
static int
reinitialize(struct psm_softc *sc, int doinit)
{
int err;
int c;
int s;
/* don't let anybody mess with the aux device */
if (!kbdc_lock(sc->kbdc, TRUE))
return (EIO);
s = spltty();
/* block our watchdog timer */
sc->watchdog = FALSE;
untimeout(psmtimeout, (void *)(uintptr_t)sc, sc->callout);
callout_handle_init(&sc->callout);
/* save the current controller command byte */
empty_both_buffers(sc->kbdc, 10);
c = get_controller_command_byte(sc->kbdc);
if (verbose >= 2)
log(LOG_DEBUG, "psm%d: current command byte: %04x (reinitialize).\n",
sc->unit, c);
/* enable the aux port but disable the aux interrupt and the keyboard */
if ((c == -1) || !set_controller_command_byte(sc->kbdc,
kbdc_get_device_mask(sc->kbdc),
KBD_DISABLE_KBD_PORT | KBD_DISABLE_KBD_INT
| KBD_ENABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
/* CONTROLLER ERROR */
splx(s);
kbdc_lock(sc->kbdc, FALSE);
log(LOG_ERR, "psm%d: unable to set the command byte (reinitialize).\n",
sc->unit);
return (EIO);
}
/* flush any data */
if (sc->state & PSM_VALID) {
disable_aux_dev(sc->kbdc); /* this may fail; but never mind... */
empty_aux_buffer(sc->kbdc, 10);
}
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
flushpackets(sc);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->syncerrors = 0;
/* try to detect the aux device; are you still there? */
err = 0;
if (doinit) {
if (doinitialize(sc, &sc->mode)) {
/* yes */
sc->state |= PSM_VALID;
} else {
/* the device has gone! */
restore_controller(sc->kbdc, c);
sc->state &= ~PSM_VALID;
log(LOG_ERR, "psm%d: the aux device has gone! (reinitialize).\n",
sc->unit);
err = ENXIO;
}
}
splx(s);
/* restore the driver state */
if ((sc->state & PSM_OPEN) && (err == 0)) {
/* enable the aux device and the port again */
err = doopen(sc, c);
if (err != 0)
log(LOG_ERR, "psm%d: failed to enable the device (reinitialize).\n",
sc->unit);
} else {
/* restore the keyboard port and disable the aux port */
if (!set_controller_command_byte(sc->kbdc,
kbdc_get_device_mask(sc->kbdc),
(c & KBD_KBD_CONTROL_BITS)
| KBD_DISABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
/* CONTROLLER ERROR */
log(LOG_ERR, "psm%d: failed to disable the aux port (reinitialize).\n",
sc->unit);
err = EIO;
}
}
kbdc_lock(sc->kbdc, FALSE);
return (err);
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* psm driver entry points */
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
static void
psmidentify(driver_t *driver, device_t parent)
{
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
device_t psmc;
device_t psm;
u_long irq;
int unit;
unit = device_get_unit(parent);
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
/* always add at least one child */
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
psm = BUS_ADD_CHILD(parent, KBDC_RID_AUX, driver->name, unit);
if (psm == NULL)
return;
irq = bus_get_resource_start(psm, SYS_RES_IRQ, KBDC_RID_AUX);
if (irq > 0)
return;
/*
* If the PS/2 mouse device has already been reported by ACPI or
* PnP BIOS, obtain the IRQ resource from it.
* (See psmcpnp_attach() below.)
*/
psmc = device_find_child(device_get_parent(parent),
PSMCPNP_DRIVER_NAME, unit);
if (psmc == NULL)
return;
irq = bus_get_resource_start(psmc, SYS_RES_IRQ, 0);
if (irq <= 0)
return;
bus_set_resource(psm, SYS_RES_IRQ, KBDC_RID_AUX, irq, 1);
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
}
wrap macro in do {...} while(0)
2003-05-31 21:11:51 +00:00
#define endprobe(v) do { if (bootverbose) \
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
--verbose; \
kbdc_set_device_mask(sc->kbdc, mask); \
kbdc_lock(sc->kbdc, FALSE); \
return (v); \
wrap macro in do {...} while(0)
2003-05-31 21:11:51 +00:00
} while (0)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static int
psmprobe(device_t dev)
{
int unit = device_get_unit(dev);
struct psm_softc *sc = device_get_softc(dev);
int stat[3];
int command_byte;
int mask;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
int rid;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
int i;
#if 0
kbdc_debug(TRUE);
#endif
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
/* see if IRQ is available */
rid = KBDC_RID_AUX;
Convert callers to the new bus_alloc_resource_any(9) API. Submitted by: Mark Santcroos <marks@ripe.net> Reviewed by: imp, dfr, bde
2004-03-17 17:50:55 +00:00
sc->intr = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid,
RF_SHAREABLE | RF_ACTIVE);
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
if (sc->intr == NULL) {
if (bootverbose)
device_printf(dev, "unable to allocate IRQ\n");
return (ENXIO);
}
bus_release_resource(dev, SYS_RES_IRQ, rid, sc->intr);
Update the alpha port to use the new syscons. Submitted by: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> (partly)
1999-01-23 16:53:30 +00:00
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->unit = unit;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
sc->kbdc = atkbdc_open(device_get_unit(device_get_parent(dev)));
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
sc->config = device_get_flags(dev) & PSM_CONFIG_FLAGS;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* XXX: for backward compatibility */
#if defined(PSM_HOOKRESUME) || defined(PSM_HOOKAPM)
sc->config |=
#ifdef PSM_RESETAFTERSUSPEND
PSM_CONFIG_HOOKRESUME | PSM_CONFIG_INITAFTERSUSPEND;
#else
PSM_CONFIG_HOOKRESUME;
#endif
#endif /* PSM_HOOKRESUME | PSM_HOOKAPM */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
sc->flags = 0;
if (bootverbose)
++verbose;
Update the alpha port to use the new syscons. Submitted by: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> (partly)
1999-01-23 16:53:30 +00:00
device_set_desc(dev, "PS/2 Mouse");
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if (!kbdc_lock(sc->kbdc, TRUE)) {
printf("psm%d: unable to lock the controller.\n", unit);
if (bootverbose)
--verbose;
return (ENXIO);
}
/*
* NOTE: two bits in the command byte controls the operation of the
* aux port (mouse port): the aux port disable bit (bit 5) and the aux
* port interrupt (IRQ 12) enable bit (bit 2).
*/
/* discard anything left after the keyboard initialization */
empty_both_buffers(sc->kbdc, 10);
/* save the current command byte; it will be used later */
mask = kbdc_get_device_mask(sc->kbdc) & ~KBD_AUX_CONTROL_BITS;
command_byte = get_controller_command_byte(sc->kbdc);
if (verbose)
printf("psm%d: current command byte:%04x\n", unit, command_byte);
if (command_byte == -1) {
/* CONTROLLER ERROR */
printf("psm%d: unable to get the current command byte value.\n",
unit);
endprobe(ENXIO);
}
/*
* disable the keyboard port while probing the aux port, which must be
* enabled during this routine
*/
if (!set_controller_command_byte(sc->kbdc,
KBD_KBD_CONTROL_BITS | KBD_AUX_CONTROL_BITS,
KBD_DISABLE_KBD_PORT | KBD_DISABLE_KBD_INT
| KBD_ENABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
/*
* this is CONTROLLER ERROR; I don't know how to recover
* from this error...
*/
restore_controller(sc->kbdc, command_byte);
printf("psm%d: unable to set the command byte.\n", unit);
endprobe(ENXIO);
}
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
write_controller_command(sc->kbdc, KBDC_ENABLE_AUX_PORT);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/*
* NOTE: `test_aux_port()' is designed to return with zero if the aux
* port exists and is functioning. However, some controllers appears
* to respond with zero even when the aux port doesn't exist. (It may
* be that this is only the case when the controller DOES have the aux
* port but the port is not wired on the motherboard.) The keyboard
* controllers without the port, such as the original AT, are
* supporsed to return with an error code or simply time out. In any
* case, we have to continue probing the port even when the controller
* passes this test.
*
* XXX: some controllers erroneously return the error code 1 when
* it has the perfectly functional aux port. We have to ignore this
* error code. Even if the controller HAS error with the aux port,
* it will be detected later...
* XXX: another incompatible controller returns PSM_ACK (0xfa)...
*/
switch ((i = test_aux_port(sc->kbdc))) {
case 1: /* ignore this error */
case PSM_ACK:
if (verbose)
printf("psm%d: strange result for test aux port (%d).\n",
unit, i);
Replace various spelling with FALLTHROUGH which is lint()able
2002-08-25 13:23:09 +00:00
/* FALLTHROUGH */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
case 0: /* no error */
break;
case -1: /* time out */
default: /* error */
recover_from_error(sc->kbdc);
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
if (sc->config & PSM_CONFIG_IGNPORTERROR)
break;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
restore_controller(sc->kbdc, command_byte);
if (verbose)
printf("psm%d: the aux port is not functioning (%d).\n",
unit, i);
endprobe(ENXIO);
}
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
if (sc->config & PSM_CONFIG_NORESET) {
/*
* Don't try to reset the pointing device. It may possibly be
* left in the unknown state, though...
*/
} else {
/*
* NOTE: some controllers appears to hang the `keyboard' when the aux
* port doesn't exist and `PSMC_RESET_DEV' is issued.
Reset the PSM aux device twice to help pierce through some KVM's to get the correct data from the attached mouse. Multiple resets should be harmless, but just in case, the second one is non-fatal and is just ignored.
2003-07-07 05:40:13 +00:00
*
* Attempt to reset the controller twice -- this helps
* pierce through some KVM switches. The second reset
* is non-fatal.
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
*/
if (!reset_aux_dev(sc->kbdc)) {
recover_from_error(sc->kbdc);
restore_controller(sc->kbdc, command_byte);
if (verbose)
printf("psm%d: failed to reset the aux device.\n", unit);
endprobe(ENXIO);
Reset the PSM aux device twice to help pierce through some KVM's to get the correct data from the attached mouse. Multiple resets should be harmless, but just in case, the second one is non-fatal and is just ignored.
2003-07-07 05:40:13 +00:00
} else if (!reset_aux_dev(sc->kbdc)) {
recover_from_error(sc->kbdc);
if (verbose >= 2)
printf("psm%d: failed to reset the aux device (2).\n",
unit);
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/*
* both the aux port and the aux device is functioning, see if the
* device can be enabled. NOTE: when enabled, the device will start
* sending data; we shall immediately disable the device once we know
* the device can be enabled.
*/
if (!enable_aux_dev(sc->kbdc) || !disable_aux_dev(sc->kbdc)) {
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
/* MOUSE ERROR */
recover_from_error(sc->kbdc);
restore_controller(sc->kbdc, command_byte);
if (verbose)
printf("psm%d: failed to enable the aux device.\n", unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
endprobe(ENXIO);
}
/* save the default values after reset */
if (get_mouse_status(sc->kbdc, stat, 0, 3) >= 3) {
sc->dflt_mode.rate = sc->mode.rate = stat[2];
sc->dflt_mode.resolution = sc->mode.resolution = stat[1];
} else {
sc->dflt_mode.rate = sc->mode.rate = -1;
sc->dflt_mode.resolution = sc->mode.resolution = -1;
}
/* hardware information */
sc->hw.iftype = MOUSE_IF_PS2;
/* verify the device is a mouse */
sc->hw.hwid = get_aux_id(sc->kbdc);
if (!is_a_mouse(sc->hw.hwid)) {
restore_controller(sc->kbdc, command_byte);
if (verbose)
printf("psm%d: unknown device type (%d).\n", unit, sc->hw.hwid);
endprobe(ENXIO);
}
switch (sc->hw.hwid) {
case PSM_BALLPOINT_ID:
sc->hw.type = MOUSE_TRACKBALL;
break;
case PSM_MOUSE_ID:
case PSM_INTELLI_ID:
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
case PSM_EXPLORER_ID:
case PSM_4DMOUSE_ID:
case PSM_4DPLUS_ID:
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
sc->hw.type = MOUSE_MOUSE;
break;
default:
sc->hw.type = MOUSE_UNKNOWN;
break;
}
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
if (sc->config & PSM_CONFIG_NOIDPROBE) {
sc->hw.buttons = 2;
i = GENERIC_MOUSE_ENTRY;
} else {
/* # of buttons */
sc->hw.buttons = get_mouse_buttons(sc->kbdc);
/* other parameters */
for (i = 0; vendortype[i].probefunc != NULL; ++i) {
if ((*vendortype[i].probefunc)(sc)) {
if (verbose >= 2)
printf("psm%d: found %s\n",
unit, model_name(vendortype[i].model));
break;
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
}
sc->hw.model = vendortype[i].model;
sc->dflt_mode.level = PSM_LEVEL_BASE;
sc->dflt_mode.packetsize = MOUSE_PS2_PACKETSIZE;
sc->dflt_mode.accelfactor = (sc->config & PSM_CONFIG_ACCEL) >> 4;
if (sc->config & PSM_CONFIG_NOCHECKSYNC)
sc->dflt_mode.syncmask[0] = 0;
else
sc->dflt_mode.syncmask[0] = vendortype[i].syncmask;
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
if (sc->config & PSM_CONFIG_FORCETAP)
sc->mode.syncmask[0] &= ~MOUSE_PS2_TAP;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
sc->dflt_mode.syncmask[1] = 0; /* syncbits */
sc->mode = sc->dflt_mode;
sc->mode.packetsize = vendortype[i].packetsize;
/* set mouse parameters */
Implement a kludge for some wheeled mice for which infamous "psmintr: out of sync..." messages is generated and the wheel movement is not recognized. The trick is found by Takashi Nishida.
1999-07-12 13:40:21 +00:00
#if 0
/*
* A version of Logitech FirstMouse+ won't report wheel movement,
* if SET_DEFAULTS is sent... Don't use this command.
* This fix was found by Takashi Nishida.
*/
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
i = send_aux_command(sc->kbdc, PSMC_SET_DEFAULTS);
if (verbose >= 2)
printf("psm%d: SET_DEFAULTS return code:%04x\n", unit, i);
Implement a kludge for some wheeled mice for which infamous "psmintr: out of sync..." messages is generated and the wheel movement is not recognized. The trick is found by Takashi Nishida.
1999-07-12 13:40:21 +00:00
#endif
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if (sc->config & PSM_CONFIG_RESOLUTION) {
sc->mode.resolution
= set_mouse_resolution(sc->kbdc,
Implement a kludge for some wheeled mice for which infamous "psmintr: out of sync..." messages is generated and the wheel movement is not recognized. The trick is found by Takashi Nishida.
1999-07-12 13:40:21 +00:00
(sc->config & PSM_CONFIG_RESOLUTION) - 1);
} else if (sc->mode.resolution >= 0) {
sc->mode.resolution
= set_mouse_resolution(sc->kbdc, sc->dflt_mode.resolution);
}
if (sc->mode.rate > 0) {
sc->mode.rate = set_mouse_sampling_rate(sc->kbdc, sc->dflt_mode.rate);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
Implement a kludge for some wheeled mice for which infamous "psmintr: out of sync..." messages is generated and the wheel movement is not recognized. The trick is found by Takashi Nishida.
1999-07-12 13:40:21 +00:00
set_mouse_scaling(sc->kbdc, 1);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* request a data packet and extract sync. bits */
if (get_mouse_status(sc->kbdc, stat, 1, 3) < 3) {
printf("psm%d: failed to get data.\n", unit);
sc->mode.syncmask[0] = 0;
} else {
sc->mode.syncmask[1] = stat[0] & sc->mode.syncmask[0]; /* syncbits */
/* the NetScroll Mouse will send three more bytes... Ignore them */
empty_aux_buffer(sc->kbdc, 5);
}
/* just check the status of the mouse */
/*
* NOTE: XXX there are some arcane controller/mouse combinations out
* there, which hung the controller unless there is data transmission
* after ACK from the mouse.
*/
if (get_mouse_status(sc->kbdc, stat, 0, 3) < 3) {
printf("psm%d: failed to get status.\n", unit);
} else {
/*
* When in its native mode, some mice operate with different
* default parameters than in the PS/2 compatible mode.
*/
sc->dflt_mode.rate = sc->mode.rate = stat[2];
sc->dflt_mode.resolution = sc->mode.resolution = stat[1];
}
/* disable the aux port for now... */
if (!set_controller_command_byte(sc->kbdc,
KBD_KBD_CONTROL_BITS | KBD_AUX_CONTROL_BITS,
(command_byte & KBD_KBD_CONTROL_BITS)
| KBD_DISABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
/*
* this is CONTROLLER ERROR; I don't know the proper way to
* recover from this error...
*/
restore_controller(sc->kbdc, command_byte);
printf("psm%d: unable to set the command byte.\n", unit);
endprobe(ENXIO);
}
/* done */
kbdc_set_device_mask(sc->kbdc, mask | KBD_AUX_CONTROL_BITS);
kbdc_lock(sc->kbdc, FALSE);
return (0);
}
static int
psmattach(device_t dev)
{
int unit = device_get_unit(dev);
struct psm_softc *sc = device_get_softc(dev);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
int error;
int rid;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* Setup initial state */
sc->state = PSM_VALID;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
callout_handle_init(&sc->callout);
/* Setup our interrupt handler */
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
rid = KBDC_RID_AUX;
Convert callers to the new bus_alloc_resource_any(9) API. Submitted by: Mark Santcroos <marks@ripe.net> Reviewed by: imp, dfr, bde
2004-03-17 17:50:55 +00:00
sc->intr = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid,
RF_SHAREABLE | RF_ACTIVE);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
if (sc->intr == NULL)
return (ENXIO);
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
error = bus_setup_intr(dev, sc->intr, INTR_TYPE_TTY, psmintr, sc, &sc->ih);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
if (error) {
bus_release_resource(dev, SYS_RES_IRQ, rid, sc->intr);
return (error);
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* Done */
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
sc->dev = make_dev(&psm_cdevsw, PSM_MKMINOR(unit, FALSE), 0, 0, 0666,
"psm%d", unit);
sc->bdev = make_dev(&psm_cdevsw, PSM_MKMINOR(unit, TRUE), 0, 0, 0666,
"bpsm%d", unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if (!verbose) {
printf("psm%d: model %s, device ID %d\n",
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
unit, model_name(sc->hw.model), sc->hw.hwid & 0x00ff);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
} else {
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
printf("psm%d: model %s, device ID %d-%02x, %d buttons\n",
unit, model_name(sc->hw.model),
sc->hw.hwid & 0x00ff, sc->hw.hwid >> 8, sc->hw.buttons);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
printf("psm%d: config:%08x, flags:%08x, packet size:%d\n",
unit, sc->config, sc->flags, sc->mode.packetsize);
printf("psm%d: syncmask:%02x, syncbits:%02x\n",
unit, sc->mode.syncmask[0], sc->mode.syncmask[1]);
}
if (bootverbose)
--verbose;
return (0);
}
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
static int
psmdetach(device_t dev)
{
struct psm_softc *sc;
int rid;
sc = device_get_softc(dev);
if (sc->state & PSM_OPEN)
return EBUSY;
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
rid = KBDC_RID_AUX;
bus_teardown_intr(dev, sc->intr, sc->ih);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
bus_release_resource(dev, SYS_RES_IRQ, rid, sc->intr);
destroy_dev(sc->dev);
destroy_dev(sc->bdev);
return 0;
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
psmopen(struct cdev *dev, int flag, int fmt, struct thread *td)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{
int unit = PSM_UNIT(dev);
struct psm_softc *sc;
int command_byte;
int err;
int s;
/* Get device data */
sc = PSM_SOFTC(unit);
if ((sc == NULL) || (sc->state & PSM_VALID) == 0)
/* the device is no longer valid/functioning */
return (ENXIO);
/* Disallow multiple opens */
if (sc->state & PSM_OPEN)
return (EBUSY);
device_busy(devclass_get_device(psm_devclass, unit));
/* Initialize state */
sc->mode.level = sc->dflt_mode.level;
sc->mode.protocol = sc->dflt_mode.protocol;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
sc->watchdog = FALSE;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* flush the event queue */
sc->queue.count = 0;
sc->queue.head = 0;
sc->queue.tail = 0;
sc->status.flags = 0;
sc->status.button = 0;
sc->status.obutton = 0;
sc->status.dx = 0;
sc->status.dy = 0;
sc->status.dz = 0;
sc->button = 0;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
sc->pqueue_start = 0;
sc->pqueue_end = 0;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* empty input buffer */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
flushpackets(sc);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->syncerrors = 0;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* don't let timeout routines in the keyboard driver to poll the kbdc */
if (!kbdc_lock(sc->kbdc, TRUE))
return (EIO);
/* save the current controller command byte */
s = spltty();
command_byte = get_controller_command_byte(sc->kbdc);
/* enable the aux port and temporalily disable the keyboard */
if ((command_byte == -1)
|| !set_controller_command_byte(sc->kbdc,
kbdc_get_device_mask(sc->kbdc),
KBD_DISABLE_KBD_PORT | KBD_DISABLE_KBD_INT
| KBD_ENABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
/* CONTROLLER ERROR; do you know how to get out of this? */
kbdc_lock(sc->kbdc, FALSE);
splx(s);
log(LOG_ERR, "psm%d: unable to set the command byte (psmopen).\n",
unit);
return (EIO);
}
/*
* Now that the keyboard controller is told not to generate
* the keyboard and mouse interrupts, call `splx()' to allow
* the other tty interrupts. The clock interrupt may also occur,
* but timeout routines will be blocked by the poll flag set
* via `kbdc_lock()'
*/
splx(s);
/* enable the mouse device */
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
err = doopen(sc, command_byte);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* done */
if (err == 0)
sc->state |= PSM_OPEN;
kbdc_lock(sc->kbdc, FALSE);
return (err);
}
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
psmclose(struct cdev *dev, int flag, int fmt, struct thread *td)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{
int unit = PSM_UNIT(dev);
struct psm_softc *sc = PSM_SOFTC(unit);
int stat[3];
int command_byte;
int s;
/* don't let timeout routines in the keyboard driver to poll the kbdc */
if (!kbdc_lock(sc->kbdc, TRUE))
return (EIO);
/* save the current controller command byte */
s = spltty();
command_byte = get_controller_command_byte(sc->kbdc);
if (command_byte == -1) {
kbdc_lock(sc->kbdc, FALSE);
splx(s);
return (EIO);
}
/* disable the aux interrupt and temporalily disable the keyboard */
if (!set_controller_command_byte(sc->kbdc,
kbdc_get_device_mask(sc->kbdc),
KBD_DISABLE_KBD_PORT | KBD_DISABLE_KBD_INT
| KBD_ENABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
log(LOG_ERR, "psm%d: failed to disable the aux int (psmclose).\n",
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* CONTROLLER ERROR;
* NOTE: we shall force our way through. Because the only
* ill effect we shall see is that we may not be able
* to read ACK from the mouse, and it doesn't matter much
* so long as the mouse will accept the DISABLE command.
*/
}
splx(s);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* stop the watchdog timer */
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
untimeout(psmtimeout, (void *)(uintptr_t)sc, sc->callout);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
callout_handle_init(&sc->callout);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* remove anything left in the output buffer */
empty_aux_buffer(sc->kbdc, 10);
/* disable the aux device, port and interrupt */
if (sc->state & PSM_VALID) {
if (!disable_aux_dev(sc->kbdc)) {
/* MOUSE ERROR;
* NOTE: we don't return error and continue, pretending
* we have successfully disabled the device. It's OK because
* the interrupt routine will discard any data from the mouse
* hereafter.
*/
log(LOG_ERR, "psm%d: failed to disable the device (psmclose).\n",
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
if (get_mouse_status(sc->kbdc, stat, 0, 3) < 3)
log(LOG_DEBUG, "psm%d: failed to get status (psmclose).\n",
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
if (!set_controller_command_byte(sc->kbdc,
kbdc_get_device_mask(sc->kbdc),
(command_byte & KBD_KBD_CONTROL_BITS)
| KBD_DISABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
/* CONTROLLER ERROR;
* we shall ignore this error; see the above comment.
*/
log(LOG_ERR, "psm%d: failed to disable the aux port (psmclose).\n",
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
/* remove anything left in the output buffer */
empty_aux_buffer(sc->kbdc, 10);
/* close is almost always successful */
sc->state &= ~PSM_OPEN;
kbdc_lock(sc->kbdc, FALSE);
device_unbusy(devclass_get_device(psm_devclass, unit));
return (0);
}
static int
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
tame_mouse(struct psm_softc *sc, packetbuf_t *pb, mousestatus_t *status, unsigned char *buf)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{
static unsigned char butmapps2[8] = {
0,
MOUSE_PS2_BUTTON1DOWN,
MOUSE_PS2_BUTTON2DOWN,
MOUSE_PS2_BUTTON1DOWN | MOUSE_PS2_BUTTON2DOWN,
MOUSE_PS2_BUTTON3DOWN,
MOUSE_PS2_BUTTON1DOWN | MOUSE_PS2_BUTTON3DOWN,
MOUSE_PS2_BUTTON2DOWN | MOUSE_PS2_BUTTON3DOWN,
MOUSE_PS2_BUTTON1DOWN | MOUSE_PS2_BUTTON2DOWN | MOUSE_PS2_BUTTON3DOWN,
};
static unsigned char butmapmsc[8] = {
MOUSE_MSC_BUTTON1UP | MOUSE_MSC_BUTTON2UP | MOUSE_MSC_BUTTON3UP,
MOUSE_MSC_BUTTON2UP | MOUSE_MSC_BUTTON3UP,
MOUSE_MSC_BUTTON1UP | MOUSE_MSC_BUTTON3UP,
MOUSE_MSC_BUTTON3UP,
MOUSE_MSC_BUTTON1UP | MOUSE_MSC_BUTTON2UP,
MOUSE_MSC_BUTTON2UP,
MOUSE_MSC_BUTTON1UP,
0,
};
int mapped;
int i;
if (sc->mode.level == PSM_LEVEL_BASE) {
mapped = status->button & ~MOUSE_BUTTON4DOWN;
if (status->button & MOUSE_BUTTON4DOWN)
mapped |= MOUSE_BUTTON1DOWN;
status->button = mapped;
buf[0] = MOUSE_PS2_SYNC | butmapps2[mapped & MOUSE_STDBUTTONS];
- GC a few more hand-rolled 'abs' macros. - GC a few hand-rolled min()/max() macros while I'm here.
2003-01-15 02:15:57 +00:00
i = imax(imin(status->dx, 255), -256);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if (i < 0)
buf[0] |= MOUSE_PS2_XNEG;
buf[1] = i;
- GC a few more hand-rolled 'abs' macros. - GC a few hand-rolled min()/max() macros while I'm here.
2003-01-15 02:15:57 +00:00
i = imax(imin(status->dy, 255), -256);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if (i < 0)
buf[0] |= MOUSE_PS2_YNEG;
buf[2] = i;
return MOUSE_PS2_PACKETSIZE;
} else if (sc->mode.level == PSM_LEVEL_STANDARD) {
buf[0] = MOUSE_MSC_SYNC | butmapmsc[status->button & MOUSE_STDBUTTONS];
- GC a few more hand-rolled 'abs' macros. - GC a few hand-rolled min()/max() macros while I'm here.
2003-01-15 02:15:57 +00:00
i = imax(imin(status->dx, 255), -256);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
buf[1] = i >> 1;
buf[3] = i - buf[1];
- GC a few more hand-rolled 'abs' macros. - GC a few hand-rolled min()/max() macros while I'm here.
2003-01-15 02:15:57 +00:00
i = imax(imin(status->dy, 255), -256);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
buf[2] = i >> 1;
buf[4] = i - buf[2];
- GC a few more hand-rolled 'abs' macros. - GC a few hand-rolled min()/max() macros while I'm here.
2003-01-15 02:15:57 +00:00
i = imax(imin(status->dz, 127), -128);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
buf[5] = (i >> 1) & 0x7f;
buf[6] = (i - (i >> 1)) & 0x7f;
buf[7] = (~status->button >> 3) & 0x7f;
return MOUSE_SYS_PACKETSIZE;
}
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
return pb->inputbytes;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
psmread(struct cdev *dev, struct uio *uio, int flag)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{
register struct psm_softc *sc = PSM_SOFTC(PSM_UNIT(dev));
unsigned char buf[PSM_SMALLBUFSIZE];
int error = 0;
int s;
int l;
if ((sc->state & PSM_VALID) == 0)
return EIO;
/* block until mouse activity occured */
s = spltty();
while (sc->queue.count <= 0) {
if (PSM_NBLOCKIO(dev)) {
splx(s);
return EWOULDBLOCK;
}
sc->state |= PSM_ASLP;
More low-hanging fruit: kill caddr_t in calls to wakeup(9) / [mt]sleep(9).
2003-03-02 16:54:40 +00:00
error = tsleep( sc, PZERO | PCATCH, "psmrea", 0);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
sc->state &= ~PSM_ASLP;
if (error) {
splx(s);
return error;
} else if ((sc->state & PSM_VALID) == 0) {
/* the device disappeared! */
splx(s);
return EIO;
}
}
splx(s);
/* copy data to the user land */
while ((sc->queue.count > 0) && (uio->uio_resid > 0)) {
s = spltty();
- GC a few more hand-rolled 'abs' macros. - GC a few hand-rolled min()/max() macros while I'm here.
2003-01-15 02:15:57 +00:00
l = imin(sc->queue.count, uio->uio_resid);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if (l > sizeof(buf))
l = sizeof(buf);
if (l > sizeof(sc->queue.buf) - sc->queue.head) {
bcopy(&sc->queue.buf[sc->queue.head], &buf[0],
sizeof(sc->queue.buf) - sc->queue.head);
bcopy(&sc->queue.buf[0],
&buf[sizeof(sc->queue.buf) - sc->queue.head],
l - (sizeof(sc->queue.buf) - sc->queue.head));
} else {
bcopy(&sc->queue.buf[sc->queue.head], &buf[0], l);
}
sc->queue.count -= l;
sc->queue.head = (sc->queue.head + l) % sizeof(sc->queue.buf);
splx(s);
error = uiomove(buf, l, uio);
if (error)
break;
}
return error;
}
static int
block_mouse_data(struct psm_softc *sc, int *c)
{
int s;
if (!kbdc_lock(sc->kbdc, TRUE))
return EIO;
s = spltty();
*c = get_controller_command_byte(sc->kbdc);
if ((*c == -1)
|| !set_controller_command_byte(sc->kbdc,
kbdc_get_device_mask(sc->kbdc),
KBD_DISABLE_KBD_PORT | KBD_DISABLE_KBD_INT
| KBD_ENABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
/* this is CONTROLLER ERROR */
splx(s);
kbdc_lock(sc->kbdc, FALSE);
return EIO;
}
/*
* The device may be in the middle of status data transmission.
* The transmission will be interrupted, thus, incomplete status
* data must be discarded. Although the aux interrupt is disabled
* at the keyboard controller level, at most one aux interrupt
* may have already been pending and a data byte is in the
* output buffer; throw it away. Note that the second argument
* to `empty_aux_buffer()' is zero, so that the call will just
* flush the internal queue.
* `psmintr()' will be invoked after `splx()' if an interrupt is
* pending; it will see no data and returns immediately.
*/
empty_aux_buffer(sc->kbdc, 0); /* flush the queue */
read_aux_data_no_wait(sc->kbdc); /* throw away data if any */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
flushpackets(sc);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
splx(s);
return 0;
}
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
static void
dropqueue(struct psm_softc *sc)
{
sc->queue.count = 0;
sc->queue.head = 0;
sc->queue.tail = 0;
if ((sc->state & PSM_SOFTARMED) != 0) {
sc->state &= ~PSM_SOFTARMED;
untimeout(psmsoftintr, (void *)(uintptr_t)sc, sc->softcallout);
}
sc->pqueue_start = sc->pqueue_end;
}
static void
flushpackets(struct psm_softc *sc)
{
dropqueue(sc);
bzero(&sc->pqueue, sizeof(sc->pqueue));
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static int
unblock_mouse_data(struct psm_softc *sc, int c)
{
int error = 0;
/*
* We may have seen a part of status data during `set_mouse_XXX()'.
* they have been queued; flush it.
*/
empty_aux_buffer(sc->kbdc, 0);
/* restore ports and interrupt */
if (!set_controller_command_byte(sc->kbdc,
kbdc_get_device_mask(sc->kbdc),
c & (KBD_KBD_CONTROL_BITS | KBD_AUX_CONTROL_BITS))) {
/* CONTROLLER ERROR; this is serious, we may have
* been left with the inaccessible keyboard and
* the disabled mouse interrupt.
*/
error = EIO;
}
kbdc_lock(sc->kbdc, FALSE);
return error;
}
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
psmioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flag, struct thread *td)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{
struct psm_softc *sc = PSM_SOFTC(PSM_UNIT(dev));
mousemode_t mode;
mousestatus_t status;
#if (defined(MOUSE_GETVARS))
mousevar_t *var;
#endif
mousedata_t *data;
int stat[3];
int command_byte;
int error = 0;
int s;
/* Perform IOCTL command */
switch (cmd) {
case OLD_MOUSE_GETHWINFO:
s = spltty();
((old_mousehw_t *)addr)->buttons = sc->hw.buttons;
((old_mousehw_t *)addr)->iftype = sc->hw.iftype;
((old_mousehw_t *)addr)->type = sc->hw.type;
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
((old_mousehw_t *)addr)->hwid = sc->hw.hwid & 0x00ff;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
splx(s);
break;
case MOUSE_GETHWINFO:
s = spltty();
*(mousehw_t *)addr = sc->hw;
if (sc->mode.level == PSM_LEVEL_BASE)
((mousehw_t *)addr)->model = MOUSE_MODEL_GENERIC;
splx(s);
break;
case OLD_MOUSE_GETMODE:
s = spltty();
switch (sc->mode.level) {
case PSM_LEVEL_BASE:
((old_mousemode_t *)addr)->protocol = MOUSE_PROTO_PS2;
break;
case PSM_LEVEL_STANDARD:
((old_mousemode_t *)addr)->protocol = MOUSE_PROTO_SYSMOUSE;
break;
case PSM_LEVEL_NATIVE:
((old_mousemode_t *)addr)->protocol = MOUSE_PROTO_PS2;
break;
}
((old_mousemode_t *)addr)->rate = sc->mode.rate;
((old_mousemode_t *)addr)->resolution = sc->mode.resolution;
((old_mousemode_t *)addr)->accelfactor = sc->mode.accelfactor;
splx(s);
break;
case MOUSE_GETMODE:
s = spltty();
*(mousemode_t *)addr = sc->mode;
((mousemode_t *)addr)->resolution =
MOUSE_RES_LOW - sc->mode.resolution;
switch (sc->mode.level) {
case PSM_LEVEL_BASE:
((mousemode_t *)addr)->protocol = MOUSE_PROTO_PS2;
((mousemode_t *)addr)->packetsize = MOUSE_PS2_PACKETSIZE;
break;
case PSM_LEVEL_STANDARD:
((mousemode_t *)addr)->protocol = MOUSE_PROTO_SYSMOUSE;
((mousemode_t *)addr)->packetsize = MOUSE_SYS_PACKETSIZE;
((mousemode_t *)addr)->syncmask[0] = MOUSE_SYS_SYNCMASK;
((mousemode_t *)addr)->syncmask[1] = MOUSE_SYS_SYNC;
break;
case PSM_LEVEL_NATIVE:
/* FIXME: this isn't quite correct... XXX */
((mousemode_t *)addr)->protocol = MOUSE_PROTO_PS2;
break;
}
splx(s);
break;
case OLD_MOUSE_SETMODE:
case MOUSE_SETMODE:
if (cmd == OLD_MOUSE_SETMODE) {
mode.rate = ((old_mousemode_t *)addr)->rate;
/*
* resolution old I/F new I/F
* default 0 0
* low 1 -2
* medium low 2 -3
* medium high 3 -4
* high 4 -5
*/
if (((old_mousemode_t *)addr)->resolution > 0)
mode.resolution = -((old_mousemode_t *)addr)->resolution - 1;
mode.accelfactor = ((old_mousemode_t *)addr)->accelfactor;
mode.level = -1;
} else {
mode = *(mousemode_t *)addr;
}
/* adjust and validate parameters. */
if (mode.rate > UCHAR_MAX)
return EINVAL;
if (mode.rate == 0)
mode.rate = sc->dflt_mode.rate;
else if (mode.rate == -1)
/* don't change the current setting */
;
else if (mode.rate < 0)
return EINVAL;
if (mode.resolution >= UCHAR_MAX)
return EINVAL;
if (mode.resolution >= 200)
mode.resolution = MOUSE_RES_HIGH;
else if (mode.resolution >= 100)
mode.resolution = MOUSE_RES_MEDIUMHIGH;
else if (mode.resolution >= 50)
mode.resolution = MOUSE_RES_MEDIUMLOW;
else if (mode.resolution > 0)
mode.resolution = MOUSE_RES_LOW;
if (mode.resolution == MOUSE_RES_DEFAULT)
mode.resolution = sc->dflt_mode.resolution;
else if (mode.resolution == -1)
/* don't change the current setting */
;
else if (mode.resolution < 0) /* MOUSE_RES_LOW/MEDIUM/HIGH */
mode.resolution = MOUSE_RES_LOW - mode.resolution;
if (mode.level == -1)
/* don't change the current setting */
mode.level = sc->mode.level;
else if ((mode.level < PSM_LEVEL_MIN) || (mode.level > PSM_LEVEL_MAX))
return EINVAL;
if (mode.accelfactor == -1)
/* don't change the current setting */
mode.accelfactor = sc->mode.accelfactor;
else if (mode.accelfactor < 0)
return EINVAL;
/* don't allow anybody to poll the keyboard controller */
error = block_mouse_data(sc, &command_byte);
if (error)
return error;
/* set mouse parameters */
if (mode.rate > 0)
mode.rate = set_mouse_sampling_rate(sc->kbdc, mode.rate);
if (mode.resolution >= 0)
mode.resolution = set_mouse_resolution(sc->kbdc, mode.resolution);
set_mouse_scaling(sc->kbdc, 1);
get_mouse_status(sc->kbdc, stat, 0, 3);
s = spltty();
sc->mode.rate = mode.rate;
sc->mode.resolution = mode.resolution;
sc->mode.accelfactor = mode.accelfactor;
sc->mode.level = mode.level;
splx(s);
unblock_mouse_data(sc, command_byte);
break;
case MOUSE_GETLEVEL:
*(int *)addr = sc->mode.level;
break;
case MOUSE_SETLEVEL:
if ((*(int *)addr < PSM_LEVEL_MIN) || (*(int *)addr > PSM_LEVEL_MAX))
return EINVAL;
sc->mode.level = *(int *)addr;
break;
case MOUSE_GETSTATUS:
s = spltty();
status = sc->status;
sc->status.flags = 0;
sc->status.obutton = sc->status.button;
sc->status.button = 0;
sc->status.dx = 0;
sc->status.dy = 0;
sc->status.dz = 0;
splx(s);
*(mousestatus_t *)addr = status;
break;
#if (defined(MOUSE_GETVARS))
case MOUSE_GETVARS:
var = (mousevar_t *)addr;
bzero(var, sizeof(*var));
s = spltty();
var->var[0] = MOUSE_VARS_PS2_SIG;
var->var[1] = sc->config;
var->var[2] = sc->flags;
splx(s);
break;
case MOUSE_SETVARS:
return ENODEV;
#endif /* MOUSE_GETVARS */
case MOUSE_READSTATE:
case MOUSE_READDATA:
data = (mousedata_t *)addr;
if (data->len > sizeof(data->buf)/sizeof(data->buf[0]))
return EINVAL;
error = block_mouse_data(sc, &command_byte);
if (error)
return error;
if ((data->len = get_mouse_status(sc->kbdc, data->buf,
(cmd == MOUSE_READDATA) ? 1 : 0, data->len)) <= 0)
error = EIO;
unblock_mouse_data(sc, command_byte);
break;
#if (defined(MOUSE_SETRESOLUTION))
case MOUSE_SETRESOLUTION:
mode.resolution = *(int *)addr;
if (mode.resolution >= UCHAR_MAX)
return EINVAL;
else if (mode.resolution >= 200)
mode.resolution = MOUSE_RES_HIGH;
else if (mode.resolution >= 100)
mode.resolution = MOUSE_RES_MEDIUMHIGH;
else if (mode.resolution >= 50)
mode.resolution = MOUSE_RES_MEDIUMLOW;
else if (mode.resolution > 0)
mode.resolution = MOUSE_RES_LOW;
if (mode.resolution == MOUSE_RES_DEFAULT)
mode.resolution = sc->dflt_mode.resolution;
else if (mode.resolution == -1)
mode.resolution = sc->mode.resolution;
else if (mode.resolution < 0) /* MOUSE_RES_LOW/MEDIUM/HIGH */
mode.resolution = MOUSE_RES_LOW - mode.resolution;
error = block_mouse_data(sc, &command_byte);
if (error)
return error;
sc->mode.resolution = set_mouse_resolution(sc->kbdc, mode.resolution);
if (sc->mode.resolution != mode.resolution)
error = EIO;
unblock_mouse_data(sc, command_byte);
break;
#endif /* MOUSE_SETRESOLUTION */
#if (defined(MOUSE_SETRATE))
case MOUSE_SETRATE:
mode.rate = *(int *)addr;
if (mode.rate > UCHAR_MAX)
return EINVAL;
if (mode.rate == 0)
mode.rate = sc->dflt_mode.rate;
else if (mode.rate < 0)
mode.rate = sc->mode.rate;
error = block_mouse_data(sc, &command_byte);
if (error)
return error;
sc->mode.rate = set_mouse_sampling_rate(sc->kbdc, mode.rate);
if (sc->mode.rate != mode.rate)
error = EIO;
unblock_mouse_data(sc, command_byte);
break;
#endif /* MOUSE_SETRATE */
#if (defined(MOUSE_SETSCALING))
case MOUSE_SETSCALING:
if ((*(int *)addr <= 0) || (*(int *)addr > 2))
return EINVAL;
error = block_mouse_data(sc, &command_byte);
if (error)
return error;
if (!set_mouse_scaling(sc->kbdc, *(int *)addr))
error = EIO;
unblock_mouse_data(sc, command_byte);
break;
#endif /* MOUSE_SETSCALING */
#if (defined(MOUSE_GETHWID))
case MOUSE_GETHWID:
error = block_mouse_data(sc, &command_byte);
if (error)
return error;
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
sc->hw.hwid &= ~0x00ff;
sc->hw.hwid |= get_aux_id(sc->kbdc);
*(int *)addr = sc->hw.hwid & 0x00ff;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
unblock_mouse_data(sc, command_byte);
break;
#endif /* MOUSE_GETHWID */
default:
return ENOTTY;
}
return error;
}
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
static void
psmtimeout(void *arg)
{
struct psm_softc *sc;
Add spltty()/splx() in the watchdog timer routine.
2000-08-24 08:49:44 +00:00
int s;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc = (struct psm_softc *)arg;
Add spltty()/splx() in the watchdog timer routine.
2000-08-24 08:49:44 +00:00
s = spltty();
This is yet another attempt to fix "psmintr out of sync.." problems. - Properly protect the watchdog timer routine. - Relocate the sync check statement so that we don't see too many error messages.
2000-07-22 04:08:12 +00:00
if (sc->watchdog && kbdc_lock(sc->kbdc, TRUE)) {
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
if (verbose >= 4)
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
log(LOG_DEBUG, "psm%d: lost interrupt?\n", sc->unit);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
psmintr(sc);
This is yet another attempt to fix "psmintr out of sync.." problems. - Properly protect the watchdog timer routine. - Relocate the sync check statement so that we don't see too many error messages.
2000-07-22 04:08:12 +00:00
kbdc_lock(sc->kbdc, FALSE);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
}
sc->watchdog = TRUE;
Add spltty()/splx() in the watchdog timer routine.
2000-08-24 08:49:44 +00:00
splx(s);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->callout = timeout(psmtimeout, (void *)(uintptr_t)sc, hz);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
}
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
static int psmhz = 20;
SYSCTL_INT(_debug, OID_AUTO, psmhz, CTLFLAG_RW, &psmhz, 0, "");
static int psm_soft_timeout = 500000; /* 0.5 sec */
SYSCTL_INT(_debug, OID_AUTO, psm_soft_timeout, CTLFLAG_RW,
&psm_soft_timeout, 0, "");
static int psmerrsecs = 2;
SYSCTL_INT(_debug, OID_AUTO, psmerrsecs, CTLFLAG_RW, &psmerrsecs, 0, "");
static int psmerrusecs = 0;
SYSCTL_INT(_debug, OID_AUTO, psmerrusecs, CTLFLAG_RW, &psmerrusecs, 0, "");
static int psmsecs = 0;
SYSCTL_INT(_debug, OID_AUTO, psmsecs, CTLFLAG_RW, &psmsecs, 0, "");
static int psmusecs = 500000;
SYSCTL_INT(_debug, OID_AUTO, psmusecs, CTLFLAG_RW, &psmusecs, 0, "");
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static void
psmintr(void *arg)
{
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
struct psm_softc *sc = arg;
struct timeval now;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
int c;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
packetbuf_t *pb;
int haderror = 0;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* read until there is nothing to read */
while((c = read_aux_data_no_wait(sc->kbdc)) != -1) {
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
pb = &sc->pqueue[sc->pqueue_end];
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* discard the byte if the device is not open */
if ((sc->state & PSM_OPEN) == 0)
continue;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
getmicrouptime(&now);
if ((pb->inputbytes > 0) && timevalcmp(&now, &sc->inputtimeout, >)) {
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#if DEBUG
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
log(LOG_DEBUG, "psmintr: delay too long; resetting byte count\n");
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#endif
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
pb->inputbytes = 0;
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
sc->syncerrors = 0;
}
sc->inputtimeout.tv_sec = PSM_INPUT_TIMEOUT/1000000;
sc->inputtimeout.tv_usec = PSM_INPUT_TIMEOUT%1000000;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
timevaladd(&sc->inputtimeout, &now);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
pb->ipacket[pb->inputbytes++] = c;
if (pb->inputbytes < sc->mode.packetsize)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
continue;
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#if DEBUG
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
log(LOG_DEBUG, "psmintr: %02x %02x %02x %02x %02x %02x\n",
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
pb->ipacket[0], pb->ipacket[1], pb->ipacket[2],
pb->ipacket[3], pb->ipacket[4], pb->ipacket[5]);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
#endif
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
c = pb->ipacket[0];
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
This is yet another attempt to fix "psmintr out of sync.." problems. - Properly protect the watchdog timer routine. - Relocate the sync check statement so that we don't see too many error messages.
2000-07-22 04:08:12 +00:00
if ((c & sc->mode.syncmask[0]) != sc->mode.syncmask[1]) {
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#if DEBUG
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
log(LOG_DEBUG, "psmintr: out of sync (%04x != %04x) %d"
" cmds since last error.\n",
c & sc->mode.syncmask[0], sc->mode.syncmask[1],
sc->cmdcount - sc->lasterr);
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#endif
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
haderror = 1;
sc->lasterr = sc->cmdcount;
dropqueue(sc);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
++sc->syncerrors;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
sc->lastinputerr = now;
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
if (sc->syncerrors < sc->mode.packetsize) {
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#if DEBUG
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
log(LOG_DEBUG, "psmintr: discard a byte (%d).\n", sc->syncerrors);
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#endif
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
--pb->inputbytes;
bcopy(&pb->ipacket[1], &pb->ipacket[0], pb->inputbytes);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
} else if (sc->syncerrors == sc->mode.packetsize) {
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#if DEBUG
- Add a hack for "psmintr: out of sync.." This is NOT a fix, but a hack! Add `flags 0x8000' to the psm driver to enable it. The psm driver will try to get out of out-of-sync situation by disabling the mouse and immediately enable it again. If you are seeing this out-of-sync problem because of an incompetent(?!) KVM switch, this hack will NOT be good for you. However, if you are occasionally seeing the problem because of lost mouse interrupt, this might help.
2000-12-01 05:26:24 +00:00
log(LOG_DEBUG, "psmintr: re-enable the mouse.\n");
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#endif
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
pb->inputbytes = 0;
- Add a hack for "psmintr: out of sync.." This is NOT a fix, but a hack! Add `flags 0x8000' to the psm driver to enable it. The psm driver will try to get out of out-of-sync situation by disabling the mouse and immediately enable it again. If you are seeing this out-of-sync problem because of an incompetent(?!) KVM switch, this hack will NOT be good for you. However, if you are occasionally seeing the problem because of lost mouse interrupt, this might help.
2000-12-01 05:26:24 +00:00
disable_aux_dev(sc->kbdc);
enable_aux_dev(sc->kbdc);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
} else if (sc->syncerrors < PSM_SYNCERR_THRESHOLD1) {
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#if DEBUG
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
log(LOG_DEBUG, "psmintr: discard a byte (%d).\n", sc->syncerrors);
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#endif
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
--pb->inputbytes;
bcopy(&pb->ipacket[1], &pb->ipacket[0], pb->inputbytes);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
} else if (sc->syncerrors >= PSM_SYNCERR_THRESHOLD1) {
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#if DEBUG
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
log(LOG_DEBUG, "psmintr: reset the mouse.\n");
Put a bunch of output that us really only useful in a debug scenario into #ifdef DEBUG. This makes my cluster with Belkin KVM switch completely usable, even if the KVM switch and mouse get a bit confused sometimes. Without this, when the mouse gets confused, all sorts of crud gets spammed all over the screen. With this, the mouse may appear dead for a second or three, but it recovers silently.
2004-04-04 16:36:21 +00:00
#endif
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
reinitialize(sc, TRUE);
- Add a hack for "psmintr: out of sync.." This is NOT a fix, but a hack! Add `flags 0x8000' to the psm driver to enable it. The psm driver will try to get out of out-of-sync situation by disabling the mouse and immediately enable it again. If you are seeing this out-of-sync problem because of an incompetent(?!) KVM switch, this hack will NOT be good for you. However, if you are occasionally seeing the problem because of lost mouse interrupt, this might help.
2000-12-01 05:26:24 +00:00
}
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
continue;
This is yet another attempt to fix "psmintr out of sync.." problems. - Properly protect the watchdog timer routine. - Relocate the sync check statement so that we don't see too many error messages.
2000-07-22 04:08:12 +00:00
}
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
/* if this packet is at all bogus then drop the packet. */
if (haderror ||
!timeelapsed(&sc->lastinputerr, psmerrsecs, psmerrusecs, &now)) {
pb->inputbytes = 0;
haderror = 0;
continue;
}
sc->cmdcount++;
if (++sc->pqueue_end >= PSM_PACKETQUEUE)
sc->pqueue_end = 0;
/*
* If we've filled the queue then call the softintr ourselves,
* otherwise schedule the interrupt for later.
*/
if (!timeelapsed(&sc->lastsoftintr, psmsecs, psmusecs, &now) ||
(sc->pqueue_end == sc->pqueue_start)) {
if ((sc->state & PSM_SOFTARMED) != 0) {
sc->state &= ~PSM_SOFTARMED;
untimeout(psmsoftintr, arg, sc->softcallout);
}
psmsoftintr(arg);
} else if ((sc->state & PSM_SOFTARMED) == 0) {
sc->state |= PSM_SOFTARMED;
sc->softcallout = timeout(psmsoftintr, arg,
psmhz < 1 ? 1 : (hz/psmhz));
}
}
}
static void
psmsoftintr(void *arg)
{
/*
* the table to turn PS/2 mouse button bits (MOUSE_PS2_BUTTON?DOWN)
* into `mousestatus' button bits (MOUSE_BUTTON?DOWN).
*/
static int butmap[8] = {
0,
MOUSE_BUTTON1DOWN,
MOUSE_BUTTON3DOWN,
MOUSE_BUTTON1DOWN | MOUSE_BUTTON3DOWN,
MOUSE_BUTTON2DOWN,
MOUSE_BUTTON1DOWN | MOUSE_BUTTON2DOWN,
MOUSE_BUTTON2DOWN | MOUSE_BUTTON3DOWN,
MOUSE_BUTTON1DOWN | MOUSE_BUTTON2DOWN | MOUSE_BUTTON3DOWN
};
static int butmap_versapad[8] = {
0,
MOUSE_BUTTON3DOWN,
0,
MOUSE_BUTTON3DOWN,
MOUSE_BUTTON1DOWN,
MOUSE_BUTTON1DOWN | MOUSE_BUTTON3DOWN,
MOUSE_BUTTON1DOWN,
MOUSE_BUTTON1DOWN | MOUSE_BUTTON3DOWN
};
register struct psm_softc *sc = arg;
mousestatus_t ms;
int x, y, z;
int c;
int l;
int x0, y0;
int s;
packetbuf_t *pb;
getmicrouptime(&sc->lastsoftintr);
This is yet another attempt to fix "psmintr out of sync.." problems. - Properly protect the watchdog timer routine. - Relocate the sync check statement so that we don't see too many error messages.
2000-07-22 04:08:12 +00:00
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
s = spltty();
do {
pb = &sc->pqueue[sc->pqueue_start];
c = pb->ipacket[0];
Recognize Interlink VersaPad. `Tap' action will be recognized as the button 4. Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
1999-08-17 12:14:13 +00:00
/*
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
* A kludge for Kensington device!
* The MSB of the horizontal count appears to be stored in
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
* a strange place.
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
*/
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
if (sc->hw.model == MOUSE_MODEL_THINK)
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
pb->ipacket[1] |= (c & MOUSE_PS2_XOVERFLOW) ? 0x80 : 0;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* ignore the overflow bits... */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
x = (c & MOUSE_PS2_XNEG) ? pb->ipacket[1] - 256 : pb->ipacket[1];
y = (c & MOUSE_PS2_YNEG) ? pb->ipacket[2] - 256 : pb->ipacket[2];
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
z = 0;
ms.obutton = sc->button; /* previous button state */
ms.button = butmap[c & MOUSE_PS2_BUTTONS];
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
/* `tapping' action */
if (sc->config & PSM_CONFIG_FORCETAP)
ms.button |= ((c & MOUSE_PS2_TAP)) ? 0 : MOUSE_BUTTON4DOWN;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
switch (sc->hw.model) {
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
case MOUSE_MODEL_EXPLORER:
/*
* b7 b6 b5 b4 b3 b2 b1 b0
* byte 1: oy ox sy sx 1 M R L
* byte 2: x x x x x x x x
* byte 3: y y y y y y y y
* byte 4: * * S2 S1 s d2 d1 d0
*
* L, M, R, S1, S2: left, middle, right and side buttons
* s: wheel data sign bit
* d2-d0: wheel data
*/
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
z = (pb->ipacket[3] & MOUSE_EXPLORER_ZNEG)
? (pb->ipacket[3] & 0x0f) - 16 : (pb->ipacket[3] & 0x0f);
ms.button |= (pb->ipacket[3] & MOUSE_EXPLORER_BUTTON4DOWN)
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
? MOUSE_BUTTON4DOWN : 0;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
ms.button |= (pb->ipacket[3] & MOUSE_EXPLORER_BUTTON5DOWN)
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
? MOUSE_BUTTON5DOWN : 0;
break;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
case MOUSE_MODEL_INTELLI:
case MOUSE_MODEL_NET:
/* wheel data is in the fourth byte */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
z = (char)pb->ipacket[3];
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* some mice may send 7 when there is no Z movement?! XXX */
if ((z >= 7) || (z <= -7))
z = 0;
/* some compatible mice have additional buttons */
ms.button |= (c & MOUSE_PS2INTELLI_BUTTON4DOWN)
? MOUSE_BUTTON4DOWN : 0;
ms.button |= (c & MOUSE_PS2INTELLI_BUTTON5DOWN)
? MOUSE_BUTTON5DOWN : 0;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
break;
case MOUSE_MODEL_MOUSEMANPLUS:
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
/*
* PS2++ protocl packet
*
* b7 b6 b5 b4 b3 b2 b1 b0
* byte 1: * 1 p3 p2 1 * * *
* byte 2: c1 c2 p1 p0 d1 d0 1 0
*
* p3-p0: packet type
* c1, c2: c1 & c2 == 1, if p2 == 0
* c1 & c2 == 0, if p2 == 1
*
* packet type: 0 (device type)
* See comments in enable_mmanplus() below.
*
* packet type: 1 (wheel data)
*
* b7 b6 b5 b4 b3 b2 b1 b0
* byte 3: h * B5 B4 s d2 d1 d0
*
* h: 1, if horizontal roller data
* 0, if vertical roller data
* B4, B5: button 4 and 5
* s: sign bit
* d2-d0: roller data
*
* packet type: 2 (reserved)
*/
if (((c & MOUSE_PS2PLUS_SYNCMASK) == MOUSE_PS2PLUS_SYNC)
&& (abs(x) > 191)
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
&& MOUSE_PS2PLUS_CHECKBITS(pb->ipacket)) {
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* the extended data packet encodes button and wheel events */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
switch (MOUSE_PS2PLUS_PACKET_TYPE(pb->ipacket)) {
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
case 1:
/* wheel data packet */
x = y = 0;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
if (pb->ipacket[2] & 0x80) {
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
/* horizontal roller count - ignore it XXX*/
} else {
/* vertical roller count */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
z = (pb->ipacket[2] & MOUSE_PS2PLUS_ZNEG)
? (pb->ipacket[2] & 0x0f) - 16
: (pb->ipacket[2] & 0x0f);
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
}
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
ms.button |= (pb->ipacket[2] & MOUSE_PS2PLUS_BUTTON4DOWN)
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
? MOUSE_BUTTON4DOWN : 0;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
ms.button |= (pb->ipacket[2] & MOUSE_PS2PLUS_BUTTON5DOWN)
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
? MOUSE_BUTTON5DOWN : 0;
break;
case 2:
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* this packet type is reserved by Logitech... */
/*
* IBM ScrollPoint Mouse uses this packet type to
* encode both vertical and horizontal scroll movement.
*/
x = y = 0;
/* horizontal count */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
if (pb->ipacket[2] & 0x0f)
z = (pb->ipacket[2] & MOUSE_SPOINT_WNEG) ? -2 : 2;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* vertical count */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
if (pb->ipacket[2] & 0xf0)
z = (pb->ipacket[2] & MOUSE_SPOINT_ZNEG) ? -1 : 1;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
#if 0
/* vertical count */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
z = (pb->ipacket[2] & MOUSE_SPOINT_ZNEG)
? ((pb->ipacket[2] >> 4) & 0x0f) - 16
: ((pb->ipacket[2] >> 4) & 0x0f);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* horizontal count */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
w = (pb->ipacket[2] & MOUSE_SPOINT_WNEG)
? (pb->ipacket[2] & 0x0f) - 16
: (pb->ipacket[2] & 0x0f);
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
#endif
break;
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
case 0:
/* device type packet - shouldn't happen */
Replace various spelling with FALLTHROUGH which is lint()able
2002-08-25 13:23:09 +00:00
/* FALLTHROUGH */
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
default:
x = y = 0;
ms.button = ms.obutton;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
if (bootverbose)
log(LOG_DEBUG, "psmintr: unknown PS2++ packet type %d: "
"0x%02x 0x%02x 0x%02x\n",
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
MOUSE_PS2PLUS_PACKET_TYPE(pb->ipacket),
pb->ipacket[0], pb->ipacket[1], pb->ipacket[2]);
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
break;
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
} else {
/* preserve button states */
ms.button |= ms.obutton & MOUSE_EXTBUTTONS;
}
break;
case MOUSE_MODEL_GLIDEPOINT:
/* `tapping' action */
ms.button |= ((c & MOUSE_PS2_TAP)) ? 0 : MOUSE_BUTTON4DOWN;
break;
case MOUSE_MODEL_NETSCROLL:
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* three addtional bytes encode buttons and wheel events */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
ms.button |= (pb->ipacket[3] & MOUSE_PS2_BUTTON3DOWN)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
? MOUSE_BUTTON4DOWN : 0;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
ms.button |= (pb->ipacket[3] & MOUSE_PS2_BUTTON1DOWN)
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
? MOUSE_BUTTON5DOWN : 0;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
z = (pb->ipacket[3] & MOUSE_PS2_XNEG)
? pb->ipacket[4] - 256 : pb->ipacket[4];
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
break;
case MOUSE_MODEL_THINK:
/* the fourth button state in the first byte */
ms.button |= (c & MOUSE_PS2_TAP) ? MOUSE_BUTTON4DOWN : 0;
break;
Recognize Interlink VersaPad. `Tap' action will be recognized as the button 4. Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
1999-08-17 12:14:13 +00:00
case MOUSE_MODEL_VERSAPAD:
/* VersaPad PS/2 absolute mode message format
*
* [packet1] 7 6 5 4 3 2 1 0(LSB)
* ipacket[0]: 1 1 0 A 1 L T R
* ipacket[1]: H7 H6 H5 H4 H3 H2 H1 H0
* ipacket[2]: V7 V6 V5 V4 V3 V2 V1 V0
* ipacket[3]: 1 1 1 A 1 L T R
* ipacket[4]:V11 V10 V9 V8 H11 H10 H9 H8
* ipacket[5]: 0 P6 P5 P4 P3 P2 P1 P0
*
* [note]
* R: right physical mouse button (1=on)
* T: touch pad virtual button (1=tapping)
* L: left physical mouse button (1=on)
* A: position data is valid (1=valid)
* H: horizontal data (12bit signed integer. H11 is sign bit.)
* V: vertical data (12bit signed integer. V11 is sign bit.)
* P: pressure data
*
* Tapping is mapped to MOUSE_BUTTON4.
*/
ms.button = butmap_versapad[c & MOUSE_PS2VERSA_BUTTONS];
ms.button |= (c & MOUSE_PS2VERSA_TAP) ? MOUSE_BUTTON4DOWN : 0;
x = y = 0;
if (c & MOUSE_PS2VERSA_IN_USE) {
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
x0 = pb->ipacket[1] | (((pb->ipacket[4]) & 0x0f) << 8);
y0 = pb->ipacket[2] | (((pb->ipacket[4]) & 0xf0) << 4);
Recognize Interlink VersaPad. `Tap' action will be recognized as the button 4. Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
1999-08-17 12:14:13 +00:00
if (x0 & 0x800)
x0 -= 0x1000;
if (y0 & 0x800)
y0 -= 0x1000;
if (sc->flags & PSM_FLAGS_FINGERDOWN) {
x = sc->xold - x0;
y = y0 - sc->yold;
if (x < 0) /* XXX */
x++;
else if (x)
x--;
if (y < 0)
y++;
else if (y)
y--;
} else {
sc->flags |= PSM_FLAGS_FINGERDOWN;
}
sc->xold = x0;
sc->yold = y0;
} else {
sc->flags &= ~PSM_FLAGS_FINGERDOWN;
}
c = ((x < 0) ? MOUSE_PS2_XNEG : 0)
| ((y < 0) ? MOUSE_PS2_YNEG : 0);
break;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
case MOUSE_MODEL_4D:
/*
* b7 b6 b5 b4 b3 b2 b1 b0
* byte 1: s2 d2 s1 d1 1 M R L
* byte 2: sx x x x x x x x
* byte 3: sy y y y y y y y
*
* s1: wheel 1 direction
* d1: wheel 1 data
* s2: wheel 2 direction
* d2: wheel 2 data
*/
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
x = (pb->ipacket[1] & 0x80) ? pb->ipacket[1] - 256 : pb->ipacket[1];
y = (pb->ipacket[2] & 0x80) ? pb->ipacket[2] - 256 : pb->ipacket[2];
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
switch (c & MOUSE_4D_WHEELBITS) {
case 0x10:
z = 1;
break;
case 0x30:
z = -1;
break;
case 0x40: /* 2nd wheel turning right XXX */
z = 2;
break;
case 0xc0: /* 2nd wheel turning left XXX */
z = -2;
break;
}
break;
case MOUSE_MODEL_4DPLUS:
if ((x < 16 - 256) && (y < 16 - 256)) {
/*
* b7 b6 b5 b4 b3 b2 b1 b0
* byte 1: 0 0 1 1 1 M R L
* byte 2: 0 0 0 0 1 0 0 0
* byte 3: 0 0 0 0 S s d1 d0
*
* L, M, R, S: left, middle, right and side buttons
* s: wheel data sign bit
* d1-d0: wheel data
*/
x = y = 0;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
if (pb->ipacket[2] & MOUSE_4DPLUS_BUTTON4DOWN)
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
ms.button |= MOUSE_BUTTON4DOWN;
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
z = (pb->ipacket[2] & MOUSE_4DPLUS_ZNEG)
? ((pb->ipacket[2] & 0x07) - 8)
: (pb->ipacket[2] & 0x07) ;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
} else {
/* preserve previous button states */
ms.button |= ms.obutton & MOUSE_EXTBUTTONS;
}
break;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
case MOUSE_MODEL_GENERIC:
default:
break;
}
/* scale values */
if (sc->mode.accelfactor >= 1) {
if (x != 0) {
x = x * x / sc->mode.accelfactor;
if (x == 0)
x = 1;
if (c & MOUSE_PS2_XNEG)
x = -x;
}
if (y != 0) {
y = y * y / sc->mode.accelfactor;
if (y == 0)
y = 1;
if (c & MOUSE_PS2_YNEG)
y = -y;
}
}
ms.dx = x;
ms.dy = y;
ms.dz = z;
ms.flags = ((x || y || z) ? MOUSE_POSCHANGED : 0)
| (ms.obutton ^ ms.button);
if (sc->mode.level < PSM_LEVEL_NATIVE)
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
pb->inputbytes = tame_mouse(sc, pb, &ms, pb->ipacket);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
sc->status.flags |= ms.flags;
sc->status.dx += ms.dx;
sc->status.dy += ms.dy;
sc->status.dz += ms.dz;
sc->status.button = ms.button;
sc->button = ms.button;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
sc->watchdog = FALSE;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* queue data */
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
if (sc->queue.count + pb->inputbytes < sizeof(sc->queue.buf)) {
l = imin(pb->inputbytes, sizeof(sc->queue.buf) - sc->queue.tail);
bcopy(&pb->ipacket[0], &sc->queue.buf[sc->queue.tail], l);
if (pb->inputbytes > l)
bcopy(&pb->ipacket[l], &sc->queue.buf[0], pb->inputbytes - l);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
sc->queue.tail =
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
(sc->queue.tail + pb->inputbytes) % sizeof(sc->queue.buf);
sc->queue.count += pb->inputbytes;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
pb->inputbytes = 0;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
if (++sc->pqueue_start >= PSM_PACKETQUEUE)
sc->pqueue_start = 0;
} while (sc->pqueue_start != sc->pqueue_end);
if (sc->state & PSM_ASLP) {
sc->state &= ~PSM_ASLP;
wakeup( sc);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
selwakeuppri(&sc->rsel, PZERO);
sc->state &= ~PSM_SOFTARMED;
splx(s);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
psmpoll(struct cdev *dev, int events, struct thread *td)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{
struct psm_softc *sc = PSM_SOFTC(PSM_UNIT(dev));
int s;
int revents = 0;
/* Return true if a mouse event available */
s = spltty();
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
if (events & (POLLIN | POLLRDNORM)) {
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if (sc->queue.count > 0)
revents |= events & (POLLIN | POLLRDNORM);
else
KSE Milestone 2 Note ALL MODULES MUST BE RECOMPILED make the kernel aware that there are smaller units of scheduling than the process. (but only allow one thread per process at this time). This is functionally equivalent to teh previousl -current except that there is a thread associated with each process. Sorry john! (your next MFC will be a doosie!) Reviewed by: peter@freebsd.org, dillon@freebsd.org X-MFC after: ha ha ha ha
2001-09-12 08:38:13 +00:00
selrecord(td, &sc->rsel);
Merge revs 1.57 and 1.60 of i386/isa/psm.c
1999-04-18 15:12:11 +00:00
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
splx(s);
return (revents);
}
/* vendor/model specific routines */
static int mouse_id_proc1(KBDC kbdc, int res, int scale, int *status)
{
if (set_mouse_resolution(kbdc, res) != res)
return FALSE;
if (set_mouse_scaling(kbdc, scale)
&& set_mouse_scaling(kbdc, scale)
&& set_mouse_scaling(kbdc, scale)
&& (get_mouse_status(kbdc, status, 0, 3) >= 3))
return TRUE;
return FALSE;
}
- Slightly rearrnage IntelliMouse Explorer and Logitech MouseMan+ identification routines for efficiency. No functional change.
2000-12-01 05:24:30 +00:00
static int
mouse_ext_command(KBDC kbdc, int command)
{
int c;
c = (command >> 6) & 0x03;
if (set_mouse_resolution(kbdc, c) != c)
return FALSE;
c = (command >> 4) & 0x03;
if (set_mouse_resolution(kbdc, c) != c)
return FALSE;
c = (command >> 2) & 0x03;
if (set_mouse_resolution(kbdc, c) != c)
return FALSE;
c = (command >> 0) & 0x03;
if (set_mouse_resolution(kbdc, c) != c)
return FALSE;
return TRUE;
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
#if notyet
/* Logitech MouseMan Cordless II */
static int
enable_lcordless(struct psm_softc *sc)
{
int status[3];
int ch;
if (!mouse_id_proc1(sc->kbdc, PSMD_RES_HIGH, 2, status))
return FALSE;
if (status[1] == PSMD_RES_HIGH)
return FALSE;
ch = (status[0] & 0x07) - 1; /* channel # */
if ((ch <= 0) || (ch > 4))
return FALSE;
/*
* status[1]: always one?
* status[2]: battery status? (0-100)
*/
return TRUE;
}
#endif /* notyet */
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* Genius NetScroll Mouse, MouseSystems SmartScroll Mouse */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static int
enable_groller(struct psm_softc *sc)
{
int status[3];
/*
* The special sequence to enable the fourth button and the
* roller. Immediately after this sequence check status bytes.
* if the mouse is NetScroll, the second and the third bytes are
* '3' and 'D'.
*/
/*
* If the mouse is an ordinary PS/2 mouse, the status bytes should
* look like the following.
*
* byte 1 bit 7 always 0
* bit 6 stream mode (0)
* bit 5 disabled (0)
* bit 4 1:1 scaling (0)
* bit 3 always 0
* bit 0-2 button status
* byte 2 resolution (PSMD_RES_HIGH)
* byte 3 report rate (?)
*/
if (!mouse_id_proc1(sc->kbdc, PSMD_RES_HIGH, 1, status))
return FALSE;
if ((status[1] != '3') || (status[2] != 'D'))
return FALSE;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* FIXME: SmartScroll Mouse has 5 buttons! XXX */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
sc->hw.buttons = 4;
return TRUE;
}
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* Genius NetMouse/NetMouse Pro, ASCII Mie Mouse, NetScroll Optical */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static int
enable_gmouse(struct psm_softc *sc)
{
int status[3];
/*
* The special sequence to enable the middle, "rubber" button.
* Immediately after this sequence check status bytes.
* if the mouse is NetMouse, NetMouse Pro, or ASCII MIE Mouse,
* the second and the third bytes are '3' and 'U'.
* NOTE: NetMouse reports that it has three buttons although it has
* two buttons and a rubber button. NetMouse Pro and MIE Mouse
* say they have three buttons too and they do have a button on the
* side...
*/
if (!mouse_id_proc1(sc->kbdc, PSMD_RES_HIGH, 1, status))
return FALSE;
if ((status[1] != '3') || (status[2] != 'U'))
return FALSE;
return TRUE;
}
/* ALPS GlidePoint */
static int
enable_aglide(struct psm_softc *sc)
{
int status[3];
/*
* The special sequence to obtain ALPS GlidePoint specific
* information. Immediately after this sequence, status bytes will
* contain something interesting.
* NOTE: ALPS produces several models of GlidePoint. Some of those
* do not respond to this sequence, thus, cannot be detected this way.
*/
Improve the detection code for GlidePoint. This is still a kludge, but better than before... PR: kern/13215
1999-08-22 06:11:52 +00:00
if (set_mouse_sampling_rate(sc->kbdc, 100) != 100)
return FALSE;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if (!mouse_id_proc1(sc->kbdc, PSMD_RES_LOW, 2, status))
return FALSE;
Improve the detection code for GlidePoint. This is still a kludge, but better than before... PR: kern/13215
1999-08-22 06:11:52 +00:00
if ((status[1] == PSMD_RES_LOW) || (status[2] == 100))
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return FALSE;
return TRUE;
}
/* Kensington ThinkingMouse/Trackball */
static int
enable_kmouse(struct psm_softc *sc)
{
static unsigned char rate[] = { 20, 60, 40, 20, 20, 60, 40, 20, 20 };
KBDC kbdc = sc->kbdc;
int status[3];
int id1;
int id2;
int i;
id1 = get_aux_id(kbdc);
if (set_mouse_sampling_rate(kbdc, 10) != 10)
return FALSE;
/*
* The device is now in the native mode? It returns a different
* ID value...
*/
id2 = get_aux_id(kbdc);
if ((id1 == id2) || (id2 != 2))
return FALSE;
if (set_mouse_resolution(kbdc, PSMD_RES_LOW) != PSMD_RES_LOW)
return FALSE;
#if PSM_DEBUG >= 2
/* at this point, resolution is LOW, sampling rate is 10/sec */
if (get_mouse_status(kbdc, status, 0, 3) < 3)
return FALSE;
#endif
/*
* The special sequence to enable the third and fourth buttons.
* Otherwise they behave like the first and second buttons.
*/
for (i = 0; i < sizeof(rate)/sizeof(rate[0]); ++i) {
if (set_mouse_sampling_rate(kbdc, rate[i]) != rate[i])
return FALSE;
}
/*
* At this point, the device is using default resolution and
* sampling rate for the native mode.
*/
if (get_mouse_status(kbdc, status, 0, 3) < 3)
return FALSE;
if ((status[1] == PSMD_RES_LOW) || (status[2] == rate[i - 1]))
return FALSE;
/* the device appears be enabled by this sequence, diable it for now */
disable_aux_dev(kbdc);
empty_aux_buffer(kbdc, 5);
return TRUE;
}
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* Logitech MouseMan+/FirstMouse+, IBM ScrollPoint Mouse */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static int
enable_mmanplus(struct psm_softc *sc)
{
KBDC kbdc = sc->kbdc;
int data[3];
/* the special sequence to enable the fourth button and the roller. */
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/*
* NOTE: for ScrollPoint to respond correctly, the SET_RESOLUTION
* must be called exactly three times since the last RESET command
* before this sequence. XXX
*/
- Slightly rearrnage IntelliMouse Explorer and Logitech MouseMan+ identification routines for efficiency. No functional change.
2000-12-01 05:24:30 +00:00
if (!set_mouse_scaling(kbdc, 1))
return FALSE;
if (!mouse_ext_command(kbdc, 0x39) || !mouse_ext_command(kbdc, 0xdb))
return FALSE;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if (get_mouse_status(kbdc, data, 1, 3) < 3)
return FALSE;
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
/*
* PS2++ protocl, packet type 0
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
*
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
* b7 b6 b5 b4 b3 b2 b1 b0
* byte 1: * 1 p3 p2 1 * * *
* byte 2: 1 1 p1 p0 m1 m0 1 0
* byte 3: m7 m6 m5 m4 m3 m2 m1 m0
*
* p3-p0: packet type: 0
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
* m7-m0: model ID: MouseMan+:0x50, FirstMouse+:0x51, ScrollPoint:0x58...
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
*/
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
/* check constant bits */
if ((data[0] & MOUSE_PS2PLUS_SYNCMASK) != MOUSE_PS2PLUS_SYNC)
return FALSE;
if ((data[1] & 0xc3) != 0xc2)
return FALSE;
/* check d3-d0 in byte 2 */
if (!MOUSE_PS2PLUS_CHECKBITS(data))
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return FALSE;
Improve Logitech MouseMan+ protocol support.
1999-07-12 15:16:14 +00:00
/* check p3-p0 */
if (MOUSE_PS2PLUS_PACKET_TYPE(data) != 0)
return FALSE;
sc->hw.hwid &= 0x00ff;
sc->hw.hwid |= data[2] << 8; /* save model ID */
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/*
* MouseMan+ (or FirstMouse+) is now in its native mode, in which
* the wheel and the fourth button events are encoded in the
* special data packet. The mouse may be put in the IntelliMouse mode
* if it is initialized by the IntelliMouse's method.
*/
return TRUE;
}
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* MS IntelliMouse Explorer */
static int
enable_msexplorer(struct psm_softc *sc)
{
- Add temporary workaround to fool some "clever" KVM switch products which think they know the IntelliMouse 4-byte packet and believe, wrongly, that any other protocols use 3-byte packets. - Update a couple of comment lines for A4 Tech mice.
2000-04-02 08:28:21 +00:00
static unsigned char rate0[] = { 200, 100, 80, };
static unsigned char rate1[] = { 200, 200, 80, };
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
KBDC kbdc = sc->kbdc;
int id;
int i;
- Slightly rearrnage IntelliMouse Explorer and Logitech MouseMan+ identification routines for efficiency. No functional change.
2000-12-01 05:24:30 +00:00
/* the special sequence to enable the extra buttons and the roller. */
for (i = 0; i < sizeof(rate1)/sizeof(rate1[0]); ++i) {
if (set_mouse_sampling_rate(kbdc, rate1[i]) != rate1[i])
return FALSE;
}
/* the device will give the genuine ID only after the above sequence */
id = get_aux_id(kbdc);
if (id != PSM_EXPLORER_ID)
return FALSE;
sc->hw.hwid = id;
sc->hw.buttons = 5; /* IntelliMouse Explorer XXX */
- Add temporary workaround to fool some "clever" KVM switch products which think they know the IntelliMouse 4-byte packet and believe, wrongly, that any other protocols use 3-byte packets. - Update a couple of comment lines for A4 Tech mice.
2000-04-02 08:28:21 +00:00
/*
* XXX: this is a kludge to fool some KVM switch products
* which think they are clever enough to know the 4-byte IntelliMouse
* protocol, and assume any other protocols use 3-byte packets.
* They don't convey 4-byte data packets from the IntelliMouse Explorer
* correctly to the host computer because of this!
* The following sequence is actually IntelliMouse's "wake up"
* sequence; it will make the KVM think the mouse is IntelliMouse
* when it is in fact IntelliMouse Explorer.
*/
for (i = 0; i < sizeof(rate0)/sizeof(rate0[0]); ++i) {
if (set_mouse_sampling_rate(kbdc, rate0[i]) != rate0[i])
- Slightly rearrnage IntelliMouse Explorer and Logitech MouseMan+ identification routines for efficiency. No functional change.
2000-12-01 05:24:30 +00:00
break;
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
}
id = get_aux_id(kbdc);
return TRUE;
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
/* MS IntelliMouse */
static int
enable_msintelli(struct psm_softc *sc)
{
/*
* Logitech MouseMan+ and FirstMouse+ will also respond to this
* probe routine and act like IntelliMouse.
*/
static unsigned char rate[] = { 200, 100, 80, };
KBDC kbdc = sc->kbdc;
int id;
int i;
/* the special sequence to enable the third button and the roller. */
for (i = 0; i < sizeof(rate)/sizeof(rate[0]); ++i) {
if (set_mouse_sampling_rate(kbdc, rate[i]) != rate[i])
return FALSE;
}
/* the device will give the genuine ID only after the above sequence */
id = get_aux_id(kbdc);
if (id != PSM_INTELLI_ID)
return FALSE;
sc->hw.hwid = id;
sc->hw.buttons = 3;
return TRUE;
}
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
/* A4 Tech 4D Mouse */
static int
enable_4dmouse(struct psm_softc *sc)
{
/*
* Newer wheel mice from A4 Tech may use the 4D+ protocol.
*/
static unsigned char rate[] = { 200, 100, 80, 60, 40, 20 };
KBDC kbdc = sc->kbdc;
int id;
int i;
for (i = 0; i < sizeof(rate)/sizeof(rate[0]); ++i) {
if (set_mouse_sampling_rate(kbdc, rate[i]) != rate[i])
return FALSE;
}
id = get_aux_id(kbdc);
/*
- Add temporary workaround to fool some "clever" KVM switch products which think they know the IntelliMouse 4-byte packet and believe, wrongly, that any other protocols use 3-byte packets. - Update a couple of comment lines for A4 Tech mice.
2000-04-02 08:28:21 +00:00
* WinEasy 4D, 4 Way Scroll 4D: 6
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
* Cable-Free 4D: 8 (4DPLUS)
- Add temporary workaround to fool some "clever" KVM switch products which think they know the IntelliMouse 4-byte packet and believe, wrongly, that any other protocols use 3-byte packets. - Update a couple of comment lines for A4 Tech mice.
2000-04-02 08:28:21 +00:00
* WinBest 4D+, 4 Way Scroll 4D+: 8 (4DPLUS)
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
*/
if (id != PSM_4DMOUSE_ID)
return FALSE;
sc->hw.hwid = id;
sc->hw.buttons = 3; /* XXX some 4D mice have 4? */
return TRUE;
}
/* A4 Tech 4D+ Mouse */
static int
enable_4dplus(struct psm_softc *sc)
{
/*
* Newer wheel mice from A4 Tech seem to use this protocol.
* Older models are recognized as either 4D Mouse or IntelliMouse.
*/
KBDC kbdc = sc->kbdc;
int id;
/*
* enable_4dmouse() already issued the following ID sequence...
static unsigned char rate[] = { 200, 100, 80, 60, 40, 20 };
int i;
for (i = 0; i < sizeof(rate)/sizeof(rate[0]); ++i) {
if (set_mouse_sampling_rate(kbdc, rate[i]) != rate[i])
return FALSE;
}
*/
id = get_aux_id(kbdc);
Add support for the A4 Tech RFSW-35 mouse wheel. Probe is similar to 4D Plus. PR: 44333
2003-07-12 18:36:04 +00:00
switch (id) {
case PSM_4DPLUS_ID:
sc->hw.buttons = 4;
break;
case PSM_4DPLUS_RFSW35_ID:
sc->hw.buttons = 3;
break;
default:
return FALSE;
}
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
sc->hw.hwid = id;
return TRUE;
}
Recognize Interlink VersaPad. `Tap' action will be recognized as the button 4. Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
1999-08-17 12:14:13 +00:00
/* Interlink electronics VersaPad */
static int
enable_versapad(struct psm_softc *sc)
{
KBDC kbdc = sc->kbdc;
int data[3];
set_mouse_resolution(kbdc, PSMD_RES_MEDIUM_HIGH); /* set res. 2 */
set_mouse_sampling_rate(kbdc, 100); /* set rate 100 */
set_mouse_scaling(kbdc, 1); /* set scale 1:1 */
set_mouse_scaling(kbdc, 1); /* set scale 1:1 */
set_mouse_scaling(kbdc, 1); /* set scale 1:1 */
set_mouse_scaling(kbdc, 1); /* set scale 1:1 */
if (get_mouse_status(kbdc, data, 0, 3) < 3) /* get status */
return FALSE;
if (data[2] != 0xa || data[1] != 0 ) /* rate == 0xa && res. == 0 */
return FALSE;
set_mouse_scaling(kbdc, 1); /* set scale 1:1 */
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
sc->config |= PSM_CONFIG_HOOKRESUME | PSM_CONFIG_INITAFTERSUSPEND;
Recognize Interlink VersaPad. `Tap' action will be recognized as the button 4. Submitted by: Masachika ISHIZUKA <ishizuka@ish.org>
1999-08-17 12:14:13 +00:00
return TRUE; /* PS/2 absolute mode */
}
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
static int
- Add the device resume method. It supercedes the existing resume routine which hooks the apm driver. - Rename the PSM_HOOKAPM option to PSM_HOOKRESUME. - Delete unnecessary #include.
1999-12-15 10:04:05 +00:00
psmresume(device_t dev)
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
{
- Add the device resume method. It supercedes the existing resume routine which hooks the apm driver. - Rename the PSM_HOOKAPM option to PSM_HOOKRESUME. - Delete unnecessary #include.
1999-12-15 10:04:05 +00:00
struct psm_softc *sc = device_get_softc(dev);
int unit = device_get_unit(dev);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
int err;
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if (verbose >= 2)
- Add the device resume method. It supercedes the existing resume routine which hooks the apm driver. - Rename the PSM_HOOKAPM option to PSM_HOOKRESUME. - Delete unnecessary #include.
1999-12-15 10:04:05 +00:00
log(LOG_NOTICE, "psm%d: system resume hook called.\n", unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
- Add Support for the following PS/2 mice: - Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "IntelliMouse Explorer". - Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a wheel which also acts as the middle button. The mouse is recognized as "NetMouse/NetScroll Optical". - MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top, 1 side button and a wheel. The mouse is recognized as Genius "NetScroll". - IBM ScrollPoint: 2 buttons on top and a stick between the buttons. The stick can perform "horizontal scroll" in W*ndows environment. The horizontal movement of the stick is detected. It is currently mapped to the Z axis movement in the same way as the first wheel. The mouse is recognized as "MouseMan+", as it is considered to be a variation of MouseMan. - A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement of the second wheel is reported as the Z axis movement in the same way as the first wheel. These mice are recognized as "4D Mouse" and "4D+ Mouse". - Tweak IntelliMouse support code a bit so that less-than-compatible wheel mice can work properly with the psm driver. - Add driver configuration flags which correspond to the kernel options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't need to recompile the kernel when we need these functions. - Properly keep track of the irq resource. - Add a watchdog timer in case interrupts are lost (experimental). - Add `detach' function (experimental).
2000-03-18 15:21:40 +00:00
if (!(sc->config & PSM_CONFIG_HOOKRESUME))
return (0);
Hack for the "out-of-sync" error. - Count the number of this error. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to 20, the psm driver reset and reinitialize the mouse. The counter is reset to zero. - It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. You may see the following error logs during the above operations: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" MFC after: 1 month
2001-10-13 10:28:02 +00:00
err = reinitialize(sc, sc->config & PSM_CONFIG_INITAFTERSUSPEND);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
if ((sc->state & PSM_ASLP) && !(sc->state & PSM_VALID)) {
/*
* Release the blocked process; it must be notified that the device
* cannot be accessed anymore.
*/
sc->state &= ~PSM_ASLP;
More low-hanging fruit: kill caddr_t in calls to wakeup(9) / [mt]sleep(9).
2003-03-02 16:54:40 +00:00
wakeup(sc);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
}
if (verbose >= 2)
- Add the device resume method. It supercedes the existing resume routine which hooks the apm driver. - Rename the PSM_HOOKAPM option to PSM_HOOKRESUME. - Delete unnecessary #include.
1999-12-15 10:04:05 +00:00
log(LOG_DEBUG, "psm%d: system resume hook exiting.\n", unit);
Port the ps/2 mouse driver to the alpha.
1998-11-08 18:43:03 +00:00
return (err);
}
Use DEVICE_MODULE() directly instead of DEV_DRIVER_MODULE. psm.c uses make_dev() already.
1999-11-08 07:29:23 +00:00
DRIVER_MODULE(psm, atkbdc, psm_driver, psm_devclass, 0, 0);
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
/*
* This sucks up assignments from PNPBIOS and ACPI.
*/
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
/*
* When the PS/2 mouse device is reported by ACPI or PnP BIOS, it may
* appear BEFORE the AT keyboard controller. As the PS/2 mouse device
* can be probed and attached only after the AT keyboard controller is
* attached, we shall quietly reserve the IRQ resource for later use.
* If the PS/2 mouse device is reported to us AFTER the keyboard controller,
* copy the IRQ resource to the PS/2 mouse device instance hanging
* under the keyboard controller, then probe and attach it.
*/
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
static devclass_t psmcpnp_devclass;
static device_probe_t psmcpnp_probe;
static device_attach_t psmcpnp_attach;
static device_method_t psmcpnp_methods[] = {
DEVMETHOD(device_probe, psmcpnp_probe),
DEVMETHOD(device_attach, psmcpnp_attach),
{ 0, 0 }
};
static driver_t psmcpnp_driver = {
PSMCPNP_DRIVER_NAME,
psmcpnp_methods,
1, /* no softc */
};
static struct isa_pnp_id psmcpnp_ids[] = {
Add another PS2 PNP id. PR: 32973 Submitted by: KT Sin <ktsin@acm.org>
2001-12-19 13:32:21 +00:00
{ 0x030fd041, "PS/2 mouse port" }, /* PNP0F03 */
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
{ 0x130fd041, "PS/2 mouse port" }, /* PNP0F13 */
{ 0x1303d041, "PS/2 port" }, /* PNP0313, XXX */
Add PnP PS/2 id for Dell Latitude X200. PR: 48516 MFC after: 2 weeks
2003-07-01 14:41:16 +00:00
{ 0x02002e4f, "Dell PS/2 mouse port" }, /* Lat. X200, Dell */
Refine ACPI/PnP BIOS probe/attach routines a bit. - Add workaround for the problematic PnP BIOS which does not assign irq resource for the PS/2 mouse device node; if there is no irq assigned for the PS/2 mouse node, refer to device.hints for an irq number. If we still don't find an irq number in the hints database, use a hard-coded value. - Delete unused ivars. - Bit of clean up in probe/attach. - Add PnP ID for the PS/2 mouse port on some IBM ThinkPad models.
2001-09-15 04:38:20 +00:00
{ 0x80374d24, "IBM PS/2 mouse port" }, /* IBM3780, ThinkPad */
Add PnP ID 'IBM3781' for TP240 mouse.
2001-10-03 07:26:28 +00:00
{ 0x81374d24, "IBM PS/2 mouse port" }, /* IBM3781, ThinkPad */
Add yet another Sony Vaio PS/2 mouse ID. This one is found on a VX88. Submitted by: marcel
2003-01-22 03:31:08 +00:00
{ 0x0190d94d, "SONY VAIO PS/2 mouse port"}, /* SNY9001, Vaio */
{ 0x0290d94d, "SONY VAIO PS/2 mouse port"}, /* SNY9002, Vaio */
YAM: This id is found in a Sony Vaio GRX-670. When will this end? Submitted by: Chuck McCrobie <mccrobie2000@yahoo.com>
2003-01-22 22:02:09 +00:00
{ 0x0390d94d, "SONY VAIO PS/2 mouse port"}, /* SNY9003, Vaio */
Add yet another Sony Vaio PS/2 mouse ID. This one is found on a VX88. Submitted by: marcel
2003-01-22 03:31:08 +00:00
{ 0x0490d94d, "SONY VAIO PS/2 mouse port"}, /* SNY9004, Vaio */
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
{ 0 }
};
static int
create_a_copy(device_t atkbdc, device_t me)
{
device_t psm;
u_long irq;
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
/* find the PS/2 mouse device instance under the keyboard controller */
psm = device_find_child(atkbdc, PSM_DRIVER_NAME,
device_get_unit(atkbdc));
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
if (psm == NULL)
return ENXIO;
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
if (device_get_state(psm) != DS_NOTPRESENT)
return 0;
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
/* move our resource to the found device */
irq = bus_get_resource_start(me, SYS_RES_IRQ, 0);
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
bus_set_resource(psm, SYS_RES_IRQ, KBDC_RID_AUX, irq, 1);
/* ...then probe and attach it */
return device_probe_and_attach(psm);
}
static int
psmcpnp_probe(device_t dev)
{
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
struct resource *res;
u_long irq;
int rid;
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
if (ISA_PNP_PROBE(device_get_parent(dev), dev, psmcpnp_ids))
return ENXIO;
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
/*
* The PnP BIOS and ACPI are supposed to assign an IRQ (12)
* to the PS/2 mouse device node. But, some buggy PnP BIOS
* declares the PS/2 mouse device node without an IRQ resource!
* If this happens, we shall refer to device hints.
* If we still don't find it there, use a hardcoded value... XXX
*/
rid = 0;
irq = bus_get_resource_start(dev, SYS_RES_IRQ, rid);
if (irq <= 0) {
if (resource_long_value(PSM_DRIVER_NAME,
device_get_unit(dev), "irq", &irq) != 0)
irq = 12; /* XXX */
device_printf(dev, "irq resource info is missing; "
"assuming irq %ld\n", irq);
bus_set_resource(dev, SYS_RES_IRQ, rid, irq, 1);
}
Convert callers to the new bus_alloc_resource_any(9) API. Submitted by: Mark Santcroos <marks@ripe.net> Reviewed by: imp, dfr, bde
2004-03-17 17:50:55 +00:00
res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid,
RF_SHAREABLE);
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
bus_release_resource(dev, SYS_RES_IRQ, rid, res);
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
/* keep quiet */
if (!bootverbose)
device_quiet(dev);
Refine ACPI/PnP BIOS probe/attach routines a bit. - Add workaround for the problematic PnP BIOS which does not assign irq resource for the PS/2 mouse device node; if there is no irq assigned for the PS/2 mouse node, refer to device.hints for an irq number. If we still don't find an irq number in the hints database, use a hard-coded value. - Delete unused ivars. - Bit of clean up in probe/attach. - Add PnP ID for the PS/2 mouse port on some IBM ThinkPad models.
2001-09-15 04:38:20 +00:00
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
return ((res == NULL) ? ENXIO : 0);
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
}
static int
psmcpnp_attach(device_t dev)
{
Refine ACPI/PnP BIOS probe/attach routines a bit. - Add workaround for the problematic PnP BIOS which does not assign irq resource for the PS/2 mouse device node; if there is no irq assigned for the PS/2 mouse node, refer to device.hints for an irq number. If we still don't find an irq number in the hints database, use a hard-coded value. - Delete unused ivars. - Bit of clean up in probe/attach. - Add PnP ID for the PS/2 mouse port on some IBM ThinkPad models.
2001-09-15 04:38:20 +00:00
device_t atkbdc;
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
int rid;
Refine ACPI/PnP BIOS probe/attach routines a bit. - Add workaround for the problematic PnP BIOS which does not assign irq resource for the PS/2 mouse device node; if there is no irq assigned for the PS/2 mouse node, refer to device.hints for an irq number. If we still don't find an irq number in the hints database, use a hard-coded value. - Delete unused ivars. - Bit of clean up in probe/attach. - Add PnP ID for the PS/2 mouse port on some IBM ThinkPad models.
2001-09-15 04:38:20 +00:00
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
/* find the keyboard controller, which may be on acpi* or isa* bus */
atkbdc = devclass_get_device(devclass_find(ATKBDC_DRIVER_NAME),
device_get_unit(dev));
if ((atkbdc != NULL) && (device_get_state(atkbdc) == DS_ATTACHED)) {
Refine ACPI/PnP BIOS probe/attach routines a bit. - Add workaround for the problematic PnP BIOS which does not assign irq resource for the PS/2 mouse device node; if there is no irq assigned for the PS/2 mouse node, refer to device.hints for an irq number. If we still don't find an irq number in the hints database, use a hard-coded value. - Delete unused ivars. - Bit of clean up in probe/attach. - Add PnP ID for the PS/2 mouse port on some IBM ThinkPad models.
2001-09-15 04:38:20 +00:00
create_a_copy(atkbdc, dev);
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
} else {
/*
* If we don't have the AT keyboard controller yet,
* just reserve the IRQ for later use...
* (See psmidentify() above.)
*/
rid = 0;
Convert callers to the new bus_alloc_resource_any(9) API. Submitted by: Mark Santcroos <marks@ripe.net> Reviewed by: imp, dfr, bde
2004-03-17 17:50:55 +00:00
bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, RF_SHAREABLE);
Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems.
2001-09-25 16:59:28 +00:00
}
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
return 0;
}
Significantly reduce the "jitter" that is typical for PS/2 mice when using a KVM. There is no actual solution possible, but this gets us pretty close. Typically when switching back to a FreeBSD box and moving the mouse wild data is produced, because the protocol's validation/checksum system is extremely weak it is impossible to determine that we're out of sync before dropping several bogus packets to user land. The actual solution that appears to offer the best clamping of jitter is to buffer the mouse packets if we've not seen mouse activity for more than .5 seconds. Then waiting to flush that data for 1/20th of a second. If within that 20th of a second we get any packets that do fail the weak test we drop the entire queue and back off accepting data from the mouse for 2 seconds and then repeat the whole deal. You can still get _some_ jitter, notably if you switch to the FreeBSD box, then move the mouse just enough to generate one or two packets. Those packets may be bogus, but may still pass the validity check. One way to finally kill the problem once and for all is to check the initial packets for "wild" values. Typically one sees packets in the +/-60 range during normal operation, however when bogus data is generated it's typically near the outer range of +/-120 or more, those packets would be a good candidate for dropping or clamping. I've been running with this for several weeks now and it has significantly helped me stay sane even with a piece of junk Belkin KVM causing wild jitter each and every time I switch. Lastly I'd like to note that my experience with Windows shows me that somehow the Microsoft PS/2 driver typically avoids this problem, but that may only be possible when running the mouse in a dumb-ed down PS/2 mode that Belkin recommends on their site.
2003-12-11 11:28:11 +00:00
/*
* Return true if 'now' is earlier than (start + (secs.usecs)).
* Now may be NULL and the function will fetch the current time from
* getmicrouptime(), or a cached 'now' can be passed in.
* All values should be numbers derived from getmicrouptime().
*/
static int
timeelapsed(start, secs, usecs, now)
const struct timeval *start, *now;
int secs, usecs;
{
struct timeval snow, tv;
/* if there is no 'now' passed in, the get it as a convience. */
if (now == NULL) {
getmicrouptime(&snow);
now = &snow;
}
tv.tv_sec = secs;
tv.tv_usec = usecs;
timevaladd(&tv, start);
return (timevalcmp(&tv, now, <));
}
Update the atkbdc, atkbd, and psm drivers to probe/attach more cleanly and consistently in all APCI, PnP BIOS, and "hint" cases. NOTE: this doesn't necessarily solve the problem that the PS/2 mouse is not detected after the recent ACPI update.
2001-09-06 12:09:26 +00:00
DRIVER_MODULE(psmcpnp, isa, psmcpnp_driver, psmcpnp_devclass, 0, 0);
DRIVER_MODULE(psmcpnp, acpi, psmcpnp_driver, psmcpnp_devclass, 0, 0);
Reference in New Issue Copy Permalink