[sane-devel] How to handle devices with multiple USB bulk-in endpoints
reinhold at kainhofer.com
Sat Nov 6 12:31:28 UTC 2010
Am Dienstag, 2. November 2010, um 01:24:38 schrieb m. allan noah:
> I've not had a chance to look at the code, but i can say that this
> design is preferred over a new argument to the open() function,
> because some scanner might someday require communication with two
> endpoints of the same type concurrently.
Actually, I meant whether we should additionally provide a way to globally
override the default endpoint. Most devices use only one endpoint, so it
doesn't make so much sense to require their backends to provide the endpoint
to each and every USB command. Rather, one would pass the endpoints to be used
to the open function and those will be set as default.
Of course, with each individual USB command, one can override that default
(which is only relevant for devices that use multiple endpoints for different
> Also, sanei is 'internal' to sane. The interface is not stable, and we
> don't want it installed to the system. In fact, if we wanted to, we
> could just use your new functions in place of the old ones, and modify
> all the backends to use the -1 argument, without harming external
> So, the bigger question is, why are you not installing your backend
> using the infrastructure that sane gives you?
Well, in the end I think the backend should be included with the stock sane-
backends repository. However, I don't think that each new backend development
process should start inside sane-backends for several reasons:
1) One never knows if a developer will really finish the backend (or at least
get it to a usable stat), so cluttering sane-backends with half-finished,
broken backends in development is not an option.
2) I want to provide a repository for others to try out the backend (and only
that backend) while still in development.
3) During development, I wasn't sure which additional libraries would be
required or which external code would be incorporated (in particular for SNMP
detection in my case). I was also investigating the code from the CUPS
project, which is GPL, but owned by Apple, so I doubt that the SANE exception
(which AFAIU is needed for the backends in sane-backends) would be granted.
4) In particular for new backends, there will be users (larger institutions
with managed installations) that want to use the backend with older sane
So, in short, I think that new backends should start in their own repository
and can then later be incorporated into sane-backends. However, for this, one
needs to copy (and continuosly sync) sanei from sane-backends to one's one
repository. After all, sanei provides utility function for all the basic
functionality common to most backends.
Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
More information about the sane-devel