On Thu, May 02, 2013 at 01:06:59PM -0400, Todd Showalter wrote: > On Thu, May 2, 2013 at 12:38 PM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > > 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. > > >> 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 -- 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
