This is understandable but this doesn’t solve the problem of using the Honeycomb hardware with other programs which are using auto-detection for assigning switches:
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).
More about this:
Heading Increment Bug (10 degree instead of 1) Explained - #344 by CptLucky8 Heading Increment Bug (10 degree instead of 1) Explained - #2 by CptLucky8