I did just pull the latest git, which has that change in indeed. And rendering is normal again now
I even tried to understand what is going on in that routine, but eventually gave up. Too little knowledge of C++ and the internal kstars layout. So I better restrict my contributions to finding errors, and let the masters fix them
But as I always create RPM packages when compiling I can easily switch them if they 'misbehave'
After some Astro-Outage due to too much work load, I compiled the latest version of kstars today to get myself up to date.
The very first thing I noticed is that the display of the artificial horizon is now completely messed up:
Well, the '--' option in the filter wheel[/i] selection of align is there. It is what I always use. If it doesn't know about a wheel it doesn't try to change filters
You just have to activate/select it before starting the acquisition.
+1, I was hit by that, too: I have two connected at the same time, and numbering may change depending on where they are plugged in which messes up filter names and filter offsets....
Same will happen with EAFs
Where did you install INDI? You might have to adapt paths in Settings->Configure KStars->INDI.
And check (Serrings->Toolbars shown) that the INDI toolbar is active and (Settings->Configure Toolbars->INDI Toolbar) contains the proper entries.
Also careful when self compiling/installing that you don't have multiple versions interfering.
Why should they fight? The algorithm just sends (additional) tuning commands to ensure you are out of a possible BL. They don't do any harm if there is no BL. Whether the latter is because the system doesn't have it, or because a driver-internal correction is in place, doesn't matter.
I have the driver BL correction of my EAF active, and no problems with the two linear algorithms.
I think that indicates that the program was compiled against a different lib and/or using headers from another version. But there I'm on very thin ice, so maybe some of the devs can give deeper info how to proceed.
Well, the first thing would be to get the proper library, not from armv8, but from armv7, and install it at the proper place, definitely not in something like x86_64. I don't have a debian-based Pi, so I can't tell you where it is supposed to end up.
But AFAIR only 64bit ARMs were affected, so back to: Find out what the problem is. I don't think it's the broken ASI libs.
A first try could be to log in to the Pi and run indi_asi_ccd from the command line, and report the error you get.