CIR bzw. nuvoton-cir, Nachlaufen von Befehlen

    So, bin wieder zurück von yaUsbir. Leider immer mal wieder ist der Rechner komplett eingefroren, als ich die FB getätigt habe, das war mir zu oft. Nichts im Log. Irgendwo wurde gesagt, libusb wäre Schuld und ein Workaround
    aufgezeigt, aber leider nichts gebracht bei mir. Jedenfalls nicht zumutbar zu Hause.


    Nun zu CIR:


    Ich habe eine Verständnisfrage:


    Wie ich bereits schrieb, ist eine Taste nicht über ir-keytables gemappt ist, kein Nachlaufen, zumindest was nicht Harmony typisch wäre.
    Wer/Was genau wertete diese Tabelle aus?


    so steht doch in /etc/rc_maps.cfg


    Code
    nuvoton-cir rc-rc6-mce /mypath/rc-rc6-mce


    nuvoton-cir ist der Treiber. Wenn ohne Mapping, events korrekt ankommen, scheint der Treiber doch die Events korrekt zu liefern?


    Dann ist noch rc-rc6-mce Was genaus ist das? Auch eine Mapping oder eine lib oder was?


    Also jetzt habe ich das Gefühl, dass nuvoton-cir die IR Signale korrekt nach /dev/input/cirzb leitet. Wenn es darum geht (rc_mapping) die LIRC Keys zu produzieren mit key_up/down und hold, geht was schief.





    Gruß,
    Lado

    OK, gerade gesehen, dass es (rc-rc6-mce) ein Kernel Modul ist und auch von Jarod (leider, leider) stammt.

    Also mein Problem ist, dass ich nicht verstehe, was ändert sich wenn ich über rc-keytables das Mapping angeben oder nicht.
    Am besten würde ich den Code dazu mir anschauen, warum hier den Unterschied gibt -> CIR bzw. nuvoton-cir, Nachlaufen von Befehlen

    Hallo Leute,
    ist euch klar wie HID den "Autorepeat" macht? Zumindest bei normalen Tastaturen macht dies nicht mehr die Tastatur sondern der Rechner selbst (der HID-Treiber).
    Ich kann mich auch noch vage an Diskussionen in den "Device Working Groups" des USB erinnern (war so um 1997). Daher bin ich überzeugt dass dies der Grund fürs Nachlaufen ist.
    Man muss sich hier Fragen ob HID überhaupt für unsere Anwendung geeignet ist....


    Und zumindest meine Cine C2 oder deren Treiber macht die Reaktionen auf die FB erheblich langsamer. Bei mir ist es noch ein klassisches Lirc.
    Sobald die Cine eingebaut ist, ist die FB deutlich träger und läuft auch überhaupt nicht mehr gleichmäßig. Auch eine reines DVB1-System mit Budget+FF laufen nicht exakt gleichmäßig, aber doch besser.


    Übrigens: Lirc selbst (irw) wird durch die Cine nicht beeinflusst, dort kommen die Tastendrücke sofort an.

    Grüße, Dieter :)

    Zitat von Dieter

    Man muss sich hier Fragen ob HID überhaupt für unsere Anwendung geeignet ist....


    Deine Theorie hinkt etwas, denn die FB von MS-TECH MC-1200, welches ein reines HID ist, funktioniert perfekt und läuft überhaupt nicht nach.


    Albert

    Hallo,
    dann ist ja noch Hoffnung... ist die FB über USB angeschlossen? Wenn ja könnte man prüfen ob der Empfänger regelmäßig die HID-Reports abliefert. (ich habe Zugang zu einem Analyzer und kann auch damit umgehen).
    Wo gibt es diese FB/Empfänger zu kaufen?

    Grüße, Dieter :)

    Zitat von Dieter

    ist die FB über USB angeschlossen


    Klar.


    Zitat von Dieter

    Wenn ja könnte man prüfen ob der Empfänger regelmäßig die HID-Reports abliefert.


    Ja, zumindest sieht evtest sauber aus.


    Zitat von Dieter

    Wo gibt es diese FB/Empfänger zu kaufen?


    Kommt mit dem Gehäuse, separat wird sie nicht geben.


    Albert

    Ein klassiches HID-Gerät in dem Sinn ist ein CIR-Empfänger ja soweit ich weiß gar nicht.
    Neben dem mceusb-Geräten (USBCIR) stellt das CIR auf den Mainboards eine zweite Variante dar: http://msdn.microsoft.com/en-u…re/ff539443(v=vs.85).aspx
    Hier gibt es noch Informationen dazu:
    http://download.microsoft.com/…cf47d23cd/med001_wh06.ppt
    http://download.microsoft.com/…ication-03-08-2011-V2.pdf


    IMHO ist es ein Software-Problem, weil die Scancodes ja völlig korrekt ankommen, aber die Key-Events die über rc-core daraus generiert werden daneben liegen:

    Zitat von herrlado
    Code
    Event: time 1364695269.704980, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f0422
Event: time 1364695269.704980, -------------- SYN_REPORT ------------
Event: time 1364695269.715526, type 1 (EV_KEY), code 352 (KEY_OK), value 2
Event: time 1364695269.715526, -------------- SYN_REPORT ------------
Event: time 1364695269.840524, type 1 (EV_KEY), code 352 (KEY_OK), value 2
Event: time 1364695269.840524, -------------- SYN_REPORT ------------
Event: time 1364695269.954526, type 1 (EV_KEY), code 352 (KEY_OK), value 0

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von seahawk1986

    IMHO ist es ein Software-Problem


    Das ist es meiner Meinung nach auch. Deswegen habe ich geschrieben, dass es HID gibt, welches nicht betroffen ist. CIR mit HID gleich zu setzen wäre ein Fehler.


    Lado macht aber Fortschritte, das gibt Hoffnung. :thumbup:


    Albert

    seahawk1986


    Ja definitiv Software Problem, vermutlich hat nuvoton-cir nicht die Schuld.


    Also ich möchte nun den Ansatz verfolgen, dass in rc-core Modul was nicht stimmt, denn rc-rc6-mce Modul
    stellt bloẞ das Mapping bereit, da ist überhaupt keine Logik drin, so wie ich dem Code entnehmen kann. Das rc-core Modul kann man mit debug:int Laden.
    Ich würde es erst mal so probieren. Eventuell schreibe ich den Author auch an :)

    Gibt es schon etwas neues?

    VDR-Server: 1HE Barebone Supermicro 200 Watt, X7SPE-HF, 2 GB RAM, 320 GB HDD, 2 x Technisat Skystar USB HD, 1 x DVBSKy S952, yaVDR 0.6.1 Kernel 3.19 Headless
    Client 1: LC-Power LC-1400mi ITX Tower 200 Watt Klavierlack schwarz, ASRock E35LM1 AMD A50M, 2 GB RAM (Kingston ValueRAM DDR3), 1024MB Palit GeForce GT 520, 160 GB HDD, yaVDR 0.5.0
    Client 2: Raspberry PI, OpenElec

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden