RFC: Support for different PTP implementations/port backends

[trilader]

(No idea if the issue title captures what I want to say well...)

The Issue:

On Windows the user has to install a driver for libusb to access the camera. It's a bit annoying but manageable just fine.

On macOS (especially later versions) ptpcamerad is a real annoyance. It used to (macOS 12 and older) auto start when the camera gets plugged in but you could just pkill it and the issue was solved. In macOS 13 they changed the launch configuration so it gets started once an application (like Preview.app or Dropbox, or even a printer driver) wants to talk to the/a camera. Annoyingly it also gets restarted every time you kill it if whatever process is still running. See also #562.

My propsal:

Firstly: $dayjob uses libgphoto2 in a product and we're likely to do implement something like this for ourselves, however we would like to ideally do that in a way that can be upstreamed.

Currently camlibs/ptp2 is using the libusb port together with a custom/vendored PTP implementation.

I would propose to add a new port driver based on Apples ImageCaptureCore Framework and support it in the PTP2 camlib. ICC supports sending arbitrary PTP commands as well as listening for PTP events received from the camera. (If/Once that is implemented and working I would guess a similar WIA based implementation for Windows could also be implemented more easily which $dayjob is also interested in)

I have not investigated if and how feasible this is to implement. I guess the ptp2 camlib would need some refactoring or at least some kind of ptp implementation abstraction similar to the libusb/ptpip support there is now.

Have you heard if anyone else has done any investigating in that direction?

[msmeissn]

The PTP driver currently also has different port drivers already, USB, PTP/IP and a PTP wrapped in XML passed over PTP driver.

For the TCP/IP thing we basically do all the actual socket work in the ptp driver already.

So setup wise we would create a thin port driver that perhaps just does the same thing with the MacOS framework, and implement the MacOS framework forwarding in the ptp driver as you write.

Port driver would do the device detection / enumeration.

Sadly I have no Mac so I can't do this here.