On Thu, May 2, 2013 at 4:45 PM, Dmitry Torokhov
<[email protected]> wrote:
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html