Thanks Hy!
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' 
Read More...
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:
At least in equatorial mode. In Horizon mode it does work - but I never use that. Here for comparison how it should look:
I tried deleting some points so it's just a 'line' (it had to be a closed area in earlier days). Also tested the 'ceiling mode toggle' but that made it even worse. What happened?
Read More...
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.
Read More...
+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
Read More...
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.
Read More...
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.
Read More...
Good
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.
Read More...
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.
Read More...
OK, a few questions:
You are running 64bit Linux, yes? What does 'uname -a' report?
Version 1.26 has fixed the issues with 64bit ARM. So it should work. If you still have issues, it might well be some other problem.
Compiling: Not 100% sure, but I think for compiling INDI there should be enough RAM. No need to fiddle with kstars.
Read More...