Samsung SPF Photo Frame

Hi,

Habe hier auch einen SPF-87-H und komme einfach nicht richtig in laufen.
Auf meinen beiden (yavdr 0.3a und Kubuntu 10.10) Systemen taucht der Rahmen unter lsusb nur auf, wenn ich ihn in den Massenspeichermodus schalte. Auch unter Windows ist der Frame Manager dauernd inaktiv. Ich denke also, dass ich etwas grundlegend falsch mache, nur was?
Habt Ihr mal nen Tritt in die richtige Richtung?

Mein Endziel ist GraphTFT unter yavdr 0.3a zu betreiben.

Gruß

Joachim

So. Ich hatte ein Brett vorm Kopf. Das SPFtool läuft jetzt auf meinem yaVDR mit der udevregel und ich kann per playusb Bilder auf das Display schieben. Jetzt bleibt nur noch das Problem unter yaVDR GraphTFT zu patchen ohne mir die ganze Installation zu zerhauen.

Allerdings habe ich nosh eine andere Frage an die Programmierer: Glaubt Ihr es wird mit dem Display jemals eine automatische Lösung möglich sein, bei der ich das Display nicht anschalten und in den Mini-Monitor-Modus versetzen muss?

Joachim

Hallo Andi,

vielen Dank für das super Tool. Habe hier ein verstaubtes SPF-83H wieder
vorgekramt und es funktioniert , zumindest JPEGs konnte ich schon
erfolgreich anzeigen lassen

hier mein Eintrag in der playusb.h

{
.name = "Samsung SPF-83H",
.vendorid = 0x04e8,
.productid_massstorage = 0x200c,
.productid_photo = 0x200d,
.xres = 800,
.yres = 600,
},

Wie das mit dem graphTFT plugin läuft hab ich noch nicht begriffen.
Muss das plugin zwingend gepatched werden ? Hab hier die yaVDR
Pakete am laufen und will ungern daran rumfummeln.

bis denn

Andreas

Hallo Andi,

ich habe nun einige Zeit versucht den framebuffer anzusprechen, leider ohne Erfolg.

So bin ich vorgegangen:

- das Kernel-Modul habe ich gebaut und mittels dem beigefügten load script geladen

make -C /lib/modules/2.6.38-8-generic/build M=/home/andreas/build/spfb modules
make[1]: Betrete Verzeichnis '/usr/src/linux-headers-2.6.38-8-generic'
CC [M] /home/andreas/build/spfb/spfb.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
CC /home/andreas/build/spfb/spfb.mod.o
LD [M] /home/andreas/build/spfb/spfb.ko
make[1]: Verlasse Verzeichnis '/usr/src/linux-headers-2.6.38-8-generic'

- zuerst hab ich versucht per sudo cat /dev/urandom > /dev/fb1 etwas in den framebuffer zu
schreiben um es dann per playusb ausgeben zu lassen. Das funktioniert leider nicht, da
cat auf das fb1 device nicht funktioniert und hängenbleibt.

- hab dann das fbv tool besorgt und versucht mit diesem tool was in das fb1 device
zu schreiben aber mit dem selben Ergebnis wie mit dem cat Befehl.

Mir scheint das framebuffer device bzw. das Modul funktioniert nicht korrekt auf meiner
Maschine.

Kannst du mir einen Tip geben wie ich hier weiterkomme ?

Danke

Andreas

Zitat von aoster

sudo cat /dev/urandom > /dev/fb1

So kann das ja auch nicht funktionieren - wenn du es so aufrufst gilt das sudo nur für cat, nicht für die Umleitung der Ausgabe.
Sieh dir mal den entsprechenden Abschnitt zu sudo mit Umleitungen an.
Denkbar wäre z.B. sudo bash -c "cat /dev/urandom > /dev/fb1"

Hallo seahawk1986,

danke für deine Antwort, allerdings ändert das auch nichts.
Egal wie ich es mache, versuche ich etwas in das fb device
zu schreiben so hängt sich der Vorgang auf ( keine Rückkehr
zu shell , kein CTRL-C nicht mal kill hilft)

bis denn

Andreas

Falls noch von Interesse: das Ganze geht auch mit reinem Python.

siehe http://pyframe.blogspot.com/

aber doch immer noch nicht ohne den Bildschirm nach dem Einschalten von Hand in den richtigen Mode zu bringen, oder?

Das automatische Einschalten ist keine Funktion der verwendeten Programmiersprache, sondern durch die Hardware, genauer die Firmware, des SPF-87H bedingt. Die Firmware meines Rahmens nach Update ist 1007.0

Zum Einschalten des Rahmens reicht es nicht, ihn an eine Stromversorgung (Netzteil oder USB Kabel) zu hängen. Man muss erst noch von Hand einschalten. Danach ist der Rahmen aber noch nicht am USB Bus angemeldet, und das Betriebssystem - weder Linux noch Windows - kann ihn erkennen. Wenn der Rahmen am USB Kabel hängt, erscheint nach einem Moment eine Dialogbox auf dem Rahmen, mit der zwischen Massenspeicher, Mini Monitor und Bilderrahmen gewählt werden kann. Wählt man Bilderrahmen, so bleibt er weiterhin unsichtbar für den Computer, da der Rahmen sich nicht am USB Bus anmeldet. Dadurch hat der Computer keinen Zugriff auf den Rahmen.

Wählt man eine der beiden anderen Optionen, so findet die USB Anmeldung statt, und er ist mit der jeweiligen idVendor, idProduct Kennung sichtbar. Unter Windows, wenn der Samsung Frame Manager installiert ist, kann man damit zwischen Massenspeicher und Mini Monitor hin und her schalten. Das würde unter Linux auch gelingen, wenn der Control Code dafür bekannt wäre.

Wenn mir den jemand nennen könnte, wäre das schnell zu programmieren.

Auf Anregung von killerhippy hier der Python Teil eines Transfergeschwindigkeits Vergleichs zwischen Python Script und C Programm.

Ich habe zwei sehr unterschiedliche Bilder im Script geladen, aufbereitet, und in einer Schleife die Daten abwechselnd zum Rahmen geschickt. Ein Paar Bilder war einfach und klein (<<16384 Bytes), ein weiteres komplex und daher gross (ca 100kB nach Schrumpfen auf 800x480). Alle Bilder angehängt. Auf dem Rahmen war nur noch ein Flackern zu sehen. Die CPU Last lag bei nur 1-2%. Hier die Daten:

Bilder_____________ BildGröße(B) _______Bilder/sek ___Gesamt Transfer MB/sec
red.jpg/blue.jpg __ 6631/2536 _________ 28 ___________ 0.46
i244,jpg/i247.jpg _ 98792/123768_____ 16 ___________ 1.93

Bei den kleinen Bildern wird sehr viel Ballast mit transferiert, da mindestens ein Chunk von 16384 Bytes übertragen werden muss. Allgemein sollten 20+ Bilder/sec möglich sein. Der USB Bus kann gut das 10fache übertragen, die CPU ebenso - der Rahmen scheint das Limit zu setzen.

Spasseshalber habe ich einen Video Clip per ffmpeg in Einzelbilder zerlegt, und versucht, diese Einzelbilder als schnelle Sequenz am Rahmen anzuzeigen. Mit keinem (!) der Bilder gelang dies, obwohl jedes in jedem Bildbetrachter korrekt angezeigt wurde. Auch diverse Permutationen der ffmpeg Parameter brachten keinen Erfolg. Erst Einlesen und Neuschreiben mit dem Python IMAGE Modul mit diesem Code resultierte in anzeigbaren Bildern:

import Image
filename = "bild.jpg" 
image = Image.open(filename)
image.save( "neu" + filename, "JPEG", quality=95)

Danach ist aus dem "Bilderrahmen" ein "Videorahmen" mit flackerfreien knapp 26 Bildern/sec (1.7 MB/sec) geworden. Einlesen der Bilder von einer schnellen SSD brachte keine schnellere Übertragung, was wiederum für den Rahmen als Flaschenhals spricht.

Jetzt bin ich mal auf die C Programm Ergebnisse gespannt . Python Testprogram (pyframe_tspeed.txt) ebenfalls angehängt.

Hallo,

habe versucht das spf87h-tool Programm zu kompilieren. Habe dazu den Code im Verzeichnis /usr/src/spf87h-tool-v0.01 abgelegt.

Bekomme aber immer die Meldung fatal error: usb.h: Datei oder Verzeichnis nicht gefunden. Habe in meiner unwissenden Verzweiflung schon eineauf der Platte gefundene
Header-Datei ins gleiche Verzeichnis kopiert hat aber auch nichts gebracht.

Was mach ich da falsch.

Gruß Sindbad6

Mal wild geraten "apt-get install libusb-dev"?

cu

Zitat von Keine_Ahnung

Mal wild geraten "apt-get install libusb-dev"?

cu

Tja, jetzt vermisst er libusb-1.0/libusb.h

Ich bin echt Ahnungslos

Hi,

apt-get install libusb-1.0-0-dev

Wenn etwas fehlt, libjpeg, libpng z.B., die developer Pakete nachinstallieren. Die Namen der fehlenden Pakete werden ja direkt angezeigt..

Edit:
Hat sich erledigt! Wer lesen kann....

Der Fehler:

Error while writing to USB device. Please check your system rights.

waren bei mir falsche Rechte der Dateien. Sie waren root.src und muessen root.root sein, bzw mit chmod angepasst werden.

Danke und Gruss...

Nach den Hinweisen von blogga habe ich jetzt das spf-tool und auch playusb kompilieren können.
Für das spf-tool habe ich eine eine udev-Regel erstellt.

Jetzt fehlt mir noch ein Hinweis wie ich playusb einsetze um etwas auf dem Monitor anzuzeigen.
Irgendwie stehe ich im Wald. Anschließend steht dann wohl GraphTFT an.

Ziel ist letztendlich XBMC über den Monitor bedienen (Bilder, Musik, Wetter, etc.) zu können.

Versuche mich da schrittweise ran zu tasten.

Gruß Sindbad6

Hi,

ich hab folgende /etc/udev/rules.d/11photoframe.rules

SUBSYSTEMS=="usb", ACTION=="add", ATTR{idVendor}=="04e8", ATTR{idProduct}=="2035", RUN+="/usr/local/bin/usbmonitor.out"
#SUBSYSTEMS=="usb", ACTION=="add", ATTR{idVendor}=="04e8", ATTR{idProduct}=="2036", RUN+="/usr/local/bin/playusb -f /dev/fb1 -i 1000 &"

Allerdings hab ich jetzt probleme playusb am yavdr0.4 zu compilen. Sind zwar nur warnungen, aber der Task haengt sich dann auf.

root@vdr-1:~# cd /usr/src/playusb
root@vdr-1:/usr/src/playusb# make clean
rm -rf *o playusb
root@vdr-1:/usr/src/playusb# make
gcc -Wall -O2 -funsigned-char -lrt -lusb -ljpeg -c playusb.c
gcc -Wall -O2 -funsigned-char -lrt -lusb -ljpeg -c fbgrab.c
fbgrab.c: In function ‘Write_JPG’:
fbgrab.c:269:16: warning: pointer targets in assignment differ in signedness
fbgrab.c: At top level:
playusb.h:61:12: warning: ‘num_frames’ defined but not used
fbgrab.c: In function ‘read_fb’:
fbgrab.c:154:1: warning: control reaches end of non-void function
gcc -Wall -O2 -funsigned-char -lrt -lusb -ljpeg playusb.o fbgrab.o -o playusb
playusb.o: In function `main':
playusb.c:(.text+0x7c6): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
root@vdr-1:/usr/src/playusb#

Ein Pointer wird in einer Schleife auf die aktuelle Bild-Zeile gesetzt. Ich denke dabei geht irgendwas schief..
Der Teil der Funktion Write_JPG in fbgrab.c

.
.
.      
JSAMPROW row_pointer[0];                                /* pointer to a single row */
.
.
.
while (cinfo.next_scanline < cinfo.image_height)
        {
        row_pointer[0]= pict->buffer + (cinfo.next_scanline * row_stride);
        ret = jpeg_write_scanlines(&cinfo, row_pointer, 1);
        }

Das Device /dev/fb1 existiert. Was ist hier falsch? Vielen Dank schon mal...

root@vdr-1:/usr/src/playusb# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)

Erstmal Danke für euren Support mit den Programmen SPFB und PLAYUSB. Ich verwende diese schon seit längerem mit meinem yaVDR und bis jetzt hat es auch immer wunderschön funktioniert. Nach dem Upgrade auf eine SSD hab ich das System um einiges beschleunigen können, jedoch kommt es öfters vor, dass das Laden der SPFB Modulen im Skript zu lange braucht und dadurch der VDR nicht mehr starten kann. Aus diesem Grund würde ich gerne das Laden von den einzelnen SPFB Modulen schon beim Kenerlstart erledigen.

Ich habe alle nötigen Module in /etc/initramfs-tools/modules eingetragen und das spfb.ko nach /lib/modules/2.6.38-16-generic/kernel/drivers/video/ kopiert (Verzeichnis des aktuellen verwendeten Kenerls). Zusätzlich habe ich noch update-initramfs -u
-k all ausgeführt. Nachdem System Neustart habe ich mittels lsmod alle benötigten Module bis auf das spfb Modul gefunden. modprobe -l findet das Modul spfb auch nicht. Was muss ich noch beachten, wenn ich ein eigenes Modul über diese Methode starten möchte? Reicht ein einfaches kopieren des Moduls in den Ordner nicht aus?

Hallo Community

Ich versuche das spftool zu kompilieren, aber er endet mit:
collect2: Fehler: ld gab 1 als Ende-Status zurück
make: *** [spf87h-tool] Fehler 1
und macht mir nur die spf87_tool.o

Habt irgendwer eine Idee, woran das liegt?

Ich möchte diesen Monitor unbedingt verwenden können, wäre eine grosse Hilfe

Zitat von n00b

Ich versuche das spftool zu kompilieren, aber er endet mit:
collect2: Fehler: ld gab 1 als Ende-Status zurück

Aber das ist doch viel zu spät, die Ursache für diesen Fehler muss vorher gestanden haben.

Gerald

Sorry!

Hier der ganze Text vom Terminal:
gcc -Wall -O2 -lusb-1.0 -c spf87h-tool.c
spf87h-tool.c: In Funktion »main«:
spf87h-tool.c:124:6: Warnung: Variable »actual_length« gesetzt, aber nicht verwendet [-Wunused-but-set-variable]
gcc -Wall -O2 -lusb-1.0 spf87h-tool.o -o spf87h-tool
spf87h-tool.o: In function `find_spf':
spf87h-tool.c:(.text+0x35): undefined reference to `libusb_get_device_descriptor'
spf87h-tool.c:(.text+0xfb): undefined reference to `libusb_free_device_list'
spf87h-tool.c:(.text+0x107): undefined reference to `libusb_exit'
spf87h-tool.o: In function `main':
spf87h-tool.c:(.text.startup+0x1c): undefined reference to `libusb_init'
spf87h-tool.c:(.text.startup+0x3a): undefined reference to `libusb_set_debug'
spf87h-tool.c:(.text.startup+0x4e): undefined reference to `libusb_get_device_list'
spf87h-tool.c:(.text.startup+0x7c): undefined reference to `libusb_open'
spf87h-tool.c:(.text.startup+0x9a): undefined reference to `libusb_claim_interface'
spf87h-tool.c:(.text.startup+0x119): undefined reference to `libusb_control_transfer'
spf87h-tool.c:(.text.startup+0x16a): undefined reference to `libusb_control_transfer'
spf87h-tool.c:(.text.startup+0x1b7): undefined reference to `libusb_control_transfer'
spf87h-tool.c:(.text.startup+0x1f8): undefined reference to `libusb_release_interface'
spf87h-tool.c:(.text.startup+0x204): undefined reference to `libusb_close'
spf87h-tool.c:(.text.startup+0x218): undefined reference to `libusb_free_device_list'
spf87h-tool.c:(.text.startup+0x224): undefined reference to `libusb_exit'
spf87h-tool.c:(.text.startup+0x2e1): undefined reference to `libusb_detach_kernel_driver'
spf87h-tool.c:(.text.startup+0x322): undefined reference to `libusb_claim_interface'
spf87h-tool.c:(.text.startup+0x3b9): undefined reference to `libusb_free_device_list'
spf87h-tool.c:(.text.startup+0x3c5): undefined reference to `libusb_exit'
spf87h-tool.c:(.text.startup+0x477): undefined reference to `libusb_free_device_list'
spf87h-tool.c:(.text.startup+0x483): undefined reference to `libusb_exit'
collect2: Fehler: ld gab 1 als Ende-Status zurück
make: *** [spf87h-tool] Fehler 1