-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sony ptpip feature request #16
Comments
i added parts of this in real ptp code. if you could try out current git of libgphoto2 and see if that already helps as well? (it is not fully the same as you do yet.) |
(check ptp_sony_9280 and ptp_sony_9281 implementation and calls in camera_init and camera_exit ) |
Excellent! I'll check it out this weekend. |
I'm still studying what you have done. From what I can tell, this is going to be great. Let me tell you what I've done so far.
So, I added this extra piece of code in the fixup_cached_deviceinfo function: That got it so the new code would be executed.
32.299992 ptp_ptpip_generic_read (3): ptpip/generic_read header: (hexdump of 8 bytes) 32.300065 ptp_ptpip_generic_read (3): ptpip/generic_read data: (hexdump of 12 bytes) 32.343034 ptp_ptpip_generic_read (3): ptpip/generic_read header: (hexdump of 8 bytes) 32.343106 ptp_ptpip_generic_read (3): ptpip/generic_read data: (hexdump of 4 bytes) 32.343352 ptp_ptpip_getresp ptpip.c:409: response type 10 packet? So, tried adding an additional case entry in the ptp_ptpip_getresp function to support respType 10 (DATA_PACKET): This let it get further and it received this from the camera: I figure this might be appearing because the initial 'sending' status isn't working yet, so it can't shut things down.
Attached is a recent log if you care to look (Note: I had to name it a gif file in order to upload). I'll continue experimenting and report back anything I think might be useful. |
instead of adding this specific case, can you go to camera_exit I think the 9280 call must come always before the 9281 call. |
I applied your change from (1) to git. also swapped the ptp_sony_928x lines in camera_exit in current git. |
This is starting to get really exciting. I swapped the two lines and not only did it not fail, but it also shut down the camera like I want! Also, using how you call the 9280 followed by the data packet I started playing with my raw packet injections again. I was really able to bring down the number of packets needed by following this standard. So after the GetDeviceInfo call these are the only packets required to get the 'sending' to appear: Then to get it to shut off I send: The 9281 I send prior to it shutting off probably is pending from the 9280 send to get it into sending mode. And probably a trailing 9080 might be needed after the camera turns off to be fully completed. I'm not sure how important it is to have these calls alternate. Still more experimenting needed So, what I have right now in the camera_init is just this: I found this will display 'connected' on the camera (not 'sending...'). This might be good enough to prevent the camera from disconnecting. I think the extra "0101" might need to be passed in to get the 'sending' to appear instead of the 'connected' I'll keep playing around and let you know what I find. Thanks! --Andy |
Hi, Okay last update of the day. I realized you can merge the Data Packet and End Data Packet into one by just making sure the 0x0c byte is set instead of the 0x0a byte. This saved another packet--which is what you are already doing. Also, it does look like 9281 function needs to follow the 9280 function in the camera_init. However, in the camera_exit, I think only 9280 is needed. Looking back on some older network traces, I never see a final 9281 when shutting down the connection, I also played around a bit with the ptp_sony_9280 function so it can take in those extra two bytes (01 01). I know this probably isn't the best way to do it, but this is how I coded it:
Then this is all I have in the camera_init:
And this is all I have in the camera_exit
Thing are working exactly how I think they should now and I'm able to transfer pictures successfully. Let me know what you think. And thank you for your kindness and wisdom. --Andy |
send the correct 9280 and 9281 codes to make it appear like Sony Playmemories #16
i did the ptp_sony_9280 a bit different, i think the first argument is actually the number of additional bytes sent. commited your suggestions of 9280 and 9281 usage in camera_init and camera_exit. |
Brilliant! I just pulled the latest and everything works perfectly. I'll try to gather up other Sony users and verify it works for them as well. I'll provide feedback if needed. I think for now we can close this request. Thanks so much for helping. |
very nice :) |
Marcus,
Things work as I would expect after doing this. Let me know if you don't agree. Thanks! --Andy |
Hi Marcus, |
i saw it and already applied the fix to git |
yea! Thanks. Sorry didn't mean to spam you. |
This isn't an issue but rather a future feature request. I'm hoping one day gphoto2 will be able to tell the Sony cameras when it is transferring files and when it is done. You don't need to do this but I wanted to at least bring to your attention what I've figured out so far.
Basically I started up a mini project and I'm hoping to get other Sony users to try it out to verify it works. Please check it out if you have a chance:
https://github.com/falk0069/sony-pm-alt
It is quite a hack job I did to the ptpip.c code. I basically inject 29 data packets in order to tell the Sony camera this info. Also the transactionIDs are all over the board, but the camera doesn't seem to care.
Lastly, You'll notice I created a 500 byte sonyrequest buffer. I only should have needed to defined it as 26 bytes but when I made it smaller I occasionally got a variety of segmentation fault issues. I couldn't figure out where the issue was but I believe it might be the same issue that alik55 reported (#15). I feel that it might be in the logging code since this is where the core dumps generally blew up. Of course I might be doing something completely brain dead with my packet injections. By making the buffer large enough I seemed to avoid any illegal memory boundary writes.
I'm hoping you might entertain this idea and you don't find it upsetting. Please let me know what you think.
Thanks!
The text was updated successfully, but these errors were encountered: