On Thu, May 2, 2013 at 4:45 PM, Dmitry Torokhov
[off-list ref] wrote:

quoted

    I'd far rather the games with special needs had to do heavy
lifting than have the common case be complicated just because someone
might want to use a wiimote with a balance board plugged in though a
motion plus.

    If there was good support for racing wheels, kinect-like
controllers and so forth, that would be nice too.  But 99% of games
will have their input needs met just fine by the standard controller
I'm proposing, the standard keyboard and standard mouse.

So are you arguing for /dev/input/wheel as well? And for applications
that are a bit more advanced /dev/input_wheel_with_pedals? This is not
really sustainable when we can already deliver all data through existing
interface.

    No, I'm arguing the opposite.  I want a canonical mapping for
standard controllers.  Anything that wants more than that can deal
with having to understand specific devices.  What I'm saying is that a
vanishingly small number of games actually care about more than the
standard gamepad.

And this is better then cherry pick commit 1765326732afd763876348 from
next branch of input tree, recompile the kernel and see if that fixes
your issue?

    "Make sure you're running the latest kernel." beats the hell out
of "Make sure you've installed the latest FixLegacyGamepads package.
If your distro doesn't support FixLegacyGamepads or has a version
older than 1.2.62104, you'll need to install git...".

Again, the kernel will try to do the right thing and produce the correct
events for new input devices, but we are not going to introduce a copy
of evdev protocol that limits the events to "standard gamepad" ones.

    Ok.  I can see there's no point arguing this.  What can I do to at
least make sure future devices behave?  Is there anything that can be
done about current devices other than translate in userspace?

                                       Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.