ff_replay substructure in ff_effect empty

Question

I am developing a force feedback driver (linux) for a yet unsupported gamepad.

Whenever a application in userspace requests a ff-effect (e.g rumbling), a function in my driver is called:

static int foo_ff_play(struct input_dev *dev, void *data, struct ff_effect *effect)

this is set by the following code inside my init function:

input_set_capability(dev, EV_FF, FF_RUMBLE);
input_ff_create_memless(dev, NULL, foo_ff_play);

I'm accessing the ff_effect struct (which is passed to my foo_ff_play function) like this:

static int foo_ff_play(struct input_dev *dev, void *data, struct ff_effect *effect)
{
    u16 length;
    length = effect->replay.length;
    printk(KERN_DEBUG "length: %i", length);

    return 0;
}

The problem is, that the reported length (in ff_effect->replay) is always zero.

That's confusing, since i am running fftest on my device, and fftest definitely sets the length attribute: https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c (line 308)

/* a strong rumbling effect */
effects[4].type = FF_RUMBLE;
effects[4].id = -1;
effects[4].u.rumble.strong_magnitude = 0x8000;
effects[4].u.rumble.weak_magnitude = 0;
effects[4].replay.length = 5000;
effects[4].replay.delay = 1000;

Does this have something to do with the "memlessness"? Why does the data in ff_replay seem to be zero if it isn't?

Thank you in advance

Answer 1

Why is the replay struct empty?

Taking a look at https://elixir.free-electrons.com/linux/v4.4/source/drivers/input/ff-memless.c#L406 we find:

static void ml_play_effects(struct ml_device *ml)
{
    struct ff_effect effect;
    DECLARE_BITMAP(handled_bm, FF_MEMLESS_EFFECTS);

    memset(handled_bm, 0, sizeof(handled_bm));

    while (ml_get_combo_effect(ml, handled_bm, &effect))
        ml->play_effect(ml->dev, ml->private, &effect);

    ml_schedule_timer(ml);
}

ml_get_combo_effect sets the effect by calling ml_combine_effects., but ml_combine_effects simply does not copy replay.length to the ff_effect struct which is passed to our foo_play_effect (at least not if the effect-type is FF_RUMBLE): https://elixir.free-electrons.com/linux/v4.4/source/drivers/input/ff-memless.c#L286

That's why we cannot read out the ff_replay-data in our foo_play_effect function.

Okay, replay is empty - how can we determine how long we have to play the effect (e.g. FF_RUMBLE) then?

Looks like the replay structure is something we do not even need to carry about. Yes, fftest sets the length and then uploads the effect to the driver, but if we take a look at ml_ff_upload (https://elixir.free-electrons.com/linux/v4.4/source/drivers/input/ff-memless.c#L481), we can see the following:

if (test_bit(FF_EFFECT_STARTED, &state->flags)) {
    __clear_bit(FF_EFFECT_PLAYING, &state->flags);
    state->play_at = jiffies +
             msecs_to_jiffies(state->effect->replay.delay);
    state->stop_at = state->play_at +
             msecs_to_jiffies(state->effect->replay.length);
    state->adj_at = state->play_at;
    ml_schedule_timer(ml);
}

That means that the duration is already handled by the input-subsystem. It starts the effect and also stops it as needed.

Furthermore we can see at https://elixir.free-electrons.com/linux/v4.4/source/include/uapi/linux/input.h#L279 that

/*
 * All duration values are expressed in ms. Values above 32767 ms (0x7fff)
 * should not be used and have unspecified results.
 */

That means that we have to make our effect play at least 32767ms. Everything else (stopping the effect before) is up to the scheduler - which is not our part :D