• USB-Tastatur bei Hibernate erkennen

    From Stefan Blochwitz@21:1/5 to All on Sun Jan 12 12:20:01 2025
    Liebe Liste,

    ich habe das Problem, dass nach dem Hibernate des Systems die
    Tastaturbelegung meiner externen USB-Tastatur am Notebook nicht mehr
    erkannt wird, ich muss jedes mal xmodmap ~/.Xmodmap aufrufen. Ich
    hatte die Frage schon einmal hier gestellt und die Lösung war, das
    über eine udev-Regel zu lösen. Ich habe mich an die Anleitung hier: https://superuser.com/questions/1576107/changing-keyboard-layout-when-keyboard-is-plugged-with-udev
    gehalten, aber es funktioniert noch nicht so richtig. Mir fehlen
    leider die Kenntnisse und ich benötige Hilfe:

    Ich habe die Datei /etc/udev/rules.d/keyboard.rules mit folgendem Inhalt:

    SUBSYSTEM=="input" \
    , ATTRS{idVendor}=="04d9" \
    , ATTRS{idProduct}=="0171" \
    , SYMLINK+="usb_keyboard" \
    , TAG+="systemd"

    das scheint auch zu klappen, denn nach

    # sudo /etc/init.d/udev restart
    # ls -lF /dev | grep myusb

    sehe ich:

    lrwxrwxrwx 1 root root 13 12. Jan 11:24 usb_keyboard -> input/event15

    Und ich habe in ~/.config/systemd/user/keyboard.service mit folgendem Inhalt:

    [Unit]
    Description=Keyboard layout
    After=dev-keyboard.device
    BindsTo=dev-keyboard.device
    Requisite=dev-keyboard.device

    [Service]
    Environment=DISPLAY=:0
    ExecStart=xmodmap /home/familie/.Xmodmap
    StandardOutput=journal
    RemainAfterExit=yes
    Type=forking

    [Install]
    WantedBy=dev-keyboard.device

    Rufe ich jetzt
    # systemctl --user enable keyboard.service
    auf erhalte ich die Meldung
    Unit /home/familie/.config/systemd/user/keyboard.service is added as a dependency to a non-existent unit dev-keyboard.device.

    Und es wurde in /home/familie/.config/systemd/user das Verzeichnis ev-keyboard.device.wants angelegt. Insgesamt sieht es da so aus.

    insgesamt 12
    drwxr-xr-x 2 familie familie 4096 12. Jan 11:40 dev-keyboard.device.wants -rw-r--r-- 1 familie familie 291 1. Aug 21:30 keyboard.service

    ./dev-keyboard.device.wants:
    insgesamt 0
    lrwxrwxrwx 1 familie familie 51 12. Jan 11:40 keyboard.service -> /home/familie/.config/systemd/user/keyboard.service

    udev läuft zumindest prinzipiell, wenn ich
    #udevadm monitor
    aufrufe und die Tastatur herausziehe und hereinstecke, tut sich
    allerlei. Nach dem Neuhineinstecken muss ich aber wieder xmodmap
    starten.

    Für mich sieht es so aus, als wäre Kern des Problems der Verweis auf dev-keyboard.device in ~/.config/systemd/user/keyboard.service. Das
    ist wohl kein kein Standard-Dienst, aber was ist es dann? Wie muss man
    das erzeugen?

    Danke schon jetzt,

    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helge Reimer@21:1/5 to All on Sun Jan 12 13:00:02 2025
    Am Sonntag, 12. Januar 2025, 12:02:46 MEZ schrieb Stefan Blochwitz:

    ich habe das Problem, dass nach dem Hibernate des Systems die Tastaturbelegung meiner externen USB-Tastatur am Notebook nicht mehr
    erkannt wird, ich muss jedes mal xmodmap ~/.Xmodmap aufrufen. Ich
    hatte die Frage schon einmal hier gestellt und die Lösung war, das
    über eine udev-Regel zu lösen.

    Ich würde dafür eher eine systemd-Unit für deinen Benutzer anlegen.

    $ nano ~/.config/systemd/user/xmodmap.service

    [Unit]
    Description=Reload Xmodmap after sleep or hibernate
    After=suspend.target hibernate.target

    [Service]
    Type=oneshot
    ExecStart=/usr/bin/xmodmap ~/.Xmodmap
    Environment=DISPLAY=:0

    [Install]
    WantedBy=suspend.target hibernate.target

    Dann die Konfiguration laden und den Service aktivieren

    $ systemctl --user daemon-reload
    $ systemctl --user enable xmodmap.service



    --
    Gruß
    Helge

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Blochwitz@21:1/5 to All on Mon Jan 13 20:40:01 2025
    Hallo Helge,

    danke für den Tipp. Kurze Zusammenfassung: Es funktioniert tatsächlich.

    Etwas länger: Etwas Mysteriöses bleibt, denn wenn ich das so mache,
    bekomme ich als Meldung:

    Unit /home/familie/.config/systemd/user/xmodmap.service is added as a dependency to a non-existent unit suspend.target.
    Unit /home/familie/.config/systemd/user/xmodmap.service is added as a dependency to a non-existent unit hibernate.target.

    Daran ändert sich auch nichts, wenn ich zuvor

    # systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target

    aufrufe.

    Erstaunlicherweise funktioniert Dein Tipp aber trotz dieser Meldung,
    die ich erst einmal als Fehler verstanden hätte (auch nach einem
    Reboot), denn wenn das System reanimiert ist, ist die gewünschte Tastaturbelegung vorhanden. Deshalb nur so als interessierte Frage:
    Was soll mir die Meldung dann sagen?

    Pragmatischerweise kann man es aber auch akzeptieren und dabei belassen.

    Also, noch einmal vielen Dank für die Hilfe,

    Stefan





    Am So., 12. Jan. 2025 um 12:55 Uhr schrieb Helge Reimer <[email protected]>:

    Am Sonntag, 12. Januar 2025, 12:02:46 MEZ schrieb Stefan Blochwitz:

    ich habe das Problem, dass nach dem Hibernate des Systems die Tastaturbelegung meiner externen USB-Tastatur am Notebook nicht mehr erkannt wird, ich muss jedes mal xmodmap ~/.Xmodmap aufrufen. Ich
    hatte die Frage schon einmal hier gestellt und die Lösung war, das
    über eine udev-Regel zu lösen.

    Ich würde dafür eher eine systemd-Unit für deinen Benutzer anlegen.

    $ nano ~/.config/systemd/user/xmodmap.service

    [Unit]
    Description=Reload Xmodmap after sleep or hibernate
    After=suspend.target hibernate.target

    [Service]
    Type=oneshot
    ExecStart=/usr/bin/xmodmap ~/.Xmodmap
    Environment=DISPLAY=:0

    [Install]
    WantedBy=suspend.target hibernate.target

    Dann die Konfiguration laden und den Service aktivieren

    $ systemctl --user daemon-reload
    $ systemctl --user enable xmodmap.service



    --
    Gruß
    Helge



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helge Reimer@21:1/5 to All on Mon Jan 13 21:40:01 2025
    Am Montag, 13. Januar 2025, 20:21:00 MEZ schrieb Stefan Blochwitz:
    Hallo Helge,

    bitte keine Kopie deiner Mails mehr an mich. Antworte nur an die Liste.

    Unit /home/familie/.config/systemd/user/xmodmap.service is added as a
    dependency to a non-existent unit suspend.target.
    Unit /home/familie/.config/systemd/user/xmodmap.service is added as a dependency to a non-existent unit hibernate.target.

    'suspend.target' und 'hibernate.target' sind System-Services und keine Benutzer-Services.
    Versuche mal in der Zeile 'WantedBy' die Targets durch 'default.target' zu ersetzen.
    Dann die neue Konfiguration laden und den Service erneut aktivieren, so wie unten schon beschrieben.

    $ systemctl --user daemon-reload
    $ systemctl --user enable xmodmap.service

    --
    Gruß
    Helge

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Blochwitz@21:1/5 to All on Tue Jan 14 00:30:01 2025
    Danke, das klappt jetzt ohne Gemaule des Systems.

    Am Mo., 13. Jan. 2025 um 21:34 Uhr schrieb Helge Reimer <[email protected]>:

    Am Montag, 13. Januar 2025, 20:21:00 MEZ schrieb Stefan Blochwitz:
    Hallo Helge,

    bitte keine Kopie deiner Mails mehr an mich. Antworte nur an die Liste.

    Unit /home/familie/.config/systemd/user/xmodmap.service is added as a
    dependency to a non-existent unit suspend.target.
    Unit /home/familie/.config/systemd/user/xmodmap.service is added as a dependency to a non-existent unit hibernate.target.

    'suspend.target' und 'hibernate.target' sind System-Services und keine Benutzer-Services.
    Versuche mal in der Zeile 'WantedBy' die Targets durch 'default.target' zu ersetzen.
    Dann die neue Konfiguration laden und den Service erneut aktivieren, so wie unten schon beschrieben.

    $ systemctl --user daemon-reload
    $ systemctl --user enable xmodmap.service

    --
    Gruß
    Helge



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)