[dss-developer] Fragen zu Add-ons und Entwicklungsstatus für virtuelle Geräte

Lukas Zeller luz at plan44.ch
Mon Oct 13 11:37:43 CEST 2014


Hallo Jan,

Michael hat Dir ja zu den meisten Punkten schon ausführliche Antwort gegeben.

Da ich aber das letzte Jahr (als Externer) an der vDC-API gearbeitet habe und eine komplette vdc-Implementation (vdcd) als OpenSource beigesteuert habe, hier noch meine Ergänzungen:

On 03.10.2014, at 11:41, MasterJani at gmx.de wrote:

> 2-1  Ist die API für virtuelle Geräte bereits freigegeben, und wenn nicht, wann ist die Freigabe geplant?

Zur Einsicht frei ist die API schon lange (https://gitorious.digitalstrom.org/virtual-devices/vdcd/trees/master/docs), seit das vdcd-Projekt unter GPLv3 freigegeben ist (seit Anfang 2014). Aber es wurde über den Sommer noch intensiv daran (um)gebaut.

Unterdessen kann man die API als stabil bezeichnen. Es wird keine Änderungen mehr geben, die die Binär-Kompatibilität brechen, und der Basis-Satz von nicht-optionalen Properties ist festgelegt. Wahrscheinlich kommen mit der Zeit noch Properties oder Calls dazu, aber ohne das Bestehende signifikant zu ändern.

> 2-2 Wird ein vdSM und vDC host standardmäßig auf der DSS laufen, sodass man ein vdSD in JavaScript entwickeln kann?

Ein zentrales vdSM ist dem Hören nach in der Diskussion, aber Genaues weiss ich da nicht. Für angstrom und poky gibt es seit Neuerem prebuilt binaries im gitorious: https://gitorious.digitalstrom.org/virtual-devices/vdsm-binaries

Ein "vdc host" ist einfach die Bezeichnung für ein Stück Software, das die vDC-API versteht, und einen oder mehrere "vcds" mit je einem oder mehreren "virtuellen devices" repräsentiert. *Den* vcd host gibt es nicht - es gibt einige Implementationen davon für verschiedene Zwecke.

Eine davon ist der oben erwähnte "vdcd" (https://gitorious.digitalstrom.org/virtual-devices/vdcd); dieses Projekt ist als C++ Framework konzipiert mit dem Ziel, das (teilweise komplexe) digitalSTROM-Verhalten inkl. Properties, Settings, Szenenverwaltung etc. fertig bereitzustellen, so dass die Implementation von Devices möglichst einfach wird und unbelastet von dS-Spezifika ist.

Andere Implementationen decken eine ganz bestimmte Anwendung ab, und bauen auf der (C) libdsvdc (https://gitorious.digitalstrom.org/virtual-devices/libdsvdc) auf, die die vdc-API-Kommunikation sowie das Message-Handling (z.B. Property-Abfragen aufbauen und decodieren etc.) zur Verfügung stellt.

Ein vdc-host mit einer Architektur, um vdcs und virtuelle devices in einer Skriptsprache zu schreiben, ist denkbar, aber meines Wissens hat noch niemand sowas angefangen.

> 2-3 Wenn 2-2 mit Nein beantwortet wird, welche Komponenten müsste ich selbst entwickeln, damit ein virtuell device der Gruppe Video auf der DSS  läuft? Dieses vdSD würde den Fernseher via TCP/IP einbinden.

Du kannst den vdcd nehmen, und ausgehend vom Demoprojekt (demovdc) ein TV-device machen. Ein ausprogrammiertes Standardverhalten für Video gibt es da allerdings noch nicht - ich weiss gar nicht, ob ein Video-Standardverhalten schon dokumentiert ist. Das Ziel des vdcd-Projekts ist es natürlich, solche Standardverhalten, sobald bekannt, umzusetzen und bereitzustellen, damit die Implementation für einzelne TVs möglichst simpel wird. So wie es jetzt z.B. für Farblampen schon besteht - das Framework hat alles schon drin, inkl. HSB/RGB/xy-Konversion, Kalibrierung, Farbszenen - der gerätespezifische Teil besteht lediglich darin, R,G,B an die Hardware senden zu können.

Gruss von Lukas


More information about the dss-developer mailing list