In traditional Linux, if you run two mouse-utilizing programs on two different virtual consoles, they will both try to open the mouse device. One will succeed, one will fail. Usually, this results in the failure of one of the two programs. Clearly, it would be better if the two programs could coexist and share the mouse, in the same way that they coexist and share the keyboard.
The problem stems from the fact that the keyboard is virtualized, but the mouse is not. This is easily fixed. We've created a simple mouse-driver module that can virtualize a mouse. It opens one physical mouse device, and creates 16 virtual mouse devices.
In the same way that a "tty" device represents both a virtual monitor and a virtual keyboard, we decided that a "graph" device could represent both a virtual monitor and a virtual mouse. Opening a graph device for writing gives you a virtual monitor. Opening one for reading gives you a virtual mouse. As with ttys, this isn't a strict pairing --- a graph device can be missing a monitor, or missing a mouse. When you load a mouse-driver module, you specify (via insmod parameters) which set of 16 graph devices the mouse should attach itself to.
While graph devices seem to "pair" the mice with the monitors, there is again no requirement that you actually use them in pairs. If an application program needs three mice, four graphics displays, and five keyboards, it need merely open three graph devices for reading, four graph devices for writing, and five tty devices for reading.
The mouse driver not only virtualizes the mouse, it also standardizes its protocol. Real physical mice speak mouse systems protocol, microsoft mouse protocol, or any number of other protocols. But no matter what protocol the physical device uses, the virtual mice all use the standard protocol.