Game Controllers

Game Controllers

[Todd Showalter]

    I'm a game developer, and I'm interested in discussing changes in
the way gamepad input is handled at the evdev and device level; is
this the correct place to do that?

                                       Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[Dmitry Torokhov]

Hi Todd, 
On Friday, April 26, 2013 08:13:50 PM Todd Showalter wrote:
>     I'm a game developer, and I'm interested in discussing changes in
> the way gamepad input is handled at the evdev and device level; is
> this the correct place to do that?
> 

It might or it might not. It would be great if you could tell a bit about
your issues.

Thanks.

-- 
Dmitry

Re: Game Controllers

[Todd Showalter]

On Mon, Apr 29, 2013 at 5:04 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

>>     I'm a game developer, and I'm interested in discussing changes in
>> the way gamepad input is handled at the evdev and device level; is
>> this the correct place to do that?
>
> It might or it might not. It would be great if you could tell a bit about
> your issues.

    My primary concern is game controllers (specifically gamepads).
I'd like to see a standard game controller (something akin to the
input functionality of the xbox 360 controller) become a first-class
input citizen alongside the keyboard and mouse.  My argument is
essentially that amongst the major gamepads (the ps3 6axis controller,
the xbox 360 controller, the xbox controller, the wii classic
controller, the ouya controller, and various OEM versions and
imitations of the same) there is a lot of common functionality that is
worth exposing as a standard gamepad the same way systems now expose a
standard mouse.

    My proposed standard gamepad is:

- left stick (2d vector, each component [-1.0f .. 1.0f])
- right stick (2d vector, each component [-1.0f .. 1.0f])
- left trigger (1d vector, [-1.0f .. 1.0f])
- right trigger (1d vector, [-1.0f .. 1.0f])
- dpad
- start button
- system button (home on wii, ps on ps3, glowy x on xbox 360)
- four face buttons (north, south, east, west)
- two shoulder buttons
- two stick click buttons

    What I'd like to request at the evdev level is that things which
are gamepads export these values in standard offsets, so that:

EV_ABS 0 == left stick x
EV_ABS 1 == left stick y
EV_ABS 2 == right stick x
EV_ABS 3 == right stick y
EV_ABS 4 == dpad x
EV_ABS 5 == dpad y
EV_ABS 6 == left trigger
EV_ABS 7 == right trigger

    Or some similar defined order.  I'd like buttons to be similarly mapped:

BTN_START == start button
BTN_WEST == xbox x, ps square
BTN_NORTH == xbox y, ps triangle
BTN_EAST == xbox b, ps circle
BTN_SOUTH == xbox a, ps x
BTN_TL == xbox tl, ps l1
BTN_TR == xbox tr, ps r1
BTN_MODE == xbox glowy x, ps ps
BTN_THUMBL == stick click l
BTN_THUMBR == stick click r

    I'm aware that the xbox and xbox 360 controllers are already
largely mapped this way, but the ps3 controller is not, at least from
what I can tell, and I have no other gamepad hardware to test.  My
goal here is to make it so that something reading an evdev gamepad
stream doesn't need to know what kind of hardware device is backing it
*if* all the reader cares about is the standard gamepad functionality.

    The analogy here is mice; while you can get mice with variable DPI
settings, macro engines and loads of buttons or scroll wheels, normal
applications don't have to query the mouse type to know how the core
functionality is mapped.  If all I want in a game is the left stick
for movement, the bottom face button for jump and the right face
button for shoot, I shouldn't have to be querying the controller to
figure out how those are mapped.  I should be able to take ABS_X and
ABS_Y for the left stick, BTN_SOUTH for jump and BTN_EAST for shoot,
and it should map to the proper buttons and stick regardless of
whether the player has an xbox controller, a logitech controller, a
ps3 controller or a wiimote with a classic controller plugged in.

    There are several advantages of doing this remapping at the driver
level, but the most important ones from my point of view are that it
is simplest to do near the source, and it makes supporting a standard
gamepad as part of (for instance) Wayland a much simpler and thinner
translation layer.  I want to do this through a Wayland (or X11) event
protocol because I want my game (which may be running mods or scripts
downloaded from forums) to be as isolated as possible from the
elevated privileges that opening evdev streams requires.

    So, that's my issue, really; I'd like a standardized core gamepad
protocol in Linux, and I'm talking to people at every level of the
stack to see if I can make it happen.

                                       Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[Antonio Ospite]

On Mon, 29 Apr 2013 20:46:47 -0400
Todd Showalter <todd@electronjump.com> wrote:

> On Mon, Apr 29, 2013 at 5:04 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> 
> >>     I'm a game developer, and I'm interested in discussing changes in
> >> the way gamepad input is handled at the evdev and device level; is
> >> this the correct place to do that?
> >
> > It might or it might not. It would be great if you could tell a bit about
> > your issues.
> 
>     My primary concern is game controllers (specifically gamepads).
> I'd like to see a standard game controller (something akin to the
> input functionality of the xbox 360 controller) become a first-class
> input citizen alongside the keyboard and mouse.  My argument is
> essentially that amongst the major gamepads (the ps3 6axis controller,
> the xbox 360 controller, the xbox controller, the wii classic
> controller, the ouya controller, and various OEM versions and
> imitations of the same) there is a lot of common functionality that is
> worth exposing as a standard gamepad the same way systems now expose a
> standard mouse.
> 
>     My proposed standard gamepad is:
> 
> - left stick (2d vector, each component [-1.0f .. 1.0f])
> - right stick (2d vector, each component [-1.0f .. 1.0f])
> - left trigger (1d vector, [-1.0f .. 1.0f])
> - right trigger (1d vector, [-1.0f .. 1.0f])
> - dpad
> - start button
> - system button (home on wii, ps on ps3, glowy x on xbox 360)

The "Share" button on DualShock4? 

> - four face buttons (north, south, east, west)
> - two shoulder buttons
> - two stick click buttons
> 
>     What I'd like to request at the evdev level is that things which
> are gamepads export these values in standard offsets, so that:
> 
> EV_ABS 0 == left stick x
> EV_ABS 1 == left stick y
> EV_ABS 2 == right stick x
> EV_ABS 3 == right stick y
> EV_ABS 4 == dpad x
> EV_ABS 5 == dpad y
> EV_ABS 6 == left trigger
> EV_ABS 7 == right trigger
> 
>     Or some similar defined order.  I'd like buttons to be similarly mapped:
> 
> BTN_START == start button
> BTN_WEST == xbox x, ps square
> BTN_NORTH == xbox y, ps triangle
> BTN_EAST == xbox b, ps circle
> BTN_SOUTH == xbox a, ps x
> BTN_TL == xbox tl, ps l1
> BTN_TR == xbox tr, ps r1
> BTN_MODE == xbox glowy x, ps ps
> BTN_THUMBL == stick click l
> BTN_THUMBR == stick click r
> 
>     I'm aware that the xbox and xbox 360 controllers are already
> largely mapped this way, but the ps3 controller is not, at least from
> what I can tell, and I have no other gamepad hardware to test.  My
> goal here is to make it so that something reading an evdev gamepad
> stream doesn't need to know what kind of hardware device is backing it
> *if* all the reader cares about is the standard gamepad functionality.
>

WRT the PS3 controllers the problem is the HID descriptor, it should be
rewritten to expose saner event codes, and/or a .input_mapping callback
should be added. I can give some hints about how to proceed if anyone is
up to it; it would something along the line of
drivers/hid/hid-ps3remote.c

>     The analogy here is mice; while you can get mice with variable DPI
> settings, macro engines and loads of buttons or scroll wheels, normal
> applications don't have to query the mouse type to know how the core
> functionality is mapped.  If all I want in a game is the left stick
> for movement, the bottom face button for jump and the right face
> button for shoot, I shouldn't have to be querying the controller to
> figure out how those are mapped.  I should be able to take ABS_X and
> ABS_Y for the left stick, BTN_SOUTH for jump and BTN_EAST for shoot,
> and it should map to the proper buttons and stick regardless of
> whether the player has an xbox controller, a logitech controller, a
> ps3 controller or a wiimote with a classic controller plugged in.
>

BTW have you looked at the joystick driver/API?
(Documentation/input/joystick.txt), it allows some form of remapping
and calibration to have normalized axis values across different
controllers but I don't know it that suits what you have in mind.

>     There are several advantages of doing this remapping at the driver
> level, but the most important ones from my point of view are that it
> is simplest to do near the source, and it makes supporting a standard
> gamepad as part of (for instance) Wayland a much simpler and thinner
> translation layer.  I want to do this through a Wayland (or X11) event
> protocol because I want my game (which may be running mods or scripts
> downloaded from forums) to be as isolated as possible from the
> elevated privileges that opening evdev streams requires.
> 
>     So, that's my issue, really; I'd like a standardized core gamepad
> protocol in Linux, and I'm talking to people at every level of the
> stack to see if I can make it happen.
> 
>                                        Todd.

Conventions are good, having drivers following them would be even
better ;)

Ciao,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Game Controllers

[Todd Showalter]

On Thu, May 2, 2013 at 2:35 AM, Antonio Ospite <ospite@studenti.unina.it> wrote:
> On Mon, 29 Apr 2013 20:46:47 -0400
> Todd Showalter <todd@electronjump.com> wrote:
>>
>>     My proposed standard gamepad is:
>>
>> - left stick (2d vector, each component [-1.0f .. 1.0f])
>> - right stick (2d vector, each component [-1.0f .. 1.0f])
>> - left trigger (1d vector, [-1.0f .. 1.0f])
>> - right trigger (1d vector, [-1.0f .. 1.0f])
>> - dpad
>> - start button
>> - system button (home on wii, ps on ps3, glowy x on xbox 360)
>> - four face buttons (north, south, east, west)
>> - two shoulder buttons
>> - two stick click buttons
>
> The "Share" button on DualShock4?

[reordered a bit for clarity after snipping]

    What I'm proposing is a standard gamepad that developers can
assume is mostly supported on most available hardware.  Most real
gamepads will be a superset of the proposed standard, and it would be
nice if there was some canonical set of keysyms and axis indicies for
common extended functionality, but my main concern is that if a
developer checks for BTN_SOUTH they get the button at the bottom of
the right-hand face button cluster of the gamepad, whether it's the
(x) on Sony gamepads, the (A) on Microsoft gamepads, the (b) on
Nintendo gamepads, the (o) on the Ouya gamepad, the yellow button on
the old Gravis gamepad, or whatever.

    Likewise, I want the left stick to map to the same two axis
indicies on all gamepad, and so forth.  My goal here is that *unless*
you are going to use features specific to a gamepad, you don't have to
care who made it or what specific model it is.  I want most games to
be able to say "ah, a gamepad, excellent", and just use it without
having to parse the results of calling ioctl() with EVIOCGNAME.

    So, I'd be happy if there was a keysym for SHARE, and extra axis
values for all the pressure sensitive buttons on ps4, and a keysym for
the BACK button on xbox controllers and so forth, but I wouldn't call
SHARE and BACK part of the standard gamepad because they're not yet
something that has an analog on most available hardware.  I suppose if
you conflate BACK with SELECT you could make an argument that it was
on nearly everything, but SHARE is still only a proposed button on a
gamepad for a console that hasn't shipped, and for which I presume we
don't have drivers yet.

>>     I'm aware that the xbox and xbox 360 controllers are already
>> largely mapped this way, but the ps3 controller is not, at least from
>> what I can tell, and I have no other gamepad hardware to test.  My
>> goal here is to make it so that something reading an evdev gamepad
>> stream doesn't need to know what kind of hardware device is backing it
>> *if* all the reader cares about is the standard gamepad functionality.
>
> WRT the PS3 controllers the problem is the HID descriptor, it should be
> rewritten to expose saner event codes, and/or a .input_mapping callback
> should be added. I can give some hints about how to proceed if anyone is
> up to it; it would something along the line of
> drivers/hid/hid-ps3remote.c

    That would be a great start; right now, at least on my machine,
the PS3 controller produces events that don't seem to map sanely at
all.

>>     The analogy here is mice; while you can get mice with variable DPI
>> settings, macro engines and loads of buttons or scroll wheels, normal
>> applications don't have to query the mouse type to know how the core
>> functionality is mapped.  If all I want in a game is the left stick
>> for movement, the bottom face button for jump and the right face
>> button for shoot, I shouldn't have to be querying the controller to
>> figure out how those are mapped.  I should be able to take ABS_X and
>> ABS_Y for the left stick, BTN_SOUTH for jump and BTN_EAST for shoot,
>> and it should map to the proper buttons and stick regardless of
>> whether the player has an xbox controller, a logitech controller, a
>> ps3 controller or a wiimote with a classic controller plugged in.
>>
>
> BTW have you looked at the joystick driver/API?
> (Documentation/input/joystick.txt), it allows some form of remapping
> and calibration to have normalized axis values across different
> controllers but I don't know it that suits what you have in mind.

    I've read those, and our game engine currently uses libjsw, which
is IIRC a thin wrapper around that, but it isn't really very useful in
practise.  The problem with it is that when the game discovers a
gamepad, all it knows is that it now has access to an unlabelled bag
of axis values and buttons.  There's no way (at least that I've found)
to determine *in code* how those axis and button values map onto the
hardware, so you either have to build up a database of device strings
and check them against the output of JSIOCGNAME, or you have to ask
the player to go through a gamepad setup phase.  Neither of these are
desirable.

    The player expects (quite reasonably) to be able to plug in a
gamepad and have it Just Work.

    From the game point of view, working with JSIOCGNAME is lousy,
because it means that anything that isn't in my name->mapping table is
unsupported.  If next year Microsoft releases an XBox 720 gamepad
that's all but identical to the 360 controller, and the kernel gets
support for it, our game won't know what to do with it because when we
shipped the game that gamepad wasn't in the translation table.  Or for
that matter, if the player has a MadCatz controller we've never seen
that's really just an XBox controller, but it happens to have a
different identifier string, well, fail.

    Using evdev raw has the same problem for us right now, with the
additional problem that we need dangerously elevated privileges to
access it.

    What I'm hoping for is to get a standardized gamepad coming out of
evdev in such a way that systems like Wayland and X11 can expose them
to programs through their standard event passing systems without
having to massage them unduly, and without throwing us into the same
sea of   The ultimate goal here is that if someone builds a living
room PC with Linux on it, plugs it in to their TV and plugs in a
couple of gamepads, games running on the system can access the gamepad
information as easily as they access mouse information.  No querying
vendor and device ID or identifier strings, no looking things up in
mapping tables.

    I think we're within reach of that.  I've been talking to the
Wayland folks about this, and they seem amenable to the idea.  On the
kernel side it's really just a matter of making sure all gamepads map
like so:

left stick: ABS_X, ABS_Y
right stick: ABS_RX, ABS_RY
dpad: ABS_HAT0X, ABS_HAT0Y
left trigger: ABS_Z
right trigger: ABS_RZ
start button: BTN_START
system button: BTN_SYSTEM
four face buttons: BTN_NORTH, BTN_EAST, BTN_SOUTH, BTN_WEST
two shoulder buttons: BTN_TL, BTN_TR
two stick click buttons: BTN_THUMBL, BTN_THUMBR

    Most of these values are already in <linux/input.h>, only
BTN_SYSTEM and the NSEW buttons aren't defined yet.  It's mostly just
a matter of making the gamepads adhere to the standard.

    The XBox controllers are nearly compliant already; they export
their buttons as ABXY, but other than that they already fit the
proposed model.  The PS3 controller needs to be completely remapped;
at least on my machine (for example) I get the right thumbstick mapped
to ABS_Z, ABS_RZ, and the button mappings are all over the place.  I
don't have any other gamepads I can hook to this box to test.

> Conventions are good, having drivers following them would be even
> better ;)

    Indeed. :)

                                       Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[David Herrmann]

Hi Todd

On Thu, May 2, 2013 at 3:46 PM, Todd Showalter <todd@electronjump.com> wrote:
> On Thu, May 2, 2013 at 2:35 AM, Antonio Ospite <ospite@studenti.unina.it> wrote:
>> On Mon, 29 Apr 2013 20:46:47 -0400
>> Todd Showalter <todd@electronjump.com> wrote:
>>>
>>>     My proposed standard gamepad is:
>>>
>>> - left stick (2d vector, each component [-1.0f .. 1.0f])
>>> - right stick (2d vector, each component [-1.0f .. 1.0f])
>>> - left trigger (1d vector, [-1.0f .. 1.0f])
>>> - right trigger (1d vector, [-1.0f .. 1.0f])
>>> - dpad
>>> - start button
>>> - system button (home on wii, ps on ps3, glowy x on xbox 360)
>>> - four face buttons (north, south, east, west)
>>> - two shoulder buttons
>>> - two stick click buttons
>>
>> The "Share" button on DualShock4?
>
> [reordered a bit for clarity after snipping]
>
>     What I'm proposing is a standard gamepad that developers can
> assume is mostly supported on most available hardware.  Most real
> gamepads will be a superset of the proposed standard, and it would be
> nice if there was some canonical set of keysyms and axis indicies for
> common extended functionality, but my main concern is that if a
> developer checks for BTN_SOUTH they get the button at the bottom of
> the right-hand face button cluster of the gamepad, whether it's the
> (x) on Sony gamepads, the (A) on Microsoft gamepads, the (b) on
> Nintendo gamepads, the (o) on the Ouya gamepad, the yellow button on
> the old Gravis gamepad, or whatever.
>
>     Likewise, I want the left stick to map to the same two axis
> indicies on all gamepad, and so forth.  My goal here is that *unless*
> you are going to use features specific to a gamepad, you don't have to
> care who made it or what specific model it is.  I want most games to
> be able to say "ah, a gamepad, excellent", and just use it without
> having to parse the results of calling ioctl() with EVIOCGNAME.
>
>     So, I'd be happy if there was a keysym for SHARE, and extra axis
> values for all the pressure sensitive buttons on ps4, and a keysym for
> the BACK button on xbox controllers and so forth, but I wouldn't call
> SHARE and BACK part of the standard gamepad because they're not yet
> something that has an analog on most available hardware.  I suppose if
> you conflate BACK with SELECT you could make an argument that it was
> on nearly everything, but SHARE is still only a proposed button on a
> gamepad for a console that hasn't shipped, and for which I presume we
> don't have drivers yet.
>
>>>     I'm aware that the xbox and xbox 360 controllers are already
>>> largely mapped this way, but the ps3 controller is not, at least from
>>> what I can tell, and I have no other gamepad hardware to test.  My
>>> goal here is to make it so that something reading an evdev gamepad
>>> stream doesn't need to know what kind of hardware device is backing it
>>> *if* all the reader cares about is the standard gamepad functionality.
>>
>> WRT the PS3 controllers the problem is the HID descriptor, it should be
>> rewritten to expose saner event codes, and/or a .input_mapping callback
>> should be added. I can give some hints about how to proceed if anyone is
>> up to it; it would something along the line of
>> drivers/hid/hid-ps3remote.c
>
>     That would be a great start; right now, at least on my machine,
> the PS3 controller produces events that don't seem to map sanely at
> all.
>
>>>     The analogy here is mice; while you can get mice with variable DPI
>>> settings, macro engines and loads of buttons or scroll wheels, normal
>>> applications don't have to query the mouse type to know how the core
>>> functionality is mapped.  If all I want in a game is the left stick
>>> for movement, the bottom face button for jump and the right face
>>> button for shoot, I shouldn't have to be querying the controller to
>>> figure out how those are mapped.  I should be able to take ABS_X and
>>> ABS_Y for the left stick, BTN_SOUTH for jump and BTN_EAST for shoot,
>>> and it should map to the proper buttons and stick regardless of
>>> whether the player has an xbox controller, a logitech controller, a
>>> ps3 controller or a wiimote with a classic controller plugged in.
>>>
>>
>> BTW have you looked at the joystick driver/API?
>> (Documentation/input/joystick.txt), it allows some form of remapping
>> and calibration to have normalized axis values across different
>> controllers but I don't know it that suits what you have in mind.
>
>     I've read those, and our game engine currently uses libjsw, which
> is IIRC a thin wrapper around that, but it isn't really very useful in
> practise.  The problem with it is that when the game discovers a
> gamepad, all it knows is that it now has access to an unlabelled bag
> of axis values and buttons.  There's no way (at least that I've found)
> to determine *in code* how those axis and button values map onto the
> hardware, so you either have to build up a database of device strings
> and check them against the output of JSIOCGNAME, or you have to ask
> the player to go through a gamepad setup phase.  Neither of these are
> desirable.
>
>     The player expects (quite reasonably) to be able to plug in a
> gamepad and have it Just Work.
>
>     From the game point of view, working with JSIOCGNAME is lousy,
> because it means that anything that isn't in my name->mapping table is
> unsupported.  If next year Microsoft releases an XBox 720 gamepad
> that's all but identical to the 360 controller, and the kernel gets
> support for it, our game won't know what to do with it because when we
> shipped the game that gamepad wasn't in the translation table.  Or for
> that matter, if the player has a MadCatz controller we've never seen
> that's really just an XBox controller, but it happens to have a
> different identifier string, well, fail.
>
>     Using evdev raw has the same problem for us right now, with the
> additional problem that we need dangerously elevated privileges to
> access it.
>
>     What I'm hoping for is to get a standardized gamepad coming out of
> evdev in such a way that systems like Wayland and X11 can expose them
> to programs through their standard event passing systems without
> having to massage them unduly, and without throwing us into the same
> sea of   The ultimate goal here is that if someone builds a living
> room PC with Linux on it, plugs it in to their TV and plugs in a
> couple of gamepads, games running on the system can access the gamepad
> information as easily as they access mouse information.  No querying
> vendor and device ID or identifier strings, no looking things up in
> mapping tables.
>
>     I think we're within reach of that.  I've been talking to the
> Wayland folks about this, and they seem amenable to the idea.  On the
> kernel side it's really just a matter of making sure all gamepads map
> like so:
>
> left stick: ABS_X, ABS_Y
> right stick: ABS_RX, ABS_RY
> dpad: ABS_HAT0X, ABS_HAT0Y
> left trigger: ABS_Z
> right trigger: ABS_RZ
> start button: BTN_START
> system button: BTN_SYSTEM
> four face buttons: BTN_NORTH, BTN_EAST, BTN_SOUTH, BTN_WEST
> two shoulder buttons: BTN_TL, BTN_TR
> two stick click buttons: BTN_THUMBL, BTN_THUMBR

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..)?

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...

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.

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

Re: Game Controllers

[Todd Showalter]

On Thu, May 2, 2013 at 10:09 AM, David Herrmann <dh.herrmann@gmail.com> 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.

Re: Game Controllers

[Dmitry Torokhov]

On Thu, May 02, 2013 at 11:37:48AM -0400, Todd Showalter wrote:
>     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.

No, not in the kernel please. Create a library that implements the
"standard gamepad", like we have tslib for "standard touchscreen" and
have it do the transformations.

Kernel can try doing proper mapping but userspace should examine device
and try to make most out of what it offers even if it is not exactly PS3
controller.

Thanks.

-- 
Dmitry

Re: Game Controllers

[Todd Showalter]

Webmail makes it too easy to fat-finger "send".

On Thu, May 2, 2013 at 10:09 AM, David Herrmann <dh.herrmann@gmail.com> wrote:

> 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.

    User-space mapping sucks.

    It means we can't just ship a game and have it work with new
hardware; every time someone adds a new controller to the kernel, we
have to patch the game to support it.  Or else the mapping has to
happen in a shared library, and someone has to patch that to match the
kernel.

    It means that things that should just work (like OEM 360
controllers) may well not work because EVIOCGNAME returns a string
that isn't in our table, so we don't know what to do with the data.

    I love developing on Linux; it's the lead platform for our game
engine and has been since I wrote the first line of code in 2003, but
from a game development standpoint gamepad input is one of the real
friction points on the platform.  As a game developer, I don't want a
universe of possible controllers each subtly different from the other.
 I want the player to be able to plug in a gamepad and know that if
they push the bottom face button on the right hand side of the pad,
their character will jump.  If they plug in a racing wheel or a
wiimote plugged into a balance board, I'm ignoring it and giving them
keyboard controls.

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

                                       Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[Dmitry Torokhov]

On Thu, May 02, 2013 at 11:58:08AM -0400, Todd Showalter wrote:
> Webmail makes it too easy to fat-finger "send".
> 
> On Thu, May 2, 2013 at 10:09 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> 
> > 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.
> 
>     User-space mapping sucks.
> 
>     It means we can't just ship a game and have it work with new
> hardware; every time someone adds a new controller to the kernel, we
> have to patch the game to support it.  Or else the mapping has to
> happen in a shared library, and someone has to patch that to match the
> kernel.
> 
>     It means that things that should just work (like OEM 360
> controllers) may well not work because EVIOCGNAME returns a string
> that isn't in our table, so we don't know what to do with the data.

I agree here, mapping sucks. But sometimes it is necessary.

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.

> 
>     I love developing on Linux; it's the lead platform for our game
> engine and has been since I wrote the first line of code in 2003, but
> from a game development standpoint gamepad input is one of the real
> friction points on the platform.  As a game developer, I don't want a
> universe of possible controllers each subtly different from the other.
>  I want the player to be able to plug in a gamepad and know that if
> they push the bottom face button on the right hand side of the pad,
> their character will jump.  If they plug in a racing wheel or a
> wiimote plugged into a balance board, I'm ignoring it and giving them
> keyboard controls.
> 
>     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.

-- 
Dmitry

Re: Game Controllers

[Todd Showalter]

On Thu, May 2, 2013 at 12:38 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> 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

- 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

- 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

    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.

                                       Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[Dmitry Torokhov]

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@gmail.com> 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

Re: Game Controllers

[Todd Showalter]

On Thu, May 2, 2013 at 2:29 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

>> - 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.

    I think calibration, dead-zones, easing, button remapping and the
like are a totally orthogonal problem.  They are nice to have, but
that's the kind of thing that belongs in a desktop environment's
accessibility settings, not at the input protocol level.

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

    If we can have that, at least, it means the problem is eventually
fixed.  Maybe not for years, but at least someday.

> 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?

    The kernel is the core of the system; Linux isn't Linux without
the Linux kernel.  If I make a game input library and try to get
people to use it, there's a whole chicken-and-egg problem of getting
developers to support something nobody has installed, and getting
users to install something no developers support.  I have to convince
the distros to pick it up, and to keep updating it.  I have to monitor
changes in the kernel codebase to see if the library needs updating.
I have to deal with the possibility that the library becomes a useful
bandaid, with people saying "meh, this is a hard problem, punt the fix
to the library".  I have to hope that telling players to install
another dependency isn't going to lose me customers.

    The kernel has authority that a library does not, and it has a
distribution mechanism that a library does not.  The kernel is
effectively the source of the data; all I can do outside of that is
provide a filter and hope people use it.

                                      Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[Dmitry Torokhov]

On Thu, May 02, 2013 at 03:54:45PM -0400, Todd Showalter wrote:
> On Thu, May 2, 2013 at 2:29 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> 
> >> - 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.
> 
>     I think calibration, dead-zones, easing, button remapping and the
> like are a totally orthogonal problem.  They are nice to have, but
> that's the kind of thing that belongs in a desktop environment's
> accessibility settings, not at the input protocol level.
> 
> > There also should not be lag if new devices follow the agreed upon
> > mapping.
> 
>     If we can have that, at least, it means the problem is eventually
> fixed.  Maybe not for years, but at least someday.
> 
> > 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?
> 
>     The kernel is the core of the system; Linux isn't Linux without
> the Linux kernel.  If I make a game input library and try to get
> people to use it, there's a whole chicken-and-egg problem of getting
> developers to support something nobody has installed, and getting
> users to install something no developers support.  I have to convince
> the distros to pick it up, and to keep updating it.  I have to monitor
> changes in the kernel codebase to see if the library needs updating.
> I have to deal with the possibility that the library becomes a useful
> bandaid, with people saying "meh, this is a hard problem, punt the fix
> to the library".  I have to hope that telling players to install
> another dependency isn't going to lose me customers.

Until you get a traction with the new you might need to distribute it
with your game. Another option would be to extend already established
library, such as SDL, with the required functionality.

> 
>     The kernel has authority that a library does not, and it has a
> distribution mechanism that a library does not.  The kernel is
> effectively the source of the data; all I can do outside of that is
> provide a filter and hope people use it.

No, I do not think so. Kernel provides a level of abstraction, but so
does X, ALSA, given desktop environment and so forth. If a task does not
require hardware access (and translating input events form one type to
another does not) one should think really hard whether it should be
done in kernel.

Thanks.

-- 
Dmitry

Re: Game Controllers

[Todd Showalter]

On Thu, May 2, 2013 at 4:18 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

> No, I do not think so. Kernel provides a level of abstraction, but so
> does X, ALSA, given desktop environment and so forth. If a task does not
> require hardware access (and translating input events form one type to
> another does not) one should think really hard whether it should be
> done in kernel.

    What's the scope of acceptable changes in-kernel?  I'd like to fix
as much of this as possible in the kernel; if the rest has to happen
in a library, so be it.

    Would you be open to considering some sort of ioctl() that exports
a mapping table?  The PS3 controller mappings are completely wonky,
and even the xbox and xbox 360 controllers are less than ideal.  If we
could pull a mapping table out of the dev node at least it would let
us fix the common cases.

                                      Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[Dmitry Torokhov]

On Thursday, May 02, 2013 04:30:01 PM Todd Showalter wrote:
> On Thu, May 2, 2013 at 4:18 PM, Dmitry Torokhov
> 
> <dmitry.torokhov@gmail.com> wrote:
> > No, I do not think so. Kernel provides a level of abstraction, but so
> > does X, ALSA, given desktop environment and so forth. If a task does not
> > require hardware access (and translating input events form one type to
> > another does not) one should think really hard whether it should be
> > done in kernel.
> 
>     What's the scope of acceptable changes in-kernel?  I'd like to fix
> as much of this as possible in the kernel; if the rest has to happen
> in a library, so be it.
> 
>     Would you be open to considering some sort of ioctl() that exports
> a mapping table?  The PS3 controller mappings are completely wonky,
> and even the xbox and xbox 360 controllers are less than ideal.  If we
> could pull a mapping table out of the dev node at least it would let
> us fix the common cases.

What information does kernel have in this case than userspace does not? Having 
a static table compiled in kernel and available via ioctl and having the same 
data in a file on disk is no different, with the exception that data on disk 
does not take kernel memory and user can much more easily "play" with it.

I am pretty sure it should be also much more easy to have a distribution pick 
up a new mapping than to convince them to take a kernel patch.

Thanks.

-- 
Dmitry

Re: Game Controllers

[Dmitry Torokhov]

On Thu, May 02, 2013 at 09:46:44AM -0400, Todd Showalter wrote:
> 
> left stick: ABS_X, ABS_Y
> right stick: ABS_RX, ABS_RY

Not sure about this one. Originally RX, RY and RZ were introduces for
device having more than 3 degress of freedom; and RX is used by many
joystick devices. We'd ether need a property bit to distinguish gamepad
from a joystick or simply ass ABS_X2, ABS_Y2 etc for the second stick.

> dpad: ABS_HAT0X, ABS_HAT0Y
> left trigger: ABS_Z

Huh?

> right trigger: ABS_RZ

Not at all. These are not absolute events but rather buttons, so let's
define them as such.

> start button: BTN_START
> system button: BTN_SYSTEM
> four face buttons: BTN_NORTH, BTN_EAST, BTN_SOUTH, BTN_WEST
> two shoulder buttons: BTN_TL, BTN_TR
> two stick click buttons: BTN_THUMBL, BTN_THUMBR

Thanks.

-- 
Dmitry

Re: Game Controllers

[Todd Showalter]

On Thu, May 2, 2013 at 1:01 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, May 02, 2013 at 09:46:44AM -0400, Todd Showalter wrote:
>>
>> left stick: ABS_X, ABS_Y
>> right stick: ABS_RX, ABS_RY
>
> Not sure about this one. Originally RX, RY and RZ were introduces for
> device having more than 3 degress of freedom; and RX is used by many
> joystick devices. We'd ether need a property bit to distinguish gamepad
> from a joystick or simply ass ABS_X2, ABS_Y2 etc for the second stick.

    I'd be happy to have ABS_LX, ABS_LY and ABS_RX, ABS_RY, I was just
looking at what was available in input.h and what the xbox pads were
already doing.  Likewise, mapping the dpad as HAT0X, HAT0Y is a little
wierd and ABS_DX, ABS_DY would probably be better.

>> dpad: ABS_HAT0X, ABS_HAT0Y
>> left trigger: ABS_Z
>
> Huh?
>
>> right trigger: ABS_RZ
>
> Not at all. These are not absolute events but rather buttons, so let's
> define them as such.

    Most game controllers these days (including ps3 and xbox/xbox 360)
have analog shoulder triggers.  On Microsoft, LT and RT are analog
(0..255) and LB and RB are digital.  On ps3, L1, L2, R1 and R2 are
actually pressure sensitive and are exported both as analog (0..255)
and digital; I figured we'd treat LR1 as digital, LR2 as analog.  The
Wii Classic controller has L and R analog, ZL and ZR digital, though
IIRC the Classic Pro controller has L and R as digital.

    Here's a complete mapping for some well known controllers:

left stick
  - ps3, xbox, xbox360, wiiclassic, ouya -- left stick

right stick
  - ps3, xbox, xbox360, wiiclassic, ouya -- right stick

dpad
  - ps3, xbox, xbox360, wiiclassic, ouya -- dpad

shoulder analog triggers
  - ps3 -- L2, R2, use pressure values
  - xbox, xbox360 -- LT, RT
  - wiiclassic -- L, R
  - ouya -- unsure what they're called, but it has them

shoulder digital buttons
  - ps3 -- L1, R1
  - xbox, xbox360 -- LB, RB
  - wiiclassic -- ZL, ZR
  - ouya -- unsure what they're called, but it has them

face buttons (NORTH, EAST, SOUTH, WEST)
  - ps3 -- triangle, circle, x, square
  - xbox, xbox360 -- Y, B, A, X
  - wiiclassic -- x, a, b, y
  - ouya -- Y, A, O, U

stick buttons
  - ps3, xbox, xbox360, wiiclassic -- left stick click, right stick click
  - ouya -- unsure if this is supported,

start button
  - ps3, xbox, xbox360, wiiclassic -- start
  - ouya -- not present, developers are asking for one

system button
  - ps3 -- playstation logo button
  - xbox -- not available
  - xbox360 -- glowy x button
  - ouya -- system (U) button

select button -- arguable
  - ps3, wiiclassic -- select
  - xbox, xbox360 -- back
  - ouya -- not present, developers are asking for one

                                      Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[David Herrmann]

Hi Todd

On Thu, May 2, 2013 at 7:35 PM, Todd Showalter <todd@electronjump.com> wrote:
> On Thu, May 2, 2013 at 1:01 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Thu, May 02, 2013 at 09:46:44AM -0400, Todd Showalter wrote:
>>>
>>> left stick: ABS_X, ABS_Y
>>> right stick: ABS_RX, ABS_RY
>>
>> Not sure about this one. Originally RX, RY and RZ were introduces for
>> device having more than 3 degress of freedom; and RX is used by many
>> joystick devices. We'd ether need a property bit to distinguish gamepad
>> from a joystick or simply ass ABS_X2, ABS_Y2 etc for the second stick.
>
>     I'd be happy to have ABS_LX, ABS_LY and ABS_RX, ABS_RY, I was just
> looking at what was available in input.h and what the xbox pads were
> already doing.  Likewise, mapping the dpad as HAT0X, HAT0Y is a little
> wierd and ABS_DX, ABS_DY would probably be better.
>
>>> dpad: ABS_HAT0X, ABS_HAT0Y
>>> left trigger: ABS_Z
>>
>> Huh?
>>
>>> right trigger: ABS_RZ
>>
>> Not at all. These are not absolute events but rather buttons, so let's
>> define them as such.
>
>     Most game controllers these days (including ps3 and xbox/xbox 360)
> have analog shoulder triggers.  On Microsoft, LT and RT are analog
> (0..255) and LB and RB are digital.  On ps3, L1, L2, R1 and R2 are
> actually pressure sensitive and are exported both as analog (0..255)
> and digital; I figured we'd treat LR1 as digital, LR2 as analog.  The
> Wii Classic controller has L and R analog, ZL and ZR digital, though
> IIRC the Classic Pro controller has L and R as digital.
>
>     Here's a complete mapping for some well known controllers:
>
> left stick
>   - ps3, xbox, xbox360, wiiclassic, ouya -- left stick
>
> right stick
>   - ps3, xbox, xbox360, wiiclassic, ouya -- right stick
>
> dpad
>   - ps3, xbox, xbox360, wiiclassic, ouya -- dpad
>
> shoulder analog triggers
>   - ps3 -- L2, R2, use pressure values
>   - xbox, xbox360 -- LT, RT
>   - wiiclassic -- L, R
>   - ouya -- unsure what they're called, but it has them
>
> shoulder digital buttons
>   - ps3 -- L1, R1
>   - xbox, xbox360 -- LB, RB
>   - wiiclassic -- ZL, ZR
>   - ouya -- unsure what they're called, but it has them
>
> face buttons (NORTH, EAST, SOUTH, WEST)
>   - ps3 -- triangle, circle, x, square
>   - xbox, xbox360 -- Y, B, A, X
>   - wiiclassic -- x, a, b, y
>   - ouya -- Y, A, O, U
>
> stick buttons
>   - ps3, xbox, xbox360, wiiclassic -- left stick click, right stick click
>   - ouya -- unsure if this is supported,
>
> start button
>   - ps3, xbox, xbox360, wiiclassic -- start
>   - ouya -- not present, developers are asking for one
>
> system button
>   - ps3 -- playstation logo button
>   - xbox -- not available
>   - xbox360 -- glowy x button
>   - ouya -- system (U) button
>
> select button -- arguable
>   - ps3, wiiclassic -- select
>   - xbox, xbox360 -- back
>   - ouya -- not present, developers are asking for one
>
>                                       Todd.

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).

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.
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.

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.
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.
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 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.

Cheers
David

Re: Game Controllers

[Todd Showalter]

On Thu, May 2, 2013 at 1:54 PM, David Herrmann <dh.herrmann@gmail.com> 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.

Re: Game Controllers

[Dmitry Torokhov]

On Thu, May 02, 2013 at 03:10:55PM -0400, Todd Showalter wrote:
> On Thu, May 2, 2013 at 1:54 PM, David Herrmann <dh.herrmann@gmail.com> 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).

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.
> 
> > 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.

> 
> > 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.

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

> 
> > 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?

> 
> > 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.

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

Re: Game Controllers

[Todd Showalter]

On Thu, May 2, 2013 at 4:45 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

>>     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.

    No, I'm arguing the opposite.  I want a canonical mapping for
standard controllers.  Anything that wants more than that can deal
with having to understand specific devices.  What I'm saying is that a
vanishingly small number of games actually care about more than the
standard gamepad.

> 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?

    "Make sure you're running the latest kernel." beats the hell out
of "Make sure you've installed the latest FixLegacyGamepads package.
If your distro doesn't support FixLegacyGamepads or has a version
older than 1.2.62104, you'll need to install git...".

> 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.

    Ok.  I can see there's no point arguing this.  What can I do to at
least make sure future devices behave?  Is there anything that can be
done about current devices other than translate in userspace?

                                       Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[Dmitry Torokhov]

On Thu, May 02, 2013 at 05:10:42PM -0400, Todd Showalter wrote:
> On Thu, May 2, 2013 at 4:45 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> 
> > 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.
> 
>     Ok.  I can see there's no point arguing this.  What can I do to at
> least make sure future devices behave?  Is there anything that can be
> done about current devices other than translate in userspace?

Please post the patches for discussion and keep en eye on changes going
into drivers/input/joystick and drivers/hid as you have a vested
interest of everyone getting it right.

I am not sure about status of PS3 controller, I think Bastien was
working on supporting it from userspace?

-- 
Dmitry

Re: Game Controllers

[Bastien Nocera]

Em Fri, 2013-05-03 às 08:50 -0700, Dmitry Torokhov escreveu:
> On Thu, May 02, 2013 at 05:10:42PM -0400, Todd Showalter wrote:
> > On Thu, May 2, 2013 at 4:45 PM, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > 
> > > 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.
> > 
> >     Ok.  I can see there's no point arguing this.  What can I do to at
> > least make sure future devices behave?  Is there anything that can be
> > done about current devices other than translate in userspace?
> 
> Please post the patches for discussion and keep en eye on changes going
> into drivers/input/joystick and drivers/hid as you have a vested
> interest of everyone getting it right.
> 
> I am not sure about status of PS3 controller, I think Bastien was
> working on supporting it from userspace?

Antonio Ospite has patches against bluez5 to make it work[1], though
some more work is definitely needed. Benjamin Tissoires has a test
device now, so between them, they should be able to get it running
again.

Cheers

[1]: http://pkgs.fedoraproject.org/cgit/bluez.git/tree/playstation-peripheral-pugin-v5.x.patch

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Game Controllers

[Simon Farnsworth]

On Thursday 2 May 2013 15:10:55 Todd Showalter wrote:
>     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.
> 
Could you consider a gamepad equivalent of libv4l2 (source found in 
http://git.linuxtv.org/v4l-utils.git/tree/HEAD:/lib )?

The idea here is a shared library that can be used in two ways:

 * As an LD_PRELOAD library, for applications that have been designed around a 
standard device. When used as an LD_PRELOAD, it intercepts 
open()/ioctl()/close() etc; it passes them through if you're opening something 
that isn't a V4L2 device, and uses its internal functionality to emulate 
standard devices atop whatever you've actually got (e.g. doing colour space 
conversion).

 * As a genuine shared library, using v4l2_open, v4l2_ioctl etc when working 
with V4L2 devices. This is a mechanical change to an existing codebase, as the 
functions provided by libv4l2 behave the same way as the kernel functions do, 
but add extra functionality like colourspace conversion.

A gamepad version would intercept opens of /dev/input/event* nodes, and if 
that node was a gamepad, do the remapping from gamepad-specific events to the 
standard gamepad events. You can then use this with unmodified apps as an 
LD_PRELOAD, or with modified apps as a shared library that only gets in the way 
if the app is accessing a gamepad.
-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com

Re: Game Controllers

[Todd Showalter]

On Fri, May 3, 2013 at 6:29 AM, Simon Farnsworth
<simon.farnsworth@onelan.com> wrote:

> Could you consider a gamepad equivalent of libv4l2 (source found in
> http://git.linuxtv.org/v4l-utils.git/tree/HEAD:/lib )?

[8<]

> A gamepad version would intercept opens of /dev/input/event* nodes, and if
> that node was a gamepad, do the remapping from gamepad-specific events to the
> standard gamepad events. You can then use this with unmodified apps as an
> LD_PRELOAD, or with modified apps as a shared library that only gets in the way
> if the app is accessing a gamepad.

    The problem here is that this really shouldn't be a shared library
if it's going to be accessed directly by (say) games.  Unless there's
something I'm missing, accessing /dev/input/event* requires elevated
privileges, and the idea that all games will run as root kind of
terrifies me.  The only way it makes sense is either:

- as a library for the X11 or Wayland server, in which case it might a
well be a static library

- as a server delivering events over AF_UNIX or AF_INET sockets

    If non-root clients are going to want to talk to this, it needs to
be mediated by something.  Unless there's some ELF trickery I don't
know about, that means passing through some sort of RPC mechanism,
whether it's X11, Wayland or the network stack.

    I suppose there's d-bus, but I'm reluctant to involve xml parsing
in anything with performance requirements.

    I've got a prototype server now, actually; it isn't binding an
address yet, but it should be shortly.  It basically throws an inotify
watch on /dev/input and maintains a list of active devices that it
understands, with open file descriptors.  The next stage is to get it
binding a port on localhost and dumping appropriately rewritten events
via udp.  It'd be nice to use SOCK_SEQPACKET, but does anyone other
than me actually build their kernel with sctp support?

    The way I'm currently planning this is essentially in two parts; a
static library that deals with slurping and massaging data from evdev,
and a server built with it that spews the results out in a udp torrent
to whoever is listening.  The hope would be that your graphical
library of choice (X11, Wayland...) builds against the static lib and
delivers the messages through its own standardized RPC mechanism.  In
the mean time, the server is there partly as a testbed and partly so
that you don't have to run your game as root to get a gamepad.

                                        Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[Dmitry Torokhov]

On Fri, May 03, 2013 at 08:57:12AM -0400, Todd Showalter wrote:
> On Fri, May 3, 2013 at 6:29 AM, Simon Farnsworth
> <simon.farnsworth@onelan.com> wrote:
> 
> > Could you consider a gamepad equivalent of libv4l2 (source found in
> > http://git.linuxtv.org/v4l-utils.git/tree/HEAD:/lib )?
> 
> [8<]
> 
> > A gamepad version would intercept opens of /dev/input/event* nodes, and if
> > that node was a gamepad, do the remapping from gamepad-specific events to the
> > standard gamepad events. You can then use this with unmodified apps as an
> > LD_PRELOAD, or with modified apps as a shared library that only gets in the way
> > if the app is accessing a gamepad.
> 
>     The problem here is that this really shouldn't be a shared library
> if it's going to be accessed directly by (say) games.  Unless there's
> something I'm missing, accessing /dev/input/event* requires elevated
> privileges, and the idea that all games will run as root kind of
> terrifies me.

Actually not all input devices have to be accessible to root only. We
definitely need this for now for keyboards (since we do not have
revoke() yet) so that one user would not snoop another users keystrokes,
but I think we could relax the restriction for certain devices such as:

"A device that emits ABS_X and ABS_Y events and button events in
BTN_JOYSTICK - BTN_GAMEPAD ranges and no other key events can be considered
a gamepad or joystick device and should be available for read/write by
the current console owner".

You may want to talk to ConsoleKit/systemd folks and see if they are
willing to consider this.

Thanks.

-- 
Dmitry

Re: Game Controllers

[Todd Showalter]

On Fri, May 3, 2013 at 12:01 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

> Actually not all input devices have to be accessible to root only. We
> definitely need this for now for keyboards (since we do not have
> revoke() yet) so that one user would not snoop another users keystrokes,
> but I think we could relax the restriction for certain devices such as:
>
> "A device that emits ABS_X and ABS_Y events and button events in
> BTN_JOYSTICK - BTN_GAMEPAD ranges and no other key events can be considered
> a gamepad or joystick device and should be available for read/write by
> the current console owner".

    I don't have the device to actually test this, but:

http://www.slipperybrick.com/2007/04/xbox-360-keyboard-controller/
http://www.itechnews.net/wp-content/uploads/2008/08/sony-ps3-wireless-keypad-1.jpg

    Depending on whether that gets exposed as a separate device or
part of the xbox gamepad, you may have cases where plugging the
keyboard in means you need root access to read the gamepad, unplugging
it means you don't, which is a little counterintuitive for users.

    I would hope the keyboard would just turn up as a separate device,
since IIRC the pad is actually a hub, but it's a potential
complication if that isn't the case.

    Single-seat is really the norm for people playing games, and I
thought ConsoleKit was fading and systemd still controversial, so I
think I'll put that on my list of future mountains to move rather than
current mountains.  :)

                                      Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[Ignaz Forster]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Todd Showalter schrieb am 30.04.2013 02:46 Uhr:
>     What I'd like to request at the evdev level is that things which
> are gamepads export these values in standard offsets, so that:
> 
> EV_ABS 0 == left stick x
> EV_ABS 1 == left stick y
> EV_ABS 2 == right stick x
> EV_ABS 3 == right stick y
> EV_ABS 4 == dpad x
> EV_ABS 5 == dpad y
> EV_ABS 6 == left trigger
> EV_ABS 7 == right trigger
> 
>     Or some similar defined order.  I'd like buttons to be similarly mapped:
> 
> BTN_START == start button
> BTN_WEST == xbox x, ps square
> BTN_NORTH == xbox y, ps triangle
> BTN_EAST == xbox b, ps circle
> BTN_SOUTH == xbox a, ps x

I don't think this will work as you expect it.

Let's take my own gamepad adapter for example: You can connect PlayStation, Dreamcast and GameCube controllers to it. The Dreamcast controller has the A button on the bottom and the B button on the right side, the GameCube controller has the A button in the middle and the B button on the lower left side:

          | A      | B          | X     | Y
- ----------+--------+------------+-------+-----
Dreamcast | bottom | right      | left  | top
- ----------+--------+------------+-------+-----
GameCube  | middle | lower left | right | top

In any case the A button is reported as the first button, the B button as the second one etc.
Now the question is: Which button is BTN_WEST? You cannot tell, as it depends on what controller is connected.

This may be a special case, but there are probably other controllers with "weird" button layouts out there (e.g. 6 button pads, the SNES pad, ...); moreover you don't have the guaranty that every gamepad has all the buttons you expect.
To make it usable "out of the box" you would have to limit the interface to gamepads with a certain layout, but this will probably break if any of the major manufacturers decides to develop a new gamepad layout. Those "features specific to a gamepad" you are mentioning in another mail are probably everything that a gamepad has, as you can never be sure about it's layout ;-)


While I totally agree that the situation is not ideal there is probably nothing to do about it. Using a default layout which fits for most controllers (these days probably the Xbox 360 controller layout) and offering some kind of ingame mapping to adjust it for non-standard controllers should be the way to go. You will have to offer an ingame remapping option anyway if you don't want to force your users to use your button mapping even if they may prefer another one.


Ignaz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlGENCoACgkQ/2+SjQTlQJnbVwCfVVGZcuESUNv9V+UDcLikGJtC
RUYAmwcYvb7Ngjo0fSNkrhXoeA4hXKWj
=dH7P
-----END PGP SIGNATURE-----

Re: Game Controllers

[Todd Showalter]

On Fri, May 3, 2013 at 6:03 PM, Ignaz Forster <ignaz.forster@gmx.de> wrote:

> I don't think this will work as you expect it.
>
> Let's take my own gamepad adapter for example: You can connect PlayStation, Dreamcast and GameCube controllers to it. The Dreamcast controller has the A button on the bottom and the B button on the right side, the GameCube controller has the A button in the middle and the B button on the lower left side:
>
>           | A      | B          | X     | Y
> - ----------+--------+------------+-------+-----
> Dreamcast | bottom | right      | left  | top
> - ----------+--------+------------+-------+-----
> GameCube  | middle | lower left | right | top
>
> In any case the A button is reported as the first button, the B button as the second one etc.
> Now the question is: Which button is BTN_WEST? You cannot tell, as it depends on what controller is connected.

    Correct,  What you're missing here is that as a game developer I
don't *care* what the labels are on the buttons or how those buttons
set bits on the wire, I care how they're laid out on the pad.  I want
BTN_EAST to be generated by:

- B on the dreamcast controller
- Circle on ps/ps2/ps3 controllers
- B on xbox and xbox 360 controllers
- A on snes, n64, gamecube, wii classic and wii classic pro controllers
- A on ouya controllers
- green on gravis gamepad

    All of these controllers have a four button layout under the
player's right thumb, with the buttons laid out at the compass points.
For all of them, the SOUTH and EAST buttons are the easy ones to
reach, and the NORTH and WEST are reachable but take slightly more
effort.

    The gamecube controller is a slight anomaly in that it distorts
the layout, but seen in the context of the history of Nintendo
controllers it's obvious which button should be which.  Every Nintendo
gamepad from the snes forward has had a cluster of four face buttons
that are (clockwise from the top) x, a, b, y.

    Yes, there are some pads that don't map perfectly; the Dreamcast
controller has no right stick.  The gamecube controller has two
shoulder triggers but only one shoulder button, no select button and
no system button.  Those controllers just won't export those events.

    The problem I'm trying to fix here is that at least for game
controllers the data coming out of evdev requrires a priori knowledge
about the controller plugged in, exactly as you say.  And that's
horrible from a game development point of view.  As a game developer,
I want to be able to say "BTN_SOUTH is shoot", and know that button
will be in more or less the same place on every reasonable gamepad.
Yes, this requires remapping to happen somewhere.

    Right now, to make games on Linux that use a gamepad, I have to
manually remap every controller, and as far as I know nobody has a
database of *how* that remapping has to be done.  Have you seen the
events a ps3 controller dumps?  The right stick is ABS_Z for the x
axis, ABS_RZ for the Y axis.  It spits out a massive stream of MT
events that I can only assume are mislabelled accelerometer data.  And
that's a controller I can expect a lot of players to have.

    My only recourse is to ship a game with support for all the
controllers I can find, and then wait for bug reports from angry
customers.

    I want a standard that all gamepads conform to when reporting
data.  Anything else is madness.  There can be dispute about where
that standard is applied; whether it should be in-kernel or whether it
should be in some middle layer between the kernel and the world, but
without that standard mapping the data as currently reported is
essentially useless for non-toy projects.

    There will be exception cases with hardware.  If someone plugs in
a racing wheel or a DDR pad and tries to play a gamepad-based game,
they get what they get (which will hopefully be some controls working
but no incorrect control mappings).  But for the standard case, where
they've got something resembling a standard gamepad (basically any
gamepad from the past three or four console generations, plus PC
gamepads) they'll get a standard mapping that can be explained with a
simple diagram.

> This may be a special case, but there are probably other controllers with "weird" button layouts out there (e.g. 6 button pads, the SNES pad, ...); moreover you don't have the guaranty that every gamepad has all the buttons you expect.

    A controller can export the parts of the spec it can cover.  Any
functionality beyond the standard controller can be exported as well,
and it would be nice if there was some sort of spec for that, but
that's not what I'm concerned with.  What I'm concerned with is the
standard gamepad case, which covers (a) the use cases of nearly all
games, and (b) the hardware that most people actually have.

    I've got a mouse that has only two buttons and no scroll wheel.
If I plug it in, it still works as a mouse, I just don't get a scroll
wheel or a middle button.

    Razer makes a crazy 17 button MMO mouse with controllable DPI and
controllable color lighting.  It works as a mouse too; maybe I don't
get access to all the buttons, and maybe I can't control the DPI or
the colors through the standard mechanism, but the parts that are
supported work as expected.

    I want the same for gamepads.  I want to know as a game developer
that if I follow the protocol then I'll get sane results on sane
hardware.  Most users have sane hardware, so it covers most real-world
use nicely.

> To make it usable "out of the box" you would have to limit the interface to gamepads with a certain layout, but this will probably break if any of the major manufacturers decides to develop a new gamepad layout. Those "features specific to a gamepad" you are mentioning in another mail are probably everything that a gamepad has, as you can never be sure about it's layout ;-)

    Likewise, why build roads when someone might make a flying car
some day?  Sure, lots of people have cars and bikes and things *now*,
but...

    Sure, five years from now we may be in a place where every gamepad
has a touchpad on the back (like the vita), maybe the C and Z buttons
come back, maybe accelerometers become more widespread.  If that
happens, then maybe we talk about extending the spec to cover the new
functionality.

    But right now we have a consensus amongst the platform
manufacturers about what constitutes a standard gamepad, and that
consensus has been pretty consistent for quite a while.  There are a
hell of a lot of gamepads out there that can be fit into the model I'm
proposing without breaking the conceptual model.  Remapping those
parts to a standard layout doesn't break anything else, either; if
something wants to use the full suite of sensors and buttons on the
ps3 controller, or some crazy future controller, it's all still there,
just mapped beyond the range of the standard events.

> While I totally agree that the situation is not ideal there is probably nothing to do about it. Using a default layout which fits for most controllers (these days probably the Xbox 360 controller layout) and offering some kind of ingame mapping to adjust it for non-standard controllers should be the way to go. You will have to offer an ingame remapping option anyway if you don't want to force your users to use your button mapping even if they may prefer another one.

    There is an easy fix.  Use a standard mapping where it applies and
where possible.  That fixes tons of stuff here in reality where we
actually live, without breaking anything.  Yes, games should in theory
allow remapping the controls, but it shouldn't have to be something
every player has to do in order to render the gamepad functional at
all.  Expecting the developer to own a large cross-section of gamepad
hardware so they can expose sane mappings is unreasonable.

    Would you find it acceptable (as a developer OR a user) if every
time you started a new program for the first time it brought up a
screen to configure your keyboard and mouse?

                                      Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.

Re: Game Controllers

[Ray Dillinger]

On 04/26/2013 05:13 PM, Todd Showalter wrote:
>      I'm a game developer, and I'm interested in discussing changes in
> the way gamepad input is handled at the evdev and device level; is
> this the correct place to do that?
>
>                                         Todd.
>
> --
>   Todd Showalter, President,
>   Electron Jump Games, Inc.
> --

I sure hope so.  That's why I'm here too, but I still haven't seen any
detailed discussion of it yet.  I have a keyboard with builtin gamepad
that registers as a different USB device, and I'm trying to figure out
how to write a driver that treats the gamepad as being logically a part
of the keyboard so I can use Autokey to record and play back macros.

Autokey does everything that gamepad software usually does, so it's 
ideal for the purpose -- but as far as I can tell, it cannot be made
to "see" something that isn't the same USB device as the keyboard.

				Ray