Testbericht unter Linux

[Flo Zille]

Der memory leak mit Proton 7 wird wohl mit dem nächsten Proton 7-Release abgestellt sein, dann steht einer stundenlangen Kassel-Hamburg-Fahrt hoffentlich auch mit "nur" 16 GB RAM oder weniger nichts mehr im Wege (wenn man dxvk in Proton abschaltet oder per dxvk.conf das neue 64-bit-dxvk-Grafikproblem beseitigt).

[Fabian H.]

"libusb-1.0.so.0: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden"

Es muss libusb in der 32-Bit-Variante installiert sein. Weiß nicht, wie man das bei Manjaro macht.

libusb war eigentlich in der 32bit Version installiert. Nach einer Neuinstallation wird auch alles gefunden.
Aber jetzt kam ein neues Problem:
Der Web Installer gibt mir eine "Zugriffsverletzung bei Adresse 7CCB27FC. Lesen von Adresse FFFFFFFF." aus.
Die Konsole sieht jetzt so aus:

Code: Alles auswählen

007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
Bitte 'wine winecfg' aufrufen und unter 'Drives' eine neue virtuelle Festplatte mit folgenden Einstellungen anlegen:
 - Path: <Pfad, an dem der Zusi-USB-Stick eingehängt ist>
 - Type: Floppy disk  [zum Anzeigen dieses Feldes auf "Show Advanced" klicken].
Auch dann, wenn Wine schon eine virtuelle Festplatte mit demselben "Path" angelegt hat!
Nach Ende der Installation kann die virtuelle Festplatte wieder entfernt werden.

Bitte mit Enter-Taste bestätigen, dass die Einstellungen so sind wie beschrieben.

0110:fixme:thread:GetThreadUILanguage : stub, returning default language.
0110:fixme:nls:RtlGetThreadPreferredUILanguages 00000038, 00CAD9D4, 00000000 00CAD9FC
0110:fixme:nls:get_dummy_preferred_ui_language (0x38 0x407 00CAD9D4 00000000 00CAD9FC) returning a dummy value (current locale)
0110:fixme:nls:RtlGetThreadPreferredUILanguages 00000038, 00CAD9D4, 027BA680 00CAD9FC
0110:fixme:nls:get_dummy_preferred_ui_language (0x38 0x407 00CAD9D4 027BA680 00CAD9FC) returning a dummy value (current locale)
0110:fixme:system:NtUserSystemParametersInfo Unknown action: 8220
0110:fixme:wtsapi:WTSRegisterSessionNotification Stub 0001007E 0x00000000
0110:fixme:uxtheme:BufferedPaintInit Stub ()
0110:fixme:system:EnableNonClientDpiScaling (00010090): stub
0110:fixme:system:EnableNonClientDpiScaling (000100A6): stub
0120:fixme:imm:ImeSetActiveContext (000000000002002A, 0): stub
0120:fixme:imm:ImmReleaseContext (0000000000020036, 000000000002002A): stub
0110:fixme:imm:ImeSetActiveContext (00010076, 1): stub
0110:fixme:imm:ImmReleaseContext (000100A6, 00010076): stub
0110:fixme:richedit:editor_handle_message EM_SETMARGINS: stub
0110:fixme:richedit:editor_handle_message EM_SETEDITSTYLE: stub
0058:fixme:nsi:ipv6_forward_enumerate_all not implemented
0058:fixme:nsi:ipv6_forward_enumerate_all not implemented
0110:fixme:wincodecs:BitmapScaler_Initialize unsupported mode 4
device 0: class 9, manufacturer 3, product 2
 - bus 4, device 1
 - configuration 0
  - interface 0
   - altsetting 0
device 1: class 0, manufacturer 1, product 2
 - bus 3, device 3
 - configuration 0
  - interface 0
   - altsetting 0
  - interface 1
   - altsetting 0
device 2: class 0, manufacturer 1, product 2
 - bus 3, device 2
 - configuration 0
  - interface 0
   - altsetting 0
  - interface 1
   - altsetting 0
  - interface 2
   - altsetting 0
device 3: class 9, manufacturer 3, product 2
 - bus 3, device 1
 - configuration 0
  - interface 0
   - altsetting 0
device 4: class 9, manufacturer 3, product 2
 - bus 2, device 1
 - configuration 0
  - interface 0
   - altsetting 0
device 5: class 0, manufacturer 1, product 2
 - bus 1, device 3
 - configuration 0
  - interface 0
   - altsetting 0
 - reading from /sys/bus/usb/devices/1-5/serial

Grüße
Fabian

[Flo Zille]

Damit es nicht so aussieht, als ob ich dich ignoriere: Leider kann ich dazu nichts sagen.


Aber ein anderes Thema, das mir aufgefallen ist: Einige wenige Befehle bzw. Funkgespräche werden unter Wine nicht angezeigt, das Fenster bleibt weiß. Das betrifft Befehle, die nicht als HTML-Datei erstellt werden, sondern direkt als PNG-Datei (laut Zusi-Doki ist das nicht vorgesehen, "Die angezeigte Datei muss im html-Format erstellt sein und wird in einem in Zusi integrierten Fenster des Internet-Explorers angezeigt", funktioniert aber unter Windows). Ein betroffener Zug ist 79706 im Fahrplan Luitpoldhuette-Klardorf_2022_06Uhr-10Uhr.fpn, direkt am Anfang wenn von der Abstellung zum Bahnsteig rangiert werden soll.

Ein Workaround ist, mittels regedit im Wine-Präfix unter "HKEY_CLASSES_ROOT\MIME\Database\Content Type\image/png" einen Schlüssel "CLSID" mit dem gleichen Inhalt wie z.B. in "image/gif" anzulegen. Ist aber nicht für das "Upstreaming" in wine geeignet, weil unter Windows dieser Schlüssel für image/png auch nicht existiert.

Meine Versuche, einen unter Windows funktionierenden und unter Wine fehlschlagenden Test für das PNG-Laden in einem "ieframe" zu erstellen, den wine für die Anzeige der Befehle nutzt, haben mich dann beinahe in den Wahnsinn getrieben. Es schien einfach keine Konfiguration des Tests unter Windows zu laufen. Bis ich dann gestern bemerkt habe, dass es unter Windows 10 eben manchmal tatsächlich auch nicht funktioniert: Während das Windows auf meinem eigenen Rechner, der meistens Ubuntu ausführt, PNG-Dateien in einem ieframe völlig problemlos anzeigt und auch das Erstellen eines funktionierenden Tests daher leicht ist, weigert sich der andere Windows 10-Rechner im Haushalt, den ich i.d.R. für die wine-Tests nutze, beharrlich. Statt die PNG-Datei anzuzeigen, erscheint nur eine weiße Seite und es öffnet sich stattdessen ein Download-Dialog für die PNG-Datei. Deshalb schlugen dort auch die ganzen Test-Bastelversuche bei nicht sichtbarem Fenster immer fehl. Hier hat jemand das gleiche Phänomen in einer anderen Software bemerkt.

Meine aktuelle Theorie für die Sache ist jetzt, dass Zusi normalerweise das Webview2 nutzt, welches auf Edge basiert und kein Problem mit PNGs hat (das hat Carsten ja für 3.5 bekanntgegeben, wenn ich mich richtig erinnere, und wir haben jetzt auch WebView2Loader.dll-Dateien). Nur wenn Edge nicht verfügbar ist, wie wohl eben bei Nutzung mit Wine, gibt es einen Fallback auf die alte Internet Explorer-basierte "IWebBrowser2"-Lösung. Und hier implementiert zumindest Wine derzeit die Variante, dass PNG-Dateien nicht funktionieren, so wie das wohl teilweise auch unter Windows der Fall zu sein scheint, aber irgend eine Konfiguration gibt es, mit der es dann doch funktioniert – so wie auf meiner Win10-Installation – und vielleicht löst Zusi diese Konfiguration ja auch irgendwie programmseitig aus.

Das doofe an der Situation ist jetzt, dass man die wine-Leute immer am besten von einer Änderung überzeugen kann, wenn man einen automatisierten Wine-Test hat, der demonstriert, dass etwas auf Windows funktioniert und unter Wine nicht. Das dürfte in dem Fall jetzt schwierig werden, denn tatsächlich würde der Test ja auch unter Windows nicht immer funktionieren, falls ich nicht noch herausfinde, wie man Windows zuverlässig davon abbringen kann, die Datei nur zum Download anzubieten. Vielleicht kann man auf recht umständliche Art einen abgespeckten Test basteln, der nur einen Teil der momentan für ieframe-Tests üblichen Dinge prüft (unter Wine gibt es beim PNG-Versuch derzeit einen expliziten Fehler, aber unter Windows nicht, denn es kommt ja immerhin zumindest erfolgreich der Datei-Download-Dialog).

[Carsten Hölscher]

Also ist in dem Fahrplan als Befehlsdatei direkt die png-Datei angegeben? Das wäre dann wirklich falsch, es soll immer eine html-Datei sein.

Carsten

[Leonard K.]

Das ist so in der Strecke konfiguriert (auch, um die Anzahl der Dateien zu reduzieren). Ich kann aber bei Gelegenheit mal die 14 HTML-Dateien für die Befehler erstellen und in der Strecke entsprechend anpassen.

[schorlemischer]

Hallo zusammen,

Aber jetzt kam ein neues Problem:
Der Web Installer gibt mir eine "Zugriffsverletzung bei Adresse 7CCB27FC. Lesen von Adresse FFFFFFFF." aus.

Kann ich bestätigen. Da ich mein Tagesziel einer funktionierenden Zusi Installation auf meiner Linux Maschine aber unbedingt erreichen wollte, hab ich versucht den Fehler einzugrenzen und habe sogar etwas gefunden: In serial.cpp#L100 des Hilfsprogrammes ist ein DEBUG Aufruf. Ich kann mit meinen stark limitierten C++-Kenntnissen nicht erklären warum, aber als ich den Aufruf ausgebaut habe, lief der Installer weiter

Viele Grüße
schorlemischer

[Johannes]

Danke, ich hab den Aufruf rausgenommen -> Version 0.14. Auf was für einer Linux-Distribution und mit welcher Wine-Version bist du unterwegs?

[schorlemischer]

Hi Johannes,

bei mir läuft aktuell Arch Linux mit Kernel 6.2.6 und wine 8.4 staging.

[Paneologe]

Moin,

ich möchte hier auch meinen Testbericht von der Steam-Version von Zusi 3 unter openSUSE 15.4 mit Proton 7.0 anhängen.

CPU:
AMD Ryzen 7 2700X Eight-Core Processor
Grafik:
VGA compatible controller: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (rev a1)
nvidia-glG05-470.161.03-lp154.59.1.x86_64

A) Vulkan-Bugfix:
erstellung von dxvk.conf wie unter https://www.forum.zusi.de/viewtopic.php ... 11#p344411 beschrieben war notwendig.

B) Das Öffnen der Konfiguration verursacht folgenden Fehler:

Die Bilder unten rechts werden nicht geladen, sonst ohne weitere Auswirkungen

C) Das Beenden der Simulation verursacht meist Probleme, nach Auswertung der Fahrt bleibt es im Simulator-Bild hängen, das nochmalige "Beenden" verursacht diverse Fehlermeldungen (bei Bedarf kann ich Details nachreichen) - Das Beenden der Anwendung ist nur über "kill" oder über Steam-Button "STOP" möglich.

D) Die Zusidateiverwaltung bringt eine Fehlermeldung, der Zusi-Server werde nicht erreicht. Somit nicht nutzbar

sonst keinerlei Probleme mit Zusi 3 oder ZusiDisplay.
Zusimeter und Zusistart habe ich nicht zum laufen gebracht.

Viele Grüsse

[Flo Zille]

Zu den Problemen mal der aktuelle Stand:

A) Falls die Leute von dxvk gnädig sind und die Erweiterung der "Handelt es sich hier um Zusi?"-Abfrage auf die "ZusiSim.64.exe" akzeptieren, sollte das dann auch wieder ohne dxvk.conf funktionieren. So ganz glücklich ist wohl keiner mit dieser Lösung, nur gibt es derzeit glaub ich keine bessere.
B) Ich nutze ein auf wine 8.3 basierendes Proton (proton_tkg_8.3.r0.g575f6f67), und dort ist das Problem wohl gelöst, jedenfalls bei mir nicht mehr reproduzierbar. Hoffentlich somit dann auch mit einem Proton 8.0 von Valve, das vielleicht ja irgendwann mal kommt.
C) Ist mir glaube ich schon länger nicht mehr begegnet, auch mit Proton 7 nicht, aber ich meine mich daran zu erinnern – weiß nicht genau, ob ich da nur Glück hatte.
D) Also die normalen Updates sollen wir Steam-Nutzer ja ohnehin nicht über die Dateiverwaltung installieren, habe da also noch nie etwas ausprobiert. Aber unter "Verwaltung" -> "Verwaltung Add-Ons" erscheint bei mir eine Liste von eingereichten Add-Ons (aktuell nur ein 422), die ich dann mit meinem 8.3-basierten Proton auch herunterladen kann.

Ich würde noch anmerken, dass die aktuelle Proton 7-Version von Valve einen üblen ZusiDisplay-Memory Leak verursacht. Der wird aber mit dem nächsten Proton-Release (egal ob 7 oder 8) behoben. Und eine Zugwende macht glaube ich in Proton 7 noch die integrierten Displays kaputt, in 8 sollte es klappen. Außerdem bringt Proton 8 Performance-Verbesserungen für die integrierten ZusiDisplays (neue zlib-Version und schwächere PNG-Komprimierung).