Ist doch bei anderer Hardware auch nicht anders. Ich finde hier wird auf ziemlich hohem Niveau gemosert. Man denke nur an die Hardware bei der man als Endbenutzer die Firmware nicht einmal ändern könnte wenn man es wollte. Die Hauptsache ist doch, dass der Treiber nun auch auf andere Plattformen portiert werden kann.
Von theBohemian_ am Do, 25. Oktober 2012 um 17:12 #
Nope, die Firmware ist die OpenGL-Implementierung. Dave Airlie erklärt die Details in seinem Blog und vergleicht es mit Netzwerkkarten deren Firmware TCP/IP implementieren. Zu guter letzt: Einfach in den Source gucken ... und gruseln.
Irgendwie sehe ich das Problem hier nicht. Irgendeine Schnittstelle zwischen Hardware und Software braucht es ja immer. Hier ist die Schnittstelle halt einfach besonders poliert und versteht mächtige Kommandos. Als Treiber-Entwickler sollte man sich darüber doch eigentlich freuen, da so weniger Arbeit an einem selbst hängen bleibt.
Der Treiber soll die Hardware betreiben und nicht Proxy spielen.
Bei dieser Firmware ist man zu 100% vom Hersteller abhängig. Ich kann mich da noch an die ganzen Brooktree Chipsätze erinnern, wo der Treiber bei jeder neuen Version Features blockierte. Auch gab es da mal ganz nette Firmware von Epson, welche den Drucker aufgrund des Seitenzählers lahmlegte.
Hoffentlich schafft es irgendwann jemand einen OSS Treiber/Firmware für das Ding herzustellen.
Wird etwa mit dieser Lösung der Kernel befleckt? Also was spricht dagegen eine reine Schnittstelle zur Hardware zu haben?
In der Automatisierungstechnik käme niemand auf die Idee einen Treiber für einen Servo-Achsverstärker selbst zu schreiben, warum auch? Es reicht wenn es eine genormte Schnittstelle gibt womit sich das Ding ansprechen läßt.
Und du vertrittst die Meinung aller anderen oder was?
Es spricht folgendes dagegen: * Wenige bzw. keine Möglichkeit der Erweiterung * Security (auch Firmware und Treiber haben Sicherheitslücken) * Keine Bugfixes möglich (außer vom Hersteller)
In der Automatisierungstechnik wird aber auch selten ein Betriebssystem oder Treiber geschrieben. Auch kennt die Automatisierungstechnik noch immer den Begriff Security nicht. Von Herstellerunabhängigkeit, freien Systemen, etc. will ich noch gar nicht reden. Das meiste was ich an Code auf SPS, Visualisierungsterminals etc. gesehen habe treibt einem die Tränen ins Gesicht und hat mit Programmierung wenig zu tun.
Abgesehen davon bietet diese Firmware keine genormte Schnittstelle.
Das allerschönste: Obwohl du ein selbsternannter Spezialist für Firmware, Linux, SPS, Visualisierungsterminals, etc. bist wird sich an dem Treiber nichts ändern.
Der Treiber bleibt so wie er ist, da kannst du noch so viel heulen und winseln und dich darüber aufregen
Weder habe ich mich zu irgendwas ernannt, noch habe ich zweiteres getan. Ich habe lediglich dem Vorposter die Probleme näherbringen wollen, welche er nicht gesehen hat oder sehen wollte.
Wer oder was zum Teufel ist dieser "David Airlie"? Hat der vielleicht die Hardware entwickelt, oder warum meint der sich zum Thema äußern zu müssen? Der soll sich lieber um seine freien ATI Treiber kümmern, da hat er mehr wie genug zu tun.
Der Kernel wird nicht befleckt, Ende der Diskussion.
Wenn er freie Grafik-Hardware haben will, dann kann er sich ja mit einem selbsternannten Alleskönner & Universalgenie wie dir zusammentun und welche entwicklen.
Da du scheinbar von deinen Beleidigungen und unangebrachten Sarkasmus nicht abrücken willst, beenden wir diese Diskussion besser.
Zum Abschluss: 1. Niemand hat sich wegen des Kernels aufgeregt 2. Es wird hauptsächlich an der Pressemitteilung und deren Irreführung Kritik geübt 3. Es ist nicht an dir, zu bestimmen, wer sich zu welchem Thema äußern darf 4. Beleidigungen in dieser Form sind nicht nur unangebracht sondern verstoßen sicher auch gegen die Forenregel. Bitte zügle dich in Zukunft.
pro-linux ist hier leider auf eine Falschmeldung - wie viele andere auch - hereingefallen.
Der Code, den Broadcom jetzt unter der 3-Klausel BSD-Lizenz veröffentlichte, implementiert EGL, OpenGL ES, OpenVG und OpenMax
und genau das macht der Code nicht. Er leitet nur an die Firmware weiter. All dies ist in der Firmware implementiert inklusive dem Compiler (!) für GLSL.
Ist doch bei anderer Hardware auch nicht anders. Ich finde hier wird auf ziemlich hohem Niveau gemosert. Man denke nur an die Hardware bei der man als Endbenutzer die Firmware nicht einmal ändern könnte wenn man es wollte. Die Hauptsache ist doch, dass der Treiber nun auch auf andere Plattformen portiert werden kann.
Nope, die Firmware ist die OpenGL-Implementierung. Dave Airlie erklärt die Details in seinem Blog und vergleicht es mit Netzwerkkarten deren Firmware TCP/IP implementieren. Zu guter letzt: Einfach in den Source gucken ... und gruseln.
Irgendwie sehe ich das Problem hier nicht. Irgendeine Schnittstelle zwischen Hardware und Software braucht es ja immer. Hier ist die Schnittstelle halt einfach besonders poliert und versteht mächtige Kommandos. Als Treiber-Entwickler sollte man sich darüber doch eigentlich freuen, da so weniger Arbeit an einem selbst hängen bleibt.
Der Treiber soll die Hardware betreiben und nicht Proxy spielen.
Bei dieser Firmware ist man zu 100% vom Hersteller abhängig. Ich kann mich da noch an die ganzen Brooktree Chipsätze erinnern, wo der Treiber bei jeder neuen Version Features blockierte. Auch gab es da mal ganz nette Firmware von Epson, welche den Drucker aufgrund des Seitenzählers lahmlegte.
Hoffentlich schafft es irgendwann jemand einen OSS Treiber/Firmware für das Ding herzustellen.
Das ist ganz alleine deine persönliche Meinung.
Wird etwa mit dieser Lösung der Kernel befleckt? Also was spricht dagegen eine reine Schnittstelle zur Hardware zu haben?
In der Automatisierungstechnik käme niemand auf die Idee einen Treiber für einen Servo-Achsverstärker selbst zu schreiben, warum auch? Es reicht wenn es eine genormte Schnittstelle gibt womit sich das Ding ansprechen läßt.
Mit dem Raspberry Pi steuert man keine Produktionsstraßen, sondern bastelt selber an Hard- und Software.
Richtig, man bastelt selbst an Hard- und Software. Und diese Hardware kann durchaus auch Maschinen steuern mit harter Echtzeit...
Harte Echtzeit mit dem Raspberry PI: Xenomai on Raspberry Pi
Und du vertrittst die Meinung aller anderen oder was?
Es spricht folgendes dagegen:
* Wenige bzw. keine Möglichkeit der Erweiterung
* Security (auch Firmware und Treiber haben Sicherheitslücken)
* Keine Bugfixes möglich (außer vom Hersteller)
In der Automatisierungstechnik wird aber auch selten ein Betriebssystem oder Treiber geschrieben. Auch kennt die Automatisierungstechnik noch immer den Begriff Security nicht. Von Herstellerunabhängigkeit, freien Systemen, etc. will ich noch gar nicht reden. Das meiste was ich an Code auf SPS, Visualisierungsterminals etc. gesehen habe treibt einem die Tränen ins Gesicht und hat mit Programmierung wenig zu tun.
Abgesehen davon bietet diese Firmware keine genormte Schnittstelle.
Das allerschönste: Obwohl du ein selbsternannter Spezialist für Firmware, Linux, SPS, Visualisierungsterminals, etc. bist wird sich an dem Treiber nichts ändern.
Der Treiber bleibt so wie er ist, da kannst du noch so viel heulen und winseln und dich darüber aufregen
Du besitzt anscheinend eine Leseschwäche:
Weder habe ich mich zu irgendwas ernannt, noch habe ich zweiteres getan. Ich habe lediglich dem Vorposter die Probleme näherbringen wollen, welche er nicht gesehen hat oder sehen wollte.
Hier ein Eintrag von David Airlie zu dem Thema.
Wer oder was zum Teufel ist dieser "David Airlie"? Hat der vielleicht die Hardware entwickelt, oder warum meint der sich zum Thema äußern zu müssen? Der soll sich lieber um seine freien ATI Treiber kümmern, da hat er mehr wie genug zu tun.
Der Kernel wird nicht befleckt, Ende der Diskussion.
Wenn er freie Grafik-Hardware haben will, dann kann er sich ja mit einem selbsternannten Alleskönner & Universalgenie wie dir zusammentun und welche entwicklen.
Da du scheinbar von deinen Beleidigungen und unangebrachten Sarkasmus nicht abrücken willst, beenden wir diese Diskussion besser.
Zum Abschluss:
1. Niemand hat sich wegen des Kernels aufgeregt
2. Es wird hauptsächlich an der Pressemitteilung und deren Irreführung Kritik geübt
3. Es ist nicht an dir, zu bestimmen, wer sich zu welchem Thema äußern darf
4. Beleidigungen in dieser Form sind nicht nur unangebracht sondern verstoßen sicher auch gegen die Forenregel. Bitte zügle dich in Zukunft.
David Airlie scheibt da was von "Treiber verbessern".
Wer soll den Treiber denn "verbessern"?
Etwa er, der trotz aller Unterstützung durch ATI und seinen Arbeitgeber RedHat noch nicht einmal den freien ATI 100%ig zum laufen bekommt?
Bei Hardware ist man doch immer 100% vom Hersteller abhängig.
Das stimmt nur zum Teil. Wenn die Hardware selbst Fehler enthält, kann man oft wirklich nichts machen.
Hier ein paar Beispiele wie man Hardware durch eigene Software weiter benutzen konnte oder überhaupt ordentlich funktionsfähig bekam:
https://www.openwrt.org/
http://btwincap.sourceforge.net/story.html
http://www.ssclg.com/epsone.shtml
lg unreal
pro-linux ist hier leider auf eine Falschmeldung - wie viele andere auch - hereingefallen.
und genau das macht der Code nicht. Er leitet nur an die Firmware weiter. All dies ist in der Firmware implementiert inklusive dem Compiler (!) für GLSL.Genauer nachzulesen im Blog von David Airlie.
Insgesamt also nur viel Lärm um nichts, trotzdem schön, dass zumindest der Userspace offen ist - selbst wenn er nichts macht.
Dann ist die verwendete Grafik von Paul Beech auch falsch?
nein. Die Grafik ist richtig, nur was so eine Grafik nicht zeigen kann, ist dass die VCHIQ Schicht halt nichts macht.