MSCONVD(8)
π MSCONVD(8) β System Manager's Manual π
Okay so bestie, this is the MSCONVD(8) page from the System Manager's Manual, and it's literally the mouse protocol conversion daemon. It's giving legacy-mouse-whisperer main character energy. β¨
β¨ NAME β¨
msconvd β mouse protocol conversion daemon
π SYNOPSIS π
msconvd [-DPRcdfs] [-I file] [-F rate] [-r resolution] [-S baudrate]
[-t mousetype] [-l level] -p port
msconvd [-Pd] -p port -i info
π DESCRIPTION π
Okay so here's the tea, bestie: the msconvd utility and the moused(8) driver work together to support legacy devices like COM, ams(4) mices, and X10 remotes as well. psm(4), ums(4) and some other devices are supported too, but lowkey not recommended to use with msconvd unless the kernel is compiled without option EVDEV_SUPPORT.
The msconvd listens to the specified port for mouse data, decodes it, and then passes it via input event device a.k.a evdev to consumer applications like moused(8) or libinput(1).
Vibe check: it does not display the mouse pointer on the screen or provide cut and paste functions. Periodt. π
The msconv daemon converts translation movement, button press/release events, and movement of the roller or the wheel if available.
If the msconvd receives the signal SIGHUP, it will reopen the mouse port and reinitialize itself. Useful if the mouse is attached/detached while the system is suspended.
If the msconvd receives the signal SIGUSR1, it will stop passing mouse events. Sending the signal SIGUSR1 again will resume passing mouse events. Useful if you're typing on a laptop and accidentally touch the mouse pad. π
The following options are available:
-Dβ Lower DTR on the serial port. This option is valid only ifmousesystemsis selected as the protocol type. The DTR line may need to be dropped for a 3-button mouse to operate in themousesystemsmode.-F rateβ Set the report rate (reports/sec) of the device if supported.-I fileβ Write the process id of themsconvdutility in the specified file. Without this option, the process id will be stored in/var/run/moused.pid.-Pβ Do not start the Plug and Play COM device enumeration procedure when identifying the serial mouse. If this option is given together with the-ioption, themsconvdutility will not be able to print useful information for the serial mouse.-Rβ Lower RTS on the serial port. This option is valid only ifmousesystemsis selected as the protocol type by the-toption below. It is often used with the-Doption above. Both RTS and DTR lines may need to be dropped for a 3-button mouse to operate in themousesystemsmode.-S baudrateβ Select the baudrate for the serial port (1200to9600). Not all serial mice support this option.-cβ Some mice report middle button down events as if the left and right buttons are being pressed. This option handles this.-dβ Enable debugging messages.-fβ Do not become a daemon and instead run as a foreground process. Useful for testing and debugging.-i infoβ Print specified information and quit. Available pieces of information are:portβ Port (device file) name, i.e./dev/cuau0,/dev/ums0and/dev/psm0.ifβ Interface type:serialorps/2.typeβ Protocol type. It is one of the types listed under the-toption below orsysmouseif the driver supports thesysmousedata format standard.modelβ Mouse model. Themsconvdutility may not always be able to identify the model.allβ All of the above items. Print port, interface, type and model in this order in one line.
If the msconvd utility cannot determine the requested information, it prints unknown or generic.
-l levelβ Specifies at which levelmsconvdshould operate the mouse driver. Refer to βOperation Levelsβ inpsm(4)for more information on this.-p portβ Useportto communicate with the mouse.-r resolutionβ Set the resolution of the device; in Dots Per Inch, orlow,medium-low,medium-highorhigh. This option may not be supported by all the device.-sβ Select a baudrate of9600for the serial line. Not all serial mice support this option.-t typeβ Specify the protocol type of the mouse attached toport. You may explicitly specify a type listed below, or useautoto let themsconvdutility automatically select an appropriate protocol for the given mouse. If you entirely omit this option in the command line,-t autois assumed. Under normal circumstances, you need to use this option only if themsconvdutility is not able to detect the protocol automatically (see βConfiguring Mouse Protocol Conversion Daemonβ).- Note that if a protocol type is specified with this option, the
-Poption above is implied and the Plug and Play COM device enumeration procedure will be disabled. - Also note that if your mouse is attached to the PS/2 mouse port, you should always choose
autoorps/2, regardless of the brand and model of the mouse. - For the USB mouse, the protocol must be
auto. No other protocol will work with the USB mouse. - Valid types for this option are listed below.
- For the serial mouse:
microsoftβ Microsoft serial mouse protocol. Most 2-button serial mice use this protocol.intellimouseβ Microsoft IntelliMouse protocol. Genius NetMouse, ASCII Mie Mouse, Logitech MouseMan+ and FirstMouse+ use this protocol too. Other mice with a roller/wheel may be compatible with this protocol.mousesystemsβ MouseSystems 5-byte protocol. 3-button mice may use this protocol.mmseriesβ MM Series mouse protocol.logitechβ Logitech mouse protocol. Note that this is for old Logitech models.mousemanorintellimouseshould be specified for newer models.mousemanβ Logitech MouseMan and TrackMan protocol. Some 3-button mice may be compatible with this protocol. Note that MouseMan+ and FirstMouse+ useintellimouseprotocol rather than this one.glidepointβ ALPS GlidePoint protocol.thinkingmouseβ Kensington ThinkingMouse protocol.mmhitabβ Hitachi tablet protocol.x10mouseremoteβ X10 MouseRemote.kidspadβ Genius Kidspad and Easypad protocol.versapadβ Interlink VersaPad protocol.gtco_digipadβ GTCO Digipad protocol.
- For the PS/2 mouse:
ps/2β This is the only protocol type available for the PS/2 mouse and should be specified for any PS/2 mice, regardless of the brand.
- For the USB mouse:
autois the only protocol type available for the USB mouse and should be specified for any USB mice, regardless of the brand.
- Note that if a protocol type is specified with this option, the
π Configuring Mouse Protocol Conversion Daemon π
The first thing you need to know is the interface type of the mouse you are going to use. It can be determined by looking at the connector of the mouse. The serial mouse has a D-Sub female 9- or 25-pin connector. The bus and InPort mice have either a D-Sub male 9-pin connector or a round DIN 9-pin connector. The PS/2 mouse is equipped with a small, round DIN 6-pin connector. Some mice come with adapters with which the connector can be converted to another. If you are to use such an adapter, remember the connector at the very end of the mouse/adapter pair is what matters. The USB mouse has a flat rectangular connector.
The next thing to decide is a port to use for the given interface. The PS/2 mouse is always at /dev/psm0. There may be more than one serial port to which the serial mouse can be attached. Many people often assign the first, built-in serial port /dev/cuau0 to the mouse. You can attach multiple USB mice to your system or to your USB hub. They are accessible as /dev/ums0, /dev/ums1, and so on.
You may want to create a symbolic link /dev/mouse pointing to the real port to which the mouse is connected, so that you can easily distinguish which is your βmouseβ port later.
The next step is to guess the appropriate protocol type for the mouse. The msconvd utility may be able to automatically determine the protocol type. Run the msconvd utility with the -i option and see what it says. If the command can identify the protocol type, no further investigation is necessary on your part. You may start the daemon without explicitly specifying a protocol type (see βEXAMPLESβ).
The command may print sysmouse if the mouse driver supports this protocol type.
Note that the type and model printed by the -i option do not necessarily match the product name of the pointing device in question, but they may give the name of the device with which it is compatible.
If the -i option yields nothing, you need to specify a protocol type to the msconvd utility by the -t option. You have to make a guess and try. There is rule of thumb:
- The
ps/2protocol should always be specified for the PS/2 mouse regardless of the brand of the mouse. - You must specify the
autoprotocol for the USB mouse. - Most 2-button serial mice support the
microsoftprotocol. - 3-button serial mice may work with the
mousesystemsprotocol. If it does not, it may work with themicrosoftprotocol although the third (middle) button will not function. 3-button serial mice may also work with themousemanprotocol under which the third button may function as expected. - 3-button serial mice may have a small switch to choose between βMSβ and βPCβ, or β2β and β3β. βMSβ or β2β usually mean the
microsoftprotocol. βPCβ or β3β will choose themousesystemsprotocol. - If the mouse has a roller or a wheel, it may be compatible with the
intellimouseprotocol.
To test if the selected protocol type is correct for the given mouse, ensure moused(8) is running in auto port mode,
moused -p auto
start msconvd in the foreground mode,
msconvd -f -p <selected_port> -t <selected_protocol>
and see if the mouse pointer travels correctly according to the mouse movement. Then try cut & paste features by clicking the left, right and middle buttons. Type Ctrl+C (^C) to stop the command.
π Multiple Mice π
Okay bestie, this is the part that's genuinely iconic β you can run as many instances of msconvd as you have mice plugged in. Like, one daemon per mouse. No sharing, no fighting, everybody gets their own.
Why would you even want that? Picture this: you're on your laptop with the built-in PS/2 pointing device, living your travel era βοΈ, and then you get to the office and dock the thing and want your serial mouse instead. So you run two msconvds and then the application program, e.g. moused(8), will always see mouse data from either mouse. The way that works is lowkey genius:
- When the serial mouse isn't attached, its corresponding
msconvdjustβ¦ doesn't detect any movement or button state change. Nothing. Ghost town. So the application only sees mouse data coming from the daemon for the PS/2 mouse. - In contrast, when both mice are attached and you move both of them at the same time in this configuration, the mouse pointer will travel across the screen just as if the movement of the mice is combined all together. Fr fr, they team up. π«Ά
π FILES π
/dev/input/event%dβ input event device/dev/psm%dβ PS/2 mouse driver/dev/cuau%dβ serial port/dev/ttyv%dβ virtual consoles/dev/ums%dβ USB mouse driver/var/run/msconvd.pidβ process id of the currently runningmsconvdutility/var/run/MouseRemoteβ UNIX-domain stream socket for X10 MouseRemote events
β¨ EXAMPLES β¨
Okay so these are the actual use cases, and honestly they ate:
msconvd -p /dev/cuau0 -i type
Let the msconvd utility determine the protocol type of the mouse at the serial port /dev/cuau0. If successful, the command will print the type, otherwise it will say βunknownβ. π A little mystery never hurt anybody.
msconvd -p /dev/cuau0
If the msconvd utility is able to identify the protocol type of the mouse at the specified port automatically, you can start the daemon without the -t option. Let it cook. π₯
msconvd -p /dev/mouse -t microsoft
Start the mouse daemon on the serial port /dev/mouse. The protocol type microsoft is explicitly specified by the -t option. No guessing needed, you're being so direct and honestly? Slay.
If you add
ALL ALL = NOPASSWD: /usr/bin/killall -USR1 msconvd
to your /usr/local/etc/sudoers file, and bind
killall -USR1 msconvd
to a key in your window manager, you can suspend mouse events on your laptop if you keep brushing over the mouse pad while typing. π The classic "my thumb grazed the trackpad and now my cursor is in another timezone" situation β solved. Main character energy.
π SEE ALSO π
moused(8), kill(1), xset(1), psm(4), screen(4), sysmouse(4), uart(4)
Go read those too, they're all in the group chat. π
π STANDARDS π
The msconvd utility partially supports βPlug and Play External COM Device Specificationβ in order to support PnP serial mice. Partially!! Emphasis on partially, bestie.
However, due to various degrees of conformance to the specification by existing serial mice, it does not strictly follow the version 1.0 of the standard. So it's giving "I read the syllabus but I didn't do every reading." π Even with this less strict approach, it may not always determine an appropriate protocol type for the given serial mouse. Not every mouse is gonna cooperate, and that's not the daemon's fault.
π¦ HISTORY π¦
The msconvd utility first appeared in FreeBSD 15.0. It is a cropped-down version of FreeBSD 14.0 moused(8) utility originated back in FreeBSD 2.2. So it's like the younger sibling that got the good genes β shorter, cuter, still iconic. β¨
π AUTHORS π
The msconvd utility is based on moused(8) written by Michael Smith <msmith@FreeBSD.org>. This manual page is extracted from moused(8) page written by Mike Pritchard <mpp@FreeBSD.org>. The command and manual page have since been updated by Kazutaka Yokota <yokota@FreeBSD.org>.
Legends, all three of them. π«Ά
π CAVEATS π
Read this part, fr fr:
- Many pad devices behave as if the first (left) button were pressed if the user βtapsβ the surface of the pad. So your "gentle little tap" is registering as a full click. Rude, honestly.
- In contrast, some ALPS GlidePoint and Interlink VersaPad models treat the tapping action as fourth button events.
- Use the option
-m 1=4ofmoused(8)for these models to obtain the same effect as the other pad devices. That's the fix β go forth and tap in peace. πΈ
ngl bestie, that's the whole page. You're now officially fluent in msconvd. Go forth and point and click. π
Cute little sign-off: this beauty comes to you from the Debian edition of the page, dated May 18, 2025 β so you know it's fresh. πβ¨
π¦ where this page comes from
- freebsd 15.1: base 15.1
- π the page's license: BSD-4-Clause
- Copyright (c) 1996 Mike Pritchard <mpp@FreeBSD.org>. All rights reserved
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms