On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote:

The file format of an IFR is probably easily deducible. There's a lot of
textual clues to parameters and the values are also written out in
string form.

I don't have a FEdit file at hand, but I suppose it will be similar.

I believe that Elias successfully reverse engineered the effect file format 
produced by FEdit. There is no support for this kind of prefabricated effects 
in the Linux FF API.

quoted

I assume that most AAA games, would implement these through some middle
layer. I think that is probably via Steam using SDL2 haptic API, we have
been testing against SDL2's 'testhaptic'.

I wasn't aware of this layer. I must read up on it. It sounds like a
simple way to access force feedback - I guess a game developer should
shed some light on this...

quoted

Do you see another path (which we should be supporting/testing)?

Nope, not at this time.

quoted

There was some discussion about rate limiting the USB packets to the
wheel, and how to deal if app updates too quickly. Is there an upper limit
for the wheel itself, or is it just the USB 'pipe' which is the limiting
factor?

On the Windows side we send 125 reports/sec. The entire simulation loop
runs with a 8ms resolution. I assume this value was chosen for some
hardware constraints back in the days, but it has proven to be a good
compromise for simulated periodics and physics constraints.

Our current code uses 8 msecs delay as well.

In any case, the USB traffic should be decoupled from the app. Any force
updates should only change state in the ff-memless[-next] driver. Any
change there should trickle down to a 'slot' representation of the
device. If there's any change in the slots, the device is marked as
'dirty' and USB transfers are scheduled to send the latest state to the
physical device.

The scheduling should keep track of how many requests are in-flight and
delay writing the next output, until the previous one has completed.

The approach I had in mind would keep track of the last effect that made it to 
the device and the last effect that arrived from userspace. This would be 
stored for each effect slot. An update would be scheduled at the desired update 
rate. The updating routine would figure out the state change between last 
update and "now", send the required data to the device and reschedule itself. 
The routine could check if there are any USB transfers still running and 
reschedule itself immediately.

Question back to the community: are there APIs in the USB layer to check
for presence of in-progress requests? Can one add a 'completion'
callback to a request, that gets invoked on completion/cancellation?

For instance "usb_submit_urb()" can have a completion handler that is called 
once the transfer is done. The current code uses "hid_hw_request()" which is 
asynchronous and doesn't report anything back.

Proper decoupling of the userspace and driver is the only important thing that 
is missing from the current code.

Michal