Hi Dmitry,

On Jan 12, 2024, at 9:41 AM, James Ogletree [off-list ref] wrote:

quoted

On Jan 11, 2024, at 1:28 AM, Dmitry Torokhov [off-list ref] wrote:

On Wed, Jan 10, 2024 at 02:36:55PM +0000, James Ogletree wrote:

quoted

quoted

On Jan 9, 2024, at 4:31 PM, Dmitry Torokhov [off-list ref] wrote:

On Tue, Jan 09, 2024 at 10:03:02PM +0000, James Ogletree wrote:

quoted

quoted

On Jan 6, 2024, at 7:58 PM, Dmitry Torokhov [off-list ref] wrote:

On Thu, Jan 04, 2024 at 10:36:37PM +0000, James Ogletree wrote:

quoted

+ } else {
+ queue_work(info->vibe_wq, &info->vibe_stop_work);

Which effect are you stopping? All of them? You need to stop a
particular one.

Our implementation of “stop” stops all effects in flight which is intended.
That is probably unusual so I will add a comment here in the next
version.

Again, please implement the driver properly, not define your own
carveouts for the expected behavior.

Ack, and a clarification question: the device is not actually able to
play multiple effects at once. In that case, does stopping a specific
effect entail just cancelling an effect in the queue?

In this case I believe the device should declare maximum number of
effects as 1. Userspace is supposed to determine maximum number of
simultaneously playable effects by issuing EVIOCGEFFECTS ioctl on the
corresponding event device.

Is it possible to specify the device’s maximum simultaneous effects
without also restricting the number of effects the user can upload? It
looks like both are tied to ff->max_effects.

Best,
James

Is there an opportunity here for a subsystem change to disassociate max
upload-able effects and max simultaneously playable effects, or if not what
do you advise in the case of a device in which the two differ? Or is this
a misuse of the subsystem in some way?

Best,
James