Hi all,
Ok I sat down with Ken (the benefits of being in the same office) and after a lengthy discussion I have come to terms with how it may not be the most ideal plan to put the joystick driver into the graphics driver. However I am still of the strong opinion that we need some sort of better joystick architecture and I know Alexandre is also of the like mindset.
This was discussed back on 2005 and I know there was also recent discussion around BSD that also involves this. I also have an itch to start to poke at xinput, but I have no interest in poking at xinput with the current way joysticks are handled.
When I was working on this driver thing Alexandre expressed he was pretty opposed to having a whole new set of platform specific wine drivers. (winejoystick_mac, winejoystick_linux, etc...) But if we at least did that we would reduce code duplication by not having the platform specific code duplicated in 2 (with xinput it would become 3) places and have it collected in one place.
Now completely unresearched but it may be possible to make a single joystick driver, maybe replacing winejoystick.drv that would build only the platform code that is relevant.
but before I do another big chunk of work I am seeking some community buy-in and not just discuss with with Alexandre. I understand if the USB driver path gets actually fleshed out and we try to support Joysticks via that then all this separate driver work would fall away and be replaced.
We of course need to make sure we come up with a plan that Alexandre will approve of. Would a replacement winejoystick.drv that holds all the platform specific code be acceptable? Is there a case where we would want that driver to be able to build multiple platform code? Maybe Linux and Linux Input? I will admit I am pretty ignorant of the Linux side of this whole situation.
Ideas? Comments?
thanks! -aric
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/16/15 15:11, Aric Stewart wrote:
Ok I sat down with Ken (the benefits of being in the same office) and after a lengthy discussion I have come to terms with how it may not be the most ideal plan to put the joystick driver into the graphics driver. However I am still of the strong opinion that we need some sort of better joystick architecture and I know Alexandre is also of the like mindset.
One more thing that makes merging this into the graphics driver a bad idea: Assume we have a Wayland graphics driver one day. It would run on Linux, just like winex11. The way we talk to joysticks would be the same though.
Now completely unresearched but it may be possible to make a single joystick driver, maybe replacing winejoystick.drv that would build only the platform code that is relevant.
I'm OK with that, but I don't think my opinion actually matters.
but before I do another big chunk of work I am seeking some community buy-in and not just discuss with with Alexandre. I understand if the USB driver path gets actually fleshed out and we try to support Joysticks via that then all this separate driver work would fall away and be replaced.
What do you mean with USB? Have support for USB devices and talk to the raw USB device? In a way loading Windows joystick drivers or write our own?
If this is the plan, does this work well in practise? The permissions for accessing a USB device and an input device may be different. There are non-USB joysticks. (Gameport, and nowadays hard drives have acceleration sensors that get exposed as joysticks, but this may work via fake USB devices)
There's another issue that may be related: When I play a game with a joystick I usually don't touch my mouse or keyboard. That results in the monitor going into standby after the standby timeout expired. I suspect that d3d is supposed to disable screensavers (there are flags that essenially say don't disable my screensaver), though maybe the X server is supposed to read the joystick in some way and recognize that I am still using the computer.
On 16 April 2015 at 15:38, Stefan Dösinger stefandoesinger@gmail.com wrote:
On 04/16/15 15:11, Aric Stewart wrote:
Ok I sat down with Ken (the benefits of being in the same office) and after a lengthy discussion I have come to terms with how it may not be the most ideal plan to put the joystick driver into the graphics driver. However I am still of the strong opinion that we need some sort of better joystick architecture and I know Alexandre is also of the like mindset.
One more thing that makes merging this into the graphics driver a bad idea: Assume we have a Wayland graphics driver one day. It would run on Linux, just like winex11. The way we talk to joysticks would be the same though.
Arguably the way we talk to joysticks on Linux is just broken. I think it really would make much more sense for joysticks to go through X11 like every other input device. There may even be some multiseat considerations somewhere in there as well.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/16/15 15:49, Henri Verbeet wrote:
Arguably the way we talk to joysticks on Linux is just broken. I think it really would make much more sense for joysticks to go through X11 like every other input device. There may even be some multiseat considerations somewhere in there as well.
- From a design point of view yes, but are there any other Linux applications that do this? The few I have run either talk to /dev/js* or /dev/input/event*. I'm worried that we end up being the only application using a poorly tested codepath.
This here makes me doubt that going through the X server is a good idea: http://lists.freedesktop.org/archives/wayland-devel/2015-January/019462.html (without knowing who or how competent the author is)
On 16 April 2015 at 16:06, Stefan Dösinger stefandoesinger@gmail.com wrote:
On 04/16/15 15:49, Henri Verbeet wrote:
Arguably the way we talk to joysticks on Linux is just broken. I think it really would make much more sense for joysticks to go through X11 like every other input device. There may even be some multiseat considerations somewhere in there as well.
- From a design point of view yes, but are there any other Linux
applications that do this? The few I have run either talk to /dev/js* or /dev/input/event*. I'm worried that we end up being the only application using a poorly tested codepath.
Yeah. I have the impression it's mostly a case of "Why fix something if you can hack around it instead?", but it's true that in practice you can't really use joysticks through X.
This here makes me doubt that going through the X server is a good idea: http://lists.freedesktop.org/archives/wayland-devel/2015-January/019462.html (without knowing who or how competent the author is)
You can consider Peter Hutterer pretty much authoritative when it comes to X input. And yeah, it's probably one of those things that if you want it fixed you have to fix it yourself.
It seems the main issue with placing the joystick driver in the "graphics" driver (it's really more of a platform driver at this point) would be OS X joystick support when using winex11.drv. One option could perhaps be to share the OS X joystick code between winemac.drv and winex11.drv with e.g. PARENTSRC, although arguably that isn't exactly pretty either.
In addition to dinput, winmm, and xinput, joysticks can be accessed through user32 via the raw input API, and listed via WMI. There's code floating around that uses xinput in conjunction with both of those things.
Xinput combined with WMI: https://msdn.microsoft.com/en-us/library/ee417014%28v=vs.85%29.aspx XInput combined with raw input: http://snes-sdk.googlecode.com/svn/trunk/bsnes/src/ruby/input/rawinput.cpp
Note that in both of these cases it's expected that the device list returned by dinput is consistent with that returned by WMI and raw input, which is another reason it's important to have a common implementation.
I guess having a duplicate input device probably isn't too bad, but I vaguely remember hearing about games that ignore all joystick input if they don't think there's an xinput device available, based on those other API's.
Also, it seems according to MSDN any XInput device should have "IG_" in its name, so any common implementation will have to know whether the device is XInput or not, and probably will have to do the required remapping to the standard xinput layout (which sort of makes more sense than doing it in xinput anyway, as I've noticed games using joysticks through dinput that are hard-coded to expect the xinput layout). So, it seems to me we'd want some sort of "remapping driver" to create an xinput device which is what we actually use for some joysticks. Note that SDL3 has taken the approach of maintaining a hard-coded list of known joysticks with an xinput-like layout (see http://hg.libsdl.org/SDL/file/127fb2272098/src/joystick/SDL_gamecontrollerdb...), which is simpler and maybe better than providing a general-purpose remapping system for users.
On Thu, Apr 16, 2015 at 08:11:39AM -0500, Aric Stewart wrote:
Now completely unresearched but it may be possible to make a single joystick driver, maybe replacing winejoystick.drv that would build only the platform code that is relevant.
This makes sense to me, and is how dinput already works. Make some sane API for it and build dinput/winmm/xinput on top of that.
but before I do another big chunk of work I am seeking some community buy-in and not just discuss with with Alexandre. I understand if the USB driver path gets actually fleshed out and we try to support Joysticks via that then all this separate driver work would fall away and be replaced.
I may be misunderstanding something, but I think the USB thing is an entirely separate issue, and in the distant future anyway. It doesn't concern me.
We of course need to make sure we come up with a plan that Alexandre will approve of. Would a replacement winejoystick.drv that holds all the platform specific code be acceptable? Is there a case where we would want that driver to be able to build multiple platform code? Maybe Linux and Linux Input? I will admit I am pretty ignorant of the Linux side of this whole situation.
The driver should just provide all backends that are supported by the OS. dinput currently does this, and builds both linux and linuxinput.
We might even be able to drop the non-input Linux path entirely. I'm not sure if anyone still needs it (maybe BSD?). The event interface has been around much longer than ten years, and I think duplicating devices (/dev/jsX == /dev/input/eventY) just causes user and application confusion. I've disabled the non-input Linux driver in some of our game ports, especially those with FFB, and haven't heard any complaints.
Andrew
On Apr 16, 2015, at 9:46 AM, Andrew Eikum aeikum@codeweavers.com wrote:
On Thu, Apr 16, 2015 at 08:11:39AM -0500, Aric Stewart wrote:
Now completely unresearched but it may be possible to make a single joystick driver, maybe replacing winejoystick.drv that would build only the platform code that is relevant.
This makes sense to me, and is how dinput already works. Make some sane API for it and build dinput/winmm/xinput on top of that.
Makes sense to me, too.
-Ken
On 4/16/15 2:12 PM, Ken Thomases wrote:
On Apr 16, 2015, at 9:46 AM, Andrew Eikum aeikum@codeweavers.com wrote:
On Thu, Apr 16, 2015 at 08:11:39AM -0500, Aric Stewart wrote:
Now completely unresearched but it may be possible to make a single joystick driver, maybe replacing winejoystick.drv that would build only the platform code that is relevant.
This makes sense to me, and is how dinput already works. Make some sane API for it and build dinput/winmm/xinput on top of that.
Makes sense to me, too.
-Ken
Thanks to the great leads that Vincent gave me about Raw Input and such I ended up on a path reading about the HID minidrivers and the whole HID class.
I bounced the idea that the Joystick support should be in HID and Alexandre seemed warm to the idea. So I will do work to implement and update our hid.dll to see about putting joystick code in there.
Then, all the other joystick areas can be build off of the HID code. It is already clearly stated in the HID documentation that dinput is a client of the HID code.
The main trick is going to see if all the special functionality (such as forcefeedback or rumble) has a path through HID or not.
-aric
Hi Aric,
Sorry for the late reply, I don't have too much time lately.
HID is the proper abstraction layer for gamepads, any USB or Bluetooth input device uses it. All the input events map to input reports and LED adjustment / force feedback / rumble map to output reports.
It can be a bit of a challenge though to represent all the buttons, axes properly through HID since HID is quite complex. I'm wondering to what extend we need to report the proper device IDs since recreating the exact descriptors as the real device on Windows is nearly impossible. The concern being that various apps are probably stupid enough to just interpret HID report data without parsing the report descriptors if they detect a certain vendor / device ID. On the other hand not using the exact hardware IDs, may result in apps not working (e.g. app not finding an Xbox controller). I'm not sure what is best, so far I would lean to at least reporting the proper device IDs and see how it goes.
Regarding design, I would not look too much about the old Wine joystick code. There are various things it is not doing correctly and some newer'ish features are missing. Some requirements from my end: - Hardware bus layout needs to be provided to WMI and maybe other system information libraries, so stupid apps mixing dinput + xinput can identify x360 devices. - New HID subsystem needs a mechanism to deal with hotplugging and send corresponding WM_DEVICECHANGE event. Various applications especially xinput ones, are not continuously monitoring if there are devices (especially if there were 0 at app startup). For Linux this would probably need a thread dealing with udev / inotify. - HID backend at least for Linux needs some sort of input thread to prevent lost input. Event queue on Linux has a limited size (typically 64 events) and needs to be drained quickly in order not to get SYN_DROPPED events. Some newer devices like DS4 are very sensitive to this, because they have short poll intervals and sensitive axes.
Thanks, Roderick
On Thu, Apr 23, 2015 at 5:03 AM, Aric Stewart aric@codeweavers.com wrote:
On 4/16/15 2:12 PM, Ken Thomases wrote:
On Apr 16, 2015, at 9:46 AM, Andrew Eikum aeikum@codeweavers.com wrote:
On Thu, Apr 16, 2015 at 08:11:39AM -0500, Aric Stewart wrote:
Now completely unresearched but it may be possible to make a single joystick driver, maybe replacing winejoystick.drv that would build only the platform code that is relevant.
This makes sense to me, and is how dinput already works. Make some sane API for it and build dinput/winmm/xinput on top of that.
Makes sense to me, too.
-Ken
Thanks to the great leads that Vincent gave me about Raw Input and such I ended up on a path reading about the HID minidrivers and the whole HID class.
I bounced the idea that the Joystick support should be in HID and Alexandre seemed warm to the idea. So I will do work to implement and update our hid.dll to see about putting joystick code in there.
Then, all the other joystick areas can be build off of the HID code. It is already clearly stated in the HID documentation that dinput is a client of the HID code.
The main trick is going to see if all the special functionality (such as forcefeedback or rumble) has a path through HID or not.
-aric
-
Andrew Eikum -
Aric Stewart -
Henri Verbeet -
Ken Thomases -
Roderick Colenbrander -
Stefan Dösinger -
Vincent Povirk