On Wed, May 22, 2013 at 8:10 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote:
> I think the kernel provides a pretty nice FF interface. It even
> provides emulations for the different kinds of FF if not all are
> supported by hardware. Anyway, that's beyond the scope of this
> definition and mostly belongs to joysticks. Gamepads normally only
> have rumble-motors, don't they?
From an end-use point of view, (at least on casual reading, which
is as much as I can claim to have done at this point), the problem
with the force feedback API is that you find out what something is by
enumerating its capabilities, but the capabilities aren't specific
enough.
Let's say I have a controller with two rotary motors. I can
examine the FF caps and see that there are two motors, and possibly
even infer a little about them, but I don't think I can tell what
direction they are mounted in and how strong they are.
There were some games on the PS2/PS3 that did some clever tricks
with force feedback; subtle stuff like making the controller fake a
gentle heartbeat that got faster and more uneven the more hurt your
character got, or gave feedback in time to the soundtrack. To do that
really effectively, you need to understand the power, positioning,
response speed and orientation of the force feedback device. Without
that complex understanding all you can really do is buzz or thump in a
fairly generic way.
> I wanted to have BTN_NORTH/A/GAMEPAD mapped for all gamepads, but
> you're right, the commercial systems use SOUTH/EAST for all trivial
> operations. I will change this and see whether we can get another key
> that is always mapped (probably BTN_SOUTH? and make this an alias for
> BTN_GAMEPAD).
Sounds good.
> I changed the menu-pad definition a little bit. 1-button PADs map to
> BTN_START, 2-button pads to START and SELECT. BTN_MODE is no longer
> mapped as 3rd button but instead is a special button to acknowledge
> the fact that it is mostly some fancy branded button that isn't mapped
> by applications.
> So the menu-pad no longer _has_ to be in the middle, but I still map
> the right button to START and the left to SELECT to keep the "map by
> position, not by label" definition.
Ok.
>> I'd prefer if things were mapped to a pair of digital buttons and
>> a pair of analog linear pot triggers for the shoulders; that covers a
>> lot of existing hardware (the xbox series gamepads, wii classic
>> gamepad, and playstation series gamepad can all be made to fit this
>> model without undue violence).
>
> Ugh? I don't understand what you mean here.
If you look at (for example) the XBox 360 controller, it has two
digital shoulder buttons (LB and RB, IIRC) and two analog shoulder
triggers (LT and RT). The Wii Classic controller has the same; L and
R are analog, ZL and ZR are digital. The PS series controllers have
four pressure sensitive buttons (L1, L2, R1, R2) which can be digital
or analog depending on whether you read the button bit or the pressure
sensor byte. Other controllers all map onto this model reasonably
well.
It's not ideal, but it's a fairly close.
> Thanks a lot! Unfortunately, I don't have all hardware at home so I
> can only test the Nintendo devices. However, I am trying to assemble a
> list of supported gamepads and how they are mapped. This will give us
> a better overview and we can see whether this definition actually
> makes sense.
I've an original XBox S controller (with a Lik Sang USB adapter),
an XBox 360 wired controller (Microsoft-branded), a PS3 controller
(Sony-branded, but has to be plugged in since I don't have bluetooth),
and can probably dig up my gamecube/ps2/dreamcast USB adapter if given
time.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
