On Thu, May 2, 2013 at 1:54 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote:
> 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).
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.
> 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.
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.
> 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?
> 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.
> 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...".
> 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.
> 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.
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
