ZWO ASI Support in the Linux build

[Robin G]

Well, I have made this work, which is good, but there are a number of issues that mean that I am not comfortable committing my changes - basically looking for some advice on how to overcome them or if it is worth bothering.

1) Needs to run as root - this looks like a permissions issue when opening the usb device (ie /dev/bus/usb/xxx/yyy). I suspect there is some way to configure linux to give appropriate permissions to the USB device when plugged in, but this is outside my knowledge, sadly

2) Library linkage - I have both dynamic and static libraries for x64, x86, armv5, armv6 and mac. I've managed to tweak the CMakeLists.txt file to link to one version of the static libraries for testing, but it's going to need a more elegant solution so it will find the right library for the current architecture. Any suggestions welcome - I have never 'cmaked' before...

3) Name clash - the ZWO libraries have a public symbol named 'pCamera' which clashes with the global pCamera in phd.cpp. Now, the easy solution for me is to just rename pCamera to (say) pGuideCamera throughout the source (266 locations!), which works. Not the nicest thing to have to do just to link to a library though. Acceptable? Or not?

Any advice welcome :)

cheers,

Robin

[Hans]

Hi Robin,

On Friday, June 13, 2014 9:39:13 PM UTC+2, Robin G wrote:

Well, I have made this work, which is good, but there are a number of issues that mean that I am not comfortable committing my changes - basically looking for some advice on how to overcome them or if it is worth bothering.

 
This is excellent news !

 

 1) Needs to run as root - this looks like a permissions issue when opening the usb device (ie /dev/bus/usb/xxx/yyy). I suspect there is some way to configure linux to give appropriate permissions to the USB device when plugged in, but this is outside my knowledge, sadly

Yes, this is done via udev (Linux dynamic device management), see the UDEV(7) man page. For instance, the indi-sx package for StarlightXpress cameras on Linux has config like :
cat /etc/udev/rules.d/99-sx.rules                   
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1278", ATTRS{idProduct}=="0100", MODE="0666" 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1278", ATTRS{idProduct}=="0105", MODE="0666" 
...

Which recognizes the USB devices when they get plugged in and sets permission modes. Other configs also create convenient symlinks, like /dev/dvdrw for instance.

2) Library linkage - I have both dynamic and static libraries for x64, x86, armv5, armv6 and mac. I've managed to tweak the CMakeLists.txt file to link to one version of the static libraries for testing, but it's going to need a more elegant solution so it will find the right library for the current architecture. Any suggestions welcome - I have never 'cmaked' before...

We can hardcode-hack it in, or create a FindZWO.cmake which supports linux, mac and mswindows. (the buildbots use cmake to create makefiles on linux and osx and can create sln project files for future mswindows buildbots, if we find someone to host one that is)
 

3) Name clash - the ZWO libraries have a public symbol named 'pCamera' which clashes with the global pCamera in phd.cpp. Now, the easy solution for me is to just rename pCamera to (say) pGuideCamera throughout the source (266 locations!), which works. Not the nicest thing to have to do just to link to a library though. Acceptable? Or not?

Fine with me but I'll defer this one to Andy. Maybe something for namespaces ?

regards,
   Hans Lambermont

[Andy Galasso]

Apparently their lib is has a bunch of exported symbols that are not part of the API. I think we should contact them to see if they can cleanup their library. The problem can be easily solved on their end with '__attribute__ ((visibility ("hidden")))' (assuming they use g++), or using a linker export map. Even if they had prefixed their global symbols with "ASI_" we would be much better off.

Let's at least try to contact them and see if they can clean up their library. It will make their library more usable for everyone, not just PHD2. Since they went to the trouble of creating an SDK, I would guess they would be interested in making it usable :) If that fails, then we can look at workarounds like namespaces. We would have to put our phd variables in a phd namespace, but let's not go there yet.

My specific recommendations to them would be:

  1. make sure all the symbols in the public interface in the .h file (enums and functions) have a unique prefix, like "ASI_". For example, replace "initCamera() with ASI_initCamera()" and enum IMG_TYPE with enum ASI_IMG_TYPE.

  2. make sure the public api names ASI_* are the _only_ public symbols exported in the .so

Andy

[Robin G]

Hi Andy, Hans, thanks for the useful suggestions.

I am in contact with Sam at ZWO anyway, so I will pass on the suggestions about hiding the unnecessary symbols and/or renaming - I expect they will be very helpful.

Right now I have gone back to the namespace idea, which is at least tidier than the renaming the pCamera global. I won't commit that to trunk, but will put the changes into a branch so that anyone else interested can experiment or contribute.

cheers,

Robin

[Andy Galasso]

sounds good, thanks

[Robin G]

Ok, I have made some more progress with this

* contacted Sam at ZWO to suggest that he clean up the exports of the libraries
* as an interim measure I have renamed the clashing symbol using 'objcopy --redefine-sym pCamera=pASICamera libASICamera.a' - this allows removal of the namespace change
* added the 64 and 32 bit versions of the libASICamera.a into svn in ./cameras/zwolibs/x[86|64]/ - this is a tentative path location for them - feel free to suggest a better home (note using the .so was segfaulting for me - maybe because of the objcopy rename? - anyway the static library works fine and requires no deployment)
* created a FindZWO.Cmake that will locate the correct version of the .a for x64 and x86 Linux (very much a 'copy existing cmake file and tinker' exercise so may not be elegant, sorry)
* Only added the ASI library and libRT to the linker for linux builds.

This is getting close to as far as I am able to take these changes - I hope that I haven't broken the OSX build (or the use of CMake for the windows build) but have no suitable environment to test this out - all the changes are in the zwo_linux branch if anyone has a moment or two to check out the other build environments then I will do the merge later.

cheers,

Robin

[Andy Galasso]

Great work, Robin. I like the `objcopy --redefine-sym' solution as a workaround until we get a fixed lib from ZWO, though hopefully they will work to address it since many of their other symbol names are just so generic that they are accidents waiting to happen.

If you want to go ahead and merge to trunk, we can always fix any OSX build error afterwards.

Cheers,

Andy

[javier ramirez]

Is there any way to avoid linking to PHD some camera drivers I don't want to compile... I have problems on raspbian compiling WZO modules (drivers for arm are nor available) and I have tried many options to avoid compiling PHD2 with links to those libraries, but I am almost lost in code... changing every line related to those drivers... but I am sure that there must be something I miss.

Many Thank in advance.

Javier R.

[Andy Galasso]

Javier,

This patch should do it. Make sure you run cmake after you apply the patch.

Andy

P.S. Are you a Spanish speaker?  Do you know of anybody who could help provide a Spanish translation for PHD2?