Hallo Sebastian, Danke für Deine Statusmeldung und deiner Arbeit die Du da rein steckst.
Aktuell hänge ich noch an dem Problem fest. Die letzten beiden Wochenenden habe ich genutzt, um den Grund des Problems zu erforschen.
Nun fand ich Schritt für Schritt heraus, dass das Problem irgendwo bei der Erzeugung eines X-Server an einer anderen tty (üblicherweise tty7) mittels sddm zusammen hängt. Dabei schmiert AMDGPU-Pro komplett ab und sddm versucht immer wieder den X-Server neuzustarten, sobald er abgeschmiert ist. Also, hing ich quasi in einer Endlosschleife fest.
Als nächstes wollte ich mal testweise den X-Server mit root-Rechten mit "startx" starten. Und das hat eigenartigerweise funktioniert und sah dann den Plasma-Desktop und konnte auch ein 3D-Spiel starten. Also, lag es wohl irgendwo an den Dateirechten, auch udev habe ich in Verdacht. Dachte ich bis jetzt zumindest...
Dann startete ich den X-Server über einen lokalen User per "startx", dabei schmiert er mir ab, weil er keine Verbindung zu ":0" aufbauen konnte. Was für mich überhaupt nicht ganz schlüssig war.
Dann tippte ich in der Konsole folgenden Befehl ein: # WINDOWMANAGER=startkde startx -- -keeptty
Damit startete der X-Server auch für den User im aktuellen tty. Auch die 32-bit AMDGPU-Pro Libraries funktionieren mit Steam tatlos.
Hier vermute ich, dass sddm in Verbindung mit dem AMDGPU-Pro ein Rechte Problem hat, wenn er eine XSession auf der tty7 aufbauen will. Im Moment weiß ich aktuell nicht, wo genau ich noch suchen muss, um die richtige Schraube zu ziehen.
Ich fürchte ich kann dazu leider wenig beitragen, da ich rund um sddm wenig Ahnung habe. Aber, tty7 ist doch eigentlich das Standardterminal auf dem X gestartet wird, oder? Das scheint bei mir ja soweit zu gehen. Nach der Installation vom amdgpu-pro mit dem Skript von AMD kam der ganz normale sddm login Bildschirm. Allerdings habe ich natürlich keine 32 Bit Bibliotheken. Trat das Problem bei dir erst auf, nachdem du auch die 32 Bit Bibliotheken auf das System kopiert hast? Was mir hier allerdings gerade aufgefallen ist, wenn ich auf Terminal 1-6 per ALT+Fn schalte, bekomme ich nur noch einen schwarzen Bildschirm anstatt des Text-Logins. Das war vor Installation das amdgpu-pro definitiv anders. Aber ich glaube das gleiche Problem hatte ich irgendwann schon einmal mit dem firegl auf einer älteren openSUSE Distribution mit einer älteren Grafikkarte.
Bei mir läuft der Treiber ja soweit ganz gut, nur würde ich ihn halt für Steam benötigen und da gaht halt garnichts ohne die 32 Bit Versionen.
Ja, ich bin ganz bei dir und würde auch gerne lieber heute als morgen damit fertig sein. Auch alle anderen openSUSE-User warten auf die angepasste AMDGPU-Pro Variante für openSUSE Leap 42.2, um z.B. Steam-Apps, OpenCL-Apps oder VDPAU-Apps starten zu können.
Ich bin an dem Punkt angekommen, wo ich definitiv Hilfe benötige.
VDPAU habe ich hier mit mplayer zum Laufen bekommen. Habe dazu das mesa-amdgpu-pro-vdpau-drivers aus dem Repository nachinstalliert welches das AMD Installations-Skript lokal eingerichtet hat. Musste dabei allerdings eine Abhängigkeit zu einem mesa-filesystem package ignorieren und danach noch folgende Links setzen: ln -s /opt/amdgpu-pro/lib64/vdpau/libvdpau_amdgpu.so.1.0.0 libvdpau_amdgpu.so.1 ln -s /opt/amdgpu-pro/lib64/vdpau/libvdpau_amdgpu.so.1.0.0 libvdpau_amdgpu.so.1.0 ln -s /opt/amdgpu-pro/lib64/vdpau/libvdpau_amdgpu.so.1.0.0 libvdpau_amdgpu.so.1.0.0 ln -s /opt/amdgpu-pro/lib64/vdpau/libvdpau_amdgpu.so.1.0.0 libvdpau_amdgpu.so Das habe ich auch bereits als Bug-Report AMD gemeldet, vielleicht hilft es ja. Ansonsten, wenn ich irgendwie helfen kann, versuche ich es gerne. Ich habe hier einen Rechner mit RX480 Karte auf dem ich testen kann. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org