[Workaround] Ab Kernel 3.5 evtl. doppelter Tastendruck bei inputlirc & mceusb notwendig ...

fnu · 21. Juli 2013

Hi,

auf einem meiner VDRs habe ich das Problem, das mit Kerneln > 3.2.0 ich alle Tasten 2x drücken muß (mceusb). Das ist zuverlässig aber sehr nervig und scheinbar bei mir ein einzigartiges Problem. Bei lirc konnte man das verhalten mittels "toggle_bit_mask" in der lircd.conf beeinflussen.

Nun da wir input-/eventlirc nutzen müssen, stehe ich vor dem Problem, das es hier nichts entsprechendes gibt, oder ich finde es schlicht nicht. Hat hier jemand ein Tip für mich?

Ich möchte das wenn ich eine Taste drücke diese doppelt im inputlirc Stack ausgegeben werden ...

Regards
fnu

Keine_Ahnung · 21. Juli 2013

Das einfachste wäre es erstmal im entsprechenden Decoder Modul (rc_core, das Modul was rc6 decodiert) ne Debugmeldung einzubauen um zu schauen ob hier die Tastendrücke korrekt interpretiert werden. Der Code hier ist nicht so komplex -> https://git.kernel.org/cgit/li…media/rc/ir-rc6-decoder.c

Klingt jetzt evtl. etwas übertrieben, aber meiner Erfahrung nach ist das am Ende einfacher erstmal hier anzufangen (schauen ob der Kernel sinnige Sachen liefert) als blind in irgendwo der langen Kette rumzusuchen wo da was falsch läuft

Mit nem raw lirc Empfänger kannst du auch gut schauen welche Pulse deine FB sendet (und dann mit der Interpretation im Code vergleichen), evtl. sendet die ja schon Fehlerhaft?

cu

fnu · 21. Juli 2013

Keine_Ahnung

Eigentlich ist schon klar was falsch läuft, analysiert habe ich das schon ziemlich lange. Es gab hier auch entsprechende (Filter-)Änderung von der RedHat Saftnase die dafür verantwortlich zeichnet, leider will er nicht verraten wo im Code ich das wieder zurück ändern könnte.

Bisher konnte ich bei Kernel 3.2.0 verbleiben, nur für die neue Zotac GT 630 geht das nimmer, sonst gibts kein Ton via HDMI ...

Also nochmal ich suche den Hinweis, wie ich mit inputlirc Tasten doppelt ausgeben kann wenn ich sie drücke, keine Analyse Tips? Bei lircd konnte man es doch auch beeinflussen ...

Regards
fnu

seahawk1986 · 21. Juli 2013

Zitat von fnu

Also nochmal ich suche den Hinweis, wie ich mit inputlirc Tasten doppelt ausgeben kann wenn ich sie drücke, keine Analyse Tips?

Kannst du mal mit evtest auf dem Kernel Input Device für den mceusb-Empfäger schauen (ohne inputlircd), ob da zumindest die Scancodes für die Tasten korrekt bei einem einzelnen Tastendruck ausgegeben werden?

Da ich beim CIR-Empfänger das entgegengesetzte Problem habe, dass zu viele KEY-Events für einen Scancode generiert werden, habe ich da ein kleines Python-Skript dazwischen gehängt, dass allein die Scancodes auswertet und auf Wunsch einen Repeat-Filter dazwischen hängt.

fnu · 21. Juli 2013

Zitat von seahawk1986

Kannst du mal mit evtest auf dem Kernel Input Device für den mceusb-Empfäger schauen (ohne inputlircd), ob da zumindest die Scancodes für die Tasten korrekt bei einem einzelnen Tastendruck ausgegeben werden?

Ja, habe ich schon in 2012 gemacht gehabt evtl. erinnerst Du Dich, über das Problem hatten wir vor einiger Zeit immer mal wieder gesprochen gehabt ...

Mit lircd wurden traditionell bei mceusb die Tasten zweimal im System ausgegeben, wie bei vielen anderen FBs auch. Nun muß ich eine Taste 2x drücken, damit in "irw" das entsprechende Kommando 1x auftaucht.

TheChief · 21. Juli 2013

Und was kommt bei evtest bei einem Tastendruck? Garnichts?

fnu · 21. Juli 2013

Zitat von TheChief

Und was kommt bei evtest bei einem Tastendruck? Garnichts?

Genau das was kommen soll ... das wird danach irgendwo noch gefiltert ...

TheChief · 21. Juli 2013

Zitat von fnu

Genau das was kommen soll ... das wird danach irgendwo noch gefiltert ...

Versteh ich nicht ganz. evtest geht also "normal", nur input/eventlirc nicht? Eventuell mit der -r Option spielen?

fnu · 21. Juli 2013

Zitat von TheChief

Versteh ich nicht ganz. evtest geht also "normal", nur input/eventlirc nicht?

Was ist daran unverständlich?

Zitat von TheChief

Eventuell mit der -r Option spielen?

Diese Option wäre gegen etwaiges Tastenprellen, war z.B. bei der L4M Merlin immer nötig. Es ermöglicht mir nicht die Taste als "double issue" auszugeben, sondern verhindert dies ...

seahawk1986 · 21. Juli 2013

Zitat von fnu

Ja, habe ich schon in 2012 gemacht gehabt evtl. erinnerst Du Dich, über das Problem hatten wir vor einiger Zeit immer mal wieder gesprochen gehabt ...

Ja, ich habe aber nicht mehr genau im Kopf wie das damals ausgesehen hat und weiß mittlerweile ein bisschen mehr darüber was da so an Daten kommt und wie man das so auswerten kann, dass man das Verhalten bekommt, das man erwartet...

Mal zum Vergleich ein CIR-Empfänger:

http://www.vdr-portal.de/board18-vdr-hardware/board13-fernbedienungen/p1135723-cir-bzw-nuvoton-cir-nachlaufen-von-befehlen/#post1135723

Code

Event: time 1364695268.239525, -------------- SYN_REPORT ------------
Event: time 1364695268.840121, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f0422
Event: time 1364695268.840121, type 1 (EV_KEY), code 352 (KEY_OK), value 1
Event: time 1364695268.840121, -------------- SYN_REPORT ------------
Event: time 1364695268.944283, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f0422
Event: time 1364695268.944283, -------------- SYN_REPORT ------------
Event: time 1364695269.048450, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f0422
Event: time 1364695269.048450, -------------- SYN_REPORT ------------
Event: time 1364695269.150798, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f0422
Event: time 1364695269.150798, -------------- SYN_REPORT ------------
Event: time 1364695269.254423, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f0422
Event: time 1364695269.254423, -------------- SYN_REPORT ------------
Event: time 1364695269.340523, type 1 (EV_KEY), code 352 (KEY_OK), value 2
Event: time 1364695269.340523, -------------- SYN_REPORT ------------
Event: time 1364695269.371328, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f0422
Event: time 1364695269.371328, -------------- SYN_REPORT ------------
Event: time 1364695269.465526, type 1 (EV_KEY), code 352 (KEY_OK), value 2
Event: time 1364695269.465526, -------------- SYN_REPORT ------------
Event: time 1364695269.475453, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f0422
Event: time 1364695269.475453, -------------- SYN_REPORT ------------
Event: time 1364695269.579655, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f0422
Event: time 1364695269.579655, -------------- SYN_REPORT ------------
Event: time 1364695269.590526, type 1 (EV_KEY), code 352 (KEY_OK), value 2
Event: time 1364695269.590526, -------------- SYN_REPORT ------------
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

Alles anzeigen

Man sieht schön die MSC_SCAN Events mit dem Scancode der Taste (das ist das was der Treiber vom Empfänger bekommt) und die durch die durch die bescheidenen Mechanismen in rc-core generierten KEY-Events, die nicht ganz so recht dazu passen.

fnu · 21. Juli 2013

Dabei suche ich nur nach einer Möglichkeit inputlirc anzuweisen, die Keys doppelt auszugeben, die Codes stimmen doch, wie oft denn noch?

Gehe ich auf der selben Maschine, mit der selben HW auf Kernel 3.2.0 zurück, habe ich das korrekte Verhalten, ab 3.5.0 nicht. Nur, benötige ich jetzt für die neue Zotac GT 630 min. Kernel 3.8.0 ...

Bei lircd konnte man das Verhalten anpassen, mittels "toggle_bit_mask 0x800000[0|1]", was nur bei Spezialfällen nötig war, was meiner ja hier klar wäre ...

TheChief · 21. Juli 2013

Vielleicht doppelt in die entsprechende Keymap eintragen? Keine Ahnung ob das geht und was dann passiert.

Oder mittels ir-keytable versuchen:

Code

-D, --delay=DELAY
    Sets the delay before repeating a keystroke
-P, --period=PERIOD
    Sets the period to repeat a keystroke

So beispielsweise

Code

ir-keytable -D 1000 -P 1000 -c -p RC-6 -w /etc/rc_keymaps/rc6_mce

seahawk1986 · 21. Juli 2013

Zitat von fnu

Dabei suche ich nur nach einer Möglichkeit inputlirc anzuweisen, die Keys doppelt auszugeben, die Codes stimmen doch, wie oft denn noch?

Das ist doch gar nicht der Punkt... inputlircd macht ja mit einem KEY-Event das hier (in Zeile 59 im Spoiler bzw. 336 in der inputlircd.c schreibt er den Tastendruck an die Clients raus):

aus der inputlircd.c Zeile 278ff

Code

static void processevent(evdev_t *evdev, fd_set *permset) {
        struct input_event event;
        char message[1000];
        int len;
        client_t *client, *prev, *next;


        if(read(evdev->fd, &event, sizeof event) != sizeof event) {
                syslog(LOG_ERR, "Error processing event from %s: %s\n", evdev->name, strerror(errno));
                FD_CLR(evdev->fd, permset);
                close(evdev->fd);
                evdev->fd = -999;
                return;
        }


        if(event.type != EV_KEY)
                return;


        if(event.code > KEY_MAX || event.code < key_min)
                return;


        if(capture_modifiers) {
                if(event.code == KEY_LEFTCTRL || event.code == KEY_RIGHTCTRL) {
                        ctrl = !!event.value;
                        return;
                }
                if(event.code == KEY_LEFTSHIFT || event.code == KEY_RIGHTSHIFT) {
                        shift = !!event.value;
                        return;
                }
                if(event.code == KEY_LEFTALT || event.code == KEY_RIGHTALT) {
                        alt = !!event.value;
                        return;
                }
                if(event.code == KEY_LEFTMETA || event.code == KEY_RIGHTMETA) {
                        meta = !!event.value;
                        return;
                }
        }


        if(!event.value)
                return;


        struct timeval current;
        gettimeofday(&current, NULL);
        if(event.code == previous_event.code && time_elapsed(&previous_input, &current) < repeat_time)
                repeat++;
        else
                repeat = 0;


        if(KEY_NAME[event.code])
                len = snprintf(message, sizeof message, "%x %x %s%s%s%s%s %s\n", event.code, repeat, ctrl ? "CTRL_" : "", shift ? "SHIFT_" : "", alt ? "ALT_" : "", meta ? "META_" : "", KEY_NAME[event.code], evdev->name);
        else
                len = snprintf(message, sizeof message, "%x %x KEY_CODE_%d %s\n", event.code, repeat, event.code, evdev->name);


        previous_input = current;
        previous_event = event;


        for(client = clients; client; client = client->next) {
                if(write(client->fd, message, len) != len) {
                        close(client->fd);
                        client->fd = -1;
                }
        }


        for(prev = NULL, client = clients; client; client = next) {
                next = client->next;
                if(client->fd < 0) {


        for(prev = NULL, client = clients; client; client = next) {
                next = client->next;
                if(client->fd < 0) {
                        if(prev)
                                prev->next = client->next;
                        else
                                clients = client->next;
                        free(client);
                } else {
                        prev = client;
                }
        }
}

Alles anzeigen

Eventuell hilft es das doppelt zu machen (unter der Voraussetzung, dass die KEY-Events so gesendet werden, dass sie korrekt ausgewertet werden können). Wenn man die Scancodes direkt auswertet kann man das unabhängig von den mitunter unpraktischen Mechanismen für die Generierung von KEY-Events durch rc-core umsetzen.

TheChief · 22. Juli 2013

hat das eigentlich zu was geführt oder hast Du aufgegeben?

fnu · 22. Juli 2013

Nein, nicht aufgegeben, bin aber gestern lieber noch eine Runde durch den Schwarzwald gepfiffen ...

Das Problem ist existent, muß also gelöst werden. Bin mir aber nimmer sicher das doppelt senden per inputlirc was bringt, weil das ja ab einem gewissen Entwicklungsstand in Kernelmodul für rc_core/mceusb gefiltert wird. Vmtl. muß ich eher dort ansetzen ...

TheChief · 22. Juli 2013

Bin eben nicht sicher. Wenn das event bei evtest ankommt, müsste es doch schon durch mceusb durch sein. Aber wer weiß, bin auf die Lösung gespannt.

seahawk1986 · 22. Juli 2013

Zitat von fnu

Vmtl. muß ich eher dort ansetzen ...

Natürlich ist es schöner das Problem in Treiber anzugehen - falls das nicht klappen sollte und du aber schon beim ersten Tastendruck einen Scancode bekommst

Code

Event: time 1364695268.840121, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f0422

kann ich ein Python-Skript anbieten das den auswertet und daraus anhand einer bestehenden keytable ein KEY-Event macht.

fnu · 27. Juli 2013

So, hab mal wieder ein wenig gesucht ohne weiteres Ergebnis.

Am Beispiel des "OK" Buttons was bei mir mit Kernel 3.5 && 3.8 passiert, sieht bei allen anderen Tasten gleich aus, die Events sind alle korrekt:

Code

Kernel 3.2.0 inputlirc mit mceusb#/> sudo evtest /dev/input/by-id/usb-Philips_eHome_Infrared_Transceiver_PH00Xi62-event-if00----> hier erster und einziger Tastendruck "OK", Event wird sofort ausgelöstEvent: time 1374940017.124689, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8011525cEvent: time 1374940017.124691, type 1 (EV_KEY), code 352 (KEY_OK), value 1Event: time 1374940017.124692, -------------- SYN_REPORT ------------Event: time 1374940017.230688, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8011525cEvent: time 1374940017.230689, -------------- SYN_REPORT ------------Event: time 1374940017.364687, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8011525cEvent: time 1374940017.364688, -------------- SYN_REPORT ------------Event: time 1374940017.614274, type 1 (EV_KEY), code 352 (KEY_OK), value 0Event: time 1374940017.614274, -------------- SYN_REPORT ------------

Code

Kernel 3.8.0 inputlirc mit mceusb:#/> sudo evtest /dev/input/by-id/usb-Philips_eHome_Infrared_Transceiver_PH00Xi62-event-if00----> hier erster Tastendruck "Ok"Event: time 1374938533.492559, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8011d25cEvent: time 1374938533.492559, -------------- SYN_REPORT ------------Event: time 1374938533.599504, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8011d25cEvent: time 1374938533.599504, -------------- SYN_REPORT ------------Event: time 1374938533.732436, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8011d25cEvent: time 1374938533.732436, -------------- SYN_REPORT ----------------> hier zweiter Tastendruck "Ok", nun kommt der EventEvent: time 1374938534.992798, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8011525cEvent: time 1374938534.992798, type 1 (EV_KEY), code 352 (KEY_OK), value 1Event: time 1374938534.992798, -------------- SYN_REPORT ------------Event: time 1374938535.099744, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8011525cEvent: time 1374938535.099744, -------------- SYN_REPORT ------------Event: time 1374938535.233677, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8011525cEvent: time 1374938535.233677, -------------- SYN_REPORT ------------Event: time 1374938535.485465, type 1 (EV_KEY), code 352 (KEY_OK), value 0Event: time 1374938535.485465, -------------- SYN_REPORT ------------

Regards
fnu

TheChief · 27. Juli 2013

Die Vorschläge brachten keine Verbesserung?

fnu · 27. Juli 2013

Zitat von TheChief

Die Vorschläge brachten keine Verbesserung?

Wie sollte Deiner Meinung nach hier die Situation sich bessern? Die Ursache liegt doch schon im Kernelmodul, das für die Events verantwortlich ist.

Selbst mein ursprünglicher Ansatz inputlirc so zu verbiegen das die Tasten zweimal gesendet werden erscheint in der Tat sinnlos, daher habe ich auch den Threadnamen geändert.

Regards
fnu

[Workaround] Ab Kernel 3.5 evtl. doppelter Tastendruck bei inputlirc & mceusb notwendig ...

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema