Beiträge von shh

shh · 28. Mai 2014

Hallo,
ich habe ein Verständnisproblem. Wenn ich mir diese Grafik ansehe, gibt's zig Wege IR-codes irgendwie "erkennen" zu können:
http://www.yavdr.org/documentation/0.5/de/ch02s03.html

Nun kann man udev-rules erstellen, damit beim Anstecken des USBasp-IR-Geräts der irmplircd geladen wird. Eigentlich ist das jedoch umständlich, da man extra nen extra dämon kompilieren und laden muss. Evtl. auch noch cross-compile und fürs OpenELEC-image sowieso total umständlich.

Der USBasp erstellt mir ja schon ein hidraw-device. Kann man da nicht irgendwo ne .map erstellen, dass das System LIRC-events zu hören bekommt?
Warum hört mein System keine LIRC-events vom hidraw-dev? Tastatur-hid-events kommen ja auch durch!?
"Irgendwie" scheinen da ja schon etliche Protokolle und IR-Empfänger implementiert zu sein, ich verstehe aber nicht wie das System die Codes letztlich "bekommt", bzw ausführt.
Blickt da jemand durch?

Eine weitere Frage ist, warum der USBasp+IR-Empfänger sich nicht gleich als event-dev anmeldet. Wäre da ein extra kernel-modul nötig?

shh · 27. Mai 2014

Hallo,
habe auch einen Empfänger auf USBasp-Basis aufgebaut.
- nur USBasp mit Atmega8A aus Hong Kong von hier: http://www.ebay.de/itm/310506909410?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649
- TSOP direkt verbunden (Spannungsstabi über RC-Glied dürfte bei USB-Power überflüssig sein) an SCK/Pin7 der 10-Port Buchse.
- main.hex mit arduino und auch einem anderen USBasp geflasht. verify war ok.
- FUSES auf 0xC9 und 0xEF

Damit wir unter Linux ein hidraw0 erstellt und lsusb zeigt mir das Gerät auch an.
Wenn ich auf verschiedene Fernbedienungen drücke flackert die grüne LED, die rote ist dauerhaft an.
ABER:
cat /dev/hidraw0 bringt NICHTS!

Daher kann irmplircd, irw etc. auch nichts mehr anzeigen.
Was stimmt denn hier nicht?

NACHTRAG:
Mmm, Kommando zurück. Auf einem "richtigen" Rechner mit Debian 7.0.5 live-CD ging's jetzt.
Kann es sein, dass ein Laptop am USB-Port zuwenig Strom liefert?!

NACHTRAG2:
OK, ich bin doof.
hidraw0 war das device der Maus, nicht vom USBasp. Ergo: geht auch am Laptop, wenn man das richtige hidrawX erwischt.

Gibts eigentlich schon ein plugin für OpenELEC?

shh · 12. Juli 2013

Klar, geht die unter OpenELEC, hab ich doch in dem Thread bei den OpenELECs drüben beschrieben.
Ich hab allerdings keine Lust, das nochmal groß auszuführen - meine Probleme mit dem Empfänger haben auch keinen interessiert.
Nur soviel: Patchen + Kompilieren ist nötig, außerdem muss der patch an den aktuellen OpenELEC angepasst werden. Am besten mit meinem patch anfangen, ich musste etliches anpassen. Build-System anpassen ist nicht mehr nötig.
Siehe: http://openelec.tv/forum/103-i…or-yausbir?start=15#79426

Hier mal mein aktuelle howto:
0. Dev-System einrichten: http://openelec.tv/forum/12-gu…nelec-distro?limitstart=0
1. lirc-0.9.0-030-ya_usbirv3.patch nach
~/OpenELEC.tv/packages/sysutils/remote/lirc/patches/ kopieren
2. ir-toy patch löschen!
3. bauen:
PROJECT=ION ARCH=x86_64 make release
4. SYSTEM + KERNEL nach \Update auf dem OpenELEC und updaten lassen

ANPASSUNGEN am OpenELEC:
1.
2. Lircmap.xml nach \Userdata
3. autostart.sh nach Configfiles
4. lircd.conf nach Configfiles
5. remote.conf nach Configfiles

shh · 13. Dezember 2012

Zitat von Argus

das denke ich nicht, die Seite 5 (siehe unten) ist bei allen Modellen identisch.

Hast Recht. Das Datenblatt zum TSOP17xx liest sich dazu etwas ausführlicher. Die Funktionsweise ist anscheinend gleich. Beide haben einen Bandpass filter und eine auto gain control, wenn Störungen erkannt werden.
Leider habe ich aber keinen TSOP34838 um prüfen, ob nun wirklich keine Unterschiede beim Empfang festzustellen sind.

Zitat

IR-Filter bauen

Zitat

wiki:...Wir kaufen uns also einen Diafilm und geben diesen unbelichtet(!) zur Entwicklung

Öhm... Ja.
Ist sicher einen *Versuch* wert, dafür aber eigentlich zu umständlich und zu teuer: Stattdessen könnte man sich die ganze Palette an TSOPs bestellen und damit etliche Versuche starten. ZB mit dem TSOP34438, der nen stärkeren Filter hat.
Das Problem ist ja eigentlich, dass der TV anscheinend tatsächlich IR-Rauschen produziert, das trotz Bandpassfilter und AGC durchkommt. Wahrscheinlich durch die Hintergrundbeleuchtung des TVs, weil's ja auch bei schwarzem Bild so ist. Ich verstehe jetzt nicht, was da ein IR-Filter helfen soll.

NACHTRAG1:
Hab den TSOP jetzt in eine alte FB gesteckt mit tiefdunktem Kuststoff vorne an der IR-Sendediode. Müsste auch ein IR-Filter sein, oder?
Jedenfalls: Keine Änderung, gleiches Geblinker.

Zitat

Erstaunlich ist aber, das andere Empfänger bei diesem Pegel nicht zugestopft werden.

Ja, allerdings. Irgendwas müssen die besser machen. Denn qualitativ hochwertigere Empfänger bauen die bestimmt nicht ein. Und zwei meiner Billiggeräte haben exzellentes Empfangsverhalten: Da kann ich auch mal "irgendwo an die Wand schießen" - kommt trotzdem an.
Ich gehe davon aus, dass die Empfänger da schon gezieht nach Protokoll filtern. Also das µC-Programm selbst, das nach NEC, oder RC5 filtert. Einfach *alles* anzunehmen, was der TSOP ausspuckt, kann nicht gut sein, wie man sieht.
Störungen könnten zwar auf Software-Ebene von LIRC gefiltert werden, LIRC macht das ja eigentlich via lircd.conf, fatal ist aber, dass da irgendwas zu lange dauert. Der µC blockiert anscheinend, weil beim grünen Blinkern einfach keine anderen gültigen Signale meiner Fernbedienung mehr angenommen werden.
Irgendwas dauert also zu lange. Entweder die µC-Verarbeitung der TSOP-Pulse, oder die USB-Kommunikation (mit LIRC). Komisch dass dabei auch der tolle USB2.0 C8051F387 nix hilft.

NACHTRAG2:

Code

mode2: yaUsbIr: Initializing yaUsbIr
mode2: yaUsbIr: device: vid=10C4, pic=876C, with 1 interface
mode2:          Manufacturer: UG Development Lab
                Product: yaUsbIR V2:IR transceiver with power switch
                hid interface (generic)
space 425971
pulse 104
space 425971
pulse 91
space 425971
pulse 104
space 425971
pulse 65
space 425971
pulse 104
space 425971
pulse 143
space 425971
pulse 143

Alles anzeigen

Sowas zB ist sporadischer "IR-Müll" wenn ich den Empfänger verstecke (sodass ich ihn mit meiner IR-Bedienung nicht mehr erwische).
Das grüne Geblinker ist übrigens unregelmäßig gewesen, im Gegensatz zu den const anmutenden space 425971. Die Anzahl der space/pulse-Erkennungen von mode2 dürfte der Zahl der grünen Geblinker entsprechen (ich kann das nicht genau sagen, weil ich zwischen den Zimmern hin- und herflitzen muss).
Komisch ist, dass mode2 nach einem erneutem Start 5min(!) später total voll ist, d.h. alle gesammelten space/pulse ausgibt. Hmm... Das Puffern von Signalen 5min lang kann eigentlich nicht gut sein - machen das alle Lirc-Module so?
Bei Drücken der FB-Knöpfe hab ich übrigens kurze space-Werte und "beliebige" pulse-Werte (ich war jetzt zu faul nachzuschauen, was die Werte bedeuten).

shh · 13. Dezember 2012

Der USB-Port dient doch beim RasberryPi zur Spannungsversorgung.
Der yaUsbIR benötigt "laufend" 5V irgendwoher.
Beim Einschalten (= wenn yaUsbIr einen bestimmten IR-Code erkennt) schließt er zwei Pins kurz, was am PC so funktioniert, wie wenn man den Power-Knopf drückt.
Also NEIN: Der yaUsbIr schaltet nicht den USB-Port oder die 5V-Leitung zur Spannungsversorgung, er gibt nur einen Impuls. Willste schalten bäuchtest du n Relais.

shh · 13. Dezember 2012

Danke hepi. Die Beiträge bestätigen aber leider nur meine Beobachtung. Ich muss also meinen TV verschrotten, oder den IR-Empfänger so verstecken, dass ich ihn selbst nicht mehr erreiche? Ist leider keine Lösung.
Dieses Problem hat _kein_ anderer Empfänger _irgendeines_ meiner Geräte: VCR, SAT-Box, TV, Media-Player, Receiver, ... usw. Die alle schaffen das, dass der IR-Empfänger bei dem IR-Rauschen - in irgendeinem Band - trotzdem noch funktioniert und dabei gültige RC-Signale nicht blockiert.

Wenn das denn kein mechanisches Problem ist (TSOP34838 ist der Nachfolger vom TSOP1738 soweit ich das verstanden habe, vielleicht hat der nen besseren Filter), so ist das ein Softwareproblem. Denn einerseits blockiert yaUsbIr Gerät anscheinend bei "IR-Müll", andererseits werden anscheinend auch "unmögliche" RC-Signale weitergeleitet.
Ich weiß ja nicht, wie die firmware aufgebaut ist, aber vielleicht könnte man solche Störungen auch softwaremäßig ausmerzen.
zB:
- Standardfilter, der meine Peaks rausfiltert/ignoriert. Die Störungen sind aber je nach TV-Helligkeit, Umgebungslicht, Lampenverwendung wahrscheinlich schwer zu identifizieren...
- Puffer implementieren (ist wahrsch. eh schon drin, um die USB-frames zu füllen) und die Empfangsdaten auf _gültige_ Protokolle filtern. Ich bin eigentlich davon ausgegangen, das sowas schon drin wäre.
Es müsste relativ einfach sein, auf gültige Start-Codes der bekannten Protokolle zu prüfen (RC5,RC6, Denon, NEC, Sony, ...).
Siehe: http://www.mikrocontroller.net…otokolle_Diplomarbeit.pdf
Protokolle exotischer Trägerfrequenzen werden wg. 38kHz Vorgabe eh nicht benötigt. Bzw. hat man eigentlich immer eine programmierbare Fernbedienung, die RC5 oder NEC kann, die man entsprechend für den yaUsbIr anlernen kann. Ich sehe keinen Anwendungsfall, wo der yaUSBIr unbedingt auf irgendein exotisches Privatprotokoll hören müsste.

shh · 12. Dezember 2012

Hallo,
hab jetzt mal Zeit gehabt, die yaUSBIrV2-Platine einzurichten.
Ich habe eine mit großem IR-Empfänger bekommen, der TSOP1738 müsste das sein. Kabel waren auch fix und fertig dabei.

Schalte ich den TV, fängt yaUsbIr ununterbrochen "schnell grün" zu blinken an. Dabei werden dann keine IR-kodes meiner Fernbedienung mehr erkannt:

Code

root ~ # mode2
mode2: yaUsbIr: Initializing yaUsbIr
mode2: yaUsbIr: device: vid=10C4, pic=876C, with 1 interface
mode2:          Manufacturer:
                Product:
                hid interface (generic)
mode2: yaUsbIr: unable claim interface 0
mode2: yaUsbIr: unable to open yaUsbIr device '10c4:876c'
mode2: yaUsbIr: connect to yaUsbIr device '10c4:876c'
space 1586
pulse 1716
space 4524
pulse 1781
space 4459
pulse 1677
space 4589
pulse 1716
space 4563
pulse 1755
space 4498
pulse 1664
space 4576
pulse 1716
space 4498
pulse 1755
space 4550
pulse 1703
space 4537
pulse 1690
space 4576
pulse 1703
space 4511
pulse 1781
space 4485
pulse 1703
space 4550
pulse 1729
...

Alles anzeigen

Wir haben hier einen "normalen" 52" Samsung TFT TV ohne LED Hintergrundbeleuchtung.
Dieses IR-Rauschen empfängt der TSOP fast überall im Zimmer. Kommt mir fast unmöglich vor, anscheinend reagiert der auch auf die ganzen Reflektionen der Wand. Reagiert übrigens auch, wenn der TV "total schwarz" ist.
Jedenfalls muss ich den Empfänger total verstecken, damit das Blinken aufhört. Dann ist aber - natürlich - das Teil mit der normalen Fernbiedienung nicht mehr zu erreichen.

Tja, was tun?
Ist der 1µF C3 zu klein, oder auf den TSOP34838 ausgelegt, sodass das hier nicht ordentlich läuft?

shh · 21. Mai 2012

Also...
Lösung1 (mit LIRC):
Eine Datei in /usr/share/X11/xorg.conf.d erstellen, zB eine 11-evdev-tevii-s480.conf mit folgendem Inhalt:

Code

Section "InputClass"
  Identifier "Ignore the two IR devices"
  MatchProduct "IR-receiver inside an USB DVB receiver"
  Option "Ignore" "true"
EndSection

Damit werden beide devices unter X ignoriert.
Dann via dpkg-reconfigure lirc LIRC auf die Linux input layer setzen, dann ein Gerät via by-path auswählen.

Es gibt auch eine Option MatchDevice, die man oben einsetzen könnte, um bestimmte Geräte zu identifizieren. Z.B.:

Code

MatchDevice "/dev/input/event5"

ginge also, allerdings ist das unsinnig, da sich die event-device-Nummern ja je nach angesteckten Geräten verändern.
Die by-path-devices, wie hier zB /dev/input/by-path/pci-0000:02:00.3-usb-0:1-event-ir gehen leider nicht, wegen einem bug in X (zB-> http://lists.debian.org/debian-x/2011/11/msg00197.html ). X erkennt da nämlich keine Symlinks, obwohl die bei udev mittlerweile verpflichtend sind.

Lösung2:
Ein event-device ignorieren. Hier hat man allerdings das Problem, dass beide devices bis auf den PCI-Pfad exakt gleich aussehen (siehe cat /proc/bus/input/devices)
Man muss den devices erstmal einen eindeutigen Namen geben, damit X dann ein bestimmtes device sperren kann.
Ich habe hier event4 und event5, von denen ich event5 sperren möchte. Meine Karte steckt im PCIe-Port eines ASRock A330ION. Bei euch müssen die PCI-Adressen evtl. angepasst werden.

1. Erstmal den Adresspfad nachschaun und die Adresse von ATTRS{phys} notieren:
udevadm info -a -n /dev/input/event5

2. Eine Datei erstellen: /etc/udev/rules.d/66-xorg-tevii-ir-quirks.rules
Es wird den physischen PCI-devices ein bestimmter tag zugewiesen

Code

ACTION!="add|change", GOTO="xorg_tevii_ir_quirks_end"
KERNEL!="event*", GOTO="xorg_tevii_ir_quirks_end"


# Set some ID_INPUT.tags for the IR-devices
ATTRS{phys}=="usb-0000:02:00.1-1/ir0", ENV{ID_INPUT.tags}="tevii_ir0"
ATTRS{phys}=="usb-0000:02:00.3-1/ir0", ENV{ID_INPUT.tags}="tevii_ir1"


LABEL="xorg_tevii_ir_quirks_end"

3. udev aktualisieren via:
udevadm test --action=change /devices/pci0000:00/0000:00:0c.0/0000:02:00.1/usb2/2-1/input/input4/event4
und
udevadm test --action=change /devices/pci0000:00/0000:00:0c.0/0000:02:00.3/usb3/3-1/input/input5/event5
Dann sieht man ganz unten schon den neuen tag:

Code

...
ID_INPUT.tags=tevii_ir1

4. Eine Datei erstellen: /usr/share/X11/xorg.conf.d/11-evdev-tevii-s480.conf
(das MatchProduct ist eigentlich nicht nötig)

Code

# Remove the double IR device of a TeVii S480 card.
# Events from the IR-port are sendt to *both* event devices,
# effectively doubling all IR key presses under X.


Section "InputClass"
  Identifier "Ignore the second IR device"
  MatchProduct "IR-receiver inside an USB DVB receiver"
  MatchTag "tevii_ir1"
  Option "Ignore" "true"
EndSection

Alles anzeigen

So wird dann event5 von X zwar noch erkannt, aber nicht mehr als keyboard-device via xinput hinzugefügt.
Es ist also nur noch ein event-device für den IR-port der Karte aktiv.

shh · 18. Mai 2012

Guten Morgen Albert,

> Stellst Du immer die falsche Fragen? Wie jung sollte es heißen.

Wie, die falsche Fragen? Entschuldige! Meins war grammatikalisch korrekt; man fragt nach dem Alter, nicht nach der Jungheit.

Nö, Albert, das Problem mit der DVB-Karte (nicht FB, wenn du den Beitrag gelesen hättest), habe ich noch nicht gelöst.
Aber du darfst diesen thread gerne ignorieren, wenn du keine Ahnung hast - gerade vor solchen Leuten ist man ja nie gefeit.

shh · 18. Mai 2012

[Schmunzel]
> Du IT!? Dann spiele ich mal den IT-Babysitter

DU aber auf jeden Fall, oder? Wie alt bist du eigentlich?
Aber, kein Problem, ich kann gerade auch nicht schlafen, und die Kinder sind im Bett - OPTIMAL um Sachen neu einzurichten...
- und du weißt GENAU was man von solch passenden Kommentaren gebrauchen kann...

p.s.
BOAH: posts nachträglich bearbeiten is fies!

shh · 18. Mai 2012

DaKilla>

Klar, heute - gestern - war Vatertag. Vielleicht hat man da einfach keine Lust. Du machst dir trotzdem die Mühe einen post mit NULL Inhalt zu formulieren?

DaKilla> Beruf: IT

Ja, ich auch. Deshalb kannst du dir auch gut vorstellen, was man von solchen unpassenden Kommentaren hält.

Grüße...

shh · 17. Mai 2012

Hi Kurt, danke für die Antwort!

Oje das ist ja sehr ernüchternd!
Die doppelte Ausgabe an die zwei event-devices ist ja im Grunde ein firmware-Fehler. Es ist sowieso lächerlich, dass bei einem IR-Port zwei event-devices angemeldet werden. Die letzte Firmware ist aber so alt, dass man aber nicht auf Bereinigungen hoffen kann...

Wie man best. X-hotplugging-Regeln abzuschalten kann, ist mir völlig unbekannt - deshalb die Frage.
Allerdings ginge es natürlich auch mit best. udev-Regeln, das event5 zum Schweigen zu bringen. Die Karte hängt ja immer an demselben PCIe-xyz-00123-Bus und müsste sich (teilweise) sperren lassen.

Hast du einen Link zu den udev-threads, wo udev-Regeln bzgl S480 diskutiert wurden? Ich habe mittlerweile soviel Irrelevantes gelesen, ich habe keine Ahnung, wonach ich suchen soll...

p.s.
Ich hab jetzt erst gesehen, dass du auch eine S480 hast. Ich habe eine v2.1, mir ist aber nicht klar, was da "neuer" ist. Hattest bzw hast du mit der mitgelieferten FB dasselbe Problem wie ich?

shh · 17. Mai 2012

Ubuntu 11.10, Kernel 3.0, xorg-server 2:1.10.4-1ubuntu4.2

Karte: TeVii S480, doppel DVB-S2, ein IR-Stecker hinten, aber 2(!) event-devices dafür

Hallo,
bin mir nicht sicher ob dies schon gelöst wurde - für mich jedenfalls noch nicht. Alles was ich diesbzgl über "doppelte" codes gelesen habe hatte immer etwas mit "zuviel" codes der Fernbedienung (FB) zutun, also nur eine zu hohe repeat- bzw die Aufnahme-Rate.
Das Problem hier:
Die TeVii S480 hat einen IR-port hinten, wo ich den mitgelieferten Empfänger eingesteckt habe. Die mitgelieferte FB funktioniert damit wunderbar. Das kann man zB testen, wenn man LIRC auf das kernel-event-dev konfiguriert und dann mit irw testet.
LIRC habe ich aber wieder abgeschaltet, sonst hätte ich unter X 3(!) Eingaben derselben Fernbedienung.

Code

evtest:
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  	Power Button
/dev/input/event1:  	Power Button
/dev/input/event2:  	AT Translated Set 2 keyboard
/dev/input/event3:  	Logitech Logitech USB Optical Mouse
/dev/input/event4:  	IR-receiver inside an USB DVB receiver
/dev/input/event5:  	IR-receiver inside an USB DVB receiver

Jetzt ist's so, dass beim Drücken auf die FB die IR-codes einfach an beide(!) event-devices (event4 und event5) gesendet werden.
X erkennt wegen udev und hotplugging diese 2 Eingabegeräte und nimmt somit immer doppelte Eingaben an.
Wie kann man X dazu bringen, dass zB /dev/input/event5 einfach ignoriert wird?

dmesg-Auszug:

Code

[   12.254518] IR NEC protocol handler initialized
[   12.300676] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware
[   12.318280] IR RC5(x) protocol handler initialized
[   12.333277] IR RC6 protocol handler initialized
[   12.382549] IR JVC protocol handler initialized
[   12.399129] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
[   12.399137] dw2102: start downloading DW210X firmware
[   12.400635] IR Sony protocol handler initialized
[   12.419094] lirc_dev: IR Remote Control driver registered, major 250
[   12.420998] IR LIRC bridge handler initialized
[   12.552069] dvb-usb: found a 'TeVii S660 USB' in warm state.
[   12.552211] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[   12.552630] DVB: registering new adapter (TeVii S660 USB)
[   12.562190] HDA Intel 0000:00:08.0: power state changed by ACPI to D0
[   12.562204] HDA Intel 0000:00:08.0: power state changed by ACPI to D0
[   12.562734] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 21
[   12.562765] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] -> GSI 21 (level, low) -> IRQ 21
[   12.562774] hda_intel: Disabling MSI
[   12.562860] HDA Intel 0000:00:08.0: setting latency timer to 64
[   12.662215] nvidia: module license 'NVIDIA' taints kernel.
[   12.662223] Disabling lock debugging due to kernel taint
[   12.850407] dvb-usb: MAC address: 00:18:bd:5a:d6:fe
[   16.245568] DS3000 chip version: 0.192 attached.
[   16.245953] dw2102: Attached ds3000+ds2020!
[   16.245956]
[   16.245965] DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)...
[   16.248800] input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:0c.0/0000:02:00.1/usb2/2-1/input/input4
[   16.249415] dvb-usb: schedule remote query interval to 150 msecs.
[   16.249432] dvb-usb: TeVii S660 USB successfully initialized and connected.
[   16.249500] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware
[   16.255781] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
[   16.255793] dw2102: start downloading DW210X firmware
[   16.412062] dvb-usb: found a 'TeVii S660 USB' in warm state.
[   16.412228] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[   16.412842] DVB: registering new adapter (TeVii S660 USB)
[   16.619527] ACPI: PCI Interrupt Link [LPMU] enabled at IRQ 20
[   16.619576] nvidia 0000:00:03.5: PCI INT B -> Link[LPMU] -> GSI 20 (level, low) -> IRQ 20
[   16.620473] ACPI: PCI Interrupt Link [SGRU] enabled at IRQ 23
[   16.620494] nvidia 0000:01:00.0: PCI INT A -> Link[SGRU] -> GSI 23 (level, low) -> IRQ 23
[   16.620519] nvidia 0000:01:00.0: setting latency timer to 64
[   16.620533] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[   16.621584] NVRM: loading NVIDIA UNIX x86 Kernel Module  280.13  Wed Jul 27 16:55:43 PDT 2011
[   16.656429] type=1400 audit(1337251980.841:2): apparmor="STATUS" operation="profile_load" name="/sbin/dhclient" pid=738 comm="apparmor_parser"
[   16.657862] type=1400 audit(1337251980.841:3): apparmor="STATUS" operation="profile_load" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=738 comm="apparmor_parser"
[   16.658783] type=1400 audit(1337251980.841:4): apparmor="STATUS" operation="profile_load" name="/usr/lib/connman/scripts/dhclient-script" pid=738 comm="apparmor_parser"
[   16.660776] type=1400 audit(1337251980.845:5): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=770 comm="apparmor_parser"
[   16.660802] type=1400 audit(1337251980.845:6): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=748 comm="apparmor_parser"
[   16.662338] type=1400 audit(1337251980.845:7): apparmor="STATUS" operation="profile_replace" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=748 comm="apparmor_parser"
[   16.662365] type=1400 audit(1337251980.845:8): apparmor="STATUS" operation="profile_replace" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=770 comm="apparmor_parser"
[   16.663322] type=1400 audit(1337251980.845:9): apparmor="STATUS" operation="profile_replace" name="/usr/lib/connman/scripts/dhclient-script" pid=748 comm="apparmor_parser"
[   16.663348] type=1400 audit(1337251980.845:10): apparmor="STATUS" operation="profile_replace" name="/usr/lib/connman/scripts/dhclient-script" pid=770 comm="apparmor_parser"
[   16.710791] dvb-usb: MAC address: 00:18:bd:5a:d6:ff
[   16.717695] DS3000 chip version: 0.192 attached.
[   16.718030] dw2102: Attached ds3000+ds2020!
[   16.718034]
[   16.718046] DVB: registering adapter 1 frontend 0 (Montage Technology DS3000/TS2020)...
[   16.719595] input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:0c.0/0000:02:00.3/usb3/3-1/input/input5
[   16.720170] dvb-usb: schedule remote query interval to 150 msecs.
[   16.720186] dvb-usb: TeVii S660 USB successfully initialized and connected.
[   16.720378] usbcore: registered new interface driver dw2102

Alles anzeigen

Xorg.0.log:

Code

[	18.842]
X.Org X Server 1.10.4
Release Date: 2011-08-19
[	18.842] X Protocol Version 11, Revision 0
[	18.842] Build Operating System: Linux 2.6.24-29-server i686 Ubuntu
[	18.843] Current Operating System: Linux xbmc 3.0.0-19-generic #33-Ubuntu SMP Thu Apr 19 19:05:57 UTC 2012 i686
[	18.843] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.0.0-19-generic root=UUID=c524f9db-051d-4dcc-b071-1ea4262623e6 ro quiet splash vt.handoff=7
[	18.843] Build Date: 19 October 2011  05:09:41AM
[	18.843] xorg-server 2:1.10.4-1ubuntu4.2 (For technical support please see http://www.ubuntu.com/support)
[	18.843] Current version of pixman: 0.22.2
[	18.843]	Before reporting problems, check http://wiki.x.org
    	to make sure that you have the latest version.
[	18.843] Markers: (--) probed, (**) from config file, (==) default setting,
    	(++) from command line, (!!) notice, (II) informational,
    	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[	18.843] (==) Log file: "/var/log/Xorg.0.log", Time: Thu May 17 12:53:03 2012
[	18.849] (==) Using config file: "/etc/X11/xorg.conf"
[	18.849] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[	18.859] (==) ServerLayout "Layout0"
[	18.859] (**) |-->Screen "Screen0" (0)
[	18.859] (**) |   |-->Monitor "Monitor0"
[	18.859] (**) |   |-->Device "Device0"
[	18.859] (**) |-->Input Device "Keyboard0"
[	18.859] (**) |-->Input Device "Mouse0"
[	18.860] (==) Automatically adding devices
[	18.860] (==) Automatically enabling devices
[	18.870] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[	18.870]	Entry deleted from font path.
[	18.870] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[	18.870]	Entry deleted from font path.
[	18.870] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[	18.870]	Entry deleted from font path.
[	18.871] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[	18.871]	Entry deleted from font path.
[	18.871] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[	18.871]	Entry deleted from font path.
[	18.878] (==) FontPath set to:
    	/usr/share/fonts/X11/misc,
    	/usr/share/fonts/X11/Type1,
    	/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
    	built-ins
[	18.878] (==) ModulePath set to "/usr/lib/i386-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[	18.878] (**) Extension "Composite" is disabled
[	18.879] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[	18.879] (WW) Disabling Keyboard0
[	18.879] (WW) Disabling Mouse0
[	18.879] (II) Loader magic: 0x823ada0
[	18.879] (II) Module ABI versions:
[	18.879]	X.Org ANSI C Emulation: 0.4
[	18.879]	X.Org Video Driver: 10.0
[	18.879]	X.Org XInput driver : 12.3
[	18.879]	X.Org Server Extension : 5.0
[	18.881] (--) PCI:*(0:1:0:0) 10de:087d:1849:087d rev 177, Mem @ 0xfb000000/16777216, 0xe0000000/268435456, 0xf8000000/33554432, I/O @ 0x0000ec00/128, BIOS @ 0x????????/131072
[	18.882] (II) Open ACPI successful (/var/run/acpid.socket)
[	18.882] (II) LoadModule: "extmod"
[	18.888] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[	18.892] (II) Module extmod: vendor="X.Org Foundation"
[	18.892]	compiled for 1.10.4, module version = 1.0.0
[	18.892]	Module class: X.Org Server Extension
[	18.892]	ABI class: X.Org Server Extension, version 5.0
[	18.892] (II) Loading extension MIT-SCREEN-SAVER
[	18.892] (II) Loading extension XFree86-VidModeExtension
[	18.892] (II) Loading extension XFree86-DGA
[	18.893] (II) Loading extension DPMS
[	18.893] (II) Loading extension XVideo
[	18.893] (II) Loading extension XVideo-MotionCompensation
[	18.893] (II) Loading extension X-Resource
[	18.893] (II) LoadModule: "dbe"
[	18.894] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[	18.896] (II) Module dbe: vendor="X.Org Foundation"
[	18.896]	compiled for 1.10.4, module version = 1.0.0
[	18.896]	Module class: X.Org Server Extension
[	18.896]	ABI class: X.Org Server Extension, version 5.0
[	18.896] (II) Loading extension DOUBLE-BUFFER
[	18.896] (II) LoadModule: "glx"
[	18.896] (II) Loading /usr/lib/i386-linux-gnu/xorg/extra-modules/extra-modules.dpkg-tmp/libglx.so
[	20.361] (II) Module glx: vendor="NVIDIA Corporation"
[	20.375]	compiled for 4.0.2, module version = 1.0.0
[	20.375]	Module class: X.Org Server Extension
[	20.375] (II) NVIDIA GLX Module  280.13  Wed Jul 27 17:14:51 PDT 2011
[	20.375] (II) Loading extension GLX
[	20.375] (II) LoadModule: "record"
[	20.376] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[	20.920] (II) Module record: vendor="X.Org Foundation"
[	20.920]	compiled for 1.10.4, module version = 1.13.0
[	20.920]	Module class: X.Org Server Extension
[	20.920]	ABI class: X.Org Server Extension, version 5.0
[	20.920] (II) Loading extension RECORD
[	20.920] (II) LoadModule: "dri"
[	20.921] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
[	20.939] (II) Module dri: vendor="X.Org Foundation"
[	20.939]	compiled for 1.10.4, module version = 1.0.0
[	20.939]	ABI class: X.Org Server Extension, version 5.0
[	20.939] (II) Loading extension XFree86-DRI
[	20.939] (II) LoadModule: "dri2"
[	20.940] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
[	20.944] (II) Module dri2: vendor="X.Org Foundation"
[	20.944]	compiled for 1.10.4, module version = 1.2.0
[	20.944]	ABI class: X.Org Server Extension, version 5.0
[	20.944] (II) Loading extension DRI2
[	20.944] (II) LoadModule: "nvidia"
[	20.944] (II) Loading /usr/lib/i386-linux-gnu/xorg/extra-modules/extra-modules.dpkg-tmp/nvidia_drv.so
[	20.973] (II) Module nvidia: vendor="NVIDIA Corporation"
[	20.973]	compiled for 4.0.2, module version = 1.0.0
[	20.973]	Module class: X.Org Video Driver
[	20.990] (II) NVIDIA dlloader X Driver  280.13  Wed Jul 27 16:57:12 PDT 2011
[	20.994] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[	20.998] (++) using VT number 7


[	21.003] (II) Loading sub module "fb"
[	21.003] (II) LoadModule: "fb"
[	21.008] (II) Loading /usr/lib/xorg/modules/libfb.so
[	21.013] (II) Module fb: vendor="X.Org Foundation"
[	21.013]	compiled for 1.10.4, module version = 1.0.0
[	21.013]	ABI class: X.Org ANSI C Emulation, version 0.4
[	21.013] (II) Loading sub module "wfb"
[	21.014] (II) LoadModule: "wfb"
[	21.014] (II) Loading /usr/lib/xorg/modules/libwfb.so
[	21.021] (II) Module wfb: vendor="X.Org Foundation"
[	21.021]	compiled for 1.10.4, module version = 1.0.0
[	21.021]	ABI class: X.Org ANSI C Emulation, version 0.4
[	21.021] (II) Loading sub module "ramdac"
[	21.021] (II) LoadModule: "ramdac"
[	21.021] (II) Module "ramdac" already built-in
[	21.034] (II) Loading /usr/lib/i386-linux-gnu/xorg/extra-modules/extra-modules.dpkg-tmp/nvidia_drv.so
[	21.034] (II) Loading /usr/lib/xorg/modules/libwfb.so
[	21.034] (II) Loading /usr/lib/xorg/modules/libfb.so
[	21.045] (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
[	21.045] (==) NVIDIA(0): RGB weight 888
[	21.045] (==) NVIDIA(0): Default visual is TrueColor
[	21.045] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
[	21.045] (**) NVIDIA(0): Option "NoLogo" "True"
[	21.045] (**) NVIDIA(0): Option "HWcursor" "Off"
[	21.046] (**) NVIDIA(0): Option "FlatPanelProperties" "Scaling = Native"
[	21.046] (**) NVIDIA(0): Option "DynamicTwinView" "False"
[	24.309] (II) NVIDIA(GPU-0): Display (ONK TX-SR507 (DFP-1)) does not support NVIDIA 3D
[	24.711] (II) NVIDIA(GPU-0): 	Vision stereo.
[	25.226] (II) NVIDIA(0): NVIDIA GPU ION (C79) at PCI:1:0:0 (GPU-0)
[	25.226] (--) NVIDIA(0): Memory: 524288 kBytes
[	25.227] (--) NVIDIA(0): VideoBIOS: 62.79.78.00.00
[	25.227] (--) NVIDIA(0): Interlaced video modes are supported on this GPU
[	25.227] (--) NVIDIA(0): Connected display device(s) on ION at PCI:1:0:0
[	25.227] (--) NVIDIA(0): 	ONK TX-SR507 (DFP-1)
[	25.227] (--) NVIDIA(0): ONK TX-SR507 (DFP-1): 165.0 MHz maximum pixel clock
[	25.227] (--) NVIDIA(0): ONK TX-SR507 (DFP-1): Internal Single Link TMDS
[	25.231] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID has been
[	25.231] (**) NVIDIA(0): 	enabled on all display devices.
[	25.382] (II) NVIDIA(0): Assigned Display Device: DFP-1
[	25.382] (==) NVIDIA(0):
[	25.382] (==) NVIDIA(0): No modes were requested; the default mode "nvidia-auto-select"
[	25.382] (==) NVIDIA(0): 	will be used as the requested mode.
[	25.382] (==) NVIDIA(0):
[	25.382] (II) NVIDIA(0): Validated modes:
[	25.382] (II) NVIDIA(0): 	"nvidia-auto-select"
[	25.382] (II) NVIDIA(0): Virtual screen size determined to be 1920 x 1080
[	25.421] (--) NVIDIA(0): DPI set to (304, 304); computed from "UseEdidDpi" X config
[	25.421] (--) NVIDIA(0): 	option
[	25.421] (--) Depth 24 pixmap format is 32 bpp
[	25.421] (II) NVIDIA: Using 768.00 MB of virtual memory for indirect memory access.
[	25.430] (II) NVIDIA(0): Setting mode "nvidia-auto-select"
[	25.757] (II) Loading extension NV-GLX
[	26.988] (==) NVIDIA(0): Disabling shared memory pixmaps
[	26.988] (==) NVIDIA(0): Backing store disabled
[	26.988] (==) NVIDIA(0): Silken mouse enabled
[	26.995] (**) NVIDIA(0): DPMS enabled
[	26.995] (II) Loading extension NV-CONTROL
[	26.996] (II) Loading extension XINERAMA
[	26.996] (II) Loading sub module "dri2"
[	26.996] (II) LoadModule: "dri2"
[	26.997] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
[	26.997] (II) Module dri2: vendor="X.Org Foundation"
[	26.997]	compiled for 1.10.4, module version = 1.2.0
[	26.997]	ABI class: X.Org Server Extension, version 5.0
[	26.997] (II) NVIDIA(0): [DRI2] Setup complete
[	26.997] (==) RandR enabled
[	26.997] (II) Initializing built-in extension Generic Event Extension
[	26.997] (II) Initializing built-in extension SHAPE
[	26.997] (II) Initializing built-in extension MIT-SHM
[	26.997] (II) Initializing built-in extension XInputExtension
[	26.997] (II) Initializing built-in extension XTEST
[	26.997] (II) Initializing built-in extension BIG-REQUESTS
[	26.997] (II) Initializing built-in extension SYNC
[	26.997] (II) Initializing built-in extension XKEYBOARD
[	26.997] (II) Initializing built-in extension XC-MISC
[	26.997] (II) Initializing built-in extension SECURITY
[	26.997] (II) Initializing built-in extension XINERAMA
[	26.997] (II) Initializing built-in extension XFIXES
[	26.998] (II) Initializing built-in extension RENDER
[	26.998] (II) Initializing built-in extension RANDR
[	26.998] (II) Initializing built-in extension COMPOSITE
[	26.998] (II) Initializing built-in extension DAMAGE
[	26.998] (II) Initializing built-in extension GESTURE
[	27.007] (II) Initializing extension GLX
[	27.154] (II) XKB: reuse xkmfile /var/lib/xkb/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm
[	27.184] (II) config/udev: Adding input device Power Button (/dev/input/event1)
[	27.184] (**) Power Button: Applying InputClass "evdev keyboard catchall"
[	27.184] (II) LoadModule: "evdev"
[	27.185] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[	27.223] (II) Module evdev: vendor="X.Org Foundation"
[	27.223]	compiled for 1.10.2, module version = 2.6.0
[	27.223]	Module class: X.Org XInput Driver
[	27.223]	ABI class: X.Org XInput driver, version 12.3
[	27.223] (II) Using input driver 'evdev' for 'Power Button'
[	27.223] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[	27.223] (**) Power Button: always reports core events
[	27.223] (**) Power Button: Device: "/dev/input/event1"
[	27.224] (--) Power Button: Found keys
[	27.224] (II) Power Button: Configuring as keyboard
[	27.224] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1"
[	27.224] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
[	27.224] (**) Option "xkb_rules" "evdev"
[	27.224] (**) Option "xkb_model" "pc105"
[	27.224] (**) Option "xkb_layout" "de"
[	27.233] (II) XKB: reuse xkmfile /var/lib/xkb/server-808BBA3D4C227BDB44C370226C34E44C5D69A4A9.xkm
[	27.254] (II) config/udev: Adding input device Power Button (/dev/input/event0)
[	27.254] (**) Power Button: Applying InputClass "evdev keyboard catchall"
[	27.254] (II) Using input driver 'evdev' for 'Power Button'
[	27.254] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[	27.254] (**) Power Button: always reports core events
[	27.254] (**) Power Button: Device: "/dev/input/event0"
[	27.254] (--) Power Button: Found keys
[	27.254] (II) Power Button: Configuring as keyboard
[	27.254] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0/event0"
[	27.255] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
[	27.255] (**) Option "xkb_rules" "evdev"
[	27.255] (**) Option "xkb_model" "pc105"
[	27.255] (**) Option "xkb_layout" "de"
[	27.268] (II) config/udev: Adding input device Logitech Logitech USB Optical Mouse (/dev/input/event3)
[	27.268] (**) Logitech Logitech USB Optical Mouse: Applying InputClass "evdev pointer catchall"
[	27.268] (II) Using input driver 'evdev' for 'Logitech Logitech USB Optical Mouse'
[	27.268] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[	27.268] (**) Logitech Logitech USB Optical Mouse: always reports core events
[	27.268] (**) Logitech Logitech USB Optical Mouse: Device: "/dev/input/event3"
[	27.269] (--) Logitech Logitech USB Optical Mouse: Found 3 mouse buttons
[	27.269] (--) Logitech Logitech USB Optical Mouse: Found scroll wheel(s)
[	27.269] (--) Logitech Logitech USB Optical Mouse: Found relative axes
[	27.269] (--) Logitech Logitech USB Optical Mouse: Found x and y relative axes
[	27.269] (II) Logitech Logitech USB Optical Mouse: Configuring as mouse
[	27.269] (II) Logitech Logitech USB Optical Mouse: Adding scrollwheel support
[	27.269] (**) Logitech Logitech USB Optical Mouse: YAxisMapping: buttons 4 and 5
[	27.269] (**) Logitech Logitech USB Optical Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[	27.269] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:04.0/usb6/6-3/6-3:1.0/input/input3/event3"
[	27.269] (II) XINPUT: Adding extended input device "Logitech Logitech USB Optical Mouse" (type: MOUSE)
[	27.269] (II) Logitech Logitech USB Optical Mouse: initialized for relative axes.
[	27.269] (**) Logitech Logitech USB Optical Mouse: (accel) keeping acceleration scheme 1
[	27.269] (**) Logitech Logitech USB Optical Mouse: (accel) acceleration profile 0
[	27.269] (**) Logitech Logitech USB Optical Mouse: (accel) acceleration factor: 2.000
[	27.269] (**) Logitech Logitech USB Optical Mouse: (accel) acceleration threshold: 4
[	27.270] (II) config/udev: Adding input device Logitech Logitech USB Optical Mouse (/dev/input/mouse0)
[	27.270] (II) No input driver/identifier specified (ignoring)
[	27.283] (II) config/udev: Adding input device IR-receiver inside an USB DVB receiver (/dev/input/event4)
[	27.283] (**) IR-receiver inside an USB DVB receiver: Applying InputClass "evdev keyboard catchall"
[	27.283] (II) Using input driver 'evdev' for 'IR-receiver inside an USB DVB receiver'
[	27.283] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[	27.283] (**) IR-receiver inside an USB DVB receiver: always reports core events
[	27.284] (**) IR-receiver inside an USB DVB receiver: Device: "/dev/input/event4"
[	27.284] (--) IR-receiver inside an USB DVB receiver: Found keys
[	27.284] (II) IR-receiver inside an USB DVB receiver: Configuring as keyboard
[	27.284] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:0c.0/0000:02:00.1/usb2/2-1/input/input4/event4"
[	27.284] (II) XINPUT: Adding extended input device "IR-receiver inside an USB DVB receiver" (type: KEYBOARD)
[	27.284] (**) Option "xkb_rules" "evdev"
[	27.284] (**) Option "xkb_model" "pc105"
[	27.284] (**) Option "xkb_layout" "de"
[	27.289] (II) config/udev: Adding input device IR-receiver inside an USB DVB receiver (/dev/input/event5)
[	27.290] (**) IR-receiver inside an USB DVB receiver: Applying InputClass "evdev keyboard catchall"
[	27.290] (II) Using input driver 'evdev' for 'IR-receiver inside an USB DVB receiver'
[	27.290] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[	27.290] (**) IR-receiver inside an USB DVB receiver: always reports core events
[	27.290] (**) IR-receiver inside an USB DVB receiver: Device: "/dev/input/event5"
[	27.290] (--) IR-receiver inside an USB DVB receiver: Found keys
[	27.290] (II) IR-receiver inside an USB DVB receiver: Configuring as keyboard
[	27.290] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:0c.0/0000:02:00.3/usb3/3-1/input/input5/event5"
[	27.290] (II) XINPUT: Adding extended input device "IR-receiver inside an USB DVB receiver" (type: KEYBOARD)
[	27.290] (**) Option "xkb_rules" "evdev"
[	27.290] (**) Option "xkb_model" "pc105"
[	27.290] (**) Option "xkb_layout" "de"
[	27.298] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event2)
[	27.299] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall"
[	27.299] (II) Using input driver 'evdev' for 'AT Translated Set 2 keyboard'
[	27.299] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[	27.299] (**) AT Translated Set 2 keyboard: always reports core events
[	27.299] (**) AT Translated Set 2 keyboard: Device: "/dev/input/event2"
[	27.299] (--) AT Translated Set 2 keyboard: Found keys
[	27.299] (II) AT Translated Set 2 keyboard: Configuring as keyboard
[	27.299] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio0/input/input2/event2"
[	27.299] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD)
[	27.299] (**) Option "xkb_rules" "evdev"
[	27.299] (**) Option "xkb_model" "pc105"
[	27.299] (**) Option "xkb_layout" "de"
[   424.124] (II) Open ACPI successful (/var/run/acpid.socket)

Alles anzeigen

xorg.conf:

Code

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 280.13  (buildmeister@swio-display-x86-rhel47-05.nvidia.com)  Wed Jul 27 17:18:55 PDT 2011


Section "ServerLayout"
	Identifier 	"Layout0"
	Screen  	0  "Screen0"
	InputDevice	"Keyboard0" "CoreKeyboard"
	InputDevice	"Mouse0" "CorePointer"
EndSection


Section "Files"
EndSection


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


Section "InputDevice"
	# generated from default
	Identifier 	"Keyboard0"
	Driver     	"kbd"
EndSection


Section "Monitor"
	Identifier 	"Monitor0"
	VendorName 	"Unknown"
	ModelName  	"Unknown"
	HorizSync   	28.0 - 33.0
	VertRefresh 	43.0 - 72.0
	Option     	"DPMS"
EndSection


Section "Device"
	Identifier 	"Device0"
	Driver     	"nvidia"
	VendorName 	"NVIDIA Corporation"
EndSection


Section "Screen"
	Option  	"HWCursor" "Off"
	Identifier 	"Screen0"
	Device     	"Device0"
	Monitor    	"Monitor0"
	DefaultDepth	24
	Option     	"NoLogo" "True"
	Option     	"DynamicTwinView" "False"
	Option     	"FlatPanelProperties" "Scaling = Native"
	SubSection 	"Display"
    	Depth   	24
	EndSubSection
EndSection


Section "Extensions"
	Option     	"Composite" "Disable"
EndSection

Alles anzeigen

shh · 12. Januar 2011

Vielen Dank für eure Einschätzungen!

Kompilier- und Bastelprobleme gibt's hier nicht. Ich hab hier ewig schon alles mögliche Linux-Zeugs laufen (ab SuSE 4.2 1996, später dann Debian und Konsorten, ab potato). Ich hab' nur nicht viel LUST mir alle möglichen patches zusammensuchen zu müssen, und damit dann quasi das ganze System nochmal zu übersetzen (Kernel, xorg, vdr + plugins). Hab ich zwar auch schon alles gemacht, ist aber NICHT LUSTIG, und eigentlich hab ich auch keine Zeit mehr dafür.

Hmm, wenn alles andere irgendwie nix ist, dann halt doch NVidia.

Ich habe jetzt mal was gewagtes zusammengewürfelt.
- ohne die PCI-Slots zu erhalten. Da ich eh ein neues Netzteil brauche, ist es nicht unbedingt sinnvoll mein altes Riesengehäuse zu erhalten.

- ASRock A330ION (das hat nur featureset B), kostet aber nur 100,-
- Digital Devices Cine S2 - Duale DVB-S2 HDTV (Rev. V5.5): 150,-
- 1-2GB (normales) DDR3 RAM
- Lüfter
- 3,5" WD EARS
...und Achtung, jetzt kommts... hier reinbauen:
ITX LC-Power LC-1300mi, 75W, Mini-ITX: 36,-

Kritische Punkte:
- Einbauhöhe der DVB-Karte (Löcher bohren müsste ich sowieso)
- 75W Netzteil

Fragen:
1. gibt's außer dem featureset B grundsätzlich am Board (bzw A330, ION1) etwas auszusetzen?
2. gibt's irgendwo Maße zu der DVB-Karte?
3. Wie knapp sind 75W für's Netzteil?
4. gibt's irgendwo Infos darüber, wie lange die DVB-Karte zum laden/entladen der Module braucht? Oder ist obige Karte vielleicht sowieso Mist?

shh · 11. Januar 2011

Tja, die Lotterie...
Die kenne ich doch! Ich hatte ja gehofft, dass Ihr mir die Wahrscheinlichkeiten etwas drücken könnt...

Wobei Platte+CPU eher sekundär sein dürfte. Wenn das BIOS 10sek für [irgendwas] prüfen braucht, kann wohl kaum ein Linux-System den Zeitverbrauch irgendwie wieder nivellieren.
...soll heißen, dass ich immer noch Erfahrungswerte benötige.

shh · 10. Januar 2011

Oje, das ist eigentlich das, was ich befüchtet habe (und VIELEN DANK für diesen wichtigen Hinweis!)
Genau solche Probleme gibt's ja schon seit Ewigkeiten. Ich meine, es dürfte jedem klar sein, dass 10x funktionierendes S3 nicht reicht, wenn er sich dann beim 11ten Mal aufhängt. So etwas treibt einen zur Weißglut.

Yepp, ich habe schon etliche threads zur GT210/220 und auch aktuellen Boards gelesen. Natürlich ist das temporal_spatial was Feines, allerdings ist das nicht wichtig, wenn viel andere Baustellen dann doch nicht ordentlich funktionieren.

Deshalb spechte ich (vielleicht etwas zu stark) auf eine Intel-Lösung, da da der Kernel-support außerordentlich ist (siehe KMP und 3D-hardware-support) => AMD und Nvidia brauchen immer ewig für Anpassungen, bei bei neuen Kerneln ist der Intel-support immer schon "so mit drin". Ich würde mir hier zumindest konstanten S3-support und aktuell unterstützte features erhoffen.

Mit den Bootzeiten hast du Recht. Ich hab noch nen extra Ubuntu 10.04-Server laufen, der ist mit den ASRock 330ION schon super schnell beim booten - sowas kennt man unter Debian gar nicht.
Allerdings startet der natürlich kein X, VDR und DVB-modules.
Aber vielleicht wäre neu booten mittlerweile tatsächlich verschmerzbar; da müsste man wieder konkrete Boot-Zeiten vergleichen.
Das mit DVB-Module laden/entladen kenne ich schon, das dauert _einige_ Zeit. Ich hatte nur gehofft, dass man die nach 7 Jahren vielleicht doch einfach so einfrieren kann.
Wie schnell sind da Windows-Systeme eigentlich ? Für Win7 gibt's ja vorgegebene (mindest-)Aufwachzeiten. Dauert das da das Aufwachen auch so lang?

shh · 10. Januar 2011

> Normal geht der VDR in den Wakeup und ist dann ganz aus.

Was meinst du damit? Ich verwende zZ NVRAM-wakeup auf nem ASUS-Board. Der VDR kann die Zeiten programmieren und schaltet dann direkt aus (das BIOS muss hier nichtmal rebooten, damit der wakeup-timer läuft). Funktionierende wakeup-timer und funktionierendes S3 sind aber zwei paar Stiefel.

Aha, Stromverbrauch auf i3-Plattform niedriger.
Wie ich gerade gelesen habe, soll XBMC seit Dezember VAAPI unterstützen. Ist natürlich noch nicht in einer Distri drin(Debian unstable vielleicht), allerdings wären damit auch die Intel-Chipsätze bald out-of-the-box unterstützt, ohne, dass mit "hacker-patches" rumhantiert werden muss.

Ich weiß, dass es noch tausend andere Fallstricke gibt, die beachtet werden müssen - hab ja schon nen VDR seit Ewigkeiten. Ich würde aber gerne die Hauptmankos diesmal ausmerzen.
Fallstricke, die ich später noch abchecken wollte:
- Gesamtlautstärke
- BIOS-bootzeit
- Umschaltzeiten
- ...
Stromverbrauch ist mir eigentlich nur wichtig wg Verlustleistung -> mehr Lüftungsbedarf -> lauter
Der VDR steht bei mir im Schlafzimmer und muss daher seeeehr leise sein.

Seit langem stört mich die Bootzeit meiner Kiste, und S3 - mit dem yaVDR wirbt - wäre doch super!
Zusätzliches Problem ist, dass ich gerade auch festgestellt habe, dass ich noch ein neues Netzteil brauche (das alte hat leider nur 20pins). Also muss ich schon überlegen, ob nicht gleich ein kleines Gehäuse (ITX) mit Passivnetzteil besser/leiser wäre.

Wenn ich gleich eine IGP-Lösung verwende mit einer PCIe-TwinDVB, könnte man das Ganze sehr klein und effektiv gestalten - wenn denn alles funktioniert.
Leider sind die VDR-Wikis recht alt und man braucht für jede Info einen Erfahrungsbericht mit "Ja, das geht!".
Und gerade bei Linux sind solche Meldungen wichtig, weil alle nicht vorhandenen Berichte so viel heißen, wie "GEHT NICHT!"

Grüße...

shh · 9. Januar 2011

Danke für die Infos!

Bei VP4 (Featureset C) sind anscheinend DivX-Decodierung etc. dazu gekommen. Naja, würde ich nicht wirklich als wichtig bezeichnen, weil diese Kodierung kaum Rechenleistung beim decoden zieht (bzw nicht in den üblichen Auflösungen). Interessanter ist da schon die Aufhebung der Auflösungsbeschränkungen von H.264.

Spricht eigentlich etwas gegen einen Intel-IGP (z.B.: i3-530) in Verbindung mit VAAPI?
Abgesehen von
- fehlendem Deinterlacer (der temporal_spatial wird ja direkt in der Gforce ausgeführt, oder?)
- mehr Stromverbrauch der Intel-Plattform
...oder ist VAAPI einfach noch nicht fertig (zuviel Gebastel)?
Intel war die letzten Jahre super bzgl. Kernelunterstützung und Suspendverhalten.

shh · 9. Januar 2011

> Featureset C: mehr codecs

Uups, ich dachte die können sowieso "alles": MPEG2/4, H.264, VC1 etc. pp.
Wo kann man darüber etwas nachlesen?
Ich habe hier ein PDF: pure_video_hd_support.pdf von Nvidia, und da ist kein Unterschied bei den decoding-Fähigkeiten von nforce-Chipsätzen und normalen Grakas zu sehen. Auf einer anderen Wiki(?)-Seite habe ich auch nachgelesen, dass VDPAU-Fähigkeit mit PureVideoHD gleichzusetzen ist.
Mit besserem Deinterlacer meinte ich den "temporal_spatial". Da weiß ich aber noch nicht genau, welche Karten den unterstützen und ob das vielleicht einfach nur wegen der fehlenden Leistungsfähigkeit der IGPs nicht geht.

Eure (anscheinend S3-funktionierenden) Mainboards muss ich mir später noch mal genauer anschaun.
Bei S3 ist die Grafikkarte nicht mehr das Problem? Interessant.
Damit bin ich ein geschlagenes Kind und hatte mir irgendwann mal geschworen nie wieder nen proprietären Treiber anzufassen.

Den PCIe wollte ich eigentlich freihalten, um evtl. später ne TwinDVB-Karte reinzustecken.

shh · 9. Januar 2011

Hallo Stephan_84, danke für den Überblick.

Zunächstmal möchte ich noch anmerken, dass "Basteln" für mich grundsätzlich kein Problem ist. Allerdings möchte ich nicht mehr im Stile von VGA2SCART basteln (= patches für CVS-versionen, wobei letztere ständig ändern und man nach Wochen Gebastel merkt, dass es selbst mit einer "normalen" Distri nicht richtig läuft). Entwicklerpatches sollten also in absehbarer Zeit also auch standardmäßig integriert sein, sodass es keine Patches mehr braucht.
Wenn die Intel-Lösung nicht _jetzt_schon_ vollständig in allen subsystemen (kernel, xorg, xine) drin ist, besteht wenig Hoffnung, dass das in 6-9 Monaten "einfach läuft". Und ob S3 damit läuft, ist ohnehin unklar.

Ich wollte eigentlich nicht auf die PCI-Slots verzichten. Ansonsten müsste ich meine jetzigen Karten verschrotten und nen extra Twin-Tuner >120,- kaufen. Das wollte ich vermeiden, bzw in die Zukunft verschieben.

> Zotac Board aus der GeForce 9300er

Ist das ein ION-Board?
=> Sehr heiß (also Lüftung _doch_ nötig -> wo sind dann die Vorteile?), Wenig CPU-Leistung, keine/kaum Erweiterbarkeit. Hat das nen COM-Port?
(Wie bereits im Eingangspost beschrieben, wollte ich eben lieber kein ION-Board - außer es kann S3. Ich habe bereits ein genügend großes Gehäuse. Ich brauche keine bestimmte Boardgröße, nur 100%ige Funktionalität)

> Alternative ist dann ein aktuelles µATX Board mit einer GeForce GT210, wie schon häufig hier im Forum diskutiert.

Ich würde gerne eins mit im Chipsatz integrierter GPU haben, ohne extra Grafikkarte. Sonst ist der PCIe wieder zu, ebenso die Erweiterungsmöglichkeiten. Ich sehe auch bei allem Lesen noch nicht die echten Vorteile einer GT210.

Mein Hauptpunkt ist hier aber anscheinend übersehen worden: Ich möchte, dass Suspend-To-RAM läuft!
Ich habe mir die meisten empfohlenen Systeme hier schon angesehen mit allen ihren Vor- und Nachteilen.
Wo VDPAU anscheinend von der hardware-Unterstützung am weitesten ist, ist mir noch nicht klar, ob damit auch S3 läuft (Stichwort(e): closed-source-Treiber contra Kernelwechsel)
Erwähnt wird in den Listen, die ich gesehen habe, nur ACPI-wakeup, womit aber etwas anderes gemeint ist (timergesteuerte Aufnahmen).
Die standalone GeForce GT210 ist anscheinend recht leistungsfähig und kann einige deinterlace-Modi, die IGP-GeForces nicht können(?) - laut NVidia-Datenblatt allerdings schon......tja. Brauche ich denn den besseren deinterlacer?

Beiträge von shh

irmplircd für USB IR Remote Receiver (based on irmp)

irmplircd für USB IR Remote Receiver (based on irmp)

yaUsbIR V3 LIRC USB IR Empfänger/Sender/Einschalter

yaUsbIR V2 LIRC USB IR Empfänger/Sender/Einschalter

yaUsbIR V3 LIRC USB IR Empfänger/Sender/Einschalter

yaUsbIR V2 LIRC USB IR Empfänger/Sender/Einschalter

yaUsbIR V2 LIRC USB IR Empfänger/Sender/Einschalter

TeVii S480: Immer 2 event-devices unter X -> IR-Eingaben doppelt

TeVii S480: Immer 2 event-devices unter X -> IR-Eingaben doppelt

TeVii S480: Immer 2 event-devices unter X -> IR-Eingaben doppelt

TeVii S480: Immer 2 event-devices unter X -> IR-Eingaben doppelt

TeVii S480: Immer 2 event-devices unter X -> IR-Eingaben doppelt

TeVii S480: Immer 2 event-devices unter X -> IR-Eingaben doppelt

Mainboard mit voller HD-Beschleunigung und S3

Mainboard mit voller HD-Beschleunigung und S3

Mainboard mit voller HD-Beschleunigung und S3

Mainboard mit voller HD-Beschleunigung und S3

Mainboard mit voller HD-Beschleunigung und S3

Mainboard mit voller HD-Beschleunigung und S3

Mainboard mit voller HD-Beschleunigung und S3