Autor Thema: Sundtek Treiber macht wine und mplayer kaputt! (fixed)  (Gelesen 5289 mal)

newton

  • Newbie
  • *
  • Beiträge: 1
    • Profil anzeigen
Sundtek Treiber macht wine und mplayer kaputt! (fixed)
« am: August 04, 2010, 01:49:49 Nachmittag »
Hallo,

verwendete Version: sundtek_installer_100506.sh

Wenn /opt/lib/libmediaclient.so in /etc/ld.so.preload ist schmiert wine z.B. (aber nicht nur) bei den sonst in Wine einwandfrei funktionierenden Office-Viewern mit einer kryptischen Execption ab. (Das hat mich vielleicht was Nerven gekostet, die Ursache zu finden!).

MPlayer zerhauts bei manchen Filmen, ich vermute denen, wo der codec als win32 dll geladen wird mit einem Segmentation fault - geht "natürlich" ohne die Sundtek-lib.

Doch so keine gute Idee, grundsätzlich allen Programmen wildfremden closed-source code unterzujubeln?!

Gruß,

Michael
« Letzte Änderung: Oktober 07, 2010, 09:38:14 Nachmittag von Sundtek »

Sundtek

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 8512
    • Profil anzeigen
Re:Sundtek Treiber macht wine und mplayer kaputt!
« Antwort #1 am: August 04, 2010, 03:11:37 Nachmittag »
EDIT 7. Oktober 2010
Das Problem wurde mit einem aktuellen Treiber behoben

----
Originale Nachricht:

Hallo,

verwendete Version: sundtek_installer_100506.sh

Wenn /opt/lib/libmediaclient.so in /etc/ld.so.preload ist schmiert wine z.B. (aber nicht nur) bei den sonst in Wine einwandfrei funktionierenden Office-Viewern mit einer kryptischen Execption ab. (Das hat mich vielleicht was Nerven gekostet, die Ursache zu finden!).

MPlayer zerhauts bei manchen Filmen, ich vermute denen, wo der codec als win32 dll geladen wird mit einem Segmentation fault - geht "natürlich" ohne die Sundtek-lib.

Doch so keine gute Idee, grundsätzlich allen Programmen wildfremden closed-source code unterzujubeln?!

Gruß,

Michael

Probleme mit wine sind soweit bekannt, da wine in etwa auf den selben Mechanismus aufbaut. Fuer Wine Applikationen einfach /etc/ld.so.preload temporaer umbenennen. Wir hatten diesbezueglich jetzt genau 2 Anfragen in einem Jahr. Wer den Treiber fuer gewisse Applikationen sperren moechte kann zudem AppArmor verwenden.
Ohne /etc/ld.so.preload kann man den Applikationen auch mittels LD_PRELOAD mitteilen das sie direkt auf den Treiber zugreifen sollen
Zitat
LD_PRELOAD=/opt/lib/libmediaclient.so Applikation

'Wildfremder' Code ist dies zudem nicht, es stellt lediglich die Verbindung zum Treiber her, in mehr als 99% bleibt dieser Mechanismus konsistent und bereitet ueblicherweise nicht einmal Probleme auf embedded Plattformen.

Wir hatten ebenfalls andere Mechanismen evaluiert jedoch muessten die Kunden dann anfangen zu  kompilieren - und dies ist in der Realitaet fuer die allermeisten Anwender ebenfalls keine Alternative - und wir koennten das ganze auch nicht zentral supporten.
Wir koennen und wollen auch nicht auf die Kernelrelease-Zeiten Ruecksicht nehmen sobald wir neue Geraete unterstuetzen wollen.
Das kommende DVB-S/S2 Geraet wird ueber diesen Mechanismus problemlos auf Linux 2.6.15 unterstuetzt - dies ist ausnahmslos nur mit diesem Mechanismus moeglich. Zudem ist der Treiber mit dieser Kernelversion dann ebensogut getestet wie mit den aktuellsten.

Die Vorteile der derzeitigen vorgehensweise sind ueberwiegend groesser, und fuer eventuelle Nachteile sind wir auch bereit akzeptable Loesungen zu erarbeiten.
« Letzte Änderung: Oktober 07, 2010, 09:38:41 Nachmittag von Sundtek »
Failure is a good thing! I'll fix it