Touch Display - Typ der beiligenden Platine?

Alex schrieb:
> 1. Welcher Standard ist der Display Anschluss (Flachbandkabel) ?
>    Ich vermute DSI?

Nein. Das dürfte ein stinknormales LVDS-Display sein.

> Ich vermute mal die Ansteuerungslogik bzw. der Displaycontroller ist am
>    Display und auf der Platine nur ein Konverter (HDMI/VGA <--> DSI
> o.ä.)

Die Platine ist ein HDMI/VGA-zu-LVDS-Konverter.

Das ist damit auch der Displaycontroller; was stellst Du Dir darunter 
anderes vor?

Da das Display kein DSI-Display ist, kannst Du es auch nicht am 
DSI-Anschluss betreiben.

DSI ist praktisch undokumentiert, da die MIPI keine Unterlagen an 
Nicht-Mitglieder 'rausrückt. Obendrein wird DSI nur in Mobilgeräten 
(Smartphones & Tablets) verwendet; nur deren Hersteller produzieren 
ausreichende Stückzahlen, daß es sich lohnt, MIPI-Mitglied zu werden.

Und wegen der miserablen Dokumentationslage wird die Anzahl verfügbarer 
DSI-Displays sich kaum vergrößern, aus dem gleichen Grund ist die 
Schnittstelle für Bastelzwecke auch reichlich ungeeignet.

Obendrein ist es so, daß nicht jedes Display in Mobilgeräten ein 
DSI-Display ist; im iPad beispielsweise wird Embedded DisplayPort 
verwendet, und andere Geräte mit geringeren Auflösungen verwenden 
herkömmliche LVDS-Displays -- wie das, das Du da als eBay-Auktion 
gefunden hast.

Alex schrieb:
> Das Protokoll kann wohl alles mögliche sein.

Da ist nicht viel Protokoll. Als Unterschiede gibt es die verwendete 
Farbtiefe (8 oder 6 Bit pro Grundfarbe) und einen oder zwei Datenkanäle, 
was sich in vier oder acht LVDS-Datenleitungspärchen niederschlägt.

> LVDS scheint mir da auch eher schlecht als recht dokumentiert zu sein.

Das ist es nicht; sieh Dir einfach mal ein Datenblatt eines 
entsprechenden Displays an, da steht alles drin.

> Im Grunde genommen dass das Display per Kommandos angesprochen werden
> kann

Das macht so ein Ding nicht, das macht aber auch ein DSI-Display nicht. 
So etwas ist ein Monitor, der ein zyklisch aktualisiertes Bild 
anzeigt.
Deswegen findest Du auch nichts über irgendwelche "Kommandos" in den 
Displaydatenblättern, die gibt es nämlich nicht.
Stattdessen wird mit üblicherweise 60 Hz das komplette Bild Pixel für 
Pixel an das Display übertragen.

Den Aufbau des Bildes, das Verwalten des Bildspeichers etc. muss eine 
separate Elektronik durchführen. Der Raspberry Pi macht das - und er 
gibt die Bilddaten entsprechend aufbereitet an seiner 
Monitorschnittstelle (HDMI) aus.

Alexander schrieb:
>> Stattdessen wird mit üblicherweise 60 Hz das komplette Bild Pixel für
>> Pixel an das Display übertragen.
> Aber auch das ist nicht standardisiert, korrekt?

Es gibt Ausnahmen mit anderer Bildwechselfrequenz. Die aber sind selten.

> Das heißt jedes Display erhält seine Daten in (geringfügig) anderer
> Reihenfolge?

Nö. Sofern es mit einem LVDS-Kanal* angesteuert wird, ist die 
Reihenfolge identisch.
Zeilenweise, von links nach rechts und von oben nach unten, so wie ein 
oller Röhrenkübel auch angesteuert wurde.
Das wird mit drei Taktsignalen gesteuert, Pixeltakt, Zeilentakt (Hsync) 
und Bildwechseltakt (Vsync). Die Namen können abweichen, die Funktion 
bleibt aber die gleiche.

Bei zwei** LVDS-Kanälen werden zwei Pixel gleichzeitig übertragen.

Dazu wird das Display üblicherweise horizontal geteilt, so daß es eine 
obere und untere Hälfte gibt, die gleichzeitig angesteuert werden.

(Manche Displays bieten Steuersignale an, mit denen sie das übertragene 
Bildsignal vertikal und/oder horizontal spiegeln können, das ist dann 
noch mal eine Sonderlocke).

> würde das doch heißen das ich auch beim Laptop zum Beispiel nicht
> einfach jedes Display anstecken kann wenn der GPU Controller im Laptop
> dieses Display nicht unterstützt oder?

Richtig. Allerdings ist es mittlerweile verbreitet, daß das Display ein 
EEPROM enthält, in dem die zur Ansteuerung wesentlichen Daten 
gespeichert sind und die Graphikhardware passt sich dem --innerhalb 
gewisser Grenzen-- an. Das muss natürlich nicht so sein, es gibt leider 
immer wieder Ausnahmen.

Ein Problem gibt es, wenn zwischen Ein- und Zweikanal-Displays 
gewechselt wird, da muss nämlich das Displaykabel passen; die 
Notebookhersteller sind hier gerne sparsam und lassen bei 
Einkanalbetrieb die unbenutzten Leitungen des zweiten Kanals weg.

Es gibt diese Displayansteuerungselektroniken auch in vom Benutzer 
konfigurierbaren Varianten, die Firma Pollin vertreibt so etwas. Da wird 
mit Jumpern ein Parametersatz aus einer Tabelle ausgewählt. Hat man ein 
Display, das in dieser Tabelle zu finden ist, kann man die Platine 
nutzen, sonst nicht.


Ein zweiter nicht standardisierter Punkt ist die Ansteuerung der 
Hintergrundbeleuchtung. Es gibt Displays mit LED-Beleuchtung, bei denen 
die Ansteuerung über das selbe Kabel erfolgt wie auch die restliche 
Ansteuerung (das in Deinem eBay-Link ist so eines), aber es gibt auch 
Displays, bei denen dafür ein separater Anschluss verwendet wird - und 
bei Displays mit CCFL-Beleuchtung ist das sowieso der Fall. Hier gibt es 
noch je nach Größe des Displays und je nach Verwendungszweck 
unterschiedlich viele CCFL-Röhren, in Notebooks ist eine einzelne 
üblich, bei Desktopmonitoren können auch deutlich mehr auftreten.

Die benötigen dann eine passende Hochspannungserzeugung, den sogenannten 
"Inverter".


*) Das ist die Summe der Farb- und Takt-Informationen, also vier 
LVDS-Datenleitungspärchen.

**) Die werden i.d.R. als "even" und "odd" bezeichnet, so daß es die 
unter* erwähnten Datenleitungspärchen doppelt gibt.

Alexander schrieb:
> Flashe ich den mit einer eigenen Firmware und greife während der
> Entwicklung auf Bibliotheksfunktionen (für LVDS oder was auch immer)
> zurück?

Dies System wird im normalen PC in der Startphase benutzt. Die 
Grafikkarte hat eine eigene rudimentäre Firmware ('BIOS') auf der Karte, 
die für simplere Sachen ausreicht, um bspw. Zeichen auf den Schirm zu 
bringen oder Speicherbereiche in den Bildspeicher zu kopieren.

Alexander schrieb:
> Oder wird ein Grafik Prozessor bereits mit Firmware ausgeliefert und ich
> übergebe ihm z.B. ein Bitmap und er kümmert sich um die weitere
> Verarbeitung (Behält es im Speicher bis aktualisiertes Bild Material
> kommt, wiederholt es auf dem Display etc...)

Höhere Grafikaufgaben laufen so gut wie immer durch einen an die GPU 
angepassten Treiber. Das ist unter Linux genauso wie unter Mac OS oder 
Windows. Dazu 'übersetzt' der Treiber standardisierte Aufrufe wie OpenGL 
oder DirectX auf die 'Sprache' der GPU und nutzt dann deren Funktionen, 
um komplexere Bilder etc. zu generieren.

Das Problem beim Edison ist, das du gar keinen Datenbus hast, an den du 
eine GPU andocken könntest, zumindest nicht so schnell, das du deren 
Vorteile nutzen könntest. Es wäre allerdings denkbar, einen simplen 
Framebuffer Treiber zu schreiben, der mittels Timer und ganz schön 
Rechenleistung eine Teil des Hauptspeicher so über den 70-Pin Anschluss 
ausgibt, das man da ein recht dummes LCD anschliessen kann. Das ist aber 
eine Aufgabe für jemanden, der sich sowohl mit LCD als auch mit der 
Architektur des Atom gut auskennt.
Hier sind zwei solcher Projekte, die kleine Displays am Edison 
betreiben:
https://blog.adafruit.com/2016/05/03/framebuffer-fbtft-for-intel-edison-ssd1322-oled-display-linux-yoctoproject/

http://hackaday.com/2015/01/10/running-doom-on-the-intel-edison/

Letzteres benutzt den Arduino Shield für den Edison.

Alexander schrieb:
> Der Edison ist für mich quasi perfekt

Ist ja auch ein nettes Dingelchen, aber eben nicht für Bildschirme 
gedacht, sondern eher als 'Embedded Atom'. Im 'Doom on Edison' Projekt 
sagt der Entwickler ja auch, das die Leistung mit Bildschirm dann eher 
auf 486er Niveau ankommt und gerade mal 15 fps schafft. Mit einem 
grösseren Display wird das dann noch weniger.