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
Am Montag, 1. November 2010, um 01:03:23 schrieb m. allan noah:
Yes- what we should probably do is add a new set of
sanei_usb_{read,write,etc}_extended() functions, which take the
endpoint as a argument. Then all of the existing functions could
become a wrapper around those, which call a
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.
Also, sanei is 'internal' to sane. The interface is not
My KONICA MINOLTA magicolor 1690mf has one bulk-out endpoint and unfortunately
two bulk-in endpoints (#4 and #5, where it only uses #5 for all
communication). SANE on the other hand chooses to only use the first bulk-in
endpoint (i.e. #4 in my case), which will not work.
There were some
Yes- what we should probably do is add a new set of
sanei_usb_{read,write,etc}_extended() functions, which take the
endpoint as a argument. Then all of the existing functions could
become a wrapper around those, which call a helper function to
determine the 'automatic' endpoint to use.
Thanks
