Controllers we have never seen, and a server blip that stopped being fatal

Controllers we have never seen

Until now OmniControl read four Sony pads and anything Windows exposed as an Xbox controller. Everything else appeared in the list, said not decoded, and did nothing. That was deliberate rather than lazy: without reading a controller's own layout, any guess at which byte means which button is wrong more often than right, and a pad that half-works is worse than one that plainly does not.

The reason has gone away. Every HID controller publishes a description of itself, and Windows will hand it over: which bits are buttons, which are axes, how wide each one is, and what range it reports. OmniControl now reads that description and works out the controller from it.

So a pad nobody has written code for gets plugged in, and its sticks, triggers and d-pad simply work.

What that description does not contain is which button is which. HID numbers buttons one to however many and never says that number three is X. Worse, the two common conventions disagree with each other, so the same numbering means A on one pad and Square on another. OmniControl guesses from the shape of the rest of the layout, which is right most of the time, and the setup flow below is how you settle it when it is not.

One category is unaffected, and it is worth naming rather than letting you find out: controllers officially licensed for Xbox do not present as HID devices at all. They speak Microsoft's own protocol and reach Windows through the Xbox driver, so there is no description to read. They were already supported through that route and nothing here changes them, for better or worse.

Setting one up

Controllers, pick your controller, Set up controller. OmniControl asks you to press A, then B, then X, and so on through the standard set, and learns which control you actually pressed. Anything your pad does not have, skip.

If your d-pad is the usual kind, all four directions are answered by one press, because that one the controller does describe properly and there is nothing to be gained by asking four more times.

Then it asks about back buttons, one at a time: press the left one, press the right one, and so on.

That step is where you may get an answer you did not want, and it is the honest one. Most pro controllers remap their paddles inside the controller. You assign a paddle to a face button in the manufacturer's own software, and Windows only ever receives that face button. There is nothing arriving for any program to bind, ours included. If setup sees a paddle sending exactly what A already sends, it tells you so rather than pretending to bind it and leaving you to discover it later.

Setup offers itself the first time an unrecognised controller is plugged in, once per controller, and never while you are in a game.

You can also choose which layout the controller is drawn and named as: Treat this as, in the same panel. Pick the Razer Raiju V3 and you get its six extra buttons; pick a DualSense and you get PlayStation naming. It is remembered against the controller and against how it is connected, because the same pad genuinely can report a different layout over USB than over Bluetooth.

Why is my controller not showing up

The Controllers page used to say, when nothing was connected: "No controller detected. Connect a DualSense, DualShock 4 or Xbox controller."

Both halves of that could be wrong. It asserted nothing was connected, which is exactly the wrong thing to say to someone looking at their controller sitting in Device Manager. And it named three pads as though they were the only ones that work.

It now lists what Windows can actually see: which devices report themselves as controllers, which of those OmniControl can read, and how many other input devices are present. If a controller is plugged in and not reporting itself as a controller to Windows at all, that is the single most useful fact about it, because it means the problem is upstream of anything this app does.

There is a Copy details for support button. If a controller does not work, that text is the whole diagnosis and it saves a long exchange of guesses. It contains no serial numbers.

The same panel now also catches one failure that was ours: if you have ever hidden a controller and then moved or reinstalled OmniControl, the hiding can end up pointing at the old copy, which means a controller you hid is hidden from OmniControl as well. It disappears from the app while Windows still shows it working perfectly. That now says so, and tells you how to repair it.

If you would rather none of this ran, Settings, Controller, Read controllers without built-in support turns it off and restores exactly the previous behaviour.

A server blip is not a revocation

This one has been fixed for a week and is only reaching you now, so it is worth explaining properly.

OmniControl checks in with our server periodically to confirm your licence. That check is designed to tolerate failure, because a dropped Wi-Fi connection is not a revocation: the server was never reached, so it never said no.

The tolerance only covered the connection failing to open. Any reply that was not a success, including our server returning an error, was treated as the server saying no. So a brief backend incident did not degrade anything gracefully. It disarmed the engine on the very first check, everywhere, at once.

What that looked like from your side: it died mid-game, and pressing Start did nothing afterwards.

The line is now drawn where it belongs. A revocation is the server being reached, understanding the question, and refusing: that is a 401 or a 403. Everything else is the server failing to answer, whether it was never reached, fell over, or asked us to slow down, and none of those is an instruction to stop.

Stop everything

There was no control anywhere in OmniControl that could reliably stop a macro that was already running.

Every stop was attached to something. The Stop button only appeared for the macro you had selected. The hotkey labelled as the panic switch only changed which macros are allowed to fire next time, and did nothing at all to one already in flight. So the honest answer to "a macro is holding my stick and I cannot stop it" was Task Manager, which also skips the shutdown step that saves your profiles and macros.

There is now a single action that stops everything in flight: it ends the running macro, drops whatever it was holding on the sticks, and releases any key or button still held down. It is deliberately unconditional, because it has to work when the thing that is stuck is the thing that would normally decide whether to stop.

Three ways to reach it: a new hotkey, a tray item, and a Stop everything button beside Pause all. The tray one matters more than it sounds, because a macro pinning your view is exactly when alt-tabbing back to the window is hardest.

Smaller things

The mapping screen. On any controller with rear controls, the Underneath button and Check what mine send were drawn in the same corner, on top of each other, and the one underneath could not be clicked at all. They now sit side by side.

Getting back to the front. Turning the pad around to look at its underside worked. Turning it back did not, once you had selected a control back there: the button was there and did nothing. There is now a Front button next to the underside controls, and the toolbar one works from any state.

Player numbers. Hiding a controller does not free its player number, so your real pad keeps Player 1 and OmniControl arrives as Player 2, which most games ignore. The Be Player 1 step that fixes this used to disappear whenever OmniControl could not work out which player number was its own, which is precisely when you needed it. It now stays, says plainly that it cannot tell, and keeps the button that fixes it. Turning on Xbox output while a controller is hidden also mentions it up front.