MSE(4)

πŸ’– MSE β€” bus and InPort mice driver πŸ’–

i386 Kernel Interfaces Manual β€” yes bestie, we're reading the mse page together, grab a snack πŸ“


✨ NAME ✨

mse β€” bus and InPort mice driver 🐭


🌸 SYNOPSIS 🌸

device mse

In /boot/device.hints:

hint.mse.0.at="isa"
hint.mse.0.port="0x23c"
hint.mse.0.irq="5"

πŸ¦‹ DESCRIPTION πŸ¦‹

So the mse driver is the girl who handles support for the bus mouse and the InPort mouse β€” and everyone lowkey just calls them both ``bus'' mice because these mice ship with an interface card that you literally have to install in an expansion bus slot. The interface circuit might come on an integrated I/O card, or it can be an option on video cards. It's giving ✨versatile✨.

The bus and InPort mice have two or three buttons, and either a D-sub 9-pin male connector or a round DIN 9-pin male connector. Cute little guys ngl πŸ’…

The primary port address of the bus and InPort mouse interface cards is usually 0x23c. Some cards can also be set to use the secondary port address at 0x238. The interface cards need a single IRQ, which may be 2, 3, 4 or 5. Some cards offer additional IRQs too, no cap. The port number and the IRQ number get configured by jumpers on the cards or by software that comes with the card πŸŽ€

Frequency β€” aka report rate, aka how often the device sends movement and button state reports to the host system β€” may also be configurable on some interface cards. It may be 15, 30, 60 or 120Hz. ⏱️

The difference between the two types of mice is not in the mouse devices (fr fr they are exactly the same). It's in the circuit on the interface cards. Which means the device from a bus mouse package can be connected to the interface card from an InPort mouse package, or vice versa, as long as their connectors match. Mix and match, it's giving main character energy πŸ‘‘

🧚 Operation Levels 🧚

The mse driver has two levels of operation. The current operation level can be set via an ioctl call.

At level zero the basic support is provided; the device driver will report horizontal and vertical movement of the attached device and the state of up to three buttons in the format described below. It's a subset of the MouseSystems protocol.

  • Byte 1
    • bit 7 β€” always one.
    • bit 6..3 β€” always zero.
    • bit 2 β€” left button status; cleared if pressed, otherwise set.
    • bit 1 β€” middle button status; cleared if pressed, otherwise set. Always one, if the device does not have the middle button.
    • bit 0 β€” right button status; cleared if pressed, otherwise set.
  • Byte 2 β€” horizontal movement count in two's compliment; -128 through 127.
  • Byte 3 β€” vertical movement count in two's compliment; -128 through 127.
  • Byte 4 β€” always zero.
  • Byte 5 β€” always zero.

This is the default level of operation and the driver is initially at this level when opened by the user program. So that's where you're at when you show up πŸ’–

At the operation level one (extended level), a data packet is encoded in the standard format MOUSE_PROTO_SYSMOUSE as defined in mouse(4). Upgrade era ✨

πŸ’« Acceleration πŸ’«

The mse driver can somewhat accelerate' the movement of the pointing device. The faster you move the device, the further the pointer travels on the screen. The driver has an internal variable which governs the effect of the acceleration. Its value can be modified via the driver flag or via an ioctl` call. Zoom zoom πŸ¦‹

🌈 Device Number 🌈

The minor device number of the mse is made up of:

minor = (`unit' << 1) | `non-blocking'

where unit is the device number (usually 0) and the non-blocking bit is set to indicate ``do not block waiting for mouse input, return immediately''. The non-blocking bit should be set for XFree86, therefore the minor device number usually used for XFree86 is 1. See β€œFILES” for device node names.


πŸŽ€ DRIVER CONFIGURATION πŸŽ€

⭐ Driver Flags ⭐

The mse driver accepts the following driver flag. Set it in the kernel configuration file (see config(8)) or in the User Configuration Menu at the boot time (see boot(8)).

  • bit 4..7 ACCELERATION β€” this flag controls the amount of acceleration effect. The smaller the value of this flag is, more sensitive the movement becomes. The minimum value allowed, thus the value for the most sensitive setting, is one. Setting this flag to zero will completely disables the acceleration effect.
Not me warning you that zero = no acceleration at all, that's the whole vibe check right there πŸ™ˆ

πŸ’… IOCTLS πŸ’…

There are a few ioctl(2) commands for mouse drivers. These commands and related structures and constants are defined in <sys/mouse.h>. General description of the commands is given in mouse(4). This section explains the features specific to the mse driver β€” the ✨exclusive✨ mse lore.

  • MOUSE_GETLEVEL int *level
  • MOUSE_SETLEVEL int *level β€” These commands manipulate the operation level of the mse driver. Slay, level up πŸ’–
  • MOUSE_GETHWINFO mousehw_t *hw β€” Returns the hardware information of the attached device in the following structure. Only the iftype field is guaranteed to be filled with the correct value by the current version of the mse driver. (So don't come for the other fields, they're just out here living their truth.)
typedef struct mousehw {
    int buttons;    /* number of buttons */
    int iftype;     /* I/F type */
    int type;       /* mouse/track ball/pad... */
    int model;      /* I/F dependent model ID */
    int hwid;       /* I/F dependent hardware ID */
} mousehw_t;

The buttons field holds the number of buttons on the device.

The iftype is either MOUSE_IF_BUS or MOUSE_IF_INPORT.

The type may be MOUSE_MOUSE, MOUSE_TRACKBALL, MOUSE_STICK, MOUSE_PAD, or MOUSE_UNKNOWN.

The model is always MOUSE_MODEL_GENERIC at the operation level 0. It may be MOUSE_MODEL_GENERIC or one of MOUSE_MODEL_XXX constants at higher operation levels.

The hwid is always 0.

  • MOUSE_GETMODE mousemode_t *mode β€” The command gets the current operation parameters of the mouse driver.
typedef struct mousemode {
    int protocol;    /* MOUSE_PROTO_XXX */
    int rate;        /* report rate (per sec), -1 if unknown */
    int resolution;  /* MOUSE_RES_XXX, -1 if unknown */
    int accelfactor; /* acceleration factor */
    int level;       /* driver operation level */
    int packetsize;  /* the length of the data packet */
    unsigned char syncmask[2]; /* sync. bits */
} mousemode_t;

The protocol is either MOUSE_PROTO_BUS or MOUSE_PROTO_INPORT at the operation level zero. MOUSE_PROTO_SYSMOUSE at the operation level one.

The rate is the status report rate (reports/sec) at which the device will send movement report to the host computer. As there is no standard to detect the current setting, this field is always set to -1.

The resolution is always set to -1.

The accelfactor field holds a value to control acceleration feature (see β€œAcceleration”). It is zero or greater. If it is zero, acceleration is disabled.

The packetsize field specifies the length of the data packet. It depends on the operation level.

  • level 0 β€” 5 bytes
  • level 1 β€” 8 bytes

The array syncmask holds a bit mask and pattern to detect the first byte of the data packet. syncmask[0] is the bit mask to be ANDed with a byte. If the result is equal to syncmask[1], the byte is likely to be the first byte of the data packet. Note that this detection method is not 100% reliable, thus, should be taken only as an advisory measure. (It's giving "trust but verify", bestie 😭)

Only level and accelfactor are modifiable by the MOUSE_SETMODE command. Changing the other field does not cause error, but has no effect.

  • MOUSE_SETMODE mousemode_t *mode β€” The command changes the current operation parameters of the mouse driver as specified in mode. Only level and accelfactor may be modifiable. Setting values in the other field does not generate error and has no effect.
  • MOUSE_READDATA mousedata_t *data
  • MOUSE_READSTATE mousedata_t *state β€” These commands are not supported by the mse driver. Sorry bestie, not today πŸ’€
  • MOUSE_GETSTATUS mousestatus_t *status β€” The command returns the current state of buttons and movement counts as described in mouse(4).

πŸ“ FILES πŸ“

  • /dev/mse0 β€” non-blocking' device node in the system without devfs, blocking' under devfs.
  • /dev/nmse0 β€” `non-blocking' device node under devfs.

✨ EXAMPLES ✨

device mse

In /boot/device.hints:

hint.mse.0.at="isa"
hint.mse.0.port="0x23c"
hint.mse.0.irq="5"

Add the mse driver at the primary port address with the IRQ 5.

device mse

hint.mse.1.at="isa"
hint.mse.1.port="0x238"
hint.mse.1.irq="4"
hint.mse.1.flags="0x30"

Define the mse driver at the secondary port address with the IRQ 4 and the acceleration factor of 3.


🌈 SEE ALSO 🌈

ioctl(2), mouse(4), psm(4), sysmouse(4), moused(8)


⚠️ CAVEATS ⚠️

Some bus mouse interface cards generate interrupts at the fixed report rate when enabled, whether or not the mouse state is changing. The others generate interrupts only when the state is changing. Two different girls, two different energies 🫢


Okay that's the whole page, you ate that πŸ’… This one's from the Debian crew, dated December 3, 1997 β€” vintage icon behaviour, honestly iconic. Now go plug in your mouse and slay ✨🐭

πŸ“¦ where this page comes from