On Wed, May 21, 2014 at 4:13 AM, Michal Malý
[off-list ref] wrote:

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

quoted

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.

I've got another/(a more detailed?) idea about this:
We can use round-robin scheduling for the slots, and use a priority
queue for e.g. LED data or data that doesn't fit in the
slot-methodology and doesn't permit in-between packets to be lost.
And I believe that ff-memless-next should generate a periodic force
with a constant/defined sample-period/update-rate, while the layer
between ff-memless-next and USB transfers, i.e. the round-robin and
priority queue scheduler, should send the dirty slots as soon as
possible, i.e. when the USB pipe is clear or when some custom
#maxAllowedPacketsInUsbBuffer (optimized for somewhere between latency
and throughput) is not exceeded by the kernel USB queue.
Now the question is, can we query the state of the kernel USB queue?

Optionally, this method of packet scheduling could be used by other
kernel drivers (even non-FF drivers) as well, and can further increase
flexibility of ff-memless-next and the HW-specific drivers, and it
will reduce code duplication.

quoted

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.

Also dynamic updating of periodic effects is not yet supported in
"ff-memless-next".
This can also be important in simulation games (=second type), e.g.
the "rFactor" game.

Elias
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html