On Thu, May 02, 2013 at 03:10:55PM -0400, Todd Showalter wrote:

On Thu, May 2, 2013 at 1:54 PM, David Herrmann [off-list ref] wrote:

quoted

How about a new input property that marks devices that follow general
rules as such? So for instance:
  INPUT_PROP_DEV_MOUSE
  INPUT_PROP_DEV_KEYBOARD
  INPUT_PROP_DEV_GAMEPAD
  INPUT_PROP_DEV_JOYSTICK
And so on. And then we can decide on a generic mapping for each. We
only set these properties on devices that follow the generic mapping.
Devices that don't have these flags set are non-generic or have weird
keymaps. This would also solve problems were the xserver thinks some
gamepads or accelerometers are a mouse (or similar).

The devices that use generic mappings are easy to identify from
userspace already (does this thing has 2 sticks? then it should be
usable as gamepad. Only one stick? Joystick or older-style pad, etc).
It is devices that incorrectly mapped with generic drivers that need
these hits and for them we also need the heuristic, either in kernel or
in userspace.

If if it map/config file driven user at least has a chance of adjusting
properties without patching and recompiling the kernel.

    That could work.  As long as I can programatically filter devices
to get the ones with sane behaviour, I don't really have strong
opinions about the specific method.  The /dev/input/gamepad* method
solves the problem, but if I can march /dev/input/event* looking for
events that advertise INPUT_PROP_DEV_GAMEPAD I think it gets me what I
need.

quoted

This allows user-space to detect generic devices. For all other device
types, they need special support, anyway. They can still use the same
heuristics that they use now, but we can try to provide a generic flag
to avoid these often wrong heuristics.

    That's the thing; while the ps3 controller has (for example) 12
pressure sensitive buttons and a suite of accelerometers, most games
don't care.  Even on the ps3, most games don't care.  A few do, and
they do the extra work they need to in order to use those controls,
but the vast majority of games want one or two analog sticks and a
handful of buttons with known mappings.

So ignore the events you do not care about.

Again, nobody argues against needing a consistent mapping, the arguments
are against an additional in kernel interface that only does
ABS_XXX->ABS_YYY mapping.

    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.

quoted

I talked with Kay (udev maintainer) and he was really opposed to huge
udev black/white-lists that mark devices as generic MOUSE, KEYBOARD,
TOUCHPAD, ... These kernel properties would really help, but require
agreement on a generic mapping.

    What about a /dev/input/by-type directory?
/dev/input/by-type/gamepad could have symlinks to all the
gamepad-supporting devices, /dev/input/by-type/mouse could symlink the
mice, and so forth.  Or is that udev's territory?

quoted

And as Dmitry noted, we cannot change legacy drivers due to backwards
compatibility. A separate /dev/input/gamepad* interface just wastes
resources when all you want is just a different and consistent
mapping.

    Could we consider a build switch?  Something where people could
choose to build (for example) the ps3 support either in "legacy" or
"new" form?  I'd be a little surprised to hear anyone is actually
relying on the current ps3 mapping, and if it can't be changed and we
can't offer alternate mappings at runtime, we could let people choose
which mapping they want.

    Or could we have an ioctl() to flip it from legacy mode to
canonical mode?  Or an ioctl() to query the driver for a mapping table
that would at least tell us how to map from the legacy mapping to a
canonical mapping?  We're talking about 8 axis index values and 12ish
button index values, so it could fit in 20 bytes or less per supported
legacy device.

Again, this does not have to be in kernel. The mapping has nothing to do
with hardware access.

quoted

Why not try to create a /usr/share/gamepad/*.map filetype and let
distros ship these files. Your game can then parse these into a table
and use the mappings for all legacy gamepads.

    That's an option, but what it mostly means is angry customers
wanting to know why their handrolled fork of TinyCore Linux doesn't
see their PowerA Batarang XBox 360 controller.  If I can't force the
distros to ship the updates in a timely fashion (and I'm pretty sure I
can't...), what the customer sees is they plug their perfectly good
controller in, /dev/input/event16 shows up, and my game just ignores
it.  And I'm stuck responding with email and faq entries saying "step
1: install git...".

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?

quoted

Or provide a "enable_legacy_mapping=true" module option for legacy
gamepad-drivers which allows to switch between different mappings
(even though that would be a global flag).

    I'd prefer something like this if we can't just fix things, or an
ioctl() to toggle behaviour.

quoted

I still think the problems with user-space mappings can be solved. And
we should avoid wasting kernel memory for an interface that does
nothing more than change button-mappings.

    I'd really like to see Linux be a good option for living room PCs;
something you can plug into your TV, maybe install Steam or the Ouya
store or Desura or whatever (or just use your distro's package manager
as long as I'm dreaming), and be able to run games on it.  You can do
that now, but there are places (gamepad input is one, sound is
another) where the user experience and the developer experience are
less than optimal.

    Users want to plug in a gamepad and have it just work, regardless
of who made it.  Developers occasionally want access to he more
esoteric parts of the gamepad hardware, but 99% of the time they just
want standard sticks-and-buttons functionality mapped in a predictable
way.

    As a developer, if I had to choose between the current situation
or having all game hardware map down to a standard one-stick, two
button controller with no access to anything else, I'd jump on the
standard controller in a heartbeat.  A standard controller means
there's a gigantic pile of crap I don't have to deal with every time I
write a game.  It means once a player knows what the NORTH button is,
it's the same in every game and on every controller, regardless of
developer or hardware maker.

    The further away from the data source the translation to a
standard controller is when it happens, the more likely it is to
break.  Right now, we're fixing it at the app level, which sucks for
everyone.  Pushing it up to a library or a set of data tables is
better than what we have now, but only slightly.  I'm trying to get it
pushed at least to the point where it's between Wayland/X11 and evdev,
but even at that point it means there are inevitably going to be
version mismatches or missing translation tables.  We can't fix the
hardware, so the closest to the data source we can theoretically get
to is the drivers.

And here we disagree because I believe a library (that not only does the
mapping, but also does all necessary additional transformations) is the
proper solution here. And then you write your games to that library API
and you do not need to know how exactly something was mapped to
EVENT_NORTH in your game. Maybe it comes form a gamepad and maybe it is
a key on a keyboard.

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.

Thanks.

-- 
Dmitry