Jérôme Flesch a écrit 345 commentaires

D'après le rapport, c'est l'API WIA2 qui a utilisée. Libinsane n'a pas trouvé la DLL TWAIN.

Et effectivement, ce n'est pas le bon nom qui s'est affiché. C'est un point qu'il faut que je travaille.

En fait j'ai cru que tu avais voulu lancer IronScanner depuis ses sources comme rapido l'avait fait. Je viens de réaliser que toi tu as utilisé le binaire IronScanner.

Toutes les dépendances du binaire devrait être incluses dedans. Cependant il y a visiblement un soucis dans le packaging de IronScanner qui fait qu'il cherche quand même à utiliser quelques librairies du système.

En attendant que je trouve comment régler ça proprement, je pense qu'installer les paquets suivants devrait régler le problème:

sudo apt install \
    python3-gi libgirepository1.0-dev gobject-introspection \
    gir1.2-gdkpixbuf-2.0 gir1.2-gtk-3.0

Nop, même idée. Il faut juste espérer que le trafic réseau n'est pas chiffré …

J'ai commité un fix dans la Libinsane et j'ai rebuildé IronScanner. Le fix n'est pas aussi propre que ce que j'aurais voulu, mais ça permettra déjà de confirmer que c'est bien le problème que je pense.

De ce que j'en ai compris, le problème est que le pilote de son scanner founit une source de numérisation 0000\\Root\\Auto. Je suppose que si utilisée, elle sélectionne automatiquement une des sources qui a du papier. Problème: elle ne fournit pas les options requises par Libinsane et IronScanner (resolution et mode), et ça a l'air de faire planter IronScanner. Donc là j'ai patché Libinsane pour qu'elle l'ignore.

Est-ce que tu pourrais retélécharger IronScanner et réessayer s'il te plait ?

Malheureusement, on tape en plein dans le problème de la diversité des distributions Linux … :/. Pour ma part, je ne teste que sur Debian, Ubuntu, et plus rarement sur Fedora. Comme je fais ça sur mon temps libre, je peux difficilement assurer le support des autres distributions :(

En supposant qu'il s'agit d'un scanner USB, ce que je ferais:

• Voir si il n'y a pas des applications tierces opensource (non-Sane) qui le supporte. J'avais un vieux scanner supporté comme ça il y a longtemps par exemple.
• sniffer le trafic USB avec Wireshark:
  • tout en sniffant, faire un scan d'une page rouge, puis d'une verte, puis d'une bleue (ça suppose que le scanner est en RGB, mais ça devrait aussi permettre de voir si le scanner est en CMYK ou dans un autre espace de couleur fantaisiste).
  • tout en sniffant, essayer des scans en changeant juste un réglage à chaque fois.
• jouer aux devinettes
• jouer avec pyusb et le scanner pour voir si ces devinettes sont tombées juste
• rajouter un backend à sane et soumettre un patch

Et il marche avec l'application "Numérisation et Fax" de Windows ?

Ok en fait cette question est inutile. Je vois bien le scanner dans les traces du rapport donc il marche sûrement avec "Numérisation et Fax. Par contre il manque l'option "resolution", ce qui est sacrément étrange vu que cette option est normalement rajoutée par Libinsane.
Va falloir que je creuse ça.

le scanner n'apparait pas dans la liste.

Et il marche avec l'application "Numérisation et Fax" de Windows ?

Apparemment, os.uname ne marche pas sous Windows, il faudrait utiliser platform.uname à la place.

Bonne remarque. Ce warning est non-bloquant mais je vais voir pour corriger ça.

Y a-t-il une solution simple, ou reconstruire l'exécutable à partir des sources est-elle la seule ?

Je ne vois que deux solutions malheureusement:

• Le lancer à partir des sources + un virtualenv python (voir le readme sur gitlab)
• Faire un schroot Debian Buster

Bizarre, toutes les dépendances devraient être incluses dans le binaire. Essaye voir en installant ce paquet: libgdk_pixbuf-gir2.0

Fait, ça a marché.

\o/

Ils seront détectés ?

Si ils sont installés sur la machine, ils devraient l'être. Une façon de confirmer qu'ils sont bien installés est de lancer l'application "Numérisation et Fax" de Windows et de voir si elle les trouve.

Bon, rebelote.

Le backend Genesys dit que la Libinsane ne peut pas changer la valeur de l'option source parce-qu'elle est inactive (sauf que c'est lui qui la met inactive, donc ça me fait une belle jambe ..).

Pour l'heure, je viens de contourner le problème en acceptant simplement qu'on ne puisse pas changer la valeur de cette option.

Est-ce que tu peux essayer encore une fois s'il te plaît ? (merci pour ta patience)

En fait il y a une légère différence d'objectif entre libsane et libinsane:
- Libsane cherche à apporter un support pour un maximum de périphériques d'acquisition d'images, sans trop se soucier de quel type de périphériques il s'agit exactement ou de comment les applications vont interagir avec.
- Libinsane cherche à supporter les mange-papiers (et que les mange-papiers) le mieux possible, en fournissant un protocole précis pour interagir avec eux.

De ce que j'en ai vu, la libsane passe les appels des applications quasi-directement aux backends (pilotes). On pourrait rajouter une surcouche directement dans la libsane pour essayer de normaliser tout ça, mais on risquerait de perdre en flexibilité: Parce-qu'elle impose très peu aux pilotes, pratiquement tout ce qui génère une image peu être intégré dans la libsane. Il y a même un backend v4l (video4linux ; support des caméras ; désactivé par défaut dans Sane).

Deux exemples:
- La plupart des backends Sane propose une option source. Mais la libsane ne normalise pas du tout les valeurs possibles pour ce champs. Cette option acceptera généralement les valeurs Flatbed et Automatic Document Feeder. Mais il y a par exemple les scanners Canon CanoScan N1240U/LiDE30 qui ont pour sources possibles Normal, Transparency et Negative. Seule la première valeur est pertinente dans le cas de Libinsane. Les autres marcheront peut-être sur un malentendu mais ne sont pas officiellement supportées.
- La plupart des backends Sane propose les options tl-x, tl-y, br-x, br-y pour définir la zone à scanner. Le backend v4l) ne les proposent pas. La libinsane devrait fonctionner même si ils sont absents, mais c'est plus un coup de bol qu'autre chose.

Ça va déjà un peu plus loin, mais ça coince toujours. Que ce soit en voulant consulter la valeur de l'option "source" ou en voulant la modifier, le driver répond INVAL.

J'ai modifié IronScanner pour qu'il active les traces du pilote Genesys. Avec un peu de chance, ça nous dira pourquoi le pilote refuse toute manipulation de l'option 'source'. Pourrais-tu relancer un test avec la dernière version de IronScanner s'il te plaît ? (pour le binaire, le build est encore en cours).

Le rapport est incomplet. Il manque les informations concernant le scanner. Et le serveur balance une exception en tentant de chercher les infos du scanner dans le rapport (j'ai codé ça à la va-vite).

La question pour moi, c'est comment est-il possible que le rapport soit incomplet ?

Quand tu lances IronScanner, il indique qu'il met ses traces dans un fichier temporaire. Pourrais-tu m'envoyer ce fichier par email ( jflesch@openpaper.work ) s'il te plaît ?

J'ai commité un possible correctif et IronScanner a été reconstruit avec. Peux-tu le retélécharger et le relancer s'il te plaît ? (si tu l'avais lancé à partir des sources: git pull && source ./activate_test_env.sh && make clean && make install && ironscanner)

Je soupçonne que ce driver n'accepte pas qu'on mette comme valeur la valeur déjà en place (source=Flatbed ; déjà vu ça avec d'autres pilotes) et renvoi EINVAL. Je soupçonne aussi qu'il marque l'option source comme inactive (non-lisible) alors qu'elle l'est. --> J'ai autorisé la lecture de l'option source malgré le flag INACTIVE. Je pense que ça devrait débloquer la situation.

'fectivement, j'avais manqué quelques autres dépendances (GTK, GdkPixbuf notamment). C'est rectifié.

Bien vu. C'est rajouté.

J'en profite pour clarifier un truc rapidement: Même si le scan échoue, IronScanner vous laisse soumettre un rapport de scan. Personnellement ça m'arrange si vous le soumettez quand même. Le site openpaper.work présente les informations d'une façon plus pratique pour moi et fournit des statistiques sur ce qui marche et ce qui ne marche pas.

il semble que ce soit un problème de droits

Je suppose que c'est cette trace qui t'as fait pensé ça: source->get_value() failed: 0x40000008, Access denied ? Mais en fait c'est un peu plus fourbe que ça.

Si c'était un problème de droit, il ne verrait même pas le scanner.

Là il le voit, mais n'arrive pas à accéder à la valeur de l'option source. Quand le programme tente de sélectionner la source, un des composants de la Libinsane cherche à s'assurer que la valeur qu'on veut y mettre n'est pas déjà la valeur courante (certains pilotes crash dans ce cas …). Quand il tente d'accéder à la valeur de source, un autre composant vérifie qu'on a le droit de demander cette valeur au pilote (certains pilotes crashent si on cherche à lire une valeur d'option dans une option inactive …). Ici le pilote a indiqué qu'on n'a pas le droit de lire la valeur de l'option source (probablement une erreur …), et donc le composant Libinsane qui vérifie les droits renvoie "Access denied".

Tout ça pour dire que le problème est après: Faute d'avoir pu consulter la valeur courant de l'option source, le composant Libinsane autorise l'écriture. Et là paf, le backend répond genesys:libusb:003:002->source->sane_control_option(SET_VALUE) failed: 0x40000003, Invalid value. Pourtant la valeur passée me semble correcte.

Est-ce que tu parviens à scanner avec un autre programme type simple-scan ?

Ça c'est toujours une bonne question :-)
Parce-que si ça ne marche pas avec simple-scan, le problème ne vient sûrement pas de la Libinsane.

Le binaire IronScanner est construit pour amd64 uniquement. Tu ne serais pas en i386 sur ta machine par hasard ?

Si c'est le cas, il reste la possibilité de lancer IronScanner à partir de ses sources.

Effectivement, dans les instructions, il manquait le paquet virtualenv. Merci de me l'avoir signalé. C'est rectifié.

Je vais jeter un coup d'œil au code de Gsane, des fois que tu avais des fixs que je n'ai pas encore :)

D'ailleurs, SANE2 n'est jamais sortie, non ?

Il ne me semble pas. Et ce n'est pas une mince affaire parce-que je suppose que ça implique de refaire une passe sur tout les backends/pilotes, et comme il y en a certains qui sont propriétaires (Brother par exemple) …

AttributeError: module 'PIL' has no attribute 'Image'

Arf. Je note que selon la version de PIL, on peut accéder à PIL.Image sans faire import PIL.Image :-)
C'est rectifié. Merci de me l'avoir signalé.

Ah, c'est .. gênant. Sur un scanner à plat, il devrait s'arrêter après la première page. Sur un scanner à bac d'alimentation, il devrait s'arrêter une fois le bac vide.

Lorsque IronScanner est lancé depuis un terminal, il indique qu'il met ses traces dans un fichier temporaire. Pourrais-tu m'envoyer ce fichier à jflesch@openpaper.work s'il-te-plaît ? (deux ou trois pages de scans suffiront ;).

Elles sont complémentaires.

Libsane = Librairie pour accéder aux scanners sous GNU/Linux (et FreeBSD, etc). Elle fait partie du projet Sane et fait elle-même appel aux sane-backends: les pilotes. Elle a toutefois un défaut: Le design de la libsane fait qu'elle laisse beaucoup de libertés aux pilotes des scanners, ce qui implique des comportements parfois différents d'un pilote de scanner à un autre.

Libinsane = Librairie pour accéder aux scanners GNU/Linux et Windows. Sous GNU/Linux, elle utilise la Libsane (d'où son nom). L'objectif, en plus d'être cross-platform, est de fournir un comportement cohérent quelque-soit le système d'exploitation, l'API (Sane, WIA, TWAIN, etc), ou le pilote utilisé.

Je construit les binaires sur une Debian stable et je ne la teste pas avec des librairies plus vieilles que celles dans Debian stable / Ubuntu LTS. Ça serait trop de travail pour moi.

Dans ton cas, il reste la possibilité de lancer IronScanner à partir des sources.