SANE 2 driver suggestion

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SANE 2 driver suggestion

Donald Straney
Hi,

I've got a suggestion for the drivers in the upcoming SANE 2 - it
would probably be more efficient if they were put in kernel space, at
least for Linux 2.6.  With udev and the new driver model, the 2.6
kernel has a great hardware detection system already in place, and
SANE could take advantage of that for hotplug detection and all the
other features.  Before, SANE has had to implement its own device
detection system, which can be inefficient in some cases.  For
example, I'm working on a daemon which would provide a D-BUS image
capture service by interfacing to SANE, and to detect hotplugged
scanners while it's running, it has to call sane_get_device_list and
rebuild its entire internal device list (which has to be current so it
can poll for button presses) each time HAL issues a hotplug event.
Besides, each driver has to probe for the device itself.  With
kernel-space drivers, each one could just register a list of bus IDs
or a probe function (for parallel port devices) so it could be
automatically inserted when needed, instead of having to call the
probe function for every single registered driver just to get a device
list.  Another good point is that HAL could then handle scanners
easily, without having to build any HAL integration into SANE, just a
few HAL rules which register a "scanner" or "image capture" capability
for the devices.

To not kill portability, the wrapper around the drivers could be
expanded as necessary.  The interface to the actual driver code could
be kept high-level, so that on Linux, I/O would be done through a
device node, and on other systems (like Windows and OS X) where each
driver would be built as a library, it could be done through a buffer
the way it's done now.  The same goes for options - on Linux, the
wrapper would accept ioctl operations and pass them on to the driver,
and on other systems the wrapper could just take the arguments from a
library function.  Of course, some things like memory allocation and
copying between user space and kernel space work differently in kernel
drivers than in libraries, but if the wrapper was well written, it
could take care of that.  A "sanei_malloc" function could call kmalloc
when built on Linux, and the system's malloc when built on other
systems, and the wrapper could also handle any transfer of data
between the program and the driver.  For registering drivers, the
wrapper could either pass on the bus IDs to the kernel's driver model
(in Linux) or have its own probe functions on the systems where it's
built as a library.

Of course, kernel programming is VERY different from userspace
programming, but what I'm thinking about is changing the drivers'
responsibilities from doing most of the communication to just issuing
device-specific commands, and letting the wrapper handle most of the
real work.  That way, each driver would be simple enough that it would
be almost more like a script for the wrapper to run than a stand-alone
piece of code.  The libgphoto2 backend wouldn't work with in-kernel
drivers, but honestly, it wasn't that useful anyways.

The userspace access to the devices would have to be abstracted a bit
more too.  The dll backend would be replaced with a single libsane
which scanning programs would link to.  On Linux,  libsane would
contain the functions to manipulate the device nodes, and on other
systems, it would load and use the functions from the other driver
libraries.  Of course, a program which wants to interface with SANE at
a lower level to handle hotplugging better, like my D-BUS image
capture daemon, could just talk to the device nodes directly.  I know
that all of this could be a lot of work, but I think it would be worth
it to have better Linux support.

Any suggestions? Comments? Reasons why this is a bad idea?

Donald Straney

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE 2 driver suggestion

m. allan noah-3
On 2/17/07, Donald Straney <[hidden email]> wrote:
> Hi,
>
> I've got a suggestion for the drivers in the upcoming SANE 2 - it
> would probably be more efficient if they were put in kernel space, at
> least for Linux 2.6.  With udev and the new driver model, the 2.6
> kernel has a great hardware detection system already in place, and
> SANE could take advantage of that for hotplug detection and all the
> other features.  Before, SANE has had to implement its own device
> detection system, which can be inefficient in some cases.

these detection systems are relatively similar probing, across all OS's
that sane supports. while i agree that they are archaic, they are easily
abstracted into 'hunt thru scsi bus for X' and 'hunt thru usb bus for Y'.
doing linux differently would require some sort of backend registration
mechanism that we do not currently have.

> With
> kernel-space drivers, each one could just register a list of bus IDs
> or a probe function (for parallel port devices) so it could be
> automatically inserted when needed, instead of having to call the
> probe function for every single registered driver just to get a device
> list.

and kernel space drivers are a whole new kettle of fish. sane has
slowly abandoned its earlier kernel-level driver in favor of a user-land
solution, which has been historically favored by all kernel devels. Has
the situation on LKML suddenly changed to become favorable to large
chunks of code for low-speed devices (like scanners) becoming kernel
modules again?

> Another good point is that HAL could then handle scanners
> easily, without having to build any HAL integration into SANE, just a
> few HAL rules which register a "scanner" or "image capture" capability
> for the devices.

this point presumes that 'HAL support' is a good thing, without explaining
why. to a certain extent, sane devels are a wide-ranging group, and dont
spend much time keeping up with everything new in Linux-only land. :)

> To not kill portability, the wrapper around the drivers could be
> expanded as necessary.  The interface to the actual driver code could
> be kept high-level, so that on Linux, I/O would be done through a
> device node, and on other systems (like Windows and OS X) where each
> driver would be built as a library, it could be done through a buffer
> the way it's done now.  The same goes for options - on Linux, the
> wrapper would accept ioctl operations and pass them on to the driver,
> and on other systems the wrapper could just take the arguments from a
> library function.

so you are saying that someone who writes a front-end for sane would have
to use /dev/ io on linux, but continue to link to libsane elsewhere?

>  Of course, some things like memory allocation and
> copying between user space and kernel space work differently in kernel
> drivers than in libraries, but if the wrapper was well written, it
> could take care of that.  A "sanei_malloc" function could call kmalloc
> when built on Linux, and the system's malloc when built on other
> systems, and the wrapper could also handle any transfer of data
> between the program and the driver.  For registering drivers, the
> wrapper could either pass on the bus IDs to the kernel's driver model
> (in Linux) or have its own probe functions on the systems where it's
> built as a library.
>
> Of course, kernel programming is VERY different from userspace
> programming, but what I'm thinking about is changing the drivers'
> responsibilities from doing most of the communication to just issuing
> device-specific commands, and letting the wrapper handle most of the
> real work.  That way, each driver would be simple enough that it would
> be almost more like a script for the wrapper to run than a stand-alone
> piece of code.  The libgphoto2 backend wouldn't work with in-kernel
> drivers, but honestly, it wasn't that useful anyways.

i agree with the basic idea of making backends as simple as possible,
but i dont think your abstraction of 'changing the drivers responsibilities'
is detailed enough to do any real work. can you make more specific
suggestions as to how you would structure the API?

> The userspace access to the devices would have to be abstracted a bit
> more too.  The dll backend would be replaced with a single libsane
> which scanning programs would link to.  On Linux,  libsane would
> contain the functions to manipulate the device nodes, and on other
> systems, it would load and use the functions from the other driver
> libraries.

ok, this answers my question above. break sane into two parts (or 3?)
and use the device node as the go-between. most front-ends will
link with libsane.

  Of course, a program which wants to interface with SANE at
> a lower level to handle hotplugging better, like my D-BUS image
> capture daemon, could just talk to the device nodes directly.

and now we've got two api's to manage? can you suggest how you
would structure the ioctl's or whatever the kernel-level interface will
be? i am concerned about how you would provide to your dbus code
the level of device-specific control that the sane options functions
provide...

i feel that we are discussing a solution without having a firm
statement of the problem. this keeps coming up, so there must be
some sort of need here, but i dont have a concise statement of the
issue. can you help?

allan

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE 2 driver suggestion

Donald Straney
> these detection systems are relatively similar probing, across all OS's
> that sane supports. while i agree that they are archaic, they are easily
> abstracted into 'hunt thru scsi bus for X' and 'hunt thru usb bus for Y'.
> doing linux differently would require some sort of backend registration
> mechanism that we do not currently have.

Right, that would be handled by the wrapper.  I was thinking of
something like this:

register_bus_ids(bus_enum bus_type, char **id_array)
register_probe_func(probe_function func)

> this point presumes that 'HAL support' is a good thing, without explaining
> why. to a certain extent, sane devels are a wide-ranging group, and dont
> spend much time keeping up with everything new in Linux-only land. :)

Sorry, I should've been more specific.  What I meant is that all
scanners (or other image-capture devices) would show up consistently
in HAL, and have something to identify them, like an "image capture"
capability.  As it is right now, any scanner hardware recognized by
the kernel (including the USB and probably the SCSI devices) is going
to show up in HAL, so it wouldn't be hard to just have a list of HAL
rules which match the bus IDs and mark those with the "image capture"
capability.  The problem is that scanners on the parallel port, or
networked scanners handled by saned, aren't going to be in the kobject
system, so they're not going to be shown in HAL.

The reason for all this is that it could make everything easier if
done right.  For one thing, it would be nice to just be able to see
all scanners consistently recognized in the HAL device manager, so you
could keep track of them more easily.  Also, it could make getting a
scanner list much more efficient.  Instead of the program having to
probe for devices each time it has to get a list of available
scanners, it can just get a list from HAL, which I'm sure would be
faster.  That way, programs could also handle hotplugging more easily.
 Right now, if a USB scanner was plugged in while xsane was running,
it wouldn't have any way to recognize it, unless it was constantly
probing through sane_get_device_list every second (that wouldn't even
work with some drivers, which probe only once when they're loaded -
that's more of a driver problem, though).  With HAL support, the
program could just listen for DeviceAdded and DeviceRemoved signals.
With xsane that wouldn't matter very much, since it's easy to just
close it and open it again, but for daemons like mine that run
continuously to monitor button presses or something similar, it makes
things a little harder.

> i agree with the basic idea of making backends as simple as possible,
> but i dont think your abstraction of 'changing the drivers responsibilities'
> is detailed enough to do any real work. can you make more specific
> suggestions as to how you would structure the API?

Right.  First there could be functions for accessing the different
buses. I honestly don't know much about this, so I'm not going to go
into detail here:

send_usb_command
recv_usb_command
send_scsi_command
recv_scsi_command
(ieee1284, firewire, etc.)

...something along those lines anyways, probably like what's in sanei
now.  For debugging:

show_message(char *message) [for critical messages]
show_debug_message(char *message) [wouldn't be compiled in for
non-debug versions]

...then some wrappers for the standard functions:

sane_malloc
sane_free
sane_strcpy
sane_strlen
sane_strncmp
sane_memset

...and something to get configuration values:

char **get_config_keys()
get_config_value(char *key)

Or more like what's in sanei already:

sanei_config_handle *config_open
int config_read_line(char **line, sanei_config_handle *config)

It actually doesn't seem like the sanei interface for drivers would
need to be changed too much to fit.  Is there something I'm leaving
out which scanners would need?

> and now we've got two api's to manage? can you suggest how you
> would structure the ioctl's or whatever the kernel-level interface will
> be?

To keep things consistent, the device node API could be just like the
library API, which could be almost just like the API libsane has now.
Getting a device list would be done by looking at all the "imcapX"
nodes in /dev, connecting to a device would be done by opening the
device node, and closing the device node would close the connection
(as opposed to using sane_open, sane_close, etc.), but except for
that, the set of commands could be just about the same.  The device
info (like the manufacturer and model) would probably be stored in the
device's entry in /sys, right?  It could have ioctls for setting an
option value, getting an option value, getting the name of an option,
getting the type of an option, getting constraints on an option,
starting a scan, reading data (which would be read through the device
node using "read", of course) and stopping a scan.

> i am concerned about how you would provide to your dbus code
> the level of device-specific control that the sane options functions
> provide...

Do you mean on the device node level or the dbus level?

> i feel that we are discussing a solution without having a firm
> statement of the problem. this keeps coming up, so there must be
> some sort of need here, but i dont have a concise statement of the
> issue. can you help?

Again, sorry, I should've been more specific.  I guess the way I see
the problem is that it would be nice to have better handling of
hardware recognition: First, so that the hardware (including parallel
port and networked devices) could show up in /sys and HAL, instead of
having SANE's device list functions for scanners, and /sys for
everything else (which seems inconsistent).  It seems inefficient to
me to have to probe for devices every time to get a list of them,
instead of having a persistent list somewhere that's updated when
devices are plugged in or removed, like /sys or HAL.  Of course, SANE
could be based on a daemon which listens for hotplug events, checks
the bus IDs against a list of IDs registered by the drivers, and
updates an internal list of available scanners, but I don't really
like the idea of having something like that running all that time just
to get basic scanner access (especially since it has to be portable),
and it seems like a huge waste to duplicate all that stuff in
userspace when the kernel's already got a great driver model and
hardware detection system that it could use.

One other thing I was thinking of is how it would be nice to make all
the various imaging device APIs work well together.  As it is now,
SANE and V4L are fine, since video hardware can have a V4L driver and
SANE can grab frames through the V4L backend.  It seems like
libgphoto2 is the one that doesn't quite fit in, though, since it has
its own methods for getting video and still images from cameras,
although it's the only one that can transfer images stored on the
memory cards of cameras.  Think about it from the perspective of a
driver developer: Suppose that you're from a Linux-friendly company
and you're trying to add support for your camera, which can act as a
webcam for taking video and also store images.  If you create a
libgphoto2 driver for it, then programs which capture video (which
probably use V4L) won't be able to get video from your camera.  On the
other hand, if you create a V4L driver for it, there won't be a way to
transfer the pictures off the memory card.  It gets even more complex
if it can also take still images, something that SANE should be
handling.  It would be possible to write two separate drivers, but
honestly, who thinks that's a good idea?  The libgphoto2 backend for
SANE could also be improved so that it can actually get a list of
cameras and take still images from them if they support it, but that
doesn't solve the problem of video, unless libgphoto2 adds a V4L
backend and programs switch to using libgphoto2 for all video capture.
 Then we end up with a huge mess of different APIs and backends that
will scare everyone away from writing Linux drivers or imaging
programs... ;)

Anyways, where I'm leading with all this rambling is that if all the
drivers were in-kernel, then supporting a device which can capture
images or video in multiple ways would be much simpler.  There can be
just one driver per device in the form of a kernel module, which
registers itself for V4L if it can capture video, SANE if it can
capture still images, and as a block device if it stores pictures.
That way, any shared internal code (to send common commands to a
camera or to set options, for example) also wouldn't have to be
copy-pasted between the different drivers.

Oh, and on a sort-of-unrelated topic, I agree with Etienne that
clearer scanner button handling (I'm talking about physical buttons on
the scanner here) for SANE 2 would be great.

> and kernel space drivers are a whole new kettle of fish. sane has
> slowly abandoned its earlier kernel-level driver in favor of a user-land
> solution, which has been historically favored by all kernel devels. Has
> the situation on LKML suddenly changed to become favorable to large
> chunks of code for low-speed devices (like scanners) becoming kernel
> modules again?

Not as far as I know.  If the kernel hackers think scanner drivers
should be in userspace, then I'm not going to argue.  They obviously
know a whole lot more than me about it. :)

It's too bad, though, since there's no way to take advantage of the
2.6 kernel's great hardware system without that, and as I said before,
duplicating it in userspace with a daemon and a list of bus IDs
compiled from the drivers and everything seems inefficient and
inconsistent, definitely not the right solution.  Maybe the kernel
needs a standard way for userspace drivers to register hardware in
/sys, create device nodes in some way that works well with udev, and
automatically load the right library (from userspace, of course) when
the hardware's present, but that's a whole different matter...

Donald Straney

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE 2 driver suggestion

m. allan noah-3
[SNIP Re: in-kernel drivers]
> It's too bad, though, since there's no way to take advantage of the
> 2.6 kernel's great hardware system without that, and as I said before,
> duplicating it in userspace with a daemon and a list of bus IDs
> compiled from the drivers and everything seems inefficient and
> inconsistent, definitely not the right solution.

inconsistent only as compared to linux, but very consistent as compared to
other platforms, which sane devels must keep in mind.

> Maybe the kernel
> needs a standard way for userspace drivers to register hardware in
> /sys, create device nodes in some way that works well with udev, and
> automatically load the right library (from userspace, of course) when
> the hardware's present, but that's a whole different matter...

this i think is the best solution. a shim inside the kernel, and the bulk of
the code outside.

theoretically, using the description files, sane should be able to map a
specific usb id to a specific backend. scsi is more difficult, pp is almost
impossible. i dont know enough about how things get into /sys to go any
further. must do more research.

allan

--
"The truth is an offense, but not a sin"

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE 2 driver suggestion

Donald Straney
> this i think is the best solution. a shim inside the kernel, and the bulk of
> the code outside.

Sounds like a good idea to me.

> theoretically, using the description files, sane should be able to map a
> specific usb id to a specific backend. scsi is more difficult, pp is almost
> impossible.

Yeah, I think the parallel port would probably have to be probed manually.

Donald Straney

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE 2 driver suggestion

abel deuring
In reply to this post by m. allan noah-3
m. allan noah wrote:
> [SNIP Re: in-kernel drivers]
>> It's too bad, though, since there's no way to take advantage of the
>> 2.6 kernel's great hardware system without that, and as I said before,
>> duplicating it in userspace with a daemon and a list of bus IDs
>> compiled from the drivers and everything seems inefficient and
>> inconsistent, definitely not the right solution.
>
> inconsistent only as compared to linux, but very consistent as compared to
> other platforms, which sane devels must keep in mind.

exactly.

>> Maybe the kernel
>> needs a standard way for userspace drivers to register hardware in
>> /sys, create device nodes in some way that works well with udev, and
>> automatically load the right library (from userspace, of course) when
>> the hardware's present, but that's a whole different matter...
>
> this i think is the best solution. a shim inside the kernel, and the
> bulk of
> the code outside.

Would the advantage(s) of using sysfs (as I understand it, that's
basically better button handling for daemons and perhaps easier
backend/driver detection) compared to the "software layers" we use
currently really be big enough to design a specialized Linux version
of Sane? And before we discuss this in greater depth, we should ask
the kernel developers, what they think about special support for
scanners. If they don't like it, we're only producing hot air...

> theoretically, using the description files, sane should be able to map a
> specific usb id to a specific backend. scsi is more difficult, pp is almost
> impossible. i dont know enough about how things get into /sys to go any
> further. must do more research.

The "hardware registration" suggested by Donald can easily be done
via hald -- we only need to transform Sane's *desc files into *fdi
files for hald. I have already tested this -- I mainly need to
replace my prototype Python script that creates the fdi files with a
patch/new output mode for sane-desc.c . I also played a bit with a
hald callout for scanners; this callout can give some additional
information.

SCSI scanners are not a problem for hardware detection by hald: We
just need to add a new tag like ":scsiid" to the *desc files, which
specifies the vendor and model string. OK, this does not fix the
problem that a SCSI scanner must be powered on, when the kernel
scans the SCSI bus for devices -- but this is a limitation of the
SCSI bus.

Abel

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE 2 driver suggestion

Donald Straney
> The "hardware registration" suggested by Donald can easily be done
> via hald -- we only need to transform Sane's *desc files into *fdi
> files for hald. I have already tested this -- I mainly need to
> replace my prototype Python script that creates the fdi files with a
> patch/new output mode for sane-desc.c . I also played a bit with a
> hald callout for scanners; this callout can give some additional
> information.

Do you mean that to get a device list, sane_get_device_list would then
go through HAL?  That would work too, if you don't mind having the
Linux version rely on HAL (I was thinking of integrating it at a lower
level, but if this would work just as well and make it simpler then it
sounds good to me).

The problem with using only HAL rules to identify the scanners is that
parallel port and networked scanners won't show up.  I guess
sane_get_device_list could probe manually for parallel port scanners
and use Avahi or something similar to get remote computers running
saned on each call, but it would probably be better to get them into
the HAL device list somehow.  I'm guessing that automatically
detecting networked scanners with Avahi wouldn't be too hard, but
there's still the problem of parallel port devices.  Is there any way
around this, like running a quick SANE probe program at boot which
would test for non-hotpluggable devices and add them to HAL's device
list? (It would break if someone decides to hotplug their parallel
port scanner all the time, but does that really matter?)

Donald Straney

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE 2 driver suggestion

abel deuring
Donald Straney wrote:

>> The "hardware registration" suggested by Donald can easily be done
>> via hald -- we only need to transform Sane's *desc files into *fdi
>> files for hald. I have already tested this -- I mainly need to
>> replace my prototype Python script that creates the fdi files with a
>> patch/new output mode for sane-desc.c . I also played a bit with a
>> hald callout for scanners; this callout can give some additional
>> information.
>
> Do you mean that to get a device list, sane_get_device_list would then
> go through HAL?

I doubt, if it makes much sense to call HAL from sane_get_devices.
While it might save a few processor cycles, because not all known
backends need to be tried, it might lead to difficult
interdependency problems: A HAL callout, invoked when a scanner is
connected to the machine, might actually call sane_get_devices, in
order to get additional information about the device.

But applications can easily ask hald about recognized scanners, and
a HAL callout might start a scan application, when a scanner is
detected.

> That would work too, if you don't mind having the
> Linux version rely on HAL (I was thinking of integrating it at a lower
> level, but if this would work just as well and make it simpler then it
> sounds good to me).

If you means the functions send_usb_command, recv_usb_command etc
from an older mail: I do not understand, what advantages these
functions would have, in comparision with Sane's current approach as
implemented in sanei_scsi and sanei_usb.

> The problem with using only HAL rules to identify the scanners is that
> parallel port and networked scanners won't show up.  I guess
> sane_get_device_list could probe manually for parallel port scanners

...what is done right now...

> and use Avahi or something similar to get remote computers running
> saned on each call, but it would probably be better to get them into
> the HAL device list somehow.  I'm guessing that automatically
> detecting networked scanners with Avahi wouldn't be too hard, but
> there's still the problem of parallel port devices.  Is there any way
> around this, like running a quick SANE probe program at boot which
> would test for non-hotpluggable devices and add them to HAL's device
> list?

We already have such a "probe program": scanimage -L ;)
Or any other program that calls sane_get_devices.

> (It would break if someone decides to hotplug their parallel
> port scanner all the time, but does that really matter?)

If you are thinking about the famous "aunt Tillie", it really does
matter ;) Why should users switch on their parport scanner together
with the computer? But I think that Sane's current version handles
this case just fine, provided that the right backend is enabled in
dll.conf (disclaimer: I don't have any first-hand experience with
parport scanners, but I assume that parport scanners do not behave
that much different than parport printers).

Abel

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE 2 driver suggestion

Donald Straney
> I doubt, if it makes much sense to call HAL from sane_get_devices.
> While it might save a few processor cycles, because not all known
> backends need to be tried, it might lead to difficult
> interdependency problems: A HAL callout, invoked when a scanner is
> connected to the machine, might actually call sane_get_devices, in
> order to get additional information about the device.

Ok, as long as programs can easily get a scanner list through HAL (and
if sane_get_device_list is used more by callouts and other system
stuff than by xscanimage, for example).

> If you means the functions send_usb_command, recv_usb_command etc
> from an older mail: I do not understand, what advantages these
> functions would have, in comparision with Sane's current approach as
> implemented in sanei_scsi and sanei_usb.

No, I was talking about adding objects to /sys through some kind of
kernel support for userspace drivers.

> If you are thinking about the famous "aunt Tillie", it really does
> matter ;) Why should users switch on their parport scanner together
> with the computer? But I think that Sane's current version handles
> this case just fine, provided that the right backend is enabled in
> dll.conf (disclaimer: I don't have any first-hand experience with
> parport scanners, but I assume that parport scanners do not behave
> that much different than parport printers).

Good point. ;)  Of course parallel port scanner detection works fine
now, I'm just trying to figure out how it would fit into a model based
on HAL or something similar.  I guess only a few drivers would need to
probe the parallel port and it would be really fast, so doing it each
time a program wanted to get a device list (and then adding any new
ones to HAL?) would probably be the best way to do it.

Donald Straney

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE 2 driver suggestion

Donald Straney
Sorry for bringing up an old thread again, but here's an idea that
could solve the hardware detection problem in a simpler way, without
adding anything to the kernel or having all probing go through HAL:

Instead of using the sane_get_device_list call in most backends to
probe for devices, there could be another function,
sane_get_supported_devices, which would return a pointer to a
SANE_Supported_Devices struct.

typedef struct {
  int autodetect;  //1 if it can be autodetected, 0 if it needs to be
probed by the driver
  SANE_Bus bus;  //shows which bus the device is on
  char **id_list;  //a null-terminated list of IDs for the bus the
device is on -
                       // is there a better way to store this?
  sane_probe_func probe_func;  //the probe function to use if needed
} SANE_Supported_Devices;

Then, there could be a small program (sane-update-driverlist or
something similar) which would load each driver, get its supported
devices, and build a driver list in /etc/sane.d, which would list each
driver, whether it can be autodetected or not, and if it can the bus
and bus IDs.  That way, instead of having to load each driver in turn
for a simple device listing, sane_get_device_list in the dll backend
could just read the driver list, compare the bus IDs in it against a
list of PCI, USB, and other devices it gets from a bit of
platform-specific code (I don't know if libusb and the others can do
this, or if it would have to check in /proc or /sys on Linux), and
only load the drivers which need to manually probe the hardware.  To
keep the list up to date, RPM and .deb packages with additional SANE
drivers could run sane-update-driverlist as a post-install command.

Anyways, I'd definitely work on implementing it myself in SANE 2 if
you all agree.

Donald Straney

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Loading...