HAL and scanners

[abel deuring]

Étienne Bersac wrote:
> Hi,
> 
>>IMHO, a button handler is something for a desktop environment or a
>>dedicated scan program; there are too many policy related questions
>>than to place it into HAL or make the handler a Sane "core
>>function".
> 
> HAL is able to tel apps that a device has been plugged. A similar event
> must be sent by hal on scanner button press. This avoid desktop to
> implement another dbus daemon for each session. Let the desktop decide
> what to do with on this event. Also, such feature force software to open
> the device; device access may be exclusive, SANE calls must be in one
> software at one time.

[I'm afraid that we're now becoming a bit off-topic regarding HAL,
but anyway:]

There is a reason for exclusive access to a scanner: It is quite
hard to allow conflict-free concurrent access to a scanner by more
than one program. Imagine that program 1 reads scan data, while
program 2 changes the scan mode from "RGB" to "gray". Simple usage
of O_EXCL in the open() call avoid any such conflicts.

> 
>>If you or Martin want to give these advanced (to avoid the word
>>"bloat" ;) things a try nevertheless in the HAL context -- fine, but
>>let's focus on the core topics that we can implement today with
>>today's version of Sane and all its quirks:
> 
> The problem is to decide which software access SANE (which one do
> sane_open() ). I'm against loading sane as app library like we do today.
> Apps should only ask a daemon (either system wide or session wide) to do
> the job. This allow the daemon to monitor the button state.

Just make sure that you don't break existing Sane frontends by
keeping the device file constantly open for the button monitor.

Another problem: Sane already has a working IPC protocol
implementation, saned and the net backend. Works more or less well,
but it is way too slow for "faster" scanners (and this includes
scanners that need as much as 5 or 7 seconds for an A4 page scan,
which is not really "high end" -- with a bit of luck, you can get
them for 5 Euro at Ebay). If you want to completely abandon direct
device access by appications, you'll need to develop a much faster
IPC protocol. And no, I have no idea, where the bottlenecks are.

And keep in mind that you don't know anything about the development
status of a Sane backend. In contrast to most other free software
projects, you can't say that Sane version X is completely stable:
There are of course quite old, well tested and stable backends, but
from time to time a new backend is added. If this new backend
crashes a specialized button daemon, this is just annoying for
scanner usage -- but if this crashes hald, users could quickly
complain that HAL is crap ;)

But take my remarks as "outsider comments": I will restrict my
efforts on HAL and Sane to things that allow others to integrate
Sane better with whatever they think is reasonable. For now, this
means mainly an fdi file (the Sane project will need some more
information for non-USB devices in its *.desc files) and
specification of a useful scanner name space for HAL. (OK, the
latter will probably need at least some polishment from the people
who work on HAL...).

Other suggestions are welcome (a callout for HAL that investigates a
scanner somewhat closer might make sense), but let's keep the
discussion to topics that are essential. Practically speaking: How
does your idea of "scanner button supervision" by hald affect the
"core integration" or cooperation of Sane and HAL? What must and
what should Sane (and I mean Sane 1, not Sane 2, the latter being
nothing more than a not yet finished and for a long time sleeping
API specification) provide, especially in the context of HAL?
Anything special for an fdi file, a fancy callout, a text file with
hints how to deal with the well known inconsistencies in Sane's
scanner option names?

Abel