Fuer Linux-Leute: Raspberry-Konkurrent?

Der Raspberry Pi kann 1080p30 Full HD H.264 Videos decodieren und encodieren. Weiss nicht, ob das in Hardware oder mit Hilfe der GPU implementiert ist, aber gibt ein Beispielprogramm auf der Plattform, was bei mir problemlos ein Video flüssig auf meinem 1900x1200 Display ausgibt (wahrscheinlich auf 1080p skaliert).

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Also bei meinem Chumby gibt es z.B ein Device im Kernel um I2C anzusprechen. Es war eine Sache von einer Stunde bis ich da was drauf ansprechen konnte. Aehnliches wuerde ich bei den anderen Systemen auch erwarten.

Olaf

Frank Buss :

Hmm, welche ARM-Controller in der Grössenordnugn mit dokumentierter Kameraschnittselle gibt es denn eigentlich. Auch für TI's aktuelle OMAPs 4 und 5 kriegt man ja keine offene Doku.

M.

Kuerzlich gab es ja wieder so ein "Stoermanoever":

Micha

Moin, zusammen,

Gibts aber nicht immer. Zum Beispiel ist in den Standarddistributionen für das Beagleboard kein Treiber für SPI enthalten, da muß man dann den Kernel neu übersetzen etc. etc.

Christian

Nimm lieber Renesas. Der SH7262 hat:

8-bit input conforming to the ITU-R BT.656 standard (27Mhz) 8-bit serial input conforming to the ITU-R BT.601 standard (27Mhz)

Allerdings ist mir bisher noch kein Grund eingefallen wofuer ich an einem Microcontroller eine Kamera brauche. Das sind doch eher seltene Sonderanwendungen.

Olaf

Olaf Kaluza :

Naja so ne 640x480 Kamera mit eingebauter Linse 2x3mm gross kostet 10Eur (RS) und man kann da mehr mit anstellen als mit ne CCD-Zeile. Nachteil für die Doku der Kamera musste NDA abschliessen. (ist aber immer ziemlich ähnlich zu den Vorgängern mit Doku OV565 z.b.) und dat dinens is nen minikleines BGA. Wenn man da aber was richtiges machen will (Bildverarbeitung) muss man eh mit ein paar 100MB RAM arbeiten...., letztlich geht das schon in Richtung Mini- PC.

M.

Nicht wirklich. So eine Kamera ist nämlich ein ziemlich universeller optischer Sensor.

Und bei den Preisen, zu denen die Dinger inzwischen zu bekommen sind, ist es u.U. sogar garnicht mal so verrückt, eine Kamera sogar als simplen Helligkeitssensor zu verwenden. Nämlich z.B. dann, wenn man die Helligkeit an bestimmten Stellen erfassen will und das dann vielleicht noch an mehr als einer gleichzeitig.

Ja klar, die Fähigkeiten der Kamera werden bei so einer Anwendung nicht mal näherungsweise ausgenutzt. Aber wenn man mal aufrechnet, welche Kosten entstehen, wenn man statt dessen "klassische" Sensoren verwendet, dann stellt sich schnell raus, daß die Kamera als leicht verfügbare Massenware schlicht billiger ist, obwohl sie für die Anwendung eigentlich hoffnungslos "überdimensioniert" ist.

Für die CPU-internen GPUs von Intel (Intel HD) wird von Intel offenbar massiv Manpower ins Development und den Support gesteckt -- und alle Linux-Bemühungen fließen als OpenSource in den Kernel ein. Und was die abliefern ist absolut einwandfrei: Bei meinem Laptop mit Sandy Bridge gehen mit den neusten Treibern alle GPU-Deepsleep-Varianten und er ist mir (auch bei Suspend, mplayer mit OpenGL-rendering und Nutzung von glx/drm etc) noch nicht abgestürzt, trotz "experimenteller" Dev-Version. Der Support auf der Mailingliste ist geradezu vorbildlich.

Gruß, Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa

Das liegt daran dass einer aus unserer Blindenhund-Aufzuchtgruppe dort als Ingenieur mitmischt 8-)

Was ich nie verstanden habe ist dass so viele Leute Bedenken mit den diversen Suspend- und Sleep- oder Hibernate-Modes haben. Ich benutze das sei Jahren ohne jedes Probleme, bei inzwischen fuenf verschiedenen Rechnern. Ok, normalerweise Windows aber das habe ich auch mit in einer VM laufenden Linux-Programmen so gemacht.

--
Gruesse, Joerg

http://www.analogconsultants.com/

Privat oder von Intel bezahlt?

Naja, Suspend to RAM bei Linux ist ja relativ jung. IIRC sind die notwendigen Shutdown- und Reenable-Hooks erst mit 2.2 oder 2.4 dazugekommen. Und anfangs hat das gar nicht mal so prima funktioniert... Neue Treiber implementieren die Hooks natürlich, aber das Nachziehen der älteren Teile hat schon gedauert. Aber ob ein Sound Blaster, den du heute auf Linux während dem Abspielen in den Suspend schickst, sich heute wieder fangen würde, weiß ich nicht ;-)

Viele Grüße, Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa

Er arbeitet bei Intel. Der grosse Intel Folsom Campus ist nur rund 10 Meilen von hier entfernt.

Linux ist ja auch juenger, das kann noch werden. Bei mir hat Ubunto dann eines Tages mittendrin eine Art Harakiri hingelegt. Seitdem ist es weg, einfach futsch, taucht als OS in der Liste der VM gar nicht mehr auf. Als waere Salzsaeure druebergelaufen. Allerdings war ich zu dem Zeitpunkt auch fertig mit dem was ich mit Linux ausprobieren wollte (gEDA) und habe es dann nicht mehr neu installiert.

--
Gruesse, Joerg

http://www.analogconsultants.com/

Das stimmt zwar, der GMA500 ist aber leider von PowerVR lizensiert.

Gruß Henning

Eine Linux-VM kann sich nicht selbst löschen, genau so wenig wie ein Linux- PC sich selbstständig in Luft auflösen kann.

Wahrscheinlich ist Deine Virtualisierungssoftware Amok gelaufen.

Gruß Henning

Ja, koennte sein, ist Sun VirtualBox. Die kommt selbst ordentlich hoch, aber Unbuntu hat sich unerlaubt vom Arbeitsplatz entfernt oder VirtualBox hat es wegen unflaetigen Benehmens rausgeschmissen :-)

--
Gruesse, Joerg

http://www.analogconsultants.com/

Miserabel.

NVidia hat nach wie vor keine großen Freunde im OpenSource-Bereich:

Man liest sich, Alex.

--
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

r da

Ist das so? Das letzte Mal, als ich nachschaute, taten sich Nvidia und = ATI mit den jeweiligen propri=E4tren Treibern nicht viel. Siehe zum Beispie= l:

680&num=3D1

Wenn im Zusammenhang mit Grafikkarten von einer "offenen Schnittstelle"= =20 die Rede ist, meint man meist die Schnittstelle =FCber die der Treiber = die=20 Hardware anspricht. Und auf diesem Feld zeigt sich Nvidia komplett zuge= kn=F6pft. (Im Gegensatz zu ATI und Intel) Entsprechend sind die Entwickler von Op= en- Source-Treibern f=FCr Nvidia-Karten auf Back-Engeneering mit all den da= mit verbundenen Nachteilen angewiesen. =20

Sie erdreisten sich, den Kernel weiter zu entwickeln...

So kann man es auch nennen, wenn ganze Produktgruppen nicht mehr vom=20=

propri=E4t=E4ren Treiber unterst=FCtzt werden. Dann hat man als Anwende= r die Wahl zwischen Pest (veraltetes System) und Cholera (schlechterer=20 Grafiktreiber)

------

--=20 Kai-Martin Knaak tel: +49-511-762-2895=

Universit=E4t Hannover, Inst. f=FCr Quantenoptik fax: +49-511-762-=

2211=09 Welfengarten 1, 30167 Hannover

GPG key:

get

Es soll Softwaredesigner geben, die in der Lage sind, Schnittstellen zu definieren, die einerseits lange Zeit stabil bleiben können, andererseits aber die Weiterententwicklung auf _beiden_ Seiten der Schnittstelle möglichst lange nicht hemmen, sondern eben dadurch beschleunigen und vereinfachen, DASS sie stabil sind.

Dem Vernehmen nach soll die Definition solcher Schnittstellen sogar eine der wesentlichen Aufgaben von Softwaredesignern sein, also von Leuten, die weiter als vom Nachtpups bis zur Morgenlatte denken können...

Hätte der Kernel sinnvolle und stabile Schnittstellen, könnten permanent ca. 1/4..1/3 des Entwicklungsaufwands für neue Kernelversionen eingespart werden. Das ist nämlich der Aufwand, der jedesmal entsteht, wenn sich was ändert, was Anpassungen bei den Hunderten existierender Treiber erforderlich macht.

Stell dir mal vor, wie schnell der Kernel weiterentwickelt werden könnte, wenn diese Manpower direkt dabei mitwirken könnte, statt dafür verschwendet zu werden, ständig die ganzen Treiber anpassen zu müssen. Was im übrigen nichtmal besonders gut funktioniert, etliche Treiber sind inzwischen de facto unbrauchbar, viele zumindest funktional erheblich eingeschränkt in dem Sinne, daß sie nicht von den neuen Funktionalitäten im Kernel profitieren.

Sprich: der Verzicht auf die stabilen Schnittstellen wirkt sich in keinster Weise positiv aus. Denn genau an diesem Punkt würde der einzige Vorteil dieses Verzichts zum Tragen kommen. Aspekte, die eine einmal definierte Schnittstelle nicht unterstützt, können nicht genutzt werden, bis die Schnittstelle erweitert oder neu definiert wird, bei nicht existierenden Schnittstellen ist das nicht so. Das hilft aber ganz offensichtlich auch nicht wirklich...

Naja. Bei mir hat Nvidia mit dem letzten Sicherheitsupdate sehr zuverlässig die virtuellen Konsolen, die ich üblicherweise ganz gerne mal benutzt habe, kaputt gemacht. Bisher hat kein Treiberupdate seit diesem "Sicherheitsproblem" diesen Fehler beseitigen können.

Meine Vermutung: Meine Grafikkarte ist vermutlich mittlerweile zu alt (8600 GT) und gerade hier wäre man mit einem OSS-Treiber nun möglicherweise besser aufgehoben. Nvidia testet möglicherweise schon nicht mehr mit älteren Karten.

Unabhängig davon ist mir eine Closed-Source-Firmware, die ich in die Karte schicken muss, allemal lieber als ein Closed-Source-Treiber, der direkt auf meinem Rechner laufen muss. Nouveau wird aber, wenn es dann mal so weit ist, beides unnötig machen, denn AFAIK generiert der Treiber seine Firmware für die Karte selber.

Gruß

Manuel