Now I'm wondering, when I committed the change roger posted later in this thread, if indeed I broke the changes you made, I will have to check into that.
What I have found, is calling all the entry points for equatorial co-ordinates, it appeared to be working, I calculating correct offsets for a goto etc, but when I left the mount tracking, turns out calls into the alignment system are actually turning it into a 'stationary' mount. I call in with updated ra/dec, and after it comes out of the transform, it's transformed to a spot that is stationary in alt/az co-ordinate space, ie the mount no longer appears to be tracking. But when I hacked up the driver to use alt/az inputs to the system, it works just fine, I just used libnova calls to transform current ra/dec values to alt/az values, now it's all working correctly. I'm going to re-do the hacks now to use ha/dec and see how that works out.
But, there has also been a lot of confusion on my part going thru all the different transform variations. What I've been looking at, is in all honesty, we shouldn't need to expose things like telescope direction vectors etc to the low level drivers. If we do a clean set of encapsulations into the base telescope class, it should be possible to hide all of that from a basic telescope driver, and bury all the the dealing with to/from telescope direction vectors etc into a couple of simple functions along this line:-
MountToSky
SkyToMount
Sync
If those are properly implemented in the base telescope class, then there is really no need for a mount driver to be aware of anything other than it's own co-ordinate space. On top of that, there are only really two variations of co-ordinates to deal with. In the first case, an alt/az or ha/dec style mount, is dealing with a co-ordinate space fixed relative to the mount, we can initialize with a hint as to orientation, but after it's got two sync points, even that is no longer necessary. Then another variation, is a mount that returns ra/dec values when queried, and it's in a co-ordinate space fixed relative to the sky. that can be buried into one intialization call, and the rest can be well hidden in the base telescope class, so that a driver never need deal with things like telescope direction vectors and transforms. It just says 'here is where I think I am, give me back a fixed pair of numbers to say where I really am'.
So I've once again got a hacked up variant of the synscan driver workign here, and i'm going to clean up the hacks again, then look at putting it all in the temma2 driver. But a thought that keeps running thru my mind, it's about the same amount of work to put it in the temma driver as it would be to put it in the base telescope class. If I bury all of the dealing with telescope direction vectors and such into the base telescope class, then implementing into more drivers becomes trivial, if any work at all. If it's done thru the NewRaDec, Sync and Goto hooks already in the base telescope, then any drivers using base telescope will magically inherit the alignment implementation, and it'll all 'just work'. It would sure help keep drivers simple because writing a driver for a new type of mount would not require understanding all the hoops and jumps necessary to go between equatorial, celestial, alt/az and telescope direction vectors. Just let the hooks already in place for sync, goto, and NewRaDec deal with it all transparently.