Hallo! Jetzt hatte ich doch mal Zeit, es zu probieren und hey, ES FUNKTIONIERT! Bislang sogar "geschmeidig". Einfach insaned compilieren und als root starten. Nix konfigurieren! Er forkt sich dann in den Hintergrund, pollt einen eventuell gefundenen Scanner an (vermutlich sogar mehrere, wenn mehrere angeschlossen werden, ich hab nur einen). Drücke ich dann z.B. auf die Copy-Taste an meinem Scanner, wird das Script /etc/insaned/events/copy auf meinem Rechner ausgeführt, sofern es existiert und ausführbar ist. Wohlgemerkt, insaned weiß auch, welche Tasten mein Scanner hat, weil er sane gefragt hat (scanimage -A kann das übrigens auch anzeigen, was ich bislang nicht wusste). Außerdem liegen fertige Scripte für alle möglichen Buttons bei, die man ggf. anpassen muss (noch nicht probiert). Der wesentliche Unterschied zu scanbd ist jetzt der, dass insaned einfach das USB-Device wieder ZUMACHT, wenn er mit dem Pollen fertig ist. Scannt jemand, z.B. auch ohne Tastendrücken einfach per Programm auf dem Rechner, sagt ihm die sane-Library, dass jemand anders dran ist. Er legt dann eine Pause ein: insaned: Opening device 'genesys:libusb:001:004' insaned: opening device 'genesys:libusb:001:004' returned status DEVICE BUSY insaned: Failed to open device 'genesys:libusb:001:004' insaned: Reading sensors is suspended: 30 events left [...] (Zum Vergleich: scanbd hat das einfach umgekehrt gemacht, er hat sich zum Herrn im Hause erklärt und alle anderen sollten entweder beim Öffnen des Device scheitern oder ihn bitte als Proxy benutzen - nur dabei gab es bei mir halt "Effekte"...) So sollte das auch weiterhin gut und ohne Sollbruchstellen funktionieren. Es liegt sogar ein insaned.service für den systemd für's automatische Starten bei. Da gibt es noch ein kleines Problem, denn wenn kein Scanner angeschlossen ist, beendet sich insaned sofort. D.h. es ist wohl besser, wenn man den insaned über eine udev-Regel startet. Die liegt leider nichrt bei, dürfte aber schnell zu schreiben sein. Das alles zu wissen reicht mir erst mal, den Rest mache ich demnächst... Viele Grüße Manfred Manfred Haertel, DB3HM schrieb:
Hallo!
Ich habe noch ein relativ einfach aussehendes Programm für die Scanner-Buttons gefunden, was offensichtlich direkt mit den Sane-Libraries arbeitet und vom Entwickler dem README nach geschrieben wurde, weil er ähnliche Erfahrungen mit scanbd gemacht hat wie ich...
https://github.com/abusenius/insaned
Compilieren tut es schon mal unter Opensuse 15.2, zum probieren werde ich heute nicht mehr kommen, wenn ein anderer es schon mal machen will, wäre ich an Erfahrungen interessiert.
Und ja, es arbeitet auch mit Polling. Alle Recherchen deuten darauf hin, dass es nicht anders geht. Ob Windows stattdessen "irgendwas ganz geniales" macht, konnte ich bislang nicht in Erfahrung bringen, ich würde aber mal nicht davon ausgehen...
Da es aber besser mit sane zusammenzuarbeiten scheint als scanbd, könnte es trotzdem besser funktionieren...
Viele Grüße
Manfred
Manfred Haertel, DB3HM schrieb:
Hallo!
Das mit dem Polling bei USB hat mir keine Ruhe gelassen. :-)
Ich habe heute dazu noch ein bisschen Tests gemacht und auch recherchiert.
Mein Verständnis ist immer noch dass, dass bei USB immer der Host-Adapter das Device anpollen muss (so steht das auch auf verschiedenen Webseiten), womit eine gewisse Latenz durch die Poll-Rate entsteht, weil die muss erst mal abgewartet werden und kann nicht beliebig klein sein. Für Gamer soll das mit Mäusen ein Problem sein.
Aber anscheinend kann der Host-Adapter ohne Software-Unterstützung pollen! D.h. man sagt ihm, benutze diese oder jene Poll-Rate und dann macht er das. Aus Software-Sicht sieht es dann eben DOCH so aus, als könne auch das Device sich melden, wenn es Daten hat. So beobachtet mit Wireshark auf einem USB-Bus mit einer USB-Maus dran.
Aber hier muss natürlich auch das Device mitspielen. Es kann also sein, dass das bei den Scanner-Tasten eben nicht so funktioniert wie bei einer Maus.
Wenn man wüsste, was der Windows-Treiber bei den Scanner-Tasten macht...
Ich werde mich der Sache also irgendwann noch mal in Ruhe widmen. Vielleicht geht es ja doch mit "passivem Beobachten" per usbmon (ohne sane außer Tritt zu bringen). Wahrscheinlich nicht, sonst wäre so eine "Krücke" wie scanbd ja nicht geschrieben worden. Aber jetzt will ich es verstehen. :-)
Wenn jemand sich hier besser auskennt, darf er mich gerne belehren...
Viele Grüße
Manfred
Bernd Nachtigall schrieb:
Hallo Manfred,
vielen Dank für das teilen deiner Erkenntnisse :-)
Da ich auf diesen Gebieten nicht so versiert bin, hätte ich wahrscheinlich viel Zeit darin versenkt ehe ich frustriert aufgegeben hätte.
Außerdem habe ich nun so nebenbei erfahren das USB-Geräte keinen Interrupt auslösen können. Hoffentlich behalte ich das bis es für mich mal relevant ist. ;-)
Bernd
Am 10.04.21 um 06:34 schrieb Manfred Haertel, DB3HM:
Manfred Haertel, DB3HM schrieb:
Ich werde mir bei Gelegenheit mal anschauen, WIE scanbd den Tastendruck erkennt und dann versuchen, diese Lösung auf usbmon umzusetzen, was ich ja schon ganz zu Anfang vorgeschlagen hatte, als ich scanbd noch nicht kannte. Denn usbmon hätte den Vorteil, dass man eben NICHT das USB-Device öffnen muss, aber trotzdem mitlesen kann.
Daran hätte ich zumindest mal mehr Spaß als am Debugging undefinierbarer Randprobleme. :-) Aber keine Ahnung, wann ich dazu mal komme, denn die Scanner-Buttons sind derzeit nicht mein dringlichstes Anliegen...
Ich habe grade mal die Zeit gefunden, ein bisschen in den Source-Code zu "luchsen", konkret in das Genesys-Backend für die Canon-Scanner.
Meine Idee wird nicht funktionieren und eigentlich hätte mir das klar sein müssen. USB ist nämlich so designed, dass ein USB-Gerät eben NICHT einen Interrupt auslösen kann, wenn ihm danach ist (z.B. wenn eine Taste gedrückt ist), sondern man MUSS den Status anpollen. Das habe ich zwar schon mal gewusst, aber irgendwie verdrängt.
Das erklärt auch, warum mein Tastendruck manchmal nicht erkannt wurde. Er war einfach kürzer als das Poll-Intervall.
Steht auch in einem Kommentar:
// only the currently pressed keys are reported, if some key was pressed _and_ release betwee // the last an the current query it is not reported here, depending on the query frequence // the key needs to be holded for some time to be recognised
Man muss also "lang genug drücken".
Spätestens damit ist das Thema für mich uninteressant geworden.
-- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
-- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel