[sane-devel] How to handle devices with multiple USB bulk-in endpoints

m. allan noah kitno455 at gmail.com
Mon Nov 8 15:00:12 UTC 2010


On Sat, Nov 6, 2010 at 8:31 AM, Reinhold Kainhofer
<reinhold at kainhofer.com> wrote:
> 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
> operations).

Ahh- I see. Yes, this is how the current implementation of altering
timeouts is written. You could add a function to change the default
endpoints, but you potentially have several, bulk, iso, etc, both read
and write. That might be a simpler mechanism.

>> 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
>> development.
>>
>> 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.

just because the developer does his initial work inside of a
sane-backends checkout does not mean that he must commit to the master
sane repo.

> 2) I want to provide a repository for others to try out the backend (and only
> that backend) while still in development.

git specifically is design to allow this, AFAIK.

> 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.

Then you also cannot use sanei.

> 4) In particular for new backends, there will be users (larger institutions
> with managed installations) that want to use the backend with older sane
> versions.

A non-issue, IMHO, has they would have to upgrade the installed
version of sanei if there were changes for your new backend, and that
would break the other 'stable' backends.

History has shown that many backends start out being built outside of
sane, and are eventually incorporated, yet the silly 'wrapper' code is
left behind. Then when the developer leaves, we are left with code
that is less maintainable due to the cruft. It is also my personal
preference to reduce the number of compiler warnings to the barest
minimum. However, developers that work external to sane-backends quite
often intentionally disable warnings, which make alot of noise after
integration.

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



More information about the sane-devel mailing list