[gelöst] "headless"-Programme/Dienste und Eingabegeräte

[smutbert]

Hallo,

der eine oder andere wird sich vielleicht noch an mein kleines Musikspielerprojekt erinnern (Vorstellung einer Bastelei?!).
Der gute Cubietruck, der bis jetzt dort gelaufen ist, ist immer wieder mit kleineren Problemen unangenehm aufgefallen (Störgeräusche bei Speicherkartenzugriffen im sonst recht anständigen analogen Ausgang, schlechte Bluetooth- und sonstige Hardwareunterstützung in Debian, unerklärliche Störgeräusche mit USB-Soundkarten, die mit dem WLAN zusammenzuhängen scheinen,....), weshalb ich ihn nun durch einen Raspberry Pi 3 ersetzt habe.

Und wie ich im obigen Thread auch bereits erzählt habe, gibt es im Linuxkernel Treiber, die es erlauben Taster und Drehimpulsgeber als Eingabegeräte zu verwenden, ganz so als wären es Zeigegeräte und Tastaturen.
Diesen Raspberry-Pi-spezifischen Teil habe ich nun recht gut im Griff meine ich, aber mir bereitet eine andere Frage Kopfzerbrechen:


Mein Programm, das u.a. auf die Drehimpulsgeber und Taster reagieren soll, lief am Cubietruck im Hintergrund als systemd-Service, wo es direkt auf die Hardware zugegriffen hat um die gpios mit den Tastern und Drehimpulsgebern zu überwachen. Das sollte ja jetzt nicht mehr notwendig sein, aber wie komme ich in einem Hintergrunddienst am besten zu den Eingabeereignissen?

1. Für den normalsten Weg um zu Eingaben zu kommen müsste mein Programm ja im Vordergrund laufen – wäre es eine gute Idee meinen Dienst auf tty1 statt getty (?) zu starten?
2. Oder sollte ich doch lieber direkt auf die Eingabegeräte zugreifen (würde ich ev. mit python3-evdev machen) und den Dienst weiterhin im Hintergrund laufen lassen?
3. oder gibt es noch andere Möglichkeiten?

und kann ich bei 2. irgendwie verhindern, dass ich mit meinen per gpio angebundenen Tastern und Drehimpulsgebern, unbeabsichtigt ein im Vordergrund laufendes Programm bediene?

edit:
ich versuche es gerade mit 1. scheitere aber schon ganz am Anfang. Ich habe nicht die geringste Idee, wie ich via ssh ein Programm auf tty1 starten kann. Im Netz finde ich immer nur Beispiele mit einer Ausgabeumleitung auf tty1, aber mir geht es ja mehr um die Eingabe, die vom aktiven tty kommt (oder kommen soll).

lg Philipp

[NoobOfLinux]

Hi,

hilft dir da screen vielleicht weiter?

[EDIT] Ich hab mal das Ubuntu Wiki dazu befragt, nachfolgend die URL https://wiki.ubuntuusers.de/Screen/

[eggy]

@smubert: kannst Du Deine Software evtl per dbus oder pipe fernsteuern? Dann brauchst Dir keine Sorgen mehr darüber machen, was im Vordergrund ist und was nicht.

[smutbert]

screen hilft mir nicht oder zumindest sehe ich nicht wie und tmux nutze ich sowieso gelegentlich.

Mein Programm per pipe oder dbus steuern ginge, wenn ich lerne wie man das umsetzt (speziell bei dbus), aber auch da sehe ich nicht wie mich das weiterbringt.
Ich bin mir jetzt aber auch nicht ganz sicher ob ich an euren Tipps etwas missverstehe oder ich die Herausforderung blöd beschrieben habe:


Die Taster erscheinen am Raspberry Pi als je eine Tastatur mit der Taste <F1>, respektive <F2>, <F3>,... <F6> und die Drehimpulsgeber als je ein (einachsiges/eindimensionales) Zeigerät, das sich auf der Achse Nr. 5 bzw. 6 bewegt.
(Dass jedes der Bedienelemente als eigenes Gerät erscheint, lässt sich meines Wissens mit dem Treiber im Linuxkernel nicht ohne weiteres vermeiden.)

Was ich jetzt vermeiden wollte, war, dass ich mit den Bedienelementen statt oder zusätzlich zu meinem Programm auch die Textkonsole und in Folge agetty/den Login-Prompt bediene.

Gelöst habe ich es so, dass ich getty@.service, speziell getty@tty1.service komplett deaktiviere. Mein Programm läuft im Hintergrund und liest die Events direkt von den Eingabegeräten (mit python3-evdev).

[JTH]

mit python3-evdev

Hilft dir Folgendes aus der Doku: Getting exclusive access to a device? Ich nehme an, damit könntest du es dann wieder als systemd-Dienst oder beliebig anders laufen lassen.

[smutbert]

Das gefällt mir, wenn das geht. Das Laufenlassen als systemd-Dienst hat zwar vorher auch funktioniert, aber damit sollten jegliche Nebeneffekte durch meine eigenen Bedienelemente ausgeschlossen sein. Ich habe das jetzt für jedes Eingabegerät gemacht und mein Programm funktioniert immer noch.
(Normalerwesie muss ich nach jeder Änderung erst einmal auf Fehlersuche gehen )

Wie kann ich denn ohne (echte) Tastatur und Bildschirm testen ob an der Textkonsole tatsächlich keine Tastendrücke mehr ankommen?

[JTH]

Hmm, ich würde mich da einfach hauptsächlich mal drauf verlassen, dass das tut, was es verspricht

Du könntest ansonsten einfach dein Programm testweise zweimal gleichzeitig laufen lassen – das sollte ja nun einmal fehlschlagen. Oder du schaust mit

Code: Alles auswählen

lsof /dev/input/event*

mal, ob noch jemand anderes auf die Taster zugreift.

[smutbert]

Das sieht denke ich gut aus:

Code: Alles auswählen

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/bin/orpheus.py", line 61, in collect_input
    device.grab()
  File "/usr/lib/python3/dist-packages/evdev/device.py", line 298, in grab
    _input.ioctl_EVIOCGRAB(self.fd, 1)
OSError: [Errno 16] Device or resource busy

Dankeschön!

[JTH]

Biddeschön!