Interesting discovery vis-a-vis Saitek "Mode" switch

[Gypsy Baron]

In trying to solve a mystery surrounding another users reporting of once seeing

the Mode Rotary on his X52 stick being displayed in the FSUIPC4 Buttons + Switches

window and now NOT seeing those switch positions reported, I did some digging on

the web and discovered an old 2007 post on the Microsoft Developers Network Forum

that addressed this issue.

Using my Saitek X-45 for a test, as it did not report the Mode switch positions

to FSUIPC4 either, I did the following:

Opened the Windows Control Panel and then selected the Game Controllers application.

I selected my X-45 from the list of attached controllers and then "Properties".

With the Properties window open, showing all the functions available on the X-45

INCLUDING the Mode switch positions, I then started FSX, loaded a flight, opened

FSUIPC4 and the Buttons + Switches window.

The result under those conditions was that the Mode switch position WAS being seen

now by FSUIPC. On the X-45 the three modes showed as Btn# 8, 9 and 10.

I wrote a little Lua script to use the "n = ipc.buttons(joynumber)" function

to read 32-bit mask showing which buttons are currently ON or OFF and the

"ipc.display" function to show that variable on the screen.

This revealed that as long as the Windows Controller Properties window was OPEN,

bit 11 of the button mask was set along with either bit 8, 9 or 10. There is

no "button 11" on the X-45. The numbers jump from 7 ot 12 without the "Properties"

dialog window open. The setting of this "switch" is apparently some hidden feature.

Any other buttons or switches activated showed up as well, added to the current

mode switch bits.

Once the Windows "Properties" window was closed, the mode switch was no longer reported

to FSUIPC4 nor was bit 11 set.

I do not have knowledge of the inner workings of DirectInput or what might be happening

to allow the pass-through of the mode switch settings when that Properties dialog window

is open but it seems there is some communication between the X-45 (or X-52 I believe)

and that Windows function that enables this "special condition".

It would be nice if this behavior could be "activated" without having to keep the

"Properties" dialog open. Barring that, anyone who wishes to use the compound

button programming facilities of FSUIPX4 to implement modes and all their other

button/switch programming for FSX, without having to use other switches, could use

this technique. This would enable the use of an otherwise unusable switch, (Mode)

assuming one chooses not to use the Saitek SST software.

Paul

Here is the link to the old post I found:

My link

[Pete Dowson]

It would be nice if this behavior could be "activated" without having to keep the

"Properties" dialog open. Barring that, anyone who wishes to use the compound

button programming facilities of FSUIPX4 to implement modes and all their other

button/switch programming for FSX, without having to use other switches, could use

this technique. This would enable the use of an otherwise unusable switch, (Mode)

assuming one chooses not to use the Saitek SST software.

This sounds very much like a fault in the drivers, not the SST software, provided by Saitek. With the Properties dialog open they are obviously following a slightly different path internally. There's really not anything I can do -- the interface allows me to read the set of axes and button settings as a single data structure. There's really no variations apart from "raw" mode as opposed to "calibrated", and that only affects axes.

Has anyone tried SPAD which I believe must be reading and interpreting the USB data itself. Or doesn't that apply to those devices?

FSUIPC's Lua facilities now contain USB device access via the COM library, but you'd need some sort of USB monitor program to see what the protocols were before venturing into that sort of programming. If Saitek had not reneged on their agreement, and paid the licence fee they promised and I invoiced, I would have worked on this as I did for VRI devices, but I am certainly not interested in supporting them further in the circumstances.

Regards

Pete

[Herb]

Thank You Gypsy for posting this. It really works, got the mode-wheel and some other buttons working now. See attachment. This Has to stay open, Now I'm loading FSX WIN7/64bit. Herb

I would like to add more Info:

In the windows/System32 folder there are Saitek .dll files the last one (under Saitek) is named: SaiD075C.pr0

You have to remove this line and Restart your computer. This will give you the 3 Modes + some other buttons. No need to run the Saitek Flight-Control Window in the back any more. Herb

[rkagerer]

Agreed; this is a very useful post. I discovered it while trying to capture the X52 buttons/axes from C#.

The following buttons on the joystick are only available when the control panel applet is open (assuming numbering starts at 1):

- 24: (down when Mode1 is active)

- 25: (down when Mode1 is active)

- 26: (down when Mode1 is active)

- 31: mouse button (on throttle, the tiny button behind the pointer stick)

- 32: wheel button

- 33: wheel scroll up

- 34: wheel scroll down

These buttons also work when the Profiler window has focus.

As Herb posted, if you look in your C:\Windows\System32 folder and remove the SaiD????.pr0 file, it causes the joystick to NOT be initialized with the default empty profile on startup, which lets you read these keys without the need to have any background windows open.