Hi, all.
In order to add HID joystick support to FreeBSD I need to do some changes I never did before so I could use some help. I tried to understand the changes made by Ken in order to add the winmm OSX driver but I don't get it =)
In simple words I need to ensure that usbhid.h and dev/usb/usbhid.h exist and only if they exist compile the winejoystick driver. I believe it's a change in configure.ac but I tried adding these .h files to the long list of other .h files and it didn't work.
Also I guess a similar change is needed like Ken did to enable the driver building:
-test "$ac_cv_header_linux_joystick_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no}
+test "$ac_cv_header_linux_joystick_h" = "yes" -o "$ac_cv_header_IOKit_hid_IOHIDLib_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no}
Can anyone help?
Best wishes and thanks in advance, Bruno
Hi,
On Mar 21, 2015, at 1:06 PM, Bruno Jesus 00cpxxx@gmail.com wrote:
In order to add HID joystick support to FreeBSD I need to do some changes I never did before so I could use some help. I tried to understand the changes made by Ken in order to add the winmm OSX driver but I don't get it =)
In simple words I need to ensure that usbhid.h and dev/usb/usbhid.h exist and only if they exist compile the winejoystick driver. I believe it's a change in configure.ac but I tried adding these .h files to the long list of other .h files and it didn't work.
Yes, you need to add the headers to the long list, similar to IOKit/hid/IOHIDLib.h (as used by the Mac code) and linux/joystick.h (for Linux). That causes configure to check for the existence of those headers. If they exist, configure will set the corresponding ac_cv_header_… variable. The name of the variable will be ac_cv_header_ concatenated with the name of the header file with slashes and periods replaced by underscores.
Also I guess a similar change is needed like Ken did to enable the driver building:
-test "$ac_cv_header_linux_joystick_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no}
+test "$ac_cv_header_linux_joystick_h" = "yes" -o "$ac_cv_header_IOKit_hid_IOHIDLib_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no}
Right. That line is a bit complex. The short version is that you would add another "-o" followed by a check for the new ac_cv_header_… variable being equal to "yes".
The test command is checking if the configure variable indicating the presence of either of those headers is equal to "yes". If either is, then the "test" command succeeds (exits with status 0, which means true). The test command is followed by the shell's OR operator ("||"). If either operand of the OR is true, then the whole expression is true. Therefore, once the test command has succeeded, there's no need to run the other command and the shell does not. The effect is to only run the second command if the test fails.
The second command sets the enable_winejoystick_drv variable to "no" if it has not previously been set. It's only determining the default value. If the user specified --enable-winejoystick-drv on the command line, that overrides this logic. (Actually, it is overridden if the user specified any of --enable-winejoystick-drv, --disable-winejoystick-drv, or --enable-winejoystick-drv=anything.)
Later in configure.ac, WINE_CONFIG_DLL(winejoystick.drv) informs configure about the existence the dlls/winejoystick.drv directory and to treat it like other DLL directories. It uses the enable_winejoystick_drv variable to decide whether to build it.
Anyway, once you make the changes to configure.ac, you need to generate configure from that by running autoconf. You'd then need to run the configure script as normal. I think a "make" should then be sufficient. It's possible you will need to force a rebuild of Makefile at the top level (rm Makefile ; make Makefile), but I think that should be automatic.
If it's not working for you, what's going wrong?
One final point: my recent changes added Mac joystick support to WinMM. This is used by older games. More modern games use DInput, which has separate joystick support code. So, you may need to add support there, too, depending on what game you're trying to get working.
-Ken
On Sat, Mar 21, 2015 at 4:31 PM, Ken Thomases ken@codeweavers.com wrote:
Hi,
On Mar 21, 2015, at 1:06 PM, Bruno Jesus 00cpxxx@gmail.com wrote:
In order to add HID joystick support to FreeBSD I need to do some changes I never did before so I could use some help. I tried to understand the changes made by Ken in order to add the winmm OSX driver but I don't get it =)
In simple words I need to ensure that usbhid.h and dev/usb/usbhid.h exist and only if they exist compile the winejoystick driver. I believe it's a change in configure.ac but I tried adding these .h files to the long list of other .h files and it didn't work.
Yes, you need to add the headers to the long list, similar to IOKit/hid/IOHIDLib.h (as used by the Mac code) and linux/joystick.h (for Linux). That causes configure to check for the existence of those headers. If they exist, configure will set the corresponding ac_cv_header_… variable. The name of the variable will be ac_cv_header_ concatenated with the name of the header file with slashes and periods replaced by underscores.
Also I guess a similar change is needed like Ken did to enable the driver building:
-test "$ac_cv_header_linux_joystick_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no}
+test "$ac_cv_header_linux_joystick_h" = "yes" -o "$ac_cv_header_IOKit_hid_IOHIDLib_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no}
Right. That line is a bit complex. The short version is that you would add another "-o" followed by a check for the new ac_cv_header_… variable being equal to "yes".
The test command is checking if the configure variable indicating the presence of either of those headers is equal to "yes". If either is, then the "test" command succeeds (exits with status 0, which means true). The test command is followed by the shell's OR operator ("||"). If either operand of the OR is true, then the whole expression is true. Therefore, once the test command has succeeded, there's no need to run the other command and the shell does not. The effect is to only run the second command if the test fails.
The second command sets the enable_winejoystick_drv variable to "no" if it has not previously been set. It's only determining the default value. If the user specified --enable-winejoystick-drv on the command line, that overrides this logic. (Actually, it is overridden if the user specified any of --enable-winejoystick-drv, --disable-winejoystick-drv, or --enable-winejoystick-drv=anything.)
Later in configure.ac, WINE_CONFIG_DLL(winejoystick.drv) informs configure about the existence the dlls/winejoystick.drv directory and to treat it like other DLL directories. It uses the enable_winejoystick_drv variable to decide whether to build it.
Anyway, once you make the changes to configure.ac, you need to generate configure from that by running autoconf. You'd then need to run the configure script as normal. I think a "make" should then be sufficient. It's possible you will need to force a rebuild of Makefile at the top level (rm Makefile ; make Makefile), but I think that should be automatic.
If it's not working for you, what's going wrong?
One final point: my recent changes added Mac joystick support to WinMM. This is used by older games. More modern games use DInput, which has separate joystick support code. So, you may need to add support there, too, depending on what game you're trying to get working.
Thank you very much for all information, I'll try and report back if I find any problems. I'm working in winmm because it's an easier starter point.
-Ken
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-03-21 um 20:58 schrieb Bruno Jesus:
Thank you very much for all information, I'll try and report back if I find any problems. I'm working in winmm because it's an easier starter point.
Wouldn't it make sense to have a shared joystick library that winmm, dinput and (later on xinput) talk to rather than have different OS abstraction layers in winmm and dinput?
On Sun, Mar 22, 2015 at 10:12 AM, Stefan Dösinger stefandoesinger@gmail.com wrote:
Am 2015-03-21 um 20:58 schrieb Bruno Jesus:
Thank you very much for all information, I'll try and report back if I find any problems. I'm working in winmm because it's an easier starter point.
Wouldn't it make sense to have a shared joystick library that winmm, dinput and (later on xinput) talk to rather than have different OS abstraction layers in winmm and dinput?
Hi, Stefan. I'm just perpetuating the current standards, doing what you are asking would require someone more experienced with such things.
On 22/03/15 14:12, Stefan Dösinger wrote:
Wouldn't it make sense to have a shared joystick library that winmm, dinput and (later on xinput) talk to rather than have different OS abstraction layers in winmm and dinput?
Here's a thread about that from a long time ago with some ideas and concerns about that: http://wine.1045685.n5.nabble.com/josystick-driver-layer-and-support-of-mult...
Jonas
On Mar 22, 2015, at 7:12 AM, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-03-21 um 20:58 schrieb Bruno Jesus:
Thank you very much for all information, I'll try and report back if I find any problems. I'm working in winmm because it's an easier starter point.
Wouldn't it make sense to have a shared joystick library that winmm, dinput and (later on xinput) talk to rather than have different OS abstraction layers in winmm and dinput?
I agree. In fact, what I think we should do is implement the HID ioctls in ntdll, and perhaps even hid.dll on top of that. Then all the input-related stuff would just make HID ioctl calls to ntdll.
But even if we don’t wind up doing that, I definitely think that having a common library handling input devices is a good idea.
Chip
On Sun, Mar 22, 2015 at 4:26 PM, Charles Davis cdavis5x@gmail.com wrote:
On Mar 22, 2015, at 7:12 AM, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-03-21 um 20:58 schrieb Bruno Jesus:
Thank you very much for all information, I'll try and report back if I find any problems. I'm working in winmm because it's an easier starter point.
Wouldn't it make sense to have a shared joystick library that winmm, dinput and (later on xinput) talk to rather than have different OS abstraction layers in winmm and dinput?
I agree. In fact, what I think we should do is implement the HID ioctls in ntdll, and perhaps even hid.dll on top of that. Then all the input-related stuff would just make HID ioctl calls to ntdll.
But even if we don’t wind up doing that, I definitely think that having a common library handling input devices is a good idea.
Chip
Recently I had a look at this area as well due to some xinput work I did recently, but it again adder per platform backends. In addition xinput has some nasty behaviour, which really requires dinput and xinput to have a common base. In a nutshell xinput is all about polling 'XInputGetState(device_index, ..)' and there is no method defined by xinput of enumerating a device except for checking if 'XInputGetState' returns an error. Microsoft at the time recommended to do enumeration using dinput and then mix the dinput enumeration code with some fun WMI calls to check if a device is xinput capable. To do this well dinput, xinput and even WMI need to have a similar view of input devices.
Initially I was looking at win32 raw input, because you can also use raw input for gamepads (yep, this is a 4th method in addition to winmm, dinput and xinput). It felt quite suitable and it also handles device notification (for gamepad devices you want WM_DEVICE_CHANGED notifications for hotplug notifications). The only thing it was lacking was some sort of 'SetRawInputData'-like call, which you would need for sending force feedback / rumble data to a HID device. This disqualified it for me, but it was really close.
It felt like the raw input API was a thin layer on top of HID anyway, since a lot of posts refer to HID APIs if you want to understand what is inside your data blobs. Ultimately it felt that implementing hid.dll would probably the way to go. The API is not very hard, but it is all quite low level and we would layer it on top of a higher level APIs like Linux evdev, which again feels like translating D3D bytecode back to GLSL or worse. Doing this would be quite a big undertaking and I'm not sure how easy it is to get right, especially debugging raw HID packets is no joy.
Roderick
-
Bruno Jesus -
Charles Davis -
Jonas Maebe -
Ken Thomases -
Roderick Colenbrander -
Stefan Dösinger