GNOME Scan

Hi,

One anonymous comment worries about SANE 1.0.19 support by Gnome Scan. Well, i don’t have to do anything to support this bugfix release, please ask smart question to the right people, for instance your distribution.

However, i’m very concerned about SANE future. SANE is about to plan a 1.2 release including updated well-known options, additionnal frame type and other minor changes to the standard itself, without breaking compatibility. That’s an amazing news to see things moving around in SANE project. However, this mean also that SANE 2 won’t land before a while.

I’m very concerned by SANE due to its by-design mistakes. Nothing to be shame on, but this lead me to join the last comment about the drop of gnome-scan splash in 0.5 serie (Promised, i’ll add a waiting cursor while probing). Something i’m very sad about is that SANE 2 won’t change this. SANE 2 will not be the opportunity to fix design mistakes, but only to break the API in order to complete the design. SANE 2 is planned to be what SANE 1 should have been. SANE is still designed with only the backend point of view in mind, not the frontend. SANE should take both in account.

A good thing about SANE is the fact it’s in user space. No more kernel module. Just like printers, camera and some other devices. This is better for maintainability and stability. So kernel does not load some .ko. Now, it’s up to the frontend to load some .so (listed in /etc/sane.d/dll.conf and /etc/sane.d/dll.d on debian system). This design completely break hotplug : the frontend will never be launched before the driver. Even worse, the detection itself is done in frontend side. Frontend will never be launched after the device is recognized as a scanner. So, first problem is : no hotplug, by design. There have been some contorsion to plug this mistake, but that always failed.

Do you know why probing is so long ? Because each driver is loaded, and each driver walk all the device tree searching for known device. That’s quite crazy ! The more you have USB port, the longer the probe will take. Another problem steming from this design : no sensor/button handling is possible. You will never have a decent support for having the « push scan button on your device, click ok », or « insert paper, click ok » workflow. Your frontend won’t be launched on sensor/button event : the frontend itself must be launched before polling device registers. Actually, SANE standard doesn’t even talk about sensor, button or event. It’es completely up to the driver to design this. In SANE standard, a button is a feature of the scanner you can trigger by software (e.g. calibration).

I have some idea about what we need. Based on the work both in term of design and code, i started thinking of SANE 10 (or whatever). The idea is to use an architecture similar to Hurd servers, FUSE driver or HAL addon : the driver is standalone programm running in it’s own process, launched by HAL upon plug. The driver use a common backend library to expose a service through DBus/Avahi/Socket/whatever. Service will include procedure for scanning, but also signal for events, function for sharing, etc. The backend library will contains all common op for driver plus some helper. On the other side, a frontend library will allow frontends to talks to driver through native function, hiding DBus/Socket/etc.. Hal will just run lm983x hal://org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_1 or hplip-sane hal://org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_1, depending on some .fdi files shiped by the project.

I wish this word about SANE will clarify how gnome-scan interact with SANE but don’t trigger flames from anyone.

Regards,
Étienne.