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 15:04:52 -0700
From:	Roland Bosa <rbosa@...itech.com>
To:	simon@...gewell.org
CC:	Michal Malý <madcatxster@...oid-pointer.net>,
	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
Subject: Re: [PATCH v4 01/24] input: Add ff-memless-next module

On 05/20/2014 12:39 PM, simon@...gewell.org wrote:
> hopefully bring Linux into scope for force-feedback of AAA game quality.

^ That's my objective too.

> Mostly this has come from a small group of people reverse engineering the
> Logitech wheels, which leads to the 'tailor-made' situation. But we'd like
> the systems/interfaces to be device agnostic.

I'm sure we can consolidate the support into fewer files.

> As you how you can help...? As Michal said having a contact at Logitech to
> whom we can ask technical questions (off list) would probably be the
> greatest help. This would clear up any assumptions we have made, and help
> with decisions going forward.

Please don't hesitate to contact me. ;-)

> It may also be the case that Logitech is working with studios/game
> designers to improve controller performance. If any information can be
> feed 'forward' to improve the Linux driver, that would be useful too.

IMO, there are two types of games. The "arcade" ones, which have a set
of 'canned' force effects, which play whenever an event happens in game.
And the "simulation" ones, which base the game on a physics engine. The
latter can redirect some variables of their engine to the input layer
and typically drive a constant force and maybe a spring/damper too.

For the first type, you might want to keep a centering spring active all
the time. Maybe you want to tweak the gain in the game settings. Maybe
there's a gain for the centering and one for the special effects. The
canned effects are mostly periodics with varying waveform, duration,
amplitude and envelope. That's about it.

For the second type, you don't want a centering spring. You typically
will drive a constant force effect with the engine, with some sprinkled
damping and maybe a slight spring here and there.

I would personally put more weight and effort to get the second type
properly implemented. The players of those games demand more realism and
they need the subtle force changes to drive better than the competition.
That means having a FF driver that can deal with many force updates per
second without choking and a consistent, reproducible force output at
the device, maybe even similar across varying devices. This translates
into a decoupled design for accepting force updates and sending USB
updates, as well as a device-specific layer to "calibrate" and "unify"
the force responses across different models.

Does this make sense?

thanks
roland

--
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/