> 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 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
> 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