Add AutomationTechnology C6 to legacy exceptions; add ARV_QUIRK_LEGACY_ENDIANNESS env var

[eudoxos]

Please have a look what it feels like. I don't feel strong about the env var workaround (and the name could be also different); for quick testing, it could work better than repeated instruction "add to the exception list and recompile".

[EmmanuelP]

Thanks. I will commit the new entry.

I don't really want to make it easy to enable the legacy workaround, as I'd like to be kept informed about the devices requiring the workaround. Once a user has patched aravis, there is more chance I will get a merge request.

[eudoxos]

For me it is okay this way. I understand your reasoning as well. I just think that there would be more people without resources to recompile (time, motivation, skills, ...) who will just leave Aravis if they don't have a quick way to override this.

[EmmanuelP]

Pushed the first commit to main.

Thanks.

[eudoxos]

I would have a compromise solution. Use the environment variable, but then display an annoying warning like this:

!!! WARNING:
!!! ARV_QUIRK_LEGACY_ENDIANNESS is being used with camera "Manufacturer etc" / "Model name".
!!! This is meant for debugging-only.
!!! Please follow this link to submit your camera to Aravis exception list:
!!!    https://github.com/AravisProject/aravis/issue/new?...[contains pre-filled camera details]
!!! It will help other Aravis users and this message will disappear.
!!! Thank you.

Don't forget that many users these days have Aravis pre-packaged (in my case both msys2 and debian), and recompilation is really not easy for everybody. Msys2 package will take a few weeks to contain the exception after being submitted; for Debian, it might take literally years (stable distribution).

[EmmanuelP]

Event better, I think we should be able to detect when the quirk is required, by reading a 4 byte register with the 2 methods (register and memory read). I have to experiment a bit with this idea.

[eudoxos]

I mentioned that in one of my (chaotic) replies in the discussion here: would the GevDeviceModeIsBigEndian node be of any use? I skimmed genicam data of some of the cameras on the exception list (here in issue reports) and a few of them actually had that node.

A possible heuristics would be to read a 2-byte range-restricted node and see which endianness yields a value within range (such as Width or Height).