Testbericht unter Linux

Hier kann alles Allgemeine rund um Zusi 3 gefragt und beantwortet werden. Neuigkeiten zum Programm werden hier erscheinen.
Nachricht
Autor
Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33430
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Testbericht unter Linux

#521 Beitrag von Carsten Hölscher »

Bitte mal die Shifttaste sachgerecht zum Einsatz bringen.

Carsten

sgpch
Beiträge: 2
Registriert: 06.10.2022 16:23:50

Re: Testbericht unter Linux

#522 Beitrag von sgpch »

Tschuldigung.. Aber, hab mittlerweile eine Fehlermeldung:

wine: Unhandled stack overflow at address 7BC4E410 (thread 002c), starting debugger...
002c:err:virtual:virtual_setup_exception stack overflow 1220 bytes in thread 002c addr 0x7bc29ff2 stack 0x480b3c (0x480000-0x481000-0x600000)


Und zwar wenn ich mit "protontricks -c 'wine _Tools/ZusiDisplay/ZusiDisplay.exe' 1040730" versuche zusidisplay manuell zu starten. Toll.. Das hilft warscheinlich nicht weiter!

Trotzdem hätte ich gern hilfe wie ich das zum Laufen bekommen könnte.. trotz meiner schlechten Rechtschreibung - Bitte!? :)

Edit: Mein System ist ein FX3850, 16gb Ram, AMD RX580 Grafikkarte Linux Mint 21 (Ubuntu ableger Distribution), Ich nutze den Opensource Grafiktreiber und Vulkan. Hab auch schon andere Proton versionen versucht. Nix.

Edit2: Ok nein das war nur wegen einer alten Wine version.. Hat nix mit Proton zu tun... hmm..

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

Re: Testbericht unter Linux

#523 Beitrag von Christian Gründler »

Die Netzwerk-Installation von Zusi 3.5 scheitert derzeit daran, dass setup.bash die Datei wbemdisp32.dll.so erwartet, aber wbemdisp.dll.so mitgeliefert wird. Reicht es, den Dateinamen zu ändern, oder sind das unterschiedliche Dateien?

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

Re: Testbericht unter Linux

#524 Beitrag von Johannes »

Christian Gründler hat geschrieben: 02.02.2023 09:10:49 Die Netzwerk-Installation von Zusi 3.5 scheitert derzeit daran, dass setup.bash die Datei wbemdisp32.dll.so erwartet, aber wbemdisp.dll.so mitgeliefert wird. Reicht es, den Dateinamen zu ändern, oder sind das unterschiedliche Dateien?
Reicht, den Namen zu ändern; ist ein Fehler von mir. Hab's gleich mal korrigiert.

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

Re: Testbericht unter Linux

#525 Beitrag von Christian Gründler »

Danke!

Jetzt hänge ich am nächsten Problem. In setup.bash heißt es:

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].


Ich habe unter Wine 8.0 ein ein neues Prefix angelegt (Zusi 3.4 will ich vorläufig in Reserve halten). winecfg zeigt mir den Stick unter Laufwerk F: an; im Linux-Dateisystem ist das /media/<username>/ZUSI3HOBBY.

Ich habe dann mit dem Buchstaben E:, /media/<username>/ZUSI3HOBBY und Floppy disk noch mal gemacht: Das ist streng genommen keine virtuelle Festplatte, denn die fangen nach meiner vagen Erinnerung mit // an. Allerdings schreibst Du Pfad, an dem der Zusi-USB-Stick eingehängt ist., insofern wäre /media..... richtig. Einziger Unterschied zu F: ist, dass mir von winecfg bei E: kein Device angezeigt wird.

Die Netzwerkinstallation startet, zeigt mir zunächst drei grüne Haken, bricht auf der zweiten Seite vor dem Download aber wegen Lizenzproblemen ab. Auf dem Stick gibt es mit Datum von heute eine Datei .windows-serial mit dem Inhalt "0"; keine Ahnung, ob die schon vorher da war.

Mal wieder ratlos

Christian

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

Re: Testbericht unter Linux

#526 Beitrag von Johannes »

Irgendwelche Ausgaben in der Kommandozeile?

Ist der Typ von E: immer noch "Floppy disk"? Hatte das schon, dass Wine mir das zurückgestellt hat.

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

Re: Testbericht unter Linux

#527 Beitrag von Christian Gründler »

Johannes hat geschrieben: 02.02.2023 16:05:37 Ist der Typ von E: immer noch "Floppy disk"? Hatte das schon, dass Wine mir das zurückgestellt hat.
Das scheint nicht verloren zu gehen.

winecfg zeigt mir für C: die Seriennummer 4300000 und für E: bzw. F: 45000000. Bei E: ist die Nummer ausgegraut und unveränderlich.

Wine meldet in der Shell:

wine: Read access denied for device L"\\??\\E:\\", FS volume label and serial are not available.
wine: Read access denied for device L"\\??\\F:\\", FS volume label and serial are not available.
wine: Read access denied for device L"\\??\\G:\\", FS volume label and serial are not available.
wine: Read access denied for device L"\\??\\Z:\\", FS volume label and serial are not available.

Insofern dürfte die Seriennummer für den Stick eine "Hausnummer" sein.

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

Re: Testbericht unter Linux

#528 Beitrag von Christian Gründler »

Bei Johannes funktioniert es, bei mir funktioniert es trotz einiger Tests und Tricksereien weiterhin nicht. So recht erklälich ist das nicht, daher meine Frage: hat schon irgendjemand eine Zusi-Web-Installation mit den Hilfsmitteln von Johannes erfolgreich durchgeführt? War etwas besonders zu beachten, oder hat es vielleicht sogar "out of the box" funktioniert?

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

#529 Beitrag von Bernhard K. »

Für einen ordentlichen Betrieb mit 3.5, muss man sich alle Schriftarten von Windows in den Wineprefix kopieren und zusätzlich WineD3D mit OpenGL als Renderer verwenden.
D.h. bei Verwendung von Proton/Steam-Version die Variable PROTON_USE_WINED3D=1 %command% setzen.

Andernfalls bekommt man diesen schönen Anblick...
Bild

Achimd1
Beiträge: 12
Registriert: 13.05.2019 20:12:30

Re: Testbericht unter Linux

#530 Beitrag von Achimd1 »

Hallo an alle und einen schönen Sonntag,
Update auf 3.5 verlief problemlos, aber es gibt Probleme; zwei Screenshots anbei, wo die Fehler zu sehen sind.
Ich habe schon die verschiedenen Grafiktreiber ausprobiert,jedoch keine Änderung.
Es könnte vielleicht, meine Vermutung, an Zusi Display liegen; wenn man die verschiedenen Ansichten wechselt sind die Fehler weg, dafür sind aber nicht mehr alle Displays aktiv!
Viele Grüße,
Achim

Bild
Bild

Flo Zille
Beiträge: 203
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#531 Beitrag von Flo Zille »

Als ich da vor längerer Zeit mal geschaut hatte, hat sich Zusi nicht ganz an die DirectX-Regelungen für den von Zusi angeforderten "DISCARD" SwapEffect gehalten (der ist nötig, um MSAA nutzen zu können, und sorgt wohl auch für bessere Performance). Der Führerstand wurde nicht, wie eigentlich nötig, in jedem Frame komplett neu gezeichnet, sondern nur die Elemente des Führerstands, die sich seit dem letzten Frame geändert haben. Dadurch gab es damals in dxvk Probleme, denn anders als die meisten Windows-DirectX-Implementierungen nutzt dxvk eben aus, dass es den gezeichneten Inhalt eines Frames komplett "vergessen" darf, nachdem es damit fertig ist.

Ich hab damals eine Option "d3d9.noExplicitFrontbuffer" in dxvk eingebaut, welche eben diese DISCARD-Sache so handhabt, dass der alte Frame-Inhalt nicht "weggeworfen", sondern als Grundlage für den nächsten Frame herangezogen wird, und diese Option wird standardmäßig für alle Programme "ZusiSim.exe" aktiviert. Allerdings heißt das Programm ja jetzt "ZusiSim.64.exe", somit wird diese Option nicht mehr standardmäßig aktiviert.

Wer diese Grafikprobleme mit dem 64-Bit Zusi hat, der kann mal versuchen, die dxvk-Option manuell zu aktivieren. Dazu muss man eine Datei "dxvk.conf" anlegen, (edit:) unter Steam im Zusi-Hauptverzeichnis ("ZUSI 3 - Aerosoft Edition"), mit folgendem Inhalt:

Code: Alles auswählen

d3d9.noExplicitFrontBuffer = True
Zuletzt geändert von Flo Zille am 28.02.2023 20:09:36, 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

#532 Beitrag von Bernhard K. »

Ich hab gestern ein Ticket dafür aufgemacht, anscheinend gibt es noch andere Programme, die dieses Problem haben: https://github.com/doitsujin/dxvk/issues/3250
Ist natürlich noch die Frage offen, will man wieder den Workaround einbauen oder lieber auf einen allgemeingültigen Fix warten?

Flo Zille
Beiträge: 203
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#533 Beitrag von Flo Zille »

Ah, interessant dass es jetzt auch eine andere Anwendung betrifft. Scheint aber ja derzeit auch nicht wirklich einer "ordentlichen" Lösung entgegen zu gehen. Mir ist damals jedenfalls auch keine "gute" Lösung dafür eingefallen.

Ich erinnere mich nicht mehr genau, aber ich glaube das Problem, welches dxvk mit dieser "wir rendern abwechselnd in verschiedene rendertargets, statt immer in das gleiche, wie es wohl unter Windows im Fenstermodus meistens üblich ist"-Sache löst, besteht darin, dass mit Vulkan jedenfalls zum damaligen Zeitpunkt kein direkter Zugriff auf die Framebuffer in der Swapchain möglich war. Also wenn man Vulkan einen Frame zum Anzeigen gegeben hat, dann ist der aus Sicht der Anwendung weg und die swapchain ist so eine Art Black Box, um die sich Vulkan selbst kümmert ohne Zugriffsmöglichkeiten von außen (außer "hier hast du ein neues Bild, zeig das mal an"). Für DirectX9 braucht man aber, falls jemand später "IDirect3DDevice9::GetFrontBufferData()" oder "IDirect3DDevice9::GetBackBuffer()" aufruft, auch danach noch Zugriff auf die einzelnen Framebuffer in der Swapchain. Deshalb wechselt dxvk glaube ich die rendertargets zusätzlich zur "automatischen black-box" Vulkan-Swapchain auch noch selbst reihum durch, und wenn die Anwendung dann eine Kopie eines Frames aus der Swapchain haben möchte, dann kann der darüber noch ausgelesen werden.

Jetzt scheint Zusi kein wirkliches Interesse an Inhalten der Swapchain zu haben und GetFrontBufferData oder GetBackBuffer daher nicht zu nutzen (?), und Zusi nutzt auch nur 1 Backbuffer. Im Fenstermodus bedeutet das wohl unter Windows meistens, dass zum Präsentierzeitpunkt der Inhalt des Backbuffers für die Anzeige kopiert wird und es geht mit dem Rendern des nächsten Frames weiter, ohne den Backbuffer zu tauschen. Das Kopieren muss im Fenstermodus glaube ich ohnehin passieren, weshalb es für die Performance wohl egal ist (denn der Fensterinhalt muss ja durch einen compositor mit den anderen Fenstern und den Fensterrahmen, Titelleisten usw. irgendwie in einem neuen Buffer zusammengemischt werden). In dxvk wird hingegen zu dem Zeitpunkt ganz klassisch der Frontbuffer mit dem Backbuffer vertauscht, der neue Frontbuffer wird Vulkan zur Anzeige überreicht und der neue Backbuffer als neues rendertarget konfiguriert, damit auch dxvk selbst später noch Zugriff auf die aktuellen Bufferinhalte der Swapchain hat.

Das Problem bei einer "allgemeingültigen" Lösung ist jetzt glaube ich, dass die "sowieso zwingend nötige Kopie aus dem Backbuffer" unter Vulkan eben durch die "black box Vulkan-Swapchain" passiert. Man kann also für die "GetFrontBufferData"-Implementierung nicht auf den Frontbuffer dieser Vulkan-Swapchain zugreifen, so wie es unter Windows mutmaßlich gelöst ist. Und zu jedem Präsentierzeitpunkt zusätzlich noch selbst eine Kopie des Backbuffers in einen selbst verwalteteten "Frontbufferersatz" durchzuführen, nur für den Fall, dass vielleicht jemand GetFrontBufferData() aufruft, kostet glaube ich unnötig Performance. Daher gibt es wohl keine performante Lösung, die einerseits GetFrontBufferData() ermöglicht, andererseits aber in jedem Frame den gleichen Buffer als rendertarget nutzt. Außer wenn Vulkan inzwischen eine Extension hat, mit der man auf den aktuellen Frontbuffer der Swapchain zugreifen kann.

Edit: Nach etwas googlen bin ich mir gar nicht mehr so sicher, ob man wirklich nicht auf die Inhalte der Vulkan-Swapchain zugreifen kann. Falls man also GetFrontBufferData und GetBackBuffer irgendwie darüber implementieren könnte, wäre es vielleicht möglich, die separate "Nachbildung" der Swapchain innerhalb von dxvk wieder zu entfernen und dann innerhalb von dxvk doch immer den gleichen buffer als rendertarget zu nutzen. Aber ich vermute irgendwie, dass die dxvk-Leute das damals schon gemacht hätten, wenn es möglich gewesen wäre…?

blauergrashalm
Beiträge: 2
Registriert: 27.01.2023 18:06:48

Re: Testbericht unter Linux

#534 Beitrag von blauergrashalm »

Hallo,
ich hatte vor einigen Wochen schon mal probiert Zusi (unter Windows und Linux) neu zu installieren, bin dann aber in beiden Fällen am Updateprozess gescheitert. Hab mich gefreut, dass man jetzt direkt "frisch" die 3.5 installieren kann.
Mein Ziel ist erstmal unter Linux eine lauffähige Version hinzubekommen. Nach dem Start des Tools bekomme ich 3 grüne Hacken. Nach klick auf "Installation" hingegen kommt die Fehlermeldung "Stick passt nicht zur Lizenz der Zusi-Installation
" und der letzte grüne Hacken wird zu einem roten X. Dabei hatte ich im Rahmen meiner vorherigen Installationsversuche den Stick mehrfach neu beschrieben. Ich nutze Manjaro Linux, wine 8.1.
Die Ausgabe aus dem Terminal lautet wie folgt:

Code: Alles auswählen

$> zusi_linux_installer/setup.bash "C:\\Users\\*********\\Temp\\ZusiWebInstaller.exe"
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0080:fixme:wineusb:add_usb_device Interface 1 has 7 alternate settings; using the first one.
0080:fixme:wineusb:add_usb_device Interface 3 has 2 alternate settings; using the first one.
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:wineusb:query_id Unhandled ID query type 0x5.
007c:fixme:wineusb:query_id Unhandled ID query type 0x5.
007c:fixme:wineusb:query_id Unhandled ID query type 0x5.
007c:fixme:wineusb:query_id Unhandled ID query type 0x5.
007c:fixme:wineusb:query_id Unhandled ID query type 0x5.
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, 027C19B0 00CAD9FC
0110:fixme:nls:get_dummy_preferred_ui_language (0x38 0x407 00CAD9D4 027C19B0 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
0110:fixme:commdlg:IServiceProvider_fnQueryService Interface {e07010ec-bc17-44c0-97b0-46c7c95b9edc} requested from unknown service {e07010ec-bc17-44c0-97b0-46c7c95b9edc}
0110:fixme:shell:ViewModeToListStyle ViewMode 0 not implemented
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1026, a003, 0, 00CAE6DC)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1026, a004, 0, 00CAE6DC)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1025, a003, 1, 00CAE6DC)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1025, a004, 1, 00CAE6DC)
0110:fixme:nstc:NSTC2_fnSetControlStyle2 mask & style (0x00000004) contains unsupported style(s): 0x00000004
0110:fixme:commdlg:IServiceProvider_fnQueryService Interface {e07010ec-bc17-44c0-97b0-46c7c95b9edc} requested from unknown service {e07010ec-bc17-44c0-97b0-46c7c95b9edc}
0110:fixme:shell:ViewModeToListStyle ViewMode 0 not implemented
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1026, a003, 0, 00CAE32C)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1026, a004, 0, 00CAE32C)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1025, a003, 1, 00CAE32C)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1025, a004, 1, 00CAE32C)
wine: Read access denied for device L"\\??\\D:\\", FS volume label and serial are not available.
wine: Read access denied for device L"\\??\\E:\\", FS volume label and serial are not available.
wine: Read access denied for device L"\\??\\F:\\", FS volume label and serial are not available.
wine: Read access denied for device L"\\??\\G:\\", FS volume label and serial are not available.
wine: Read access denied for device L"\\??\\Z:\\", FS volume label and serial are not available.
0110:fixme:commdlg:IServiceProvider_fnQueryService Interface {e07010ec-bc17-44c0-97b0-46c7c95b9edc} requested from unknown service {e07010ec-bc17-44c0-97b0-46c7c95b9edc}
0110:fixme:shell:ViewModeToListStyle ViewMode 0 not implemented
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1026, a003, 0, 00CAE32C)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1026, a004, 0, 00CAE32C)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1025, a003, 1, 00CAE32C)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1025, a004, 1, 00CAE32C)
0110:fixme:shell:IShellBrowser_fnOnViewWindowActive stub, 039FA128 (03A20AB0)
0110:fixme:commdlg:IServiceProvider_fnQueryService Interface {e07010ec-bc17-44c0-97b0-46c7c95b9edc} requested from unknown service {e07010ec-bc17-44c0-97b0-46c7c95b9edc}
0110:fixme:shell:ViewModeToListStyle ViewMode 0 not implemented
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1026, a003, 0, 00CAE48C)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1026, a004, 0, 00CAE48C)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1025, a003, 1, 00CAE48C)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 039FA128 (2, 1025, a004, 1, 00CAE48C)
0110:fixme:shell:IShellBrowser_fnOnViewWindowActive stub, 039FA128 (03A1BE28)
0110:fixme:shell:IShellBrowser_fnOnViewWindowActive stub, 039FA128 (03A1BE28)
0058:fixme:nsi:ipv6_forward_enumerate_all not implemented
0058:fixme:nsi:ipv6_forward_enumerate_all not implemented
device 0: class 9 manufacturer 0 product 0
 - configuration 0
  - interface 0
   - altsetting 0
device 1: class 9 manufacturer 3 product 2
 - configuration 0
  - interface 0
   - altsetting 0
device 2: class 9 manufacturer 0 product 0
 - configuration 0
  - interface 0
   - altsetting 0
device 3: class 9 manufacturer 3 product 2
 - configuration 0
  - interface 0
   - altsetting 0
device 4: class 9 manufacturer 1 product 2
 - configuration 0
  - interface 0
   - altsetting 0
device 5: class 9 manufacturer 3 product 2
 - configuration 0
  - interface 0
   - altsetting 0
device 6: class 239 manufacturer 1 product 2
 - configuration 0
  - interface 0
   - altsetting 0
  - interface 1
   - altsetting 0
   - altsetting 1
   - altsetting 2
   - altsetting 3
   - altsetting 4
   - altsetting 5
   - altsetting 6
  - interface 2
   - altsetting 0
  - interface 3
   - altsetting 0
   - altsetting 1
device 7: class 0 manufacturer 1 product 2
 - configuration 0
  - interface 0
   - altsetting 0
  - interface 1
   - altsetting 0
device 8: class 0 manufacturer 1 product 2
 - configuration 0
  - interface 0
   - altsetting 0
  - interface 1
   - altsetting 0
device 9: class 0 manufacturer 1 product 2
 - configuration 0
  - interface 0
   - altsetting 0
  - interface 1
   - altsetting 0
   - altsetting 1
  - interface 2
   - altsetting 0
   - altsetting 1
  - interface 3
   - altsetting 0
device 10: class 9 manufacturer 1 product 2
 - configuration 0
  - interface 0
   - altsetting 0
   - altsetting 1
device 11: class 0 manufacturer 4 product 5
 - configuration 0
  - interface 0
   - altsetting 0
  - interface 1
   - altsetting 0
   - altsetting 1
  - interface 2
   - altsetting 0
   - altsetting 1
  - interface 3
   - altsetting 0
  - interface 4
   - altsetting 0
   - altsetting 1
   - altsetting 2
  - interface 5
   - altsetting 0
device 12: class 0 manufacturer 0 product 1
 - configuration 0
  - interface 0
   - altsetting 0
 - reading from /sys/bus/usb/devices/3-11/serial
device 13: class 0 manufacturer 1 product 2
 - configuration 0
  - interface 0
   - altsetting 0
More than one USB mass storage device found, taking first one.
device 14: class 9 manufacturer 3 product 2
 - configuration 0
  - interface 0
   - altsetting 0
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
Hat da jemand eine Idee, was ich falsch mache?
Danke auf jedenfall für die wahnsinnige Mühe die hier reingesteckt wird!

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

Re: Testbericht unter Linux

#535 Beitrag von Johannes »

Nutzt du die allerneuste Version von gestern Abend (v0.10)? Habe die Tage mit Christian intensive Fehlersuche und -korrektur betrieben.

Außerdem scheinst du mehrere USB-Speicher angeschlossen zu haben. Vielleicht nimmt er einfach den falschen. Probier mal, nur den Zusi-Stick anzuschließen.

blauergrashalm
Beiträge: 2
Registriert: 27.01.2023 18:06:48

Re: Testbericht unter Linux

#536 Beitrag von blauergrashalm »

Johannes hat geschrieben: 18.02.2023 10:51:13 Nutzt du die allerneuste Version von gestern Abend (v0.10)? Habe die Tage mit Christian intensive Fehlersuche und -korrektur betrieben.

Außerdem scheinst du mehrere USB-Speicher angeschlossen zu haben. Vielleicht nimmt er einfach den falschen. Probier mal, nur den Zusi-Stick anzuschließen.
Danke für die schnelle Rückmeldung. Ja ich habe auch gerade eben extra nochmal frisch dein Tool von deinem Github heruntergeladen. Habe jetzt mal alle externen USB Geräte die ich nicht zwingend brauche aus gesteckt und auch den USB Stick direkt in einem USB Port des Motherboards gestöpselt (war vorher an einem Hub). Gleiches Verhalten, auch die Meldung, dass mehrere USB Geräte gefunden wurden bleibt, dabei war nie ein zweiter Stick/SD-Karte eingesteckt. Habe eine zweite Festplatte, die ist aber via SATA angeschlossen. Hier die Ausgabe aus lsusb:

Code: Alles auswählen

Bus 002 Device 002: ID 8087:8000 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 05e3:0612 Genesys Logic, Inc. Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 009: ID 0bf8:1028 Fujitsu Siemens Computers Fujitsu Keyboard
Bus 003 Device 008: ID 046d:c332 Logitech, Inc. G502 Proteus Spectrum Optical Mouse
Bus 003 Device 006: ID 0d8c:0014 C-Media Electronics, Inc. Audio Adapter (Unitek Y-247A)
Bus 003 Device 004: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 003 Device 010: ID 058f:6387 Alcor Micro Corp. Flash Drive
Bus 003 Device 007: ID 05e3:0745 Genesys Logic, Inc. Logilink CR0012
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Habe jetzt in der Zwischenzeit auch meine Windowspartition reaktiviert, dort hat die Installation geklappt. Also falls du jetzt auch keine Ideen hast wärs nicht all zu schlimm, ich hab eine Alternative.

Achimd1
Beiträge: 12
Registriert: 13.05.2019 20:12:30

Re: Testbericht unter Linux

#537 Beitrag von Achimd1 »

@Flo Zille

dein Tipp mit "d3d9.noExplicitFrontBuffer = True hat leider nicht den Erhofften Erfolg gebracht, immer noch das gleich Problem!

Ich habe mal "Proton Experimental" in Steam aktiviert; damit verschwindet aber wenigstens schon mal die Zugriffsverletzung Im Modul "ZusiSim.64.exe".

Viele Grüße,
Achim

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

Re: Testbericht unter Linux

#538 Beitrag von Christian Gründler »

Bernhard K. hat geschrieben: 15.06.2022 12:53:02 .net Core Desktop 3.1.5, sonst nichts. Den Rest macht Wine-mono.
Gilt das auch unter 64 Bit?

Bei einem ersten Test (noch ohne natives .NET) mit der 64-Bit-Verwaltung werden mir die installierten Programmversionen anscheinend richtig angezeigt, allerdings erhalte ich die Fehlermeldung "Fehler beim Einfügen einer Zeile In RichEdit".

Kopieren der Windows-Textfonts nach .../windows/Fonts bringt keine Abhilfe. Das ist möglicherweise nur ein Schönheitsfehler, aber irritirend.

Sicherheitshalber nachgefragt: Ist es normal, dass mir bei der Versionsübersicht für die Add-Ons "000201_korrekturen.za7" als bereits installiert angezeigt wird? Mein WebInstaller stammt vom 12. Februar 21:05 Uhr.

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

#539 Beitrag von Bernhard K. »

Achimd1 hat geschrieben: 18.02.2023 22:17:58
dein Tipp mit "d3d9.noExplicitFrontBuffer = True hat leider nicht den Erhofften Erfolg gebracht, immer noch das gleich Problem!
Bei mir klappt das auch, muss also irgendwas bei dir nicht richtig konfiguriert sein.
Christian Gründler hat geschrieben: 19.02.2023 10:34:55
Bernhard K. hat geschrieben: 15.06.2022 12:53:02 .net Core Desktop 3.1.5, sonst nichts. Den Rest macht Wine-mono.
Gilt das auch unter 64 Bit?
Du musst ab 3.5, ja .NET 6.0 installieren (was bei Zusi dabei ist)
--
Bernhard

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

Re: Testbericht unter Linux

#540 Beitrag von Christian Gründler »

Bernhard K. hat geschrieben: 19.02.2023 13:58:09 Du musst ab 3.5, ja .NET 6.0 installieren (was bei Zusi dabei ist)
Danke!

Ich habe also .NET 6.0 nachinstalliert wie von Carsten unter viewtopic.php?t=18448&start=26 beschrieben.

Der Simulator startet, Auswahl von Fahrplan und Zug ist möglich. Nach dem Laden der Module geht es aber nicht weiter; ps -ef meldet "[ZusiSim.64.exe] <defunct>".

stderr von wine meldet (nur die Zeilen ohne "fixme"):

Code: Alles auswählen

0108:err:winediag:ntlm_check_version ntlm_auth was not found. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
0108:err:ntlm:ntlm_LsaApInitializePackage no NTLM support, expect problems
0108:err:virtual:virtual_setup_exception stack overflow 2128 bytes addr 0x170058c0d stack 0x21c07b0 (0x21c0000-0x21c1000-0x25c0000)
Der 3D-Editor scheint zu funktionieren, identifiziert beim Anklicken eines Streckenelements aber immer ein falsches (zielmlich weit entfernt).

Antworten