wsmouse(4) [netbsd man page]
WSMOUSE(4) BSD Kernel Interfaces Manual WSMOUSE(4) NAME
wsmouse -- generic mouse support in wscons SYNOPSIS
wsmouse* at pms? mux 0 (PS/2 mouse, including ``IntelliMouse''-compatible wheel mice) wsmouse* at ums? mux 0 (USB mouse) wsmouse* at uts? mux 0 (USB touchscreen) wsmouse* at lms? mux 0 (Logitech bus mouse, i386 only) wsmouse* at mms? mux 0 (Microsoft InPort mouse, i386 only) wsmouse0 at ams? mux 0 (Apple ADB mouse) wsmouse* at btms? mux 0 (Bluetooth mouse) wsmouse* at lkms? mux 0 (DEC VSXXX serial mice) DESCRIPTION
The wsmouse driver is an abstraction layer for mice within the wscons(4) framework. It is attached to the hardware specific mouse drivers and provides a character device interface which returns struct wscons_event via read(2). For use with X servers, ``mouse events'' can be generated. The wsconsctl(8) utility gives access to several configurable details that affect this driver. Ioctls The following ioctl(2) calls are provided by the wsmouse driver or by devices which use it. Their definitions are found in dev/wscons/wsconsio.h. WSMOUSEIO_GETREPEAT (struct wsmouse_repeat) Retrieve the current automatic button repeating configuration. The structure returned is as follows: struct wsmouse_repeat { unsigned long wr_buttons; unsigned int wr_delay_first; unsigned int wr_delay_decrement; unsigned int wr_delay_minimum; }; The wr_buttons field is a bit mask that specifies which buttons send press and release events periodically while they are phys- ically held down. The least significant bit corresponds to button 0. The other three fields describe the frequency upon which these automatic events are sent. wr_delay_first specifies the mil- liseconds before the first repeated event is sent. wr_delay_decrement is used to calculate the delay between the most recently generated event and the forthcoming one: the previous delay is taken and it is decreased by the value given in this variable. wr_delay_minimum specifies the minimum delay, in milliseconds, between two consecutive events. WSMOUSEIO_SETREPEAT (struct wsmouse_repeat) Set the automatic button repeating configuration. See WSMOUSEIO_GETREPEAT above for more details. WSMOUSEIO_SETVERSION (int) Set the wscons_event protocol version. The default is 0 for binary compatibility. The latest version is always available as WSMOUSE_EVENT_VERSION, and is currently 1. All new code should use a call similar to the below to ensure the correct version is returned. int ver = WSMOUSE_EVENT_VERSION; if (ioctl(fd, WSMOUSEIO_SETVERSION, &ver) == -1) err(EXIT_FAILURE, "cannot set version"); FILES
/dev/wsmouse* /usr/include/dev/wscons/wsconsio.h. SEE ALSO
btms(4), lms(4), mms(4), pms(4), uep(4), ums(4), uts(4), wscons(4), wsmux(4), moused(8), wsconsctl(8), wsmoused(8), wsmouse(9) BSD
May 27, 2012 BSD
Check Out this Related Man Page
PMS(4) BSD Kernel Interfaces Manual PMS(4) NAME
pms -- PS/2 auxiliary port mouse driver SYNOPSIS
pckbc* at isa? pms* at pckbc? wsmouse* at pms? options PMS_DISABLE_POWERHOOK options PMS_SYNAPTICS_TOUCHPAD options PMS_ELANTECH_TOUCHPAD DESCRIPTION
The pms driver provides an interface to PS/2 auxiliary port mice within the wscons(4) framework. Parent device in terms of the autoconfigu- ration framework is pckbc(4), the PC keyboard controller. ``pms'' is a generic driver which supports mice using common variants of the PS/2 protocol, including wheel mice of the ``IntelliMouse'' breed. Wheel movements are mapped to a third (z-) axis. The driver is believed to work with both 3-button and 5-button mice with scroll wheels. Mice which use other protocol extensions are not currently supported, but might be if protocol documentation could be found. Mouse related data are accessed by wsmouse(4) devices. The pms driver has been updated to attempt to renegotiate mouse protocol after seeing suspicious or defective mouse protocol packets, or unusual delays in the middle of a packet; this should improve the chances that a mouse will recover after being switched away or reset (for instance, by a console switch). The PMS_DISABLE_POWERHOOK kernel option disables PS/2 reset on resume. In addition, the pms driver supports the ``Synaptics'' and ``Elantech'' touchpads in native mode, enabled with the PMS_SYNAPTICS_TOUCHPAD and PMS_ELANTECH_TOUCHPAD kernel options. This allows the driver to take advantage of extra features available on Synaptics and Elantech Touch- pads. The following sysctl(8) variables control behavior of Synaptics touchpads: hw.synaptics.up_down_emulation If the touchpad reports the existence of Up/Down buttons, this value determines if they should be reported as button 4 and 5 events or if they should be used to emulate some other event. When set to 0, report Up/Down events as buttons 4 and 5. When set to 1, the Up and Down buttons are both mapped to the middle button. When set to 2 (default), the Up and Down buttons are used for Z-axis emulation, which more closely resembles how mouse wheels operate. hw.synaptics.up_down_motion_delta When the Up/Down buttons are used for Z-axis emulation, this value specifies the emulated delta-Z value per click. hw.synaptics.gesture_move Gestures will not be recognised if the finger moves by more than this amount between taps. hw.synaptics.gesture_length Gestures will not be recognised if the number of packets (at 80 packets per second) between taps exceeds this value. hw.synaptics.edge_left hw.synaptics.edge_right hw.synaptics.edge_top hw.synaptics.edge_bottom These values define a border around the touchpad which will be used for edge motion emulation during a drag gesture. If a drag gesture is in progress and the finger moves into this border, the driver will behave as if the finger continues to move in the same direction beyond the edge of the touchpad. hw.synaptics.edge_motion_delta This specifies the pointer speed when edge motion is in effect. hw.synaptics.finger_high The driver will ignore new finger events until the reported pressure exceeds this value. hw.synaptics.finger_low The driver will assume a finger remains on the touchpad until the reported pressure drops below this value. hw.synaptics.two_fingers_emulation More recent touchpads can report the presence of more than one finger on the pad. This value determines how such events are used. If set to 0 (default), two-finger events are ignored. If set to 1, two-finger events generate a right button click. If set to 2, two-finger events generate a middle button click. hw.synaptics.scale_x hw.synaptics.scale_y Scale factor used to divide movement deltas derived from Synaptics coordinates (0-6143) to yield more reasonable values (default 16). hw.synaptics.max_speed_x hw.synaptics.max_speed_y Limits pointer rate of change (after scaling) per reported movement event (default 32). hw.synaptics.movement_threshold Movements of less than this value (in Synaptics coordinates) are ignored (default 4). The following sysctl(8) variables control behavior of Elantech touchpads: hw.elantech.xy_precision_shift hw.elantech.z_precision_shift Increased values improve the accuracy of X, Y, and Z-axis reporting at the expense of slower mouse movement (default 2 for xy, and 3 for z). For Elantech touchpads, the Z-axis is emulated using two-finger Y-axis reporting. SEE ALSO
pckbc(4), ums(4), wsmouse(4) AUTHORS
The pms driver was originally written by Christopher G. Demetriou. The changes to merge the ``IntelliMouse'' protocol in, and reset the mouse in the event of protocol problems, were contributed by Peter Seebach. Special thanks to Ray Trent, at Synaptics, who contributed valu- able insight into how to identify bogus mouse data. The changes to add ``Synaptics'' pad support were by Ales Krenek, Kentaro A. Kurahone, and Steve C. Woodford. The changes to add ``Elantech'' pad support were by Jared D. McNeill. BUGS
It is possible for the driver to mistakenly negotiate the non-scroll-wheel protocol, after which it is unlikely to recover until the device is closed and reopened. The ``Elantech'' pad code only supports trackpads with firmware version 2.48 or above. BSD
December 13, 2008 BSD