Discover the new reWASD generation: reWASD 9.3 and reWASD Basic

[thejoe]

reWASD 9.3 brings a set of changes we’ve been building toward for quite some time. This update focuses on expanding the core platform, improving how reWASD works with external devices, and opening new directions for advanced and accessibility-oriented setups.

One of the key additions in reWASD 9.3 is Send Input - a new Advanced (and currently experimental) feature. Send Input expands how reWASD can interact with system-level input APIs, allowing it to work with on-screen keyboards that were previously outside of reWASD’s scope. This is especially relevant for handheld devices and accessibility-focused setups, where virtual keyboards are often a primary input method. While Send Input is intended for advanced users and specific scenarios at this stage, it represents an important foundation for future development in adaptive and accessibility-oriented workflows.

This release also expands support for ESP32-based setups. reWASD 9.3 adds full support for ESP32-S3, including the ability to communicate with the board over a network. Wi-Fi communication is now also available for ESP32-S2.

Alongside these larger changes, reWASD 9.3 continues to expand controller support and overall compatibility. This includes support for Flydigi Apex 5, improvements for Nintendo controllers (including GR / GL button remapping for Joy-Con 2 in Grip mode), as well as a range of fixes and refinements that improve gyro behavior, rumble support, device initialization, and overall stability across different hardware configurations.

And here's our next lot: reWASD Basic

Along with reWASD 9.3, we’re also introducing reWASD Basic - a separate product built around a simpler idea: just the essentials.

reWASD Basic is designed for users who want a clean, straightforward way to remap their controllers, keyboards, or mice. It’s not a “cut-down” version of reWASD, but a focused alternative for simpler setups, handheld devices, and anyone who prefers a lightweight remapping experience. It’s worth noting that reWASD Basic supports the same wide range of devices as reWASD itself - including 80+ supported controllers, as well as keyboards and mice.


This release reflects the direction we’re moving in - expanding advanced capabilities where needed, while also offering simpler, more focused options for those who prefer the essentials.
As always, we’re happy to hear your feedback. Thank you for staying with us.

[lankaras]

Hi,

Thanks for the update. Send Input is interesting to me because it works with AutoHotkey, this means I can do things that are not available through command line such as changing a shift layer.
I tested it and it works, except: It requires a delay (holding the virtual key) to work consistently, which I found a bit weird.

This did not work (AHK code) :

Z::
Send, a
return

This works:

Z::
Send, {a down}
Sleep 40
Send, {a up}
return

Even a delay of 20ms was not enough for consistency. At 40ms it seems good.
Also we can't mute the virtual key? Might be a system limitation I suppose?

[lankaras]

Follow up question, I noticed that it doesn't work when I'm in the reWASD GUI. Is that intended / a known limitation?

I have a shift layer that I use for when I'm in the reWASD GUI, so I can more easily change mappings using a controller.
If Send Input doesn't work there then I can't use my new trick for that...

Edit: I found a workaround, I can focus Explorer, change the layer and focus back to reWASD. Still I wonder why this happens, it works everywhere else. Must be hardcoded for some reason I think?

[1ncorrect]

Hi,

Thanks for the update. Send Input is interesting to me because it works with AutoHotkey, this means I can do things that are not available through command line such as changing a shift layer.
I tested it and it works, except: It requires a delay (holding the virtual key) to work consistently, which I found a bit weird.

This did not work (AHK code) :

Z::
Send, a
return

This works:

Z::
Send, {a down}
Sleep 40
Send, {a up}
return

Even a delay of 20ms was not enough for consistency. At 40ms it seems good.
Also we can't mute the virtual key? Might be a system limitation I suppose?

1. A delay between button presses and releases is necessary for mapping to work. However, games and applications often don't register pauses of 10-20ms. This explains why changing the pause to 40ms worked.
2. Send input is a system event, not a physical button. Therefore, it can't be muted.

[1ncorrect]

Follow up question, I noticed that it doesn't work when I'm in the reWASD GUI. Is that intended / a known limitation?

I have a shift layer that I use for when I'm in the reWASD GUI, so I can more easily change mappings using a controller.
If Send Input doesn't work there then I can't use my new trick for that...

Edit: I found a workaround, I can focus Explorer, change the layer and focus back to reWASD. Still I wonder why this happens, it works everywhere else. Must be hardcoded for some reason I think?

Could you elaborate further: is the problem that send input is not hooked in the GUI?

[lankaras]

Could you elaborate further: is the problem that send input is not hooked in the GUI?

Yes, I think that's it if I understand you correctly. My test case is as follows:

1. Create Send Input mapping F24 -> A
2. Send F24 through AHK at the press of Z.
3. Expectation: I press Z > AHK sends F24 > reWASD engine will send A.

4. I press Z in notepad. Result: A appears, so the whole chain works.
5. I press Z in reWASD after focusing a text field. Result: Nothing appears.

When reWASD app has focus, the last step is not executed, OR it is executed and reWASD app is deaf to it.

[lankaras]

I tested it again by catching the last keypress and displaying a tooltip when A is pressed, to see if the last step is being executed.
Result: The tooltip is not there when reWASD is focused. So it seems the Send Input mapping is not executed at all.

[1ncorrect]

This is intentional.
When remapping is enabled, reWASD GUI does hook up input.

[lankaras]

This is intentional.
When remapping is enabled, reWASD GUI does hook up input.

Ok, thanks. It's not a problem because I can use my workaround, I was just curious if it was intended or not. The app is separate from the engine so I don't see a reason why it shouldn't work there.