From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal =?ISO-8859-1?Q?Mal=FD?= Subject: Re: [PATCH v4 01/24] input: Add ff-memless-next module Date: Tue, 20 May 2014 21:00:17 +0200 Message-ID: <10859911.6zyzadbfH9@sigyn> References: <1398524543-15012-1-git-send-email-madcatxster@devoid-pointer.net> <2965006.XKYHWj9YzJ@sigyn> <537B9FAE.9070602@logitech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from transparentnimenzy.cz ([31.31.77.140]:33052 "EHLO smtp.devoid-pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751074AbaETTAZ convert rfc822-to-8bit (ORCPT ); Tue, 20 May 2014 15:00:25 -0400 In-Reply-To: <537B9FAE.9070602@logitech.com> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Roland Bosa Cc: Dmitry Torokhov , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, jkosina@suse.cz, elias.vds@gmail.com, anssi.hannula@iki.fi, simon@mungewell.org On Tuesday 20 of May 2014 11:32:14 Roland Bosa wrote: > On 05/20/2014 02:27 AM, Michal Mal=FD wrote: > > On Wednesday 14 of May 2014 11:05:58 Dmitry Torokhov wrote: > >> On Wed, May 14, 2014 at 10:35:25AM +0200, Michal Mal=FD wrote: > >>> Hi Dmitry, > >>>=20 > >>> thank you for reviewing this. > >>>=20 > >>> On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote: > >>>> On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Mal=FD wrote: > >>>>> + > >>>>> +/** DEFINITION OF TERMS > >>>>> + * > >>>>> + * Combined effect - An effect whose force is a superposition = of > >>>>> forces > >>>>> + * generated by all effects that can be adde= d > >>>>> together. > >>>>> + * Only one combined effect can be playing a= t a > >>>>> time. > >>>>> + * Effects that can be added together to cre= ate a > >>>>> combined + * effect are FF_CONSTANT, FF_PERIO= DIC and > >>>>> FF_RAMP. + * Uncombinable effect - An effect that cannot be com= bined > >>>>> with > >>>>> another effect. + * All conditional effec= ts - > >>>>> FF_DAMPER, FF_FRICTION, + * FF_INERTIA an= d > >>>>> FF_SPRING are uncombinable. + * Number of > >>>>> uncombinable effects playing simultaneously + * > >>>>> depends on the capabilities of the hardware. + * Rumble effect = - An > >>>>> effect generated by device's rumble motors instead of + * > >>>>> force feedback actuators. > >>>>> + * > >>>>> + * > >>>>> + * HANDLING OF UNCOMBINABLE EFFECTS > >>>>> + * > >>>>> + * Uncombinable effects cannot be combined together into just = one > >>>>> effect, > >>>>> at + * least not in a clear and obvious manner. Therefore these > >>>>> effects > >>>>> have to + * be handled individually by ff-memless-next. Handlin= g of > >>>>> these > >>>>> effects is + * left entirely to the hardware-specific driver, > >>>>> ff-memless-next merely + * passes these effects to the > >>>>> hardware-specific > >>>>> driver at appropriate time. + * ff-memless-next provides the UP= LOAD > >>>>> command to notify the hardware-specific + * driver that the use= rspace > >>>>> is > >>>>> about to request playback of an uncombinable + * effect. The > >>>>> hardware-specific driver shall take all steps needed to make + = * the > >>>>> device ready to play the effect when it receives the UPLOAD com= mand. + > >>>>> * > >>>>> The actual playback shall commence when START_UNCOMB command is > >>>>> received. > >>>>> + * Opposite to the UPLOAD command is the ERASE command which t= ells + > >>>>> * > >>>>> the hardware-specific driver that the playback has finished and= that + > >>>>> * > >>>>> the effect will not be restarted. STOP_UNCOMB command tells > >>>>> + * the hardware-specific driver that the playback shall stop b= ut the > >>>>> device + * shall still be ready to resume the playback immediat= ely. > >>>>> + * > >>>>> + * In case it is not possible to make the device ready to play= an > >>>>> uncombinable + * effect (all hardware effect slots are occupied= ), the > >>>>> hardware-specific + * driver may return an error when it receiv= es an > >>>>> UPLOAD command. If the > >>>>=20 > >>>> This part concerns me. It seems to me that devices supporting > >>>> "uncombinable" effects are in fact not memoryless devices and we= should > >>>> not be introducing this term here. If the goal is to work around > >>>> limited > >>>> number of effect slots in the devices by combining certain effec= ts then > >>>> it needs to be done at ff-core level as it will be potentially u= seful > >>>> for all devices. > >>>=20 > >>> Force generated by a conditional effect (referred to as "uncombin= able" > >>> within ff-memless-next to make the distinction clear) depends on = a > >>> position of the device. For instance the more a device is deflect= ed from > >>> a neutral position the greater force FF_SPRING generates. A truly > >>> memoryless device would have to report its position to the driver= , have > >>> it calculate the appropriate force and send it back to the device= =2E IMHO > >>> such a loop would require a very high USB polling rate to play > >>> conditional effects with acceptable quality. > >>>=20 > >>> We know for a fact that at least many (all?) Logitech devices tha= t > >>> support > >>> conditional effects use this "semi-memoryless" approach where > >>> FF_CONSTANT > >>> and FF_PERIODIC are handled in the memoryless fashion and conditi= onal > >>> effects are uploaded to the device (in a somewhat simplified form= ). The > >>> amount of effects that can be uploaded to a device is limited whi= ch is > >>> why ff-memless-next uses two steps (UPLOAD/ERASE and START/STOP) = to > >>> handle these effects. > >>>=20 > >>> Conditional effects - even if they are of the same type - cannot = be > >>> effectively combined into one because superposition doesn't seem = to work > >>> here so they have to be processed one by one. > >>>=20 > >>> If we ever come across a really memoryless device it should not b= e > >>> particularly difficult to add another callback to ff-memless-next= which > >>> would emulate conditional effects with constant force. > >>=20 > >> Thank you for the explanation. This further solidifies for me the = idea > >> that handling of such effects that are in fact uploaded to and man= aged > >> by the device should not be handled by the memoryless core but rat= her by > >> the driver itself. I.e. such drivers should implement their own pl= ay(), > >> upload(), erase(), etc, and decide whether to use a hardware slot = for > >> the effect or handle effect in memoryless fashion (if possible). W= e can > >> open ff-memless to allow such drivers to use parts of memoryless > >> handling. > >>=20 > >> Thanks. > >=20 > > To bring this to a conclusion we could go from, would this be an > > acceptable > > solution? > >=20 > > - Have the HW-specific driver talk directly to ff-core and reimplem= ent > > upload(), play(), etc. > > - Rewrite "ff-memless-next" so that it is not a self-contained modu= le but > > a > > library of functions. > >=20 > > - Have the driver either: > > - Upload an effect to a device directly if the device can fully m= anage > > the > >=20 > > effect by itself. > >=20 > > - Use provided timing functions to know when an effect should sta= rt, > > stop, > >=20 > > restart etc... > >=20 > > - Use provided timing AND processing functions to combine effects= that > > can be>=20 > > combined into one, calculate periodic waveforms etc? > >=20 > > 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... > >=20 > > Thanks, > > Michal >=20 > Hi everyone >=20 > Allow me to introduce myself. I'm Roland Bosa and I work for Logitech= , > more specifically the gaming group. I have been tasked to look into > gaming device support for Linux and I just started following this lis= t > and studying the kernel code related to the Logitech Force Feedback > devices. The 'ff-memless-next' module sounds tailor-made for our > devices. Please let me know how I can help with its development. Hi, "ff-memless-next" was designed with behavior of Logitech devices in min= d,=20 however it was always meant as a general replacement for the current "f= f- memless". After some followup discussion it's unlikely that it will be=20 mainlined in its current form. See the discussion here=20 "http://www.spinics.net/lists/linux-input/msg31426.html" for more detai= ls. We would however really appreciate some information regarding Logitech = devices=20 specifically. Although we have reverse engineered most of things, I bel= ieve=20 there are still areas we're not entirely clear about. I realize that yo= u'd=20 probably have to take it up with the legal deparment but if someone at=20 Logitech could at least take a look at what we've found so far at fill = in the=20 blanks it'd be most helpful. Please note that we found numerous bugs and DirectInput specs violation= s in=20 the Windows driver which might have impacted our understading of how th= e=20 driver works. "ff-memless-next" and "lg4ff" tries to fix or work around= these. A=20 link to out-of-tree update to lg4ff which takes full advantage of "ff-m= emless- next" is also provided in this thread. Thanks for any help you can get us, Michal -- 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