<Entitlement>
uvos - [ GitHub - IMbackK/greeter: greeter app for mameo leste ]
<uvos>
for the first boot part i just created a self deleting script in xsession
<uvos>
ill package it some other time
<parazyd>
We have some firstboot initscript
<parazyd>
I don't recall from which package it comes atm
<uvos>
i dont think gui applications are apropriate in an initscript
<uvos>
it needs to be run by the session manager not openrc
<parazyd>
I meant it could be set up using the initscript
<parazyd>
Like, copy the xsession in place
<uvos>
sure that would be fine
<Wizzup>
maybe it can an icon on the desktop, or a widget, like in fremantle
diejuse1 has joined #maemo-leste
<Wizzup>
uvos: parazyd: here's a thought I had: what if we allow the location status applet to keep location on if there are no clients, in some special mode
<Wizzup>
that way we could have libgps clients work if the user has location-status do that
<Wizzup>
(ofc that is assuming we stop gpsd once the last liblocation client is gone)
<parazyd>
We aren't stopping gpsd once it's started.
<diejuse1>
Hello, I am checking start commands to find out why tapping over "Internet Connection" is not responding. I have seen that I wasn't starting "hildon-sv-notification-daemon". How do I launch it? I get "segmentation fault".
<Wizzup>
which I think makes sense - what if someone turns off location services and gpsd is still running?
<uvos>
wo also dont have to
<Wizzup>
parazyd: I know we're not atm ^
<uvos>
Wizzup: why would we want to stop gpsd
<uvos>
Wizzup: execpt if the user turns off gps in settings?
<Wizzup>
cpa->location->gps->disable
<parazyd>
That button can have a callback to stop it
<Wizzup>
that feels incredibly hacky to me
<Wizzup>
but ymmv
<parazyd>
Why?
<Wizzup>
diejuse1: well, are all the required services running?
<parazyd>
To me it's a button that says enable/disable GPS
<parazyd>
And logic says it should
<Wizzup>
parazyd: so we'd do what, pkill gpsd as sudo from a button in cpa?
<uvos>
this seams reasonable to me to
<uvos>
Wizzup: it would ask openrc to stop it
<parazyd>
OpenRC yeah
<diejuse1>
Wizzup: I don't know what are the required services
<Wizzup>
uvos: how about setting the gconf key to disabled and having location-daemon figure that it should no longer relay info and stop gpsd?
<Wizzup>
since it's all the one to start gpsd
<Wizzup>
It could just monitor for the gconf key change
<uvos>
Wizzup: i would avoid using gconf as ipc when possible
<uvos>
btw
<parazyd>
What if location-daemon isn't running?
<parazyd>
And gpsd is
<Wizzup>
parazyd: then gpsd won't be running, per my logic
<Wizzup>
but not in the current situation
<parazyd>
It's a bit complicated
diejuse1 has quit [Quit: Leaving.]
<Wizzup>
I think it's weird that location-daemon starts on demand, but gpsd does not
<uvos>
Wizzup: we could start gpsd as soon as something uses its soccet
<parazyd>
And this is fine as long as you have GPS-enabled in gconf
<Wizzup>
well, that's not what I mean by on demand
<uvos>
Wizzup: like location-deamon or anything else
<uvos>
Wizzup: idk how to do this with openrc but systemd can do this
<uvos>
maybe you cant with orc
<parazyd>
uvos: xinetd probably
<parazyd>
Wizzup: This problem is why I initally wanted to have the control panel control this behaviour
<Wizzup>
uvos: I don't want gpsd to start unless location-daemon wants it to start, essentially
<uvos>
Wizzup: why
<uvos>
Wizzup: i want navit to just work...
<parazyd>
gpsd is disabled in runlevel
<Wizzup>
becaus them we have to patch gpsd to read the gconf val
<uvos>
Wizzup: no
<parazyd>
And the initscript checks gconf
<uvos>
Wizzup: so if this where systemd i would do this
<parazyd>
If you want to start gpsd with a root shell, you're on your own
<parazyd>
Covering these edge-cases is counterproductive
<uvos>
Wizzup: wirte a service.soccet that runs gpsd if something uses its soccet but only if gconf dosent have gps disabled
<Wizzup>
parazyd: I am responding to uvos saying that we should use socket activation on the gpsd socket
<Wizzup>
that is not 'root shell'
<parazyd>
I don't like that either
<parazyd>
You could simply add your gpsd to a runlevel if you want it autostarted
<Wizzup>
I think the edge cases are important fwiw
<parazyd>
It has zero cost to be running with no clients
<Wizzup>
but I think I'll go for a walk or something, give it some more runs
<uvos>
parazyd: some ram
<Wizzup>
I've already seen the gpsd starting fail in various a few cases
<Wizzup>
openrc forgot gpsd was running
<Wizzup>
but it was running
<Wizzup>
and location-daemon failed to start (I fixed that in master)
<Wizzup>
but still it won't help if we want to stop gpsd and openrc forgets about it, however it happens
<parazyd>
Then let's port the initscript to supervise-daemon rather than start-stop-daemon
<parazyd>
And we're good
<parazyd>
This way openrc can't "forget" about it
<Wizzup>
I really don'r see why we need to keep gpsd running once we no longer need it, but I'll go for a walk and try to see your side of it
<uvos>
i also dont see the point of having it run after location-deamon exits and not starting it on boot
pagurus has quit [Ping timeout: 268 seconds]
<uvos>
either it should allways run
<uvos>
or only with lcocation-deamon
<uvos>
or soccet activation
<Wizzup>
yes, that's what I meant
<uvos>
but really i want gpsd only clients to work
<uvos>
so allways running gpsd or soccet activation is the only thing that would work for me
<parazyd>
gpsd caches useful data, like skyview
<parazyd>
If you stop it, you often slow down getting a future fix
<uvos>
parazyd: ok thats fine
<uvos>
parazyd: but why not start it at boot then?
<parazyd>
Because the disclaimer has to be accepted.
<uvos>
the init scrpt checks the disclaimer
<parazyd>
So you only raise this with a liblocation client
<parazyd>
Correct
<uvos>
so the current behavior could be before the first gpsd client is run and sets it
<uvos>
and then on every other boot gpsd just runs
<Wizzup>
did you benchmark if keeping gpsd on helps? just wondering
diejuse1 has joined #maemo-leste
<Wizzup>
(I know this is all pretty hard to benchmark)
<uvos>
(or runs with the first client via soccet activation)
<parazyd>
Wizzup: Not specifically, but I get a (maybe placebo) faster fix with subsequent cgps runs
<parazyd>
uvos: Well, the initscript will simply fail if the disclaimer is not accepted or gps is disabled.
<parazyd>
Which can also be fine, and keep it in the default runlevel.
<parazyd>
Anyway, to sum up my thoughts:
<parazyd>
I think gpsd should always be running as long as GPS is enabled in control panel, and should be disallowed to run if it's disabled in control panel
<parazyd>
disallowed by initscript
<parazyd>
If someone wants to start it as root in a shell, this is a case we can't cover.
<parazyd>
And we shouldn't IMHO, it would be feature creep and platform lockdown
<uvos>
trying to controll what people do in root shell is silly anyhow
<Wizzup>
(jfyi I wasn't talking about root shell anywhere)
<parazyd>
Wizzup: I'm using it as a metaphor for user starting gpsd outside of the environment/ecosystem
<Wizzup>
sure, agreed
<parazyd>
Further, personally I see nothing wrong with the control panel applet button + Save would stop gpsd via initscript when pressed/saved.
<parazyd>
stop when GPS is chosen to be disabled I mean. It shouldn't be starting anything.
<parazyd>
This is basically the only interface the user has to "control" GPS, and I think one would expect it to stop and disable after the user chooses to.,
<uvos>
i would be fine with this, i have no strong optinon except that plain gpsd apps must work with no additional work.
<parazyd>
Maybe ask some of your friends, what they would expect when this button is pressed.
<uvos>
*opinion
<parazyd>
The three of us just thinking about our cases isn't often the correct solution :p
<diejuse1>
I am trying to start hildon-sv-notification-daemon like "/usr/sbin/dsmetool -t /usr/bin/hildon-sv-notification-daemon" but I get "dsmesock_connect: connection refused". Any orientation?
<parazyd>
You should start dsme first
<parazyd>
There's two initscripts
<parazyd>
/etc/init.d/dsme-dbus and /etc/init.d/dsme
<parazyd>
Also see their dependencies
<diejuse1>
they are both already started: "WARNING: dsme... is already starting"
<diejuse1>
maybe you could give me an ordered list of starting commands to boot normally? Because I think that is the problem.
<parazyd>
Run the commands inside manually
<Wizzup>
diejuse1: try to figure out how to use openrc and the x session scripts from within the chroot
<Wizzup>
that's likely the only way to really do thi
<Wizzup>
s
<Wizzup>
iirc openrc can run in a chroot
<Wizzup>
parazyd: if you keep it always on, how is it started on boot?
<parazyd>
sicelo: The checkbutton "GPS Enabled" in ControlPanel->Location
<sicelo>
Ok
diejuse1 has joined #maemo-leste
<Wizzup>
parazyd: so if I check it again, is gpsd re-added to the runlevel? idgi
<Wizzup>
or do you want to attempt to start it and fail on boot?
<Wizzup>
btw, I think I can live with gpsd running independently of liblocation/location-daemon, but I think it provides a very suboptimal ux, since you cannot see when gps is active if it is through libgps
<Wizzup>
effectively nuking all control and visibility
<Wizzup>
my solution with then status applet to control gpsd when there are libgps but no liblocation clients I think is more clear
<Wizzup>
and it would provide insights through location-daemon as normal as well (wrt fix, blink or not)
<Wizzup>
so if the location status button is always visible and has a UI to say 'keep gps on' and 'open control panel' I think would be a fair middleground
sunshavi has quit [Read error: Connection reset by peer]
<Wizzup>
so the 'keep gps on' button would effectively turn the status applet into a normal location-daemon client, keeping gpsd alive
Dgby714 has joined #maemo-leste
<Wizzup>
it should work for uvos his usecase
<Wizzup>
if it is just about the work required, I am happy and motivated to do it
<Wizzup>
btw, gpsd and modem are happy together for a bit now, so the reset seems random
<uvos>
Wizzup: mutch better would be for the location status icon to monitor the gpsd soccect and pop up if its in use
<uvos>
then the user dosent need to care about if an app uses liblocation or gpsd
<uvos>
and it all just works
<Wizzup>
I do not think gpsd can do that
<Wizzup>
unless you wamt to ptrace gpsd
<uvos>
Wizzup: you can check with the kernel if the soccet has connected users
<Wizzup>
feels like a hack tbh
<uvos>
this is true
pere has joined #maemo-leste
<uvos>
but gpsd flok wernt very open to the idea of adding something better
<Wizzup>
liblocation and the location-daemon dbus signals provide useful info to maemo components, usiong that path seems better
<Wizzup>
yeah, gpsd folk are not helpful
<uvos>
sure we should use that path aswell
<uvos>
but the logic could be something like: check liblocation status and apply unless gpsd has a client thats not location-deamon, then display the icon
<Wizzup>
like I said, I think a simple way to keep loc-daemon and gpsd on for libgps clients makes sense, and then if gpsd *stops* with loc-daemon we also have possibility of no backgrou nd libgps clients
<Wizzup>
so the UI is leading and always source of truth
<uvos>
not really you have to think about if a client you want to open is libgps or liblocation
<uvos>
thats terrible ux
<sicelo>
Not really
<Wizzup>
mhm
<uvos>
the user should not need to know about implmentation details
<Wizzup>
I agree about that, that is not ideal
diejuse1 has quit [Ping timeout: 240 seconds]
random_yanek has quit [Ping timeout: 260 seconds]
<sicelo>
There's a reason why stuff like geoclue was invented and is in use
<Wizzup>
but I think it is not too bad compared to the alternatives
<sicelo>
Basically it's what libloc is
<Wizzup>
sicelo: can you elaborate?
<uvos>
geoclue is gnome tech
<uvos>
for location
<Wizzup>
ok
<uvos>
dose the same stuff as location-deamon
<uvos>
just more and better
<uvos>
(no offense)
<Wizzup>
how does it manage gpsd<
<Wizzup>
?
<uvos>
good question
<parazyd>
14:55 <Wizzup> parazyd: so if I check it again, is gpsd re-added to the runlevel? idgi
<parazyd>
Forget the runlevels
<parazyd>
Just consider gpsd initscript is enabled and in the default runlevel
<parazyd>
The gpsd binary wouldn't start until the disclaimer is accepted + GPS is enabled.
<Wizzup>
what state will openrc think gpsd is in? start requested but failed to start?
<parazyd>
"Stopped"
<parazyd>
Obviously
<Wizzup>
I think the states are more complicated than that
<uvos>
Wizzup: is like a deamon that exits sucessufly
<Wizzup>
parazyd: so how do you think we should handle libgps clients wanting to use gps, and how do we show it in the UI?
<parazyd>
That's the next step.
<parazyd>
Let's solve this.
random_yanek has joined #maemo-leste
<Wizzup>
ok
<Wizzup>
please also look at my proposal above wrt that
<parazyd>
I don't like it because I don't think the status applet should be any kind of control for this.
<parazyd>
We have the control panel.
<parazyd>
It's called "control" for a reason.
<parazyd>
Easy enough to expand on that.
<parazyd>
e.g. suboptions
<Wizzup>
well, it's only control is that it asks for gps data
<Wizzup>
just like 'maep' controls it
<Wizzup>
no more, no less
<Wizzup>
status applets also switch wifi and profiles
<Wizzup>
those are not cpa
<parazyd>
r3ok
<parazyd>
ok
<parazyd>
I can't win this argument really
<parazyd>
So I'll move on to other stuff, I'm sorry
<parazyd>
Got too much to do
<parazyd>
Nothing personal, it just starts becoming a bikeshed
<uvos>
Wizzup: parazyd: how about we just delgate it to parazyd to do what he thinks is best?
<uvos>
since he implmented most of this
<Wizzup>
parazyd: ok, I'll chdeck with fmg, see what he thinks?
<parazyd>
And I can't really discuss UX with just the three of us
<parazyd>
Please ask physical people around you
<parazyd>
Get insights
<parazyd>
It's not just the three of us
<parazyd>
Show the UI and ask "what do you expect this and that does"
<parazyd>
Let's then come to a conclusion
<uvos>
ill just abstain from here on out.
<Wizzup>
I will try to phrase some questions
<Wizzup>
it would be good to have alternatives to handling libgps and ux though
<parazyd>
What does "alternatives" mean?
<Wizzup>
How we would handle a libgps client from Maemo perspective: (1) gpsd just runs and user in unaware (2) location-status does hacks to determine if gpsd has clients and acts appropriately (using libgps backend) (3) clients require gps+gpsd to be enabled specifically, ui implicit (4) ?
<uvos>
Wizzup: your mixing 2 problems anyhwo
<Wizzup>
I think some of questions boil down to how we want to handle that
<Wizzup>
uvos: care to split it out further?
<parazyd>
Wizzup: We started this discussion in whether gpsd should autostart from init or not, and who should stop it.
<parazyd>
Wizzup: Having userspace/GUI reporting of gpsd clients is a different problem
<uvos>
Wizzup: problem 1. when to start gpsd (we must enforce "gps enabled" and "disclamer accepted" in all cases, even malicious clients) 2. how to show gpsd is in use form a source other than location-deamon
<uvos>
problem 1 we can deal with by only starting gpsd when those are accepted by the user and setting permissions on gnss0 adequatly.
<uvos>
those are the problems
<Wizzup>
parazyd: ok, the only solutions I could come up with combine them, but if you have other solutions to the UI?
<uvos>
id just lett parazyd find solutions he likes
<Wizzup>
uvos: problem 1 is more complicated
<Wizzup>
the disclaimer does not relate to location being on whe nit should not
<uvos>
right the initscript works perfectly fine as is
<uvos>
question is just when to run it
<uvos>
and ill defer to parazyd on that
<parazyd>
My proposal is to have it always running as long as privacy is accepted, and gps is enabled in settings
<uvos>
which is fine by me
<parazyd>
This same place (where you change the GPS enabled/disabled setting) should then STOP GPSD when the user chooses to disabled GPS and save the setting.
<uvos>
and how its implmened that ill also defer to parazyd
<parazyd>
Via initscript
<parazyd>
That's all.
<parazyd>
There is no more to problem 1.
<parazyd>
If anyone thinks it's more complicated than this, then something's not right.
<uvos>
parazyd: /dev/gnss0 is world readable
<uvos>
parazyd: atm
<uvos>
parazyd: we need to enforce that gpsd is the only thing that can read it
<uvos>
parazyd: but thats details
<parazyd>
Easy, initscripts often fix permissions.
<uvos>
we can run gpsd in some group
<uvos>
and assing gnss0 via udev
<parazyd>
gpsd really needs root, as far as I've been told by the devs. It then drops privileges asap.
<uvos>
ok
<uvos>
can we have it drop privlages to a gpsd user?
<uvos>
and just have /dev/gnss0 owend by that?
<parazyd>
"Otherwise various permission bugs happen"
<uvos>
or dose it open() as root?
<uvos>
ok
<parazyd>
It does root and group dialout
<uvos>
ok
<parazyd>
So we can group own gnss0 as dialout
<uvos>
right
<uvos>
and remove o+r
<parazyd>
Yes
<uvos>
sounds good
<Wizzup>
hi
<Wizzup>
I think the one of the questions we should answer to move forward is: how do we think we should handle libgps clients when liblocation is not active? I think we seem to have different opinions on that specifically
<Wizzup>
Regardless of init script, what runs when, I think being able to answer the above questions help with figuring out how to continue
<parazyd>
They should be able to use gpsd if GPS is enabled in gconf and gpsd is running.
<Wizzup>
So the user would not be able to tell from the UI, corret?
<parazyd>
Until we implement something in location-status, yes.
<Wizzup>
I'm trying to not let the technical parts (what is running when) mix into the answer
<parazyd>
And this is not related to location-status in any way
<parazyd>
I don't think anything else makes sense when it comes to user's control over gpsd
<Wizzup>
I think that personally, I would prefer that libgps does *not* work, unless the user knows that he/she started a client that uses gps. And if that means the applications don't work unless gps is enabled (through one way or another, not just a disclaimer), then I think that is entirely acceptable, what I think is not acceptable is clients using gpsd without the user knowing
<parazyd>
As for location-status telling you when there are libgps clients, that's an entirely different problem.
<uvos>
Wizzup: from a birds eye view yes libgps should work and yes the user should be informed when it is used
<uvos>
Wizzup: but for now we can only do 1 and we will do 2 later
<Wizzup>
I want to discuss both, since I don't think we can sensibly do (2) if we do a specific (1) now
<parazyd>
Yes we can
<uvos>
here im in the just let parazyd do what he wants camp
<Wizzup>
uvos: I think that's a non-argument and also parazyd asked me to do some work on this
<parazyd>
(2) is a completely different thing
<uvos>
Wizzup: yes it is explicetly a non-argument :)
<uvos>
i lack the detailed knowlage that parazyd has on this subject to even think about trying to tell him what is better
<parazyd>
For me 3 hours of this talk today is enough.
<Wizzup>
parazyd: ok, for (2) how will you let users know libgps clients exist?
<uvos>
Wizzup: for this there are several solutions that need investiagtion
<uvos>
Wizzup: we can check what gnome/kde do
<uvos>
Wizzup: we can try to submitt some patch to gpsd
<sicelo>
Geoclue
<uvos>
sicelo: i know
<Wizzup>
uvos: ok, so we should do more research before continuing?
<uvos>
Wizzup: we can patch libgps
<Wizzup>
uvos: one of solutions being 'gpsd does not run'
<parazyd>
Wizzup: First thought is to watch gpsd's fds in /proc for $DEVICE. Second, look @ geoclue, Third, convince gpsd devs
<uvos>
Wizzup: we can ask the kernel
<Wizzup>
uvos: yes, that also came to mind, to patch libgps
<parazyd>
There's many solutions
<parazyd>
All unrelated to (1)
<Wizzup>
parazyd: watching implies polling
<uvos>
Wizzup: we can just have the status bar check with the kernel if gps is in use directly
<Wizzup>
parazyd: gpsd *not* running is related to (1)
<parazyd>
I don't care, I'm just giving examples of problem relations
<uvos>
Wizzup: via the gnss interface
<Wizzup>
uvos: that implies polling and wakeups, does it not?
<uvos>
Wizzup: no
<parazyd>
Wizzup: There shouldn't be gpsd clients if GPS is disabled in control panel.
<parazyd>
Because gpsd wouldn't be running
<uvos>
Wizzup: all of the solutions i offerd above are totaly indipendant of problem (1)
<Wizzup>
uvos: yes, and I think most of them are not great solutions
<Wizzup>
maybe I just need to research them some to get a better sense
<uvos>
ok Wizzup
<uvos>
its clear there is no consensus here
<uvos>
please wirte up how you would mangae the whole location stack
<uvos>
and link to it here
<parazyd>
++
<Wizzup>
ok
<uvos>
if you want something different than what parazyd wants
<parazyd>
Backlog became too messy
sunshavi has joined #maemo-leste
<parazyd>
Ah just want to also add
<parazyd>
If we patch gpsd, I'd prefer if we then drop location-daemon altogether
<parazyd>
Because we can just modify the dbus export to be what we want.
diejuse1 has joined #maemo-leste
<Wizzup>
fixed one typo
<bencoh>
/59/59
<bencoh>
woops
<Wizzup>
feel free to add other downsides/upsides that I missed
<parazyd>
Wizzup: So how do I use foxtrotgps with this stack implementation?
<parazyd>
Wizzup: Or whatever other libgps client
<uvos>
parazyd: Wizzup wants you activate "active liblocation" mode
<uvos>
so that the location-status becomes a liblocation client
<uvos>
that just keaps the interface open
<uvos>
and then open foxtrotgps
<uvos>
basicly: "start gpsd by hand" (via gu_
<uvos>
basicly: "start gpsd by hand" (via gui)
<parazyd>
So I need to open the status menu, then click the button, and then open the control pannel applet and enable permanent gpsd?
<parazyd>
lol
<uvos>
yeah
<Wizzup>
No
<uvos>
no?
<Wizzup>
uvos: what you said is almost correct: I suggest that (1) location-status is always visible in status menu (2) you can use it to 'Activate GPS' (not enable, that is different)
<uvos>
right
<Wizzup>
(2) would then allow libgps clients to work directly, as it has the effect of starting location-daemon via dbus
<Wizzup>
which starts gpsd
<uvos>
"start gpsd by hand, via gui"
<uvos>
effectivly
<Wizzup>
And then with the same action in reverse, you kill all the libgps clients
<Wizzup>
uvos: If you phrase it like that, yes, but it does not require CPA interaction
<parazyd>
ok, do it :)
<parazyd>
lgtm
<parazyd>
Assuming I can forcefully put gpsd into the default runlevel and I can always have it run
<uvos>
right
<uvos>
thats what i would also do if this is implmented
<parazyd>
And we can keep the current behaviour of it not being in a runlevel by default upon installation.
<Wizzup>
yeah, that should not be a problem
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #maemo-leste
<Wizzup>
we could make that a configurable option, too, to have it start on boot
<Wizzup>
depending on how confusing it gets for the user
jmlich has quit [Remote host closed the connection]
<uvos>
how about we shim libgps to location-deamon
<uvos>
libgps is really trivial
<uvos>
then maybe we can also just ditch gpsd entirely
<uvos>
and rely und linux gnss subsystem
<diejuse1>
I think I have located the problem: "[FAIL] eudev requires devtmps support, udevd did not start ... it failed!"
<diejuse1>
I am trying to mount /dev with that "devtmps support" and looking for other solutions
<diejuse1>
any idea is appreciated :)
cato`[m] has quit [Quit: Idle for 30+ days]
ravelo has joined #maemo-leste
<Wizzup>
uvos: liblocation uses libgps
<uvos>
Wizzup: sure
<Wizzup>
diejuse1: if you document how we can reproduce what you have, it might be easier to help / figure out what you have / what is wrng
<Wizzup>
to make reproduction easier
<uvos>
Wizzup: but not directly
<uvos>
we could staticly compile a libgps with liblocation
<uvos>
*location-deamon
<Wizzup>
yeah, we could
<uvos>
and then replace system libgps
<Wizzup>
I also thought of this, but I feel like this is a potential next step
<Wizzup>
one other thing I forgot to mention
<Wizzup>
I think android has a 'enable location' button, and iirc it just keeps gps *on* all the time
<Wizzup>
so the status button could be seen as analogue to that
<uvos>
Wizzup: no
<uvos>
it dosent
<Wizzup>
are you sure?
<uvos>
yes
<Wizzup>
my brother has an android and his phone always knows his location (google too, etc)
<Wizzup>
maybe google has some android app that does that in the background, then?
<uvos>
yeah that keeps _network_ location on
<Wizzup>
aha
<uvos>
and real android dosent even have that
<uvos>
(ASOP)
<Wizzup>
something I also saw is that geoclue uses a-gps by just looking up the approx location (in delta km) by looking up the lac etc
<uvos>
this is a google services addition
<Wizzup>
it doesn't seem to feed it back
<Wizzup>
uvos: ok
<uvos>
Wizzup: yeah thats a good way to do agps
<Wizzup>
well, it doesn't help the modem get a more accurate lock, though?
<Wizzup>
(was mostly my point)
<Wizzup>
but I suppose it's nice if there's a use for granularty of kilometers
<uvos>
right
<uvos>
the point is to have the location interface
<uvos>
provide the best possible location at all times
<uvos>
sometimes that means accuracy of killometers
<uvos>
ofc it needs to report this uncertenty
<Wizzup>
right
<Wizzup>
location-daemon seems like the place that could eventually support that
<Wizzup>
(or geoclue if we end up using it.)
<uvos>
bonus points to using geoclue
<uvos>
its the companion to iio-sensor-proxy and lets it provide true north via the magnetometer
<diejuse1>
Can I launch the "profile" UI with a command?
<uvos>
btw Wizzup
<uvos>
i have had it multiple times now that dbus-scripts will just stop working for no reason
<uvos>
it just stops updating the ts rotation untill i restart it
<uvos>
no errors or anything and the process is alive
<Wizzup>
uvos: hm, that is worth investigating, I just ported it from fremantle mostly
<Wizzup>
can you install the dbg symbols and gdb attach?
<Wizzup>
diejuse1: I think you should launch it from controlpanel
<uvos>
Wizzup: sure when it happens next time
<Wizzup>
ty
<diejuse1>
Wizzup. I would know if I could launch from terminal
<Wizzup>
diejuse1: ok, let me take a look for you
<Wizzup>
try 'mameo-invoker controlpanel.launch'
<Wizzup>
or just 'controlpanel'
<diejuse1>
But controlpanel launch "settings"
<Wizzup>
is there not a profiles applet there?
<diejuse1>
I would want to launch "select profile"
<diejuse1>
directly
<Wizzup>
I don't know how to do it directly, that's code in status applet
<diejuse1>
From panelcontrol I don't see any access to "select profile". I see "themes", "date and time", "language & region", "display", "notification light", "text input", "internet connections" and "device lock"
<Wizzup>
right, there should be one in the application manager
<Wizzup>
I forgot do we don't have the original one
<diejuse1>
ok
<diejuse1>
I saw that is associated to "profiles_status_menu_item.so". Then is not possible to launch directly a .so file? excuse my ignorance
sunshavi has quit [Remote host closed the connection]
<uvos>
no you have to dlopen it
<Wizzup>
diejuse1: do you not have the status bar on your hildon desktop?
diejuse1 has quit [Ping timeout: 260 seconds]
sunshavi has joined #maemo-leste
cato`[m] has joined #maemo-leste
pagurus has joined #maemo-leste
* enyc
meows
<Wizzup>
tmlind: gps has been solid for 7 hours now
<Wizzup>
no modem resets
<Wizzup>
weird
diejuse1 has joined #maemo-leste
<diejuse1>
Wizzup: Yes, true, it is there.
<Wizzup>
diejuse1: ok, and you can do it from there, but want to do it directly? (launch)
cockroach has joined #maemo-leste
RedW has quit [Remote host closed the connection]
RedW has joined #maemo-leste
<Wizzup>
looks like it broke about 10 mins after my msg (gps)
<Wizzup>
[Mon May 10 23:25:27 2021] phy-mapphone-mdm6600 usb-phy@1: modem status: 0 off