My 2c is that this is more of an issue than SDL. Using SDL is probably fine if there are good arguments that support its use and the Wine-internal layering makes sure that xinput_*.dll, dinput and winmm see the same joystick configuration. You could think about calling SDL from winex11.drv or dinput.
I think you missed the point completely here.
Example I posted link for is not if you see/can use device or you don't as device is visible full time. Games use this code to decide which interface they use that way to run, DInput or XInput. And since that code does following - enumerate all DInput visible devices (XInput are exposed there too) ---- for each DInput device check if it is XInput ------ for each passed DInput device parse trough all system devices and when you find it (!!!!!) -------- check if device ID contains "IG_", if it does lets proclaim this XInput compatible
now if any of devices was XInput compatible LoadLibrary ("XInput1_3.dll") and use XInput API, if there was no compatible device then LoadLibrary ("DInput.dll") and use DInput API. This all happens in game, not in Windows or Wine. In wine case, NO compatible device is reported
(!!!!!) - This part is where my question was aiming for, which part of wine creates devices here, so I wouldn't need to hack CoSetProxyBlanket
This part has nothing to do with DInput or XInput. Wine simply doesn't provide XInput compatible device when game parses them with CoSetProxyBlanket setup enumeration
Maybe you missed it before "*If you want your game to support legacy DirectInput http://msdn.microsoft.com/en-us/library/windows/desktop/ee416842(v=vs.85).aspx** devices, you may use DirectInput and XInput side by side. When enumerating your DirectInput devices, all DirectInput devices will enumerate correctly. All XInput devices will show up as both XInput and DirectInput devices, but they should not be handled through DirectInput. You will need to determine which of your DirectInput devices are legacy devices, and which are XInput devices, and remove them from the enumeration of DirectInput devices.*"
From same page
I guess here you mean the X input extension rather than Microsoft's xinput_*.dll, right? I guess XInput works better in remote X11 situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I don't really know how SDL talks to the joystick.)
No, I meant exactly what I said. XInput is terribly deficient API. And as far as remote situations, X11 has way too terrible remote display to be usable for game in 50x50 resolution, way off some normal @Vincent Povirk
From what I could tell, SDL has a game controller api that's very similar to xinput, which is pretty nice, and it can be configured to map to any controller.
It goes further, you can access same device as Joystick and handle axis and buttons manually or you can access it as Gamepad and have instant correct axis/button mapping. Not to mention haptic in XInput is downright terribly deficient (set left/right, ok it works), SDL is downright brilliant on haptic handling
Since I'm not native english speaker, some parts might sound like I would try to persuade in use of SDL. If it does, I sincerely apologize and believe me... I don't, I'm honestly only interested in my question regarding who/where creates devices in CoSetProxyBlanket part
p.s. sorry for double message Stefan, accidentally only sent response to you and not to list
with regards wh1sper_123
On 28 July 2014 20:43, akjsdfk sdkfnskd wh1sper.123.wtfit@gmail.com wrote:
My 2c is that this is more of an issue than SDL. Using SDL is probably fine if there are good arguments that support its use and the Wine-internal layering makes sure that xinput_*.dll, dinput and winmm see the same joystick configuration. You could think about calling SDL from winex11.drv or dinput.
I think you missed the point completely here.
Example I posted link for is not if you see/can use device or you don't as device is visible full time. Games use this code to decide which interface they use that way to run, DInput or XInput. And since that code does following
- enumerate all DInput visible devices (XInput are exposed there too)
---- for each DInput device check if it is XInput ------ for each passed DInput device parse trough all system devices and when you find it (!!!!!) -------- check if device ID contains "IG_", if it does lets proclaim this XInput compatible
now if any of devices was XInput compatible LoadLibrary ("XInput1_3.dll") and use XInput API, if there was no compatible device then LoadLibrary ("DInput.dll") and use DInput API. This all happens in game, not in Windows or Wine. In wine case, NO compatible device is reported
(!!!!!) - This part is where my question was aiming for, which part of wine creates devices here, so I wouldn't need to hack CoSetProxyBlanket
This part has nothing to do with DInput or XInput. Wine simply doesn't provide XInput compatible device when game parses them with CoSetProxyBlanket setup enumeration
Maybe you missed it before "*If you want your game to support legacy DirectInput http://msdn.microsoft.com/en-us/library/windows/desktop/ee416842(v=vs.85).aspx** devices, you may use DirectInput and XInput side by side. When enumerating your DirectInput devices, all DirectInput devices will enumerate correctly. All XInput devices will show up as both XInput and DirectInput devices, but they should not be handled through DirectInput. You will need to determine which of your DirectInput devices are legacy devices, and which are XInput devices, and remove them from the enumeration of DirectInput devices.*" From same page
I guess here you mean the X input extension rather than Microsoft's xinput_*.dll, right? I guess XInput works better in remote X11 situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I don't really know how SDL talks to the joystick.)
No, I meant exactly what I said. XInput is terribly deficient API. And as far as remote situations, X11 has way too terrible remote display to be usable for game in 50x50 resolution, way off some normal @Vincent Povirk
From what I could tell, SDL has a game controller api that's very similar to xinput, which is pretty nice, and it can be configured to map to any controller.
It goes further, you can access same device as Joystick and handle axis and buttons manually or you can access it as Gamepad and have instant correct axis/button mapping. Not to mention haptic in XInput is downright terribly deficient (set left/right, ok it works), SDL is downright brilliant on haptic handling
Since I'm not native english speaker, some parts might sound like I would try to persuade in use of SDL. If it does, I sincerely apologize and believe me... I don't, I'm honestly only interested in my question regarding who/where creates devices in CoSetProxyBlanket part
with regards wh1sper_123
On 28 July 2014 19:50, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-07-26 22:52, schrieb akjsdfk sdkfnskd:
- hotplugging/unplugging (well, only if game didn't use DInput to
scan new devices. if it is pure XInput, then it just works)
My 2c is that this is more of an issue than SDL. Using SDL is probably fine if there are good arguments that support its use and the Wine-internal layering makes sure that xinput_*.dll, dinput and winmm see the same joystick configuration. You could think about calling SDL from winex11.drv or dinput.
- far better API than XInput
I guess here you mean the X input extension rather than Microsoft's xinput_*.dll, right? I guess XInput works better in remote X11 situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I don't really know how SDL talks to the joystick.)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJT1o1zAAoJEN0/YqbEcdMwWiYP/1/hOzt/v6VIp+gDS+cYJF5u 4fRyjT4zoWoFmOUrtApSj1VaBA2DeIaeeT97D0AAvD+FQ0GLaSYcEbn2EqLTcPJO N2IGHeTABdt3IBcD1Ya4AOVAryITaqoR83qmI6KElv/jrdpNDD6BaMemcFDno4Tm pqAYdlZBlFUWP5kEcSp7OsztNWCin0gdQ6BRRnU8nhtBtlOC5qV9VQPW5CQ66SDK +CM+3YkzARMoqmPk1qNu/OnkrubRRuwpHLsCySkfE9WnIDd29tIEAvMThUeZ8ucN OKmdIhs+RSOijrZecj0QDzhNA3fPR+EYx+OFr6h10Y3PxOgdwwAstDoakEhk1x4Y /jQu0XKtP6hDqCtSruxE8Ny3Hpb8p/zsdodHIhmp1W99QdHLbnKVdZJiCYBLToFW AVJ69NPm4Ae92jerN8pesHEl5B7kIGkQepCCpxWUjwPVWEjbB6fEcegGcGN/ccNn EWiBm1+14L5wgPSPCG/DhAfEPtfsig7TLdsL6zIZFLq0/+O6PVmjW9ezjT1PD00U NP7VqmYWY5Is7XtWI6NQ1Vqi5En47uKz+ZaQLPB0ExQB57XrubMo6C6aE53Q4HRg 5Kmh7vTBZecXPZGToT6Eg3z3y1Bc6B9piipxxfRzuqOU6EUzqHO8RzG/LuMrOLG7 kHdS1Q1gRro1FRAFDT3M =gcqc -----END PGP SIGNATURE-----
-
akjsdfk sdkfnskd