Posts by schMA

Hallo,

entschuldige mein Delay, aber ich war über die Feiertage nicht zu Hause.

Ich kann dir mal grob schildern, wie ich vorgegangen bin (war aber ein Debian).
In den lirc-Modul Quellen (die sind unter Debian ein eigenes Paket) musst du die Datei drivers/lirc_mceusb2/lirc_mceusb2.c modifizieren:

Du musst nach folgendem Teil der Datei suchen:

static struct usb_device_id usb_remote_table [] = {
        { USB_DEVICE(VENDOR_PHILIPS, 0x0815) }, /* Philips eHome Infrared Transciever */
        { USB_DEVICE(VENDOR_SMK, 0x031d) },     /* SMK/Toshiba G83C0004D410 */
        { USB_DEVICE(VENDOR_TATUNG, 0x9150) },  /* Tatung eHome Infrared Transceiver */
        { USB_DEVICE(VENDOR_GATEWAY, 0x3009) },  /* Gateway eHome Infrared Transceiver */
        { }                                     /* Terminating entry */
};

Und dort kannst du für deinen Emfpänger einen Eintrag hinzufügen. Bei mir sieht der Teil nun wie folgt aus:

static struct usb_device_id usb_remote_table [] = {
        { USB_DEVICE(VENDOR_PHILIPS, 0x0815) }, /* Philips eHome Infrared Transciever */
        { USB_DEVICE(VENDOR_SMK, 0x031d) },     /* SMK/Toshiba G83C0004D410 */
        { USB_DEVICE(VENDOR_TATUNG, 0x9150) },  /* Tatung eHome Infrared Transceiver */
        { USB_DEVICE(VENDOR_GATEWAY, 0x3009) },  /* Gateway eHome Infrared Transceiver */
        { USB_DEVICE(0x1784, 0x0001) },         /* Topseed eHome Infrared Transceiver */
        { }                                     /* Terminating entry */
};

0x1784 ist in meinem Fall die Vendor-ID und 0x0001 die Product-ID (mein Empfänger ist ja auch von Topseed).
Du brauchst hier die 0x1460 und 0x9150.

Anschließend kann ich ein Debian Paket mit den lirc Treibern bauen lassen.
Ich habe hier aber noch das Problem, dass sich der lirc_mceusb Treiber für das Gerät zuständig fühlt, aber nicht wirklich funktioniert. Daher habe ich dieses Kernelmodul einfach kurzer Hand gelöscht, depmod -a, reboot und gut.

Nur mal so ein Schuss in's Blaue: Ich habe hier auch einen MCE USB Empfänger, der sich als eHome ... meldet.
Um ihn mit den lirc Modulen aus Debian etch ans Laufen zu bekommen, musste ich zuerst mal die USB IDs in das Kernelmodul patchen, da es per default den eHome wohl nicht unterstützt. Danach noch die lirc Module neu kompilieren und gut.

Ich kenne mich mit CentOS jetzt nicht wirklich aus, aber hat das nicht SELinux per default aktiviert? Das würde das Verhalten erklären...

Quote

Original von Manx
5.) mit z.B ./vdr.sh > 2&>1 > /dev/null den VDR starten, bei mir logt er ins syslog

Ich denke mal, das sollte eher ./vdr.sh > /dev/null 2>&1 heißen, oder kurz (in der bash): ./vdr.sh &> /dev/null.

Meine persönliche Empfehlung (läuft bei mir hier auch seit > 1 Jahr im Produktivbetrieb):

Jinzora steuert im Jukeboxmodus den MPD

Nun, meines Wissens nach nutzen alle lirc Clients /dev/lircd zur Kommunikation mit dem lirc Daemon. Also mal flugs in der domU anlegen...

Solche merkwürdigen Probleme kann es geben, wenn du (evtl. aus Versehen?) noch ein zweites Gerät im LAN hast, das ebenfalls die 192.168.1.5 hat.

Ich habe noch 5 LinuxTag 2007 Eintrittskarten zu vergeben und wollte mal nachfragen, ob hier jemand Interesse hat. Die Karten gelten an allen Tagen.

OK, das ist natürlich gleich der einfachste Weg
Wusste nicht, dass backports.org schon für etch aktiv ist...

Hallo hoarst:
Also in die sources.list würde ich Debian unstable wegen dem neuen Kernel mal nicht aufnehmen - sonst musst du dich noch mit apt-pinning rumschlagen, um die restlichen Pakete auf etch zu halten.
Ich würde mir an deiner Stelle einfach das Paket mit wget holen und installieren (siehe der Link, den ich gepostet habe, also z.B. http://ftp.de.debian.org/debian/pool/ma…6.20-3_i386.deb für das i686 Kernel Paket).
Dieses kannst du dann direkt mit dpkg -i installieren, da es keine Abhängigkeiten hat, die in etch nicht enthalten sind.

Brauchst du die linux-headers überhaupt? Also musst/willst du noch zusätzliche Module für den Kernel kompilieren? (lirc vielleicht?)
Falls ja, hier das grobe Vorgehen:
- Die Pakete linux-headers-2.6.20-1-686 und linux-headers-2.6.20-1 analog zu oben aus unstable holen.
- Von linux-kbuild-2.6.20 nur die Sourcen aus unstable holen (das Binärpaket ist schon gegen die neuere libc6 2.5 aus unstable gelinkt, daher unter etch nicht installierbar) und das Paket selbst bauen (backporten). dpkg-buildpackage ist dein Freund.
- Die Pakete mit dpkg -i in folgender Reihenfolge installieren:
1. linux-kbuild-2.6.20
2. linux-headers-2.6.20-1
3. linux-headers-2.6.20-1-686
Evtl. musst du noch Pakete mit apt/aptitude nachinstallieren.

Das wars im Großen

Weil ich das ganze erst bei einem Kollegen hatte: Die S-1401 läuft ab Kernel 2.6.19 (zumindest die, die mein Kollege vor ein paar Tagen vom dvb-shop bekommen hat). Unter Debian etch lässt sich der 2.6.20 aus unstable problemlos installieren - nur für die linux-headers muss man ein wenig tricksen (soll heißen selbst backporten).

linux-image aus unstable (bei Bedarf evtl. eine andere Architektur verwenden, z.B. amd64).

Quote

Kann man dieses Upscaling irgendwie einstellen oder ist das in Vorbereitung?

Also meines Wissens nach ist video upscaling derzeit nicht implementiert, da eigentlich Methode 2 bevorzugt wird.

Quote

Wird das von Xineliboutput bereits benutzt?

Soweit ich das verstanden habe, könnte xineliboutput das wohl jetzt schon nutzen, ja.

Quote

Geht das auch mit XV oder Vidix?
Welche Hardware wird denn unterstützt?

Gute Frage, weiß ich aber leider auch noch nicht wirklich. Ich beschäftige mich selbst auch erst seit knapp 2 Wochen mit xineliboutput.

Ich bin aktuell unter anderem wegen diesem Themas an einer Diskusion auf der VDR Mailingliste (Topic: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?) beteiligt, da gehts zwar primär um die Ausgabe per DirectFB, aber Petri Hintukainen hatte einige interessante Erläuterungen auf Lager, z.B.:

Quote

Probably channel uses smaller resolution than VDR OSD (720x576).

There are two methods for OSD blending:
1) "scaled OSD": OSD is blended to each video frame in software. Because
of this OSD size and resolution can't exeed video size/resolution, and
OSD can't be drawn outside of video frame (=those black bars resulting
>from hardware scaling when fitting 4:3 video to 16:9 display or
opposite). If video is lower resolution than OSD, OSD must be cropped or
downscaled. (Well, another possibility would be upscaling video in
software).
2) "unscaled OSD": OSD and video are mixed by hardware using either
colorkeying (no opacity) or hardware RGBA layer. OSD and video can be of
different size and OSD can be blended outside of video frame. OSD size
is constant (fbdev primary layer size, most likely 720x576).

Xine-lib directfb driver supports method 2) for only some hardware with
ARGB blending capacity. For the rest method 1) is used.

Display More

Das Problem mit IRQs, die zwischen verschiedenen XEN Domains geshared werden ist leider bekannt (und leider auch nicht erst seit ein paar Wochen).
Es sollte dir helfen, ALLE Domains, die den fragwürdigen IRQ sharen (also in deinem Fall wohl AUCH dom0) mal mit dem Kernelparameter 'noirqdebug' zu starten.
Meiner Erfahrung nach ist das Problem damit behoben.

edit: Habe gerade gesehen, dass du noirqdebug wohl schon versucht hast. Aber deine extra= Zeile sieht für mich ein wenig komisch aus.

Quote

extra=swiotlb=force noirqdebug

Ich denke, das sollte wohl mehr

extra = "swiotlb=force noirqdebug"

lauten.
Hänge doch vielleicht mal die config deiner VDR Domain an...

edit2: Ich habe gerade noch einen Blick auf die dmesg Ausgabe deiner dom0 und domU geworfen: Die domU akzeptiert den noirqdebug Parameter korrekt und deaktiviert IRQ debugging auch korrekt, ABER deine dom0 wird ohne den Parameter gestartet, und daher krachts vermutlich

Quote

Original von chipsfrisch

Komisch nur, dass die Umbauanleitungen und verschiedene Antennen überall zu finden sind.

Wahrscheinlich bilde ich (und alle anderen) mir auch nur ein, dass das WLAN mit der etwa 30cm langen 9dbi Antenne besser funktioniert als mit dem Standard-AVM-Stummel?

vdrtux hat Recht, es ist auch nicht möglich, mit einer anderen Antenne mehr Leistung zu bekommen. Das Signal wird z.B. bei einer Yagi Antenne lediglich sehr stark gerichtet, so dass die zur Verfügung stehende Leistung eine längere Distanz überbrücken kann.

Vielleicht interessiert euch das hier: http://www.pro-linux.de/work/anrufbean…rter-teil1.html

Ich hatte selbst früher mal vbox2 am laufen - wegen zu geringer Akzeptanz der Anrufer beim letzten Serverumzug aber einfach nicht mehr eingerichtet...

Hmm, also ich habe euren Thread hier schon eine ganze Zeit mitgelesen, konnte aber auch nichts direkt konstruktives beisteuern.
Was mich jetzt aber SEHR stark verwundert, ist die Tatsache, dass durch die Installation von udev das Problem verschwunden ist.
Ich meine, wenn schetti schreibt

Quote

in den Logfiles der DomU kann man auch erkennen, dass die DVB-Karte initialisiert wird. nur lsmod zeigt keine geladenen Module

dann stimmt da irgendwas nicht so recht...
Denn: Wenn man in den Kernelmeldungen sieht, dass die DVB-Karte(n) initialisiert wird/werden, man mittels lsmod aber keine Module sieht, dann kann das einzig und alleine daran liegen, dass die DVB Treiber fest im Kernel einkompiliert sind. Aber wie wir anfangs bei kniepbert gesehen haben, funktioniert dies wohl nicht so recht (oder es hätte funktioniert, siehe weiterer Text).

Das einzige, das ich mir noch irgendwo vorstellen könnte, wäre, dass ihr die /dev/dvb/ Struktur einfach nicht erstellt habt. Ein default sarge bringt die nicht mit. Dank udev werden diese Gerätedateien automatisch erstellt und es funktioniert. Beim DVB Sourcecode für den 2.4er Kernel war immer ein Skript mit dabei, welches die devicenodes angelegt hat...

Tach kniepbert,
ich würde jetzt mal tippen, dass bei dir pcifront (der "virtuelle" XEN PCI Bus) einfach erst NACH den DVB Treibern geladen/initialisiert wird und du deshalb evtl. keinen Zugriff auf die DVB Karten bekommst. Mein Vorgehen wäre es, die DVB Treiber als Modul zu kompillieren und nicht fest in den Kernel rein.

Ja, du hast recht, darüber bin ich gestern auch noch gefallen. Ich dachte ursprünglich, dass die Hersteller da schon etwas ehrlicher wären und zumindest einen RGB Farbpunkt als Pixel zählen lassen, aber nein...
Mit 640x480 ist das Ding natürlich schon wieder ein Stückchen uninteressanter, aber die Idee eines head mounted displays an und für sich finde ich schon genial.

Hatte von euch vielleicht schon mal jemand Gelegenheit, das von Pearl angebotene auvisio Multimedia-Headset (Cyberman) selbst zu testen?
Haben die ja schon seit einiger Zeit im Angebot, aber ~200.000 Pixel sind einfach zu wenig.
Vor kurzem bin ich aber per Zufall über oben verlinkte Variante mit 922.000 Pixel gefallen. Ich gehe jetzt mal davon aus, dass die Pearl Gauner da die Aufösung der Panel für beide Augen mal brav addiert haben. Aber selbst dann (720x576x2 = 829.440) würde es für PAL locker reichen...