wine/This is an implementation of the xinput gamepad interface.
It works both in 32 and 64 bits.

The state of the pads have to be shared through multiple applications

    ie: both Steam/32 bits and No Man Sky/64 bits will access the service simultaneously.

I originally wrote this for Wine, but having it as a purely native daemon seemed a nice option.

The first client that comes tries to connect to the xinput server.
If the xinput server is not running, depending on the build options, it will either
_ spawn a daemon in its own thread and server other clients (as well as itself)
_ start a daemon and connect to it (that was the default behaviour under Wine)

If the connection to the daemon is lost, the selection process starts again.

The clients are communicating using a shared memory for getting the sticks and buttons states.
Rumble commands are sent using a posix message queue (Linux, something will have to be made for OSX)

This project made me realise that mutex and semaphores do NOT interact well between 32 and 64 bits apps on the same machine.
Given the organic nature of the pads input, mutexes are not so important.

On the TODO list:
_ change the protocol so clients use only read access to the shared memory

How to easily get a wine-staging with xinputd support:

Easy wine-staging-2.18 archive creation : simply fetch wine/wine-staging-make-archive.sh and run it in a console.
Easy wine-staging-2.18 Linux Arch package build : fetch wine/arch-linux-build-package.sh and run it in a console.

Minor edition of the scripts may be required to handle future wine releases (ie: VERSION value)

If you have a lot of memory on your build machine, building in a ramdisk will be faster and spare your disk/ssd. (Just don't forget to copy the package on permanent storage before rebooting ;) )

ie:
    mkdir /tmp/.ramdisk
    sudo mount -t ramfs -o size=8192m ramfs /tmp/.ramdisk
    sudo chown $USER /tmp/.ramdisk
    cd /tmp/.ramdisk