asalamon74
make fails on a Mac - sg.h not found
Hi, There seems to be a missing file in the repository. make fails with "scsi/sg.h not found" after cloning the repo and running make on a Mac.
There is no SCSI Generic driver for Mac, that's why you get this error message.
And this is the reason why Mac is not supported.
That was my understanding but a guy supporting Kstars on the Mac said he had Gphoto2 supporting canon on the Mac. I guess they have some sort of USB driver for that. If he or I write that driver, could it be included with pktriggercord ?
Sent from Greg's iPhone
On Feb 5, 2019, at 2:07 AM, András Salamon [email protected] wrote:
There is no SCSI Generic driver for Mac, that's why you get this error message.
And this is the reason why Mac is not supported.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Maybe they are using some different kind of protocol. Can you share a link to the USB driver you are referring to.
I really don’t know much here. @rlancaste of indilib is going to going to look into it. He’s the expert. He may have something.
I’ve found some objective C code for USB access that I thought I could make a library out of, and provide a dylib. I’ve been able to access my Pentax K-5II with it but it would need some “scsi"_read/write functions to be written around it.
On Feb 5, 2019, at 2:41 PM, András Salamon [email protected] wrote:
Maybe they are using some different kind of protocol. Can you share a link to the USB driver you are referring to.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/asalamon74/pktriggercord/issues/38#issuecomment-460775555, or mute the thread https://github.com/notifications/unsubscribe-auth/AYVpszR7tved3V9EiuGNk_G5XgVID_Khks5vKd5NgaJpZM4aiLsg.
Yes, the INDI GPhoto driver is built on libgphoto2. This library builds on Linux, Mac, and even Windows. So we are able to provide INDI support on Macs and Linux for Canon, Nikon, and any other cameras that libgphoto2 supports. My understanding is that the library talks directly to the camera to instruct it to take exposures and that the issue with Pentax is that it doesn't include the ability to take exposures this way. Is that correct?
So I am guessing that PKTriggerCord uses a different type of connection to the camera than libgphoto2?
It seems that modifying the bsd port of the program is more promising. With a simple hack I was able to compile it on a Mac. It still has lots of warnings and need testing. I'll investigate it soon.
If you think you can gain access to the Mac USB then I'll hold off making a dylib. Let me know as soon as you can. We may incorporate pktriggercord directly into Kstars and bypass gphoto2 for Pentax.
Yes, the INDI GPhoto driver is built on libgphoto2. This library builds on Linux, Mac, and even Windows. So we are able to provide INDI support on Macs and Linux for Canon, Nikon, and any other cameras that libgphoto2 supports. My understanding is that the library talks directly to the camera to instruct it to take exposures and that the issue with Pentax is that it doesn't include the ability to take exposures this way. Is that correct?
I don't have a Mac but maybe I can help explain the state of things. The way the indi_pentax driver works is ekos>>indi>>libgphoto>>pktriggercord. The indi driver wraps to libgphoto which is in turn wrapping to PkTriggercord for calls to the camera using "MSC" (usb:scsi) through the usb port to the camera instead of the PTP used by the other brands. Cheers, Ray
Ok, does libgphoto2 run pktriggercord as a separate program where it executes commands or does it use it as a library with functions that libgphoto2 calls?
They import the source code of pktriggercord, you can find it here: https://github.com/gphoto/libgphoto2/tree/master/camlibs/pentax
They sync the source code sometimes. Occasionally there ask for changes in pktriggercord to make it easiere to import it, but it's quite rate. For instance: #22
Ok I got it, so the pktriggercord code in libgphoto2 just goes into one of the camlibs in the camlibs folder. You don't have to launch a separate program that gets called. Thank you for the clarification.
Thanks @asalamon74 . I looked at the camlibs/pentax folder and it doesn't include USB/SCSI driver so gphoto2 guys must provide one, which makes me wonder why its not working on the Mac, unless they also use a generic scsi driver. I'll see if I can find it but so far its looking like I'll have to write one.
I created a hack to compile for Mac OS X. The macosx branch contains it: https://github.com/asalamon74/pktriggercord/tree/macosx
Basically I tried to use the BSD port of the program. Since scsiio.h was missing I copied the file from BSD. It is possible to compile the program. GTK is a bit tricky so it's better to compile it using make cli.
When I connect my camera (K-x) the system recognized it, at least I can get info using ioreg -p IOUSB -l. The BSD port was assuming /dev/rsd* device which is mising from Mac OS X. The new devices after I connect the camera: /dev/disk2, /dev/disk2s1, /dev/rdisk2, /dev/rdisk2s1. I've tried all the devices but only got Device open while querying: and IOCTL failed in query error messages. The first one can be eliminated by umounting.
I don't know too much about Mac OS X ioctl, so any help would be appreciated.
That’s excellent! I have written the ioctl part. I was just trying to test it. Seems to be working but your Mac build will help a lot. Now I can try sending actual camera commands. I copied the scsiio.h also but I think in the end I won’t need it. Question though. My stuff is written in objective C. Can I add it to pk and compile? How to compile with C ?
Cause I’m using the Xcode environment. Will gcc recognize objective C?
You could do this in terminal on OS X, it worked fine for me in an experiment:
mkdir ~/Desktop/test cd ~/Desktop/test git clone https://github.com/asalamon74/pktriggercord.git cd pktriggercord git checkout macosx make cli
@mccodesurfer Please only use C, not objective C. Gcc might recognize objective C, but we need to compile pktriggercord on different platforms, so the best is to use only ANSI C.
May have to provide a library then because the code is not written from scratch. Uses macOS frameworks and libraries. The way I understand it. I just have to put the dylib file in the /usr/local/lib but not sure how to link it in the make file
@mccodesurfer If you provide a library then the language of the library is not that important, only the few calls should be written in C.
Just hack together something with using the -I -L -l switches (-I for the directory containing the headers, -L for the directory containing the lib, -l for the library linking) and I try to clean it later.
Ok. Will do. It may take a week or two. I’m not on it as much as I’d like.
@asalamon74 I am close with this macOS driver - getting status from camera failing on commands- I haven't been able to relate your USB description "pentax_scsi_protocol.md" to this doc: https://www.beyondlogic.org/usbnutshell/usb6.shtml#SetupPacket
In particular, the pslr_init sets up ioctl for BSD. I have a similar ioctl that uses the setupPacket structure. Your cmd structure is similar (I guess) but I haven't figured out how to form it into the packet structure the macOS uses.
@mccodesurfer
pentax_scsi_protocol.md describes a higher level protocol. It describes the byte arrays we send to the camera, the bytes array read from the camera. Probably you don't really need this.
The low level interfaces define scsi_read and scsi_write methods to send/receive data.
The pslr_init tries to find the device and initialize it. Probably you are referring to the get_drive_info method called by pslr_init. Is that correct? On OpenBSD it uses ioctl, but it's possible that on Mac there are other ways to get the information. For instance the linux version reads the info from the /sys filesystem without using ioctl. Unfortunately it seems to me that there is no such filesystem on Mac.
Yes, I'm trying to emulate the low level SCSI_read, SCSI_write that call ioctl (in bsd version). In particular, I replace ioctl - this seems to be where the rubber meets the road - with some macOS interfaces. One called "DeviceRequest" use is very similar to ioctl; build a USB byte stream structure with USB byte codes (per the link I gave you) and call DeviceRequest on the structure.
From what you're saying, I guess I need to encapsulate the Pentax protocol into the DeviceRequest protocol. I was thinking they were the same level. They seamed to be the same in many respects, like the F0 and TT codes look like bmRequestType and bRequest. Since F0 code defines vendor specific codes to follow, it looks like this byte stream protocol is USB, not Pentax specific. However, F0 in particular does not exactly match the USB protocol in the link - if F0 where bmRequestType, it would be a reserved code. Just thinking out loud here.
I guess, I have to find out more about using DeviceRequest.
I decided to shift the interface with Wireshark on a pc and see that indeed there is 30 bytes or so preamble to the pentax command codes... still working on it!
Got Wireshark on Mac now. Looks like I have to make "interface" transactions, which I had working a while ago but its not working right now. Anyway, just letting you know the status.
Good to see you are making progress! I’m wondering if you have given any thought yet as to whether we want to get the code for controlling this into libgphoto or whether we want to make a new INDI driver for pentax entirely ? Obviously the library you are writing could work either way, but I’m just trying to plan ahead for when you finish. Personally I think the best route due to encapsulation and simplicity would be if we can get it into gphoto
Thanks Rob! I like the idea of a Pentax driver. Its been almost a year and I don't believe GPhoto2 has yet been updated with some significant fixes in pktethercord. For the future, Pentax has finally come out with an SDK for their cameras but only support releases from the first k-1 and later. But future ports from their SDK could be truly full featured.