Debugging location issues

I’m having some issues with GPS based location services on the Librem 5 and wondering if anyone can give me some ideas for how to look into this.

I’ve tried several apps that make use of location and essentially location accuracy seems to vary a lot and in some cases is not useable. In some apps it works perfectly so I don’t think there are any hardware or firmware/device driver issues.

  1. PureMaps 3.2.0 installed from Flathub Flatpak - works as expected, accurate fix acquired quickly
  2. Gnome Maps 3.38.6 installed from Purism apt repo .deb - works as expected
  3. Gnome Maps 44.4 installed from Flathub Flatpak - location significantly less accurate (reported accuracy of ~3000m is typical), jumps around too much to be useable
  4. ASHPD Demo - installed from Flathub Flatpak - same as above, location significantly less accurate, jumps around too much to be useable

I’m trying to work out what might be causing the discrepancy. ASHPD and Gnome Maps installed from Flatpak both use the Freedesktop Location portal, which uses the host Geoclue service. PureMaps uses QT location which should also use Geoclue, Gnome Maps from .deb uses Geoclue but not the portal?

Has anyone else seen this or is able to replicate?

1 Like

You may want to log the accuracy being requested from Geoclue by the portal.

@dos I can see in Bustle that accuracy: uint32 5 is being passed by ashpd which corresponds to exact here but I guess that’s what’s being requested by ASHPD of the portal rather than by the portal of geoclue? If that’s correct how would I log that?

It should also be accessible via Bustle, although on the system bus rather than the user one.

The system bus logs also all look correct to me. Testing with ASHPD-demo flatpak, with Wifi switched off and in a location I haven’t got a wifi location cached I see the GeoClue client being setup with the correct params and location being requested:

Type: Method return 
Sender: 1.52
Destination: 1.67
Path: /org/freedesktop/GeoClue2/Client/4
Member: org.freedesktop.DBus.properties.GetAll
Arguments: ({
    'Location': <objectpath '/org/freedesktop/GeoClue2/Client/4/Location/11'>, 
    'DistanceThreshold': <uint32 0>, 
    'TimeThreshold': <uint32 0>, 
    'DesktopId': <'xdg-desktop-portal'>, 
    'RequestedAccuracyLevel': <uint32 5>, 
    'Active': <false>
},)

Type: Method call
Sender: 1.67
Destination: 1.52
Path: /org/freedesktop/GeoClue2/Client/4
Member: org.freedesktop.DBus.properties.Set
Arguments: (
    'org.freedesktop.GeoClue2.Client', 
    'RequestedAccuracyLevel', <uint32 5>
)

Type: Method call
Sender: 1.67
Destination: 1.52
Path: /org/freedesktop/GeoClue2/Client/4
Member: org.freedesktop.GeoClue2.Start
Arguments: ()

Type: Signal
Sender: 1.52
Path: /org/freedesktop/GeoClue2/Client/4
Member: org.freedesktop.DBus.properties.PropertiesChanged
Arguments: ('org.freedesktop.GeoClue2.Client', {'Active': <true>}, @as [])


Type: Directed signal
Sender: 1.52
Destination: 1.67
Path: /org/freedesktop/GeoClue2/Client/4
Member: org.freedesktop.GeoClue2/Client/4
Arguments: (objectpath '/org/freedesktop/GeoClue2/Client/4/Location/11', objectpath '/org/freedesktop/GeoClue2/Client/4/Location/12')

But then the location still ends up being accurate to ~5000m. (Right before this test Gnome Maps deb was showing an accurate location.

Type: Method return 
Sender: 1.52
Destination: 1.67
Path: /org/freedesktop/GeoClue2/Client/4/Location/12
Member: org.freedesktop.DBus.properties.GetAll
Arguments: ({
    'Latitude': <redacted>, 
    'Longitude': <redacted>, 
    'Accuracy': <4902.0>, 
    'Altitude': <redacted>, 
    'Speed': <-1.0>, 
    'Heading': <-1.0>, 
    'Description': <'3GPP'>, 
    'Timestamp': <(uint64 1693572636, uint64 0)>
},)

Accuracy level 5 is GCLUE_ACCURACY_LEVEL_NEIGHBORHOOD, so the Geoclue’s behavior seems correct and it’s the portal that needs to be fixed to pass correct values.

I see this was already fixed upstream (since 1.10.0), but it didn’t make it to the version from bullseye (1.8.1):

2 Likes

@dos thank you! That seems like the missing piece. I guess this will fix itself when Crimson is out then.

What would be your recommendation for getting this fix in in the meantime? Apt pinning?

@dos is there any chance of that fix being backported to Byzantium?

Ended up installing from debian backports with:

# /etc/apt/sources.list

deb https://deb.debian.org/debian bullseye-backports main
sudo apt install -t bullseye-backports xdg-desktop-portal

and seems to work great for now. Hopefully this won’t cause me too many issues come Crimson release.

2 Likes

Can confirm this. After installing this patch, location in GNOME Maps works a lot better :slight_smile:

1 Like