linux-kernel - Re: [PATCH v4 01/24] input: Add ff-memless-next module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 May 2014 16:16:12 -0400
From:	simon@...gewell.org
To:	"Michal Malý" 
	<madcatxster@...oid-pointer.net>
Cc:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	jkosina@...e.cz, elias.vds@...il.com, anssi.hannula@....fi,
	simon@...gewell.org
Subject: Re: [PATCH v4 01/24] input: Add ff-memless-next module


> To bring this to a conclusion we could go from, would this be an
> acceptable
> solution?
>
> - Have the HW-specific driver talk directly to ff-core and reimplement
> upload(),
> play(), etc.
> - Rewrite "ff-memless-next" so that it is not a self-contained module but
> a
> library of functions.
> - Have the driver either:
>   - Upload an effect to a device directly if the device can fully manage
> the
> effect by itself.
>   - Use provided timing functions to know when an effect should start,
> stop,
> restart etc...
>   - Use provided timing AND processing functions to combine effects that
> can be
> combined into one, calculate periodic waveforms etc?
>
> I have no problem with throwing my current approach away but before I
> start working on a new one I'd like to know which way to go...

Hi all,
If the driver itself (hid-logitech, via hid-lg4ff for example) is more
involved in the creation/timing/management of the effects, does this mean
that we end up with code duplicated in lots of places?

Also, does this mean that the 'old' ff-memless system would remain in
kernel? If not, who will reworking each driver?



Regarding the question of emulated vs. real effects, can we extend the API
so that applications can know which effects are really supported, and
enable/disable emulation somehow?

Apologies for asking some many questions, without answering anything...
Simon

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/