rklm schrieb:
icewave schrieb:
Ich arbeite derzeit an einem Rework meiner Codereader-Utils, ein paar Tools um eingelesene Codes aus einem Codereader einzulesen, ohne das dies über die stdin geschehen muss.
Meinst Du einen Barcode-Reader?
Genau. Also diese Teile wo vorne ein Laserstrahl rauskommt der die dann ließt, bzw. inzwischen gibt es auch welche die das via Kamera machen.
rklm schrieb:
icewave schrieb:
Zudem wollte ich Daten zu dem angeschlossenen Gerät ähnlich wie die Daten in /sys bereitstellen, also das Herstellerinfos, einlesbare Codes, whatever da aus Dateien ausgelesen werden können.
Problem daran ist nun: sowohl in /dev (für die named pipe) als auch /sys kann man nur Dateien erstellen, wenn man im Kernel ist. Eben das bin ich aber nicht, denn ich brauche unter meinem Daemon ja noch die Treiber um mit dem Gerät zu kommunizieren.
Den Satz habe ich nicht verstanden. Sind die Treiber nicht auch im Kernel? Oder sind das Userland Driver?
Die Geräte werden vom Kernel bereits erkannt - meist jedoch als ganz normale Tastatur. Ist nicht gerade schön wenn man versehentlich mit der Maus wo anders hin gekommen ist und dann 20 Codes fehlen ... Daher soll der Dämon das abfangen, verarbeiten und auf der anderen Seite in die Pipe jagen. Dafür ist es zunächst aber nötig, dass das Gerät an sich jedoch schon als "Tastatur" existiert, denn darauf baue ich auf. Ich wollte schließlich jetzt nicht das Rad neu erfinden und den Tastatur-Treiber auch noch ein Mal mit in meinen Treiber einfügen müssen. Wie man via USB kommuniziert sollte denke ich auch nicht mein Problem sein ...
rklm schrieb:
icewave schrieb:
Weiß da evtl. jemand eine akzeptable Lösung, die nicht 08/15 ist?
Ich bin jetzt kein Kernel-Hacker, aber eine logische Lösung erscheint mir zu sein, den ganzen Code, der auf das Gerät zugreift und irgendwelche Objekte in /sys oder /dev erstellt, in ein ladbares Kernel-Modul zu packen. Möglicherweise wird dann der Dämon überflüssig.
Ein Codereader ist nicht eindeutig identifizierbar, denn v.a. die billigen haben einen USB-Controler verbaut, den auch normale Tastaturen, Magnetkartenleser, etc. besitzen. D.h. es könnte nicht direkt das richtige Kernel-Modul ausgewählt werden.
Zudem gibt es die "einfachen" Tastatur-Emulatoren, es gibt aber auch Barcode-Reader, welche irgendwie über RS232 angesteuert werden möchten. Daher habe ich bewusst den Dämon als Zwischeninstanz gewählt, um diesen je nach Barcode-reader durch einen anderen ersetzen zu können, der das jeweilige Protokoll spricht und auf der anderen Seite kommt dann immer standardisiert nur der Code mit \n am Ende in die Pipe rein. Somit muss die Endanwendung nicht wissen was das für ein Barcode-Reader ist und ich denke das sollte auch das Ziel sein, denn das ist ja Sache des OS ☺
Nun geht es halt darum, dass ich nicht an die Standard-Orte für die Daten komme, denn device-files (meine Pipes) gehören eigtl. nach /dev und Geräteinfos nach /sys. Und unschön wäre nun ein neuer Platz unter /var/spool oder whatever ...
Achja und noch ein Punkt gegen Kernel-Module: Kernel ist root-Bereich. Ich will jetzt nicht sagen das ich ein schlechter/dummer Programmierer bin, jedoch muss es ja nicht unbedingt unter root laufen, wenn es nicht unbedingt sein muss, oder?
Liebe Grüße,
icewave