Sidewinder FFB Pro: initial support (no FFB)

[NolanNicholson]

The Sidewinder Force Feedback Pro reports its joystick data identically to the SW Precision Pro, so the latter's decode function can be reused.

The layout of the initial guessModel function is different from linux/sidewinder.c in that it only tries to repeatedly grab packets, without noting some as ID packets and some as data packets. Judging from the Linux driver, it looks like the Force Feedback Pro has an ID packet of length 14 and a data packet of length 16 or 48.

I'm not quite sure what the best way to refactor guessModel is to work generally here, so for now I've just always assigned 16/48 to be the FFB Pro. This should just mean it erroneously reports the Precision Pro with the wrong name but still all the correct data. I'd love your help doing this the right way, if you are available.

[necroware]

Hi, thank you for the contribution. As far as a I can see, this change doesn't make a lot of sense, since now the Precision Pro will be simply reported as FFB Pro with no further change whatsoever. You are right, that the guessModel() function is a bit too simple for the proper detection and should be extended accordingly. Do you have an idea in which order ID packets are coming and if they can be forced somehow by sending some command to the joystick? In a similar way as enabling digital mode for the SW3D Pro happens.

[NolanNicholson]

Hello, and thanks for your response! I agree that this change doesn't make sense just yet; thanks for your help trying to get it there.

It looks like yes, the ID packet can be forced out by sending a second trigger during the middle of a data packet transmission. From the patent:

Waveform B also includes a second interrupt request 202 that is generated by the inverter 132 in response to the additional OUT, 201H command. The second interrupt request 202 must occur while the microprocessor 124 is transmitting the 64-bit data packet. In response to the second interrupt request 202, INT0 input 134 is again set to a low logic level. The microprocessor 124 interprets the second interrupt request 202 as the Send ID command. In response to the Send ID command, the microprocessor 124 transmits a device identification (ID) data packet.

In the Linux driver, the sw_read_packet() function appears to basically have two "modes". When the last parameter is 0, it reads an ordinary data packet. (This behavior is already implemented in gameport-adapter.) But when the last parameter is nonzero, it performs an ID read instead, which causes it to also schedule a second gameport_trigger() to occur when both A) 45 microseconds have elapsed since a falling edge was detected on the axis 0 line (data0 in gameport-adapter, I think?), and B) the read has reached the last 8 bits of the packet.

So in the Linux code, it appears they request a normal data packet first, to get the packet size. Then, they call sw_read_packet() - which incidentally starts by reading a data packet again, but also uses the packet size to correctly time a second trigger in the middle of reading the data packet. The trigger causes an ID packet to follow this data packet, and only the ID packet is actually stored and measured during the second run.

At least, I think that's what's happening; it's not 100% clear to me.

[NolanNicholson]

Okay, I've implemented a function, readIDPacket(), to induce an ID packet out of the Sidewinder.

The timing is much more basic than what's in the Linux driver, but I've found it to work well - and be a bit flexible on timing - for the Sidewinder FFB Pro. I'm hopeful it should now correctly sort between the FFB Pro and the Precision Pro.

[necroware]

Okay, I've implemented a function, readIDPacket(), to induce an ID packet out of the Sidewinder.

The timing is much more basic than what's in the Linux driver, but I've found it to work well - and be a bit flexible on timing - for the Sidewinder FFB Pro. I'm hopeful it should now correctly sort between the FFB Pro and the Precision Pro.

After you asked I also implemented an ID read function too, but it doesn't work with all Sidweinder devices, which I have. I'll test your version too and will have to experiment with timings a little bit to find something what universally works for all devices.

[necroware]

@NolanNicholson I integrated your changes into the following branch, made some cleanup and the function readID more universal, so in the future it can be used not only for the Precision Pro and FFB Pro. I simplified the procedure for now to rely only on the ID package size. Should we really need more information in the future, we can add the full ID packet decoder, but for now, I don't see the point to do more, than we need. It would be nice if you could test the code on your FFB Pro.

https://github.com/necroware/gameport-adapter/tree/sw-ffb-pro

@creopard In case you'll find some time, it would be also cool, if you'd test that branch on your Precision Pro.

I also made some improvements on timing for Sidewinder joysticks. The delay should be now even shorter.

[creopard]

@necroware my Precision Pro initializes and works flawlessly with the "sw-ffb-pro" branch.

[necroware]

@necroware my Precision Pro initializes and works flawlessly with the "sw-ffb-pro" branch.

Ok, then since everything seems still to work, I'll merge it into the master. If the FFB Pro will show some issues, we can fix it afterwards too.