Unfortunately the basic X11 API does not provide a way to distinguish between mouses (We are investigating the usefulness of XInput though). The only solution is to use the evdev devices (/dev/input/event*) and grab the raw mouse events. To make this a bit simpler, we used the input library libGII, which offered a driver using these input devices.
We implemented a serial port driver to emulate the second mouse, and still use dosbox' PS/2 emulation for the primary mouse. This means that the second mouse must be made invisible to X, since it generates both evdev and X CorePointer events. Newer Xservers using the evdev input driver use HAL to detect the available input devices. Our quick solution was to create a HAL policy that blocks the second mouse to be used by X11.
With a patched dosbox version, your dosbox.conf should have a section like this:
- Code: Select all
[serial]
serial1=mouse giidriver:input-linux-evdev:/dev/input/event4
You have to figure out the correct /dev/input/event* yourself, and also may have to chown it to 666, because current distributions usually do not make it user readable.
You can try other GII drivers on your own, but beware, since your computer will propably explode.
If you start the game now, you will notice that the secondary mouse will control both player. To prevent the second mouse being detected by X, you have to create a special HAL policy.
First you will have to find out the exact vendor and product ID of your mouse with lsusb (first column).
Then you create a file named like 10-dosbox-mouse.fdi and place it in /etc/hal/fdi/policy/ .
The file content should look like this, adapt it with your USB IDs:
Pay attention that leading zero's are stripped, so that 046d:c018 from lsusb gets converted to usb_device_46d_c018, like in the example.
- Code: Select all
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.mouse">
<match key="info.udi" contains="usb_device_46d_c018">
<merge key="input.x11_driver" type="string"></merge>
</match>
</match>
</device>
</deviceinfo>
Restart HAL, replug the mouse and enjoy your dysfunctional mouse. To reverse, just delete the .fdi file and repeat.
We are aware that this is not really a solid solution yet. We are currently investigating if we can achieve grabbing of a certain mouse with XInput, but the state of Linux APIs in this field seems to be rather sorry.
