AmigaInput

[Cyborg]

@samo79
I don't see this kind of crash here with latest AmigaInput. Can you describe exactly how to reproduce it? Do you just enter calibration or actually calibrate and save, do you close AmigaInput prefs or not, etc. pp.

[samo79]

Calibration works fine and everything works, but if I go to physically unplug the pad from the port it crashes, this sometimes happens even after having saved (and closed) the AmigaInput preferences

[Cyborg]

I understood the basic issue you have, but WHEN exactly does it happen? E.g.

1) Open AmigaInput prefs.
2) Go to calibration window for an USB device.
3) Leave the calibration window via save/use/cancel button (which one?).
4) While AmigaInput prefs is still shown, detach the USB device -> Crash. (was the device selected or not selected when detached?)

Is that the correct way to reproduce it or is there anything else to it? Also please answer the questions in parentheses, thanks.

[MagicSN]

>1) Ja, es ist zu großen Teilen Dein eigener Code, zu dem Du fragst

Haha, weiß nimmer was ich da vor 10 Jahren oder so gemacht habe )) Aber irgendwie kam es mir SEEEEHR bekannt vor.

>2) Die USB HID Spezifikation läßt leider sehr viel Raum für Interpretation und eigene Implementierung. Die teureren >Gamepads halten sich praktisch alle an gewisse Konventionen, bei den günstigeren Varianten oder auch den ganzen >"Retro"-Dingern kannst Du Glück oder auch Pech haben.

Ja, das von mir ist "so billig wie möglich", aber wie gesagt - es funktioniert, wenn ich mir auch nicht sicher bin ob andere Pads mit Hats sich gleich verhalten. Daher hab ich den Hat-Support im Q2 mal abschaltbar gemacht, und die Werte für die Richtungen per Q2 Console Variablen konfigurierbar.

Sollte auch bald releasebar sein

>Wenn Deine Tester auch AmigaOS-Betatester sind, dann sollen sie auf jeden Fall die neusten Versionen von >Prefs/AmigaInput und Generic_usb.driver verwenden. Da habe ich ein paar wichtige Dinge gefixt und auch schon eine >weitere Revision in der Pipeline, die Probleme mit Geräten ohne definierten Gerätenamen behebt.

Ja sind sie. Danke für den Tip - sollte ich mir selber auch mal installieren wohl (mit "neuer" meinst Du Beta, also nicht nur 4.1 Final Edition ?)

>Die Kalibrierung in Prefs/AmigaInput braucht neben anderen AI-Teilen noch sehr viel Tüftelei. Die spielt bei vielen Dingen >verrückt oder funktioniert nicht richtig. Ob/Wann ich dazu komme, weiß ich aber noch nicht. Erstes Ziel wäre bei mir >sowieso der PS4-DualShock, weil ich die hier liegen habe.

Hab hier noch irgend nen PS3 Stick, der nicht will. Muss aber nicht an AmigaInput liegen, der könnte auch einfach kaputt sein (meine PS3 mit Zubehör war Jahrelang in ner Kiste und hat Staub gesammelt...).

>3) Im Grunde mußt Du bei der Nutzung in Spielen bestimmten Konventionen folgen und die Nutzer sich anpassen lassen. >Anders geht es nicht. z.B.:

>- linker Analogstick: X/Y-Achse
>- rechter Analogstick: Z-Achse/Z-Rotation
>- linker Analogtrigger: X-Rotation
>- rechter Analogtrigger: Y-Rotation

Hab ich etwass anders gemacht.

Alle Achsen sind über die Quake 2 Settings voll konfigurierbar, was sie auslösen, das löst dann K_JOY bzw. K_AUX Events aus. Buttons und Hats ebenso (am Anfang hatte ich es anders, das gab dann je nach Joypad "überraschende ergebnisse", daher hab ichs nun so gemacht dass mans am Anfang 1x konfigurieren muss, aber dafür hat man es so wie es will.

Nachteil: Man kann pro Action ja nur 2 Auslöser definieren (evtl. muss ich mal schauen ob man das irgendwie auf 3 ändern kann ?) Aber das is eher ein Q2 Thema und kein AI Thema. Mal Schauen.

Gruß,
Steffen

[Cyborg]

@root

Nach etwas Recherche ist der Saitek so absolut korrekt. Tatsächlich meldet er seine Kontrollen so genau, wie bisher kein anderes Pad

Das PS4-Pad mit USB ist im Grunde auch korrekt, wobei die Darstellung im Kalibrierungsfenster unglücklich ist. Da muß ich bei Gelegenheit/Zeit/Muße nochmal prüfen, warum die vorhandenen Achsen so gruppiert werden. Ich würde das etwas anders erwarten.

Im Moment bin ich aber erst Mal schon zufrieden, daß die nervigsten Crashes weg sind, es im Allgemeinen etwas robuster wurde und "THEGamepad" läuft

[kas1e]

@Cyborg
I were able to reproduce a crash Samo point out on. And i got it before and now as well. This time it happens on X5000 with generic_usb.driver 53.5 (11/20/2022) + amigaintput_prefs 53.14 (6.11.2022).

That what i do to reproduce it:

1). Plug in gamepad
2). Start amigainput prefs
4). Unplug the gamepad
5). Plug the gamepad back
6). Unplug the gamepad
7). Plug the gamepad back => crash. If it didn't crash right now, then repeat 5) and 6) again so it will surely crash.


There is relevant info about crash:

Exception Syndrome Register: 0x00000000
0: 7FBD5E48 60B67EB0 00000002 0216ADA8 00000000 00000000 00000001 022CC294
8: 02161D20 00000100 022CF162 0183B150 28222828 0000000D 0216ADA8 00000001
16: 67C80548 FFFFFFFF 00FF00FF 61210000 60B714D0 6FFFE300 67B20AD0 67FBE9D0
24: 00000000 60C86CA0 11BA5E11 11DEAD11 00000000 612AE4A0 00000000 0216ADA8
CR: 28222228 XER: 6000002F CTR: 0183A708 LR: 0185C644

Stack trace:
(0x60B67EB0) native kernel module kernel+0x0005c644
(0x60B67ED0) native kernel module kernel+0x0005c644
(0x60B67EF0) module LIBS:usbhidgate.library at 0x7FBD5620 (section 0 @ 0x5FC)
(0x60B67F00) module CURRDIR:Generic_usb.driver at 0x7F8C6060 (section 0 @ 0x3C)
(0x60B67F20) module CURRDIR:Generic_usb.driver at 0x7F8C9E18 (section 0 @ 0x3DF4)
(0x60B67F90) native kernel module dos.library.kmod+0x00029e18
(0x60B67FC0) native kernel module kernel+0x0005f280
(0x60B67FD0) native kernel module kernel+0x0005f2f8

Disassembly of crash site:
0185C634: 81430010 lwz r10,16(r3)
0185C638: 7D2903A6 mtctr r9
0185C63C: 83AA0114 lwz r29,276(r10)
0185C640: 4E800421 bctrl
>0185C644: 813E001C lwz r9,28(r30)
0185C648: 7F89E800 cmpw cr7,r9,r29
0185C64C: 419E0098 beq- cr7,0x185C6E4
0185C650: 38800001 li r4,1
0185C654: 7FC3F378 mr r3,r30
0185C658: 4BFB783D bl 0x1813E94

As you see it point out on "lwz r9,28(r30)" as on guilty instruction, and we do have r9 and r30 both NULLs.

Crash always reproducable with the same stack trace.

Should i better create it as BZ on hyperion's bugzilla, or it's enough that i post relevant info there ?

To add, that happens with all gamepads i have, so seems not related to what exactly game pad is, related to the fact that things attached/deattached while calibration window there.

And if i didn't run amigainput_prefs (just pure workbench), i can attach-deattach any gamepad as many times i wish without crash.

[Cyborg]

@kas1e
Thank you. Please re-test with latest 53.6 of Generic_usb.driver (just to be sure, it most likely will not change anything) and file a Bugzilla report against AmigaInput prefs. Please include the *complete* crashlog, not just excerpts. Thanks.

What you describe - and what was not clear to me by Samo's description - looks like one more result of fundamental fails and misses in AmigaInput. I don't know if I find the time (and motivation) to invest the probably required effort to fix this. After all, everything seems to work as long as you don't (un)plug anything while the calibration window is open. If I'd start with such things, I would probably be faster (and keep more of my sanity) rewriting AmigaInput from scratch.

But I'll make a note and have a look at the bugreport. Maybe there is even a simple solution... you never know.

[samo79]

@Cyborg

Ah it seems kas1e anticipate me, i'm not the only one then
More or less i got the same issue of him by following the same step by step procedure

[kas1e]

@Costel
Tested with amigainput 54.14 and generic usb driver 53.6 : same crash.
So created BZ : #10468
If you will ever look at this one, i can help with fast betatest without waiting me for weeks

[Cyborg]

Thanks, I'll keep it in mind. There are too many things to do in my spare time, I have to choose and working on AmigaInput beyond getting it at least to work at the most basic level is not exactly high on the priority list I'm afraid.