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




Other related posts: