On Thu, May 02, 2013 at 01:06:59PM -0400, Todd Showalter wrote:

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

quoted

I wish we have gotten all the mappings correct from the get go, but that
did not happen, so now we need to move forward. That means that we can
establish the canonical mapping and try to follow it for the new
devices, but you still need to support older devices and for that you
will still need mapping.

    That's why I'm suggesting having /dev/input/gamepad* devices
alongside the equivalent /dev/input/event* devices.  All current users
are either looking at js* or event* device nodes, so as long as those
are left unchanged, nothing breaks.  New users can open gamepad* and
know that they'll get consistent results.

    New devices can support the gamepad mapping so that what gets
exported in event* and js* is in canonical order, and older devices
will just work as they always did.  I strongly suspect once that's in
place you'll find that most users go straight to the new interface.

    I'm also talking to the Wayland folks and offering to do the
gamepad event protocol code, and if /dev/input/gamepad* is available
that's definitely what I plan to feed into the Wayland event system.

quoted

quoted

    Really, what I want is roughly what /dev/input/js* has, but as
/dev/input/gamepad* with standardized mapping.

This is understandable but I do not believe this should be done in
kernel, but rather in userspace.

    I can see why you believe that, but personally I think the kernel
is exactly where it belongs:

- it's a useful abstraction, as useful for games as the standard mouse
and standard keyboard are for other programs -- programs don't have to
call a translation library to remap mouse input

That is because all mice generate standard events. Note that mice users
do not have a dedicated interface (mousedev is legacy and nothing
remotely modern is using it).

You only need to translate for devices that do not generate the events
you are expecting.

- the current game controller semi-standard, the js* interface, was
really designed for 90s era flight simulator joysticks, and while
gamepads have been wedged into it they aren't a great match

Completely agree. The js interface was here way before we had the
current input subsystem with evdev interface that is proved to be
flexible enough. So when evdev was created joydev was implemented to
keep compatibility with older software. Newer software again is expected
to use evdev exclusively (from kernel POV, there can/should be userspace
layers on top).

- any mapping library is going to have to be a mirror of the kernel
code, which means it's basically just a lot of duplicated effort with
the added penalty of update lag

The library can do much more than that. You also need to calibrate the
device (per user), adjust it to user's tastes and so on. Maybe you have
a user that is left-handed and you'd like to remap some keys? It is
certainly not kernel's job.

There also should not be lag if new devices follow the agreed upon
mapping.

    Why not fix the problem at the source?  Creating a
/dev/input/gamepad* device node for each gamepad in addition to the
event* device node solves the whole problem.  It leaves the old
interface intact, it only brings the new interface online for devices
that support it (and have had the appropriate support code added), and
it means that the problem can be tackled piecewise.  At the same time,
it gives us standard behaviour that a game can rely on.

The same thing can be done in a library. Libraries are easier then
kernels, you do not need to consume memory until needed and you do not
need to do the conversion if it is not needed. And it should be possible
to update the library whereas with kernel you mist likely need to reboot
the box.

Why do people believe that patching the kernel is easier than updating
userspace?

Thanks.

-- 
Dmitry