[argyllcms] Re: Problem accessing HCFR probe
- From: Frédéric Mantegazza <frederic.mantegazza@xxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Wed, 12 Sep 2007 08:02:15 +0200
On Wednesday 12 September 2007 05:12, Graeme Gill wrote:
> Your patch is fine as a "proof of concept", but I really think your
> time would be better spent figuring out why Libusb isn't working
> with the HCFR on your system. I'm not sure I can be much help here,
> since it seems to work fine on my system.
>
> Problems with your patch as it stands are:
>
> There's no way to select the instrument. So if something else
> was plugged into the system and occupied /dev/ttyACM0, or
> if there were two HCFR's plugged in, you wouldn't be able
> to use it/them both.
>
> It breaks HCFR support on MSWindows and OS X. MSWindows doesn't
> have /dev/ttyACM0, and on OS X the IO manager interface needs
> to be used to locate a device name.
>
> It breaks the system dependent encapsulation, by putting
> system dependent code into the instrument drivers. Currently
> this is almost entirely concealed behind the icom object.
>
> To do this sort of thing properly would entail adding a third
> communication type to icom, a "USB connected pseudo-serial device",
> and on each system type the mechanism to locate the serial interface
> from the USB identification would be needed, and then the appropriate
> read/write routines would be needed in icom to use that interface.
>
> Since there are currently no other instruments that appear as USB
> communication devices, and the HCFR is at least capable of
> working directly via libusb as it currently stands, I don't
> think this is the right direction to go, unless there is some
> truly insurmountable obstacle.
Thanks for you comments. My goal is not to add such support of HCFR
via /dev/ttyACM0 in officiel branch of ArgyllCMS, but just to make it work
for me (of for other people having the same problems), under Linux.
As I just ran dispcal for tests, I would just like to know if my patch
works fine, or if I broke something, not in the design, but in the
calibration process.
BTW, as I said, I had similar problems with a scanner, under sane. It was
taking a long time to setup the scanner, with the same strace errors
(ressource not available), and then, once initialised, all was working
fine. So, I wonder if I put a longer timeout during initilisation phase...
I'll make a test.
Thanks,
--
Frédéric
http://www.gbiloba.org
Other related posts:
