Testbericht unter Linux

Hier kann alles Allgemeine rund um Zusi 3 gefragt und beantwortet werden. Neuigkeiten zum Programm werden hier erscheinen.
Nachricht
Autor
Benutzeravatar
Christian Gründler
Beiträge: 2209
Registriert: 04.10.2003 13:27:48
Wohnort: Brühl (Baden)

Wine 5.0

#341 Beitrag von Christian Gründler »

Leichtsinnigerweise :O bin ich auf Wine 5.0 gegangen (aus dem Repository von winehq.org; mein BS ist noch Mint 19.2, war also wg. libfaudio etwas hakelig). Verwenden wollte ich mein vorhandenens Wineprefix, das ich zuletzt mit Wine 4 genutzt habe. Das funktioniert grundsätzlich auch, aber das 3D-Fenster im Editor ist völlig vergurkt:

Code: Alles auswählen

0009:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
0009:err:winediag:load_gssapi_krb5 Failed to load libgssapi_krb5, Kerberos SSP support will not be available.
0009:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B8G8R8A8_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B8G8R8X8_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B10G10R10A2_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B5G6R5_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B5G5R5A1_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B5G5R5X1_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B8G8R8A8_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B8G8R8X8_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B10G10R10A2_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B5G6R5_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B5G5R5A1_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B5G5R5X1_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B8G8R8A8_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B8G8R8X8_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub!
[...]
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_REF, src_format WINED3DFMT_B5G5R5A1_UNORM, dst_format WINED3DFMT_B5G6R5_UNORM stub!
0009:fixme:d3d:wined3d_check_device_format_conversion wined3d 0x20a0580, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_REF, src_format WINED3DFMT_B5G5R5X1_UNORM, dst_format WINED3DFMT_B5G6R5_UNORM stub!
0009:fixme:d3d:wined3d_query_gl_create Unhandled query type 0x4.
002f:fixme:d3d:state_linepattern_w Setting line patterns is not supported in OpenGL core contexts.
Bevor ich jetzt ein neues Wineprefix aufsetze zu und versuche, Zusi3 darin zum Laufen zu bringen, natürlich die Frage an dier Spezialisten: lässt sich das Problem auch einfacher lösen?

Danke und Gruß

Christian

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#342 Beitrag von Johannes »

Was heißt denn vergurkt? Die fixme:d3d-Meldungen habe ich auch, ohne Einschränkung der Funktionalität.

Benutzeravatar
Christian Gründler
Beiträge: 2209
Registriert: 04.10.2003 13:27:48
Wohnort: Brühl (Baden)

Re: Testbericht unter Linux

#343 Beitrag von Christian Gründler »

Johannes hat geschrieben:Was heißt denn vergurkt?
So sieht's aus:

Bild

Diese Menüleiste mitten im 3D-Fenster gehört zu dem dahinter (aber nicht genau an dieser Stelle) liegenden Terminal, aus dem heraus ich Zusi starte.

Oder so :confused: :

Bild

Diese über das Fenster verteilten Schnippsel stammen vom linken Rand meines Desktops: in der richtigen Höhe, aber immer blockweise versetzt.
Zuletzt geändert von Christian Gründler am 20.06.2020 14:47:24, insgesamt 2-mal geändert.

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#344 Beitrag von Johannes »

Nein, das Problem hatte ich bisher nicht. Wenn du aber eh am Updaten bist: Aktuell ist Wine 5.11, vielleicht hilft die Flucht nach vorne?

Benutzeravatar
Christian Gründler
Beiträge: 2209
Registriert: 04.10.2003 13:27:48
Wohnort: Brühl (Baden)

Re: Testbericht unter Linux

#345 Beitrag von Christian Gründler »

Johannes hat geschrieben:Aktuell ist Wine 5.11, vielleicht hilft die Flucht nach vorne?
Seufz. Eigentlich wollte ich Betaversionen ja immer vermeiden; aber natürlich werde ich das probieren, denn schlimmer kann es nicht werden. Meine anderen Wine-Programme laufen übrigens einwandfrei, darunter ein Kartenviewer, der auch eine grafische Ausgabe hat (aber rein 2D und sicher nicht so komplex wie Zusi).

mitropam
Beiträge: 166
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#346 Beitrag von mitropam »

Ich hätte da noch ein anderes Problem. Obwohl ich vcredist_x64.exe und windowsdesktop-runtime-3.1.5-win-x64.exe längst installiert habe, ist die Dateiverwaltung der Meinung, dass dotnet core Framework noch zu installieren ist:

https://abload.de/img/zusierrornnken.png

?(
Zuletzt geändert von Carsten Hölscher am 28.12.2020 00:47:49, insgesamt 1-mal geändert.

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Testbericht unter Linux

#347 Beitrag von Carsten Hölscher »

Sie sucht für die Entscheidung in den entsprechenden registry-Einträgen:

HKEY_LOCAL_MACHINE\SOFTWARE\dotnet\Setup\InstalledVersions\x86\hostfxr\Version

Für die Windows 10-Version:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ReleaseID

Carsten

mitropam
Beiträge: 166
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#348 Beitrag von mitropam »

Sieht bei mir so aus:

Bild

Sollte ich den Wert vielleicht ändern?

Nächste Frage: Gibt es mit Zusi 3.4 irgendeinen Fortschritt bezüglich der Funktionalität von ZusiDisplay unter Linux?
Zuletzt geändert von mitropam am 12.07.2020 13:03:13, insgesamt 1-mal geändert.

Benutzeravatar
F. Schn.
Beiträge: 6629
Registriert: 24.10.2011 18:58:26

Re: Testbericht unter Linux

#349 Beitrag von F. Schn. »

mitropam hat geschrieben:windowsdesktop-runtime-3.1.5-win-x64.exe
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat

mitropam
Beiträge: 166
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#350 Beitrag von mitropam »

Ach herrje, da habe ich wohl die falsche Version gegriffen. Danke. :)

Und irgendetwas Neues bezüglich ZusiDisplay unter Linux?
Zuletzt geändert von mitropam am 12.07.2020 13:40:46, insgesamt 1-mal geändert.

Benutzeravatar
Jens Haupert
Beiträge: 4911
Registriert: 23.03.2004 14:44:34
Aktuelle Projekte: http://www.zusidisplay.de
Wohnort: Berlin
Kontaktdaten:

Re: Testbericht unter Linux

#351 Beitrag von Jens Haupert »

mitropam hat geschrieben:Und irgendetwas Neues bezüglich ZusiDisplay unter Linux?
Von meinter Seite nicht.

Grüße
Jens

mitropam
Beiträge: 166
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#352 Beitrag von mitropam »

Seit dem letztem Update kommt beim Starten diese Fehlermeldung:

Bild

Und einige Buchfahrpläne sehen nun so aus:

Bild

?(

Benutzeravatar
F. Schn.
Beiträge: 6629
Registriert: 24.10.2011 18:58:26

Re: Testbericht unter Linux

#353 Beitrag von F. Schn. »

Sind die corefonts installiert?
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat

mitropam
Beiträge: 166
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#354 Beitrag von mitropam »

Ja.

Benutzeravatar
Bernhard K.
Beiträge: 167
Registriert: 23.06.2020 22:29:41
Aktuelle Projekte: Uni
Wohnort: VzG 5900, Km 9,4
Kontaktdaten:

Re: Testbericht unter Linux

#355 Beitrag von Bernhard K. »

Hat jemand ne Idee, woran es liegen könnte, dass ZusiDisplay bei mir nur dann abstürtzt, wenn Zusi schon läuft? (Nutze Proton)

Code: Alles auswählen

❯ "/run/media/bernhard/Manjaro Volume 2/SteamLibrary/steamapps/common/Proton 5.13/proton" run "/run/media/bernhard/Manjaro Volume 2/SteamLibrary/steamapps/common/ZUSI 3 - Aerosoft Edition/_Tools/ZusiDisplay/ZusiDisplay.exe"
Starte ZusiDisplay
2020-12-05 00:44:02.8541|INFO|MMI.Program|ZusiDisplay 3.4.7.0
2020-12-05 00:44:02.8670|INFO|MMI.Program|CMDs: 
Fatal error. 0xC0000005
   at System.Drawing.SafeNativeMethods+Gdip.GdipGetGenericFontFamilySansSerif(IntPtr ByRef)
   at System.Drawing.FontFamily.GetGdipGenericSansSerif()
   at System.Drawing.FontFamily.CreateFontFamily(System.String, System.Drawing.Text.FontCollection)
   at System.Drawing.Font.Initialize(System.String, Single, System.Drawing.FontStyle, System.Drawing.GraphicsUnit, Byte, Boolean)
   at System.Drawing.Font..ctor(System.String, Single, System.Drawing.FontStyle, System.Drawing.GraphicsUnit, Byte)
   at MMI.SplashScreen.InitializeComponent()
   at MMI.SplashScreen..ctor(EBuLaTools.Authority)
   at MMI.Program.Main(System.String[])
wine: Call from 7BC2BB88 to unimplemented function KERNEL32.dll.RaiseFailFastException, aborting
Unhandled exception. System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
   at System.Drawing.SafeNativeMethods.Gdip.GdipGetGenericFontFamilySansSerif(IntPtr& fontfamily)
   at System.Drawing.FontFamily.GetGdipGenericSansSerif()
   at System.Drawing.FontFamily.CreateFontFamily(String name, FontCollection fontCollection)
   at System.Drawing.Font.Initialize(String familyName, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet, Boolean gdiVerticalFont)
   at System.Drawing.Font..ctor(String familyName, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet)
   at MMI.SplashScreen.InitializeComponent()
   at MMI.SplashScreen..ctor(Authority authority)
   at MMI.Program.Main(String[] args)
wine: Unimplemented function KERNEL32.dll.RaiseFailFastException called at address 7BC2BB88 (thread 0220), starting debugger...
Can't attach process 021c: error 5

mitropam
Beiträge: 166
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#356 Beitrag von mitropam »

Flo Zille hat geschrieben:Ich selbst habe nur die Steam-Version und kann Proton daher auch nur mit der Steam-Version testen. Proton ist letztlich "nur" eine Zusammenstellung von wine mit einigen Valve-Patches (insbesondere esync und fsync) sowie "vorinstallierten" Extras wie dxvk und wine-mono.

Es gibt ein wohl ganz nützliches Programm namens "Lutris". Damit sollte es möglich sein, auch ohne Steam eine Proton-ähnliche Variante von wine auf relativ einfachem Weg zu nutzen. Wenn man dort als "Runner" wine und z.B. "lutris-5.2" als wine-Version auswählt, kann man in den Optionen jedenfalls auch dxvk und esync per Klick aktivieren und deaktivieren. Falls Alwin nichts dagegen hat, könnten wir vielleicht Informationen dazu im ZusiWiki zusammentragen, wobei ich mich wie gesagt auf die Steam-Version beschränken müsste.

Wobei dxvk ab Version 1.5.2 das Problem hat, dass viele Führerstände flackern, da hilft dann auch die höhere Framerate nichts. In den erweiterten Lutris-Runner-Einstellungen kann man die dxvk-Version aber offenbar auf 1.5.1 setzen. d9vk für DirectX9 wird dann nicht benötigt, denn ab dxvk 1.5 ist d9vk bereits mit integriert. Das Flacker-Problem will sich der Autor noch genauer anschauen, er hat aber viel zu tun.

Es gibt auch wieder gute Neuigkeiten:
- In der nächsten wine-Version 5.3, die in einer Woche erscheinen sollte, ist ein Patch von mir enthalten, der in gdiplus.dll die Funktionen GdipSaveAdd und GdipSaveAddImage nachrüstet. Damit werden auch Buchfahrpläne mit mehreren Seiten korrekt erzeugt und es ist hoffentlich künftig nicht mehr nötig, per winetricks die gdiplus von Microsoft zu installieren.
- Ebenfalls in wine 5.3 hat Alex Henrie die Funktion GetTcp6Table ordentlich in iphlpapi.dll implementiert. Damit kann ZusiDisplay nun manuell gestartet werden, ohne dass es mit der "GetActiveTcpConnections"-Fehlermeldung (oder so) gleich wieder abstürzt.

Außerdem habe ich nun auch wine-mono überreden können, die integrierten Displays anzuzeigen. Dafür muss ein Patch von Zebediah Figura angewendet und noch etwas erweitert werden (leider führt das, wie im Kommentar dort angedeutet, zu einem memory leak, da muss wohl eine Lösung gefunden werden bevor es offiziell in wine integriert werden kann), und einen Bug in mono muss man auch noch umschiffen. Außerdem besteht jetzt noch das Problem, dass manche Displays (z.B. das links im 612er) sich nur sehr selten aktualisieren und ich konnte noch nicht herausfinden, wie ich wine dazu überreden kann, etwas weniger schmallippig zu den im ZusiDisplay-Prozess auftretenden Problemen zu sein. Bis auf weiteres ist es also vermutlich sinnvoller, wie bisher mittels winetricks dotnet45 (oder welche Version auch immer nötig war) von Microsoft zu installieren. Bei der Microsoft-Variante wird offenbar ein portabler, in C# implementierter Threadpool für die IO-Callbacks genutzt, statt den Win32 Threadpool zu nutzen, der in wine derzeit noch keine IO-callbacks unterstützt. Daher ist dafür auch kein wine-Patch nötig.


Meine io_uring-Experimente für bessere named pipes und somit bessere ZusiDisplay-Integration in Wine haben gefühlt schon eine Verbesserung gebracht, allerdings haben sie mit Kernel 5.4 auch zu starken memory leaks geführt, die selbst nach Beendigung aller Zusi- und wine-Prozesse nicht verschwanden. Es waren immer noch zahlreiche ring-Kernel-Threads aktiv, was nur durch Neustarts zu beheben war. Daran weiterzubasteln habe ich erstmal verschoben, zumal die Änderungen wohl sowieso wenig Chancen haben dürften, im offiziellen wine zu landen. Ich lade den aktuellen Stand demnächst mal auf github und schaue mir das in ein paar Kernelversionen nochmal an. Nach jedem vierten Test wegen vollem RAM neu starten zu müssen ist etwas nervig.
Eigentlich hatte ich das ja schon länger vor, aber nun hat man Zeit für Dinge, für die man sonst keine Zeit hat. Also habe ich mal Lutris bei mir installiert. Aber entweder habe ich etwas falsch verstanden oder es klappt noch nicht so richtig. Jedenfalls sieht ein 411-Führerstand derzeit bei mir so aus:

https://abload.de/img/screenshot_20201212_2tnkl7.png

Also kein Unterschied zur Installation mit Wine. Allerdings lässt esync auch nicht aktivieren. Ich verwende Zusi in der Standard-Ausführung (nicht Aerosoft).
Zuletzt geändert von Carsten Hölscher am 16.12.2020 21:27:54, insgesamt 1-mal geändert.

Benutzeravatar
Bernhard K.
Beiträge: 167
Registriert: 23.06.2020 22:29:41
Aktuelle Projekte: Uni
Wohnort: VzG 5900, Km 9,4
Kontaktdaten:

Re: Testbericht unter Linux

#357 Beitrag von Bernhard K. »

Ich habe auch sehr viel mit der Steamversion herumprobiert und habe das Problem mit den dunklen Displays auch nur auf die Named-Pipe zwischen ZusiDisplay und Zusi selbst isolieren können.
Wenn man ZusiDisplay nämlich extra startet und die Verbindung über TCP aufbaut, funktioniert alles normal. Leider gibt es kaum brauchbare Informationen zu Named-Pipes in Wine, weswegen ein Debuggen des Problems noch ein größeres Projekt werden wird...

mitropam
Beiträge: 166
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#358 Beitrag von mitropam »

ZusiDisplay extra starten mit Verbindung über TCP/IP funktioniert auch in der Nicht-Steam-Version.
In den Releasenotes zu Wine 6.0rc1 steht etwas über den Support von named Pipes, aber in der Doku finde ich nichts dazu.

Benutzeravatar
Bernhard K.
Beiträge: 167
Registriert: 23.06.2020 22:29:41
Aktuelle Projekte: Uni
Wohnort: VzG 5900, Km 9,4
Kontaktdaten:

Re: Testbericht unter Linux

#359 Beitrag von Bernhard K. »

mitropam hat geschrieben:ZusiDisplay extra starten mit Verbindung über TCP/IP funktioniert auch in der Nicht-Steam-Version.
In den Releasenotes zu Wine 6.0rc1 steht etwas über den Support von named Pipes, aber in der Doku finde ich nichts dazu.
Könntest du mal probieren, ob diese Version das problem löst?

mitropam
Beiträge: 166
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#360 Beitrag von mitropam »

Jupp, irgendetwas hat sich getan! Nach dem Start des Zuges erscheinen einige Sekunden später tatsächlich die Displays!!!

https://abload.de/img/screenshot_20201216_28xj1k.png :)

Vielmehr passiert aber noch nicht. Wenn man mit dem Zug losfährt, ändert sich die Darstellung nicht - es wird nicht mal die Geschwindigkeit angezeigt. Dafür geht die fps-Rate ganz schön in die Knie. Drückt man die Pfeil-nach-oben-Taste, werden alle Displays dunkel und bleiben es auch.

Aber immerhin, ein kleiner Fortschritt!
Zuletzt geändert von Carsten Hölscher am 16.12.2020 21:27:21, insgesamt 1-mal geändert.

Antworten