InfoScreen/Projekttagebuch: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
Keine Bearbeitungszusammenfassung
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
<-- [[InfoScreen]]
<-- [[InfoScreen]]
== Donnerstag, 1. November 2012 ==
* Der RFID-Leser wurde gestern abend noch zerlegt und unter die Glasscheibe montiert. Leider hat der Platz nicht genügt, so daß der Leser nun schief hängt und weniger empfindlich ist. Als nächstes wird der Frontrahmen neu gemacht und das LCD höher gehängt, so daß der Platz für den Leser genügt.
== Mittwoch, 31. Oktober 2012 ==
* InfoScreen goes RFID: Der InfoScreen wurde um einen SCL011 RFID-Leser ("Basisleser" aus dem IT-Sicherheitskit) ergänzt. Ein kurzer Python-Code (teilweise von Blacklotus) erkennt Karten und liest ihre ID aus. Diese ist zwar prinzipiell nicht (mehr) unbedingt eindeutig, sollte aber für die Zwecke hier genügen. Der Code simuliert bei erkannter Karte über die uinput-Schnittstelle von Linux eine Tastatureingabe ("##kartennummer.."), welche widerrum von JavaScript-Code in der Anzeige ausgewertet wird. Derzeit wird nur die erkannte Kartennummer angezeigt, aber zukünftig sollen individuelle Inhalte wie z.B. ein persönlicher Fahrplan angezeigt werden.


== Dienstag, 30. Oktober 2012 ==
== Dienstag, 30. Oktober 2012 ==

Aktuelle Version vom 1. November 2012, 19:31 Uhr

<-- InfoScreen

Donnerstag, 1. November 2012[Bearbeiten | Quelltext bearbeiten]

  • Der RFID-Leser wurde gestern abend noch zerlegt und unter die Glasscheibe montiert. Leider hat der Platz nicht genügt, so daß der Leser nun schief hängt und weniger empfindlich ist. Als nächstes wird der Frontrahmen neu gemacht und das LCD höher gehängt, so daß der Platz für den Leser genügt.

Mittwoch, 31. Oktober 2012[Bearbeiten | Quelltext bearbeiten]

  • InfoScreen goes RFID: Der InfoScreen wurde um einen SCL011 RFID-Leser ("Basisleser" aus dem IT-Sicherheitskit) ergänzt. Ein kurzer Python-Code (teilweise von Blacklotus) erkennt Karten und liest ihre ID aus. Diese ist zwar prinzipiell nicht (mehr) unbedingt eindeutig, sollte aber für die Zwecke hier genügen. Der Code simuliert bei erkannter Karte über die uinput-Schnittstelle von Linux eine Tastatureingabe ("##kartennummer.."), welche widerrum von JavaScript-Code in der Anzeige ausgewertet wird. Derzeit wird nur die erkannte Kartennummer angezeigt, aber zukünftig sollen individuelle Inhalte wie z.B. ein persönlicher Fahrplan angezeigt werden.

Dienstag, 30. Oktober 2012[Bearbeiten | Quelltext bearbeiten]

  • Die Anzeige wurde komplett neu geschrieben und basiert nun auf AngularJS (http://www.angularjs.org), welches den Code deutlich vereinfacht und verschönert. Allerdings ist z.B. die VRR-Anzeige derzeit noch weitgehend auf altem Code basierend, der nur in das neue Framework eingepresst wurde. Hier ist noch weitere Arbeit nötig.
  • Im Rahmen des Umbaus wurde auch die Gestaltung verschönert, siehe aktuellen Screenshot.

Freitag, 29. Juni 2012[Bearbeiten | Quelltext bearbeiten]

  • Zwischenzeitlich wurde übrigens die Fahrplananzeige implementiert.
  • Heute Software ausgetauscht, jetzt ist es ein Standard-Debian welches aber ro-Betrieb modifiziert wurde.
    • Wenn Google-Chrome nicht startet: Dämliches Flash-Plugin rauswerfen. Hab ich lange lange gesucht.

Montag, 28. Mai 2012[Bearbeiten | Quelltext bearbeiten]

  • Der Verdacht dass die HW nun abschmiert hat sich zum Glück nicht bestätigt. Es war einfach nur das DPMS vom X :-O
  • Die Grafikperfomance des IS4 ist ganz schön mies. Mit einem Debian-Kernel und SISFB-Modul rumgespielt, hat auch nix gebracht, daher wieder davon Abstand genommen.

Samstag, 26. Mai 2012[Bearbeiten | Quelltext bearbeiten]

  • Nach längerem Gebastel befindet sich jetzt auf dem Infoscreen "Plan D" in Form einer chroot-Umgebung. Basis Debian/Emdebian (aufgesetzt mit multistrap), darin Xorg und Google Chrome im Kiosk-Modus. Vielleicht läuft das mal stabiler. Für die schwächere Hardware ist das aber keine Lösung.

Freitag, 25. Mai 2012[Bearbeiten | Quelltext bearbeiten]

  • Wow. Peter (tixiv) hat sich des Einschaltproblems beim InfoScreen 4 angenommen. Offenbar war lediglich die Kapazität des Elko zu hoch. Es scheint so, als wäre das jetzt gefixt, wobei das System merkwürdige Abstürze zeigt.
  • Plan D für die Software: Ich werde jetzt versuchen einfach ein X + Chrome zum laufen zu bringen.

Mittwoch, 9. Mai 2012[Bearbeiten | Quelltext bearbeiten]

  • Übrigens hat Google Chrome ein ähnliches Konzept. Anscheinend kann man da auch den Renderer herauslösen. Ich tendiere derzeit ansonsten dazu, eine Minimallösung mit X zu machen (xserver-xfbdev oder evtl. Xvfb+Hack).

Montag, 30. April 2012[Bearbeiten | Quelltext bearbeiten]

  • Eine mögliche Browseralternative: ISIS von WebOS, mittlerweile OpenSource (http://isis-project.org).
    • Die WebOS-UI ist browserbasiert. Der Nutzer möchte aber darin auch einen "Browser" haben um Webseiten anzuzeigen. Dies soll aus Sicherheitsgründen eine separater Prozess sein. Daher hat man einen "BrowserServer" der über eine Art IPC angesprochen wird, und offenbar gerenderte Inhalte zur Anzeige zurückliefert. Siehe auch http://tale.wkb.ug/2012/03/20/iris/ für ausführlichere Erklärung.
    • Idee: Nur den BrowserServer laufen lassen, diesen Inhalte rendern lassen und das Resultat (Grafik?) auf den FB packen. Ist zwar etwas krank, aber vorstellbar.
      • Problem: Die Schnittstelle ist offenbar nicht dokumentiert. Es müsste daher der Source analyisiert werden. Auch scheint das IPC etwas WebOS-eigenes zu sein, für das ein spezieller Daemon erforderlich ist, für den es wohl keinen Source gibt.
      • Lichtblick: Die Integration der Browser-Prozesse in den "Hauptbrowser" (UI) funktioniert offenbar über eine Art Plugin ("BrowserAdapter") welches den BrowserServer anspricht. Daher sollte im BrowserAdapter-Source eigentlich alles wesentliche zu finden sein. Der Source ist aber nicht gerade klein.
    • Plan B: Es erscheint, als sei der BrowserServer bereits vom Umfang alles, was ich für den InfoScreen benötige. Es ist denkbar, den ganzen IPC-Code rauszuwerfen und hier direkt Code einzubauen, der das Resultat in den FB wirft. Unter Umständen wäre ein alternatives Minimal-IPC Interface (für simulierte Tastatureingaben) wünschenswert.
  • ISIS in der Linux-Adaption aus dem GIT wurde letzte Nacht von mir erfolgreich übersetzt. Es folgt nun der Test und dann weitere Prüfung. Auf jeden Fall ist der Browser-Prozess ziemlich schlank (11 MB RSS).
    • Das sieht ja nicht so gut aus: 29585 Segmentation fault $DEBUGGER./isis-test -platform xlib $URL

Montag, 23. April 2012[Bearbeiten | Quelltext bearbeiten]

  • Leider gibt es weiter keine gefixte Webkit-Version und das Projekt ist insgesamt etwas eingeschlafen, da auch die Hardware noch unbefriedigend ist.
  • Als Alternative zu Webkit habe ich die Browserkomponente von Boot2Gecko (b2g) mal testweise gebaut. Diese ist nicht direkt schlank, aber vom Speicherverbrauch offenbar doch noch akzeptabel. Dieser Ansatz wird weiter verfolgt.

Montag, 28. November 2011[Bearbeiten | Quelltext bearbeiten]

  • Die Probleme mit der automatischen Abschaltung beim InfoScreen r4 weiter untersucht. Scheint ein Problem der Hardware, Workaround ist in Prüfung.

Sonntag, 27. November 2011[Bearbeiten | Quelltext bearbeiten]

  • Einschaltsteuerung auf Basis eines ATTiny 12 programmiert. Auf dem Entwicklungsboard lief es, beim Thinkpad eingebaut leider nicht.

Samstag, 26. November 2011[Bearbeiten | Quelltext bearbeiten]

  • Der am Mittwoch auf eBay erworbene Thinkpad ist eingetroffen. Bis auf die fehlenden Teile (Netzteil, Akku, CD-Rom) ist das Gerät in einem Topzustand und vor allem läuft es. InfoScreen 5 kann kommen!
    • Bei IKEA wieder mal einen passenden Bilderrahmen erworben, bei Hornbach das Kantholz und die Haken dazu.
  • Bei Conrad mehrere LED-Nachtlichter mit Bewegungsmelder zwecks eventueller Integration in den InfoScreen erworben.
  • Hier eine Idee für einen Touchscreen, notwendige Teile (CCD-Zeile aus Flachbettscanner) sollten im Labor sogar rumliegen: http://spritesmods.com/?art=lineccdts

Mittwoch, 23. November 2011[Bearbeiten | Quelltext bearbeiten]

  • Auf eBay einen weiteren Laptop für EUR 21,05 erworben: Thinkpad A20m mit Celeron/500, 128 MB RAM und ATI Rage Mobility Grafik. Wurde als defekt/ungeprüft angeboten.
  • Blacklotus hat sich angesehen, ob man mit dem RFID-Leser aus dem IT-Sicherheitskit auch die RUB-Studentenausweise lesen kann und diese zur Identifikation nutzen. Offenbar war er dabei erfolgreich, eine Integration in den InfoScreen kann also passieren!
  • InfoScreen 1 von der Wand abgenommen und durch InfoScreen 4 ersetzt. Dieser bootet nun die bisherige Installation mit WebKitDFB. Das Memoryleak-Problem besteht zwar weiter, aber dieses Gerät hat ausreichend RAM, daß der Browser nicht so oft neugestartet werden muß. Für den Moment also eine Lösung. Leider scheint die modifizierte Einschaltlogik fehlerhaft, jedenfalls schaltet das Gerät sich gerne nach 30-60 Sekunden wieder ab.
  • Weitere mögliche Browserimplementation angesehen: Origyn Web Browser. Eigentlich ein kommerziell motiviertes Projekt, das Unternehmen ist leider pleite und die Projekt-Website ist wohl schon seit Monaten kaputt. Immerhin war es möglich über den SVN-Browser die aktuelle Revision und einige ältere getaggte Releases herunterzuladen. Kompilation mit Hürden, da z.B. Executable-Permissions so fehlen, auch hats am Ende nicht kompiliert. Wird vielleicht noch fortgeführt.

Sonntag, 20. November 2011[Bearbeiten | Quelltext bearbeiten]

  • Versuche Auto-Power-On beim InfoScreen 3 (Thinkpad).
    • Die einfache Methode (100 uF parallel zum Taster) tut nicht, ich glaube das hat inverse Logik am Taster. Mal sehen.
    • Der Powertaster zieht ein Signal auf Masse. Kondensator geht aber nicht, weil es nicht funktioniert, wenn dieses Signal direkt beim Anlegen der Netzspannung auf Masse gezogen ist und dann "losgelassen" wird. Ich brauche wohl einen Reset-Chip oder einen kleinen Attiny der das macht.
    • Interessante Lektüre, verschiedene Auto-Power-On-Methoden am Beispiel des Linksys NSLU2: http://www.nslu2-linux.org/wiki/HowTo/ForcePowerAlwaysOn

Samstag, 19. November 2011[Bearbeiten | Quelltext bearbeiten]

Freitag, 18. November 2011[Bearbeiten | Quelltext bearbeiten]

  • Die DirectFB-Änderungen aus WebKitDFB_2011-11-17 extrahiert.
    • Dazu musste die SVN-Revision von WebKit gefunden werden. Es ist r91461.
  • Diese Patches dann auf eine aktuelle WebKit Revision (r100547) portiert.
    • Neben der Anpassung des Ursprungspatches waren weitere Änderungen nötig, da sich Funktionsnamen u.ä. geändert hatten.
    • Ergebnis ist hier zu finden: http://dn.fqdn.org/webkitdfb/
  • Leider ist auch mit dieser WebKit-Version das Memoryleak-Problem vorhanden. Es liegt wohl an der DirectFB-Portierung.

Donnerstag, 17. November 2011[Bearbeiten | Quelltext bearbeiten]

  • Erfolglos versucht, den aktuelleren Code in OpenWrt/Kleistpark zu integrieren.
    • pkgconfig findet die fürs Bauen notwendige zlib nicht. Ich vermute, daß das .pc File nicht kopiert wird, muß das noch prüfen.
    • Es sind neuere Versionen für libpango und libcairo notwendig, diese liessen sich aber nicht bauen.
  • Plan B: Auf einem Debian unstable zum kompilieren bekommen.
    • Hat dann schlußendlich nach vielen Stunden geklappt.
    • Probleme habe ich gerade vergessen.

Mittwoch, 16. November 2011[Bearbeiten | Quelltext bearbeiten]

  • Vom DirectFB-Entwickler eine aktuelle(re) WebKitDFB-Version bekommen. WebKitDFB_2011-11-17.tar.xz
  • Das Noname-Notebook war schon in der Packstation!
    • Umbau angefangen. Ein wahres Schlepptop!

Dienstag, 15. November 2011[Bearbeiten | Quelltext bearbeiten]

  • Auf eBay für 25 EUR ein Thinkpad (A22e, Celeron 800 MHz, 64 MB RAM) erworben und in Mönchengladbach abgeholt.
    • Auch noch umgebaut in Rahmen.
    • Problem: Einschalter ist auf Tastatur, es ist kein PS/2-Anschluss vorhanden.
  • Auf eBay außerdem für 20 EUR ein Noname-Notebook (P3/700 MHz, 512 MB RAM) erworben.

älteres[Bearbeiten | Quelltext bearbeiten]

  • wird nachgetragen