suuuuper, auch haben will. - ich glaub das muss gar nicht sein das das Menu mitgeht, aber die Liveansicht ich der Hammer! 
Mal ne andere Frage: kriegt man das hin das das TFT automatisch startet oder muss man das nach dem Boot immer von Hand nachstarten?
Christian
Klasse Arbeit! Checkt doch bitte den Treiber ein 
Was ist zu tun?
Liebe Gruesse
CKone: dafür gibts ja die Skins - kannst auf das Display machen was Du willst.
Das mit dem Anmelden ist noch so ein Problem. Entweder nach dem Anstecken an USB für ca. 2 Sekunden MENÜ drücken - oder wenn der Akku ausgebaut wurde (was ich auf jeden Fall empfehlen würde, da der ja wohl bei den meisten Pearl-Displays sowieso im Eimer ist) UND im Menü "Diashow" eingestellt ist, geht das Ding nach ein paar Minuten automatisch in den hackfin Modus. Leider hat hackfin bis jetzt noch nichts veröffentlicht damit das direkt nach dem Einschalten automatisch geht. Wie man den Akku ausbaut ist hier beschrieben.
paulpanther: noch etwas Geduld - kriegs hoffentlich bis Anfang der Woche soweit, dass ich was veröffentlichen kann.
Gruß
superelchi
Noch mal und nur zum Verständlis für einen alten Mann:
Zitat
Das mit dem Anmelden ist noch so ein Problem. Entweder nach dem Anstecken an USB für ca. 2 Sekunden MENÜ drücken
wie jetzt, ich schalte mit der FB den VDR an und renn los um das Display an den USB zu stecken?
Zitat...im Menü "Diashow" eingestellt ist, geht das Ding nach ein paar Minuten automatisch in den hackfin Modus.
ok, schon besser, aber hier geht das Ding doch zumindest bei Rechnerboot von allein an?
Deine Mühen in allen Ehren superelchi, aber nicht das diese Lösung am Ende doch nicht so richtig praktikabel ist. Mal ganz dumm frag: Können andere solche Produkte (USB) für kleines Geld (also 20€) das denn aus dem FF?
Danke, Christian
wie jetzt, ich schalte mit der FB den VDR an und renn los um das Display an den USB zu stecken?
genau so. Und dann bitte noch für 2 Sekunden die Menütaste drücken. Hält fit. 
ok, schon besser, aber hier geht das Ding doch zumindest bei Rechnerboot von allein an?
Ja, das schon. Aber erst nach ein paar Minuten in den hackfin Modus.
Nein im Ernst: wenn du USB-Ports hast die Standby-Power liefern ist das Problem gar nicht so groß. Dann bleibt das Display ja auch bei ausgeschaltetem VDR an der Power und somit im hackfin Modus. Graphlcd löscht das Display beim Beenden, somit sollte das nicht stören (auch vom Stromverbrauch, das Ding hat einen "deep sleep" Modus, den man angeblich auch über den Hack erreicht). Ansonsten mit showpic einfach was Hübsches beim Runterfahren draufschieben...
Problematischer wirds bei USB-Ports, die keine Stanby-Power liefern und wenn der Rechner vom Netz getrennt war - da hilft dann nur Warten oder Rennen...
Nein im Ernst: wenn du USB-Ports hast die Standby-Power liefern ist das Problem gar nicht so groß. Dann bleibt das Display ja auch bei ausgeschaltetem VDR an der Power und somit im hackfin Modus. Graphlcd löscht das Display beim Beenden, somit sollte das nicht stören (auch vom Stromverbrauch, das Ding hat einen "deep sleep" Modus, den man angeblich auch über den Hack erreicht). Ansonsten mit showpic einfach was Hübsches beim Runterfahren draufschieben...
Das geht auch so wenn der Akku raus ist? Das wäre dann nämlich mein Anwendungsfall.
Der Stromverbrauh sollte ja nicht wirklich relevant sein, dann Ding wird ja nicht viel verbrauchen.
cu
Jo. Geht prima mit ohne Akku.
Gruß
superelchi
ok, überzeugt. - müsste ich nur den Jumper für 5V SB umsetzen.
was kann ich dann schon vorab ohne Treiber machen:
- plugin vorbereiten
- http://tech.section5.ch/files/dpfhack-0.12devel.tgz hacken
zu touchcol base fehlt noch dein Treiber, oder?
Christian
Hacken ist immer gut.
Dann Display ab- und wieder anstöpseln, MENÜ 2 Sekunden drücken und freuen.
Danach würde ich versuchen, ob das Display es mit lcd4linux tut - wenn Du einen Rechner hast, bei dem es nix macht, dass lcd4linux durch die vom Hack erstellte ersetzt wird.
Mein Treiber für graphlcd kommt hoffentlich noch am WE, bin noch am Schrauben.
Gruß
superelchi
So, Treiber ist jetzt fast soweit. Jetzt brauch ich Hilfe von den Profis:
Mein Treiber verwendet Routinen aus der dpflib aus dem Hack. Ich seh da drei Möglichkeiten um die einzuarbeiten:
Zu Nummer 1: Bitte nicht schlagen! Ich hab die nur aufgenommen, weil der Hack wirklich noch ziemlich unfertig ist. Seit Juni scheint sich da auch nix mehr getan zu haben. Beim Copy & Paste könnte man da noch ein paar Ecken abschleifen. Falls die Entwicklung weitergeht, würde ich dann auf Nummer 2 oder 3 umsteigen.
Zu Nummer 2: Das wäre mir im Moment am liebsten. Mann könnte das alles in ein eigenes Unterverzeichnis von glcddriver packen und ab gehts.
Zu Nummer 3: Ist einiges an Aufwand. Der Hack muss gepatched werden (Makefile um Shared-Lib Erstellung ergänzen, Headerfiles sind nicht C++ kompatibel, etc). Hab ich bei mir schon gemacht. Geht auch. Bedeutet aber, dass graphlcd von einer Shared-Lib abhängt, die aus einer gepatchen Alpha-Version eines Hacks erstellt wurde. Gefällt mir garnicht.
Ich werd auf jeden Fall mal probieren, ob die Ersteller des Hacks für Änderungen ein Ohr haben. Dann kommt vielleicht doch irgendwann Nummer 3 in Frage. Weiß aber nicht wie lange das dauert. Und hier werden einige ja schon ganz ungeduldig...
Achso, nochwas: wie soll ich das mit dem neuen Treiber machen? Ein Patch zum Testen wastl? Oder hier public?
Gruß
superelchi
Nur mal ne Frage zum Verständnis (ich blicke da durch die div. Hack Quellen noch nicht so durch): Ich meinte rausgelesen zu haben das man zum Zugriff auf den Rahmen nur die "offizielle" Lib verwenden sollte weil sich an der Hackfirmware jederzeit was ändern könnte. Das passt aber irgendwie gar nicht zu dem was du so schreibst. Gibts da verschiedene Projekte?
Ich zitiere mal den Part aus dem Readme
--
Note that the protocol may change in future, once the internal firmware
is fully replaced by something more structured. Thus, you should implement
extras on the dpflib level only, never access USB directly.
--
die dpflib ist doch ne vorhandene Lib, oder nicht?
Edit: Ah, das ist keine shared Lib!? Warum nicht dann diese einfach mit ins Unterverzeichnis von Graphlcd packen (Lösung 2), so ist es doch vom Dev der Lib auch vorgesehen, oder?
cu
Ja, mag gehen, wenn sich die dpflib.a beim Linken zupacken lässt. Hab ich probiert, ging nicht auf Anhieb. Wohl das Name Mangling - ist ne reine C-Lib.
Aber das Problem bleibt: um die libpdf.a zu bekommen musst Du erst den Hack als Source installieren, Übersetzen und dann ins glcddriver Verzeichnis kopieren - also Abhängigkeit von eine Alpha-Hack, den jeder mitinstallieren muß.
Gruß
superelchi
Ja, mag gehen, wenn sich die dpflib.a beim Linken zupacken lässt. Hab ich probiert, ging nicht auf Anhieb. Wohl das Name Mangling - ist ne reine C-Lib.
Aber das Problem bleibt: um die libpdf.a zu bekommen musst Du erst den Hack als Source installieren, Übersetzen und dann ins glcddriver Verzeichnis kopieren - also Abhängigkeit von eine Alpha-Hack, den jeder mitinstallieren muß.
Tja, stimmt. Ne shared Lib wäre vermutlich das einfachste und sauberste (sofern die Schnittstelle einigermassen konstant bleibt). Man könnte dann wohl auch im graphlcd-base Makefile prüfen ob sie auf den System vorhanden ist und den Treiber einfach auslassen wenn nicht. IMHO wäre es dann perfekt wenn die "Hacker" nen Packet mit der reinen Lib Releasen würden.
Aber solange das nicht passiert wäre dann Variante 1 Vermutlich doch das beste.
cu
Ja, mag gehen, wenn sich die dpflib.a beim Linken zupacken lässt. Hab ich probiert, ging nicht auf Anhieb. Wohl das Name Mangling - ist ne reine C-Lib.
Macht doch nix. Das dazugehörige Include-File in extern "C" klammern. Dann lässt der C++-Compiler das Name Mangeling.
extern "c" {
#include <...>
}Gerald
wastl: Ja, seh ich auch so.
Soweit mit bekannt ist, gibts für diese Display nur den einen Hack, also hier keine Verwechslungsgefahr.
Was soll ich also jetzt machen? Alles mit Copy&Paste zusammen in eine Treiberdatei, ein HAVE_wasauchimmer_EXPERIMENTAL in die Makefile und in der README auf die nötige Firmware hinweisen?
Wenns dann irgendwann mal mal eine vernünftige .so gibt, sehen wir weiter.
Gruß
superelchi
Hacken ist immer gut.
Dann Display ab- und wieder anstöpseln, MENÜ 2 Sekunden drücken und freuen.
Danach würde ich versuchen, ob das Display es mit lcd4linux tut - wenn Du einen Rechner hast, bei dem es nix macht, dass lcd4linux durch die vom Hack erstellte ersetzt wird.
Mein Treiber für graphlcd kommt hoffentlich noch am WE, bin noch am Schrauben.
Gruß
superelchi
ok, machen wir uns da mal an die Anleitung:
wget http://tech.section5.ch/files/dpfhack-0.1alpha.tgz
tar -xvzf dpfhack-0.1alpha.tgz
cd dpf/src
makeich stell als erstes fest wenn ich den devel anstelle des alpha.tgz nehme findet sich unter dpf/src kein Makefile, also ist auch nix zu kompilieren. - Muss ich das alpha da zusätzlich hochladen oder kannst du der Einfachheit halber ein passendes dpfhack wo hinstellen. Ich nehms auch per pm 
Christian
Also beim mit gings so:
Erst die nötigen Dependencies (hier für Debian/Ubuntu):
apt-get install libtool automake autoconf zlib1g-dev libssl-dev python-dev libc6 libusb-dev libibus-dev subversion libgd2-noxpm-dev sdcc
Dann
wget http://tech.section5.ch/files/dpfhack-0.12devel.tgz
tar xfvz dpfhack-0.12devel.tgzcd dpf
make (Auf keinen Fall make all - sonst macht er den ganzen lcd4linux Kram!)
cd fw
python hackit.py /dev/sgXZum Finden der richtige /dev/sgX siehe Anleitung unter http://geekparadise.de/2011/04…atusdisplay-fur-dockstar/.
Ich musste bei mit noch in der profiles.py das Datum im "pearl"-Eintrag der KNOWN_DPFS anpassen - aber dass siehts Du dann schon, wenn hackit.py eine entsprechende Meldung bringt.
Gruß
superelchi
Noch ein Nachtrag für den Hack.
Das /dev/sgX device findet Ihr mit dmesg raus
Steckt das Display an den USB Port. Drückt die Menü Taste und wählt mit der Menütaste im Menü "mit dem PC verbinden" aus.
Danach schaut mit dmesg welches device es bei euch ist.
bei mir ist dies folgender Eintrag gewesen.
[128505.106553] scsi 11:0:0:0: CD-ROM buildwin Photo Frame 1.01 PQ: 0 ANSI: 2
[128505.116535] sr1: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
[128505.119130] sr 11:0:0:0: Attached scsi CD-ROM sr1
[128505.122577] sr 11:0:0:0: Attached scsi generic sg3 type 5
Bei mir ist es also /dev/sg3.
Ich musste die profiles.py auch anpassen da mein Datum vom dpf anders war.
Wenn hackit.py einen Fehler sagt, das er das Display nicht finden konnte gibt hackit.py auch den String vom Display aus. Schaut euch dann die profiles.py an und Ihr findet schon den Eintrag den Ihr anpassen müsst. Danach sollte es gehen.
Ich habe nach dem Hack noch ein
update.py hexfiles/fw_pearl_landscape.ihx
gemacht für den Landscape modus, weiß aber nicht ob das noch zwingend notwendig ist.
Grüße Martin
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!