Hi, ich habe einen Scanner der über USB angeschlossen ist und fünf Bedientasten hat. (Canon Lide 210) Alles gut, läuft ootb perfekt. Nur die Tasten haben eben keine Funktion. Ich habe auch ein Miniskript was eine Seite scannt und druckt. Kein Problem auch alles gut. So richtig gut wäre es nun wenn das Skript startet wenn die Taste 'Copy' am Scanner gedrückt wird. :-) Wie erreiche ich das? Irgendwas am Rechner muss ja mitkriegen das am Scanner die Taste gedrückt wird und dann darauf reagieren. Bernd -- Die normative Kraft des faktischen behindert die Entwicklung zum besseren.
Bernd Nachtigall schrieb:
ich habe einen Scanner der über USB angeschlossen ist und fünf Bedientasten hat. (Canon Lide 210) Alles gut, läuft ootb perfekt.
Nur die Tasten haben eben keine Funktion. Ich habe auch ein Miniskript was eine Seite scannt und druckt. Kein Problem auch alles gut.
So richtig gut wäre es nun wenn das Skript startet wenn die Taste 'Copy' am Scanner gedrückt wird. :-)
Wie erreiche ich das? Irgendwas am Rechner muss ja mitkriegen das am Scanner die Taste gedrückt wird und dann darauf reagieren.
Das ist wahrscheinlich vom Hersteller nicht dokumentiert, da das ja der Windows-Treiber sowieso macht. :-) Man kann das aber rauskriegen, weil man kann mittlerweile tcpdump oder wireshark auch auf USB-Busse machen. Vorher ein "modprobe usbmon", und dann wireshark auf das entsprechende usbmon<X>-Device machen, wo der Scanner dran hängt (sieht man mit lsusb -t). Wenn man dann weiß, was der Scanner da abschickt, kann man sehen, wie man da dran kommt. Vielleicht behauptet der Scanner ja, auch ein Human Interface Device zu sein und schickt einen besonderen thematisch passenden Tastendruck. Glaube ich aber nicht, auf solche Ideen kommen Hardware-Hersteller nicht, das wäre ja zu einfach... :-) Was immer geht, aber auch am kompliziertesten ist, ist, den Output von usbmon zu lesen und zu parsen, siehe https://www.kernel.org/doc/Documentation/usb/usbmon.txt -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
On 08.04.21 08:25, Bernd Nachtigall wrote:
ich habe einen Scanner der über USB angeschlossen ist und fünf Bedientasten hat. (Canon Lide 210) Alles gut, läuft ootb perfekt.
Nur die Tasten haben eben keine Funktion. Ich habe auch ein Miniskript was eine Seite scannt und druckt. Kein Problem auch alles gut.
So richtig gut wäre es nun wenn das Skript startet wenn die Taste 'Copy' am Scanner gedrückt wird. :-)
Wie erreiche ich das? Irgendwas am Rechner muss ja mitkriegen das am Scanner die Taste gedrückt wird und dann darauf reagieren.
Du suchst ggf. scanbuttond. Siehe z.B. https://linuxundich.de/gnu-linux/mit-einem-tastendruck-scannen/ Der ist aber per Default nicht installierbar, sonder müsste via https://software.opensuse.org/package/scanbuttond?search_term=scanbuttond bezogen werden. Viele Grüße Ulf
Am 08.04.2021 um 16:54 schrieb Ulf Volmer:
On 08.04.21 08:25, Bernd Nachtigall wrote:
ich habe einen Scanner der über USB angeschlossen ist und fünf Bedientasten hat. (Canon Lide 210) Alles gut, läuft ootb perfekt.
Nur die Tasten haben eben keine Funktion. Ich habe auch ein Miniskript was eine Seite scannt und druckt. Kein Problem auch alles gut.
So richtig gut wäre es nun wenn das Skript startet wenn die Taste 'Copy' am Scanner gedrückt wird. :-)
Wie erreiche ich das? Irgendwas am Rechner muss ja mitkriegen das am Scanner die Taste gedrückt wird und dann darauf reagieren.
Du suchst ggf. scanbuttond. Siehe z.B.
https://linuxundich.de/gnu-linux/mit-einem-tastendruck-scannen/
Der ist aber per Default nicht installierbar, sonder müsste via
https://software.opensuse.org/package/scanbuttond?search_term=scanbuttond
bezogen werden.
Ja richtig, so nennt sich das. Hab ich auch im Einsatz (gehabt). Scanne allerdings schon weit Ewigkeiten nichts mehr mit meinem Uralt Canon Lide Hab aber immer prima funktioniert Manfred
Ulf Volmer schrieb:
ich habe einen Scanner der über USB angeschlossen ist und fünf Bedientasten hat. (Canon Lide 210) Alles gut, läuft ootb perfekt.
Nur die Tasten haben eben keine Funktion. Ich habe auch ein Miniskript was eine Seite scannt und druckt. Kein Problem auch alles gut.
So richtig gut wäre es nun wenn das Skript startet wenn die Taste 'Copy' am Scanner gedrückt wird. :-)
Wie erreiche ich das? Irgendwas am Rechner muss ja mitkriegen das am Scanner die Taste gedrückt wird und dann darauf reagieren.
Du suchst ggf. scanbuttond. Siehe z.B.
Dieses Tool kannte ich bislang nicht. Es funktioniert aber auch nicht im Verbindung mit z.B. Canon-Scannern, weil es hoffnungslos veraltet ist (ist von Mitte der Nuller Jahre). Nachfolger ist scanbd und das funktioniert tatsächlich mit meinem Canon Lide 110... -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 09.04.21 um 06:40 schrieb Manfred Haertel, DB3HM:
Ulf Volmer schrieb:
(...)
Du suchst ggf. scanbuttond. Siehe z.B.
Dieses Tool kannte ich bislang nicht. Es funktioniert aber auch nicht im Verbindung mit z.B. Canon-Scannern, weil es hoffnungslos veraltet ist (ist von Mitte der Nuller Jahre). Nachfolger ist scanbd und das funktioniert tatsächlich mit meinem Canon Lide 110...
OK, danke! Da suche ich mal nach, im OS-Repo ist es leider nicht. Interessant ist evtl. das ich Ulfs Nachricht nicht sehe (!?) ... Hätte Manfred nicht geantwortet wäre mir das entgangen. Bernd -- Die normative Kraft des faktischen behindert die Entwicklung zum besseren.
Am 09.04.21 um 06:40 schrieb Manfred Haertel, DB3HM: (...)
Nachfolger ist scanbd und das funktioniert tatsächlich mit meinem Canon Lide 110...
So weit so gut, ich habe das mal aus scanbd-1.5.1-lp152.3.4.x86_64.rpm <https://download.opensuse.org/repositories/home:/malcolmlewis:/openSUSE_General/openSUSE_Leap_15.2/x86_64/scanbd-1.5.1-lp152.3.4.x86_64.rpm> installiert. Der Service und der Socket laufen lt. systemctl status. Auch im Journal sehe ich keine Probleme. Leider fehlt mir das komplette Verständnis bzgl. der interna von dbus, udev und dergleichen. Daher bekomme ich das wohl nicht ans laufen ... Wenn Du das ans laufen gebracht hast - magst Du mir ein paar Tipps geben? In der scandb.conf habe ich user und group auf daemon gesetzt. Anschließend startete der Dienst. Aber das in der scanbd.conf angegebene test.script wird nicht ausgeführt. (auch ein testweise eingetragenes eigenes Skript wird nicht ausgeführt) Ebenso ist im Journal keine Aktion zu sehen wenn ich auf einen Knopf am Scanner drücke. Was könnte/sollte ich nun prüfen? Bernd -- Die normative Kraft des faktischen behindert die Entwicklung zum besseren.
Hallo Bernd, Am 09.04.21 um 09:46 schrieb Bernd Nachtigall:
Am 09.04.21 um 06:40 schrieb Manfred Haertel, DB3HM: (...)
Nachfolger ist scanbd und das funktioniert tatsächlich mit meinem Canon Lide 110...
So weit so gut, ich habe das mal aus scanbd-1.5.1-lp152.3.4.x86_64.rpm <https://download.opensuse.org/repositories/home:/malcolmlewis:/openSUSE_General/openSUSE_Leap_15.2/x86_64/scanbd-1.5.1-lp152.3.4.x86_64.rpm>
installiert. Der Service und der Socket laufen lt. systemctl status. Auch im Journal sehe ich keine Probleme.
Leider fehlt mir das komplette Verständnis bzgl. der interna von dbus, udev und dergleichen. Daher bekomme ich das wohl nicht ans laufen ...
Wenn Du das ans laufen gebracht hast - magst Du mir ein paar Tipps geben?
In der scandb.conf habe ich user und group auf daemon gesetzt. Anschließend startete der Dienst. Aber das in der scanbd.conf angegebene test.script wird nicht ausgeführt. (auch ein testweise eingetragenes eigenes Skript wird nicht ausgeführt) Ebenso ist im Journal keine Aktion zu sehen wenn ich auf einen Knopf am Scanner drücke.
Was könnte/sollte ich nun prüfen?
Bernd
-- Die normative Kraft des faktischen behindert die Entwicklung zum besseren.
Da ich einen LIDE 110 habe und die 4 Taster bei mir auch nicht funktioniert haben, habe ich den Thread interessiert verfolgt und auch scanbd installiert. Ich habe "scanbd -f" unter root gestartet und aufgrund einer Fehlermeldung (die ich nicht mehr habe) in /etc/scanbd/scanbd.conf die Zeile "user = saned" auskommentiert und statt dessen "user = daemon" eingestellt. Dann konnte ich als root "scanbd -f" starten. Es kommen etliche Meldungen, so dass man die Reaktion auf die Tasten leicht übersehen kann. "scanbd -f|grep SCANBD_ACTION" ist da hilfreicher. Damit siehst du nur etwas, wenn eine der 4 Tasten gedrückt werden. scanbd: setting env: SCANBD_ACTION=scan scanbd: append string SCANBD_ACTION=scan to signal trigger scanbd: setting env: SCANBD_ACTION=scan scanbd: append string SCANBD_ACTION=scan to signal trigger Nur mit "scanbd -f" kommt bei einer Taste (wo es genau los geht und endet weiss ich nicht) scanbd: get_sane_option_value scanbd: Value of mode as string (len 4, hash 2089152600): Gray scanbd: setting env: SCANBD_FUNCTION_MODE=Gray scanbd: setting env: PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/opt/kde3/bin:/usr/lib/mit/sbin:/root/bin scanbd: setting env: PWD=/root scanbd: setting env: USER=root scanbd: setting env: HOME=/root scanbd: setting env: SCANBD_DEVICE=genesys:libusb:001:004 scanbd: setting env: SCANBD_ACTION=scan scanbd: append string genesys:libusb:001:004 to signal scan_begin scanbd: now sending signal scan_begin scanbd: append string SCANBD_FUNCTION_MODE=Gray to signal trigger scanbd: append string PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/opt/kde3/bin:/usr/lib/mit/sbin:/root/bin to signal trigger scanbd: append string PWD=/root to signal trigger scanbd: append string USER=root to signal trigger scanbd: append string HOME=/root to signal trigger scanbd: append string SCANBD_DEVICE=genesys:libusb:001:004 to signal trigger scanbd: append string SCANBD_ACTION=scan to signal trigger scanbd: now sending signal trigger scanbd: now flushing the dbus scanbd: unref the signal scanbd: using relative script path: test.script, expanded to: /etc/scanbd/scripts/test.script scanbd: waiting for child: /etc/scanbd/scripts/test.script scanbd: setgid to gid=486 scanbd: setuid to uid=2 scanbd: exec for /etc/scanbd/scripts/test.script scanbd: access: Datei oder Verzeichnis nicht gefunden scanbd: stat: Datei oder Verzeichnis nicht gefunden scanbd: execlp: Datei oder Verzeichnis nicht gefunden scanbd: child /etc/scanbd/scripts/test.script exited with status: 1 Es sieht für mich so aus, als ob /etc/scanbd/scripts/test.script aufgerufen wird, was es aber nicht gibt. Die *.script stehen in /etc/scanbd. Eventuell hilft ein Softlink "ln -s /etc/scanbd/scripts /etc/scanbd". Weiter bin ich noch nicht gekommen. Hoffe es hilft dir etwas. viele Grüße Werner
On 09.04.21 19:00, Werner Franke wrote:
scanbd: using relative script path: test.script, expanded to: /etc/scanbd/scripts/test.script scanbd: waiting for child: /etc/scanbd/scripts/test.script scanbd: setgid to gid=486 scanbd: setuid to uid=2 scanbd: exec for /etc/scanbd/scripts/test.script scanbd: access: Datei oder Verzeichnis nicht gefunden scanbd: stat: Datei oder Verzeichnis nicht gefunden scanbd: execlp: Datei oder Verzeichnis nicht gefunden scanbd: child /etc/scanbd/scripts/test.script exited with status: 1
Es sieht für mich so aus, als ob /etc/scanbd/scripts/test.script aufgerufen wird, was es aber nicht gibt. Die *.script stehen in /etc/scanbd. Eventuell hilft ein Softlink "ln -s /etc/scanbd/scripts /etc/scanbd".
Mangels passender Hardware kann ich das leider nicht ausprobieren. Aber Ihr solltet das scriptdir in der Config passend setzen können. Viele Grüße Ulf
Bernd Nachtigall schrieb:
In der scandb.conf habe ich user und group auf daemon gesetzt. Anschließend startete der Dienst. Aber das in der scanbd.conf angegebene test.script wird nicht ausgeführt. (auch ein testweise eingetragenes eigenes Skript wird nicht ausgeführt) Ebenso ist im Journal keine Aktion zu sehen wenn ich auf einen Knopf am Scanner drücke.
Wie schon gesagt, für mich war scanbd auch neu und ich fand es interessant, also habe ich gestern auch ein bisschen mit rumgespielt. Bei mir wurde zwar tatsächlich das Script ausgeführt - allerdings nur "meistens". In so einem Viertel des Fälle passierte einfach NICHTS. Es funktioniert ohnehin auch erst eine unbestimmbare Zeit nach dem Starten von scanbd. Und auch sonst passierten so einige Nickeligkeiten: In den Scripten ist ein unvollständiges bzw. falsches Environment - ich hatte einen bestimmten User eingetragen, aber $HOME wurde z.B. nicht passend gesetzt, sondern zeigte auf /root . Und auch die für mich wichtige Netzwerk-Ankopplung habe ich nicht wirklich zum Fliegen gebracht. Das Hauptproblem ist hier, dass scanbd das USB-Device geöffnet hält und es somit eigentlich anderweitig nicht mehr zugänglich ist. scanbd schließt zwar anscheinend das USB-Device, wenn es ein Script ausführt, aber man will ja auch immer noch mit einem normalen Scan-Programm scannen (und bei mir eben auch schon mal von einem anderen Rechner). Dafür kann scanbd als Proxy arbeiten, als Ersatz für den saned. Aber irgendwie hatte ich dabei auch schon im Ansatz undefinierbare Probleme, es funktionierte irgendwie nicht, laut strace hat scanbd einen falschen Port geöffnet, den ich dann aber wieder nicht mit netstat sehe usw. Dann verhält sich der scanbd als Daemon per systemctl gestartet irgendwie völlig anders als händisch gestartet, obwohl nix erkennbar anders ist. Irgendwie blockiert er da bzw. wartet auf irgendwas. Als die Liste der zu investigierenden Rand-Probleme immer länger wurde, habe ich abgebrochen. 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... -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
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. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
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.
Hallo Bernd Am 10/04/2021 um 10.49 schrieb Bernd Nachtigall:
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. ;-)
vielleicht hilft dir das weiter https://wiki.ubuntuusers.de/scanbd/ Holger
Holger Bruenjes schrieb:
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. ;-)
vielleicht hilft dir das weiter
Zumindest mir hat es NICHT geholfen, da mein System sich nicht oder zumindest nicht reproduzierbar so verhalten hat, wie da beschrieben... -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
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
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
Hallo Manfred, ich wollte mit meiner Frage gar nicht so einen Aufwand auslösen ... ;-) Am 18.04.21 um 20:05 schrieb Manfred Haertel, DB3HM: (...)
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. (...)
Da es aber besser mit sane zusammenzuarbeiten scheint als scanbd, könnte es trotzdem besser funktionieren... Du hast das nicht zufällig auf diesem SUSE 'Compilierungsportal' (ah ja, hier: build.suse.com) gemacht?
Mit dem selbst compilieren (und vor allem dem finden und entfernen der einmal selbst selbst compilierten Programme) in habe ich keine Erfahrung. Bernd
Bernd Nachtigall schrieb:
ich wollte mit meiner Frage gar nicht so einen Aufwand auslösen ... ;-)
Hast Du ja gar nicht, das Thema hat mich auch schon immer interessiert, aber ich hatte nie den richtigen Ansatz gefunden bzw. auch nie den richtigen "Drive" gehabt, ihn zu suchen, was sich jetzt halt geändert hat. Und auch mit USB wollte ich mich schon länger mal intensiver auseinander setzen, da passte halt grade alles...
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. (...)
Da es aber besser mit sane zusammenzuarbeiten scheint als scanbd, könnte es trotzdem besser funktionieren... Du hast das nicht zufällig auf diesem SUSE 'Compilierungsportal' (ah ja, hier: build.suse.com) gemacht?
Mit dem selbst compilieren (und vor allem dem finden und entfernen der einmal selbst selbst compilierten Programme) in habe ich keine Erfahrung.
Nö, habe ich auf meinem Rechner gemacht, im Grunde reichen (hier) folgende Kommandos (wenn man die notwendigen Entwicklungs-Tools installiert hat): git clone https://github.com/abusenius/insaned.git cd insaned/ make Mehr habe ich noch nicht getestet, aber wenn das schon mal nicht geklappt hätte (oder nur mit "Tricks"), hätte ich wohl kaum viel Energie reingesteckt. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
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
participants (6)
-
Bernd Nachtigall
-
Holger Bruenjes
-
Manfred Haertel, DB3HM
-
Manfred Kreisl
-
Ulf Volmer
-
Werner Franke