On Thu, May 2, 2013 at 10:09 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote:
> What do you do with devices that don't provide these buttons? (like
> the Wii Remote) What do you do with HID devices which include the
> mapping in their HID-descriptor (you need fixup HID-descriptors for
> each and every incompatible device..)? What do you do with input
> devices that are half gamepad, half mouse (or whatever..)?
Regardless of how they identify themselves, devices that don't
provide the base gamepad functionality don't meet the standard, so
they don't need to conform. The wii remote can also be used as a
mouse (it has buttons, it can (sort of) sense screen position), but it
doesn't make sense to bend the mouse protocol to support them.
With mice, we're reasonably lucky in that the HID spec mostly
makes devices do the right thing, but consider the case of the
trackball on my desk, the Kensington Slimblade. It has four buttons,
and fakes a scroll wheel with clockwise and counterclockwise rotation
of the ball. It presents itself as a HID mouse. Except the third and
fourth buttons, rather than coming over the wire as buttons, are
actually set as bits in hid->usage. The kernel driver maps them to
BTN_MIDDLE and BTN_SIDE (see hid-kensington.c::31-32), and nothing
except the kernel needs to care.
> The thing is, I doubt that there is a good "generic" gamepad idea that
> we can use as a model. Yes, the three major gamepads may be very
> similar, but the kernel supports a lot more devices. Are you only
> interested in GamePad-like devices? What do you want to do with
> devices that can be used as a gamepad, but also as another device? If
> you change them, you might make their "native" mapping very weird.
> For instance, the WiiRemote can be used as gamepad (expecially if used
> with extension devices), but also as a totally different input device
> with accelerometer and IR cam. So you can map the extension
> analog-button as ABS_X/Y, but that means, the accelerometer cannot be
> mapped as ABS_X/Y. So this means the accelerometer API breaks (and is
> inconsistent with other devices). And so on...
There's a very good gamepad abstraction; it's the common set of
controls between:
- the ps3 sixaxis
- the xbox controller
- the xbox 360 controller
- the ouya controller
- the wii classic controller
- all the OEM 360 controllers
That covers a whole lot of ground, and as a game developer it
covers most of the ground I care about for most games that aren't
keyboard/mouse.
Sure, you can configure the wiimote in a lot of ways. As a game
developer on the Wii (which I am; I've a Wii devkit right here), I
care about the controller configurations because it's the standard
controller on the system. As a game developer on the PC, I couldn't
care less about it; there are probably less than a hundred people in
the world trying to play games with the Wii controller in Linux. Most
of the people connecting Wii controllers to Linux boxes are doing
something entirely else with them.
The standard gamepad (2 sticks, dpad, 2 triggers, 2 shoulder
buttons, 4 face buttons, start button, system button, stick click
buttons) is well established; the PS3 uses it, the XBox 360 uses it,
the Wii has it in the Classic controller, the Ouya uses it, the
GameStick uses it, all the OEM console game controllers use it, the
PS2 used it, the GameCube used it... I'll be fairly surprised if the
next XBox and the PS4 don't use it as well. It is now as standard as
an input device as the 3 button plus scrollwheel mouse.
All it lacks is a rigorous HID standard, which is why we have the
mess we have now.
> So please, go ahead and fix all the broken drivers that report wrong
> values. I think everyone here would appreciate that a lot. But you
> must know that it is hard work. You need to check all the different
> device-revisions, verify that other devices don't break just because
> your gamepad-revision returns other values. You might need
> backwards-compatible keymaps, module-flags and so on.
> Many of the device drivers were written by hobby-developers so their
> devices work. Many of them might not be around anymore or only have
> time to fix bugs.
I'm not afraid of the work; it's more a question of whether I can
dig up the hardware to test these things. I've an xbox controller, a
360 controller, and a ps3 controller. I've also got Wii controllers,
but my Linux box doesn't have bluetooth.
Ok, here's a question: could gamepad-like devices have two dev
entries? One that exported the full raw device, and one that
responded to EVIOCGNAME with "Standard Gamepad"? That way, the raw
device in all its glory would be available for anything that wanted to
understand the device, and games that just wanted bog standard console
gamepad controls could have it without having to jump through hoops.
It would also mean we could just leave the raw interface alone, so
that if anyone is counting on it it doesn't change.
The only hassle would be supplying some way for a game that cared
about both to know that (say) /dev/input/event15 and
/dev/input/event16 were actually different views of the same device.
> So if you want reliable gamepads, the easiest way is a user-space
> mapping based on device-names. This guarantees you get the expected
> buttons. Adding support for new devices is a matter of few lines of
> code. And it normally takes >1 month for a device driver gets included
> in the kernel, so you have enough time adding the support to your
> user-space side.
> This also allows you to easily support devices that are no gamepads,
> but would make sense with your applications.
>
> I would really appreciate, if you help fixing those drivers instead of
> using the user-space mappings. But I just want to warn you, that it is
> more work than you might think.
>
> Cheers
> David
--
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
