Beiträge von Martin28

    Hallo HeAdLeSs ,

    Habe es in der rc.local und in der /etc/xdg/lxsession/LXDE/autostart versucht. Beides ohne Erfolg.

    Autostart mit rc.local wird hier wohl nicht funktionieren, weil das unter der graphischen Oberfläche / Xorg laufen muss.

    Hast du das unter dem Autostart-Ordner /etc/xdg/lxsession/LXDE/autostart mit einer .desktop - Datei versucht ?

    Z.B. als Datei touch.desktop mit Inhalt etwa so (ungetestet)

    Code
    [Desktop Entry]
    Type=Application
    Exec=/pfad/zu/deinem/script.sh
    Terminal=true

    Gruß Martin

    Hallo Gorcon

    Nein. Ist ein Axas E4HD Ultra.

    wenn es keine fertige .conf für dein Gerät gibt, bleibt wohl nur irrecord zum laufen zu bekommen.

    Du benutzt das USB Infrared Toy aus deinen anderen Thread: https://forum-raspberrypi.de/forum/thread/58045-per-raspberry-pi-lirc-conf-erzeugen/ ?

    Das USB-Teil kann wohl mit zwei verschiedenen Treibern ir_toy oder cdc_acm laufen und macht dann auch unterschiedliche Geräteschnittstellen /dev/lircX oder /dev/ttyACMX.

    Was sagt bei dir lsusb ? Und wenn du das Teil gerade angesteckt hast, danach die Ausgabe sudo dmesg | tail -n 12 und sudo journalctl -ekg usbcore ?

    Ein Blick in die offizielle und aktuelle Anleitung kann manchmal auch hilfreich sein:

    https://forum-raspberrypi.de/Hallo%20%20%20…tion-guide.html

    Gruß Martin

    Hallo ThomasM99
    das muss ein Autostart unter der graphischen Oberfläche, deinem Desktop sein, also eine .desktop-Datei im Autostart-Ordner deiner Desktop-Umgebung (LXDE?) oder eine Datei .xinitrc in deinem Home-Verzeichnis oder global /etc/X11/xinit/xinitrc. Autostart über cronjob oder rc.local ist hier wohl der falsche Ansatz.

    In meinem Link in #16 zum Arch-Wiki findest du dazu auch zwei weiterführende Links, müsstest du dir mal ansehen. Vielleicht kommst du ja damit klar.

    Gruß Martin

    Hallo ThomasM99

    es gab da wohl mal ein Problem mit Xorg und dem Logitech-Treiber bei diesen Kombi-Tastaturen (Keyboard und Touchpad in einem Gerät). Sollte aber nicht mehr aktuell sein. Ich habe hier eine Logitech K400r und die funktioniert problemlos.

    Die Empfehlung zur Lösung war setxkbmap -layout de -variant nodeadkeys zu probieren und wenn es funktioniert, dies in Autostart oder .xinitrc einzubauen.

    Quelle: https://wiki.archlinux.org/title/Logitech…t_via_xorg.conf

    Gruß Martin

    /dev/sdb4 ist doch eine extended partition

    Wikipedia sagt dazu

    Zitat

    Eine erweiterte Partition dient als Rahmen für beliebig viele weitere logische Partitionen.

    Logische Partitionen liegen innerhalb des Speicherbereichs der erweiterten Partition. So kann es nur eine einzige erweiterte Partition geben (die als eine der vier möglichen Partitionen im MBR definiert ist), diese kann jedoch eine unlimitierte Anzahl weiterer logischer Partitionen enthalten. Logische Partitionen sind somit nicht in der primären Partitionstabelle definiert, da sowohl der Tabelleneintrag der logischen Partition innerhalb des Speicherbereichs der erweiterten Partition liegt, als auch der Speicherbereich der logischen Partition selbst.

    Gruß Martin

    Hallo Dodger ,

    hier hat jemand eine "Problemlösung" für den buggy Treiber mit dem Programm usbreset gefunden. Ist vielleicht eine Möglichkeit, wenn man das automatisiert ablaufen lässt. z.B. über Watchdog, Ping und Repair-Binary (siehe man watchdog und man watchdog.conf) oder über ein selbstprogrammiertes Ping-Script.

    Gruß Martin

    Hallo Woller

    Wenn du nur einen einzelnen Befehl ausführen möchtest, kann man das bei ExecStart=, ExecStop= und Co. direkt mit angeben, da muß man nicht unbedingt ein Bash- oder Python-Script erstellen. DefaultDependencies=no sollt man m.M.n auch sehr vorsichtig verwenden.

    Mein Vorschlag für eine Service-Unit ohne Schnickschnak würde dann z.B. so aussehen (Ich habs mal relais.service genannt):


    Auf Tippfehler und andere Probleme kann man eine selbstgeschriebene Systemd-Unit überprüfen mit:

    sudo systemd-analyze verify relais.service

    Keine Ausgabe heißt kein Fehler gefunden.

    Dann sudo systemctl daemon-reload zum Neuladen der Änderungen und systemctl reenable --now relais.service

    Ob die Service-Unit das macht, was man möchte, kann man ja einfach testen durch einen Stop der Unit:

    sudo systemctl stop relais.service

    und dann im Journal nachsehen mit sudo journalctl -eu relais.service ob etwas passiert ist.

    Wenns soweit funktioniert, wieder einschalten: sudo systemctl start relais.service und Pi neu starten.

    Was beim Shutdown passiert ist, kann man sich z.B. mit sudo journalctl -b -1 -e -u relais.service anzeigen lassen.

    Gruß Martin

    Hallo Flixm

    Deinen SEH UTNServer Pro kenne ich nicht, kann dazu leider nichts konkretes sagen.

    Wenn ich das richtig gelesen habe, ist das ja soetwas wie USB-over-IP?

    Dazu gibt es für Linux usbip - siehe z.B. hier, vielleicht lohnt sich ein Blick darauf, ich habs selber aber nie probiert.

    Gruß Martin

    EDIT:

    Aktuell scheitere ich daran wie ich ".deb" files installiere ???

    Gibt es bei SEH überhaupt ein .deb für die ARM-Architektur der Raspberry Pi's? Sieht so, aus als ob das nur für PC / X86-64 Architektur ist.

    Hallo Omegator ,

    Vorschlag zum Testen:

    Datei bei dir unter "/home/user/.config/autostart" z.B mit dem Namen tp-autostart.desktop erstellen mit folgendem Inhalt:

    Code
    [Desktop Entry]
    Name=touchpad-settings
    Comment=Autostart touchpad tap-to-klick
    Terminal=true
    Exec=xinput set-prop "SynPS/2 Synaptics TouchPad" "libinput Tapping Enabled" 1
    Type=Application
    Version=1.0

    ! Parameter set-prop "SynPS/2 Synaptics TouchPad" "libinput Tapping Enabled" 1 musst du prüfen, ob sie bei dir so passen !

    Vom Desktop abmelden und neu anmelden.

    Link zum weiterlesen: https://wiki.archlinux.org/title/Desktop_entries und dort auch weiterführende Links zu Autostart, ist zwar nicht Debian, sollte aber Linux - allgemein sein.

    Gruß Martin

    Guten Abend Omegator ,

    dann gehen mir auch die Ideen aus. Wenn du einen Hardware-Defekt definitiv ausschließen kannst, hatte ich im I-Net noch die Empfehlung gefunden, den alten Synaptics - Treiber statt libinput zu probieren für ältere Hardware. Ob der Treiber für dein System verfügbar ist und wie man das testen kann, weiß ich aber leider auch nicht.

    Gruß Martin

    Martin28 Nur weil es mir gerade aufgefallen ist, dass ich nicht angepingt/erwähnt wurde. Wenn Du jemanden erwähnen willst, dann schreib einfach ein @ vor den Usernamen. Der Username darf aber nicht verlinkt sein, was z.B. der Fall ist, wenn man einen Usernamen kopiert und einfügt.

    Dann muss man den Link vorher entfernen. ;)

    hyle Danke! :thumbup:

    hatte mich schon länger gewundert, warum das so kompliziert ist. Naja, graue Haare und Halbwissen halt. Jetzt hab ichs hoffentlich.

    Gruß Martin

    Hallo @omegator,

    Warum mein Vorschlag nicht funktioniert hat, weiß ich nicht, hatte das hier so ausprobiert mit den Parametern für mein Touchpad.

    Nur noch mal für mein Verständnis: mit deinem Script mit dem einzigen Befehl xinput set-prop "Touchpad_Device_Name" "libinput Tapping Enabled" 1 schaltest du ja nur das "Tippen zum Klicken" ein? Kenne ja deine Hardware nicht und ich habe auch nicht dein Betriebssystem hier am laufen.

    unter /home/user/bin liegt die touchpad.sh

    Bash
    #!/bin/sh
    
    xinput set-prop "Touchpad_Device_Name" "libinput Tapping Enabled" 1

    Was ich aber auch etwas sonderbar finde, heißt den Tochpad wirklich "Touchpad_Device_Name" ?? :conf: Was sagt bei dir grep -i 'using input' /var/log/Xorg.0.log und xinput list

    Wenn du einen anderen Weg versuchen möchtest:

    Gibt es für deinem Desktop nicht ein Einstellungsmenü für "Tippen zum Klicken? Ich erwende hier LXQT und da geht die Einstellung übers Menü --> Einstellungen --> Systemeinstellungen --> Konfigurationszentrum --> Tastatur und Maus --> Touchpad

    Sonst hat @hyle ja Vorschläge für Alternativen gemacht.

    Möglich wäre vielleicht auch eine Config-Datei z.b. /etc/X11/xorg.conf.d/30-touchpad.conf. Beispiel siehe hier: https://gist.github.com/fd0/d667c8b53620f44d862f und man xorg.conf, hab ich aber jetzt nicht getestet und ist vielleicht zu kompliziert.

    Gruß Martin

    Hallo @omegator,

    ich habs so getestet als systemd --user Dienst:

    Service-Datei erstellen mit nano ~/.local/share/systemd/user/touchp.service

    mit folgendem Inhalt:

    Die set-prop Parameter mußt du deinen Parametern anpassen.

    Dann den Service enablen: systemctl --user enable touchp.service und neu booten.

    mit journalctl --user -eu touchp kann man prüfen, was da gelaufen ist.

    sieht bei meinem Test so aus:

    Code
    Dez 03 12:04:50 p-k systemd[534]: Started Enable Touchpad.                                                                                                                           
    Dez 03 12:04:50 p-k systemd[534]: touchp.service: Main process exited, code=exited, status=1/FAILURE                                                                                 
    Dez 03 12:04:50 p-k systemd[534]: touchp.service: Failed with result 'exit-code'.                                                                                                    
    Dez 03 12:04:51 p-k systemd[534]: touchp.service: Scheduled restart job, restart counter is at 1.                                                                                    
    Dez 03 12:04:51 p-k systemd[534]: Stopped Enable Touchpad.                                                                                                                           
    Dez 03 12:04:51 p-k systemd[534]: Started Enable Touchpad. 

    Gruß Martin

    Guten Morgen,

    bei Systemd fehlt wohl eine saubere Abhängigkeit, um festzustellen, wann ein X-Server läuft, also soetwas wie After=(X-Server läuft) und Requires=(X-Server läuft) kann man wohl nicht machen. Eine Lösung wäre m.M.n. z.B mit

    Restart=on-failure

    RestartSec=2

    .

    Dann läuft der Service in einer Fehler-Restart-Schleife, bis der X-Server da ist.

    Der Richtige Weg ist Systemd hier m.M.n. trotzdem nicht.

    Glaube auch, daß Systemd hier das falsche Werkzeug ist, um dieses Problem zu lösen,

    Gruß Martin