linux-kernel - Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it

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] [day] [month] [year] [list]

Message-ID: <1687636.joOxxSug6B@geidi-prime>
Date:	Mon, 24 Feb 2014 23:11:20 +0100
From:	Michal Malý <madcatxster@...fuk.cz>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Elias Vanderstuyft <elias.vds@...il.com>,
	Anssi Hannula <anssi.hannula@....fi>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jiri Kosina <jkosina@...e.cz>, Simon Wood <simon@...gewell.org>
Subject: Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it

On Monday 24 of February 2014 13:48:18 Dmitry Torokhov wrote:
> On Mon, Feb 24, 2014 at 10:17:25PM +0100, Elias Vanderstuyft wrote:
> > On Mon, Feb 24, 2014 at 1:58 AM, Michal Malý <madcatxster@...fuk.cz> 
wrote:
> > > On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote:
> > >> I think we should extend the current ff-memless instead of duplicating
> > >> its functionality (even on a "for now" basis).
> > >> 
> > >> Having looked at ff-memless-next briefly, it seems very similar to
> > >> ff-memless on its basic working principle, and therefore I don't really
> > >> see why extending ff-memless would be too cumbersome. Unless I'm
> > >> missing
> > >> something - in that case, feel free to point it out to me :)
> > > 
> > > Deciding whether to patch ff-memless or write a new driver from scratch
> > > was a perfect example of being caught between the rock and a hard
> > > place. I am not particularly fond of the fact that we would have two
> > > modules doing pretty much the same thing. My reasons for writing a
> > > separate module were:
> > > - Periodic effects. ff-memless doesn't do "real" periodic effects, it
> > > simply emulates them through rumble effect. Devices without rumble
> > > effect support require emulation through constant force effect. Just
> > > this was not something one could write in one afternoon:)
> > > - Conditional effects. These effects cannot be by nature combined into
> > > one
> > > overall force (at least not easily) so they have to be handled one by
> > > one -
> > > this is a concept ff-memless does not seem to consider. FFB devices have
> > > limits as to how many conditional (referred to as "uncombinable" in
> > > MLNX)
> > > effects can be active simultaneously, etc.
> > > All in all it seemed less error prone to write a new driver based on the
> > > ff- memless logic, test and deploy it on devices I have access to and
> > > once we are sure there are no nasty regressions port the rest of the
> > > drivers to the new API. Given the scope of the changes I am afraid that
> > > a "patch" to ff-memless would be pretty close to a rewrite anyway.
> > 
> > And add the fact that we already heavily tested the ff-memless-next
> > driver.
> > Unless you do a diff between the original ff-memless.c and the current
> > ff-memless-next.c (which will result in a rather unintuitive patch),
> > it would be a huge waste of time to retest the modified (when doing
> > efforts to create an intuitive patch) ff-memless-next.c, considered my
> > total time spend on testing (and not to speak of the time that Michal
> > spent to fix the corresponding bugs.)
> > I know that might not be much of an argument, but on the other side,
> > my motivation to test again from scratch will be much lower (I can't
> > change much on that, I'm afraid), which would eventually lead to lower
> > reliability of the final product.
> 
> On the other hand having 2 drivers implementing very similar
> functionality would lead to general confusion as to which one should be
> used; they will also have to be maintained.
> 
> I would rather see them merged into one driver providing necessary
> services to all memoryless FF devices.
> 
> Thanks.

Very well. It that case I guess the most sensible thing to do would be to add 
FF_RUMBLE to ff-memless-next and replace ff-memless completely. As Anssi 
pointed out a lot of the drivers that currently use ff-memless are very simple 
so any risk of breakage will hopefully be minimal.

As I don't have any device with rumble effect support I'll appreciate help on 
this front

Michal M.
--
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/