EXP C05 — Le moment où la Canon entre dans l’enquête

Le câble est là !

Jusqu’ici, nous avions fait quelque chose d’assez inhabituel :

Nous avions construit presque tout le serveur d’impression sans brancher l’imprimante.

Le Raspberry Pi était prêt.

Bookworm fonctionnait.

L’architecture armhf était en place.

Wi-Fi fonctionnait.

Avahi avait donné au serveur une identité :

PrintLBP.local

Et CUPS était accessible depuis le réseau.

Il ne manquait plus qu’une chose.

La Canon LBP-810.

Et maintenant, le câble était enfin arrivé.

Nous avions choisi un petit adaptateur deleyCON MK738 USB HighSpeed pour relier la vieille imprimante au Raspberry Pi Zero 2 W.

Cette fois, nous n’allions pourtant pas commencer par installer un pilote.

Nous n’allions même pas demander à Linux d’imprimer.

Nous voulions d’abord répondre à une question beaucoup plus élémentaire :

Est-ce que la Canon parle encore USB ?

Premier contact.

L’imprimante était allumée.

Le Raspberry Pi était prêt.

Nous avons commencé par ouvrir un terminal qui allait écouter les événements du noyau :

dmesg -w

Puis nous avons branché le câble USB.

Et presque immédiatement, le Raspberry a commencé à parler.

Les premières lignes intéressantes sont apparues :

usb 1-1: new full-speed USB device number 2 using dwc_otg

Puis :

usb 1-1: New USB device found, idVendor=04a9, idProduct=260a

Et enfin :

Product: Canon CAPT USB Printer
Manufacturer: Canon
SerialNumber: 511497ef

Bingo.

La Canon était réellement là.

Et nous avions déjà beaucoup plus d’informations que prévu.

Une identité USB très claire.

Le couple :

idVendor=04a9
idProduct=260a

nous donnait une identification précise du périphérique.

Vendor ID  : 04A9
Product ID : 260A

Le noyau annonçait lui-même :

Product: Canon CAPT USB Printer
Manufacturer: Canon

Ce n’était donc pas simplement une imprimante USB générique.

Et surtout, une autre ligne nous intéressait énormément :

usblp0: USB Bidirectional printer dev 2

Le pilote USB générique usblp avait pris en charge l’interface d’impression.

Nous venions donc de valider plusieurs couches d’un seul coup :

La couche matérielle était validée.

Et lsusb confirme.

Nous avons ensuite demandé à Linux de dresser la liste des périphériques USB :

lsusb

La réponse était exactement celle que nous espérions :

Bus 001 Device 002: ID 04a9:260a Canon, Inc. LBP810
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

La LBP-810 n’était donc pas seulement visible dans les messages du noyau.

Elle apparaissait parfaitement dans la pile USB normale de Linux.

Nous pouvions même vérifier le périphérique créé par usblp :

ls -l /dev/usb/lp*

qui nous donnait :

crw-rw---- 1 root lp 180, 0 Jul 30 18:42 /dev/usb/lp0

À ce moment précis, nous pouvions raisonnablement dire :

La Canon n’est pas un fantôme. Elle est bel et bien vivante.

Mais une imprimante détectée n’est pas encore une imprimante utilisable.

Maintenant, CUPS.

Nous avions volontairement construit CUPS avant de brancher la Canon.

Il était donc temps de voir si CUPS, lui aussi, voyait le nouveau périphérique.

La commande :

lpinfo -v

nous donna notamment :

network beh
file cups-brf:/
direct usb://Canon/LBP-810?serial=511497ef
network https
network http
network ipps
network ipp
network lpd
network socket

Et là, une ligne attirait immédiatement notre attention :

direct usb://Canon/LBP-810?serial=511497ef

CUPS avait donc découvert une URI USB native pour la Canon.

C’était une excellente nouvelle.

Nous n’avions pas besoin :

• d’inventer un backend USB ;
• de bricoler une communication particulière ;
• de créer un faux port ;
• ni même de deviner comment CUPS devait atteindre l’imprimante.

CUPS savait déjà où elle était.

Une imprimante visible n’est pas forcément une imprimante utilisable.

Et c’est ici que le projet devenait réellement intéressant.

Nous avions maintenant :

Raspberry Pi
      │
      ├── Wi-Fi
      ├── Avahi
      └── CUPS

et :

Raspberry Pi
      │
      ├── Wi-Fi
      ├── Avahi
      ├── CUPS
      │
      └── USB
            │
            ▼
        Canon LBP-810

Mais il manquait encore quelque chose.

CUPS savait où envoyer les données.

Il ne savait pas encore quoi lui envoyer.

C’est une distinction fondamentale avec les imprimantes modernes.

Détecter le périphérique USB ne signifie pas connaître le langage qu’il faut lui parler.

Et notre Canon utilisait justement un protocole propriétaire :

CAPT — Canon Advanced Printing Technology.

Nous avions donc franchi le problème matériel.

Nous arrivions maintenant au vrai problème logiciel.

Le pilote CAPT n’est pas là.

Nous avons tenté une autre vérification :

lpinfo -m | grep -i capt

Et cette fois…

rien.

Pas de pilote CAPT.

Pas de modèle Canon.

Pas de résultat.

Nous pouvions alors dresser un premier bilan :

Et soudain, le problème était parfaitement isolé.

Tout fonctionnait sauf ce qui devait réellement faire parler la Canon.

Retour dans le passé.

Il fallait donc retrouver un pilote.

Mais pas n’importe lequel.

La LBP-810 appartient à une époque où les pilotes Canon étaient très éloignés de l’écosystème d’impression moderne.

Nous avions déjà trouvé une piste particulièrement intéressante :

le projet libre CAPT de Nicolas Boichat.

Son projet capt-0.1 contenait notamment :

capt.c
capt.h
capt-print
Canon-LBP-810-capt.ppd
Makefile

Le projet datait de 2004.

Nous étions donc sur le point de demander à un petit programme C vieux de plus de vingt ans de fonctionner sur un Raspberry Pi Zero 2 W équipé d’un système Linux de 2026.

À partir de ce moment, notre serveur d’impression devenait aussi…

Un petit projet d’archéologie informatique.

Le premier obstacle n’était pas l’imprimante.

Nous avons commencé par compiler le pilote.

make

Et évidemment…

ça ne s’est pas passé comme prévu.

Le compilateur produisait plusieurs avertissements avant que l’édition de liens ne s’arrête sur des références manquantes liées notamment à :

errorexit

Il ne s’agissait pourtant pas d’un problème avec le Raspberry.

Ni d’un problème ARM.

Ni d’un problème USB.

Le problème venait du fait que le code avait été écrit avec les anciennes conventions du langage C et de GCC.

Après analyse du code et du mécanisme INLINE, nous avons réussi à le compiler en réactivant les anciennes sémantiques GNU :

gcc -std=gnu89 -O2 -g capt.c -o capt

Le vieux pilote compilait enfin sur notre Raspberry Pi.

Une chaîne de traitement vieille de vingt ans.

À mesure que nous étudiions le projet, son architecture devenait étonnamment claire.

Le PPD ne se contentait pas de décrire une imprimante.

Il indiquait comment transformer le document et appeler capt.

La chaîne ressemblait à ceci :

CUPS
  │
  ▼
Foomatic
  │
  ▼
Ghostscript
  │
  │  PBM 600 dpi
  ▼
capt
  │
  │  CAPT protocol
  ▼
/dev/usb/lp0
  │
  ▼
Canon LBP-810

C’était une architecture typique des anciens pilotes CUPS de cette génération.

Et le PPD contenait même une commande Foomatic capable de lancer directement capt.

Un détail particulièrement intéressant apparaissait dans :

-sOutputFile="|capt%B"

Le %B permettait à Foomatic d’ajouter automatiquement les options correspondant aux réglages du PPD.

Le projet avait également prévu une redirection vers :

/tmp/capt.log

pour faciliter le débogage.

Pour un pilote datant de 2004, c’était plutôt bien pensé.

Mais ce n’était pas encore gagné.

Le pilote était compilé.

Le PPD était disponible.

Nous pouvions installer :

/usr/bin/capt
/usr/bin/capt-print
/usr/share/cups/model/Canon-LBP-810-capt.ppd

et créer l’imprimante dans CUPS.

Puis nous avons lancé les premiers essais.

Et là :

Filter failed

La vieille Canon n’avait manifestement pas l’intention de nous faciliter la vie.

Mais les journaux nous ont appris quelque chose d’essentiel.

Ghostscript fonctionnait.

Le PPD était bien pris en compte.

Foomatic lançait le processus.

capt recevait les données bitmap.

Et même mieux :

le pilote construisait effectivement les paquets CAPT.

Le problème se situait désormais dans la communication finale avec l’imprimante.

Nous étions tout près.

Puis la page est sortie.

Après les derniers essais et ajustements…

le moment est arrivé.

Une page est sortie de la Canon LBP-810.

Normalement.

Le format était correct.

Les marges étaient correctes.

La chaîne complète fonctionnait.

Ce qui avait commencé comme une simple question — « Peut-on encore utiliser cette imprimante ? » — venait de devenir une réalité.

Une imprimante laser d’une autre génération fonctionnait avec :

Linux 2026
     ↓
CUPS
     ↓
Foomatic
     ↓
Ghostscript
     ↓
CAPT
     ↓
USB
     ↓
Canon LBP-810

Et nous avions une preuve encore plus intéressante.

Une preuve sur papier.

Nous avons retrouvé le scan d’une page de test Debian imprimée par la LBP-810.

La feuille indique :

Job ID: Canon_LBP-810-55
Driver: lbp810.PPD
Driver Version: 1.1
Description: Canon_LBP-810
Printer Location: RbPi0
Make and Model: Canon LBP-810 Foomatic/capt (recommended)
Printer: Canon_LBP-810

Et surtout :

Created at: Thu Jul 30 16:51:41 2026
Printed at: Thu Jul 30 16:51:41 2026

30 juillet 2026 — 16:51:41.

Cette vieille Canon avait réellement imprimé.

Pas dans une simulation.

Pas seulement dans l’interface CUPS.

Pas seulement dans une file d’attente.

Sur papier.

Mais une page n’est pas encore un serveur.

Cette première impression constituait une victoire importante.

Mais nous n’allions pas nous arrêter là.

Parce qu’une page de test prouve qu’une chaîne peut fonctionner.

Elle ne prouve pas encore qu’elle est suffisamment fiable pour devenir un véritable serveur d’impression domestique.

Il nous restait encore à comprendre certains comportements du pilote, son intégration avec CUPS, les différents modes d’accès depuis les ordinateurs du réseau et, surtout, la manière dont les clients allaient utiliser cette imprimante.

La suite allait justement nous réserver quelques surprises.

Et certaines d’entre elles seront particulièrement intéressantes parce qu’elles nous permettront de comparer Linux et Windows face exactement au même serveur.

Ce que nous venions réellement de démontrer.

À ce stade de l’enquête, nous pouvions déjà répondre à une première question fondamentale :

La Canon LBP-810 est-elle réellement utilisable depuis Linux ?

La réponse était désormais claire :

Oui.

Mais avec une condition essentielle :

il faut encore lui parler CAPT.

Et nous venions précisément de retrouver le langage oublié qui permettait de le faire.

La LBP-810 n’était donc pas morte.

Elle attendait simplement qu’on retrouve quelqu’un capable de lui parler.

À suivre …

(C06) — Quand ça marche… mais pas vraiment

Nous avons maintenant franchi le premier grand obstacle.

La Canon est détectée.

Le pilote CAPT fonctionne.

Une première page est sortie.

Mais nous allons maintenant nous intéresser à ce qui se passe réellement entre CUPS, IPP et le pilote CAPT, et aux différentes façons d’utiliser cette imprimante depuis nos machines du réseau.

Car une chose est déjà certaine :

nous n’avons pas ressuscité une imprimante pour la laisser seule dans un coin. :)

AxehGo & DebIA
Independent Research & Experiments in Linux, AI and Statistical Computing