I like this kind of feedback. A lot of these suggestions make a lot of sense. I can't really do much about the GPS lock time, as ellweber said it probably already starts searching as soon as the empeg is turned on (i.e. when the remote amp wire becomes active). The NMEA protocol is totally one-sided, and as there are no DTR or RTS/CTS signals and I never send anything, the GPS really doesn't know whether gpsapp is active or not. The long time before a lock probably is as Drakino suggested, the receiver doesn't remember satellite trajectories, last known fix and the time while it is powered down. One solution is to always keep it powered, don't know how quickly it could drain a car battery though. The other solution is probably similar to what the earthmate and tripmate drivers in gpsd are doing, find the magic sequence to upload the current time and approximate location to the gps. Time can come from the empeg clock, while the position can be stored in a config.ini file, even if it is off by about 100 miles it doesn't really matter much, and when it is off by more it will just take 5 minutes again. However, I have no clue as to what the magic incantations might be.

Menu toggle indicators, yeah the menus were just a quick hack. I guess I had 'make the menus better' in the todo-list since the first release. They probably should also be 'context sensitive', toggling 'tracklog' doesn't do anything in the satellite screen, and clearly those popups need some more work. Keeping them up permanently probably isn't that difficult, but others would like to not even see them at all. So with a better menu structure it could become off/popup/on.

Right hand side is distance to final destination, direction to the next waypoint and distance to the next waypoint. There is a distance/time menu option that changes this to ETE (estimated time elapsed) to final destination, direction and ETE to next waypoint. I don't know why everyone wants altitude, maybe I should get a better car that also drives vertically like everyone elses. Speed is probably a nice addition, but do we want an averaged 'velocity made good', i.e. velocity towards the target, or the actual GPS reported speed. I already have both numbers, just need to add them.

And why don't you like the arrow? I find it useful when I don't have an actual route, but just a destination point. As soon as the arrow points sideways I know I probably have to take the next available turn.

The remote IR codes are not intercepted, and it wouldn't be a problem to not hijack the knob turns, but to keep the knob press. Ofcourse we do need some space on the screen to visualize that the knob works for volume (I have a headunit and never use the knob on the empeg for volume control).

I should already have that blinky satellite screen fixed, just need to test it.

That ghosting of the buttons should not happen except if hijack is forgetting to 'hijack' the button codes. My kernel patch was basically prompted by the fact that people had their player switch to AUX and back, which in turn could very well result from the knob press ghosting through.
This is a clear indication that there is something more insidious going on than I first suspected.

The menu and the 'no satellite data' actually use exactly the same 'draw_msg' function to put themselves on the screen, so yeah they probably look quite similar

It would be hard to scroll the actual NMEA messages because by the time I update the screen, I'm working with something more like a summary of the data I got from parsing the messages.