PCSX in Ubuntu 18.04 werkt niet met 2 gamepads aangesloten

[Josefien]

Mijn vraag
...
Op mijn PC met Ubuntu MATE 18.04 en PCSX-Reloaded geïnstalleerd (versie onbekend, geeft alleen "svn" aan onder Help=>About) kan ik geen controllers configureren als er meer dan 1 gamepad is aangesloten. Als ik klik op "Configuration" => "Controllers" gebeurt er simpelweg niks als er 2 USB gamepads zijn aangesloten, het instelscherm blijft weg. Als slechts 1 gamepad is aangesloten verschijnt wel netjes het instelscherm en werkt die ene gamepad ook.

Dit probleem doet zich niet voor onder een oudere Ubuntu MATE 16.04 met oudere PCSX-R 1.9.92.

Waarom kan onder de nieuwste Ubuntu-versie geen PCSX-R worden gebruikt met 2 USB gamepads terwijl het met een jarenoude versie wèl werkt?


Relevante software en hardware die ik gebruik
...
Ubuntu MATE 18.04 / Lubuntu 18.04
PCSX-R svn (uit de repository)
Verschillende USB gamepads van XFX, Saitek en Speedlink.


Wat ik al gevonden of geprobeerd heb
...

Dit zelfde probleem doet zich ook voor op een netbook met Lubuntu 18.04 en dezelfde PCSX-R versie, dus het is niet hardware-gebonden.

Ik heb ook andere merken USB gamepads geprobeerd (standaard USB HID), allen hetzelfde probleem.


Wat mij verder opvalt (maar geen idee of het met dit probleem iets te maken heeft) is dat onder het oude Ubuntu 16.04 i.c.m. oude PCSX-R de controllers getoond worden met een naam:


Onder Ubuntu 18.04 en de svn PCSX-R heet het alleen "null" ongeacht het merk gamepad wat wordt aangesloten (werkt wèl mits dus 1 gamepad aangesloten):



Onder Lubuntu 18.06 heeft "dmesg" foutmeldingen als de controller-configuratie wordt aangeklikt met 2 gamepads aangesloten:

[Josefien]

Inmiddels iets verder...

Het probleem zit 'm in dat met de nieuwere PCSX-R van Ubuntu 18.04 er ook een nieuwere input-plugin wordt bijgeleverd (1.2.0 vs 1.1.0). En die heeft op de een of andere manier problemen ermee als er 2 gamepads zijn aangesloten

Ik vind het maar raar... Ik vind op internet ook totaal niks over dit probleem. Zou werkelijk niemand multiplayer PSX-games hebben gespeeld in deze emulator met 2 gamepads?


Als (in mijn ogen best ranzige) "oplossing" heb ik de files voor de input-plugin uit de Ubuntu 16.04 installatie gekopieerd naar die in Ubuntu 18.04. Dan werkt het wel.

Ik heb in "/usr/lib/i386-linux-gnu/psemu" de bestanden "cfgDFInput" en "libDFInput.so" in de 18.04 installatie vervangen door oudere varianten uit 16.04.

En ook de /usr/share/psemu/dfinput.glade2 uit 16.04 naar dezelfde locatie van 18.04 gekopieerd. Bij die laatste bestaat dit bestand niet, die heeft .gui bestanden i.p.v. .glade2. Als gevolg hiervan moest ik handmatig libglade2-0 installeren voordat het kon werken.

De input-plugin is hiermee gedowngraded en werkt daarna ook prima met 2 gamepads en ook de namen v/d gamepads wordt weer getoond.

Alleen, dit is toch geen oplossing? Volgens mij worden de door mij vervangen bestanden bij de eerstvolgende keer dat het pcsxr pakket wordt bijgewerkt weer teruggezet naar de niet-werkende nieuwe versies

Wat is er eigenlijk mis met die nieuwere 1.2.0 waardoor het niet meer start als er meer dan 1 gamepad is aangesloten?


Voor en na het downgraden van de input-plugin:

[Josefien]

Deze bug is nog steeds aanwezig in de nieuwste Ubuntu 20.04 En ook nu weer verholpen door dezelfde bestanden uit Ubuntu 16.04 te kopiëren, weliswaar 64-bit. Bestanden uit een 32-bit 16.04 werken namelijk niet op een 64-bit 20.04.

En i.p.v. /usr/lib/i386-linux-gnu/psemu is het nu /usr/lib/x86_64-linux-gnu/psemu.

Ik heb destijds al een bugreport ingestuurd, maar helaas is er nooit wat mee gedaan. Ergens snap ik wel waarom de meeste mensen Windows blijven gebruiken. Zelfs de meest simpele dingen hebben fouten en ze worden ook nog eens niet opgelost

[MAX3400]

En daarom is Tweakers zo gaaf; @Josefien die een eigen topic bijna een jaar lang van updates voorziet ter leeringh ende vermaeck van anderen!

[Vaenir]

Al een alternatief geprobeerd zoals Retroarch i.c.m. een ps1 core? Ik gebruik zelf de Mednafen ps1 core (Beetle psx) en ik heb hier geen problemen mee. Mijn OS is alleen Manjaro maar ik denk dat dat in dit scenario weinig uitmaakt.

[ Voor 6% gewijzigd door Vaenir op 28-06-2020 23:40 ]

[Josefien]

Retroarch is een hele interface voor emulators, terwijl ik juist de simpele interface van PCSX waardeer.

En deze bug zit ook in de PCSX-R package van Debian 10 merk ik net op, en kan op dezelfde manier opgelost worden, met bestanden uit Ubuntu 16.04 Ik vraag me af waar ik deze bug kan melden zodat 'ie daadwerkelijk hersteld gaat worden

Tijdens het zoeken naar een mogelijke andere oplossing lijken de meeste over Ubuntu te gaan, niet Debian. En kwam ik op https://askubuntu.com/que...tion-window-show-in-pcsxr terecht waar iemand zelfs naar dit topic heeft verwezen voor de "oplossing"

[Hero of Time]

Josefien schreef op vrijdag 6 november 2020 @ 23:46:
k vraag me af waar ik deze bug kan melden zodat 'ie daadwerkelijk hersteld gaat worden

Dat is het mooie. Informatie over het package vind je op https://packages.ubuntu.com/focal/pcsxr en daar is een link voor bug reports, die wijst naar Launchpad: https://launchpad.net/distros/ubuntu/+source/pcsxr/+bugs. Kan je ook zien of er al een report van is. En dat is het geval: https://bugs.launchpad.net/ubuntu/+source/pcsxr/+bug/1843503.

Oh, dat is jouw report...

---

Even verder gekeken en bij Debian is er een patch beschikbaar, want upstream gaat het blijkbaar wel goed. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912171

[ Voor 22% gewijzigd door Hero of Time op 07-11-2020 14:00 ]

[Josefien]

Bij Ubuntu wordt al ruim een jaar niks gedaan met mijn bug-report zoals je kan zien

Bij Debian stamt die patch uit 2018. Waarom zit dat nog steeds niet in het pakket van mijn vers geïnstalleerde Debian 10 mèt alle updates geïnstalleerd? Of komt dat pas met Debian 11?

[GuntherDW]

Er is in al die tijd geen nieuwe versie uitgekomen en zelfs de git repo is vrij... dood te noemen.
Daarom dat ze er waarschijnlijk niet veel tijd in willen steken gezien upstream ook zo goed als dood is.

Als je nu voor PSX emulation wil gaan moet je inderdaad gaan kijken naar emulators als Retroarch of Mednafen.

Of gewoon de source downloaden en zelf een patch maken als het zo simpel is als daar staat in HoT's link.
Je kan nog eens proberen een report aan te maken maar ik schat de kans dat er iets gebeurt vrij klein in spijtig genoeg.
Het is nog niet zo oud dat ze het uit de repo's zouden schoppen maar gezien de... inactivity scheelt het niet veel.

[Josefien]

Maar waarom dan niet gewoon de oudere versie die in 16.04 zat meeleveren (of i.i.g. de input-plugin ervan)? In dit geval is nieuwer duidelijk niet beter.

[Hero of Time]

GuntherDW schreef op zondag 8 november 2020 @ 02:07:
Of gewoon de source downloaden en zelf een patch maken als het zo simpel is als daar staat in HoT's link.
Je kan nog eens proberen een report aan te maken maar ik schat de kans dat er iets gebeurt vrij klein in spijtig genoeg.

De bug report waar ik naar link heeft het niet over een patch an sich, maar de code met upstream bijwerken want daar staat het wel goed. Dat is wel iets wat je zou kunnen doen, de broncode van het pakket met alle dependencies ophalen, de upstream code toepassen en een .deb van maken.

Het is nog niet zo oud dat ze het uit de repo's zouden schoppen maar gezien de... inactivity scheelt het niet veel.

Nou... Volgens https://tracker.debian.org/pkg/pcsxr is het er wel uit geweest:

[2020-09-26] pcsxr 1.9.94-5 MIGRATED to testing (Debian testing watch)
[2020-09-20] Accepted pcsxr 1.9.94-5 (source) into unstable (Markus Koschany)
[2020-08-07] pcsxr REMOVED from testing (Debian testing watch)

Weg om 6 weken later toch nog terug te komen in Testing (en daarmee mogelijk nog in de nieuwe Stable).

Josefien schreef op zondag 8 november 2020 @ 02:36:
Maar waarom dan niet gewoon de oudere versie die in 16.04 zat meeleveren (of i.i.g. de input-plugin ervan)? In dit geval is nieuwer duidelijk niet beter.

Dat zal wel te maken hebben met de dependencies en andere veranderingen. Je zou de upstream changelog moeten bekijken om te zien wat er dan anders is tussen .92 en .94.

[GuntherDW]

Hero of Time schreef op zondag 8 november 2020 @ 10:34:
[...]
Nou... Volgens https://tracker.debian.org/pkg/pcsxr is het er wel uit geweest:

De reden dat het eruit was als je het nakijkt is een "auto removal" omdat het faalde te builden met GCC10. Gezien het oude code is en GCC10 fno-common behaviour "omgedraaid" heeft by default, jah.
Nadat ze de Makefile aangepast hebben zat het ook terug in de repo.

https://tracker.debian.or...sxr-removed-from-testing/
Met een link naar deze bugreport dus:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957671

[amx]

Ondanks dat ik dit soort topics altijd met veel plezier lees (getuige de duidelijke doorlopen stappen en inhoudelijke kennis niet alleen van TS maar ook van andere Tweakers) begrijp ik niet waarom voor dit soort programmas niet meer met Ubuntu snap wordt gewerkt, of met containers. Die zijn vaak namelijk probleemloos backwards compatible met oudere versies en minimaliseer je de dependency hell van nieuwe besturingsssytemen en verschillende oudere programmas

[Hero of Time]

Omdat in dit geval een container meer problemen geeft, omdat je namelijk apparaten zoals je controllers door moet sturen erheen en het is een grafisch programma. Dat kan je dus niet 'eventjes' in een container gooien. Het heeft ook nog eens 3D acceleratie nodig.

Een snap package kan, maar daar zal men ook wel weer wat mee doen waardoor er iets niet zal werken.

In dit specifieke geval was er een nieuwe upstream versie beschikbaar en die hebben ze gepakt. Echter is er dus schijnbaar een bug in die versie en hoewel het upstream is opgelost, is er niet gekeken of er fixes waren. Want de versie is niet verhoogd. Dit maakt het dus wat lastiger om zaken geautomatiseerd te laten lopen, waaronder een notificatie dat er een nieuwe upstream versie is om te packagen.

[Josefien]

Ik heb bewust snapd verwijderd van mijn Ubuntu-systemen. Snap-applicaties starten erg traag op en je hebt gezeik met allerlei rechten zoals een tekstverwerker die geen bestanden buiten je home-directory kan benaderen. Als PCSX een snap was kon je vast weer geen ISO's openen vanaf een netwerk-share...

Wat mij vaak hekelt aan Linux is dat applicaties niet zoals onder Windows onafhankelijk van de versie van het OS geïnstalleerd kunnen worden. Bij Linux moet je het telkens met de meegeleverde versie of hooguit een nieuwere versie doen. Je kunt niet zoals onder Windows een oudere versie pakken.

Voorbeeld Virtualbox: de versie meegeleverd met Ubuntu 16.04 vereist geen VT-x (wat niet op een C2D E7200 zit), die in 20.04 wel. Maar het blijkt onmogelijk om de oude versie in 20.04 te installeren waardoor ik dus geen Virtualbox meer kan gebruiken. Op dezelfde PC met Windows 10 kan het wél om de oude versie te pakken.

[Hero of Time]

Versies e.d. komt allemaal vanwege afhankelijkheden. Je zal voor PCSX vast en zeker zelf kunnen compileren en ipv dynamisch linken wat standaard gedaan wordt, statisch gaan linken zodat de libraries bij je package zitten. En als je het zelf gaat compileren, kan je het gewoon in een map laten staan, heb je geen root rechten nodig om het te 'installeren' en is het ook nog eens portable naar nieuwere Ubuntu versies.

Voor VirtualBox gaat die vlieger minder snel op, omdat het dieper in het systeem zit, namelijk op kernel niveau. Dan heb je naast de standaard libraries die het vereist (de versie in 16.04 kan bijvoorbeeld niet overweg met de Qt versie in 20.04) ook nog te maken met de kernel zelf. Er komen regelmatig updates op VB omdat het anders geen kernel module kan bouwen. Pak een versie van vorig jaar, die gaat niet op kernel 5.8 werken bijvoorbeeld. Dus de versie van Ubuntu 16.04 kan niet overweg met de kernel die in 18.04 zit, en dus al helemaal niet die van 20.04.

Bij Windows is er zo ontiegelijk veel backwards compatible, dat zelfs je VB6 programmaatje dat je ooit op Windows 98 had nu nog zou kunnen gebruiken. Maar iets ingewikkelders, zoals MS Office, is een ander verhaal. Kan jij Office '97 of 2000 op Windows 10 20H2 installeren, laat staan starten? Dat gaat niet, want er is voor die delen van het OS al te veel verandert of niet eens meer beschikbaar.

Het houdt een keer op. Je kan dus niet het allernieuwste OS met de allerlaatste versie van libraries draaien en verwachten dat software van >5 jaar geleden nog functioneert. Andersom ook, je kan niet verwachten dat software van vandaag op een OS van >5 jaar oud gaat werken.

Wil je echt iets dat met een specifieke versie werkt en blijft werken, dan moet je dat systeem uiteindelijk eens offline halen en stand-alone gebruiken. En 'offline' kan ook simpelweg de default gateway verwijderen zijn, om op die manier geen internettoegang te hebben.