Super ☺
Du brauchst natürlich noch eine Regel, die ACTION=="remove" abbildet. Scheint, als würde das ENV{REMOVE_CMD} nicht reichen. Ggf. eine zweite Zeile wie ganz am Anfang, die beim "unplug" ausgeführt wird.
Anmeldungsdatum: Beiträge: 12067 |
Super ☺ Du brauchst natürlich noch eine Regel, die ACTION=="remove" abbildet. Scheint, als würde das ENV{REMOVE_CMD} nicht reichen. Ggf. eine zweite Zeile wie ganz am Anfang, die beim "unplug" ausgeführt wird. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 563 |
Meinst Du so: ACTION=="add", SUBSYSTEM=="input", ATTRS{idProduct}=="05d8", ATTRS{idVendor}=="04fc", RUN+="/usr/local/bin/numlock on", ENV{REMOVE_CMD}="/usr/local/bin/numlock off" ENV{ID_VENDOR_ID}=="04fc", ENV{ID_MODEL_ID}=="05d8", ACTION=="remove", RUN+="/usr/local/bin/numlock off'" Nachtrag: Hab grad die Sitzung beendet. Kaum kam der Anmeldebildschirm schaltete sich der Nummernblock sowie die LED - Anzeige aus. Passwort eingegeben und Sitzung gestartet, schaltete sich der Nummernblock sowie die LED - Anzeige wieder automatisch ein. Fehlt also nach wie vor eine passende Funktion fürs Unpluggen... 😕 🙄 |
Anmeldungsdatum: Beiträge: 12067 |
Ich muss damit mal bei mir rumspielen, nachdem das Netbook geladen ist. Aktuell läuft es seit drei Tagen (nicht durchgehend ☺ ) und braucht mal wieder Futter. Dann nehm ich meine alte USB-Tastatur und probiere mal ein wenig herum. Aus dem Bauch heraus würde ich sagen: Entscheide dich für eine Lösung. Entweder remove oder ENV{REMOVE_CMD}, nicht beides. Zudem tendiere ich zu der systemd-Lösung über eine Service-Datei. Aber wir werden sehen... |
(Themenstarter)
Anmeldungsdatum: Beiträge: 563 |
Ich habe mich entschieden: Meine 25-usbkeyboard.rules in /etc/udev/rules.d/ sieht jetzt so aus: ACTION=="add", SUBSYSTEM=="input", ATTRS{idProduct}=="05d8", ATTRS{idVendor}=="04fc", RUN+="/usr/local/bin/numlock on" ENV{ID_VENDOR_ID}=="04fc", ENV{ID_MODEL_ID}=="05d8", ACTION=="remove", RUN+="/usr/local/bin/numlock off'" Hab neugestart: Beim Anmeldebildschrim ist Numlock aus, unmittelbar nach dem Anmelden geht es wieder an, aber wenn ich den USB Receiver rausziehe, passiert immer noch nichts... 😢 Wie ärgerlich ist das denn... |
Anmeldungsdatum: Beiträge: 12067 |
Hallo! Damit bist du weiter als ich. Mein Vorgehen war wie folgt: sudo apt install numlockx lsusb
Bus 001 Device 005: ID 1267:0103 Logic3 / SpectraVideo plc G-720 Keyboard udevadm monitor
udevadm -a -p /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 > udevinfo Daraus ausgelesen: SUBSYSTEM=="usb" ATTR{idProduct}=="0103" ATTR{idVendor}=="1267" Regel erstellt: nano /etc/udev/rules.d/99-numlocker.rules Inhalt: ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1267", ATTRS{idProduct}=="0103" RUN+="/bin/sh -c '/usr/bin/touch /home/kubuntu/info.txt'", ENV{REMOVE_CMD}="/bin/sh -c '/usr/bin/touch /home/kubuntu/info2.txt'" Testen: udevadm test /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 Ausgabe (kürzen des Regellesens, Rest komplett): ...Reading rules file: /lib/udev/rules.d/99-systemd.rules rules contain 393216 bytes tokens (32768 * 12 bytes), 37025 bytes strings 27127 strings (224162 bytes), 23453 de-duplicated (190812 bytes), 3675 trie nodes used value '[dmi/id]sys_vendor' is 'LENOVO' value '[dmi/id]sys_vendor' is 'LENOVO' IMPORT builtin 'usb_id' /lib/udev/rules.d/50-udev-default.rules:13 IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:13 MODE 0664 /lib/udev/rules.d/50-udev-default.rules:41 PROGRAM 'mtp-probe /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 1 6' /lib/udev/rules.d/69-libmtp.rules:2167 starting 'mtp-probe /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 1 6' 'mtp-probe /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 1 6'(out) '0' Process 'mtp-probe /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 1 6' succeeded. RUN '/lib/udev/tlp-usb-udev %p' /lib/udev/rules.d/85-tlp.rules:10 RUN '/bin/sh -c '/usr/bin/touch /home/kubuntu/info.txt'' /etc/udev/rules.d/99-numlocker.rules:6 handling device node '/dev/bus/usb/001/006', devnum=c189:5, mode=0664, uid=0, gid=0 preserve permissions /dev/bus/usb/001/006, 020664, uid=0, gid=0 preserve already existing symlink '/dev/char/189:5' to '../bus/usb/001/006' created db file '/run/udev/data/c189:5' for '/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2' ACTION=add BUSNUM=001 DEVNAME=/dev/bus/usb/001/006 DEVNUM=006 DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 DEVTYPE=usb_device DRIVER=usb ID_BUS=usb ID_MODEL=0103 ID_MODEL_ENC=0103 ID_MODEL_FROM_DATABASE=G-720 Keyboard ID_MODEL_ID=0103 ID_REVISION=0101 ID_SERIAL=1267_0103 ID_USB_INTERFACES=:030101:030000: ID_VENDOR=1267 ID_VENDOR_ENC=1267 ID_VENDOR_FROM_DATABASE=Logic3 / SpectraVideo plc ID_VENDOR_ID=1267 MAJOR=189 MINOR=5 PRODUCT=1267/103/101 REMOVE_CMD=/bin/sh -c '/usr/bin/touch /home/kubuntu/info2.txt' SUBSYSTEM=usb TYPE=0/0/0 USEC_INITIALIZED=68681993 run: '/lib/udev/tlp-usb-udev /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2' run: '/bin/sh -c '/usr/bin/touch /home/kubuntu/info.txt'' Unload module index Unloaded link configuration context. Test also bestanden (mit Testanlage, ohne Script, etc.) udevadm control -R systemctl restart udev.service reboot bringen alle das selbe Ergebnis: Keins. Im Test steht die Zeile drin, beim Einstecken passiert aber nichts. Ich bin also erstmal genau so aufgeschmissen, wie du ☺ Bisher dachte ich, dass das ich das mit dem udev verstanden hätte. Wie man sieht, habe ich mich geirrt und bin ebenfalls ratlos 😉 Ich versuche mal weiter... |
(Themenstarter)
Anmeldungsdatum: Beiträge: 563 |
ChickenLipsRfun2eat, danke für all Deine Bemühungen! Irgendwo steckt da doch der Wurm drin. Verdammt! |
Anmeldungsdatum: Beiträge: 12067 |
Ja, sowas fuchst mich selbst. Vor allem, weil udev ja mittlerweile zu systemd "gehört". Heute hatte ich keine Zeit dafür, aber morgen werde ich es mal mit anderen usb-Geräten und an verschiedenen Rechnern versuchen. Wenn da ein Wurm drin ist, dann muss der gefunden werden und zurück in die Tequila-Flasche, wo er hingehört ☺ Derweil bettel ich mal um Hilfe... |
Anmeldungsdatum: Beiträge: 12067 |
Aktualisierung: Was ich zwischenzeitlich herausgefunden habe, allerdings mangels frisch aufgesetztem System noch nicht 100% reproduzierbar: Die udev-Regel funktioniert nur, wenn ich nach einem Neustart / frischem Hochfahren den Warum das so ist, weiß ich noch nicht, legt aber die Vermutung nahe, dass es ein Timing-Problem ist oder von der beim Start noch nicht verfügbaren Session abhängt. Falls einer der Mitleser hier ein noch unberührtes udev sein eigen nennt, wäre es interessant das nachzuvollziehen. Die eigentlichen Dienste (-control und -kernel) zeigen beim Status keine Besonderheiten, |
(Themenstarter)
Anmeldungsdatum: Beiträge: 563 |
Das sind ja wieder interessante Neuigkeiten! Könntest Du mir vll. bitte die Befehle, die Du zum Stoppen und Neustarten des systemd-udevd-Dämons verwendet hast, mitteilen. Würde das auch gern ausprobieren wollen... 😉 |
Anmeldungsdatum: Beiträge: 12067 |
Klar. systemctl stop systemd-udevd #beenden systemctl start systemd-udevd #starten Prinzipiell kann man so alle .service-Dateien bedienen, wobei ich im Normalfall ein Siehe auch systemd. |
Anmeldungsdatum: Beiträge: 12067 |
Also ich konnte den Fehler auf Ubuntu beschränken. Unter arch funktioniert es wie erwartet. Echt zum Mäuse melken... /edit: 1641440 |
(Themenstarter)
Anmeldungsdatum: Beiträge: 563 |
Hey zusammen, gibt es mittlerweile vll. irgendwelche Neuigkeiten in Hinblick auf diese Angelegenheit?! Vielen Dank im Voraus & schönen zweiten Advent! Chipy |
Anmeldungsdatum: Beiträge: 12067 |
Hallo! Ich habe es nicht weiter ausprobiert und der Bug-Report läuft ins Leere. Also würde ich sagen: nein. Da ich aktuell alle meine Systeme am verbasteln bin, kann ich es aber auch nicht erneut ausprobieren. Frag kommende Woche nochmal, da habe ich ggf. Zeit dafür ☺ |
(Themenstarter)
Anmeldungsdatum: Beiträge: 563 |
TOP, danke Dir!!! |
Anmeldungsdatum: Beiträge: Zähle... |
Hat es geholfen nur den Nummernblock zu aktivieren ? |