Some Sony properties are reported as readonly but actually aren't #685
Comments
|
currently we set the readonly from the weird sony property blob. the use of these values is guessed. we can globally disabled it again in the code if it does not match reality. |
Oh interesting, I didn't see that code. Let me play around and see if it reports anything different for those properties internally that would allow to distinguish those from the rest of actually readonly props. In most cases it seems to report status correctly, and it would be a shame to lose readonly indicators for all properties when it's only a few that are wrong. Worst case scenario, I believe we should just whitelist those few properties for which we have custom "stepping" handlers as writable even if they're reported as readonly. |
|
i meanwhile disabled this logic until we find a better / more correct way. |
|
Hmm, I'm not sure if that's better. Most properties were reported as readonly correctly, and those few are rather niche. In general, it's very useful to have readonly status reflected in UI for properties you can't change and as long as it works for most common properties, I'd rather leave the current state of things. I think we just need to exclude those by hardcoding vendor/propid combo in readonly check in the end. Btw, we might want to do the same for opposite - e.g., as far as I can tell, there is no way to change "Exposure Program" via PTP API, as those are controlled by physical wheel on the camera - yet it's reported as writable. |
|
ok,. if we have a list then we can add these as overrides... do you have a list? and do we report exposure program as ptp prop? |
For now it's just the props from the issue description, I didn't notice more. Exposure Program comes from PTP as far as I can tell, yeah. From the log above: I believe this is the source that is (incorrectly) reported as writable. |
|
Hi, we are currently running into the same problem. It would help a lot if the following setting on a Sony RX100M7 is editable over libgphoto. We can set this configuration on the camera and the correct value is displayed in gphoto, but we cannot edit it over USB. Thanks a lot. |
|
Any news on this? I ran into that error today. It's working with another version and same camera model. I'll figure out later which versions I'm running. |
Describe the bug
I've noticed that some Sony properties on Sony a6600 are reported as readonly, but if I recompile code to ignore that, they are actually correctly writable.
In particular, I ran into this when trying to change "Exposure Compensation Mode" and "Focus Mode". I believe they are writable because they have custom stepping handlers on a6600, and I checked that those handlers do work correctly. However, the underlying PTP property they're assigned to are read-only, and so the corresponding widgets are incorrectly reported by gphoto2 as read-only too and, as a result, it forbids changes to those widgets.
This is the full dump of
--list-all-config:Name the camera
Sony a6600 (connected via USB PTP)
libgphoto2 and gphoto2 version
output of: gphoto2 --version
To Reproduce
Steps to reproduce the behavior:
Try to list config using
--list-all-configor change one of the properties from the description above viaset-config. You'll get an error when trying to change those properties.However, when changes are made to the code to ignore the readonly status (in gphoto2 https://github.com/gphoto/gphoto2/blob/1cec66dc7b078c470b28cab21bb9f998010e4d87/gphoto2/actions.c#L1827 and in libgphoto2
libgphoto2/camlibs/ptp2/config.c
Line 11156 in 233569b
I believe we need some way to recognise those properties and exclude from readonly list. One way would be to literally hardcode vendor + property combo if the
_get_config, but perhaps there's a cleaner way I didn't think of? @msmeissnThe text was updated successfully, but these errors were encountered: