N900 GPS information
 

The GPS on the N900 is accessed by sending isi/phonet messages to the cellular modem.

The messages being sent/received are defined in pn_location_isi.h which can be found in:
http://mirrors.muarf.org/maemo/apt-m...+0m5_armel.deb

The location-daemon binary sends these messages:
LS_HYBRID_TRACKING_REQ with sub blocks LS_SB_HYBRID_TRACKING_INSTR and LS_SB_CLIENT_IDENT

and receives these messages:
LS_HYBRID_TRACKING_RESP
LS_GPS_STATUS_IND
LS_HYBRID_TRACKING_NTF with sub blocks LS_SB_NPE_POSITION, LS_SB_NPE_TIME, LS_SB_NPE_VELOCITY, LS_SB_NPE_CHANNELS, LS_SB_NPE_NMEA, LS_SB_CELL_INFO_GSM and LS_SB_CELL_INFO_WCDMA

The location-proxy binary sends these messages:
LS_SUPL_NW_INIT_REQ
LS_SOCKET_CLOSE_RESPONSE_NTF
LS_SOCKET_OPEN_RESPONSE_NTF with sub blocks LS_SB_SOCKET_IPADDR and LS_SB_SOCKET_BEARER_TYPE
LS_PRIVACY_NOTIFICATION_RESULT_REQ
LS_SOCKET_CLOSED_REQ
LS_SUPL_SERVER_CONF_REQ with sub block LS_SB_SOCKET_ADDR
LS_PRIVACY_REGISTRATION_REQ
LS_SOCKET_REGISTRATION_REQ
LS_SOCKET_SEND_RESPONSE_NTF
LS_SOCKET_RECV_REQ

and receives these messages:
LS_PRIVACY_REGISTRATION_RESP
LS_PRIVACY_NOTIFICATION_RESULT_RESP
LS_SUPL_SERVER_CONF_RESP
LS_SUPL_NW_INIT_RESP
LS_SOCKET_REGISTRATION_RESP
LS_SOCKET_OPEN_REQUEST_NTF with sub blocks LS_SB_SOCKET_ADDR_EXT, LS_SB_SOCKET_BEARER_TYPE and LS_SB_SOCKET_ADDR
LS_SOCKET_SEND_REQUEST_NTF
LS_SOCKET_CLOSE_REQUEST_NTF
LS_PRIVACY_NTF with sub blocks LS_SB_LATITUDE_LONGITUDE, LS_SB_SS_CODEWORD, LS_SB_SS_SERVICE_TYPE_ID, LS_SB_SS_REQUESTOR_ID, LS_SB_SS_CLIENT_EXT_ID, LS_SB_SS_CLIENT_NAME, LS_SB_SS_NOTIFICATION_INFO and LS_SB_ALTITUDE

The clear-gps-cache binary (used to clear out stored GPS information) sends these messages
LS_CLEAR_GPS_DATA_REQ

and receives these messages
LS_CLEAR_GPS_DATA_RESP

Re: N900 GPS information
 

My suggested to-do for N900 GPS on Leste based on my own reverse engineering of the GPS system on the N900:
1.Update current N900 GPS bits for Leste to use the actual structures and constants from Nokia rather than hardcoding everything and trying to work from blind reverse engineering and potentially not catching all the corner cases and other things that may not show up in regular testing. This means dealing with LS_HYBRID_TRACKING_REQ, LS_HYBRID_TRACKING_NTF and PNS_SUBSCRIBED_RESOURCES_IND.
2.Handle LS_HYBRID_TRACKING_RESP and LS_GPS_STATUS_IND (although it would appear that location-daemon doesn't actually do anything with LS_GPS_STATUS_IND other than some debug logging)
3.Handle the case where the cellular modem changes state (i.e. correctly initializing GPS when the modem comes back up or whatever which would include airplane mode I suspect)
4.Reverse engineer location-proxy and liblas (and libisi if need be) and come up with a suitable clone for Leste that does what is needed and make that blob load as required.
and 5.Related to that, look into the wappushd stuff and whether location-proxy actually does anything with that and whether Leste needs to do anything with that (I cant tell just by looking at the binary if it does or not)