This site is being upgraded. There might be temporary layout issues. If you encounter errors, please try again later.

FS-UAE Amiga Emulator

Documentation

Mouse

Middle mouse button

Mouse wheel

Multiple mice

FS-UAE supports multiple mice on many platforms through the ManyMouse library by Ryan C. Gordon.

Note: FS-UAE 4 does not support multiple mice yet. The rest of the this section applies to FS-UAE 3 only, for now.

The old Mouse host device is still present and works like before - this is basically the system cursor, and most likely, all connected mice will affect this host device in FS-UAE.

If the support for multiple mice works on your system, you will have one additional specific host device for each mouse connected. So with two Microsoft Intellimouse devices connected, you might see these devices:

  • Mouse - This is controllable by both the physical mice
  • Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)
  • Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)

There might be some specific things you should be aware of, depending on your operating system. Read on for more information!

Mouse speed and acceleration

The old Mouse device is subject to acceleration settings, while direct hardware access to specific mouse devices is not. You may therefore want to use the new specific mouse devices for more pleasant mouse emulation regardless of the number of mice you have. You may even find that there is less input lag with the new mouse devices.

Windows

Support for multiple mice seems to work just fine on Windows out of the box. Note that with FS-UAE on modern Windows version, all devices seem to be named "HID-compliant mouse" instead of the actual device name, which makes a bit awkward to select the desired mouse device.

macOS

Note: Multiple mice are currently disabled on macOS. This is due to annoying security warnings that I need to find a workaround for.

Support for multiple mice seems to work just fine on macOS out of the box on older macOS versions.

In macOS 10.15, in order to see individual mouse devices, you may have to go to Preferences -> Security & Privacy -> Input Monitoring, and allow access for FS-UAE, FS-UAE Launcher and FS-UAE Arcade.

Mouse buttons on macOS

Linux

You may have to change permissions on some device nodes before starting FS-UAE (depending on your Linux distribution). If FS-UAE does not have permission to read from the devices, you will only get access to the old/single Mouse host device.

You can run this simple command to easily enable FS-UAE to open the mouse devices (after the mice are connected), though remember that this can have security implications if other people have remote access to the computer:

sudo chmod a+r /dev/input/*

A much better method is to tell the system to specifically make mouse event devices readable when they are plugged in:

Creating udev rules for readable mice

Note that the following works perfectly for me on Ubuntu, and it is possible you must do it slightly differently depending on your Linux distribution. Hopefully the instructions apply to you regardless of your Linux distribution :)

We need to create a config file with a udev rule to set read permissions for all mice which are connected. From a terminal, type:

sudo nano -w /etc/udev/rules.d/99-readable-mice.rules

Paste the following (on one line) in this file, and save it:

ENV{ID_INPUT_MOUSE}=="?*", MODE="644"

On my system, this was all that was needed - just unplug the mouse/mice and reconnect them for the changes to work.

To verify that it works, reconnect your mouse/mice if you haven't already and type:

ls -l /dev/input/event*

All files listed should now have read permissions for all users, something like this:

crw-rw-r-- 1 root input 13, 64 aug.  20 17:30 /dev/input/event0
crw-rw-r-- 1 root input 13, 65 aug.  20 17:30 /dev/input/event1

If it did not work, you have to do additional steps to activate the rules. Perhaps a command to reinitialize udev, such as as sudo udevstart, sudo /etc/init.d/udev restart, sudo udevcontrol reload_rules or sudo <em>udevadm trigger --subsystem-match=input and/or just reboot.

Try to google information about udev rules on your distribution if you have problems.

Evdev vs XInput2

The ManyMouse library really supports two drivers for Linux: XInput2 and Linux evdev interface. Normally, ManyMouse tries XInput2 first, and if that works, it will not use Linux evdev. In FS-UAE, I have reversed this order, so it will always try evdev first (and thus probably never use XInput2).

The reason for this is that when XInput2 is used and mouse input is grabbed by FS-UAE, no mouse events at all reach the ManyMouse library. It works fine when input grab is released. With the evdev driver, it always works fine.

FreeBSD / OpenBSD

Presumably, XInput2 should work well, with the caveat that input from specific mice probably only works when FS-UAE does not have input grabbed (See the Linux section for more information). You can use the option automatic_input_grab to prevent FS-UAE from grabbing the input.

If you are using FreeBSD / OpenBSD and have tested this feature, please leave feedback on fs-uae.net!

Running FS-UAE over VNC (or similar)

When FS-UAE is running over a remote desktop connection such as VNC, the mouse might not work correctly. This is due to FS-UAE trapping the mouse pointer and trying to read relative motion from it. This might be incompatible with for example VNC.

A workaround is to disable the automatic grabbing of the pointer (automatic_input_grab). If you're running Workbench and system-friendly programs, you can also enable mouse_integration. With this enabled, the emulated mouse pointer will follow the host mouse cursor.