[sane-devel] xerox_mfp usb malfunction

[Warren Turkal]

On Wed, Mar 9, 2011 at 11:46 AM, m. allan noah <kitno455 at gmail.com> wrote:

> 2011/3/9 Warren Turkal <wt at penguintechs.org>:
> > 2011/3/9 ABC <abc at telekom.ru>
>
> >  What i think should actually happen is that sanei should have it's own
> > method for dealing with usb (and other busses) in whatever form it takes
> > (e.g. /dev/scanner dev file or libusb or scsi device or whatever). Sanei
> > should call any callbacks into the backend with a generic form for the
> bus
> > type instead of exposing it's innards. Assuming that a string is the best
> > form for that generic form, something like "usb:vendor_id:product_id" is
> > probably reasonable.
>
> ...
>
> And that suggestion does not deal with two identical scanners attached
> to the machine.


This is a strawman argument as I think it's pretty clear that the struct
would need to include more fields to handle that, and this wasn't a complete
example. For example, bus id and device number could be added to the usb
struct.


> And the 'struct' version with a single callback
> requires us to use enum every possible transport thru a single
> function in sanei, which breaks down with a backend specific
> transport.
>

We could allow backend implemented transport by having a transport that
defers to the backend implementation. For example, we could add a
backend_attach function pointer to the attach_funcs struct that would be
take an opaque string as the current implementation does. There's no reason
we still couldn't allow that development use case if it was needed.

If a backend supports multiple transports, it can use multiple
> callbacks (or callback wrappers) which set the transport in the
> scanner struct, in addition to the opaque string. Now, this breaks
> down if two different transports use the same name, or if a backend
> treats the string as non-opaque. Though the last might be required in
> the case of a scanner which cannot be auto detected, like a tcp
> machine. I think that's the case here?


I don't see why tcp can't be treated like the other transports. The
tcp_device_info could something like the following:
struct tcp_device_info {
  SANE_String_Const hostname;
  SANE_Integer port;
}

Personally, I would prefer to use uint16_t for the port since I think it's
more accurate with my intention, but I think that the SANE_Integer type
should work.

When the tcp_attach method is called, it would get the tcp_device_info
struct and could make a connection (possibly with a library function that's
not part of the SANE backend API).

It's possible that a better name for the *_device_info structs might be
*_transport_info or something like that.

Thanks,
wt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110309/066b5742/attachment.htm>