Got a Linux PC? Good. Got a PS3? Okay. Take one of your PS3 controllers and plug it into your Linux PC. It'll be instantly recognized, initialized, and show up as a normal joystick just like a normal PC gamepad. Press the PS controller (quirk in the hardware). Now run SDLMAME. Can't get it to work? Neither can I.

[*] Pressing Escape at any controls mapping screen -> Segmentation Fault (only when the PS3 controller is present)
[*] Random buttons appear to the game as being held down, even if the controller isn't mapped to anything for the current game. Some turn on and off with certain button presses, others just stay on.

My controller is brand new, just got it from Best Buy today. jstest shows perfectly normal behavior. I think the problem is an overflow somewhere resulting from finding a joystick with 27 axes and 18 buttons.

Use the -sixaxis switch.

That fixes the random buttons, but the segfault still happens (it also segfaults if you hit delete), and now I can't map any analog controls to buttons (as in, using the analog triggers for gas/brake in any racing game that had analog pedals). If I find time I may do a little digging.

That is correct. The Linux sixaxis kernel driver sucks, especially in the area of the analog+digital buttons. (Most notably some analog axes report the correct scale where 0x80 is center/not pressed and 0 or 0xff are pressed and some report where 0 is center/not pressed and 0xff is pressed and some report where 0xff is center/not pressed and 0 is not pressed. I don't care what the hardware does, that is unacceptable and userland shouldn't need specialized knowledge of specific controllers to work properly). The -sixaxis switch protects you from the worst of those things (you can still use L2/R2 as analog) but MAME's core tends to hate super-high-feature joypads. (The Xbox 360 wired USB pads do work well - they have no analog face buttons and their kernel driver works properly).

That's not the behavior I'm seeing. In jstest's output, every axis that's mapped to a button rests at -32767 and moves through 0 to 32767, and every axis that maps to an analog stick rests at 0 and moves from -32767 to 32767. This seems perfectly reasonable. The only oddity I see in the jstest output are "dead" buttons and axes (two buttons are always off no matter how I manipulate the controller, and a number of axes always show the same arbitrary values and never change).

For what it's worth, the Linux sixaxis "driver" (at least in 2.6.28) is actually the regular USB HID driver with a quirk compensation to properly initialize the controller. Once the controller is initialized, it is treated as a fully HID-compliant joystick, and it responds in kind. I can only guess that there's something wrong internally in the utilities you are using for testing.

While I'm at it, the stuck buttons cannot possibly have anything to do with the way the kernel represents the controller. In Strikers 1945 II for instance, the coin switch was constantly held high unless I went into menus, and Coin 1 was btn0, Coin 2 was 6 on the keyboard.

Well, reading it via SDL shows all the things I mentioned. Jstest is not directly relevant for SDLMAME.

Actually... suspecting otherwise, I hacked up SDLJoytest (http://sdljoytest.sourceforge.net) to support multiple axes, and report the raw data SDL is providing. And the numbers SDL is giving out exactly match the numbers from jstest. I can make a patch of my changes if you'd like to see what I did, or even try it yourself.

We're waiting for your patch to SDLMAME then

Fair warning: the core requires that analog axes be at rest at zero afaik (Aaron?)

Yes, absolute analog axes are assumed to be centered at 0. It is the OSD's job to ensure that things are calibrated that way.

It seems like a simple enough fix; add an option OneWayAxis or similar that recenters the axis on 0 in software; something like

axis.value = (axis.value / 2) + 16384

Of course since I have approximately zero knowledge of the MAME codebase, it could take quite some time.

That's something the SDL OSD already does... see src/osd/sdl/input.c, line 1260 ff!!

But it does that on specific axes only (axis 12 and axis 13). Perhaps that's what confuses you?!

That's not the behavior I'm seeing in outrun. After fixing the overflow (src/osd/sdl/input.c, line 71, change 8 to 28), OutRun is very playable on a DualShock 3 with -nosixaxis and the pedals mapped analog to pressure sensitive buttons (I recommend L2 and R2). Its input test screen gives exactly the desired values too (00 up, FF down).

-E- Crus'n World (crusnwld) and Ridge Racer (ridgerac) behave in exactly the same way. Are you sure pedals are not an exception or similar?

On a related note, I found another issue. I can't map the button axes through MAME's menus, but if I manually edit ~/.mame/cfg/*.cfg, they work fine.

I've improved the -sixaxis handling for 0.129 so now it "sanitizes" all the non-stick axes instead of just 12 and 13 (and fixed the max axes in the OSD layer to 32). The inability to map axes > 4 or so in the UI seems to be a baseline thing. Aaron?

So the outrun and crusnwld and ridgerac drivers are bugged in their pedal handling? What games aren't bugged then?

They're not bugged. You're just getting suboptimal results right now and assuming it's perfection. Happens a lot with emulation.

Here's (presumably) a way to get the sixaxis working on OSX.

Source code and binary:
http://netkas.org/?p=76

I haven't tried it myself, I don't own a sixaxis.

With the sixaxis "fix", the pedal axes start at 0, then jump to almost exactly halfway (7F in outrun) with any axis activity, then moving between halfway and max. Unless I start the game holding down each pedal button, the game calibrates for 0-max, meaning the brake is always at least halfway on, and your car doesn't go anywhere. This strongly suggests to me the "fix" is wrong and resting at -32767 is expected for pedal axes.

I probably should have mentioned all this right off the bat.

Well, I'm doing what Aaron tells me the OS Dependent layer should do. It's up to you to convince him he's wrong :-)

Or I could just not use the sixaxis option.

I could make it mandatory if the controller name matches. Anyway, the adjustment is different in my code from what's in yours, so you're not actually seeing how 0.129 will behave.

Nothing is mandatory in open source software