Trying to troubleshoot a problem with my game related to 360
controllers, but before I do anything I want to make sure I’m not
misunderstanding how a function works (the bug could very well be I’m
passing the wrong parameter and that cascades later!).
SDL_GameControllerOpen takes a joystick index as an argument. What
value is this index, the one from event.jdevice.which (in a
SDL_JOYDEVICEADDED event) or the one returned by
SDL_JoystickInstanceID?
it takes the index from the event
SDL_JoystickInstanceID can only be called if you already opened the
joystick since it takes an instance of SDL_Joystick
The Joystick API and Controller API are completely independent (afaik)
and kind of redundant (controllers abstract away the actual button/axis
mapping)Am 05.08.2014 09:12, schrieb Sik the hedgehog:
Trying to troubleshoot a problem with my game related to 360
controllers, but before I do anything I want to make sure I’m not
misunderstanding how a function works (the bug could very well be I’m
passing the wrong parameter and that cascades later!).SDL_GameControllerOpen takes a joystick index as an argument. What
value is this index, the one from event.jdevice.which (in a
SDL_JOYDEVICEADDED event) or the one returned by
SDL_JoystickInstanceID?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2014-08-05 6:56 GMT-03:00, Robotic-Brain :
it takes the index from the event
Ugh, my issue is something else then.
SDL_JoystickInstanceID can only be called if you already opened the
joystick since it takes an instance of SDL_Joystick
Yep, doing that already, opening both in fact.
The Joystick API and Controller API are completely independent (afaik)
and kind of redundant (controllers abstract away the actual button/axis
mapping)
Not all controllers have mappings programmed, and it won’t help you if
you want to support controllers with a non-standard layout.
Probably would have been much better if it was all a single API though 
Not all controllers have mappings programmed, and it won’t help you if
you want to support controllers with a non-standard layout.
There are functions in place to load custom mappings. The only way to
generate those as of now is using steam though…
(see http://wiki.libsdl.org/SDL_GameControllerAddMapping if you want to
generate them yourself)Am 05.08.2014 15:00, schrieb Sik the hedgehog:
That still isn’t enough because the player won’t like it if the
controller doesn’t work, the player won’t care if it’s because some
database doesn’t feature that controller. A fallback is still
required. Also there’s still the issue of non-standard layouts (the
most obvious ones here would be retro-styled controllers).
Anyway, debugging this. It seems that the game isn’t detecting the 360
controller as having mappings at all (which is kind of ironic, given
those controllers are the whole point of having the API in the first
place). Does SDL2 come with a default database or is it just assumed
Steam will provide it always?
For the record: when I try to retrieve the GUID of the joystick I get
00000000-00000000-00000000-00000000, which definitely doesn’t seem to
be valid. The name is “XInput Controller #1” though, which seems to
imply SDL2 detected it as a 360 controller. Huh?
2014-08-06 15:38 GMT-03:00, Robotic-Brain :>
Am 05.08.2014 15:00, schrieb Sik the hedgehog:
Not all controllers have mappings programmed, and it won’t help you if
you want to support controllers with a non-standard layout.There are functions in place to load custom mappings. The only way to
generate those as of now is using steam though…
(see http://wiki.libsdl.org/SDL_GameControllerAddMapping if you want to
generate them yourself)
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I wonder if SDL is operating in XInput mode here. Sounds like it isn?t. ALL XInput controllers have the same mapping since the whole point of the API is to give ?standard? controllers the same mappings as XInput.
If you?re building SDL using some flavor of mingw, it?s very easy to have a build that does not support DirectX/XInput properly.
Joseph> On Aug 6, 2014, at 12:04, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
That still isn’t enough because the player won’t like it if the
controller doesn’t work, the player won’t care if it’s because some
database doesn’t feature that controller. A fallback is still
required. Also there’s still the issue of non-standard layouts (the
most obvious ones here would be retro-styled controllers).Anyway, debugging this. It seems that the game isn’t detecting the 360
controller as having mappings at all (which is kind of ironic, given
those controllers are the whole point of having the API in the first
place). Does SDL2 come with a default database or is it just assumed
Steam will provide it always?For the record: when I try to retrieve the GUID of the joystick I get
00000000-00000000-00000000-00000000, which definitely doesn’t seem to
be valid. The name is “XInput Controller #1” though, which seems to
imply SDL2 detected it as a 360 controller. Huh?
That still isn’t enough because the player won’t like it if the
controller doesn’t work, the player won’t care if it’s because some
database doesn’t feature that controller. A fallback is still
required. Also there’s still the issue of non-standard layouts (the
most obvious ones here would be retro-styled controllers).
If the player wants to use a “non standard” controller, he should expect
to configure the mapping himself.
(maybe a standardized tool would be nice though so you’re not depending
on the one from steam or on the user compiling anything)
Anyway, debugging this. It seems that the game isn’t detecting the 360
controller as having mappings at all (which is kind of ironic, given
those controllers are the whole point of having the API in the first
place). Does SDL2 come with a default database or is it just assumed
Steam will provide it always?
see here:
I’m not sure what your GUID means though…
shouldn’t a XInput device show up as a “xinput” GUID?
Unless you retrieve the GUID in a strange way, there seems to be
something wrong with your setupAm 06.08.2014 21:04, schrieb Sik the hedgehog:
If you?re creating a game you can have a menu to configure the gamepad mapping - it?s pretty trivial to construct the mapping string programmatically.On Aug 6, 2014, at 4:33 PM, Robotic-Brain wrote:
Am 06.08.2014 21:04, schrieb Sik the hedgehog:
That still isn’t enough because the player won’t like it if the
controller doesn’t work, the player won’t care if it’s because some
database doesn’t feature that controller. A fallback is still
required. Also there’s still the issue of non-standard layouts (the
most obvious ones here would be retro-styled controllers).If the player wants to use a “non standard” controller, he should expect to configure the mapping himself.
(maybe a standardized tool would be nice though so you’re not depending on the one from steam or on the user compiling anything)
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I know but most people don’t even bother about providing a way to
configure the music/sfx volumeAm 06.08.2014 21:38, schrieb Alex Szpakowski:
If you?re creating a game you can have a menu to configure the gamepad
mapping - it?s pretty trivial to construct the mapping string
programmatically.
2014-08-06 16:28 GMT-03:00, T. Joseph Carter :
I wonder if SDL is operating in XInput mode here. Sounds like it isn?t.
ALL XInput controllers have the same mapping since the whole point of the
API is to give ?standard? controllers the same mappings as XInput.
I was wondering about that too, but I don’t know how can I check it to
make sure.
If you?re building SDL using some flavor of mingw, it?s very easy to have a
build that does not support DirectX/XInput properly.
MinGW-w64, yeah, but in theory XInput should work with that one (on
vanilla MinGW it definitely won’t work though, its XInput support is
incomplete). I did see the XInput files in MinGW-w64’s install, so
unless something went wrong with the configure I don’t see why it
wouldn’t work.
2014-08-06 16:38 GMT-03:00, Alex Szpakowski :
If you?re creating a game you can have a menu to configure the gamepad
mapping - it?s pretty trivial to construct the mapping string
programmatically.
2014-08-06 16:33 GMT-03:00, Robotic-Brain :
If the player wants to use a “non standard” controller, he should expect
to configure the mapping himself.
(maybe a standardized tool would be nice though so you’re not depending
on the one from steam or on the user compiling anything)
Now that’s just plain bad UX, the player should not have to know at
all about SDL’s internals (generating the mapping for the database
implies explaining that SDL needs it). And all “non-standard”
controllers have similar mappings (and they’re the standard ones
actually, the 360 ones are the ones that deviate heavily), so I see no
reason why I can’t just rely on that if I can’t get a proper mapping.
And this still won’t help you with stuff like this (yes, this is an
USB controller):
http://a.tgcdn.net/images/products/additional/large/1b4c_classic_console_usb_controllers_genesis.jpg
OK, so it seems to be included by default. Any way I can retrieve the
entire list to make sure? Through reading a hint? (there’s
SDL_GameControllerMapping but that’s for a controller that’s already
opened)
I’m not sure what your GUID means though…
shouldn’t a XInput device show up as a “xinput” GUID?
Unless you retrieve the GUID in a strange way, there seems to be
something wrong with your setup
Since when is it bad UX to provide input configuration options ingame? You aren?t exposing SDL?s internals, you?re letting the user change their gamepad?s layout for your game without having to use an external tool.
Different controllers do not have similar joystick mappings, especially between operating systems. You will not have happy customers if you rely on that…On Aug 6, 2014, at 5:10 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
2014-08-06 16:38 GMT-03:00, Alex Szpakowski <@Alex_Szpakowski>:
If you?re creating a game you can have a menu to configure the gamepad
mapping - it?s pretty trivial to construct the mapping string
programmatically.Now that’s just plain bad UX, the player should not have to know at
all about SDL’s internals (generating the mapping for the database
implies explaining that SDL needs it). And all “non-standard”
controllers have similar mappings (and they’re the standard ones
actually, the 360 ones are the ones that deviate heavily), so I see no
reason why I can’t just rely on that if I can’t get a proper mapping.SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2014-08-06 17:14 GMT-03:00, Alex Szpakowski :
Since when is it bad UX to provide input configuration options ingame? You
aren?t exposing SDL?s internals, you?re letting the user change their
gamepad?s layout for your game without having to use an external tool.
It’s bad UX to force the player to go through configuration before
being even able to start using the thing (of course you can change
the mappings later). Nobody wants to do that, you’re expected to
provide reasonable defaults that most people won’t bother changing.
And yes, it affects the ability to start the game, because menus get
affected by this (in fact the whole reason I’m doing this is because
I’m getting complaints that the accept/cancel buttons got mapped to
the D-pad by default).
Different controllers do not have similar joystick mappings, especially
between operating systems. You will not have happy customers if you rely on
that…
I have tried several joysticks and in my experience it is the case -
face buttons mapping to buttons 0 to 3, D-pad mapping to hat 0, left
stick mapping to axes 0 and 1. Ultimately details vary (e.g. buttons 1
and 3 tend to get swapped) but it’s still relatively sane.
By contrast, 360 controller is D-pad mapped to buttons 0 to 3 and face
buttons to buttons 4 to 7. That’s completely different from what other
controllers do. Ugh.
It’s bad UX to force the player to go through configuration before
being even able to start using the thing (of course you can change
the mappings later). Nobody wants to do that, you’re expected to
provide reasonable defaults that most people won’t bother changing.
In fact I think it’s bad design, not to…
The first thing I always do If I launch a new game is jump to the input
configuration.
Traditionally you can’t assume anything about the input mappings:
“Has the user a qwerty- or qwertz-keyboard? Maybe even dvorak?!”
“Is he right or left handed?” (is he a “he” at all?)
this is even more severe with joysticks and gamepads since there are no
common standards.
The best thing you can do is rely on “wasd” (not even arrow keys since
some laptops don’t have them) and Space or Enter and the mouse to
navigate the menu. Then If you detect a (new) gamepad, ask the user to
go trough some confirmation routine like “press D-pad Up” if the
received event does not correspond to the expected one, your mapping is
wrong → immediately start the configuration routine (maybe this is why
most games ask you to “press start”)
If you really want a bulletproof mapping, you’ll have to hardcode every
single device down to the USB-Serial-number. That’s simply not feasible.
And even that does not take into account If the user want’s to switch
some buttons (he might be left-handed).
Back to topic…
What exactly is the problem?
Does it not recognize the device at all or is just the mapping off?
I managed to make an Arduino board work with SDL, so it seems to be able
to handle any HID Device if you provide the right mappings.Am 06.08.2014 22:19, schrieb Sik the hedgehog:
2014-08-06 17:56 GMT-03:00, Robotic-Brain :
In fact I think it’s bad design, not to…
The first thing I always do If I launch a new game is jump to the input
configuration.
Traditionally you can’t assume anything about the input mappings:
“Has the user a qwerty- or qwertz-keyboard? Maybe even dvorak?!”
“Is he right or left handed?” (is he a “he” at all?)
Most players will prefer going into the game directly though.
Also I’m not talking about the in-game controls, I’m talking about the
mappings of the buttons. I can’t even provide any support for
controllers in menus if I can’t tell which input is which. THIS is
the issue I’m having.
(also, if your game relies on the keyboard layout you seriously should
reconsider how you’re handling keyboard input, there’s a reason you
can use scancodes instead)
If you really want a bulletproof mapping, you’ll have to hardcode every
single device down to the USB-Serial-number. That’s simply not feasible.
Ironically, this is exactly what SDL is attempting to do with its database!
And even that does not take into account If the user want’s to switch
some buttons (he might be left-handed).
Again, you’re assuming I’m talking about the in-game controls and not
the mappings of the buttons of the controller.
Back to topic…
What exactly is the problem?
Does it not recognize the device at all or is just the mapping off?
The joystick opens just fine, but the mappings are not detected at all
(forcing me to guess some sane defaults, which usually works
reasonably fine except with 360 controllers). In fact SDL doesn’t seem
to even be able to retrieve its GUID, which is odd (probably not being
able to retrieve the GUID is what’s causing the mapping to not get
retrieved).
tl;dr game controller API can’t detect the 360 controller as such.
(also, if your game relies on the keyboard layout you seriously should
reconsider how you’re handling keyboard input, there’s a reason you
can use scancodes instead)
scan codes are even worse since they are not standardized either…
the reason you use the mapping is because most people have a qwert(y/z)
keyboard.
The best approach imho is to use the key mapping as a sane default and
use the scan codes for user defined configs.
Ironically, this is exactly what SDL is attempting to do with its
database!
That’s why it breaks so easily 
Even different device versions can throw the ID off by just one bit.
With new devices coming every day it’s simply not possible to support
unknown devices in a standardized way
And even that does not take into account If the user want’s to switch
some buttons (he might be left-handed).Again, you’re assuming I’m talking about the in-game controls and not
the mappings of the buttons of the controller.
No… even in the menu the user might want to flip up/down for whatever
reason
(it might be more comfortable that way)
The joystick opens just fine, but the mappings are not detected at all
(forcing me to guess some sane defaults, which usually works
reasonably fine except with 360 controllers).
Don’t just assume some mappings!
If the device has no mappings associated, ask the user to provide some!
(maybe even ask to send them to you, so you can add them to SDL itself)
Steam for example will just ignore the device until you configured it.
In fact SDL doesn’t seem
to even be able to retrieve its GUID, which is odd (probably not being
able to retrieve the GUID is what’s causing the mapping to not get
retrieved).
That might be the real problem here…
How do you retrieve the GUID?
The example code you gave doesn’t paint the whole picture…Am 06.08.2014 23:36, schrieb Sik the hedgehog:
2014-08-06 18:59 GMT-03:00, Robotic-Brain :
scan codes are even worse since they are not standardized either…
the reason you use the mapping is because most people have a qwert(y/z)
keyboard.
Map WSAD using key codes on an AZERTY or Dvorak keyboard and see how
it pans out. Use scan codes when you need to rely on the key place,
use key code when you need to rely on which key it is. It’s the
closest to best you can get.
That’s why it breaks so easily
Even different device versions can throw the ID off by just one bit.
With new devices coming every day it’s simply not possible to support
unknown devices in a standardized way
Not to mention different joysticks with the same GUID (which tends to
happen with cheap joysticks). What should I do, completely ignore
joysticks that are not in the database since I can’t be sure they can
be mapped at all (even if they’re provided)? Or outright ditch the
game controller API and require mappings of just about everything? (if
so, why is that API even in SDL for starters?)
Also what happens when I can’t even detect if the controller is
different, e.g. the GUID can’t be retrieved, or two joysticks happen
to share the same GUID for whatever reason?
Don’t just assume some mappings!
If the device has no mappings associated, ask the user to provide some!
(maybe even ask to send them to you, so you can add them to SDL itself)
Steam for example will just ignore the device until you configured it.
Congrats, now I have to tell the user about the workings of some
library that they shouldn’t even be aware of! Especially when talking
about a controller that practically every game should know about
(which is the issue here, with other controllers the player most
likely already knows what’s up anyway).
And you’re still assuming that the controller uses the same layout
as the 360 one. I can’t tell the player to provide new mappings if
they can’t even be entered into the database!> That might be the real problem here…
How do you retrieve the GUID?
The example code you gave doesn’t paint the whole picture…
// Open joystick
joysticks[id].joystick = SDL_JoystickOpen(index);
if (joysticks[id].joystick == NULL) {
num_joysticks–;
return;
}
“index” being the which field of the joystick added event. The GUID
gets printed, so the joystick is obviously getting opened (otherwise
the code wouldn’t get there for starters). I really don’t think
there’s much to it, open the joystick and immediately retrieve the
GUID.
Wait, gah, it probably should be SDL_JoystickGetDeviceGUID instead of
SDL_JoystickGetGUID… and the guy who was testing just went to sleep
-.-’ (so I can’t test until tomorrow) Fun stuff.
Will see tomorrow what’s up, but if anybody has any ideas as to why it
may not be working, do tell (in particular, if anybody knows how to
check if XInput is being used, say so).
Map WSAD using key codes on an AZERTY or Dvorak keyboard and see how
it pans out. Use scan codes when you need to rely on the key place,
use key code when you need to rely on which key it is. It’s the
closest to best you can get.
Since scan codes aren’t standardized in any way this only works if you
got the scan code from the user initially.
Switching between azerty or qwerty can be done on the system language
Input handling still is a messy issue however you put it…
What should I do, completely ignore
joysticks that are not in the database since I can’t be sure they can
be mapped at all (even if they’re provided)? Or outright ditch the
game controller API and require mappings of just about everything? (if
so, why is that API even in SDL for starters?)
The API tries to simplify remapping exactly because it’s a big mess!
Additionally it provides some common mappings but it’s not perfect at
all.
It’s not supposed to work “automagically”.
So your only bet is, hope the device is supported, if not, tell the user
about it, and ask for a mapping.
Also what happens when I can’t even detect if the controller is
different, e.g. the GUID can’t be retrieved, or two joysticks happen
to share the same GUID for whatever reason?
Then your mapping becomes invalid when you unplug the device.
The best thing in this case would be to give the user the option to save
multiple mappings, and choose the right one for any given device.
Congrats, now I have to tell the user about the workings of some
library that they shouldn’t even be aware of! Especially when talking
about a controller that practically every game should know about
(which is the issue here, with other controllers the player most
likely already knows what’s up anyway).
Why has the user to know about some library?
Just display a message: “Your controller could not be detected
automatically! Please follow the instructions to configure it.”
When they’re done you can ask if they want to publish the mapping so
others can use it.
This can be done in a matter of seconds
Steam has a good example wizard. The comment here explains where to find
it:
And you’re still assuming that the controller uses the same layout
as the 360 one. I can’t tell the player to provide new mappings if
they can’t even be entered into the database!
look for SDL_GameControllerAddMapping and friends.
Ideally you would build the mapping string with a wizard, save it to a
file, and load it on startup.
Wait, gah, it probably should be SDL_JoystickGetDeviceGUID instead of
SDL_JoystickGetGUID… and the guy who was testing just went to sleep
-.-’ (so I can’t test until tomorrow) Fun stuff.
what now, SDL_JoystickGetDeviceGUID or SDL_JoystickGetGUID?
one uses the Joystick instance, the other the index from the event. Make
sure not to confuse them!
The sample code seems to be correct though.
Also, you know about SDL_JoystickGetGUIDString right?Am 07.08.2014 00:12, schrieb Sik the hedgehog:
2014-08-06 20:26 GMT-03:00, Robotic-Brain :
Since scan codes aren’t standardized in any way this only works if you
got the scan code from the user initially.
OK, I really want to know from where do you get the idea that
scancodes are not standarized, because they definitely are (there are
some ancient scancode sets from like two decades ago, but even in the
rare case you have those the operating system will remap them to the
newer scancodes).
And SDL has its own set of scancodes, so in theory if some system
decides to use a completely different set SDL can just remap them to
what they’re usually. Scancodes should be considered safe.
The API tries to simplify remapping exactly because it’s a big mess!
Additionally it provides some common mappings but it’s not perfect at
all.
It’s not supposed to work “automagically”.So your only bet is, hope the device is supported, if not, tell the user
about it, and ask for a mapping.
Yeah but you’re telling me to do it even if the mapping is known
because, you know, maybe the user wants to change them! So what’s the
point of the API if I should just disregard it anyway?
look for SDL_GameControllerAddMapping and friends.
Ideally you would build the mapping string with a wizard, save it to a
file, and load it on startup.
OK, let’s put the example of the six button controller I mentioned
earlier. It lacks a lot of inputs, so I assume they could be just
ignored. But it also adds two new inputs (two face buttons). To what
should they be mapped? Because mapping them to some of the missing
inputs probably wouldn’t make much sense. And even then, the other
four face buttons don’t really follow the expected layout anyway, how
do you arrange what would be ABXY?
And don’t tell me it’s an unusual case. I kept looking for my other
testers to see if I could find somebody else with a 360 controller.
Practically nobody does. Several of them had controllers that had
nothing to do with the 360 layout, though. Yeah, I also found it
surprising, but I guess this means controllers with unusual layouts
are more common than one would think.
what now, SDL_JoystickGetDeviceGUID or SDL_JoystickGetGUID?
one uses the Joystick instance, the other the index from the event. Make
sure not to confuse them!
Yeah, I noticed that later, but I wasn’t going to send three
consecutive e-mails 
Also, you know about SDL_JoystickGetGUIDString right?
Noticed about it later, I don’t remember why I didn’t use it :S The
printing code seems to work though, unless there’s something
non-obvious.
Also for the record, I decided to try it with the other controllers
the other testers have - it does show a correct GUID in those cases.
In other words, it seems SDL can actually retrieve the GUID of the
controllers. This makes things weirder though, because the way SDL
decides to switch to XInput is through the GUID, so that means it
should be able to retrieve the GUID of a 360 controller even if XInput
isn’t working.
…unless XInput is indeed working and showing an invalid GUID turns
out to be an accidental side-effect. I do remember that if SDL finds
the 360 GUID it will stop the current initialization code and go with
the XInput code instead.
OK, I really want to know from where do you get the idea that
scancodes are not standarized, because they definitely are (there are
some ancient scancode sets from like two decades ago, but even in the
rare case you have those the operating system will remap them to the
newer scancodes).And SDL has its own set of scancodes, so in theory if some system
decides to use a completely different set SDL can just remap them to
what they’re usually. Scancodes should be considered safe.
Maybe my knowledge there is a bit outdated (I’ve been digging too much
trough the X protocol, which maintains a lot of the old stuff for
compatibility)
Yeah but you’re telling me to do it even if the mapping is known
because, you know, maybe the user wants to change them! So what’s the
point of the API if I should just disregard it anyway?
The point of the API is to provide a layer of abstraction to the raw
events so you can simply remap them!
The fact that it recognizes some “standard” devices is only an extra bit
of sugar - not the whole purpose
OK, let’s put the example of the six button controller I mentioned
earlier. It lacks a lot of inputs, so I assume they could be just
ignored. But it also adds two new inputs (two face buttons). To what
should they be mapped? Because mapping them to some of the missing
inputs probably wouldn’t make much sense. And even then, the other
four face buttons don’t really follow the expected layout anyway, how
do you arrange what would be ABXY?
Let the user decide!
Steam tries to approximate the 360 mappings so it works with a lot of
games, but you have the advantage of being as game specific as you’d
like.
So instead of asking the user to “Push A” you can ask him to “Push
‘Jump’”
You’ll get some trouble if the controller doesn’t support enough buttons
or axes, but that is quite literally the worst case.
And don’t tell me it’s an unusual case. I kept looking for my other
testers to see if I could find somebody else with a 360 controller.
Practically nobody does. Several of them had controllers that had
nothing to do with the 360 layout, though. Yeah, I also found it
surprising, but I guess this means controllers with unusual layouts
are more common than one would think.
I don’t find it surprising at all…
In fact I also have/had some cheap no-name controller
The branded ones from Microsoft are simply too expensive and I like the
playstation layout better anyways
Noticed about it later, I don’t remember why I didn’t use it :S The
printing code seems to work though, unless there’s something
non-obvious.
Well you’re breaking the opacity of SDL_JoystickGUID with your code
hm… maybe that’s your issue?
The GUID of a XInput device seems to be “xinput” but your code expects
some raw numerical data
Do you violate the opacity somewhere else?
Maybe the presence of a XInput device causes some malicious buffer
overflow or other non deterministic havoc