SFC rightshoulder input not recognized in emulation but works in GUI

[giantclambake]

Note: 'Insert previous Disk Swapper slot in DF0:' is working as expected.

Attached example uae.conf

TIA

tester.uae.gz

[midwan]

Nope, seems to work normally here :)

[giantclambake]

Interesting.... I just retested this ; seems my description of the issue is incorrect.

The above uae.conf has the following;

joyport1_amiberry_custom_none_leftshoulder=Insert previous Disk Swapper slot in DF0:
joyport1_amiberry_custom_none_rightshoulder=Insert next Disk Swapper slot in DF0:

My first hunch was to check the rightshoulder mapping of the SFC controller was being recognized -- it is.

So I reordered (swapped around) the custom control mappings to...

joyport1_amiberry_custom_none_leftshoulder=Insert next Disk Swapper slot in DF0:
joyport1_amiberry_custom_none_rightshoulder=Insert previous Disk Swapper slot in DF0:

With that configuration,Insert next Disk Swapper slot in DF0: works as expected, however then it turns out that Insert previous Disk Swapper slot in DF0: doesn't work.

So it seems you cannot have both of these custom actions mapped/used at the same time, else the 2nd (latter mapping) fails to work?

[midwan]

@giantclambake I've used a similar config as the one you posted above, mapping the two events in the two shoulder buttons of my PS4 pad.

Both work normally for me.

[giantclambake]

@midwan .... weird, definitely not working like that here.... I'll do some rechecking to see if I can fathom what's going on.

[giantclambake]

Ok.... I noticed you employed a PS4 controller ~ I have 2 connected controllers.... an Xbox style (/dev/input/js0) & SFC (/dev/input/js1), and I was trying to get this working with the SFC.

I created another config of same layout, and instead mapped these events to the Xbox controller shoulders, and they do indeed work fine in that scenario. I'll do some more testing to see if I can divine what's going on.

[giantclambake]

M'kay... so first best idea I considered, was unplugging both USB controllers, and just replugging the SFC controller, to ensure the 1 controller @ /dev/input/js0 situation. Check the SFC right shoulder button press is recognized - it is. Create a new config.uae as per previous ie; wb1.3 boot hdf, 4 disk (standard not ndos) images in diskswapper, leftshoulder mapped to 'Insert previous Disk Swapper slot in DF0:' & rightshoulder mapped to 'Insert next Disk Swapper slot in DF0:' .... start emulation ; left shoulder works as expected ;; right shoulder does nothing... F12, quit...

...in my head, I think the logic goes that custom controls are held in config.uae, and we have a 'friendly name' associated with the controller connected at the time of config creation...so what happens if I change controllers (physically, unplug SFC and replug Xbox pad to be /dev/input/js0) ; this should ignore friendly name (not present), and still work with whatever (compatible) device is found at /dev/input/js0, which still consults gamecontrollerdb.txt and in theory, the custom controls in config.uae should still apply equally to the Xbox pad...

...I do exactly that, and that's exactly what happens... left/right shoulder presses on the Xbox pad work as expected, inserting next/previous image in the diskswapper as it should... go figure... F12, quit...

...unplug Xbox pad, replug SFC (another identical unit I have here), start emulation with same config.uae, same result ; right shoulder button press not inserting next/previous disk into DF0: ...F12 & quit...

@midwan ... any ideas where to look next? I can only imagine it's something specific to the SFC controller input code?

-updated description

[midwan]

@giantclambake Test that controller with something like AmigaTestKit, after setting it to CD32 mode (and do the same in AmigaTestKit), to see if the buttons you press correspond to the expected ones under emulation. Or try mapping the event to another button, to see if that helps. My guess is that the mapping is incorrect.

[giantclambake]

@midwan

Just tried it ;

Right shoulder not recognized at all when pressed.

If then I.. F12 -> custom controls -> and try to set a hotkey to rightshoulder press, I see;

So that button press is actually working there, just the event not making it to the emulation?

[midwan]

Looks like you have RShoulder mapped as the Hotkey. The hotkey button cannot be mapped to another function as well, so it's disabled in the screen above. The hotkey can be used in combination with other buttons, to trigger (more) events, e.g. Hotkey + X can be a separate mapping than just X.

[giantclambake]

No, that was merely to demonstrate the rightshoulder button press was being registered in the GUI. Example only, it is not set like that during testing.

[midwan]

I still think it might be a mapping issue with that controller. Did you use a custom mapping, or the default? Try the other one to see if it helps. You can set the mapping with the "Remap" button. If you want to remove an existing mapping instead, you can either rename the controllersdb_user file, or remove that line from in there.

[giantclambake]

It's a standard SFC controller, I don't see why the default mapping shouldn't work, nor do I feel users should have to create a custom mapping for this standard controller device....as seems to be the case if using a PS4 or Xbox pad.

As demonstrated, with the SFC controller set to CD32 pad (as you suggested), the mapping is recognized in GUI and config.uae, but rightshoulder is not recognized in emulation using AmigaTest kit.

Created a fresh config.uae to just load ATK adf. My controllers/gamecontrollerdb_user.txt has always been an empty file during testing, as the default mappings have been fine..but TTBOMK I never actually tested/used SFC rightshoulder in practice before, because the default mapping with SFC as joystick work fine.

GUI->Input->Port 1:-> Remap ... created the normal/typical layout for this device type, right shoulder is recognized.

03004d2a1f08000001e4000010010000,USB gamepad,platform:Linux,a:b2,b:b1,x:b3,y:b0,back:b8,start:b9,leftshoulder:b4,rightshoulder:b5,dpup:-a
1,dpdown:+a1,dpleft:-a0,dpright:+a0,

Note: devicename changes from SFC controller to USB controller (if matching entry found in gamecontrollerdb_user.txt)?

Start emulation to run amigatestkit, and in that program -> F4 -->F2 to select CD32 pad (pad detected) -> all buttons work EXCEPT right shoulder.

Like I say, it's as though the rightshoulder button press on SFC/USB controller works everywhere else EXCEPT in the emulation.

Have you tried this on such a controller? If it worked for you, can you share the config.uae plz?

-logfile of above run attached amiberry.log.gz

edit: also not working in v5.6.9

edit2: Note also, that whether using the Default/CD32 pad/custom remap, the rightshoulder:b5 mapping is the same in every case, but, the emulation only sees button 5 pressed when it's an Xinput/Xbox controller (and apparently PS4 controller), but never recognizes button 5 being pressed when it's a SFC/USB pad controller.

[giantclambake]

...it's difficult to debug this, I just had another swing at it ; fortunately this is one part of amiberry that works on the fly (the GUI doesn't show it, but using F12 to remap controller, makes those settings apply upon resume ; the GUI doesn't update device field from SFC to USB controller if one creates a gamecontrollerdb_user.txt on the fly =)

-obviously button event(s) are being recognized as you can remap all buttons in GUI

Created a gamecontrollerdb_user.txt that maps rightshoulder to another button ;

03004d2a1f08000001e4000010010000,USB gamepad,platform:Linux,a:b8,b:b1,x:b3,y:b0,start:b9,leftshoulder:b4,rightshoulder:b2,dpup:-a1,dpdown:+a1,dpleft:-a0,dpright:+a0,

Launch amiberry, start AmigaTestKit in emulator ... same result -> rightshoulder not working on other buttons either (I tried a few), so somehow INPUTEVENT_JOY2_CD32_FFW doesn't get to the emulation, when it's a SFC/USB controller set to CD32 Pad mode.

03004d2a1f08000001e4000010010000,USB gamepad,platform:Linux,a:b2,b:b1,x:b3,y:b5,start:b8,leftshoulder:b4,dpup:-a1,dpdown:+a1,dpleft:-a0,dpright:+a0,misc1:b9,

-rightshoulder not remapped -- actual rightshoulder button on pad mapped to yellow ... yellow event works

03004d2a1f08000001e4000010010000,USB gamepad,platform:Linux,a:b2,b:b1,x:b3,y:b5,start:b8,leftshoulder:b4,rightshoulder:b0,dpup:-a1,dpdown:+a1,dpleft:-a0,dpright:+a0,misc1:b9,

-same as before with yellow button on pad mapped to rightshoulder ... doesn't work, rightshoulder event not there.

What's confusing me, is how come this all works fine with a PS4/Xbox pad? The only thing I can think of there, is those devices are joystick_analog and SFC pads are just joystick ...but it seems unlikely

[midwan]

I will test with a few different controllers to see if I can recreate it

[midwan]

Tested with:

• PS4 controller
• Steam controller
• Retroflag SNES controller
• XBox controller

They all work fine here. Whatever this is, it seems specific to your controller there, or something else that I don't have here.

[giantclambake]

@midwan ~ thanks again for testing, and I concur... I've got 3 different Xbox type controllers and borrowed a PS4 controller as well to check, and all these devices work fine in ATK ; rightshoulder button press works in every case. It's only with these cheap SFC controllers the problem arises... despite every button being recognized in GUI->Input->Remap, and the resultant gamecontrollerdb_user.txt file appearing 'correct'.

What I found peculiar, is when amiberry initializes this control pad as 'SFC Controller', the mapping shown in logfile is actually correct...ie; it's identical to the mapping obtained when using the Remap function in GUI;

Controller #0: SFC Controller
      GUID: 03004d2a1f08000001e4000010010000
Controller 0 is mapped as "03004d2a1f08000001e4000010010000,SFC Controller,a:b2,b:b1,back:b8,dpdown:+a1,dpleft:-a0,dpright:+a0,dpup:-a1,leftshoulder:b4,rightshoulder:b5,start:b9,x:b3,y:b0,platform:Linux,".
Joystick name: 'USB gamepad', sanitized to: 'USB gamepad'

The SFC Controller definitions are held in the conf/gamecontrollerdb.txt file, to wit;

030000001f08000001e4000010010000,SFC Controller,a:b2,b:b1,back:b8,dpdown:+a1,dpleft:-a0,dpright:+a0,dpup:-a1,leftshoulder:b4,rightshoulder:b5,start:b9,x:b3,y:b0,platform:Linux,

This infers to me the amiberry code has indeed correctly recognized the USB device as a SFC Controller, and applied the default mapping here, which is also correct, and this is why all GUI operations & gamecontrollerdb_user.txt file creation is working as expected.

I'd grabbed the sdl2-jstest utility a few weeks back ... it came with a gamecontrollerdb.txt file dated 28/02/24

Joystick Name:     'USB gamepad'
Joystick GUID:     03004d2a1f08000001e4000010010000
Joystick Number:    0
Number of Axes:     2
Number of Buttons: 10
Number of Hats:     0
Number of Balls:    0
GameControllerConfig:
  missing (see 'gamecontrollerdb.txt' or SDL_GAMECONTROLLERCONFIG)

M'kay, launch amiberry, GUI->Paths->Update Controllers DB-> Quit amiberry. Copy downloaded gamecontrollerdb.txt into sdl2-jstest build_dir ...

Joystick Name:     'USB gamepad'
Joystick GUID:     03004d2a1f08000001e4000010010000
Joystick Number:    0
Number of Axes:     2
Number of Buttons: 10
Number of Hats:     0
Number of Balls:    0
GameControllerConfig:
  Name:    'SFC Controller'
  Mapping: '03004d2a1f08000001e4000010010000,SFC Controller,a:b2,b:b1,back:b8,dpdown:+a1,dpleft:-a0,dpright:+a0,dpup:-a1,leftshoulder:b4,rightshoulder:b5,start:b9,x:b3,y:b0,platform:Linux,'

Ok, that appears correct....in the space of 1 month, the file was updated that fixed things?

-redo Amiga Test Kit check in emulation -- rightshoulder event still not registered in emulation ; works in GUI

Go figure... does sdl2-jstest see things correctly.../sdl2-jstest -t 0 -- well, yes...but it claims the device has 10 buttons, when in fact it only has 8 .. ie; buttons 0 ~ 5 and buttons 8,9 are used (buttons 6,7 not physically present) ; that's superfluous however, because the default SFC controller mapping doesn't use buttons 6&7 either =)

Everything looks like it should work and does in GUI, only in emulation is the rightshoulder event not recognized... with this SFC controller in CD32 pad mode. I doubt it'll help any, but later I'll include a line in gamecontrollerdb.txt to specifically match this device ( ID 081f:e401 Manta gamepad ). I've ordered a Retroflag SNES controller to do some comparative testing (will take a couple of weeks to get here ;)

[giantclambake]

Works in Winuae 4.10.1/5.2.0 (but 'start' button doesn't seem mapped by default)...

...but rightshoulder does work here...

edit: the reason winuae doesn't map start button by default, is it only maps in buttons 1-7 (sequentially I guess), whereas SFC controller has back/start @ buttons 8 & 9

[midwan]

@giantclambake WinUAE doesn't help in this case, as it uses Windows-specific APIs for joystick input. Amiberry uses SDL2, and controller mappings.

This needs debugging to find out what button Id is triggered inside emulation, when you press that button. Maybe it's not correctly mapped, maybe it's not reported as the expected button, I'm not sure what's going on.

Are you on Discord? It would go faster if we could chat in real-time about this, maybe send you some debug versions with extra logging info to see what's happening when you press the button.

[giantclambake]

@midwan -- yes, I'm aware of that, I was merely curious wrt what happens in the winuae case ;)

No, not on discord (zero interest in new 'social media' =) ; I do have 20 of these Manta gamepads ~ if you have a postal address, more than happy to send you one ;)

If the 'Retroflag SNES controller' works for you, in theory the same device should work here, but I need wait for that to get here to test that theory.

If you have any lines of code I can patch my local copy with to get some info of what's being presented to the emulation process when the button is pressed that's mapped to 'rightshoulder', you could just attach here. To be clear, button 'b5' is recognized by the emulation when mapped to a different event ~ but isn't recognized when (any) button is mapped to 'rightshoulder' ....(just weird, considering it works with the other controller device =)

edit: also works in fs-uae, all buttons mapped and working (including b8 -> pause as default)

[giantclambake]

M'kay .... I think I finally have a notion about what's going wrong here ;)

The SFC controller(s) giving me this issue, are those such as -> https://www.ebay.com.au/itm/201909944241

This kind of device is detected in amiberry as 'SFC controller' (gets sanitized to 'USB gamepad'), and the button mappings are provided by conf/gamecontrollerdb.txt as a result of using SDL_CONTROLLER ... and AFAICT the linux driver being employed is USB-HID or similar in the case of these SFC controllers....

....as seen above, I was curious why when testing the same controller in fs-uae (which also uses SDL_CONTROLLER), where it works fine, AmigaTestKit wasn't just reporting 'Pad Detected', but as seen ... 'Pad Detected @ CIA mirror (CD32 + fWSI Floppy Exp?)' ...I just asided this to the way fs-uae is coded (I do know what a fWSI is, and the controller option is 'cd32 gamepad pro' in fs-uae.... whatever that means =)

Today, the 'Retroflag' controller turned up here -> https://www.ebay.com.au/itm/402611766745 ...and as you can see, they are ostensibly 'like' devices ...from the outside...

First thing I noticed, were details on the box indicating the controller would by default initialize in Xinput mode, but if you hold the Y key down when plugging in, it'll initialize in Dinput mode....I would never had twigged this without obtaining this controller. Sure enough, after plugging it in, and issuing lsusb ...

Bus 001 Device 041: ID 081f:e401 Manta gamepad //<- SFC controller Bus 001 Device 039: ID 20d6:2030 PowerA Xbox Series X EnWired Purple Magma //<- PowerA Xbox controller Bus 001 Device 040: ID 045e:028e Microsoft Corp. Xbox360 Controller //<- Retroflag Classic Wired USB Gaming Controller

./sdl2-jstest -l

Found 3 joystick(s)

Joystick Name:     'Generic X-Box pad'
Joystick GUID:     03008665d62000003020000001010000
Joystick Number:    0
Number of Axes:     6
Number of Buttons: 11
Number of Hats:     1
Number of Balls:    0
GameControllerConfig:
  Name:    'XInput Controller'
  Mapping: '(null)'

Joystick Name:     'Xbox 360 Controller'
Joystick GUID:     030003f05e0400008e02000014010000
Joystick Number:    1
Number of Axes:     6
Number of Buttons: 11
Number of Hats:     1
Number of Balls:    0
GameControllerConfig:
  Name:    'Xbox 360 Controller'
  Mapping: '030003f05e0400008e02000014010000,Xbox 360 Controller,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,platform:Linux,'

Joystick Name:     'USB gamepad'
Joystick GUID:     03004d2a1f08000001e4000010010000
Joystick Number:    2
Number of Axes:     2
Number of Buttons: 10
Number of Hats:     0
Number of Balls:    0
GameControllerConfig:
  Name:    'SFC Controller'
  Mapping: '03004d2a1f08000001e4000010010000,SFC Controller,a:b2,b:b1,back:b8,dpdown:+a1,dpleft:-a0,dpright:+a0,dpup:-a1,leftshoulder:b4,rightshoulder:b5,start:b9,x:b3,y:b0,platform:Linux,'

The 'Xbox 360 Controller' listed above is the Retroflag controller.

-start amiberry -> load AmigaTestKit.uae->Input->change port 1: to 'Xbox 360 Controller' (CD32 Pad) -> Start and redo CD32 pad test ... everything works as expected (because the controller is identifying as a Xinput device and we already know that works? =)

Lets keep going ... the word 'Dinput' confuses me a bit ~ is that referring to the old directinput windows API, or, is that some shorthand for 'digital input' for some HID device, like a gamepad/joystick, attached to the USB bus?... unplug controller, hold down Y button and replug to get device into Dinput mode... controller enumerates as;

Bus 001 Device 042: ID 0583:2060 Padix Co., Ltd (Rockfire) 2-axis 8-button gamepad

Issuing ./sdl2-jstest -l reveals ;

Joystick Name:     'RetroFlag Wired Controller'
Joystick GUID:     0300af53830500006020000010010000
Joystick Number:    1
Number of Axes:     2
Number of Buttons: 16
Number of Hats:     0
Number of Balls:    0
GameControllerConfig:
  Name:    'iBuffalo Super Famicom Controller'
  Mapping: '0300af53830500006020000010010000,iBuffalo Super Famicom Controller,a:b1,b:b0,back:b6,dpdown:+a1,dpleft:-a0,dpright:+a0,dpup:-a1,leftshoulder:b4,rightshoulder:b5,start:b7,x:b3,y:b2,platform:Linux,'

-start amiberry -> load AmigaTestKit.uae->Input->change port 1: to 'iBuffalo Super Famicom Controller' (CD32 Pad) -> Start and redo CD32 pad test ... everything works as expected!?!?... go figure... sanity check time...

-start amiberry -> load AmigaTestKit.uae->Input->change port 1: to 'SFC Controller' (CD32 Pad) -> Start and redo CD32 pad test ... faithfully recreates the bug -- rightshoulder event not detected in AmigaTestKit.

On the surface it looks like if device=SFC Controller, rightshoulder:[button.mapping] is not getting passed to emulation?

@midwan ~ hopefully that helps isolate it further... it certainly explains the disparity of results between our testing ;) Want a free Manta gamepad? =)

[midwan]

From what I can see above, when you used the DInput mode on the Retroflag controller, the results of the mapping are very similar to your SFC one. If we isolate out only the parts that are different in the button mapping:

Mapping: a:b1,b:b0,back:b6,leftshoulder:b4,rightshoulder:b5,start:b7,x:b3,y:b2
Mapping: a:b2,b:b1,back:b8,leftshoulder:b4,rightshoulder:b5,start:b9,x:b3,y:b0

(top one is retroflag, bottom is SFC)

One thing I noticed, is that the top one (retroflag) which works, has all the buttons in sequential order. From b0 to b7. The SFC one has b0 to b5, then a gap and then b8 and b9. It doesn't report a b6 and b7 at all.

I'm not sure if this matters or not of course, just pointing out the only real difference I could see.

If you can send me one of those, I could try debugging this locally, and see what happens in the mapping when the button is pressed. It's clearly an issue with the mapping inside emulation, for some reason. The button is pressed, but it doesn't end up triggering the RShoulder event.

Send me an e-mail, and I'll provide you with a postal address you can ship one: midwan at gmail dot com.

[giantclambake]

Indeed, I noted the b0 thru b5 mapping with b8 & b9, and b6 & b7 missing previously ~ I didn't give it much thought, because the default mappings account for this (not just 'Manta' branded pads) and everything works swimmingly everywhere else ; it's just in the emulation things go awry.

More for poop & laughter than anything else, I decided to plugin my Saitek ST90 USB joystick ~ it's an improbable usage scenario for sure, but amiberry allows applying the 'CD32 pad' type to this input device ; so be it ...

 Joystick Name:     'HOLTEK Saitek ST90 USB Stick'
Joystick GUID:     03000d7aa3060000620d000000010000
Joystick Number:    2
Number of Axes:     3
Number of Buttons:  3
Number of Hats:     0
Number of Balls:    0
GameControllerConfig:
  missing (see 'gamecontrollerdb.txt' or SDL_GAMECONTROLLERCONFIG)

Notwithstanding ... -start amiberry -> load AmigaTestKit.uae->Input->change port 1: to 'HOLTEK Saitek ST90 USB Stick' (CD32 Pad) -> Start and redo CD32 pad test. Using the default mappings, this is detected & tested like so in ATK ;

Okay...what if I remap a couple of buttons, to left/right shoulder via gamecontrollerdb_user.txt ..ie;

HOLTEK Saitek ST90 USB Stick,platform:Linux,start:b0,leftshoulder:b1,rightshoulder:b2,leftx:a0,lefty:a1,

Buttons stop working ; mapped events not detected.

I probably didn't expect that ; the user remapping does not apply. There must be some underlying logic that sets the appropriate mapping (which is seems) the user cannot over-ride.

[midwan]

The SFC controller arrived today, and I was able to recreate (and fix) this. :)