Posts by omo

    Hallo EIB-Freak,


    gibt es bei Dir unter "/proc/bus/usb" keine Einträge? Dann wird vermutlich das usbfs nicht eingebunden sein (siehe z.B. http://www.fibel.org/linux/lfo-0.6.0/node451.html). Die Ausgaben des usbfs werden nur für die Prüfung benötigt, ob das richtige Device den Touchscreen übernommen hat.


    Ich habe mittlerweile meine Touchscreen-Einbindung auf die Treiber des Hertsellers EETI / eGalax umgestellt. Dazu habe ich diese selber in den Kernelbaum mitaufgenommen. Verglichen mit UDEV und Quirksen war das sogar verhältnismässig einfach. Ich habe es unter http://vdr-portal.de/board/thr…?postid=851629#post851629 beschrieben. Derzeit läuft bei mir Kernel 2.6.36. Diese Treiber sind zwar nur X-Treiber, so dass bei Verwendung der Framebufferausgabe keine Touchunterstützung möglich ist, aber dafür läuft es seitdem vollkommen stabil.


    Bei der Verwendung eines Hersteller-Treibers für den X-Server werden die Touchscreen-Berührungen in Mauskoordinaten auf dem X-Server umgewandelt, so dass man für GraphTFT keine zusätzliche Touchunterstützung konfigurieren muss. Ich weiß aber nicht, ob SoundGraph und eGalax kompatibel sind.

    Ich hatte das Problem "ERROR: 'index' during editing process" auch gerade mit einem selbst gebauten VDR 1.6.0-2. Bei vielen anderen Schneidevorgängen ging alles glatt.


    Beim Ansehen der marks.vdr ist mir aufgefallen, dass drei Schnittmarken vorhanden waren, wovon die letzte wohl unmittelbar am Ende der Aufnahme war. Ggf. ist es ein Problem, wenn beim Schneiden ein neuer Bereich unmittelbar am Ende einer Aufnahme beginnt. Nach dem Entfernen der letzten Schnittmarke (ohne die marks.vdr vorher zu löschen), war das Schneiden dann problemlos möglich...

    So, nach vielen Tests habe ich nun eine brauchbare Variante gefunden, um den eGalax Touchscreen mit der USB-Id 0eef:0001, der in meinem Superpowergehäuse verbaut ist, einzubinden.


    Derzeit verwende ich easyVDR 0.6.08 mit einem VDR 1.6.0-02 und dem Kernel 2.6.31.5. Die Bildausgabe der TT-Budget Karte wird derzeit über einen X-Server ausgegeben. Das zweite Display dieses X-Servers ist nun der 7"-TS des HTPC-Gehäuses. Per graphtft-fe wird das graphtft-OSD dorthin umgeleitet.


    Der Vorteil des X-Servers ist, dass man nun kein Input-Device (z. B. /dev/input/event3) mehr benötigt, was in der GraphTFT-Konfiguration eingetragen werden muss. Stattdessen kann nun der aktuelle Beta-Treiber von EETI verwendet werden. Dieser stellt kein richtiges Input-Device dar und kann deshalb nicht mittels evtest getestet werden.


    Der EETI-Treiber bringt einerseits Untersützung für den X-Server mit, so dass das Betätigen des TS wie das Drücken der linken Maustaste interpretiert wird. Andererseits wird auch (als Sourcecode) ein Device-Treiber mitgeliefert, den man als Kernel-Modul kompilieren kann. Nach der Installation des EETI X-Server Treibers kann man das Kernel-Modul aus dem Unterverzeichnis USBSrc für das aktuell vorhandene Kernel kompilieren. Das dabei entstehende Modul tkusb.ko kann man dann in das zugehörige /lib/modules/2.6.x.y/kernel/drivers/input/touchscreen Module-Verzeichnis kopieren ("depmod -a" nicht vergessen). Danach kann dieses Modul mittels modprobe tkusb geladen werden.


    Das X-Server EETI-Konfigurationstool eGalaxTouch kann dann zum Kalibrieren des TS verwendt werden. Diese Konfiguration und die Umleitung des GraphTFT-OSD auf das zweite X-Server Display reichen bereits für eine Bedienung des GraphTFT-OSD per TS aus.


    Warum aber nun so umständlich das proprietäre TKUSB-Kernel-Modul verwenden, statt einfach usbtouchscreen zu verweden? Das mit jedem aktuellen Kernel mitgelieferte usbtouchscreen Kernel-Modul funktioniert zwar, zwischendurch meldet sich der TS als USB-Gerät aber immer wieder ab, um danach sofort wieder angemeldet zu werden. Das macht sich auf dem TS dadurch bemerkbar, dass man für ca. 3 Sekunden nicht touchen kann. Danach geht wieder alles wie vorher. Das tritt leider recht häufig auf. Das TKUSB-Kernel-Modul hat dieses Problem anscheinend nicht. Daher halte ich dies für die bessere Wahl bei Verwendung eines X-Servers.


    Ein anderes Problem ist das USBHID Kernel-Modul. Da der eGalax TS mit der USB-Id 0eef:0001 sich anscheinend fälschlicherweise als USB HID Gerät zu erkennen gibt, möchte das USBHID Kernel-Modul auch gerne dessen Verwaltung übernehmen. Leider klappt das nicht so gut, da dieser TS da wohl mehr verspricht, als er halten kann. Daher muss man dem USBHID Kernel-Modul das Betreiben dieses TS austreiben. Mit normalen Mitteln, wie dem Quirksen, klappt das aber nicht zuverlässig. Durch eine kleine List lässt sich das jedoch elegant lösen. Man muss nur USBHID als Kernel-Modul, TKUSB oder USBTOUCHSCREEN aber in den Kernel einkompilieren. Dadurch sind diese Module immer vor USBHID an der Reihe und schnappen sich den TS rechtzeitig weg.


    Um TKUSB in das Kernel mit einzukompilieren muss man die Quellen des verwendeten Kernel anpassen und alle *.c/*.h Dateien, sowie das include-Verzeichnis des USBSrc-Verzeichnisses nach /usr/src/linux/drivers/input/touchscreen kopieren. Danach müssen die beiden Dateien Kconfig und Makefile angepasst werden. Hier kann man einfach folgendes ergänzen:


    Kconfig:


    Code
    1. config TOUCHSCREEN_TOUCHKIT
    2. tristate "EETI TouchKit touchscreen driver"
    3. help
    4. Say Y here if you have a EETI compatible touchscreen.
    5. To compile this driver as a module, choose M here: the
    6. module will be called tkusb.


    Makefile:


    Code
    1. obj-$(CONFIG_TOUCHSCREEN_TOUCHKIT) += tkusb.o



    Mittels make menuconfig kann nun der hinzugefügte TKUSB-Treiber unter Device Drivers ---> Input device support ---> Touchscreens ---> EETI TouchKit touchscreen driver ausgewählt werden. Alle anderen Einträge sollten deaktiviert werden.


    Danach lässt sich das Kernel ganz normal bauen und installieren. Nach einem Neustart des Rechners sollte dann mittels "cat /proc/bus/usb/devices" nach dem TS gesucht werden. Hier sollte nun TouchKit als Treiber gelistet werden. Wenn das so ist, sollte ein cat /dev/tkpanel0 zu Ausgaben führen, wenn man den TS berührt.


    Abschließend noch meine derzeitige xorg.conf (nVidia nForce i730/9300):



    So, das soll es für heute erst einmal sein.



    Gruß,


    omo

    Es hat nicht zufällig jemand, der ggf. vielleicht bei TT arbeitet, die Länge der Karte im Kopf? Nach den Bildern würde ich schätzen, das es über 20cm sein werden. Damit dürfte es nicht so viele HTPC-Gehäuse geben, welche die Karte aufnehmen können. Mein SuperPower YC-HTPC.B bietet jedenfalls höchstens 19cm Platz...


    Gruß,


    omo

    Hallo champpain,


    der Preis ist das sicherlich gut (gilt auch aktuell immer noch). Bei meinem Gehäuse war die Lieferung ebenfalls im Preis enthalten und ich habe demnach ca. € 20,- mehr ausgegeben (also genau €249,99). Ich wollte aber auch unbedingt ein schwarzes Gehäuse.


    Vom äußeren Aufbau her nehmen sich das Superpower, das OrigenAE X15e in Version 1 und das Amisos X15e wohl nicht so viel. Bei den enthaltenen Komponenten und dem Innenaufbau weiß man wohl vorher nicht so genau, was einen jeweils erwartet. Das scheint mir das größte Problem zu sein. Denn alle hier oder anderswo gesammelten Tipps funktionieren ja nicht mehr so ohne weiteres, wenn die verbauten Komponenten andere sind.


    Aber alles in allem kann ich derzeit gut mit dem Kompromiss leben. Auf jeden Fall wirkt das im Wohnzimmer um einiges atraktiver, als das vorherige graue Miditowergehäuse...


    Meine Gehäusealternativen waren übrigens das Antec Fusion Remote MAX (ca. €180,- nur VF statt TFT-TS) bzw. das Lian Li PC-C34F (ca. € 230,- nur mit FB ohne VF oder TFT-TS).

    Auch ich habe das Gehäuse unter dem Namen Superpower bei einem Amazon Marketplaceanbieter für € 250,- gekauft (Neuware). Die enthaltenen Komponenten sind aber anscheinend nicht immer dieselben. So ist mein Touchscreen-TFT nicht von Innolux, sondern von HOST. Der Touchscreen hat die USB Id 0eef:0001, also die eines Standard eGalax Gerätes. Unter WinXP und Win 7 funktioniert der mit den Treibern von EETI prima. Unter Linux muss ich noch weiter experimentieren. Jedenfalls lässt sich das Display nicht mittels vbetool dpms off abschalten. Das Bild der GraKa verschwindet zwar, aber das Display bleibt "blau" mit aktiver Hintergrundbeleuchtung. Zumindest bleibt das TFT aus, wenn man es über den TFT-Powerknopf ausschaltet, den Rechner mittels halt herunterfährt und ihn später wieder mittels Wake-on-LAN startet. Der Verbrauch des Displays liegt bei ca. 6-8W. Die physikalische Auflösung des Displays konnte ich bisher nicht herausbekommen. Es meldet sich zwar mit 800x600 unter Windows an und ist da und unter der Linux Kommandozeile auch sehr gut lesbar, es müsste aber, wie vergleichbare TFT-Displays dieser Größe, eigentlich 800x480 Punkte aufweisen.


    Auch der Kartenleser ist ein anderer. Es trägt die USB Id 058F:6366 und kommt von der Alcor Micro Corp. Er bietet nun eine weitere USB-Buchse, SD/MMC, MS, xD, CF/MD und T-F. Funktioniert unter Windows, allerdings recht langsam (ca. USB 1 Geschwindigkeit, obwohl die USB-Buchse die volle Leistung bringt und die Karte ca. 10-Mal schneller mit einem anderen Kartenleser arbeitet).


    Beim Einstecken des Fernbedienungssensors in einen USB-Port erhalte ich die Meldung unable to enumerate USB device on port X. Das sieht unter Windows ähnlich aus. Das Ding ist also entweder unbrauchbar order kaputt. Ich hoffe das ich stattdessen den Sensor meines AV-Boards dort integrieren kann, dann wäre das kein Verlust.


    Das Preis/Leistungsverhältnis für das Gehäuse ist meines Erachtens befriedigend bis gut. Eine vergleichbare Lösung mit einem 7"-Touchscreen ist aber ansonsten "neu" nur weitaus teurer zu ergattern. Die Wohnzimmertauglichkeit ist, nach einem Austausch bzw. einer Drosselung der Lüfter, ganz passabel. Zumindest habe ich nach langer Suche nichts brauchbareres in der Preisregion um € 300,- finden können und ich wollte die bereits erstandenen VDR-Komponenten nicht ohne Gehäuse und Nutzung veralten lassen :D.

    Hallo doe,


    ich habe den Tipp mit dem Quirksen aus der Touchscreenkonfiguration zum Thermaltake Gehäuse DH102 Beispielkonfiguration - Thermaltake DH 102 (etwas weiter unten). Das ist zwar ein anderer TS Hersteller mit einer anderen USB Geräte-Id (0x15c2:0x0034), aber der Vorgang sollte derselbe sein (google 'mal 0x15c2:0x0034:0x0004).


    Das Quirksen soll nach meinem Verständnis verhindern, dass das angegebene USB-Device (0x0eef:0x001) über den usbhid Treiber angesprochen wird. Zumindest funktionierte mein Touchscreen nicht mit dem usbhid Treiber. Der dritte Parameter ist der "quirks" (definiert in /usr/src/linux/include/linux/hid.h). Das 0x0004 steht für HID_QUIRK_IGNORE, also anscheinend das Ignorieren des zuvor angegebenen Devices.


    Ich habe den Eintrag testweise wieder entfernt aber usbtouchscreen bleibt derzeit trotzdem der Treiber für das Device 0x0eef:0x001. Die Gegenprobe mit dem Quirksen von usbtouchscreen führt dann aber dazu, das dann wieder usbhid das Device übernimmt.


    Seit Erstellung des Eintrages habe ich allerdings das Test-Board gegen ein Asus P5N7A-VM getauscht.


    Mein TS hat mit dem Orignalkernel des EasyVDR 0.6.06 (2.6.29.4) auf keinerlei Berührungen reagiert. Dabei sehen die Ausgaben von cat /proc/bus/usb/devices genau so aus. Auch das Inputdevice /dev/input/touch war vorhanden.

    Hallo Steve,


    ich habe selbigen TouchScreen mittlerweile auch touchend zum Laufen bekommen und hatte dieselben Probleme wie Du. Es war aber eine längere Reise...


    Als Grundlage dient mir ein EasyVDR 0.6.06, der ja nur die v0.1.9 vom GraphTFT-Plugin enthält. Die aktuellen TouchKit-Beta-Treiber von http://210.64.17.162/web20/eGalaxTouchDriver/linuxDriver.htm enthalten den Source für den Kernel-Treiber TKUSB und ein x-basiertes eGalaxTouchscreen Tool, was zum Kalibrieren unter X verwendet werden kann. Der TKUSB-Treiber stellte sich aber als sehr langsam heraus, so dass ich von dessen Verwendung abraten würde.


    Als Basis für die Installation dienten mir die folgenden Howtos (bitte beide komplett lesen):


    http://wiki.easy-vdr.de/index.php/GraphTFT
    http://www.vdr-wiki.de/wiki/index.php/Graphtft-plugin


    Insgesamt musste ich folgendes tun, um nicht nur ein Bild, sondern auch das Touchen zu ermöglichen:


    [list=1]
    [*]Kernel 2.6.29.4 kompilieren und installieren.
    [*]graphtft-plugin 0.3.3 aus dem SVN-Repository laden.
    [*]VDR mit GraphTFT-Plugin 0.3.3 unter allen weiteren Plugins übersetzen und installieren.
    [*]UDEV-Regel setzen für permanentes Input-Device /dev/input/touch.
    [*]USBHID-Treiber für TS USB-Device 0eef:001 quirksen
    [/list=1]



    KERNEL 2.6.29.4:


    Mit dem vorhadenen Kernel 2.6.22.15 konnte ich den TS nicht einbinden. Ich habe daher den aktuellen Kernel 2.6.29.4 von http://www.kernel.org als Source geladen und kompiliert. Als Grundlage zur Erstellung kann die ".config" Datei aus /usr/src/linux-2.6.22.15 verwendet werden.


    Benötigt wird der "USB Touchscreen Driver" als Module. Der "Generic HID support" ist bei mir im Kernel.



    VDR:


    Als VDR habe ich die vorhandenen v1.4.7-Quellen verwendet und dort unter /usr/local/src/VDR/PLUGINS/src die GraphTFT-Plugin-Sourcen durch die v0.3.3 aus dem SVN Repository ersetzt:


    Code
    1. cd /usr/local/src/VDR/PLUGINS/src
    2. rm graphtft
    3. mkdir graphtft-0.3.3
    4. ln -s graphtft-0.3.3 graphtft
    5. cd graphtft-0.3.3
    6. svn co https://vdr-graphtft.svn.sourceforge.net/svnroot/vdr-graphtft


    Danach habe ich den VDR und die Plugins komplett kompiliert und installiert, so wie dies in http://wiki.easy-vdr.de/index.php/GraphTFT beschrieben wird (auf -march in der Make.config achten!).



    UDEV:


    Um das Input-Device permanent unter /dev/input/touch ansprechen zu können, muss eine Regel in /etc/udev für das Device 0eef:001 erstellt werden. Ich habe dazu die Datei 10-remotes.rules mit folgendem Inhalt erstellt:


    Code
    1. KERNEL=="event*", SUBSYSTEM=="input", SYSFS{idVendor}=="0eef", SYSFS{idProduct}=="0001", SYMLINK+="input/touch"


    Danach noch einen symbolischen Link unter /etc/udev/rules.d erzeugen (vgl. http://www.vdr-wiki.de/wiki/index.php/Graphtft-plugin).



    USBHID-TREIBER QUIRKSEN:


    Damit sich der USBHID-Treiber nicht den TS unter den Nagel reißt, habe ich unter /etc/modprobe.d die Datei usbhid mit folgendem Inhalt angelegt:


    Code
    1. options usbhid quirks=0x0eef:0x0001:0x0004



    NACH DEM RESET:


    Nach einem Neustart sollte sich der Treiber usbtouchscreen dem Device 0eef:001 angenommen haben, wenn man die USB-Devices mittels

    Code
    1. cat /proc/bus/usb/devices

    anzeigen lässt. Mittels

    Code
    1. cat /dev/input/touch

    sollten nun bei Berührung des TS kryptische Ausgaben in der Konsole erscheinen. Auch

    Code
    1. evtest /dev/input/touch

    sollte nun Ausgaben produzieren.



    EINRICHTUNG DES GRAPHTFT-PLUGINS:


    Ist der eigen-kompilierte EasyVDR gestartet, so kann man die Einstellungen des GraphTFT-Plugins ändern. Es muss zunächst das Input-Device /dev/input/touch angegeben werden. Nun sollte das Kalibrieren gehen (F3/gelb). Erst danach kann man es testen (F2/grün), da sonst ggf. ein Neustart des VDR erfolgt.


    Der EasyVDR bindet ein aktiviertes GraphTFT-Plugin gleich als Framebuffer-Device /dev/fb0 ein, so dass nach dem Start sofort eine Ausgabe für den aktullen Sender erfolgt.



    Framebuffer vs. X


    Standardmäßig bindet EasyVDR das GraphTFT-Plugin als Framebuffer-Device /dev/fb0 ein, was ja bei Verwendung einer FF-Karte ausreicht. Will man xineliboutput verwenden, so kommt man meines Wissens nicht um X mit zwei Displays herum. Dem EasyVDR muss man dann als Device statt /dev/fb0 ein none übergeben, sonst gibt es Geflacker im X-Display.



    HARDWARE:


    Getestet habe ich mit einem M3A78-EMH Board und dem TS an VGA und einem alten Board mit einer Matrox G200 und dem TS an deren VGA Ausgang. Für beide Boards mussten im EasyVDR kein weiteren Einstellungen vorgenommen werden.

    Hallo halbfertiger,


    danke erstmal für die schnelle Antwort :respekt. Das Problem ist mir bisher nie aufgefallen.


    Aufgrund Deiner Antwort habe ich es einmal mit unterschiedlichen Brückenzeiten probiert. Das Problem ist aber wirklich die eingestellte Brückenzeit selbst. Ein Mindestzeit existiert meines Erachtens nicht (solange der Rechner nur schnell genug rauf- und runterfährt :)).


    Setze ich die Brückenzeit auf 1 Minute runter, so sind auch Aufweckzeiten 8 Minuten in der Zukunft kein Problem. Setze ich sie hingegen auf 60 Minuten hoch, so ändert sich die Aufweckzeit noch extremer. Als Formel für die fehlerhaft berechnete Aufweckzeit von Timern innerhalb der Brückenzeit lässt sich formulieren:


    Code
    1. (falsche) Aufweckzeit = aktuelle_Zeit + Brückenzeit - Wakeup_Vorlaufzeit


    Sobald ein Timer nur eine Minute außerhalb der Brückenzeit liegt, egal wie lang diese ist, funktioniert das Berechnen der Aufweckzeit problemlos. Also sollte man die Warnung bzgl. einer bald anstehenden Aufnahme lieber nicht ignorieren...

    Moin zusammen,


    nach der Installation des c't VDR 7.0 hatte ich Probleme mit dem ACPI Wakeup und habe daher ein wenig herumprobiert. Dabei habe ich ein paar Test-Timer erstellt, die meistens ca. 10-15 Minuten in der Zukunft lagen. Danach wurde der VDR mit dem Power-Button der VDRAdmin-AM Fernsteuerung beendet (also FB 2xPower-Button + Bestätigung des Herunterfahrens trotz nahendem Timer-Events). Die durch den Shutdown-Hook des VDR erstellte Wakeup-Zeit war in mehreren Versuchen falsch (siehe syslog-Ausgaben). Nur wenn die Test-Timer so weit in der Zukunft lagen, das die Abschaltung des VDR keine Rückfrage provozierte, wurde die korrekte Aufweckzeit des nächsten Timers (minus 5 Minuten Vorlauf) ins BIOS übernommen. Kann jemand dieses Phänomen nachvollziehen?


    Der VDR ist ein 1.6.0-2 mit dem per apt-get nachinstallierten eTobi Kernel 2.6.28 aus dem c't Artikel.



    Korrekte Aufweckzeit bei Abschaltung außerhalb der Brückenzeit:


    Falsche Aufweckzeit bei Abschaltung innerhalb der Brückenzeit (30 Min.) mit expliziter Bestätigung:


    Bei der Abschaltung außerhalb der Brückenzeit kommt als Log-Ausgabe noch ein next timer event at ... vor dem Aufruf der VDR Shutdown-Hooks. Bei der Abschaltung innerhalb der Brückenzeit steht dort stattdessen reboot at ... mit einer Uhrzeit in der Zukunft, die ziemlich genau der aktuellen Uhrzeit plus der Brückenzeit von 30 Minuten entspricht. Anscheinend wird von dieser dann die Vorlaufzeit (bei mir 5 Minuten) abgezogen und ins BIOS übernommen (vgl. 2. Log-Ausgabe).