Outside the Walled Garden

Wie Sonntag geschrieben, scheint der K1901 Displaycontroller gelegentlich recht oft in irgendeiner Form hängen zu bleiben und nicht mehr weiterarbeiten zu wollen.

Dies geschieht im Allgemeinen in einem Schritt, in dem der Treiber auf die Bereitschaft des Controllers warten muss — meist das schlafen gehen oder aufwachen — und mündet darin, dass das System scheinbar nicht mehr reagiert.

Jetzt habe ich zwar so eine Art Hang-Detector gebaut, der in diesem Fall den K1901 resetten soll:

auo_k1901fb auo_k1901fb: controller hang, do recovery
Backtrace: 
[] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c)
 r7:c79dfe8c r6:c714de98 r5:c714dec0 r4:00000000
[] (dump_stack+0x0/0x1c) from [] (es600_epd_wait_for_rdy+0xdc/0x100 [es600_epd])
[] (es600_epd_wait_for_rdy+0x0/0x100 [es600_epd]) from [] (auok190x_runtime_resume+0x68/0x8c [auo_k190x])
 r7:c79de000 r6:c02fc548 r5:c7169e08 r4:c714de98
[] (auok190x_runtime_resume+0x0/0x8c [auo_k190x]) from [] (pm_generic_runtime_resume+0x34/0x40)
 r5:c7169e08 r4:00000008
[] (pm_generic_runtime_resume+0x0/0x40) from [] (rpm_resume+0x384/0x52c)
[] (rpm_resume+0x0/0x52c) from [] (pm_runtime_work+0x84/0x94)
[] (pm_runtime_work+0x0/0x94) from [] (process_one_work+0x24c/0x3a8)
[] (process_one_work+0x0/0x3a8) from [] (worker_thread+0x20c/0x428)
[] (worker_thread+0x0/0x428) from [] (kthread+0x8c/0x98)
[] (kthread+0x0/0x98) from [] (do_exit+0x0/0x670)
 r7:00000013 r6:c00226a8 r5:c003831c r4:c7839edc

aber, dass scheint auch nicht in 100% der Fälle zu funktionieren. Die Warscheinlichkeit liegt dabei auch wirklich bei 100%, nur die Zeitspanne variiert.

Es bleibt also momentan nur die Möglichkeit, das Power-Management für den K1901 insgesamt zu deaktivieren — genauso wie es auch die Amazon-Entwickler 2009 getan haben,

Bis heute hatte ich den Unterschieden der Displaycontroller nicht sehr viel Aufmerksamkeit geschenkt. Einige der Kommandos unterschieden sich zwar, aber im Großen und Ganzen lief alles wie gehabt. Ein weiterer Blick in die Amazon-Quellen förderte dann aber einen sehr großen Unterschied zutage.

Der K1901 kann Display-Updates asynchron verarbeiten.

Update eines ePaper-Displays

Um die Tragweite dieser Fähigkeit zu verdeutlichen möchte ich nochmal kurz den normalen Update-Zyklus eines ePaper-Displays beschreiben.

Anwendungen schreiben ihre gewünschten Pixeldaten in den sogenannten Framebuffer — bei den meisten eBook-Reader ist dies einfach nur ein Stück des normalen Hauptspeichers. Da das Display aber zu träge ist, um jedes geänderte Pixel einzeln zu aktualisieren, werden Änderungen eine Zeit lang gesammelt und dann am Stück zum Display übertragen.

Controller-Vergleich

Der AUO-K1900 arbeitet dabei synchron. Wenn er also gerade ein Update einer Displayregion ausführt, markiert er sich als beschäftigt und ist nicht bereit zu dieser Zeit ein weiteres Update anzunehmen. Da das Display eine halbe bis eine Sekunde für das Update benötigt, limitiert dies die mögliche Performance auf 1-2 Frames pro Sekunde.

Der K1901 hingegen arbeitet wie oben beschrieben asynchron, d.h. während er noch mit einem Update beschäftigt ist, können trotzdem bereits neue Daten an ihn übermittelt werden. Bei meinen Tests hatte er mit den von mir vorgesehenen 4 Frames pro Sekunde überhaupt keine Probleme — seine obere Grenze muss ich erst noch finden.

Anschauungsmaterial

Und was tut man jetzt mit solch geballter Display-Performance — ScummVM starten.

Es lief auch alles soweit flüssig mit den oben erwähnten 4fps. Update: weitere Tests zeigen auch, dass diese 4fps anscheinend das obere Limit sind. Jedenfalls kommt es bei mehr Frames pro Sekunde zu Instabilitäten des Controllers. Das instabile Verhalten tritt öfter auf — hier ist also noch etwas debugging angesagt. Interessanterweise hatten die Amazon-Entwickler bei diesem Problem aufgegeben, denn im Kindle-Code findest sich nur eine Konstante die das Powermanagement für den K1901 komplett deaktiviert. Für interessierte gibt es auch noch ein wackeliges Video:

Auf dem Oyo 1 funktioniert das Ganze auch — nur eben mit einem Frame pro Sekunde viel ruckeliger.

Seit einer Woche bin ich ja im Besitz eines Oyo 2 — Zeit also, für ein paar mehr Details dazu.

Äusserlichkeiten

Die meisten Dinge zum äusseren Eindruck habe ich ja bereits Ende November geschrieben. Nach längerem Gebrauch kann ich nur beklräftigen, dass mir die Form, Plastiksorte und Haptik sehr gut gefallen und ich ertappe mich gelegentlich dabei, wie einfach mal über ihn streiche :-) . Man kann also sagen, da hat sich jemand Mühe gegeben. Nur das Gewicht ist etwas bedenklich, denn im Vergleich zur Konkurrenz ist er schon eine ganze Ecke schwerer.

Der verbesserte Kontrast ist auch deutlich zu sehen und steht einem Pearl-Display meiner Meinung relativ wenig nach. Besonders deutlich wird die Verbesserung sichtbar, wenn ein Oyo 1 daneben liegt, wobei mich das Oyo-1-Display auch nie in einem so hohen Maße gestört hat.

Die inneren Werte

Meine erste Handlung — noch vor dem ersten Einschalten — war natürlich, den Oyo 2 auf zu machen und einen Blick ins Innere zu werfen. Und siehe da, alle meine Theorien vom August letzten Jahres treffen zu.

Im ersten Augenblick sind erstmal gar keine Unterschiede zu erkennen, denn diese offenbaren sich erst bei genauerem Hinsehen.

Oyo 2 links und Oyo 1 rechts — die Ähnlichkeit ist sehr gut zu erkennen.

So ist zum Beispiel der große Schild, unter dem Prozessor und RAM sitzen um 180 Grad gedreht — zu erkennen an den Öffnungen. Dort hat sich also am Layout etwas geändert. Da sich der Prozessor immer noch als S3C2416/S3C2450 meldet, dürfte dies das vermutete Upgrade auf die S3C2450-Variante sein. Der Audio-Codec ist nun kein ALC5624 von Realtek mehr, sondern ein ALC5626 — war vermutlich günstiger zu beschaffen.

Eine große Änderung, mit der ich jetzt nicht unbedingt gerechnet hatte, versteckt sich unter dem Touchscreen-Controller (orange Folie im oberen Teil). Statt des AUO-K1900 kommt nun sein Nachfolger der K1901 als Displaycontroller zum Einsatz. Worin die Unterschiede oder Verbesserungen genau bestehen muss ich noch ergründen, auf alle Fälle haben sich einige der Kommandos zu Ansteuerung geändert. Interessant ist aber, dass dies nun der Chip ist, mit dem die Amazon-Entwickler zu irgend einer Zeit mal experimentiert haben. Das heißt ich kann auch dort spicken gehen.

Startversuche

Durch die Ähnlichkeiten der Hardware lag es nahe, dass sich auch an der Software wenig ändern würde. Mein Debian-System konnte ich auch ohne Probleme über die immer noch existierende Dual-Boot-Möglichkeit starten. Durch den geänderte Display-Controller war zwar erstmal nichts zu sehen, aber ich konnte ohne Probleme über die USB-Verbindung per SSH auf den Oyo-2 zugreifen.

Die letzten Tage war ich also damit beschäftigt den K1901 zum Reden zu bringen. Hilfreich war dabei, dass in den Kernelquellen vom Oyo 1 ein Überbleibsel des K1901-Treibers vergessen wurde (drivers/video/epaper_g1v1.c) und sich auch nur einige der Anzeige-Kommandos geändert haben.

Dass der von Qisda gelieferte Kernel für die eBook-Reader voller Probleme ist, klang ja bereits mehrfach an. Während der Oyo diesen Kernel anscheinend ohne Änderungen verwendet, hat zum Beispiel Asus relativ hohe Entwicklungssresourcen eingesetzt, um einige Probleme für den DR-900 auszubessern.

Heute habe ich nun festgestellt, dass Bookeen es auch endlich geschafft hat, die Verpflichtungen aus der GPL zu erfüllen und zumindest einen Teil der Quellen, nämlich des Linux-Kernels und der Busybox, für ihren Orizon-Reader bereitzustellen.

Beim Durchsehen der Änderungen fiel mir auf, dass nicht nur ein Broadcom WLan-Chip verbaut wurde, für den es auch einen freien Treiber zu geben scheint, sondern Bookeen auch eine ganze Menge Entwicklungsarbeit in den Kernel gesteckt hat. Unter anderem haben sie den Treiber für den Display-Controller komplett neu geschrieben. Das Ergebnis dürfte sich zwar ähnlich unintelligent verhalten wie das Original, scheint aber Probleme mit dem Original-Treiber gelöst zu haben. Für Interessierte sind die Änderungen als Diff im bk060-Zweig des »vendor-kernels«-Repositories auf Gitorious zu finden.

Solche Doppelentwicklungen resultieren daraus, dass alle Hersteller in ihrem stillen Kämmerlein vor sich hin werkeln, ohne sich zwischenzeitlich mal mit eventuellen »Leidensgenossen« auszutauschen. Dies mag zwar betriebswirtschaftlich geboten sein, von wegen Konkurrenz und so, aus einer Entwicklerperspektive ist es aber mehr als ärgerlich. Denn all die investierten Resourcen sind ja im Prinzip für die Katz, da das betreffende Gerät nach einem Jahr auch schon wieder verschwunden ist und die Code-Qualität meist so schlecht ist, dass sich wenig bis gar nichts davon wiederverwenden lässt. Hinzu kommt auch noch, dass die Readerfamilie ja noch viel größer ist. Das heißt man könnte vermutlich noch mindestens drei andere Hersteller finden, die ähnlichen Aufwand betrieben haben.

Es geht aber auch anders, denn im Bereich des Mainline-Kernels schaffen es ja auch die unterschiedlichsten Hersteller zusammenzuarbeiten, obwohl sie konkurrierende Produkte anbieten, zum Beispiel NVidia (Tegra), Samsung (Exynos) und Texas Instruments (OMAP). Dies funktioniert aber vermutlich auch nur, weil dort immer ein relativ herstellerunabhängiger Maintainer mit der Peitsche dahinter steht und Wildwuchs verhindert.

Letzten Dienstag war ich auf Einladung von Thalia in Berlin — um genau zu sein, bei der von Thalia übernommenen Textunes GmbH. Eingeladen hatte mich einer der Oyo-Projektmanager. Bei Kaffee und Sachertorte in einem nahe gelegenen Cafe haben wir dann über den Oyo und digitales Lesen im Allgemeinen philosophiert.

Ansonsten hatte ich den Eindruck, dass wirklich der Wunsch besteht, möglichst viel richtig zu machen und die momentane Situation zu verbessern. Inwieweit sich das im Lebenszyklus des Oyo(-2) noch richten lässt kann ich aber nicht wirklich beurteilen. Ich habe natürlich auch nochmal deutlich auf die GPL-Situation hingewiesen.

Am Freitag kam dann auch noch ein Paket mit einem Oyo-2 und einem Oyo-3G darin. Mein Schreibtisch sieht demzufolge momentan aus, wie die Schreibtische der verschiedenen Star-Trek Capitains — voller »Pads«.

Reader-Familienfoto - es fehlt noch der Oyo mit dem kaputten Display und der seriellen Schnittstelle für die »low-level«-Sachen.

Weitere Eindrücke des Tages

Gefahren bin ich ja mit einem EuroCity. Und zum wiederholten Male sage ich mir »nie wieder«. Die Wagen strahlen den Charme der 80er Jahre aus, sind gefühlt seit dem auch nicht mehr gereinigt worden und geben teilweise beängstigende Geräusche von sich. Das nächste Mal nehme ich wieder den ICE über Leipzig, das ist deutlich komfortabler .

Berlin wäre mir eindeutig zu groß. Überall laufen massenweise Menschen herum.

Das Kuchenangebot im Cafe Sarotti-Höfe ist sehr lecker.