1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
|
Philips TV-Remote unter Linux
=============================
:author: Benjamin Franzke
:lang: de
:imagesdir: image
// a2x: --dblatex-opts="-p thesis.xsl -s thesis.sty -b xetex"
[abstract]
== Aufgabe
Ziel dieses Forschungsprojektes ist die Programmtechnische Umsetzung
der Nutzung der Philips TV-Firmware als Netzwerkbasierter-Infoscreen.
Als Platform ist dabei GNU/Linux zu verwenden und Lösungsmöglichkeiten für
die Probleme der aktuellen Konfiguration mit dem Windows Client Pluggit
sind zu evaluieren.
== Grundlagen
*DirectFB*
'DirectFB' ist eine kleine Bibliothek, die als Hauptaufgabe
Beschleunigung durch Grafik-Hardware bereitstellt.
Außerdem werden auch Eingabegeräte unterstützt, und es enthält ein
integriertes Fenster-System.
Dementsprechend kann DirectFB als Hardware-Abstraktions-Schicht bezeichnet
werden.
*DirectFB Voodoo*
'DirectFB Voodoo' ist ein Aufsatz bzw Proxy-Kanal für DirectFB.
Es besteht aus einer Client-Server Architektur.
Der Server ist dabei das Anzeige Gerät und bietet über den Voodoo Kanal
zugriff auf den eigenen Framebuffer.
Die Client-seitige Implementierung leitet 'DirectFB'-API-Aufrufe per
'DirectFB-Voodoo' an den Server weiter, auf dem diese dann ausgeführt werden.
'DirectFB-Voodoo' ist demzufolge eine Remote-Rendering Infrastruktur
die das Zeichnen von Primitiven wie Rechtecken und Kreisen ermöglicht,
aber auch das übertragen von ganzen Bildinhalten.
*JointSpace*
'JointSpace' ist ein Framework und API für Fernseher von Philips.
Es ermöglicht das Fernseher über das API gesteuert werden können,
und eine Bildübertragung über das Netzwerk.
Das API zur Steuerung der Fernseher basiert auf einem REST-full
HTTP-Protokoll.
Für die Bildübertragung wird 'DirectFB Voodoo' eingesetzt.
== Ist-Zustand
Verwendet werden Fernseherer der 7000er Serie von Philips, auf die eine,
direkt vom Hersteller erweiterte Firmware geladen wird. Diese beinhaltet die
'JointSpace' erweiterung.
Als Datenquelle dient eine Windows-Installation in einer virtuellen Maschinen,
welche das ebenfalls vom 'JointSpace' bereitgestellte Programm 'Pluggit'
verwendet.
Die einzelnen Fernseher sind alle in eigenen Netzen, da zum Verbindungaufbau
ein Netzwerk-Broadcast genutzt wird und sich so die Fernseher gegenseitig
stören würden, wenn in einem Netzwerk enthalten.
Der Firefox-Browser wird für die Darstellung im Vollbildmodus eingesetzt, da
er unter Windows einer der stabilsten und ausgetestetsten, standardkonformer
Browser ist.
Die Fernseher bieten eine native Auflösung von 1920x1080 Pixeln,
die Remote-Anzeige funktioniert aber nur bis zur Auflösung von 1280x720
Pixeln.
== Problemlösung & Implementation
Im ersten Schritt ist eine eins-zu-eins Umsetzung der Anzeige einen
Linux-Screens auf einen Fernseher zu implementieren.
Im zweiten sollten von einem Rechner mehrere Streams an JointSpace-Fernseher
gesandt werden. In diesem Fall 3 Clients.
.Client-Server Interaktion
image::directfb-voodoo-js.eps[]
=== Pluggit
Als Basis für die Programmtechnische Umsetzung dient der Bestehende
Windows-Client Pluggit, sodass die bereits ausgetestete Remote-Rendering
Infrastruktur wiederverwendet werden kann.
Pluggit wurde so verändert, dass es X11-Protokoll anstatt der WinAPI verwendet
wird, um den Inhalt eines Fensters oder des ganzen Framebuffers anzuzeigen.
Dazu ist eine 'SourceX11' Klasse notwendig, die das in Pluggit enthaltene
Interface 'Source' implementiert.
// TODO: Graph?
==== Verbindungsaufbau
Die DirectFB-Voodoo Platform nutzt als Standardmethode zum Verbindungsaufbau
einen Broadcast Request, um verfügbare Anzeigegeräte zu finden.
Dies ist für den Einsatz im Heimnetzwerk gedacht, bei dem der
Verbindungsaufwand möglichst gering gehalten werden soll.
Sind meherere der Fernseher in einem Netzwerk, so ist nicht eindeutig
definiert, welcher zuerst auf den Broadcast antwortet, und dadurch für die
Verbindung ausgewählt werden wird.
Aus diesem Grund ist eine sofortige Unicast-Verbindung nötig.
Die Bibliothek bietet kein direktes API, um die Ziel-Addresse zu verabeiten.
Die Initialisierungsmethode +DirectFB::Init()+ erwartet einen Argumentzähler
und -vektor. Dieser Vektor bezieht sich auf die Kommandozeilen Argumente,
im folgenden beispielhaft dargestellt:
[source,c]
----
#include <directfb.h>
int
main(int argc, char *argv[])
{
DirectFB::Init(&argc, &argv);
return 0;
}
----
==== Verbindungsabbruch
Bricht die Verbindung ab -- z.B. durch Ausschalten des Fernsehers oder durch
Auswählen einer anderen Quelle -- wird dies durch die DirectFB Bibliothek
nicht an die Anwendung signalisiert.
Im produktiven Einsatz ist es bei Remote-Steuerung deshalb nicht zu erkennen, ob die Verbidnung
besteht. Im weiteren ist auch keine automatisierte Neuverbingung unmöglich.
//die Anwendung signalisiert.
//Intern wird der Rückgabewert von +send(2)+ nicht auf einen Verbindungsabbruch
//geprüft.
*Lösung:*
Die Bibiliothek DirectFB wurde erweitert, das SIGPIPE signal vom Kernel zu
empfangen. Pluggit installiert für DirectFB eine Signal Behandlungsroutine
und bricht die Programmausführung ab.
Ein Shell scripts das pluggit überwacht erkennt dies am Rückgabe-Status des
Pluggit-Prozesses und startet diesen neu.
//== Webbrowser-Rendering
=== Framebuffer Größenlimit
Bei der Verwendung von 'Pluggit' unter Windows besteht das Problem, dass eine
Maxmimale Auflösung von +1280x720+ Pixeln genutzt werden kann.
Dieses Limit ist kein Fehler im Programm oder eine Einschränkung des
Betriebsssystems, sondern das API erlaubt keine größe Auflösung.
Bei Verwendung von z.b. einer +1920x1080+ Auflösung -- bei einem Fernseher,
der diese Auflösung per HDMI unterstützt -- signalisiert das API
einen Fehler, dass ein invalides Argument übergeben wurde.
=== Framebuffer Auslesen
Das X11-Protokoll bietet die Möglichkeit den angezeigten Framebuffer
über die Funtkion +XGetSubImage(3)+ auszulesen.
Darüber hinaus gibt es eine Anbindung an +shmget(2)+, sodass Unix
Shared-Memory verwendet werden kann.
Dies bietet den Vorteil, dass die Framebuffer-Daten nicht über den
X11-Protokoll-Socket übertragen werden müssen, sondern direkt gelesen werden
können.
Es wird ein X11-Pixmap erzeugt, welchem ein auf XImage auf Shared-Memory Basis zu
grunde liegt.
Zum Auslesen wird nun +XCopyArea(3)+ mit dem X11-Pixmap als Argument
aufgerufen. Der X-Server schreibt in der Folge den angefragten Bildinhalt
in den Shared-Memory,
=== Multi-Client
Teil der Anforderung ist, mehrere Fernseher gleichzeitig mit unterschiedlichen
Bildern zu beliefern.
Um mehrere Fenster darzustellen, wird ein großer Anzeigebreich benötigt.
Mit 'XRandR' wird dies durch folgenden Aufruf erreicht:
[source,sh]
----
xrandr --fb $((1280*3+10))x768
----
.X11-Fenster Konfiguration
image::framebuffer.svg[]
=== Browser
Die Anzeige des Infoscreens erfolgt über eine HTML-Website, die auch
Multimediainhalte enthält.
Aus diesem Grund ist es nötig, dass das HTML von einem Web-Browser gerendert
wird.
In Betracht kommt auf Grund der Bekanntheit und Stabilität der
Firefox-Browser.
Dieser kann nur im Vollbild-Modus so konfiguriert werden, dass nur der Inhalt
im X11-Fenster -- welches ausgelesen werden soll -- angezeigt wird, Menus und
Scrollbars sind im normalen Floating-Modus immer vorhanden.
Ein weiteres Problem stellt die eindeutige Addressierung der Window-ID, bei
Verwänderung mehrerer Firefox-Fenster.
Es gibt keine direkte Möglichkeit die Window-ID zu erhalten, nur über Matching
des Titels des Firefox-Fensters.
Die Verwendung für mehrere Infoscreens würde es nötig machen den Titel des
Angezeiten Inhalts zu wissen, und in der Programmlogik zu berücksichtigen.
Eine Veränderung des Inhalts würde damit auch eine Anpassung des Programms
erfordern.
Deshalb wird ein Web-Browser benötigt, der es ermöglicht nur den Inhalt der
Website im X11-Fenster darzustellen.
Der Browser 'Surf' footnote:[http://surf.suckless.org] von 'suckless.org' ist
mit dem Prinzip erstellt worden, in andere Programme über das X11-XEmbed
Protokoll eingebettet zu werden, z.b. um mehrere Instanzen in einem
Tab-Manager zu embedden.
Dies ermöglicht per Design zwei Vorteile:
- Die Window-ID wird auf +stdout+ ausgegeben. +
(Kann demzufolge als Parameter an Pluggit übergeben werden.)
- Keine Bedienelemente vorhanden, denn der Browser wird über X11-Properties
gesteuert -- das erlaubt Scripting.
== Test
Getestet wurde jeweils mit der Infoscreen-Website
footnote:[http://et.hs-wismar.de/~infosc/index.php?file=config16n]
des Fachbereichs EuI:
Da während der Entwicklung nicht dauerhaft Philips-Fernseher zur Verfügung
standen, wurde der durch das 'JointSpace'-Projekt als VMWare-Virtuelle
Maschine bereitgestellte Simulator mit QEMU verwendet.
Das Anzeigen des Browser-Inhaltes und die korrekte Wiedergabe des Videos
entscheiden über das Bestehen des Tests.
== HowTo
//=== Linux-Installation
//Arch installieren?
=== System Vorraussetzungen
Beispielhaft für Gentoo:
[source,sh]
----
emerge -va wmctrl surf
----
=== DirectFB
Für diese Arbeit wurde die, zum Zeitpunkt der Bearbeitung, neuste Version von
'DirectFB' verwendet:
DirectFB141_source_1.3.1beta5.7z
footnote:[http://sourceforge.net/projects/jointspace/files/remote_applications_SDK/]
[source,sh]
----
7z x DirectFB141_source_1.3.1beta5.7z
----
Die Sourcen, inklusive benötigter Patches (mit GIT-History), sind auch im
beiliegenden Archiv enthalten.
=== Pluggit
[source,make]
-------------------------------------------------------------------------
.PHONY: pluggit
pluggit:
rm -f pluggit/pluggit # <1>
$(MAKE) -C directfb-voodoo/ -f makefile.voodoo DEBUG=$(DEBUG) package # <2>
$(MAKE) -C pluggit/ -f makefile.voodoo DIRECTFB_VOODOO=../directfb-voodoo/DirectFB_Voodoo all
-------------------------------------------------------------------------
<1> In der Entwicklungsphase ist es notwendig, dass pluggit neu gelinkt wird,
wenn directfb verändert wird.
<2> Der DirectFB package baut die Bibliothek und kopiert Header an die
benötigten Stellen.
Für die Übersetzung von DirectFB und Pluggit muss also nur folgender Befehl im
Quellverzeichnis des Projekts ausgeführt werden:
[source,sh]
------------
make pluggit
------------
== Bewertung & Ausblick
Die Performanz ist durch das ständige Übertragen komplette Bilder durch die
Übertragungsbandbreite eingeschränkt.
Ein weiterführender Ansatz wäre es, das sich in Entwicklung befindene -- und
deshalb zum Zeitpunkt dieser Arbeit noch nicht verwendbare -- WebKit-DirectFB
footnote:[http://git.directfb.org/?p=libs/WebKitDFB.git;a=summary]
backend zu nutzen.
// vim: set syntax=asciidoc tw=78 filetype=asciidoc:
// spell spelllang=de,en:
|