Compass App
#11
Would you consider adding current .deb and .rpm builds to your git?
When I do a reinstall I usually grab the installed packages list first and then can re-add the software I had.
I often end up missing some of the apps I had to do a make install.
Again thanks for Compass!
  Reply
#12
(07-28-2021, 01:07 AM)biketool Wrote: Would you consider adding current .deb and .rpm builds to your git?
When I do a reinstall I usually grab the installed packages list first and then can re-add the software I had. 
I often end up missing some of the apps I had to do a make install.
Again thanks for Compass!

While I don't have any experience with packaging, I am considering adding a flatpak given that it's already generated by the gnome-builder project.

In theory the flatpak should work across the various distributions, so hopefully there will be no need for other kinds of packages. It would probably be overkill anyway for a simple app like this one.
  Reply
#13
(07-30-2021, 04:17 AM)lgtrombetta Wrote:
(07-28-2021, 01:07 AM)biketool Wrote: Would you consider adding current .deb and .rpm builds to your git?
When I do a reinstall I usually grab the installed packages list first and then can re-add the software I had. 
I often end up missing some of the apps I had to do a make install.
Again thanks for Compass!

While I don't have any experience with packaging, I am considering adding a flatpak given that it's already generated by the gnome-builder project.

In theory the flatpak should work across the various distributions, so hopefully there will be no need for other kinds of packages. It would probably be overkill anyway for a simple app like this one.

That sounds like an exciting possibility for us users across the pineverse!
  Reply
#14
Thanks so much for this tool. I was wondering what was happening with the magnetometer and found this thread. Smile

I was tracking down a problem with GeoClue and the heading always pointing North and wanted to figure out the source of the problem. It appears that other sensors such as the Intel Sensor Hub are able to provide directly the angle to magnetic north and provide that as an IIO attribute in_rot_from_north_magnetic_tilt. I suppose that those sensors have some form of internal calibration either in hardware or in their kernel driver.

I'm wondering if there might be a way to push some of the logic for this app into iio-sensor-proxy, which might be applicable to to a wide variety of sensors. The question is what to do about the calibration. Perhaps it can be read from a configuration file that is generated with a helper app or maybe there is some way to auto-calibrate as the phone moves around enough.
  Reply
#15
(09-09-2021, 08:42 PM)newton688 Wrote: Thanks so much for this tool. I was wondering what was happening with the magnetometer and found this thread. Smile

I was tracking down a problem with GeoClue and the heading always pointing North and wanted to figure out the source of the problem. It appears that other sensors such as the Intel Sensor Hub are able to provide directly the angle to magnetic north and provide that as an IIO attribute in_rot_from_north_magnetic_tilt. I suppose that those sensors have some form of internal calibration either in hardware or in their kernel driver.

I'm wondering if there might be a way to push some of the logic for this app into iio-sensor-proxy, which might be applicable to to a wide variety of sensors. The question is what to do about the calibration. Perhaps it can be read from a configuration file that is generated with a helper app or maybe there is some way to auto-calibrate as the phone moves around enough.

Well, after working on this app I've been trying to help with something similar in UT for the Pinephone. In UT there is an intermediate layer carrying the sensor logic called sensorfw (which comes from Sailfish OS), sitting between the kernel driver and the applications. This includes auto-calibration, which turned out to have a bug preventing it from working properly.

Thanks to some very knowledgeable people already working on improving the Pinephone sensors in UT, I was able to make a small contribution including a fix for auto-calibration. Here's the draft for an MR to the sensorfw library, in case anybody is interested:

https://github.com/ubports/sensorfw/pull/4

Now, I was actually thinking on bringing some of this auto-calibration logic to the Compass app, as it seems fairly simple. But of course it makes more sense to have it in a middle layer instead, like in UT. I am not familiar with the sensor stack in distros using Phosh and what the sensorfw equivalent would be. Also I am not an expert by any measure. However, if anybody else knows about this I'd be glad to jump in and try to help them with what I can.
  Reply
#16
(09-13-2021, 11:57 AM)lgtrombetta Wrote: Well, after working on this app I've been trying to help with something similar in UT for the Pinephone. In UT there is an intermediate layer carrying the sensor logic called sensorfw (which comes from Sailfish OS), sitting between the kernel driver and the applications. This includes auto-calibration, which turned out to have a bug preventing it from working properly.

Thanks to some very knowledgeable people already working on improving the Pinephone sensors in UT, I was able to make a small contribution including a fix for auto-calibration. Here's the draft for an MR to the sensorfw library, in case anybody is interested:

https://github.com/ubports/sensorfw/pull/4

Now, I was actually thinking on bringing some of this auto-calibration logic to the Compass app, as it seems fairly simple. But of course it makes more sense to have it in a middle layer instead, like in UT. I am not familiar with the sensor stack in distros using Phosh and what the sensorfw equivalent would be. Also I am not an expert by any measure. However, if anybody else knows about this I'd be glad to jump in and try to help them with what I can.

Sadly, it seems that there will need to be some kind of duplication of what you've done with sensorfw somewhere in the iio-sensor-proxy stack to bring this functionality into this side of the stack. It's too bad that Linux can't be more unified to avoid all the duplicated effort with Ofono/ModemManager, Gtk/Qt, ...

It's good news that auto-calibration should be possible though. That will make things much simpler.
  Reply
#17
It maybe possible to change this compass app over to using DBUS with the iio-sensor-proxy and/or GeoClue so that it could work on more Linux platforms. If there's a way to get the auto-calibration logic into this patch to the sensor proxy then I think that could make a big difference to alot of people.

https://gitlab.freedesktop.org/hadess/ii...a8ccbde8b2
  Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)