EXP C06 — Quand ça marche… mais pas vraiment

EXP C06 — Quand ça marche… mais pas vraiment

Une première page est sortie.

Le 30 juillet 2026, à 16:51:41, nous avions obtenu quelque chose que nous n’étions même pas certains de pouvoir obtenir quelques jours auparavant :

la Canon LBP-810 avait imprimé sous Linux.

La feuille de test portait toutes les informations nécessaires :

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

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

La chaîne complète fonctionnait donc au moins une fois :

Linux
  ↓
CUPS
  ↓
Foomatic
  ↓
CAPT
  ↓
USB
  ↓
Canon LBP-810
  ↓
paper

Mais une première impression réussie ne signifiait pas que nous avions compris pourquoi tout fonctionnait.

Et surtout, elle ne signifiait pas que nous avions terminé.

« Filter failed »

En poursuivant les essais, nous avons rencontré un message particulièrement peu encourageant :

Filter failed

Dans les journaux, nous pouvions pourtant observer quelque chose de très intéressant.

Le traitement de la page avançait.

Ghostscript générait les données.

Foomatic lançait le filtre.

Et capt travaillait effectivement sur les données CAPT.

Le journal montrait notamment :

Packet 0 flushed
Packet 1 flushed
Packet 2 flushed
...

Autrement dit, le problème n’était probablement pas la génération de l’image.

Le vieux pilote savait encore faire son travail.

C’était déjà une information capitale.

Le pilote n’était peut-être pas coupable.

Nous avions naturellement tendance à suspecter capt.

Après tout, c’était le morceau de logiciel le plus ancien de toute la chaîne.

Mais les indices racontaient une autre histoire.

La chaîne :

Ghostscript
    ↓
Foomatic
    ↓
capt

fonctionnait suffisamment longtemps pour produire les paquets d’impression.

Puis apparaissait :

Invalid printer state, printer not connected ?

Le problème devenait donc beaucoup plus précis :

Le pilote sait préparer les données, mais quelque chose ne va plus au moment où il doit communiquer avec l’imprimante.

Et cette distinction allait nous faire gagner énormément de temps.

Que fait réellement capt ?

Nous avons donc cessé de regarder uniquement CUPS et commencé à regarder le vieux programme lui-même.

Une recherche dans capt.c nous a conduits directement à la ligne qui produisait le message :

Invalid printer state, printer not connected ?

Elle se trouvait à la ligne 604 :

fprintf(stderr, "Invalid printer state, printer not connected ?\n");

Cela nous donnait enfin un point précis dans le code.

Mais une autre information était encore plus intéressante.

En examinant le fonctionnement de capt, nous avons découvert qu’il ne comptait pas sur CUPS pour parler directement à l’imprimante.

Le programme ouvrait directement :

/dev/usb/lp0

avec :

fd = open("/dev/usb/lp0", O_RDWR | O_NONBLOCK);

Et là…

nous avions peut-être trouvé le vrai problème.

CUPS ouvre déjà l’imprimante.

Souvenons-nous de notre configuration.

Lorsque nous avions créé l’imprimante dans CUPS, son URI était :

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

C’était parfaitement logique.

CUPS détectait la Canon et nous lui avions naturellement demandé de l’utiliser comme une imprimante USB.

Mais cela signifiait que CUPS utilisait son propre backend USB.

Notre chaîne ressemblait donc, en simplifiant, à ceci :

CUPS
  │
  ├── USB backend
  │
  └── Foomatic
        │
        ▼
      capt
        │
        ▼
    /dev/usb/lp0

Et capt, lui, voulait également ouvrir :

/dev/usb/lp0

Nous avions donc potentiellement deux acteurs qui voulaient gérer le même périphérique.

Le message qui change tout : EBUSY

Nous avons alors utilisé strace pour regarder ce qui se passait réellement.

Et nous avons obtenu :

open("/dev/usb/lp0", O_RDWR|O_NONBLOCK) = -1 EBUSY

EBUSY.

Device or resource busy.

Et soudain, l’erreur devenait parfaitement logique.

La Canon était connectée.

Linux la voyait.

usblp la voyait.

CUPS la voyait.

capt fonctionnait.

Mais lorsque capt voulait ouvrir directement le périphérique, quelqu’un l’avait déjà pris.

Le suspect principal n’était donc plus capt.

C’était CUPS.

Retour en 2004.

Et c’est ici que notre vieux pilote allait nous donner un indice extraordinaire.

Le projet capt-0.1 avait été conçu à une époque où son architecture était légèrement différente.

Le principe était essentiellement :

Ghostscript
      │
      ▼
    capt
      │
      ▼
/dev/usb/lp0

CUPS servait surtout à lancer le filtre.

Il n’était pas nécessaire qu’il gère lui-même la communication USB avec l’imprimante.

Or nous avions naturellement construit une configuration plus moderne :

Ghostscript
      │
      ▼
    capt
      │
      ▼
USB backend CUPS
      │
      ▼
   printer

Le problème était donc peut-être simplement que nous avions donné à CUPS un travail que capt voulait faire lui-même.

Le vieux README avait laissé un indice.

En relisant la documentation de capt-0.1, nous avons retrouvé une indication particulièrement intéressante :

le pilote ne devait pas nécessairement être configuré avec le véritable port USB ; il pouvait utiliser un dummy serial port.

Cette vieille documentation, écrite pour un logiciel vieux de plus de vingt ans, commençait soudain à avoir beaucoup de sens.

Il fallait empêcher CUPS de prendre possession du périphérique USB.

Mais comment ?

Et puis nous avons eu une idée assez folle.

Nous pouvions donner à CUPS un périphérique qui n’était pas l’imprimante.

Un périphérique qui accepterait ce que CUPS lui envoie…

sans prendre possession de la Canon.

Et nous avions justement un candidat idéal sous Linux :

/dev/null

Le jour où nous avons envoyé l’imprimante vers /dev/null

Nous avons donc remplacé le périphérique USB de CUPS par :

file:///dev/null

À première vue, cela semblait complètement absurde.

En réalité, cette modification changeait simplement la répartition des responsabilités.

CUPS n’allait plus ouvrir le périphérique USB de la Canon.

Il allait simplement lancer la chaîne de filtres.

Pendant ce temps, capt pouvait continuer à ouvrir directement :

/dev/usb/lp0

La nouvelle architecture devenait :

CUPS
   │
   ▼
Foomatic
   │
   ▼
capt
   │
   └──────────────► /dev/usb/lp0
                          │
                          ▼
                       Canon

CUPS ───────────────► /dev/null

Et voilà pourquoi le fameux /dev/null n’est pas une plaisanterie.

CUPS ne devait pas réellement imprimer vers /dev/null.

Il devait simplement cesser de s’occuper de l’USB.

Le véritable dialogue avec la Canon restait entre les mains de capt.

Et soudain …

La configuration CUPS affichait :

Connection: direct

et :

device-uri=file:///dev/null

tandis que le pilote restait :

Canon LBP-810 Foomatic/capt (recommended)

Et surtout…

la Canon imprimait encore.

Une nouvelle page de test est même sortie après cette modification.

La configuration qui semblait complètement absurde était donc devenue une configuration CUPS parfaitement fonctionnelle.

Ce que nous venions de comprendre.

La solution n’était pas un nouveau pilote.

Nous n’avions pas modifié l’algorithme CAPT.

Nous n’avions pas remplacé CUPS.

Nous n’avions pas supprimé usblp.

Nous avions simplement corrigé la répartition des responsabilités.

CUPS
 │
 ├── receives the job
 ├── launches Foomatic
 └── no longer touches USB
             │
             ▼
          capt
             │
             ▼
         /dev/usb/lp0
             │
             ▼
         Canon LBP-810

C’était finalement très élégant.

Et surtout, cela expliquait enfin pourquoi un pilote écrit en 2004 pouvait continuer à fonctionner sur un système Linux moderne.

Nous n’avions pas essayé de transformer capt en pilote moderne.

Nous avions simplement recréé l’architecture pour laquelle il avait été conçu.

Une seule ligne.

Après des heures passées à examiner :

• le code C ;
• GCC ;
• Ghostscript ;
• Foomatic ;
• CUPS ;
• usblp ;
• les permissions ;
• les journaux ;
• strace ;
• les erreurs Filter failed ;
• et EBUSY…

la solution finale pouvait presque tenir sur une seule ligne :

DeviceURI file:///dev/null

C’est probablement l’un des moments les plus satisfaisants de toute l’expérience.

Parce que nous n’avions pas simplement trouvé une commande qui marchait.

Nous avions compris pourquoi elle marchait.

Une vieille imprimante, une vieille idée.

Il y avait quelque chose d’assez amusant dans cette découverte.

Nous avions passé plusieurs jours à essayer de faire entrer une imprimante de la fin des années 1990 dans une architecture d’impression moderne.

Et finalement, la solution consistait en partie à revenir au principe architectural prévu par son vieux pilote.

2026
CUPS modern
       │
       ▼
Foomatic
       │
       ▼
capt — 2004
       │
       ▼
/dev/usb/lp0
       │
       ▼
Canon LBP-810

Nous n’avions pas vraiment modernisé la Canon.

Nous avions appris à laisser deux générations de logiciels travailler ensemble.

Une victoire… mais pas encore la fin.

À ce stade, la configuration était fonctionnelle et nous avions enfin compris le fameux problème EBUSY.

Mais il restait encore à démontrer quelque chose de plus important :

Est-ce que cette vieille imprimante peut réellement devenir une imprimante réseau utilisable depuis les ordinateurs de la maison ?

Le Raspberry n’était plus seulement capable de faire imprimer une page localement.

Il fallait maintenant tester la chaîne complète :

computer
    ↓
network
    ↓
IPP / CUPS
    ↓
Raspberry Pi
    ↓
Foomatic / CAPT
    ↓
Canon LBP-810

Et c’est là que l’aventure allait prendre une nouvelle direction.

À suivre …

(C07) — De l’imprimante USB au véritable serveur réseau

La Canon sait maintenant imprimer depuis le Raspberry.

Mais notre objectif initial n’était pas de construire un ordinateur auquel il faudrait se connecter avec un câble.

Nous voulions une véritable imprimante réseau.

Dans le prochain chapitre, nous allons donc quitter progressivement le monde du dépannage USB pour vérifier que la LBP-810 peut être utilisée depuis Kubuntu, puis depuis Windows, en passant par le serveur d’impression.

Et nous allons découvrir quelque chose d’assez amusant :

Windows n’aura finalement pas besoin de Samba. :)

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