Beiträge von holger_p.
-
-
Anbei. Sieht für mich mit event2 eigentlich okay aus.
cat /proc/bus/input/devices
Code
Alles anzeigenI: Bus=0003 Vendor=1d57 Product=ac01 Version=0110 N: Name="Mouse" P: Phys=usb-0000:00:02.0-6/input0 S: Sysfs=/devices/pci0000:00/0000:00:02.0/usb3/3-6/3-6:1.0/input/input2 U: Uniq= H: Handlers=sysrq kbd event2 B: PROP=0 B: EV=120013 B: KEY=1000000000007 ff800000000007ff febeffdfffefffff fffffffffffffffe B: MSC=10 B: LED=1f I: Bus=0003 Vendor=1d57 Product=ac01 Version=0110 N: Name="Mouse" P: Phys=usb-0000:00:02.0-6/input1 S: Sysfs=/devices/pci0000:00/0000:00:02.0/usb3/3-6/3-6:1.1/input/input3 U: Uniq= H: Handlers=kbd mouse0 event3 B: PROP=0 B: EV=1f B: KEY=837fff002c3027 bf00444400000000 1f001f c040b27c000 267bfad941dfed 9e000000000000 0 B: REL=143 B: ABS=7f0100000000 B: MSC=10
-
was wird denn dann bei den Tasten im evtest angezeigt? - die derzeitige 03_04b4_0101.evmap stammt ja aus meinen Tests und bei mir erkennt er alles so wie es soll...
- zeig doch mal bitte Deine Ausgabe der farbigen Tasten
Hi, pacha_muc!
Genau da stecke ich derzeit fest. Ich sehe an der IR-Diode (mit Handy-Cam und Kontroll-LED), dass die FB etwas sendet, aber mit evtest /dev/input/event2 sehe ich leider nichts.
Habe gerade noch mal getestet: Es fehlen mir noch die Farb-, die "Recorded TV" und die Menütaste (welche nimmst Du?). Sonst sieht es soweit gut aus. Ob die FB eine Macke hat?
<Grmpf>
P.S. So ganz identisch zu meiner MS-TECH FB/IR scheint eventlircd die evmap von Dir nicht umzusetzen. KEY_BACK funktioniert sauber ohne laufendes eventlircd Mapping; mit fehlt es.
-
nene - bleib bei der FB - die läuft (bei mir) super...
[...]Hallo, pacha_muc!
Kurz mal:
a) Wie funktioniert das bei Dir mit den Tasten Rot,Grün,Gelb,Blau?
b) Welche Taste benutzt Du für das Menü und Key_up, Key_down, Key_exit?Da der Empfänger im MC-380 identisch zum MC-1200 zu sein scheint und die FB ähnlich aussieht habe ich derzeit einen Knoten in meiner Suche/Recherche.
Bin hier mit meiner MC-1200 "Erkennung" momentan etwas durch, da diese "Keys" nicht übertragen/erkannt werden. Habe mit evtest schon einmal nachgeschaut.
Gruß,
Holger. -
Damit wird zumindest der IR-Receiver schon einmal erkannt und dass eventlircd Mapping geladen.
Mit sudo irw kannst Du bei laufendem eventlircd testen, was die FB "ge-mapped" sendet.
Sonst mal bei abgeschaltetem eventlircd - wie in anderen Threads hier schon mitgeteilt ein
sudo evtest /dev/input/eventX
wobei X=1,2,3,4,...
Falls Du nichts siehts, bin ich erst einmal raus.
Ansonsten mal frische Batterien in die FB rein.
Gruß.
-
Versuche einmal ein
sudo stop eventlircd
und dann mit
sudo /usr/sbin/eventlircd -vvv -f --repeat-filter --socket=/var/run/lirc/lircd
nachsehen, ob die korrekt evmap geladen wird. Bei mir sieht es bspw. so aus:
Codeeventlircd[4478]: /etc/eventlircd.d/03_1d57_ac01.evmap: using 30 valid keyboard shortcut mappings eventlircd[4478]: input device /dev/input/event2: events of unsupported event type EV_MSC will be discarded eventlircd[4478]: input device /dev/input/event2: event code 0x04 of unsupported event type EV_MSC will be discarded eventlircd[4478]: input device /dev/input/event2: unsupported event code 0x03 of event type EV_LED will be discarded eventlircd[4478]: input device /dev/input/event2: unsupported event code 0x04 of event type EV_LED will be discarded eventlircd[4478]: input device /dev/input/event2: events of unsupported event type EV_REP will be discarded eventlircd[4478]: input device /dev/input/event2: grabbed
Daran kannst Du erkennen, dass die /etc/eventlircd.d/03_1d57_ac01.evmap geladen werden kann.
Leider bringt Deine Aussage "immer noch nix" nicht so ganz Licht ins Dickicht, was derzeit nicht funktioniert.
-
Passiert nix.
wozi@ubuntu:~$ restart eventlircd
restart: Rejected send message, 1 matched rules; type="method_call", sender=":1.24" (uid=1000 pid=1977 comm="restart eventlircd ") interface="com.ubuntu.Upstart0_6.Job" member="Restart" error name="(unset)" requested_reply=0 destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init"))
dann reboot
immer noch nix - Neuinstallieren???sudo stop eventlircd; sudo start eventlircd
-
Da der Thread hier generell über MS-Tech handelt und Jürgen ggf. das Thema an seinem Gehäuse auch haben wird:
Meine Orig.FB sendet für die Tasten Rot,Grün,Gelb,Blau aber evtest /dev/input/event2 "erkennt" diese nicht. Wie kann ich das - am Ursprung - debuggen, warum das so ist? Die restlichen Tasten - außer die Cursorwippe (nur in Mausfunktion) - funktionieren.
-
sudo apt-get update && sudo apt-get dist-upgrade
Dann wird Dir das aktualisierte yavdr-remote zur Aktualisierung angeboten, wo hotzenplotz die Änderungen eingefügt hat.
-
sollte gleich mit dem nächsten yavdr-remote paket funktionieren:
https://github.com/yavdr/yavdr…ac18ee57bf62c4412bfa07c7d...und ich dachte, nichts kann schneller als das Licht sein...außer Neutronen in der Schweiz vielleicht und das yaVDR Team ganz sicher.
Danke,
Holger. -
...macht wahrscheinlich schon fast mehr Sinn, eine mstech.evmap anzulegen und in den 98-eventlircd.rules darauf zu verweisen.
Es ist (mir) derzeit nicht wirklich klar, wieviele Varianten von Empfängern MS-Tech in seinen unterschiedlichen Gehäusen/-Revisionen verbaut hat. Irgendwann gibt es in /etc/eventlirc.d vielleicht zu viel "Wildwuchs". Ich hoffe, die FBs variieren nicht auch noch...
Ansonsten ist das Thema Fernbedienbarkeit in yaVDR OOTB ein immenser Pflegeaufwand für das yaVDR Team - Chapeau.
-
Ich hatte befürchtet das du das sagst. Genau das bei mir geht nicht. Was muß ich in der yaVDR Configuration angeben?
lsusb gibt:
Bus 005 Device 004: ID 1d57:ac01Mainboard ASUS E35M1-M
Habe hier ein MS-Tech MC-1200 Rev. C. wo sich der IR-Empfänger ebenfalls mit der von Dir angegebenen ID meldet.
Bin aktuell hingegangen und habe in /lib/udev/rules.d/98-eventlircd.rules folgende Zeilen hinzugefügt:CodeENV{ID_VENDOR_ID}=="1d57", ENV{ID_MODEL_ID}=="ac01", \ ENV{eventlircd_enable}="true", \ ENV{eventlircd_evmap}="03_$env{ID_VENDOR_ID}_$env{ID_MODEL_ID}.evmap"
und mir in /etc/eventlirc.d/ die evmap Datei 03_04b4_0101.evmap als 03_1d57_ac01.evmap kopiert.
Soweit funktioniert es mit der Original-FBGruß,
Holger. -
N'Abend,
bei mir hat die Abschaltung ohne Veränderungen bis zum Kernel 2.6.38-10 funktioniert. Seit 2.6.38-11 ist das nicht mehr so. Ich werde wohl auch mal nach dem USB Jumper auf meinem MB suchen.
Gruß,
Holger. -
Hi, Obelix!
Hi. Also bei mir funktioniert das auch mit der /etc/init/shutdownfsck.conf nicht.
Ist bei mir auch so (aka "hängender" mountall Prozess). Ich werde mir jetzt mal yaVDR0.4 einrichten.
Gruß,
Holger. -
Hi,
schau mal unter diesem Thema nach fsck beim shutdown.
Ggf. fehlt Dir die /etc/init/shutdownfsck.conf.Die bekommst Du mit
sudo process-template /etc/init/shutdownfsck.conf
wieder hergestellt.Gruß,
Holger. -
Hallo,
habe auf einem anderen Ubuntu 10.04 mal einen Gegentest mit /forcefsck durchgeführt:
1. Die Datei ist nach einem Neustart inkl. fsck gelöscht.
2. Der mountall Prozess läuft dort nach dem Neustart nicht mehr.Also:
Warum läuft unter yaVDR mountall als Prozess weiter und beendet sich nicht, weshalb /forcefsck nicht gelöscht wird?Gruß,
Holger. -
Tach zusammen.
Ich habe die /forcefsck mal angelegt und dann nach einem Reboot (mit vielen Meldungen) ein sudo init S durchgeführt. Danach war die /forcefsck gelöscht.
P.S.: Ein kill auf den laufenden Prozess mountall funktioniert übrigens auch...
Gruß,
Holger. -
Hallo, Werner.
/etc/init/mountall.conf ist m.W. Bestandteil der Ubuntu-Distribution.
Die letzten Upgrades des mountall Paketes liefen bei mir im September 2010 ein. Ich habe das Problem aber erst seit diesem Jahr. Leider kann ich das nicht mehr genau terminieren. Damit scheidet vielleicht mountall.conf aus, bin mir aber nicht wirklich sicher.
Bin nun temporär hin und habe die beiden init-Skripte für den forcierten fsck deaktiviert. Jetzt hoffe ich, dass das shutdownfsck.conf den Check übernimmt.
Gruß,
Holger. -
N'abend.
Habe leider nun doch das reproduzierbare Problem, dass nach 24 Mounts (=max-mount-count) der yaVDR Systempartition die /forcefsck angelegt wird und dehalb beim Starten ständig ein fsck "mit den vielen Meldungen" ausgeführt wird.
Deshalb habe ich unter den Beiträgen in
Viele Meldungen auf dem Schirm beim Start von yavdr
eine Zusammenfassung dazu geschrieben.Tschüss,
Holger -
Hi, Bender0815!
Ohne detaillierte Ahnung von den Upstart Jobs zu haben fehlt Dir ggf. ein "script" im Skript
Also
CodeTruecrypt2tb description "Truecrypt Mount" author "Autor" start on starting vdr script truecrypt -t -p "password" --protect-hidden=no --non-interactive --fs-options="umask=0000" /dev/sdb1 /mnt/2tb end script
Vielleicht hilft Dir auch das "Upstart Cookbook" weiter (Links unter http://upstart.at/2011/06/17/cookbook-in-pdf/).
Sonst suche mal nach den Begriffen Upstart und Debug.P.S.: Ein solcher Beitrag ist sicherlich unter http://www.vdr-portal.de/board…rd68-debian-und-derivate/ besser aufgehoben.
Gruß,
Holger.