The main advantage is solving this kind of situation where the game you’re using the device with is not ment to receiving 2 inputs per switch change (one on and simultaneously the opposite one off)
For example I’ve tried using the Alpha on Project Cars II (why not using a -90/+90 yoke as a wheel!) and indeed I couldn’t assign switch inputs because of this.
It just makes sense to be able to have a switch alternating 2 states instead of 4 in some cases, and it isn’t hard to do via firmware changes or better, via firmware operating mode selection which you choose when powering up the device in pressing a combo of keys (this is a common low level firmware mode selection method).
In practice, it is easy: since each switch position is 1 or 0, it just takes disabling all OFF switch states as if the switch doesn’t exist at all. In other words, take a light switch for illustration (I don’t have the exact numbers in head but there are 2 buttons input per switch I’ll reference as button 10 and 11 below):
Current 4 states firmware mode:
- switch down sets button #10 = 1 and button #11 = 0
- switch up sets button #10 = 0 and button #11 = 1
Alternate 2 states firmware mode:
- switch down sets button #11 = 0
- switch up sets button #11 = 1
- the hardware never make a button #10 visible to HID, or if not possible, let button #10 be 0 always.
Although this would give some more possibilities to use the hardware with other software, this won’t solve the “constant” input triggering FS2020 to accelerate the knobs because this is a FS2020 only bug (limitation to keep this post politically correct but it is a game design error in any way you see it).
I’m yet to try the Alpha on XP11 to see how they are mapping the switches there and see what it gives.