AMD Catalyst 12.6 (fglrx 8.980) wurde veröffentlicht. Das Skript makerpm-amd-12.6.sh steht ab sofort zum Download zur Verfügung und unterstützt 11.4 und 12.1.
[UPDATE 29.07.2012]
Soeben habe ich ein Patch für den fglrx-Treiber implementiert und ist nun auf dem Kernel 3.5.0 lauffähig. Dieser Patch stammt zum Teil aus dem Beta-Treiber und wurde von mir für AMD Catalyst 12.6 zurückportiert.
[/UPDATE 29.07.2012]
[UPDATE 17.07.2012]
Ich habe das makerpm-amd-Skript aktualisiert. Hierzu habe ich eine kleine Ergänzung vorgenommen, um den Paketbau auf openSUSE 12.2 zu ermöglichen. Auf openSUSE 12.2 wurde das rpm-Paket in „rpm“ und „rpm-build“ aufgeteilt. Das Paket „rpm-build“ muss installiert sein. Ansonsten wird es vom Skript automatisch installiert.
[/UPDATE 17.07.2012]
Was ist neu?
Das Packaging Skript habe ich manuell aktualisieren müssen, da der Kernel-Patch für 3.4.0 und höher fehlte. AMD hat noch ein älteres Packaging Skript für diesen Release verwendet, obwohl ich bereits vor längerer Zeit für den 8.98 Zweig ein aktuelleres Packaging Skript in das GIT Repository eingeliefert habe.
Für Benutzer älterer AMD Grafikkarten (Radeon HD Serie 2000 – 4000) wird dringend die Installation dieses Treibers abgeraten. AMD stellt in nächster Zeit einen Legacy-Treiber zur Verfügung, dass definitiv neuerer als der AMD Catalyst 12.4 ist. Ein makerpm-amd-Skript für den Legacy-Treiber stelle ich zur Verfügung, sobald dieser auch veröffentlicht wurde.
In Sachen Hardware-Beschleunigung hat AMD auf meine Frage zum Status geantwortet. Interessanterweise ist die Antwort von AMD aus der geschlossenen Mailingliste auf Phroronix gelandet. AMD erklärt, dass MPEG-2 VLD und MPEG-4 Part2 (DivX) implementiert wurde. Jedoch benötigt das XvBA SDK ein Update, um das neue Feature verwenden zu können. H.264 Level 5.1 ist zwar implementiert, aber nicht scharf geschaltet. In der AMD Linux Community hat man den Schalter bereits ausfindig gemacht und muss entsprechend in der Konsole aktiviert werden.
aticonfig --set-pcs-u32=MCIL,HWUVD_H264Level51Support,1
Die Entwickler (FernetMenta und fritsch) vom XBMC-Fork, die speziell an der Implementierung der XvBA-Schnittstelle in XBMC zuständig sind, haben sich wegen einigen Problemen mit dem Treiber an mich gewendet. Da sie nicht wissen, an wen sie sich bei AMD wenden sollen. Offenbar haben sie einige Bugs an AMD gemeldet und bisher hatte sich noch keiner darum gekümmert. Kurzerhand habe ich meine Hilfe angeboten, die Fehlerberichte an AMD direkt über die geschlossene Mailingliste weiterzugeben. Seitdem wurden einige Bugs wie z.B. „ASIC hang happened“ und das HDMI/Audio-Problem auf einem HD-TV behoben. Mit den Entwickler von XBMC (XvBA) stehe ich weiterhin in Kontakt. Sobald AMD die XvBA SDK aktualisiert hat und die o.g. Formate für die Hardwarebeschleunigung öffentlich zur Verfügung stehen, werden die Entwickler die XvBA-Schnittstelle im XBMC-Fork an das XBMC-Upstream Projekt weitergeben. Somit erhält auch das ffmpeg Projekt die XvBA-Schnittstelle, was letztendlich für alle Video-Player mit der ffmpeg-Anbindung zugute kommt. Die Gehhilfe VA API / xvba-video wird dann auch nicht mehr länger benötigt.
Downloads:
- Skript: makerpm-amd-12.6.sh
- SHA1: makerpm-amd-12.6.sh.sha1
Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript
Über das makerpm-amd-Skript
Das Skript makerpm-amd-12.6.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.
Folgende Argumente können dem Skript übergeben werden:
-b | Nur das RPM-Package bauen (Standard) |
-c <type> | Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten) |
-d | Nur den AMD-Installer downloaden |
-i | Das RPM-Package bauen und installieren bzw. updaten |
-kms <yes|no> | Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren |
-nohw | Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM) |
-old2ddriver <yes|no> | den alten 2D-Treiber aktivieren oder deaktivieren |
-r|–report | erstellt ein Report und speichert diese in eine Datei namens amd-report.txt |
-u|–uninstall | entfernt AMD Catalyst restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene AMD-Dateien und -Verzeichnisse entfernt. Hinweis: Falls das Rebuild-Skript installiert wurde, wird es ebenfalls entfernt und das Initskript /etc/init.d/xdm wiederhergestellt. |
-ur|–uploadreport | wie Option –report nur zusätzlich wird der Report auf einem NoPaste-Service sprunge.us hochgeladen und gibt bei Erfolg den Link zurück. |
-h | Die Hilfe anzeigen lassen |
-V | Version des Skript anzeigen |
Hilfe, es funktioniert nicht!
Bitte haltet folgende Regel ein:
- Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
- Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
- In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.
Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-amd-12.6.sh herunter und erstellt einen Report von eurem System in der Konsole:
su -c 'sh makerpm-amd-12.6.sh -ur'
Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.
Feedbacks sind wie immer willkommen.
Hallo Sebastian,
zwei kleine Anmerkungen:
1. Du schreibst oben, daß der „ASIC hang happened“ Bug gemäß AMD gefixt worden sei. Zumindest ich kann das hier nicht bestätigen. Tritt nach wie vor auf. Ich teste seit Samstag (habe mir den neuen Treiber schon vorher besorgt und eingespielt), ob das Problem evtl. nicht auftritt, wenn beim Booten kein framebuffer device verwendet wird, also vga=normal und im grub gfxmenu deaktiviert ist. Sieht bislang gut aus. Hat aber noch nicht viel zu sagen – kann auch Zufall sein. Werde mich diesbezüglich später auf jeden Fall nochmal melden.
2. Support für Kernel 3.4.
Hier mußte ich zusätzlich folgenden Patch anwenden (CONFIG_X86_X32 ist hier deaktiviert):
diff -ur a/kernel-modules/fglrx/firegl_public.c b/kernel-modules/fglrx/firegl_public.c
— a/kernel-modules/fglrx/firegl_public.c 2012-07-02 13:16:56.000000000 +0200
+++ b/kernel-modules/fglrx/firegl_public.c 2012-06-29 12:02:10.332042995 +0200
@@ -267,7 +267,7 @@
const char BUILD_KERNEL_HAS_MODVERSIONS_CLEARED;
#endif
-#ifdef __SMP__
+#if CONFIG_SMP
const unsigned long KCL_SYSINFO_SmpSupport = 1;
const char BUILD_KERNEL_HAS_SMP_SET;
#else
@@ -2715,7 +2715,7 @@
/*****************************************************************************/
-#ifdef __SMP__
+#if CONFIG_SMP
static atomic_t cpus_waiting;
static void deferred_flush(void* contextp)
@@ -2731,7 +2731,7 @@
while (atomic_read(&cpus_waiting) > 0)
barrier();
}
-#endif /* __SMP__ */
+#endif /* CONFIG_SMP */
/** \brief Run a function on all other CPUs.
* \param func The function to run.
@@ -2747,7 +2747,7 @@
int ATI_API_CALL KCL_MEM_FlushCpuCaches(void)
{
-#ifdef __SMP__
+#if CONFIG_SMP
/* write back invalidate all other CPUs (exported by kernel) */
if (KCL_SmpCallFunction(deferred_flush, NULL, 1, 0) != 0)
panic(„timed out waiting for the other CPUs!\n“);
@@ -2763,7 +2763,7 @@
while (atomic_read(&cpus_waiting) > 0)
barrier();
-#else /* !__SMP__ */
+#else /* !CONFIG_SMP */
#if defined(__i386__) || defined(__x86_64__)
asm volatile („wbinvd“:::“memory“);
#elif defined(__alpha__) || defined(__sparc__)
@@ -2771,7 +2771,7 @@
#else
#error „Please define flush_cache for your architecture.“
#endif
-#endif /* !__SMP__ */
+#endif /* !CONFIG_SMP */
return 0;
}
@@ -4156,7 +4156,7 @@
{
unsigned int p;
KCL_DEBUG5(FN_FIREGL_KAS, „%d\n“, level_init);
– for_each_cpu_mask(p, cpu_possible_map)
+ for_each_possible_cpu(p)
{
KCL_DEBUG1(FN_FIREGL_KAS,“Setting initial execution level for CPU # %d\n“, p);
preempt_disable();
diff -ur a/kernel-modules/fglrx/firegl_public.h b/kernel-modules/fglrx/firegl_public.h
— a/kernel-modules/fglrx/firegl_public.h 2012-07-02 13:16:56.000000000 +0200
+++ b/kernel-modules/fglrx/firegl_public.h 2012-06-29 12:01:29.546044364 +0200
@@ -57,7 +57,7 @@
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,26)
#define PAGING_FAULT_SIGBUS_INT (unsigned long)NOPAGE_SIGBUS
#else /* LINUX_VERSION_CODE = KERNEL_VERSION(2,6,36)
+ void __user *ret = arch_compat_alloc_user_space(size);
+#else
void __user *ret = COMPAT_ALLOC_USER_SPACE(size);
+#endif
/* prevent stack overflow */
if (!access_ok(VERIFY_WRITE, ret, size))
Viele Grüße,
Klaus
Hallo Klaus,
zu 1.)
Anscheinend hat AMD dies erst ab fglrx 8.981 behoben. Dieser Treiber beinhaltet aber noch fglrx 8.980. Da scheint es noch nicht behoben worden zu sein. Ich habe soeben noch von einigen anderen User hilfreiche Bugmeldungen vom „ASIC hang happened“ und leite diese an AMD weiter.
zu 2.)
Die Unterstützung für Kernel 3.4.0 und höher habe ich bereits im aktualisierten Packaging Skript eingebaut. Dein o.g. Patch sieht irgendwie gruselig aus und dürfte bei parallel-installierten Kernel 3.3.x und weniger echte Probleme machen. Hast du ihn von irgendwoher kopiert?
Gruß
Sebastian
Hallo Sebastian,
Zu 1:
Der ASIC hang stellt sich bei mir so dar (z.B.):
– Xorg.0 läuft.
– Dann Xorg.1 starten (entweder über einen ssh-Login oder einfach über „neue Sitzung“ starten).
Xorg.0 wird scheinbar ordentlich „abgeschlossen“:
[ 1313.381] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 1313.382] (II) fglrx(0): Backup framebuffer data.
[ 1313.434] (II) fglrx(0): Backup complete.
Xorg.1 hängt dann hier:
[ 1313.377] (II) LoadModule: „fglrxdrm“
[ 1313.377] (II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
[ 1313.377] (II) Module fglrxdrm: vendor=“FireGL – AMD Technologies Inc.“
[ 1313.377] compiled for 1.4.99.906, module version = 8.98.2
[ 1313.377] (II) AMD Proprietary Linux Driver Version Identifier:8.98.2
[ 1313.377] (II) AMD Proprietary Linux Driver Release Identifier: 8.98
[ 1313.377] (II) AMD Proprietary Linux Driver Build Date: Jun 11 2012 11:57:59
[ 1313.377] (++) using VT number 8
In messages erscheint dann kurze Zeit später der ASIC hang.
Der ASIC hang tritt aber auch auf, wenn man z.B. s2ram ausführt und dort wahrscheinlich auf die Konsole geswitched werden soll.
Gibt es den 8.981 schon irgendwo? Der Bug ist nämlich extrem nervig! Zumal das Deaktivieren des Framebuffers auch nicht weiterhilft, wie ich nun bemerkt habe, wenngleich das Problem dann subjektiv weniger oft getriggert wird bei mir.
Zu 2:
Verstehe ich nicht. Ich habe mit dem hier runtergeladenen makerpm-amd-12.6.sh installiert (welches sich das passende packaging script nachgeladen hat. md5sum: 055fe5ecd9f75ad2e2a999e30283db79 amd-12.6-packaging-script.tar.bz2). Bekomme dann aber diesen Compile error:
CC [M] /home/klaus/fglrx/fglrx/2.6.x/firegl_public.o
/home/klaus/fglrx/fglrx/2.6.x/firegl_public.c: In function ‘kasInitExecutionLevels’:
/home/klaus/fglrx/fglrx/2.6.x/firegl_public.c:4159:5: error: ‘cpu_possible_map’ undeclared (first use in this function)
/home/klaus/fglrx/fglrx/2.6.x/firegl_public.c:4159:5: note: each undeclared identifier is reported only once for each function it appears in
/home/klaus/fglrx/fglrx/2.6.x/firegl_public.c:4159:5: warning: left-hand operand of comma expression has no effect
Daß der Patch nicht opimal ist, ist mir klar (ist für 3.4 only – aber da funktioniert er).
Die Darstellung hier ist sowieso krank. Tabs und blanks und Ähnliches sind ebenfalls kaputt.
Gruß,
Klaus
Hallo Sebastian,
nochmal zu 2:
ich habe gerade festgestellt, daß ich an dieser Stelle einen Bock geschossen habe – Deine Patches sind wie immer absolut ok! Hatte mich auch schon gewundert … .
Danke,
viele Grüße,
Klaus.
Hallo Sebastian,
vielen Dank für die viele Arbeit , die Du für uns leistest.
Ich habe heute den Grafikkartentreiber 12.6 mit makerpm-amd-12.6.sh heruntergeladen und installiert. Alles läuft prima aber unten recht ist ein Hinweis dauerhaft eingeblendet „AMD Unsupported Hardware“.
Habe im Wiki unter Support Hardware geprüft ob meine Grafikkarte unterstützt wird. Antwort: Ja
Bis Treiber 12.4 keine Anzeige mit Hinweis.
Meine Hardware:
Toshiba Satellite L755D, AMD A6-3400 M APU with Radeon(tm) 6250 HD Graphics, Kerne 4
BS:
openSUSE 12.1 x86_64, Kernel 3.4.4
Daher bitte ich Dich zu prüfen ob eine Lösung des Problems möglich ist oder ein Umstieg auf den freien Treiber von Nöten ist.
Vielen Dank
Sandra
Hallo Sandra,
ich habe mich mal nach einer Lösung umgehört. Es hilft, wenn man aus der öffentlichen Beta die control-Datei in /etc/ati/control kopiert, dann verschwindet das Wasserzeichen.
Ich habe vorsorglich, die betreffende Datei extrahiert und hochgeladen. Bitte eine Konsole aufmachen, mit su zu root werden und folgenden Befehl absetzen:
wget -N -O /etc/ati/control http://www.sebastian-siebert.de/downloads/amd-12.6-beta-control
Gruß
Sebastian
Hallo
noch eine Anmerkung dazu, wenn man das nicht macht das Wasserzeichen verschwinden lassen wird auch die integrierte Grafik nicht angesprochen sondern wie auch in meinem Fall mit dem A6-3400 Chip nur die diskrete.
Danach geht crossfire wieder.
ums zu testen kann man einfach mal
aticonfig –odgt –adapter=0,1
eingeben
Grüße
Peter
Hallo Sebastian,
herzlichen Dank für die schnelle Antwort und die schnelle Lösung meines Problems mit dem Wasserzeichen.
Der Lösungsweg hat sehr gut funktioniert und das Wasserzeichen ist nun weg.
Wird dieses Problem mit einem neuen Treiber wieder auftreten?
Viele Grüße aus Berlin,
Sandra
Hallo Sandra,
super, dass es geklappt hat. Danke für die Rückinfo.
AMD hat sicherlich eine veraltete Control-Datei in den AMD Catalyst 12.6 abgelegt. Das war gruseliges Versehen von einem AMD Mitarbeiter. In Zukunft sollte das im besten Fall vermieden werden.
Gruß
Sebastian
Hallo,
das „Wasserzeichen“ war bei mir auch. Anscheinend wurde das in der Zwischenzeit nicht geändert. Danke auch von mir für die Lösung, Sebastian!
Hier meine Hardware: http://pastebin.com/uLYhABUr
Gruß, Mario
Hallo Sebastian,
und nochmal danke, das Wasserzeichen ist weg!
Viele Grüße
Stefan
Hallo,
vielen Dank, hat auch mir geholfen – mit einem E-450 (HD6320).
Gruß Simon
Hallo,
auch ich habe das dauerhaft eingeblendete Wasserzeichen. Leider verschwindet es nicht, wenn ich Ihren Lösungsansatz verwende. Dennoch scheint der 12.6 Treiber bei mir zu funktionieren, wenngleich mit schwankender Performance.
fglrxinfo
display: :0 screen: 0
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: ATI Radeon HD 4600 Series
OpenGL version string: 3.3.11653 Compatibility Profile Context
Was könnte ich noch versuchen?
Viele Grüße,
Alexander
Hallo Alexander,
Vorsicht! Du hast den AMD Catalyst 12.6 (Mainline) für deine Grafikkarte der Radeon HD 4600 Serie installiert. In deinem Fall muss du den AMD Catalyst 12.6 Legacy-Treiber installieren.
Gruß
Sebastian
Hallo Sebastian,
ich habe bei Phoronix[1] einen Hinweis gefunden, daß direct rendering in KDE nun funktionieren soll, indem man folgende Option setzt (auf eigenes Risiko!):
amdconfig –set-pcs-u32=DDX,ShadowPrimary,1
Danach kwin mit
KWIN_DIRECT_GL=1
dazu zwingen, nicht den Workaround zu nutzen.
Das Ganze scheint auch zu funktionieren. In /var/log/Xorg.0.log steht nun ein zusätzlicher Eintrag:
[ 19623.529] (II) fglrx(0): Shadow Primary option: ShadowPrimary is enabled
In ~/.xsession_erros findet man:
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: AMD Radeon HD 6570
OpenGL version string: 4.2.11733 Compatibility Profile Context
OpenGL shading language version string: 4.20
Driver: Catalyst
Driver version: 4.2.11733
GPU class: NI
OpenGL version: 4.2.11733
GLSL version: 4.20
X server version: 1.10.4
Linux kernel version: 3.4.4
Direct rendering: yes
Requires strict binding: yes
GLSL shaders: yes
Texture NPOT support: yes
Nach anfänglichem Gezicke seitens kwin (4.7.4) funktioniert es nun scheinbar problemlos. Die Umgebungsvariable ist bei kwin tatsächlich angekommen; war in /proc/pid/environ gesetzt.
Ich bin mir aber nicht sicher, ob kwin tatsächlich direct rendering nutzt. Hast Du eine Ahnung, wie man das final prüfen kann? Ich habe noch im Hinterkopf, daß die Ausgaben von kwin diesbezüglich nicht so verlässlich sind.
Warum ich das frage? Weil ich zumindest subjektiv keinen Unterschied feststellen kann zwischen vorher und nachher.
Jedenfalls gibt es zumindest auf Anhieb keine Probleme damit und alle für mich wichtigen Anwendungen laufen scheinbar problemlos.
Danke,
Gruß,
Klaus
[1] http://phoronix.com/forums/showthread.php?71284-AMD-Catalyst-12-6-Beta-improvements&s=8eac1e6d38cc3060ffbbcba88ff7aaf3&p=265618#post265618
Hallo Klaus,
die Meldung in .xsession_errors, die du gepostet hast, sind direkt von Kwin. Sie sagt aus, dass Direct rendering aktiviert ist.
Du kannst in einer Konsole folgendes eingeben, um Kwin „neuzustarten“:
Die ausgegebenen Informationen sind die gleichen wie in der .xsession_errors.
Gruß
Sebastian
Hallo Sebastian,
Danke für Deine Rückmeldung. Allerdings beantwortet das leider nicht meine Frage. Daß die Ausgabe von kwin kommt, habe ich nie bezweifelt. Ich habe aber Zweifel daran, ob die Ausgabe der Realität entspricht.
Diese Zweifel werden umso stärker, wenn man noch Folgendes entdeckt hat: Das direct rendering (also: KWIN_DIRECT_GL=1) funktioniert auch *ohne* ShadowPrimary problemlos (in Xorg.n.log ist kein Eintrag zu Shadow Primary option zu finden). Einfach so. Erfolgreich getestet mit meinem bestehenden User und auch mit einem jungfräulichen User.
Da das hier nicht immer so war, stellen sich mir nun eben diese Fragen:
1. Stimmt die Ausgabe von kwin mit der Realität überein?
2. Wenn 1. tatsächlich gegeben ist, warum funktioniert das plötzlich (aus meiner bescheidenen Sicht)? Hat AMD an dieser Stelle optimiert ohne darüber zu reden?
3. Oder wurde kwin optimiert (mein letzter Test in diese Richtung war nicht mit KDE 4.7.4)?
4. Gibt es andere, die dieses Verhalten mit Catalyst 12.6 reproduzieren können? Test ist eigentlich relativ einfach. In /etc/profile.d/ habe ich eine Datei kde.sh angelegt mit dem Inhalt
export KWIN_DIRECT_GL=1
Danach neu anmelden in KDE, sinnvollerweise mit einem zuvor neu angelegten User, der mit keinerlei Konfigurationen vorbelastet ist.
Fragen über Fragen, auf Antworten hoffend!
Gruß,
Klaus
Hallo Klaus,
das muss ich mal untersuchen. Ich werde auch nochmal AMD fragen, was genau nun stimmt.
Gruß
Sebastian
Hallo Sebastian,
mit export KWIN_DIRECT_GL=1 friert X bei Fullscreen-Flash und eintretendem DPMS / standby nicht mehr ein. Verifiziert mit Gegenprobe: ohne export … ist X sofort wieder eingefroren und hat eine CPU vollständig belegt.
Einen ASIC-Hanger hatte ich bislang auch noch nicht beim Wechseln zur Konsole oder öffnen einer neuen X-Session. Ob das wirklich dauerhaft ist (oder bisher einfach Zufall war), kann ich jetzt noch nicht sagen.
Wichtig: die Shadow Primary option verwende ich nicht! Ausschließlich export KWIN_DIRECT_GL=1.
Gruß,
Klaus
Hallo,
danke für deine Mühe damit wir es einfacher haben.
Das Problem mit dem Wasserzeichen hatte ich auch, danke für die Datei zum ersetzen.
Ich nutze einen Laptop und musste gestern mit dem Ding das erste Mal ne Präsentation machen. Mit meinem Alten Laptop (IntelGrafik) war das kein Problem, aber mit AMD (Radeon HD6480) geht das gar nicht.
Habe deswegen noch schnell den Treiber aktualisiert. War ein Fehler.
Meine Kollegen haben sich mal wieder köstlich über Linux amüsiert, da ich jedes Mal die Kiste neu starten musste, wenn ich nen anderen Monitor/Beamer anschließe bzw. Auflösung (Catalyst 12.6) ändere. Für einen Laptop ist das nicht brauchbar.
Schade eigentlich. Da fühlt man sich wie bei WindowsNT. Ist das ein Problem vom Treiber oder SuSE?
Hallo Maik,
danke für dein Feedback. Ich brauche hier deine Mithilfe, weil ich leider kein Notebook mit AMD Grafik zur Hand habe.
1. Welche Desktop-Umgebung setzt du primär für die Präsentation ein?
2. Welches Notebook (Modell) ist das?
3. Bitte die genauen Schritte zur Reproduktion aufschreiben.
4. Vor und nach dem Anschluss des Monitor/Beamer je einen Report erstellen und den Link hier posten (Wichtig: Nach dem Anschluss des Monitor/Beamer einige Sekunden warten):
5. Sollte die Konfiguration fehlschlagen und ein Neustart erforderlich machen, möchte ich gerne auch danach nochmal ein Link zum Report haben.
Es wäre super nett, wenn du mir die Fragen beantwortest und die 2-3 Reports als Link zur Verfügung stellst. Dann kann ich sehen, woran es evtl. liegen kann. Sofern es erforderlich ist, werde ich hierzu auch ein Bugreport direkt bei AMD einreichen.
Gruß
Sebastian
Hallo,
also ich nutze OpenSuse 12.1 mit KDE 4.7.2.
Meine Hardware ist ein Lenovo ThinkPad Edge E525 mit
– AMD Fusion A4-3300M Dual-Core Prozessor (2x 1,9 – 2,5 GHz)
– AMD Radeon HD 6480G
und 4 GByte DDR3 Arbeitsspeicher.
Es geht hauptsächlich um den Fall, dass ich das Grafiksystem neu starten muss, nach dem ich die Auflösung bzw. die Verteilung auf 2 Monitore eingestellt habe. Catalyst meint ich müsse das System neu starten.
Egal was ich ändere verlangt das Tool das. Vorher fragt es mich ob ich die geänderten Einstellungen behalten möchte (15 Sekunden Countdown) ohne was an der Darstellung zu ändern.
Reports:
Originalbetrieb:
http://sprunge.us/adAY
Nach dem Anschluss des 2. Monitors:
http://sprunge.us/XNVB
Nach der Konfiguration vorm Neustart:
http://sprunge.us/SOQA
Wenn ich mir etwas wünschen dürfte, hätte ich gern das Verhalten so wie auf dem Mac meines Chefs oder den anderen Windowskisten: Auch als Nicht-Root die Anzeige ändern zu können ohne irgendetwas neu starten zu müssen.
Ich bin mir nicht sicher aber auf dem Laptop meiner Frau (6 Jahre alter Acer mit NVidia) geht das.
Gruß und Dank
Maik
Hallo Maik,
danke für dein Feedback. Ich werde das mal bei AMD in Sachen Bedienbarkeit von AMD Catalyst Control Center (CCC) herantragen.
Was passiert, wenn man die Auflösung direkt in der Einstellung vom KDE ändert anstatt im CCC? Meine Erfahrung hierzu war: Wenn man die Auflösung in der KDE-Einstellung von einen oder beide Monitoren einstellt, dann wird ohne Neustart die Auflösung direkt geändert. Zumindest bei mir unter KDE 4.8.5.
Gruß
Sebastian
Hallo,
erstmal vielen Dank für das makerpm.
Mein Versuch einfach den AMD Treiber runterzuladen und selbst zu installieren scheiterte kläglich…mehrmals.
Ich war so froh als endlich mal was funktioniert hat.
Mit dem Wechsel von Catalyst 12.4 auf 12.6 tritt nun plötzlich folgendes Problem auf:
Die Overscan Funktion merkt sich die vorgenommene Einstellung nicht.
Suse startet immer wieder mit einem schwarzen Balken rund um das Bild.
Wenn ich dann im Control Center nachschaue steht der Regler aber auf 0%,
was ich ja auch so will.
Wenn ich den Regler dann nur ein kleines bischen bewege ist der Balken auch gleich wieder weg. Bis zum nächsten Neustart.
Ich benutze einen Intel Core i5 2500k, Gigabyte z68Xp-ud3 mit einer Sapphire Radeon HD6850.
Wissen Sie vielleicht Rat?
Sorry sollte ich hier an der komplett falschen Adresse sein.
Steffen
Versuchs mal mit: sudo aticonfig –set-pcs-val=MCIL,DigitalHDTVDefaultUnderscan,0
am Besten wenn X nicht läuft, also vorher init 3 oder sowas. dann wird das direkt in der /etc/ati/amdpcsdb gespeichert.
Vielleicht wäre es nicht blöd noch etwas zur Software zu sagen
Linux 3.1.10-1.16-desktop
KDE SC 4.8.4
OpenSuse 12.1
Gruß,
Steffen
Hallo Steffen,
es wäre auch nicht verkehrt ;-), mir ein Report von deinem System via makerpm-amd-Skript zur Verfügung zustellen:
Den ausgegeben Link bitte hier posten. Dann schaue ich es mir mal an.
Gruß
Sebastian
Leider bekomme ich nur ein
bash: ./makerpm-amd-12.6.sh: Datei oder Verzeichnis nicht gefunden
Wahrscheinlich weil ich es mit dem Repository nochmal probiert habe.
Der Fehler trat aber auch schon bei meinem ersten Versuch auf, da hatte ich es mit dem Skript probiert.
Gruß,
Steffen
Hab jetzt noch mal alles neu gemacht, Fehler ist noch da.
Der Link:
http://sprunge.us/jOCg
Spät ist es jetzt geworden, angenehme Nachtruhe wünsche ich.
Grüße,
Steffen
Hallo Steffen,
ich habe hierzu recherchiert und folgenden Tipp gefunden.
In der Konsole als root folgendes eingeben:
Danach den Rechner neustarten.
Gruß
Sebastian
Super Sebastian. Besten Dank für den Hinweis.
Hatte ebenfalls mit dem gleichen Problem zu kämpfen.
Die Abstürze des gnome Desktops sind wirklich mit dem aktuellen Treiber gehoben worden. Perfekt ist der Treiber zwar noch immer nicht aber wesentlich besser als die letzten gefühlten 200 .
Nebenbei –> das alte Flashproblem besteht immer noch aber damit werden wir wohl auf ewig leben müssen.
Da geht die Tage dann die versprochene Spende an dich raus.
Gruß Hennes
Das hat wirklich ganz wunderbar funktioniert.
Vielen Dank, auch für den allgemein sehr freundlichen Umgang mit offensichtlichen Neueinsteigern.
Einen schönen Sonntag und herzliche Grüße,
Steffen
Hallo Sebastian,
mir ist da gerade so eine (Schnaps?)Idee gekommen (bitte nicht schlagen :-)):
Wie wäre es denn, wenn Du Dein makerpm.sh selbst in ein RPM packen würdest und das ganz normal in einem (openSUSE) Repository (BuildService) zur Verfügung stellen würdest? Dann könnte man quasi ausschließlich mit zypper arbeiten, und Du könntest Dein makerpm.sh im Pfad installieren, so daß die Aufrufprobleme vielleicht weniger werden und daß auch der Speicherort nicht mehr vergessen wird :-).
Oder gibt es das etwa schon?
Danke für Deinen Einsatz,
viele Grüße,
Klaus
Hallo Klaus,
das Skript in ein RPM packen?! Du legst wirklich darauf an, dich schlagen zu lassen, oder?
Aber nein, das ist eine makabere Idee. Da bereits Burno Friedmann alias tigerfoot die fglrx-Pakete mit dem makerpm-amd-Skript baut und diese in seinem Repo zur Verfügung stellt. Siehe auch im Wiki.
Sobald ich mein Skript (ebenso das Packaging Skript) aktualisiert habe, teile ich die Änderung auch Bruno mit. Damit er ein neues Paket für alle anderen bauen kann. Wir arbeiten schon so gut zusammen, dass man diesen Vorschlag getrost vergessen kann.
Gruß
Sebastian
Hallo Sebastian,
habe ich noch gar nicht bemerkt, daß es das Ergebnis auch direkt in einem Repository gibt.
Ich habe gerade mal auf http://software.opensuse.org/search gesucht. Da gibt es ja auch fglrx-Pakete.
Wie kann man denn die einordnen? Dein Script boot.fglrxrebuild habe ich in x11-video-fglrxG02-8.920-1.1.x86_64.rpm gefunden. In wie fern unterscheidet sich dieses Paket von Deinen (Version mal außen vor gelassen)?
Danke,
Gruß,
Klaus
Moin Klaus,
hm… liest du auch die Wiki-Seite komplett durch?
Gruß
Sebastian
Hallo Sebastian,
ok, zwischen den Zeilen kann man eine Antwort finden :-). Wenn ich nach technischen Antworten suche, übersehe ich sowas schonmal!
Danke,
Gruß,
Klaus
Das ist ja super. Seit wann gibt es das? Gibt es irgendeinen NewsKanal den ich lesen kann, damit ich solche neuerungen nicht verpasse? Das macht alles nochmal komfortabler.
Ich habe auf der SDB mal den Link zum Tumbleweed-Repo ergänzt und den Factory-Link auf 12.2 geupdated – der war broken. Das müsste noch jemand sichten/bestätigen damit das alle sehen. Evtl. hast Du ja die Rechte dafür Sebastian.
Vielen vielen Dank schon mal
tom
Hallo Maik,
ich habe das mal eben bei mir nachgestellt mit einer HD6570, welche drei Monitor-Anschlüsse hat. Habe einen zweiten Monitor (VGA) angeschlossen mit sehr viel kleinerem Bildschirm (1024×768 vs. normal 1920 x 1200). Das Ganze hat bei mir ohne Reboot funktioniert, wohl aber mit einem Relogin (=X-Server durchstarten – also aus KDE abmelden und dann wieder neu anmelden). Die Aufforderung, die ich bekommen habe, war aber, einen Systemneustart oder so ähnlich, zu machen. Die habe ich einfach mal ignoriert und stattdessen nur einen Relogin gemacht.
Schritt für Schritt:
1. zweites Device anschließen.
2. ControlCenter mit Admin-Rechten starten.
3. Neues Device wie gewünscht konfigurieren und aktivieren (unter Anzeigen-Manager).
4. Übernehmen und die Frage, ob man das so haben will, mit ja bestätigen.
5. Aus KDE abmelden (-> Der Aufforderung zum Systemneustart nachkommen)
6. Als User neu anmelden.
Definitiv nicht schön, aber ohne Reboot möglich. Teste es am besten mal mit einem beliebigen zweiten Monitor in Ruhe, damit Du das Verfahren kennst und Dir nicht hämische Bemerkungen anhören mußt.
Wobei ich auch schon Windowsianer an dieser Stelle zappeln sehen habe. Das funktioniert auch dort nicht zwangsweise! Nur daß bei Windows keiner grinst.
Gruß,
Klaus
Ich habe heute erst die Antworten und meinen Beitrag hier gesehen. Automatisches Update hat die control-Datei mal wieder ersetzt. Ein paar Tage nach meinem Post habe ich den hier nicht finden könne. Ich werde, mal sobald ich zu Hause bin die Reports erstellen.
Das mit dem Ab- und wieder Anmelden habe ich auch schon gemerkt. Ist nur blöd.
Der Arbeitsablauf ist bei der Vorbereitung einer Präsentation nicht schön. Vorallem, wenn man erst das Grafiksystem neustarten muss bevor man in der Präsentation auf den Zweibildmodus umstellen kann. Und dazu muss man auch erst mal amBeamer bzw. zweiten Monitor hängen und der Zeigt natürlich genau was man macht, weil automatisch geclont.
Hallo Sebastian,
ich versuche dein Script zu nutzen habe aber ein Problem.
AMD E-450
Suse 12.2
KDE 4.8
Der Fehler besteht darin, daß das Programm basename Dateien nicht findet.
Entpackt wird in ein Temporäres Verzeichnis, das den Name jedesmal wechselt
und dann gelöscht wird.
Irgendeine Idee ?
mfg
Hallo Uli,
kann es vielleicht sein, dass der Pfad, in dem das Skript liegt, Sonderzeichen oder Leerzeichen enthält? Bitte einmal in einem anderen Verzeichnis ausprobieren.
Gruß
Sebastian
Hat ATI irgendwas am DNS versemmelt!? Seit Stunden „curl: (6) Could not resolve host: www2.ati.com (Timeout while contacting DNS servers)“ beim Versuch die amd-driver-installer-12-6-x86.x86_64.run Datei herunterzuladen
Hallo Jagg,
dies sollte mittlerweile behoben sein.
Gruß
Sebastian
Hi Sebastian,
habe die letzten Tage etwas an meiner Kiste gespielt da ich noch eine GTX680 habe (die sich im übrigen im installierten System unter 12.1 partout nicht zum 100%igen laufen bewegen lassen will) und bin nun zurück mit meiner HD 6970.
Habe also Catalyst 12.6 installiert (hatte vorher schon die beta drauf direkt von AMD) allerdings ist mir aufgefallen das zum Schluß in Summe 4 Meldungen kommen die mir seltsam vorkamen:
1.: usr/lib/libOpenCL.so.1 is not a symbolic link
2.: usr/lib64/libOpenCL.so.1 is not a symbolic link
3.: usr/lib/libOpenCL.so.1 is not a symbolic link
4.: usr/lib64/libOpenCL.so.1 is not a symbolic link
Was sagt mir das?
Viele Grüße
Hallo Mattes,
ja, es scheint so das NVIDIA einige Dateien ohne Rücksicht drüberbügelt und auch nicht sauber deinstalliert wird. Das liebe ich so sehr.
Die o.g. Libraries „libOpenCL.so.1“ wie auch das symbolische Link „libOpenCL.so“ sollten nach Entfernung des NVIDIA-Treibers auf deinem System nicht mehr vorhanden sein. Diese Dateien muss du von Hand nochmal entfernen und das fglrx-Paket neu installieren.
Ich bin mir jedoch nicht sicher, wo NVIDIA sich noch einklingt.
Gruß
Sebastian
Legacy Treiber,
hi Sebastian, da ich noch meine Motherboard Grafik mit ATI (AMD) Treibern nutzen wollte (ATI RS780 [Radeon HD 3200]) kommt für mich der neue Treiber leider nicht in Betracht. Wird auch gar nicht mehr kompiliert, sagt keine unterstützte Hardware gefunden.
Also den Beta Treiber 12.6 Legacy von AMD heruntergeladen (ein anderer wird z.Z gar nicht angeboten). Installation läuft auch wunderbar, selbst VLC mit deinem Helferscript funktioniert GPU beschleunigt, aber:
wie auch schon in einem anderen Kommentar erwähnt, kommt das AMD Testing Logo. Ist leider auch nicht mit deinem Workaround wegzubekommen (eigentlich logisch, ist ja auch nicht für den legacy Treiber, aber die Hoffnung stirbt zuletzt )
Hast Du evtl. eine Lösung.
Ich danke vielmals.
Mike Reichel
Hallo Mike,
ich schaue mal, ob noch eine andere Lösung zum Entfernen des Testing-Logo im Beta Legacy-Treiber existiert.
Gruß
Sebastian
Guten Tag Sebastian,
ich nutze den Treiber der mit Deinem Skript gebaut wird. Allerdings ist die Performance bei Flashvideos im Vollbildmodus alles andere als akzeptabel. Wir sprechen hier von 0,5FPS während ich bei allen anderen Anwendungen recht akzeptable Ergebnisse erziele.
Wie kann ich mir das erklären?
Gruß
Pingutux
openSUSE 12.1, KDE4.7.2, AMD Phenom X4 955, Radeon HD7750
Hi Pingutux,
woher weißt Du die frame rate beim Flashplayer? Hast Du eine Testseite?
Gruß,
Klaus
Hallo Klaus,
bei 0,5FPS braucht man nicht wirklich eine Testseite. Wenn jede 2 Sekunden ein anderes Bild angezeigt wird kann man das gut mit bloßem Auge und einer Uhr messen.
Das Problem hat sich allerdings gelöst, nachdem ich mein System durch openSUSE 12.2 Beta 2 ersetzt habe. Sebastians Skript arbeitet auch hier hervorragend. Und Flash sowie KDE arbeiten optimal.
Gruß
Pingutux
Hi Pingutux,
hast Recht. Mich hätte eine Testseite trotzdem mal interessiert.
Seltsam ist das aber schon. Ich habe damit keine Probleme, und das bei einem 26“ – Bildschirm. Wäre interessant gewesen, die Ursache zu erfahren. Aber nun hast Du ja auch ein laufendes System.
Gruß,
Klaus
Moin Pingu,
leider verfügt der flashplayer von adobe nicht über xvba-videobeschleunigung. XVBA ist AMDs video-schnittstelle, so wie VDPAU bei Nvidia. Es gibt jedoch eine alternative, da das reine flash-video-format (ohne den player) nicht proprietär ist, wird es von einigen playern voll (gpu-beschleunigt) unterstützt. Die müssen das halt nur ohne den player streamen. Ich weiß jetzt von umplayer und XBMC bzw. dessen youtube-plugin – die können das. Der umplayer hat oben rechts eine leiste wo du einfach die youtube-url copy-paste reinhaust, dann spielt der das. Damit ist dann aber auch nur youtube beschleunigt, auch bei XBMC. Und das xbmc-plugin ist von der bedienung her eher was fürs sofa….
Noch eine möglichkeit die ich oft genutzt hab, bevor ich umplayer entdeckte, ist das flashvideo erst runterzuladen, dafür git es nen haufen firefox-plugins (ich empfehle UnPlug). Das geht häufig auch auf nicht-youtube seiten. Wenn man das video im original flv oder webm format speichert gibt es auch keinen qualitätsverlust. Beschleunigt abspielen kann man das dann mit VLC, umplayer oder so.
Hallo Tom,
das ist sehr hilfreich. Vielen Dank
Gruß
Pingutux
Hallo Tom,
ein paar Ergänzungen zu Deinen Ausführungen:
XvBA (X-Video Bitstream Acceleration) ist eine AMD-Schnittstelle, um die Videocodecs MPEG-2, MPEG-4 AVC (H.264) und VC-1 hardwaregestützt (GPU) grob gesagt zu verarbeiten. vlc-Dateien haben oft andere Formate.
Die Anzeige selbst wird über OpenGL GLX Videoausgabe (XCB) hardwarebeschleunigt.
Das Tool umplayer ist lediglich ein Frontend zu mplayer. Man muß daher darauf achten, welche Features mplayer unterstützt.
Eine gute Einführung zur Nutzung beider Schnittstellen via vlc hat Sebastian hier erstellt:
http://www.sebastian-siebert.de/2011/09/11/opensuse-hardware-videobeschleunigung-via-xvba-vom-amd-catalyst-nutzen/
Gruß,
Klaus
Korrektur:
„vlc-Dateien haben oft andere Formate.“ muß natürlich „flv-Dateien haben oft andere Formate.“ heißen.
Sorry,
Klaus
Grüße.
Teste gerade den gestern veröffentlichten RC1 von openSUSE 12.2.
Bislang macht die Version einen sehr, sehr guten Eindruck. Läuft out-of-box geschmeidig rund. Sogar das altbekannte Flashproblem scheint behoben zu sein.
Bevor ich jedoch vollends Jubel, würde ich gerne den aktuellen Catalysttreiber ausprobieren. Leider lässt sich dein Skript, anders als von Pingutux beschrieben, nicht dazu bewegen den Treiber zu installieren.
Mal sehen was der morgige Tag bringt.
Gruß Hennes
Hallo Hennes,
welche Fehlermeldung meldet denn das Skript?
Wenn das Skript nur meckert, dass das gebaute Paket mit zypper nicht installiert werden kann, weil Abhängigkeiten nicht erfüllt oder gefunden werden können, dann wechsle in das Verzeichnis in der das gebaute rpm-paket liegt und installiere es mit yast.
Sollte das Paket erst gar nicht gebaut werden, gib bitte kurz Bescheid.
Gruß
Pingu
Das Ende des Skripts von Sebastian gibt folgende Fehler hervor.
Auflösung erzwingen: Nein
‚kernel-source-3.4.4-1.1.1‘ wurde in den Paketnamen nicht gefunden. Es wird ‚kernel-source = 3.4.4-1.1.1‘ versucht.
‚kernel-syms-3.4.4-1.1.1‘ wurde in den Paketnamen nicht gefunden. Es wird ‚kernel-syms = 3.4.4-1.1.1‘ versucht.
‚kernel-syms = 3.4.4-1.1.1‘ ist bereits installiert.
‚kernel-source = 3.4.4-1.1.1‘ ist bereits installiert.
Keine Anbieter von ‚has‘ gefunden.
Keine Anbieter von ‚been‘ gefunden.
Keine Anbieter von ’successfully‘ gefunden.
Error: zypper could not install the has been successfully generated.rpm package
gruß Henne
Hallo Hennes,
als ich es zuletzt auf der openSUSE 12.2 Beta getestet habe, funktionierte es noch. Ich prüfe das nochmal bei mir mit der openSUSE 12.2 RC1.
Gruß
Sebastian
Hallo Hennes,
diese Fehlermeldung hatte ich auch. Das erfolgreich generierte RPM habe ich dann mit yast installiert. Das hat dann die dependencies korrekt ermittelt und nachinstalliert.
Einfach das rpm Paket im dolphin mit der rechten Maustaste anklicken und dann den Punkt mit yast installieren auswählen.
Dummerweise baut das Skript aber kein RPM
Trotzdem Danke
Hallo Hennes,
ich habe so einen Verdacht. Schau mal bitte, ob das Paket „rpm-build“ unter openSUSE 12.2 RC 1 installiert ist. Wenn nicht, bitte einmal installieren und nochmal das Skript probieren.
Dann muss ich noch etwas im Skript für openSUSE 12.2 ergänzen.
Gruß
Sebastian
Danke für den Hinweis Sebastian.
Werde ihm aber leider erst am Montag nachgehen können. Melde mich aber dann schnellstmöglich.
Gruß und schönes Wochenende
Hennes
Super Hinweis.
Genau das war es. Das Paket „rpm-build“ war nicht installiert.
Dein Treiber läuft wunderbar.
Auch die kleinen Flashvideos laufen noch immer im Vollbildmodus butterweich.
Danke.
Hallo Sebastian,
Zuoberst schreibst du, dass OS 12.1 unterstützt wird. Im Update schreibst du, dass du Ergänzungen für OS 12.2 vorgenommen hast. In „Was ist neu“ schreibst du vom 3.4er Kernel. Im Absatz darunter rätst du mir mit meiner HD4650 von der Installation der 12.6 ab. Ich stehe gerade auf dem Schlauch.
Ist die 12.6er Version des Treibers für mein OS 12.1 mit 3.1er Kernel gar nicht gedacht, oder gilt das erst für OS 12.2 mit dem neueren Kernel?
Im wiki steht „Ab AMD Catalyst 12.6 “ wird meine Grafikkarte nicht unterstützt. Heißt das „ab und inklusive“ oder „12.6 geht noch, danach ist Schicht“? Auf AMDs Seite finde ich einen 12.6 Beta-Treiber.
Sorry für die -vermutlich dummen- Fragen!
Grüße
Ralf
Hallo Ralf,
nicht alles in ein Topf werfen, denn so kommt nix gescheites raus.
openSUSE 11.4 wie auch openSUSE 12.1 werden nach wie vor unterstützt. Ergänzung im Skript betrifft nur zur Laufzeit des Skriptes unter openSUSE 12.2 und ermöglicht die Installation des Treiber zu Testzwecken auf openSUSE 12.2. Die Kernel-Unterstützung bedeutet, dass bis einschl. Kernel 3.4 für alle openSUSE Versionen (11.4, 12.1, 12.2) unterstützt wird.
Der derzeitige Treiber AMD Catalyst 12.6 unterstützt deine Radeon HD 4650 nicht mehr. Wie du richtig erkannt hast, hat AMD eine Beta Legacy-Treiber veröffentlicht. Unglücklicherweise hat AMD die gleiche Treiber-Version genannt. Es ist aber in Wirklichkeit die damals geplante AMD Catalyst 12.5, bevor AMD seine Treiber-Politik über den Haufen geworfen hat. Sobald der Legacy-Treiber veröffentlicht wurde, werde ich hierzu auch ein Skript zur Verfügung stellen.
Gruß
Sebastian
Hallo Sebastian,
jetzt hab auch ich das verstanden
Dank dir für die Aufklärung.
Grüße
Ralf
@Sebastian:
Wir sind kein fork, wir wollen das ganze Zeug wieder nach xbmc reinbringen.
Hallo fritsch,
für mich ist es eine Art Fork. Da das XvBA-Feature im XBMC nur in eurem Entwicklungszweig (speziell im Eden-Branch) vorhanden ist und nicht im Upstream. Aber okay, man könnte es auch eine Art Unterentwicklung von XBMC (was auch den master-Branch einschließt) ansehen, dann wäre es nur bedingt ein Fork.
Gruß
Sebastian
Hallo Sebastian,
mittlerweile ist die Legacy-Version des AMD-Treibers 12.6 herausgekommen. es wäre ja gut wenn du das mit einbauen könntest….
LG Alexander Koß
Ja, das wäre wirklich super. Und eine Anpassung auf den Kernel 3.5 wäre fast noch besser.
Hallo Alexander und Obi-Wahn,
ich habe ein spezielles makerpm-amd-Skript für den Legacy-Treiber veröffentlicht. Siehe auch mein neuesten Artikel.
Was mit der Unterstützung der Kernel-Version 3.5 angeht, werde ich später noch ein Patch für beide fglrx-Varianten nachreichen. Momentan läuft der Legacy-Treiber von Hause aus bis einschließlich Kernel 3.4.
Gruß
Sebastian
Hallo Sebastian,
habe mir heute früh mit Hilf e des von Dir eingestellten neuen Installers die aktuellste Version des ATI-Treibers installiert (8.97.100).
Hat soweit (fast ….) perfekt funktioniert, keinerlei Fehlermeldungen beim Bauen oder so … nur wird mein Monitor nicht mehr erkannt, ich bekomme eine Auflösung von 1024×768 und das war es dann.
In den Systemeinstellungen habe ich sonst CRT1-verbunden und die Auflösungswerte, die der Monitor per EDID liefert, die sind mit dem neuen Treiber alle weg.
Zurück zum alten Treiber -> alles wieder prima, 1600×1200, wie es sich gehört. So gesehen habe ich kein Problem, aber IMHO funktioniert hier etwas nicht (mehr …) richtig.
Grafikkarte:
01:00.0 VGA compatible controller: ATI Technologies Inc Device 683f (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Device e213
Flags: bus master, fast devsel, latency 0, IRQ 50
Memory at e0000000 (64-bit, prefetchable) [size=256M]
Memory at f7e00000 (64-bit, non-prefetchable) [size=256K]
I/O ports at e000 [size=256]
Expansion ROM at f7e40000 [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010
Capabilities: [150] Advanced Error Reporting
Capabilities: [270] #19
Kernel driver in use: fglrx_pci
ATI Radeon 7750, also recht aktuell. Monitor: Elsa ECOMO 750 (ja, Röhre, funktioniert aber prima, will nichts anderes ….)
OS: Opensuse 12.1, Kernel 3.4.5 aus dem stable – Repo.
Vielen Dank für Deine steten Bemühungen mit dem Skript und auch sonst für Deine Mühe!
Bis bald mal
Dieter
Hallo Dieter,
Du hast „die aktuellste Version des ATI-Treibers installiert (8.97.100).“ und besitzt Graka ATI Radeon 7750.
Wenn ich das bei Sebastian richtig verstanden habe, ist der ATI-Treiber 8.97.100 der legacy-Treiber, sprich für Radeon HD 2000 – 4000, also nichts für Dich. Du solltest beim derzeit aktuellen 8.980 (12.6) bleiben. Der sollte auch Deine Graka unterstützen.
Viele Grüße,
Klaus
Hey Klaus,
vielen Dank! Das war es, irgendwie habe ich nicht aufgepasst beim Herunterladen des Installationsscripts!
Jetzt klappt alles wie es soll!
Danke nochmal
Dieter
Hallo Sebastian,
wollte nur sagen der Kernel 3.5 (Tumbleweed) schreit glaube ich wieder nach einem Patch.
viele Grüße
Peter
P.S.: build log reiche ich nach
Habe ein HP Pavilion mit AMD APU und zusätzlicher Radeon mit deduziertem Speicher. Zu installierende OS: OpenSuse 12.2 RC-2.
1. Die direkte Installation von OpenSuse geht gar nicht auf dem Laptop.
1.1 Umweg 1: Installation auf einem (älterem) MSI Laptop, danach Installation aus RPM
1.2 Umweg 2: Installation auf VM-Ware (mit direkter Anbindung der Festplatte), dabei beachten, dass die Mountpoints anhand der Partitionsnamen vergeben werden, sonst bootet das Linux nur in der VM.
1.3 Treiber während der Installation nachladen (bisher nicht ausprobiert)
Falls es bessere Vorschläge gibt, wäre ich dankbar.
2. Bei der Installation gibt es Probleme:
2.1 Die Skripte enden meist mit: unsupported …. und da kommt entweder, dass die Hardware nicht passt (bei aktueller Version nicht mehr der Fall) oder die OS-Version nicht unterstützt wird.
2.2 Ein Treiberupdate, egal ob durch Skript oder RPM führt bestenfalls zu einer partiellen Deinstallation. Meistens hielt das System beim booten kurz nach dem Ladevorgang der Firewall (letzte sichtbare Meldung). Da das System danach nicht mehr ansprechbar ist, kann ich wenig über den Verlauf sagen.
3. Nun habe ich alles zum Laufen gebracht, und die meisten Probleme umgangen. Da es nun aber bei mir funktioniert, weiß ich nicht, wie ich beim Debuggen helfen soll.
4. KDE scheint noch Probleme zu haben. Alles, was ich bisher testen konnte, funktioniert. Will ich jedoch mal herunterfahren, oder rebooten, so bleibt manchmal einfach alles nach dem klick hängen. Manchmal kann ich noch über die Shell neustarten, manchmal kann ich aber auch da nicht reinwechseln. Falls es doch gut klappt und ich den „jetzt herunterfahren“ (oder wie es auch immer heiße mag) Button sehe, gibt es oben, leicht unterhalb des Bildschirmrandes, einen verzerrten, dicken, farbig-streifenmäßig-gepunkteten, schwarzen Streifen. Manchmal einen dünnen unten.
Falls es einen Weg gibt, nötige Infos auf einem Wege zu besorgen, die mein funktionierendes System nicht in Gefahr bringen (2 Tage mit mehreren Testanläufen täglich), tue ich es gerne.
Größten Dank auch für den Tipp mit „unsupported hardware“-Wasserzeichen. Hat wunderbar funktioniert, wäre vielleicht empfehlenswert so etwas gleich in die Repository rpm zu stopfen
mfg. – Micha
Hallo Micha,
danke für dein Feedback.
Zu 1: Der KMS im Kernel scheint bei einigen Rechnern noch Probleme zu machen und lässt sich durch die Bootoption nomodeset ausschalten. Danach dürfte die Installation klappen.
Zu 1.3: Bisher kann man den fglrx-Treiber nicht nachladen, da dieser erst in kompilierter Form passend für den Kernel vorliegen muss. Leider erlaubt das die AMD-Lizenz nicht, den Treiber mit auf die CD/DVD auszuliefern. (Das gleiche ist auch mit NVIDIA)
Zu 2.1: Wenn die Grafikkarte neu ist oder ein AMD-Mitarbeiter die control-Datei zu stark ausmistet, dann kann sowas schon passieren.
Zu 2.2: Hierzu hätte ich gerne etwas mehr Informationen. Welche Pakete werden deinstalliert? Kannst du bitte den Log-Level von systemd erhöhen?
Zu 4: Du meinst sicherlich die Schaltfläche zum Abmelden/Herunterfahren. Aus früheren Tagen kannte ich es so, dass man auf die Schaltfläche geklickt hat und dabei hat er den Desktop-Hintergrund heruntergedimmt. Heute sind da irgendwelche Grafikfragmente von längst geschlossenen Fenster. Ich habe das bereits an AMD gemeldet und werde sie da nochmal darauf ansprechen.
Gruß
Sebastian
Hallo Sebastian,
da ich mir nun doch (nach 7 Jahren) eine neue GraKa gegönnt habe (eine HD7xxx), stelle ich noch einmal 2 Fragen, die du wahrscheinlich garnicht mehr hören kannst (im voraus ein „Sorry“ von mir):
1. Der Austausch nach dem Muster: PC aus ->alte GraKa raus -> neu GraKa rein ->PC wieder an
sollte unter openSuse 12.1 (Treiber-Vers. 12.4) keine Probleme bereiten, oder? Ja, du hattest mir diese Frage schon einmal beantwortet und du kannst mich zu Recht einen kleinen Schisser nennen, aber bevor ich größere Probleme bekomme, frage ich lieber nochmal nach.
2. Im Zuge der Auslagerung des Treibers für die alten GraKas, habe ich das Repository (geeko.ioda.net) deaktiviert. Nach dem Austausch der GraKa will ich es wieder aktivieren. Ich gehe mal davon aus, dass über dieses Repository der normale Treiber läuft und der Legacy-Treiber nur über dein Installationsscript zu installieren ist? Oder mit anderen Worten: mit der Aktivierung sollten auch (wieder) die richtigen/neuen Treiber installiert werden, oder
Danke im voraus für deine Antwort.
MfG
Sebastian
Hallo Sebastian,
herzlichen Glückwunsch zu deiner neuen Grafikkarte.
zu 1: Das ist zutreffend.
zu 2: Wenn du das Repository wieder aktivierst und den Treiber aktualisierst, dann wird auf jeden Fall der neuere Treiber installiert. Mit der neuen Grafikkarte sollte alles kein Problem sein.
Gruß
Sebastian
Hallo Sebastian,
danke für deine Antwort. Die macht mir Mut. Morgen will ich es in Angriff nehmen und (sofern ich nicht durch die dann installierte dreifache Grafikpower weggepustet wurde) werde berichten, wie es lief.
Schönes WE schon mal von mir.
Grüße
Sebastian
Hallo,
wie versprochen wollte ich kurz mitteilen, wie es lief. Es lief sehr gut!
Überraschung 1: unter Linux lief es einfacher als unter Win (unter Win musste noch der Treiber deinstalliert und wieder neu installiert werden…ein bischen nervig!)
Überrachdung 2: unter dem Repo gibts den neuen Treiber (12.6) noch nicht. Schade, aber ich vertraue darauf, dass er demnächst eingepflegt wird.
Grüße
Sebastian
Hallo Sebastian,
erfreulich, dass es bei dir so reibungslos geklappt hat, wie ich es auch bei meinem letzten Versuch in Erinnerung hatte.
Im Repo http://geeko.ioda.net/mirror/amd-fglrx/ habe ich nachgeschaut. Dort wird der Treiber 8.980-2 angeboten und ist auch der neueste Treiber inkl. Kernel 3.5.0 Support.
Gruß
Sebastian
Hallo Sebastian,
na, dass ist ja witzig. Obwohl ich noch die alten Repo-Daten hatte, wurde laut Yast die neueste Version am 11.08.12 installiert. Und ich hab’s nicht mitbekommen.
Danke für die Repo-Änderungs-Info. Ist an mir anscheinend total vorbei gegangen (und im HOWTO stehen auch noch die alten Daten).
Egal, ist geändert und scheint bestens zu laufen. Danke für deine Mühen.
Grüße
Sebastian
Hallo Sebastian,
nochmal ich. Ich hab gerade gemerkt (wahrscheinlich komme ich da auch wieder aus dem Mustopf), dass die Befehle
aticonfig –del-pcs-key=LDC, ReleaseVersion und
aticonfig –del-pcs-key=LDC, Catalyst_Version
nicht mehr nötig sind und die Versionsnummer nun gleich auf anhieb stimmt.
Dickes Lob, auch wenn’s „nur“ um die korrekte Anzeige der Versionsnr. geht.
Grüße
Sebastian