Tastatur Logitech K400r - Key Mapping und Power-Knopf ohne Funktion

Hallo,

hab mir besagte Tastatur zugelegt und versuche jetzt zwei Dinge:

1) Dass die Farbtasten "rot", "grün", "gelb" und "blau" nicht (nur) über die Funktionstatsen F1-F4 zu betätigen gehen sondern z.B. (der Einfachheit halber) auch über "Q", "W", "E", "R". Grund: Bei diesem Modell kommt man an die F-Tasten nur in Kombination mit einer blauen Taste namens "FN" ran. Hab mich daher (wieder) mal mit eventlirc und Konsorten beschäftigt, und bin am Ende (wieder) gescheitert. Ich sitze jetzt seit einem halben Tag vor Google und yaVDR-Doku und es ist einfach nichts so, wie man es dort zu lesen bekommt. Jedenfalls ist das jetzt gerade meine verzweifelte Meinung.

Was ich geschafft habe ist die Tastatur in den udev-Rules einzupflegen und dann über evmap die 4 Tasten zu mappen. Dann sind diese 4 Tasten aber die Einzigen, auf die VDR reagiert. Wieso ist das so? Ich dachte alle Codes, die vor eventlirc definiert sind (wie auch immer), kämen durch evmap unbeschadet durch. Und dass die Codes vor evmap sauber vorhanden sind, konnte ich mit evtest bestätigen.

Andererseits gibt es den Abschnitt KBD.* in der remote.conf doch sicher auch nicht nur aus Spass - dachte ich. Ohne eventlirc-udev-Regeln kommen die Tastaturcodes doch sicher darüber rein - dachte ich. Aber was auch immer ich in den KBD-Mappings ändere hat keinerlei Auswirkungen. Aber selbst wenn, erschliessen sich mir nicht diese langen Code-Folgen, z.B. 000000001B5B5B41 für "F1". Die haben nichts mit Scan- oder Keycodes zu tun, richtig? Wie kommen die zustande? In irgendeinem Thread ist ein Link, der das wohl beschrieben hat, nur der ist mittlerweile tot.

Also: Bitte, kann mir jemand sagen, wie es sich bei Tastaturen verhält mit dem Weg der Codes zum VDR?

2) Ich habe eine Fernbedienung (iMon), mit der ich über die "rote" Power-Taste VDR und Rechner sauber runterfahren kann, und einen so heruntergefahrenen Rechner auch wieder aufwecken kann. Grundsätzlich kann das mein System also. Warum klappt das also nicht mit der Power-Taste der K400r? Scancode für diese Taste gibt es nicht. Daher ist es vermutlich eher problematisch damit den VDR sauber runterzufahren. Aber das Aufwecken sollte schon mit der Taste gehen. Im BIOS ist natürlich alles an, was damit zu tun haben könnte. Ich hab sogar mal bei "Wake on Keyboard" auf "Passwort" gestellt, aber es rührt sich nix. Ideen?

Ach ja, vielleicht von Bedeutung: Vorher hatte ich eine Tastatur dran, die keine Power-Taste hatte. Kann es sein, dass es daran liegt? Muss ich irgendwas neu installieren?

Grüsse
ako673de

maz: Danke. Bei den vielen Kundenrezensionen bei Amazon habe ich verpasst mir dieses Tool (Setpoint) einmal anzusehen. Also sofort ausprobiert. Aber funktioniert nicht. Funktioniert nur in Windows. Bei yaVDR bleibt alles beim alten. Das Programm programmiert nicht die Tastatur um sondern Windows. Schade. Täte mich interessieren, wie Du das (genau) hinbekommen hast.

@seahawk: evtest meldet nichts bei der Power-Taste. Die sendet keinen Scancode, jedenfalls keinen den evtest mitbekommen würde. Bzgl. Aufwecken bin ich evtl. einen Schritt weiter: cat /sys/bus/usb/devices/2.1.3/power/wakeup (2.1.3 ist vermutlich nur für mich so) ergibt "disabled". Sollte wohl "enabled" sein. Also "echo enabled > ..." gemacht, aber das war's noch nicht. Zudem ist es beim nächsten Start wieder disabled. Verantwortlich für das alles scheint mir bei yaVDR die Datei /etc/udev/rules.d/40-usb-wakeup-devices.rules zu sein. Liege ich da richtig? Wenn ja, was ist zu tun? Aus dem Inhalt dieser Datei werde ich nämlich nicht schlau...

mini73: Ja, bei 6 der 10 Tasten wäre das wohl möglich, aber bei 4 kommt (mit evtest ergründet) mehr als nur ein Code bei Betätigen. Das dürfte schwierig werden.

maz: Für mich war es eindeutig genug, dass am Windows (XP) PC nach der Umprogrammierung alles richtig lief, aber sofort, als ich Setpoint beendet hatte (aus der Taskleiste) es sofort wieder falsch (=im Originalzustand) war. Aber beim nächsten Start von Setpoint wusste es noch die geänderten Einstellungen, und sofort tat die Tastatur wieder das richtige. Vermutlich merkt sich (mein?) Setpoint das in der Registry. Aber wenn Du das hin bekommen hast, kannst Du mal Deine Setpoint Version schicken? Und sagen, unter welchem OS Du es probiert hast? An irgedwas in dieser Richtung muss es ja liegen...

Hallo PAK,

seeehr interessanter Ansatz. Hab das mal probiert, stelle dabei aber folgende Probleme fest:

- F1: Auf dieser Taste liegt offenbar noch von woanders eine Funktion drauf, die sowas ähnliches tut wie (jetzt) ScrollLock, und zwar kommt da dann das yaVDR Logo in gross. Ich glaube da geht es um das Umschalten des Workspaces. Um das auszuschalten oder umzuverdrahten, muss daher wohl noch an der (Input-)Konfiguration des Desktop-Managers gebastelt werden, oder? Wo muss ich danach suchen?

- F6: Das sollte ja eine Aufnahme starten. Aber seltsamerweise kommt vordergründig erst einmal das Gleiche wie bei F5, also "Info". Erst wenn man die weg macht sieht man (vielleicht noch kurz) dass eine Aufnahme gestartet wurde. Auch hier ist wohl noch woanders konfiguriert, dass mit der "Zahnrädchen"-Taste bei VDR die "Info" kommt. Die Lösung ist daher allerdings recht einfach: Ich hab "Aufnehmen" auf die Taste (ich nenn sie jetzt mal) "Bild im Bild" (F5) umverlegt und das "Zahnrädchen" (F6) unbehandelt gelassen.

- F8: Beim Drücken dieser Taste, die ja eigentlich "Play/Pause" machen sollte, hängt sich das Script auf. Es werden zwar weiterhin grundsätzlich Tastendrücke von VDR akzeptiert aber die mit diesem Script gepatchten Funktionen sind bis zum nächsten VDR restart nicht mehr verfügbar.

- F10-F12: Auch hier ist etwas seltsam. Funktionieren tun die unge-FN-ten Tasten, aber die Lautstärke-Anzeige am unteren Rand des Bildschirms blitzt immer kurz auf was sie beim normalen F10-F12 nicht tut. Mein Verdacht: Die gepatchte Form in Deinem Skript führt ja "remote.*"-Kommandos aus. Die beinhalten vermutlich das Einblenden und wieder Ausblenden des Lautstärke-Status-Balkens.

=> Irgendwie fühlt sich das nicht nach dem richtigen Lösungsansatz an. Setzt einfach viel zu weit "hinten" an (und ist für xine und xinelib vermutlich nicht zu gebrauchen, was bei mir glücklicherweise kein Thema mehr ist, aber es gibt viele Leute da draussen, bei denen der Bildschirm schwarz bleibt bei softhddevice).

Für "Power down" hast Du jetzt die "Lock"-Taste benutzt. D.h. Dir war es auch nicht möglich, die richtige "power"-Taste zu verwenden, oder? Was mir keine Ruhe lässt: Wenn die doch keinen Scan-Code schickt, wie schafft das dann Setpoint, diese Taste auf Windows-Ebene zu mappen?! Oder noch weiter gedacht: Wenn Setpoint einen Treiber installieren kann, der Tasten so vollständig umbiegen kann, dass auch zusätzlich ausgelöste Events (Shift, Super, usw.) unterdrückt oder generiert werden, gibt's denn dann eine solche Lösung nicht auch für Linux? Ich würd ja gerne mal auf die Suche gehen, aber soweit ich das verstanden habe, gehen Events von Tastaturen nicht über z.B. ir-keytable, also worüber gehen sie, wo man evtl. Zugriff für ein Mapping hätte?

Hast Du eigentlich eine Lösung für "Power up"? Ich meine das Aufwecken durch Tastendruck. Nicht dass ich mich jetzt so viel besser auskennen würde, aber ich hab gehört, dass zum Runterfahren ein "Power-Off-Kernel" geladen wird, und daher das "echo enabled > /sys/bus/usb/devices/2.1.3/power/wakeup" evtl. beim Herunterfahren "vergessen" wird, wenn es nicht irgendwo in einer Konfigurationsdatei fest verankert wird. Lief das bei Dir OOTB?

Grüsse
ako673de

Hab noch ein wenig experimentiert, und das zentrale Problem scheint am Ende zu sein, dass man in der remote.conf (die ja ganz eindeutig der richtige Ort für die customization wäre), nur keysym-Namen (gemäss XKb) angeben kann. D.h.: Keine Modifier wie z.B. Shift, Control oder eben Super. Man muss sich also für die paar Media-Tasten, die Kombinationen aus Super und Control benutzen, eigene keysym's erzeugen. Und so hab ich jetzt seit Stunden die Doku auf https://wiki.archlinux.org/index.php/X_KeyBoard_extension gelesen um diese Aufgabe zu bewältigen. Aber das übersteigt mein Verständnis. Nicht dass ich es nicht verstanden habe wie es prinzipiell funktionieren würde, aber in yaVDR gibt es z.B. das Header-File nicht, das die keysym-Namen definiert, und auch sonst ist irgendwie vieles anders. Ich weiss einfach nicht wo und wie ich am effektivsten und minimalinvasivsten in yaVDR eingreifen soll/kann/darf.

Ich hoffe auf Eure Hilfe...
ako673de

P.S.: Es ist mir aber schon mal gelungen einige der Tweaks von PAK in die remote.conf (/etc/yavdr/templates_custom/var/lib/vdr/remote.conf/50_keys) zu verlagern, und damit für eine deutliche Verbesserung des Verhaltens zu sorgen (Im folgenden nur gegenüber dem Original geänderte Zeilen. Wer's verwenden will, bitte vorher die Kommentare ab den "#" entfernen, denn Kommentare sind in der remote.conf nicht erlaubt):

XKeySym.Menu       XF86HomePage          # Media-Taste "HomePage"
XKeySym.Red        XF86Red               # Diesen keysym gibt's (noch) nicht, aktuell wird die Media-Taste auf F2 daher über den Frontend-Event-Handler mit "Red" verknüpft
XKeySym.Green      XF86Green             # Diesen keysym gibt's (noch) nicht, aktuell wird die Media-Taste auf F3 daher über den Frontend-Event-Handler mit "Green" verknüpft
XKeySym.Yellow     XF86Yellow            # Diesen keysym gibt's (noch) nicht, aktuell wird die Media-Taste auf F4 daher über den Frontend-Event-Handler mit "Yellow" verknüpft
XKeySym.Blue       XF86Blue              # Diesen keysym gibt's (noch) nicht, aktuell wird die Media-Taste auf F5 daher über den Frontend-Event-Handler mit "Blue" verknüpft
XKeySym.Info       XF86Settings          # Diesen keysym gibt's (noch) nicht, aktuell wird die "Zahnrädchen"-Taste (F6) daher über den Frontend-Event-Handler mit "Info" verknüpft
XKeySym.Record     XF86AudioPlay         # Da die Funktion Play/Pause schon auf "space" gut aufgehoben ist, hab ich die Media-Taste "Play" (F8) zur Not mit "Aufnehmen" verknüpft
XKeySym.FastFwd    XF86AudioNext         # Media-Taste "Fast Forward" (F9)
XKeySym.FastRew    XF86AudioPrev         # Media-Taste "Fast Rewind" (F7)
XKeySym.Power      XF86Sleep             # Media-Taste "Power" (wie praktisch!)
XKeySym.Volume+    XF86AudioRaiseVolume  # Media-Taste "Vol+" (F12)
XKeySym.Volume-    XF86AudioLowerVolume  # Media-Taste "Vol-" (F11)
XKeySym.Mute       XF86AudioMute         # Media-Taste "Mute" (F10)
XKeySym.Audio      XF86Tools             # Media-Taste "Tools" (ganz oben links)
XKeySym.Subtitles  F1                    # nicht ganz so elegant wie im Eventhandler (wo das mit Shift-"Tools" erreicht wird), 
                                         # aber F1 ist ja jetzt frei, braucht auch mehr als nur einen Tastendruck 
                                         # und die Untertitel haben so viel ja auch nicht mit der Tonspur-Einstellung zu tun...

Und hier die dementsprechenden Modifikationen an den PAK-schen Modifikationen des Eventhandlers (in /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf/30_softhddevice-02-script.py) :-):

...
    def evthandler(self,path, *args):
        '''callback function to handle keys sent by inputdevices'''
        try:
            event = path.read(self.inputEventSize)
        except:
            syslog.syslog('can not read from %s'%(path))
            return False
        (time1, time2, typeev, code, value) = struct.unpack(self.inputEventFormat, event)


#       > Added for special handling of Logitech K400r keyboard
        if typeev == 1 and code == 29: # Control_L
            self.control_l_key_active = value
        if typeev == 1 and code == 125: # Super_L
            self.super_l_key_active = value


        if typeev == 1 and code == 14 and value == 1 and self.control_l_key_active == 1 and self.super_l_key_active == 1: # Media-Taste auf F2
            remote.sendkey("Red")
        if typeev == 1 and code == 217 and value == 1: # Media-Taste auf F3
            remote.sendkey("Green")
        if typeev == 1 and code == 35 and value == 1 and self.super_l_key_active == 1: # Media-Taste auf F4
            remote.sendkey("Yellow")
        if typeev == 1 and code == 37 and value == 1 and self.super_l_key_active == 1: # Media-Taste auf F5
            remote.sendkey("Blue")
        if typeev == 1 and code == 23 and value == 1 and self.super_l_key_active == 1: # "Zahnrädchen"-Taste auf F6
            remote.sendkey("Info")
        if typeev == 1 and code == 38 and value == 1 and self.super_l_key_active == 1: # Lock
#       < Added for special handling of Logitech K400r keyboard


#       > Removed for special handling of Logitech K400r keyboard
#        if typeev == 1 and code == 115: # code 115 = KEY_VOLUMEUP
#            remote.sendkey("Volume+")
#        if typeev == 1 and code == 114: # code 115 = KEY_VOLUMEDOWN
#            remote.sendkey("Volume-")
#        if typeev == 1 and code == 113 and value == 1: # code 115 = KEY_MUTE
#            remote.sendkey("Mute")
#       if typeev == 1 and code == 172 and value == 1: # code 172 = KEY_HOMEPAGE - toggle frontend (attach/detach)
#       < Removed for special handling of Logitech K400r keyboard


           if self.frontend_active == 1:
               syslog.syslog("detached frontend")
               detach()
           elif self.frontend_active == 0:
               syslog.syslog("attached frontend")
               resume(frontend.status())
        if self.frontend_active == 0:
           if typeev == 1 and code == 28 and self.GetActiveWindowTitle() == 'WM_NAM': # resume frontend on KEY_ENTER if no window has focus
               syslog.syslog("frontend attached by keyboard activity")
               resume(frontend.status())
        return True
...

Zitat von PAK

Für Power Off habe ich mir die Lock konfiguriert, weil die eigentliche Power Taste nicht wollte. Ein Power On geht mit jeder Taste.

Ja, seltsam, mittlerweile sendet die Power-Taste bei mir "XF86Sleep" (bzw. in evtest "KEY_SLEEP"). So genau weiss ich eigentlich nicht warum, ausser vielleicht, dass die tatsächlich bei meinen Versuchen mit Setpoint (siehe weiter oben in diesem Thread) umprogrammiert wurde. Wenn ja, dann war's leider trotzdem die einzige Taste, die wirklich in Hardware umprogrammiert wurde.

Power on geht bei mir nach wie vor nicht. Als Du yaVDR installiert hast war die K400r schon dran, oder? Bei mir war leider eine andere Tastatur dran als ich installiert habe, und vermutlich genau deshalb klappt das bei mir nicht. Die zentrale Frage ist daher: Kann ich irgendwie eine vollständige Tastatur-Neuerkennung machen? "dpkg-reconfigure keyboard-layout" oder so (aber letzteres hat nur gut ausgesehen, geholfen hat es nicht).

Zitat von PAK

Mein "remote.conf" beinhaltet:
XKeySym.Info F5

Das erklärt warum bei Dir bei der Aufnahme nicht noch die Info kommt. Im Original steht da ja "i" drin, und da die Multimedia-Taste über F6 Super_L+i sendet, reagieren dann zwei Funktionen auf diese Taste, "Info" über die remote.conf und "Record" über den Eventhandler!

Zitat von PAK

XKeySym.User2 Insert
XKeySym.User1 Print

Was genau hast Du denn mit denen gemacht? Vermutlich irgend eine Aktion wie z.B. "XBMC start" verknüpft. Wenn es Dir nicht allzu viel ausmacht: Kannst Du mir das bitte erklären. Bin schon einmal gescheitert mit diesem Vorhaben.

Zitat von PAK

Um störende Interaktionen der Openbox zu unterbinden, habe ich zusätzlich im "/etc/openbox/rc.xml" nach Studium von "openbox.org/wiki/Help:Bindings" folgendes ausgeschaltet: ...

Oh ja, das hilft weiter! Hab bis jetzt nicht einmal gewusst, dass wir da OpenBox haben in yaVDR :-). Genau damit wird die Media-Taste über F1 wieder verfügbar! Hab jetzt ein paar Tage mit F2 bis F5 gearbeitet, aber ich tu mir da echt schwer, mich dran zu gewöhnen...

Grüsse
ako673de

Eine Frage grad noch: /etc/openbox/rc.xml war scheinbar mal getemplated und ist jetzt nicht mehr. Oder suche ich nur falsch?

Danke Dir für die Kurzbeschreibung der keymacros.conf. Werde mich darüber hermachen, sobald die aktuellen Probleme gelöst sind. Wird auf jeden Fall noch eine Herausforderung, denn xbmc ist ja kein Plugin und auch kein "key". Ich hoffe ich muss mir dafür nicht erst ein Plugin schreiben, das dann xbmc startet.

Zurück zum Thema:
Seit dem letzten mal hab ich sicherlich dutzende von Threads durchforstet, die sich ebenfalls mit Wake-Up Problemen unter Linux beschäftigen. Das Problem ist aber, dass quasi jeder was anderes sagt und nichts von den angegebenen Lösungen bei (meinem) yavdr (0.5) funktioniert. Wovon quasi überall die Rede war, das waren Dateien in sysfs und procfs mit Datei- oder Verzeichnis-Namen "...wakeup...". Am Ende hab ich einfach mal alle Dateien und Ordner gesucht, die wakeup im Namen haben, und kam auf folgende Liste möglicherweise relevanter Orte:
- /proc/acpi/wakeup
- /etc/udev/rules.d/40-usb-wakeup-devices.rules
- /dev/input/wakeup/*
- /sys/bus/usb/devices/<Bus>-<Hub>.<Device>/power/wakeup (Bus/Hub/Device gemäss "lsusb", bzw. "lsusb -t")

Da ja meine Fernbedienung iMon Antec Veris 200 den Computer astrein aufweckt, hab ich natürlich auch geschaut, wie es sich bei der bzgl. dieser Dateien verhält, und da ist es so, dass sich deren (funktionierende) WakeUp-Funktion in keiner dieser Dateien offenbart! Sie hat nicht einmal eine wakeup-Datei in /sys/bus/..., und das ist doch grundsätzlich die für Ubuntu 12.04 (welches doch die Basis für yaVDR 0.5 ist, oder?) gültige Methode für das Einstellen des Wakeup-Verhaltens, oder? Also muss doch bei yaVDR irgendetwas anders sein als bei normalen Ubuntu 12.04 Distributionen. Oder ist nur an der Einbindung dieser Fernbedienung ins System irgendwas so besonders, das es für Tastaturen nicht gibt (Die Tastatur erscheint z.B. als /dev/usb/hiddevice0, die FB nicht)? Bitte, irgendjemand von den yaVDR-Entwicklern muss da doch was wissen.

/proc/acpi/wakeup enthält übrigens m.E. keine wirklich wertvollen Infos:

Device  S-state   Status   Sysfs node
PCI0      S5    *enabled   no-bus:pci0000:00
PEX0      S5    *disabled  pci:0000:00:1c.0
PEX1      S5    *disabled
PEX2      S5    *disabled
PEX3      S5    *disabled
PEX4      S5    *disabled
PEX5      S5    *disabled
PEX6      S5    *disabled  pci:0000:00:1c.6
PEX7      S5    *disabled  pci:0000:00:1c.7
HUB0      S5    *disabled  pci:0000:00:1e.0
USBE      S3    *enabled   pci:0000:00:1d.0
USE2      S3    *enabled   pci:0000:00:1a.0
AZAL      S5    *disabled  pci:0000:00:1b.0

Die FB und die Tastatur hängen bei mir übrigens am "USBE".

Ich möchte jeden von Euch darum bitten, mal zu posten, was Ihr so für wakeup-Dateien (und mit welchem Inhalt) auf Eurem yaVDR habt. Vielleicht komm ich dann durch Intuition weiter...

Grüsse
ako673de

Und wieder geht's ein Stückchen weiter:

Der Grund warum die iMon Antec Veris 200 meinen Computer brav weckt ist, dass sich dazu das Soundgraph LCD-Panel in den Power-Switch Anschluss auf dem Motherboard einhängt! Dieses Aufwecken passiert also NICHT über USB. USB wird da nur zur Stromversorgung des IR-Empfängers gebraucht.

Mit dieser Frage beantwortet stehe ich also jetzt vor einem System, das ÜBERHAUPT NOCH NIE per USB aufgeweckt wurde. Wake-on-Lan ist also das Einzige ausser dem Power-Switch, was meinen VDR-Rechner jemals aus dem Power-off-Zustand (NVRAM-Suspend, oder dgl. hab ich nie zum Laufen gebracht, bleibt immer beim Resume stehen) geholt hat.

Also hab ich mal eine PS/2-Tastatur angeschlossen. Und siehe da, hier startet der PC mit der designierten "Keyboard98"-Taste "Power". Diese Taste wird von xev als "XF86PowerOff" erkannt. Aha! Die "Power"-Taste von der Logitech-Tastatur wird als "XF86Sleep" erkannt, eine "XF86PowerOff" gibt es da nicht. Was für ein Unsinn ist das denn? Ist das evtl. der Grund für mein Problem?

Dann hab ich die Tastatur noch an einem Windows-PC probiert, und siehe da, das gleiche Verhalten! Aus "Standby" und "Suspend" hingegen bringt jede Taste den Rechner zurück ins Leben.

Suspend und Herunterfahren ist doch aus Sicht des PCs das Gleiche, oder? Aber Windows macht da wohl einen Unterschied. Da ich ja wie gesagt VDR so eingestellt habe, dass es beim Ausschalten den Rechner herunterfährt, liege ich dann mit meiner Vermutung richtig, dass auch Linux Suspend und Herunterfahren unterscheidet im Bezug auf die USB-Aufwachfähigkeiten? Wenn ja, was ist zu tun, um das abzustellen?

Nach einem Tag des Experimentierens kann ich jetzt sagen, dass...
- das Aufwecken per USB-Tastatur auch am VDR-Rechner prinzipiell geht, aber NUR aus dem Suspend-to-RAM- Zustand. In diesem Fall weckt jede Taste und jede Touchpad-Berührung den Rechner auf.
- ich meinen VDR-Rechner aber aus Suspend-to-RAM-Zuständen nicht zuverlässig resumen kann (im Durchschnitt scheitern ca. 4 von 5 Versuchen), und zwar selbst wenn ich - wie in http://wiki.ubuntuusers.de/pm-…-nach-RESUME-wieder-laden beschrieben - beim Suspend ALLE Module entladen lasse. In den Fehlerfällen passiert einfach nur nichts, keine Anzeige am Bildschirn, keine HDD-Aktivität, nichts.

Obwohl es in yaVDR ja keine Option für Suspend-to-disk gibt, hab ich mal aus Spass "pm-hibernate" eingegeben: Das Speicherabbild wird auch brav auf Platte geschrieben wird, aber danach das Ausschalten führt zu dem gleichen Ergebnis wie der normale "Power Off", nämlich dass USB nicht mehr aufweckfähig ist.

Und genau das ist bei Windows als OS anders! Da ist USB nur nach dem "Herunterfahren" taub, aber nicht im "Ruhezustand". Bin erstaunt, dass ich der erste bin, dem das auffällt.

Was ich also mind. brauche, ist ein Suspend-to-disk, das sich bzgl. USB-Wakeup-Fähigkeit so verhält wie Windows.

Irgend jemand eine Idee wie das zu erreichen ist? Kann doch sicherlich nur eine kleine Einstellung irgendwo im Kernel sein, oder?

Mir wäre sogar völlig egal wenn der Resume nicht funktioniert (würde ja eh kaum schneller sein als ein echter Neustart), denn zur Not kann ich das Abbild nach /dev/null schreiben lassen...

Hallo,

bin soeben umgestiegen auf yaVDR 0.6.1 und habe nun wieder das Problem, dass einige der Media-Tasten meiner Logitech K400r Tastatur tot sind (zur Erinnerung: /var/lib/vdr/remote.conf kann nicht mit Modifiern wie "Control", "Shift" und "Super" umgehen, und die Tasten, die nicht gehen, senden alle Tasten-Events, die genau diese Modifier beinhalten).

Der Eventhandler in dem in der Überschrift genannten Python-Script konnte unter yaVDR 0.5 noch zurecht gebogen werden, so dass er für die über remote.conf nicht mappbaren Tasten eigene Events generiert hat, die dann über die remote.conf gemappt werden konnten. Das scheint jetzt nicht mehr zu gehen, denn das besagte Template ist leer. Gibt's eine Alternative?

Grüsse
ako673de