FakeInput Driver breaks macros

[Filoppi]

Describe the bug When using DS4Windows with the "FakeInput Driver" installed, some "Special Actions" macros don't work.

To Reproduce Steps to reproduce the behavior:

1. Add a special action like this one (to take a screenshot through the xbox game bar): . Save the profile.
2. Try to trigger the special action with the PS button, it works once and then never again

Expected behavior The PS button takes a screenshot every single time.

Desktop (please complete the following information):

• Controller Make and Model: DualSense
• OS: Win11 22H2
• DS4Windows 3.1.12

Additional context Uninstalling the "FakeInput Driver" allows the special actions macros to work more than once, so I won't use it for the moment.

[Kanuan]

Your Macro runs so fast that windows is not even registering it is happening.

Insert A SINGLE 100ms wait time between the group of "down/pressed" events and the group of "Up/released"

[Filoppi]

That might be the reason. I'm just saying that using the FakeInput Drives can actually be worse than not using it, which I thought was worth reporting. I don't want any delay in there as I want Screenshots to be as immediate as possible.

[Kanuan]

I might be wrong on what I'm about to say, but the macro not working without delay might be windows interpreting that it's a false positive since it would be humanly impossible for the keyboard input to happen so fast.

It might work with send input because its just slower on itself.

Again, I might be wrong on this though. You may also re-record the MACRO with the the "•record delays" option enabled to compare the real wait times when you execute the key combo by hand

[Filoppi]

I highly doubt Windows would check the delay between input "events" and reject them if they are not "human like", that makes no sense. Maybe there is a limitation in some event queue, or maybe it's a bug with the FakeInput driver, but it's likely not what you are saying.

I know I can re-record the macro with delays, that's not the point. Clearly the problem here is that it only works once, so something gets stuck somewhere, and that's what I'm reporting.

[Masamune3210]

Message queue processing is up to the app entirely, so the acceptable input speed differs between apps, sometimes drastically. Inserting wait states is almost required due to macros processing so fast without them, It is very easy to get weird behavior without them due to the app not pumping messages fast enough to keep up with the queue and things either getting lost or missed