XInput over SDL

[akjsdfk sdkfnskd]

> 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 at 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 at 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-----
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140728/a245618b/attachment-0001.html>