you can touch this - mein neues TouchTFT-VDR-Gehäuse

Ok,
danke für das feedback...

Grüße

Hallo,

habe das Gehäuse auch, nur unter dem Namen Superpower (glaube Snogard) gebraucht für 200 gekauft. Allerdings habe ich meinen Homebrew IR-Empfänger dort eingearbeitet von der Atric Platine. Die Lüfter sind getauscht und noch 2 weitere eingebaut.
Die Touch Funktion habe ich bisher nur getestet, lief leider nicht so gut ab, da es sehr stark prellt, hier muß das Timing von 30ms auf 100ms sicherlich eingestellt werden, doch fehlte mir die Zeit bisher dazu...
Ansonsten doch ein schickes Gehäuse mit gut ablesbaren TFT (welches ich mit vga=0x314 starte).

Greetz
LbgDJ

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.

Zitat

Original von omo
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.

Zur Zeit gäbe es da vielleicht was: Schnäppchen? Amisos X15e Touchscreen (baugleich DIGN?)

Grüße

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).

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:

config TOUCHSCREEN_TOUCHKIT
        tristate "EETI TouchKit touchscreen driver"
        help
          Say Y here if you have a EETI compatible touchscreen.


          To compile this driver as a module, choose M here: the
          module will be called tkusb.

Makefile:

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):

Section "ServerLayout"
    InputDevice "EETI" "SendCoreEvents"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    Screen      1  "Screen1" 1280 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection


Section "Extensions"
    Option         "Composite" "Disabled"
EndSection


Section "Files"
EndSection


Section "Module"
    Load           "dbe"
    Load           "extmod"
    Load           "type1"
    Load           "freetype"
    Load           "glx"
EndSection


Section "ServerFlags"
    Option         "Xinerama" "0"
EndSection


Section "InputDevice"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection


Section "InputDevice"
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection


Section "InputDevice"
    Identifier "EETI"
    Driver "egalax"
    Option "Device" "usbauto"
    Option "Parameters" "/var/lib/eeti.param"
    Option "ScreenNo" "1"
EndSection


Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "EIZO"
    ModelName      "EIZO L788"
    HorizSync       30.0 - 65.0
    VertRefresh     59.0 - 61.0
    Option         "DPMS"
EndSection


Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "HOST"
    ModelName      "CRT-0"
    HorizSync       28.0 - 65.0
    VertRefresh     59.0 - 61.0
EndSection


Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 9300 / nForce 730i"
    BusID          "PCI:3:0:0"
    Screen          0
EndSection


Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 9300 / nForce 730i"
    BusID          "PCI:3:0:0"
    Screen          1
EndSection


Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "metamodes" "DFP: 1280x1024 +0+0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection


Section "Screen"
    Identifier     "Screen1"
    Device         "Device1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "TwinViewXineramaInfoOrder" "CRT-0"
    Option         "metamodes" "CRT: 800x600 +0+0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

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

Gruß,

omo

Es gibt im 2.6.35er Kernel einen Patch für unseren Screen 0eef:0001

Vielleicht löppt er ja nu OOTB. Bei mir geht er jedenfalls nach ca. einem Jahr immer noch nicht. Ich gebe zu hauptsächlich mangels Böcken an den Kernelsourcen rumzuschrauben.

Guggst Du

Hab ich gerade auf Heise gelest.

Mal sehen ob ich es schaffe, die Tage den Compiler anzuwerfen.