DInput
DirectInput is the part of DirectX that handles user inputs. It supports mouse, joystick and keyboard input.
Most DirectX 7 features are implemented. Some DirectX 8+ features missing (action map).
Joystick status
Joystick support is implemented - evdev, joydev and OS X drivers
Force feedback implemented but is very buggy and supported by evdev driver only.
Keyboard status
Keyboard is fully implemented.
Mouse status
There is a bit more work to be done on DInput / Mouse. While all the basic APIs have been implemented (enough to please all known games), the problems are as follows:
- DXGrab support needs to be verified. The problem here is that doing a mouse grab in X11 will restrict all inputs to the X connection which did the grab. Which means that only the thread that did the grab will get events. And as there may be one thread doing the DDraw stuff, another the DInput initialization and yet another actually reading from the device, it's hard to detect from where to grab the mouse.
- in Windows, DInput only supports relative mouse movements (absolute position reporting is buggy) while X11 only supports absolute mouse position reporting. This means that Wine has to emulate relative reporting with absolute positions. This has been implemented in Wine by warping the mouse cursor back to the middle of the screen on each move. This works but has the following adverse effects:
- for games actually doing DInput while still showing the cursor (Settlers III is one example), this plays hell with the mouse cursor and makes the game unplayable
- other games use DInput to get absolute mouse reporting while still using standard Win32 functions to get the absolute mouse position (clipped to the game window).
LionelUlmer is working on a new X11 extension to help the relative mouse movement issue (basically to add an extension to X11 that would add relative movements in addition to absolute positions). While waiting for this extension, moving all the warping stuff to the X11 driver would help fix problem 2 (but not problem 1 which requires for the clean solution the X11 extension but could be fixed in an ugly way using a hack).
The other problem is then architectural: how to move the DInput code to the X11 driver? Basically, the current DInput DLL only depends on DInput (and thus can be reused by ReactOS). Moving the mouse support to the X11 driver would mean that this DLL would be 'Wine-only' (except if the X11 driver <-> DInput DLL follows the DDK which is a path that I did not check yet).
Extension status
XInput 2 will feature relative mouse movements, and is coming to the 7.5 release of x.org. If you want to try out an early version, you can use git://people.freedesktop.org/~whot/xserver.git along with inputproto.git and libXi.git (use branch xi2 for all of these). whot (in #xorg-devel) told me that if we need any API changes to do this right, we can just ask him for it as well. Note that the Xserver in whot's tree is a 1.7 pre-release, and as such your input drivers will need to be recompiled if they support Xserver 1.6 or upgraded if they do not. Also, you need Xlib 1.2 or later to support XInput 2, and there's at least one bug on 64-bit in the XInput 2 stack, for which I (TBBle) have a fix to push to whot.
Also, at the time of writing, grabs are not yet implemented in XInput 2 so only non-exclusive DInput usage is possible.
Workers: ChristianCosta, LionelUlmer, MarcusMeissner, RaphaelJunqueira, RobertReif, VitaliyMargolen
