Gpsd based on gnss-share

I would like to get navit to work. navit uses gpsd and that conflicts with gnss-share. Before I continue with navit, I first have build a possible solution that works with cgps for testing.

My Idea is: (“ok” means already exists, “try” means I have tried to to it)

  1. ok: kernel: /dev/gnss0 (to be used only by for gnss-share.service)
  2. ok: gnss-share.service: /var/run/gnss-share.sock
  3. try: gnss2GPSD.service: /dev/ttyGPSD (to be used only by GPSD2pppd.service)
  4. try: GPSD2pppd.service: pppd (modified /dev/ttyGPSD from gpsd on port 2947)

I have created a script gnss4gpsd, that implements the idea described. If you want to try:
git clone https://salsa.debian.org/debian/librem5-setup.git
cd librem5-setup
apt-get install shellia
./gnss4gpsd -i --setup

It seems to work for me. But I am not sure if this is the correct way.

  • Is it wanted to have both gnss-share and gpsd ? Or are there other reasons, that this should not be done ? For example, would it be better if navit would be modified to use /var/run/gnss-share.sock ?
  • Does it also work for you ?
  • What should be improved ?
2 Likes

No; gnss-share is not something apps should ever be using. They actually can’t use it even if they try because of missing permissions.

gnss-share is used by Geoclue, and that’s the service that’s actually used by applications. Writing a Geoclue backend for Navit would be a better idea.

gpsd being a system service can access gnss-share just like Geoclue does, so that works too. You just need to be aware of all the consequences of exposing your GPS data via gpsd (access control etc.)

3 Likes

Blockquote Writing a Geoclue backend for Navit would be a better idea

I like the idea and I would also add the automatic navigation configuration for navit… but I’m not able to do it :slight_smile: :wink: