Closed Zirias closed 4 years ago
Könnt ihr mir ein FreeBSD Distributionen oder Derivate empfehlen wo eine GUI schon installiert ist. vorzugsweise KDE Möchte gerne FreeBSD in VBox laufen lassen aber jetzt nicht viele Stunden damit verbringen das System von grundauf einzurichten. Oder hab ihr links wo das gut beschrieben ist?
Kleines unschönes update: Bei mir funktioniert es auch mit dem Fix und SDL_AUDIODRIVER=oss
nicht, aber vielleicht ist das lokaler Murks. Dabei ist mir aber aufgefallen, dass die SingleApplication unzuverlässig ist wenn wirklich nur noch ein kill -9
hilft (was hier gerade der Fall ist) -- dann bleibt das shared memory zurück und ich muss es mit ipcs
finden und mit ipcrm -m
von Hand löschen, um emu64 wieder starten zu können. Aber das ist vielleicht ein Fall für ein neues issue :o
Ich denke ich habe selbst sehr zuverlässigen "SingleApplication" code, der mit QLocalServer arbeitet, aber plattformabhängig (windows/posix) ein bisschen unterschiedliche Dinge tut -- da gibt's auch die Möglichkeit, die "SingleApplication" auf einen einzelnen User zu beschränken, was ich meistens sinnvoll finde, ich will ja nicht auf nem multiuser terminal server emu64 nicht starten können, nur weil es ein anderer User gerade benutzt. Eventuell bastle ich da die Tage mal einen pull-request :)
FreeBSD ist FreeBSD, da gibt's keine Distributionen. Es gibt aber ein FreeBSD-Derivat speziell für Desktop user namens GhostBSD, das könntest du mal testen :) Habe es selbst nie probiert...
Für "native" FreeBSD ist es nicht allzu schwierig, man muss eben ne Menge Pakete selbst installieren. Hier gibt's ein nettes "Tut" mit ner Menge zeug, was man sinnvollerweise konfigurieren kann: https://cooltrainer.org/a-freebsd-desktop-howto/ -- ist nicht mehr GANZ aktuell, da wir ja inzwischen bei Version 12.1 sind.
Genau an der Sache arbeite ich gerade (Shared Memory). Funktioniert bei mir jetzt unter Linux aber die Windows Version hängt da irgendwie noch, bin aber noch dran. Felix, was steht den als SDL_Error in deiner Log? Immer noch Fragmentsize ?
Ich lasse das hier einfach noch offen, evtl. bekommen ẃir das bei dir auch noch hin und finden die Ursache. :)
Ich erhalte einen Dialog "Fehler beim Installieren der C64 Klasse" direkt über dem Splash und danach hilft nur noch kill -9
... das Log fällt dann recht kurz aus:
*** Emu64 FreeBSD Binary File ***
Emu64 Version: 5.0.18
>> Data Path = /usr/local/share/emu64
>> System Temp Path: /tmp
>> Emu64 Temp Path: /tmp/emu64
>> Screenshot Path = /home/felix/.config/emu64/screenshots
>> INI System wurde erzeugt: /home/felix/.config/emu64/emu64.ini
>> INI System was created: /home/felix/.config/emu64/emu64.ini
>> Sprachmenü wurde erstellt.de
>> Translator wurde installiert: Systemsprache = de
>> Ein RomSet Verzeichnis ist vorhanden
>> romsetPath = /home/felix/.config/emu64/romsets/
>> Das Screenshot Verzeichnis ist vorhanden
>> VideoPal Klasse wurde installiert
>> C64 Klasse wurde gestartet...
>> GfxPath = /usr/local/share/emu64/gfx/
<< ERROR: Fehler beim installieren von SDL2
Auf der Konsole kommt noch
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 1217, resource id: 2107408, major code: 40 (TranslateCoords), minor code: 0
Wegen shared memory: muss es unbedingt shared memory sein? Falls du auch mit einer named pipe arbeiten könntest hätte ich da n Vorschlag, siehe edit weiter oben.
edit -- nach dem Fehler suchen lohnt wohl nicht, gerade vice getestet, oss via SDL scheint auf meinem System gerade generell kaputt zu sein. Eine Verbesserung wäre bei emu64 in so einem Fall eine hilfreiche Fehlermeldung und sauberes beenden :) Vice sagt mir genauer, was los ist.
Es scheint das er bei dir schon dort aussteigt wo SDL_Init aufgerufen wird. Ja ich werde das über den Tag fixen. Du kannst ja das mit aktivierten OSS testen ob er dann trotzdem sauber beendet. ;) Ok dann ist die Audiosache soweit i.O. denke ich.
Mit dem basteln warte mal noch bis ich das beenden sauber hinbekommen habe, dann kannst du daran rumwerkeln wenn du magst. Sonst kommen wir uns evtl. mit dem merge ins gehege ;) Auf einen einzelnen User zu beschränken fände ich auch Sinvoll, soweit hatte ich bis her gar nicht gedacht wegen Terminalserver ;)
GhostBSD sieht schon mal gut aus, werd ich gleich mal testen.
Patch zum Port vorgeschlagen: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=213276&action=diff
@KarlBSD wäre toll, wenn du den auch mal testen könntest und im FreeBSD PR Feedback geben, damit wir möglichst bald ein korrigiertes Paket haben :) Da bei mir OSS mit SDL ganz kaputt ist kann ich es leider nicht selbst testen...
(einfach im PR das attachment runterladen und in /usr/ports
mit patch <[patchfile]
anwenden, dann den port neu bauen und installieren)
@KarlBSD alternativ gibt's den fertig gepatchten Port auch hier: https://github.com/Zirias/zfbsd-ports/tree/master/current/emulators/emu64 :)
Kurze Info an Felix:
Habe GhostBSD in VBox Installiert, musste zwar etwas händisch die VBox Guest Tools einrichten, aber nun läuft das sauber in VBox.
Habe dann emu64 per pkg installiert. Selber fehler wie KarlBSD. Wieder deinstalliert, und emu64 via Port erstellt. Lief dann natürlich auch noch nicht, da der enthaltene Patch den Fix noch nicht drin hatte. Dann habe ich deinen Patch nach emu64/files runter geladen und neu erstellt, und voila funktioniert. Also dein Patch für den Port läuft würde ich sagen.
Noch mal Danke an alle, dass der Fehler so schnell gefunden und korrigiert wurde. Ich finde es toll, dass ich jetzt auch unter FreeBSD einen C64 emulieren kann. Auch mein USB-Joystickadapter funktioniert auf Anhieb. Falls es mal etwas unter FreeBSD zu testen gibt, dann könnt ihr euch gern melden.
Gern geschehen, schön das er soweit läuft. Das freut mich zu hören :)
@ThKattanek danke für den zweiten Test :) Leider hab ich keine Commit-Rechte, also muss ich abwarten, bis jemand anders den korrigierten Port committed.
Im Normalfall sollte ich ja selbst als Port-Maintainer so einen Fehler entdecken, dummerweise lief es bei mir, weil ich SDL in ner modifizierten Konfiguration benutze mit https://www.freshports.org/audio/sndio/ als default backend statt direkt OSS. Dass sowas am Ende relevant dafür ist, ob der Emulator läuft oder nicht, damit kann ja nun keiner rechnen :o Auf Linux wäre das wahrscheinlich NIE aufgefallen ... da gibt's zwar noch ne kommerzielle OSS-Implementierung dafür (opensound.com), aber das nutzt ja kaum jemand :)
Ich denke jedenfalls das issue kannst du tatsächlich zumachen, wenn zwei Leute die Lösung bestätigen, dann stimmt sie auch :)
Ich räume das ganze gerade noch auf! Sauberes beenden funktioniert jetzt wenn Fehler in der C64Class auftreten und Emu64 hängt sich nicht mehr weg. Wenn ich fertig damit bin, füge ich den branch issu#192 mit dem master zusammen. Und dann mache ich hier zu :)
Schöne Zusammenarbeit! :+1:
Fehler behoben und Schluss jetzt :)
Hallo, ich habe hier einen Bugreport: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245395 -- kann es selbst leider nicht nachvollziehen. Anhand der
xwininfo
Ausgabe sieht man, dass das Fenster wirklich komplett fehlt, und nicht etwa einfach versteckt (bzw unmapped) ist. Habe hier im Moment keine Idee, wo man suchen kann -- ich kann das Problem ebenfalls auf FreeBSD 12.1 nicht nachvollziehen.Werde noch nach einem kompletten
emu64.log
fragen, vielleicht kann man damit eingrenzen, was schiefgeht.