WSMUX(4)

πŸ“¦
version 11.0 Β· 2 versions
, in nixpkgs unstable

πŸ’… WSMUX(4) β€” console keyboard/mouse multiplexor for wscons πŸ’…

Okay bestie, this is WSMUX(4) from the Kernel Interfaces Manual, and it’s literally the friend group for your input devices.

✨ NAME ✨

wsmux β€” console keyboard/mouse multiplexor for wscons

🌸 SYNOPSIS 🌸

Set it up like this, no cap:

wskbd*    at ... mux 1
wsbell*   at ... mux 1
wsmouse*  at ... mux 0

pseudo-device wsmux

πŸ’… DESCRIPTION πŸ’…

The wsmux is a pseudo-device driver that lets several wscons(4) input devices have their events multiplexed into one stream. It’s giving one big group chat for input events, and honestly? Obsessed.

The typical usage for this device is to have two multiplexors: one for mouse events and one for keyboard and bell events. All wsmouse(4) devices should direct their events to the mouse mux (normally 0), and all keyboard devices, except the console, should direct their events to the keyboard mux (normally 1). A device will send its events to the mux indicated by the mux locator. If none is given, the device will not use a multiplexor. iykyk.

The keyboard multiplexor should be connected to the display, using the wsconscfg(8) command. It will then receive all keystrokes from all keyboards and, furthermore, keyboards can be dynamically attached and detached without further user interaction. Main character energy: keyboards can come and go and nobody has to touch anything. Additionally, bell events generated for the display will be directed to all attached wsbell(4) devices. In a similar way, the window system will open the mouse multiplexor and receive all mouse events; mice can also be dynamically attached and detached.

Heads up bestie: If a wskbd(4), wsbell(4), or wsmouse(4) device is opened despite having a mux, it will be detached from the mux. The mux said β€œnot me being abandoned,” and honestly same.

It is also possible to inject events into a multiplexor from a user program. Slay: user programs can literally slide into the mux’s DMs with events.

πŸŽ€ FILES πŸŽ€

  • For each mux device, /dev/wsmuxN there is a control device /dev/wsmuxctlN.
  • The control device has a minor number 128 greater than the regular mux device.
  • It can be used to control the mux even when it is open, e.g., by wsmuxctl(8).
  • /dev/wsmouse a.k.a. /dev/wsmux0
  • /dev/wskbd a.k.a. /dev/wsmux1
  • /usr/include/dev/wscons/wsconsio.h

πŸ¦‹ SEE ALSO πŸ¦‹

Go read these besties: wsbell(4), wscons(4), wsdisplay(4), wskbd(4), wsmouse(4), moused(8), wsconscfg(8), wsconsctl(8), wsmoused(8), wsmuxctl(8).

⚠️ CAVEATS ⚠️

Real talk: If more than one type of keyboard is used, WSKBDIO_GTYPE will return the type of the first keyboard.

Mwah πŸ’‹ β€” this page came from Debian and is dated August 13, 2019. Periodt.

πŸ“¦ where this page comes from