Präsentiere: input-event-daemon v0.1.3

[gandro]

DosAmp schrieb:  “A deamon”? Das schreit nach Korrektur. :>

Grml. Fixed.

[gandro]

Version 0.1.3 ist draussen (und im AUR).

Einzelne Tasten werden jetzt bereits beim Drücken getriggert. Damit sollten einzelne Tastendrücke gleichzeitig oder sogar vor X11 erwischt werden (meine Lautstärkeanzeige unter XFCE ist jetzt synchron, vorher hinkte sie nach, das ist auch der Hauptgrund warum ich das Verhalten geändert habe).

Tastenkombinationen werden nach wie vor erst beim loslassen getriggert (d.h. bei CTRL+ALT+D wird zuerst CTRL alleine getriggert und als nächstes dann die ganze Tastenkombo (ALT und D werden nie separat getriggert)).

Zudem wird der RESET-Befehl im [Idle] Abschnitt jetzt immer ausgeführt, falls nach min. 750ms Leerlauf eine Taste gedrückt wird (und nicht mehr wie vorher erst wenn min. ein Event getriggert wurde).

[xchrissix95]

Überschrift würde ich mal anpassen.

[YAL]

Cool, habs mal aufm EeePC ausprobiert; wird wohl wirklich acpid ersetzen
BTW: Hat wer ne Idee, wie ich jack sensing zum laufen bekomm?

[gandro]

YAL schrieb:  BTW: Hat wer ne Idee, wie ich jack sensing zum laufen bekomm?

Auf meinem ThinkPad macht das Input-Event direkt der ALSA-Treiber (snd-hda-intel), und der kann das wohl auch nicht auf jeder Hardware.

[LukeGee]

Was leider ein bisschen stört finde ich, ist, dass wenn z.B. eine Konsole oder sonst ein Textfeld den Focus hat die Tasten da natürlich mit "reinprinten".
Also wenn ich halt z.B. nen Shortcut "META+M" hab und ein Texteingabefeld den Focus hat, steht da danach halt M drin.
Bzw könnts generell für die Shortcuts ein Problem sein, dass die anderen Anwendungen die Keyevents auch noch nichtbekommen.

Wärs möglich, dass man die Keyevents nach dem parsen etc irgendwie verwirft, dass die nicht noch von was anderem interpretiert werden können?

[gandro]

Also du sprichst nicht vom Monitoring-Mode, sondern davon, dass ein Event nur von input-event-daemon geparst werden sollte und der dass dann blockiert..?

Müsst ich schauen ob das machbar ist. Ich bezweifle es, weil ievd die Events auch nicht zwingend als erster Kriegt (sondern "gleichzeitig" mit XOrg und so).

Man kann zwar Tasten vorher remappen, aber bei Tastenkombinationen sieht das anders aus. Aber ich schau nachher mal.

[LukeGee]

gandro schrieb:  Also du sprichst nicht vom Monitoring-Mode, sondern davon, dass ein Event nur von input-event-daemon geparst werden sollte und der dass dann blockiert..?

Jupp, genau. Hab mich vielleicht etwas umständlich ausgedrückt.

Ist halt wirklich etwas nachteilig, wenn ich einen Shortcut ausführ und der Output der Tasten noch irgendwie landet. (Finde ich).

Bei X11-WM-Shortcuts landet der Output ja auch nicht mehr irgendwo. (Ich weiß, der Vergleich hinkt etwas, weil X halt X ist und nicht ievd, aber...joar : )

[gandro]

Ich hab mich noch ein bisschen mit der Sache beschäftigt.

evdev, der Teil das Linux-Input-Subsystemes den ich verwende bietet keine Möglichkeit einzelne Events zu stoppen. Alles was ich kann ist das gesamte Gerät zu blockieren, dass nur noch ich es haben darf.

Die einzige Möglichkeit wäre es also ein Gerät zu blockieren und eine zweite Tastatur zu emulieren, welche alle nicht behandelten Tastendrücke ausgibt, nur müsste dann input-event-daemon jeweils immer vor Xorg gestartet werden (falls Xorg mit einer solchen Handhabe überhaupt klarkommt) und sonderlich elegant oder resourcenschondend ist es auch nicht.

Nachtrag: Im übrigen bin ich nicht der einzige der sich da etwas mehr Flexibilität wünschte.[1] Aber bisher ist da afaik nichts passiert.

[1] http://lkml.org/lkml/2007/6/9/59

[TAL]

Ich hab gerade eben nen ebuild für geschrieben, ich wills euch nicht vorenthalten:

http://pixelbanane.de/yafu/729479950/inp...on.tar.bz2

Wenn's Wünsche zur Verbesserung gibt, immer her damit