KREYREN has quit [Remote host closed the connection]
KREYREN has joined #maemo-leste
Wikiwide has quit [Read error: Connection reset by peer]
Wikiwide has joined #maemo-leste
cockroach has quit [Quit: leaving]
KREYREN has quit [Ping timeout: 260 seconds]
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
Wizzup: is there any particular reason to keep hifi ? then how to properly deal with mic ?
ceene has joined #maemo-leste
<arno11>
hm, backend management is a bit confusing: able to receive a sip call through ring backend (apparently) with sound in one way
<arno11>
can't get sound anymore (with both backends)
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
arno11: hifi just means regular mic/speakers, so I think hifi is correct here
<sicelo>
arno11: Wizzup is right. there's no reason to not have mic with hifi
<Wizzup>
It's a confusing term perhaps
<Wizzup>
it just means 'good ol pc audio'
<Wizzup>
like, for video calls, other sip calls, or whatever
arno11 has joined #maemo-leste
<arno11>
Wizzup: sicelo: sorry my question was unclear: i meant, if we use hifi profile, does it mean we keep mic activated all the time or ?
Twig has joined #maemo-leste
<sicelo>
maybe think of it this way - on N900 or your pc, what do you need to do before you can record from mic? ;-)
<sicelo>
the answer is - nothing, because (at least in normal cases), you're on HiFi already, and the mic is available/ready for use in that profile too.
<arno11>
ah, so we are supposed to keep it activated all the time, ok
<sicelo>
of course you can specifically mute it (for privacy reasons, for example), otherwise the profile will normally activate it
<arno11>
i need to modify n900 hifi profile then
Livio has joined #maemo-leste
Livio has quit [Ping timeout: 252 seconds]
<arno11>
sicelo: not related but do you think ofono could be the culprit for freeze on startup ?
<Wizzup>
arno11: no mic is not active all the time, just when alsa uses it
<Wizzup>
but yes it should be ready for usde
<arno11>
ok
<Wizzup>
normally only when userspace uses alsa component it is powered on
<Wizzup>
iuc
<Wizzup>
which is why we had trouble with the modem
<arno11>
ah ok
<arno11>
Wizzup: btw i don't remember if you got some freeze on boot (pin entry) on your n900 (before swap troubles ofc)
<arno11>
sicelo also got it iirc, but it seems to work fine with no sim card inside
<Wizzup>
did you not get there then?
<Wizzup>
these*
<arno11>
yep
<sicelo>
arno11: i think ofono is well-behaved. you can experiment with `sudo rc-update del ofono default`.
<sicelo>
that'll require you to start ofono manually
<arno11>
ah ok ty
<Wizzup>
I am not so sure sicelo
<Wizzup>
other services require it so it will get pulled
<Wizzup>
I will try again later today, maybe with serial, and check
<arno11>
ok
<arno11>
the issue is a bit random in fact, sometimes it boots fine, and sometimes i need to remove the battery 4-5 times to be able to boot (with sim)
<arno11>
but maybe that's just my device (and a problem with sim slot maybe)
<arno11>
or the sim card itself
<sicelo>
iirc ofono is started by openrc on leste, so nothing can activate it. that would have been the case if we used dbus activation, yes
<sicelo>
arno11: i do have the problem, and it's 100% reproducible for me.
<sicelo>
something You could try is to remove the Pin requirement from the SIM
<arno11>
ok
<arno11>
what do you mean exactly ?
<sicelo>
the pin entry dialog shows up because your SIM requires Pin. if you disable that on SIM, pin-entry won't come up
<arno11>
ah scratch that
<arno11>
yep ok
<sicelo>
in fact that's probably easiest/quickest way to narrow down the cause
<arno11>
yes indeed
<arno11>
sicelo: btw is it possible to directly disable it form ofono scripts ?
<arno11>
*from
<sicelo>
disable pin? yes
<arno11>
lock-pin ?
<arno11>
or change-pin maybe ?
<sicelo>
i forgot what it is with ofono scripts, but a direct dbus call would look like:
<sicelo>
busctl call org.ofono /n900_2 org.ofono.SimManager UnlockPin ss pin 1234 (if your pin was 1234, amd n900 modem path was /n900_2)
<arno11>
ok ty
Livio has joined #maemo-leste
<sicelo>
ah, there' `unlock-pin` ofono script ;-)
<arno11>
yes indeed :)
<arno11>
seems to work
<arno11>
i'll try to reboot and see
arno11 has left #maemo-leste [#maemo-leste]
arno11 has joined #maemo-leste
<arno11>
still got 2 freezes on boot but when it works, boot time is a way faster with no pin
uvos__ has joined #maemo-leste
<uvos__>
did we enable openrc parallelized starting of services?
<uvos__>
i have that on my d4 but im not sure if i did that
<uvos__>
if so thats probubly bad for n900
<uvos__>
since its constantly close to oom
uvos__ has quit [Client Quit]
<arno11>
interesting
<sicelo>
rc_parallel is disabled
RedW has quit [Ping timeout: 252 seconds]
xmn has joined #maemo-leste
<arno11>
sicelo: what is clearer now is the moment when it freezes: when H-D is appearing, time + battery + network + desktop icons + widgets are visible after few sec then it freezes few sec later
xmn has quit [Ping timeout: 260 seconds]
<arno11>
btw n900 is not really constantly close to oom, leste even works with no swap on it, just multitasking (let's say 3-4 apps opened) is not usable
<arno11>
and the device is not faster with no swap (but with all tweaks) meaning imo that swapping is not really slowing down all stuff
<arno11>
as KREYREN confirmed, the ui is now really responsive with lastest tweaks, even not sure d4 responsiveness is superior with original transitions file.
<sicelo>
d4 is obviously going to be superior :-)
<arno11>
yep
<sicelo>
but yeah, FUD isn't useful either
pere has quit [Ping timeout: 252 seconds]
RedW has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__>
oom might not be quite right, since there is swap, but it its under constant memory pressure
<uvos__>
thats not fud its just a fact
<uvos__>
thanks for confirming that i just enabled the parallelizeing locally
arno11 has left #maemo-leste [#maemo-leste]
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
leste has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
cockroach has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
wow it tooks me almost 40 min to be able to boot...
<arno11>
i had to finally use fremantle to free up memory a bit in leste, removing mafw stuff from xsession
<arno11>
and then, able to boot
<arno11>
so even if memory is ok after boot, seems really near oom during boot as uvos said
<uvos__>
the way the xsession scripts work is not that great for n900 i gues
<uvos__>
we launch lots of proccesies in parralell
<uvos__>
instead maybe should wait for things to stabalise before launching the next thing on n900
<arno11>
yes and that's a bit confusing
<uvos__>
but this is hard to do with xsession
<uvos__>
we would need some thing to manage user session deamons like systemd can
<uvos__>
so either that or something custom (very common for desktop des to have something cusom here)
<uvos__>
anyhow not so tivial changes
<arno11>
the weird stuff is boot issue is totally random
<arno11>
sometimes ok, sometimes quite impossible to boot
<arno11>
anyway, true that we can't add more stuff on boot atm
vectis has quit [Ping timeout: 255 seconds]
Livio has quit [Ping timeout: 245 seconds]
vectis has joined #maemo-leste
<arno11>
btw how to explain that memory is just a problem on boot and not from userspace ? running 20 apps at the same time causes no troubles
<arno11>
maybe something is wrong with swap on boot? (like no swap)
<uvos__>
arno11: well swap may activate to late yes, but also having lots of swap used is not a problem per say but having lots of hot pages in swap is because then you are thrashing
<uvos__>
during boot lots of different stuff is happening so manny pages are hot
<uvos__>
possibly to manny for the kernel not to end up compleatly stalled
<uvos__>
once booted you opening alot of apps dosent matter as mutch as long as those apps arnt doing anything and thus need pages swaped in constantly
<arno11>
ok thx for clarifying
cockroach has quit [Quit: leaving]
enyc has quit [Ping timeout: 248 seconds]
<arno11>
hm conversations use 35MB in background now, a lot more than previously
<arno11>
d4dsc: ^^^ any idea why ?
<arno11>
*uses
enyc has joined #maemo-leste
<arno11>
scratch that, back to normal :)
<dsc_>
arno11: what is normal? :D
<dsc_>
I'd say 35MB is not so much
<arno11>
yeah that's the maximum i see, it is usually around 20MB
<dsc_>
Qt memory alloc greediness depends on several things, its hard to pinpoint when it does what
<dsc_>
for example, on d4 idle is around 50MB (never 20-30MB)
<arno11>
ok
enyc has quit [Ping timeout: 260 seconds]
<arno11>
i just wonder how stuff like conversations can use so much memory just for msgs lol
<bencoh>
because of how the underlying toolkit works I'd say
<bencoh>
(toolkit and used widgets)
<arno11>
ok
enyc has joined #maemo-leste
<uvos__>
modern toolkits use alot of memory everywhere a memory/speed tradeoff can be made as speed is gennerally more precious than space on modern devices, that comes in the form of scrolling buffers, holding huge acellerated contexts, holding caches for a veriaty of resources and surfaces. Additionally theres stuff like qtquick that means executeing scripts which in turn means spinning up interpreters, modern theming engines are also scripts whith thair own
<uvos__>
interpreters. Toolkits must expect that the dpi of any suface may change at any time (eg because it was moved to a diffferent monitor) this also means holding resources for those and it goes on like this
<uvos__>
really if we want to port leste to a modern toolkit from gtk2 i strongly doubt that continuing support for n900 is possible.
<uvos__>
of we dont have the resources to move away from gtk2 anyhow atm, so n900 is safe for the forseable future
<arno11>
yep all of this makes sense
<uvos__>
to share some expirance from the android world: android 2.x's native toolkit worked very much like gtk2 as in it simply displayed fixed sized pixmaps using the cpu for rendering.
<uvos__>
in android 4.0 this was changed to ogl accelerated rendering of vector graphics simmilar to how modern linux toolkits like qtquick also work
<uvos__>
this ment a over night doubleing of the ram requirements of android despite a large amount of optimization effort
<Wizzup>
I don't think gtk3 is ogl accelerated but their theming is more complicated
<uvos__>
gtk3 is old
<uvos__>
really old
* Wizzup
taps out
<uvos__>
qwidgets is also mostly unaccelerated
<sicelo>
we'll have to switch N900 to i3 at some point ;-)
lexik has joined #maemo-leste
<uvos__>
anyhwo android 4.0 indeed is also the cutoff where the droid1 stopped being usefull (althoug you could bearly runn it)
<dsc_>
conversations doesnt do qtquick on startup, so only widgets
<Wizzup>
arno11: rtcom-messaging-ui uses more than 35MB on fremantle think
<Wizzup>
I think*
<dsc_>
however, conversations links against many shared libs, see `ldd`. I think memory usage is due to that also
<arno11>
Wizzup: oh really ?
<Wizzup>
mhm
<Wizzup>
I don't think leste uses a lot more ram than fremantle
<arno11>
dsc_: ok
<uvos__>
well you have to count sphones 20 or so mb too
<uvos__>
oh messaging ui
<arno11>
Wizzup: yes probably
<uvos__>
nvm
<Wizzup>
yes, rtcom-call-ui is the equivalent
<arno11>
atm the real problem is only on boot, specially after H-D starts to load
<Wizzup>
I think some serial or profiling will help
<arno11>
otherwise, that's fine in userspace, even probably better than fremantle actually
<arno11>
Wizzup: yes maybe
<arno11>
Wizzup: btw is it safe to block conversations from xsession and start it from userspace instead ? (just to free up some mem on boot and see if it helps)
<sicelo>
yes @serial
<sicelo>
otherwise we're groping in the dark
<dsc_>
yes you can block from xsession
<dsc_>
or just `rm /usr/bin/conversations` like I do
<dsc_>
(I generally run debug builds)
<arno11>
ok thx
<arno11>
let's try
<arno11>
to reboot
arno11 has left #maemo-leste [#maemo-leste]
xmn has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
ok, it does the trick
<arno11>
2 min to boot instead of 4
<arno11>
just around 20 sec unresponsive once everything is loaded
<arno11>
and then everything is ok
<arno11>
so definitely (near) oom on boot
<arno11>
i removed mafw and conversations from xsession and start conversations --background from userspace
<arno11>
will reboot again to doublecheck
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
arno11: it is safe, but remember you might miss smses on boot
arno11 has joined #maemo-leste
<uvos__>
why whould you miss sms? if there is no one to read the sms they should stay in the buffer no?
<uvos__>
otherwise you may miss sms anyhow since ofono may start before conversations is ready
<sicelo>
yes, the latter ... ofono will receive the sms immediately and it'll get lost
<uvos__>
hmm thats bad
<sicelo>
yeah, i've sometimes wondered why ofono handles sms in this way.
<sicelo>
ModemManager stores them itself afaik
<Wizzup>
mission-control will still launch conversations for the incoming messages/channel fwiw
<uvos__>
none of this helps during boot
<uvos__>
rn at least using sphone for sms i know ofono starts after sphone
<uvos__>
but this is just a race
<uvos__>
*sphone is ready
<Wizzup>
the same is true for tp-ring
<arno11>
Wizzup: 2 reboots with no issue, that's fine for me with this workaround. now i can continue cmtspeech and ucm stuff :)
<uvos__>
sure but its just a race it currently winns
<Wizzup>
luckily we have full control over this
<uvos__>
so we
<Wizzup>
arno11: sounds good
<uvos__>
who sais that conversations isent stalled on startup
<uvos__>
due to memory pressure for instance
<uvos__>
(before its ready to store msgs)
<Wizzup>
it gets startd on startup, so I don't know who said it but it's wrong
<Wizzup>
arno was talking about purpusefully not starting it on boot
<uvos__>
sure but curretly
<uvos__>
the n900 stalls for a long time starting converstaions
<uvos__>
if ofonos startup is not stalled during this time
<uvos__>
you end up with ofono comeing up before
<uvos__>
even if it isent happening right now it can happen
<Wizzup>
ofono can be up if the mdeom is not online'd by cellulard
<Wizzup>
which can be done upon h-d ready signal
<Wizzup>
this is not an unsolvable problem
<uvos__>
and converstaions is guarenteed to be finished before this signal?
<Wizzup>
sure it can be
<uvos__>
ok but atm no
<uvos__>
but ok
<uvos__>
i should finish the modemmanager code for sphone
<sicelo>
ah right - forgot that the modem needs to be online first (and yes it won't online itself). my bad
<Wizzup>
yeah it's not a problem
<uvos__>
i mean it still kinda is
<uvos__>
what if sphone/conversations crashes
<uvos__>
during the restart you could loose sms
<Wizzup>
conversations restarts
<uvos__>
so?
<Wizzup>
and tp-ring keeps it like I said
<uvos__>
doseent matter
<uvos__>
if the first rung after ofono crashes
<Wizzup>
I know you're trying to find flaws in it, but it works, has since n900/fremantle :)
<uvos__>
during restart it could loose messages
<uvos__>
no its plain bad
* Wizzup
sighs and goes to do something else
<sicelo>
uvos__: solution?
<uvos__>
sicelo: not sure
<sicelo>
if whoever fetches message from ofono crashes, then yeah, it seems logically unavoidable that the message will get lost forever.
<sicelo>
i guess solution is if ofono stores message until someone has acknowledged collecting it.
<sicelo>
but yeah, this isn't how ofono works currently
<uvos__>
i gues its not a huge problem if whomever collects messages from ofono is somehing small and simple
<uvos__>
but its a bit of a defect
Livio has joined #maemo-leste
Twig has quit [Ping timeout: 252 seconds]
uvos__ has quit [Remote host closed the connection]
cockroach has joined #maemo-leste
akossh has joined #maemo-leste
ceene has quit [Remote host closed the connection]
<sicelo>
i'll respond, but just want to be sure i'm not mistaken in my understanding perhaps
Livio has quit [Ping timeout: 276 seconds]
Livio has joined #maemo-leste
nmdv has joined #maemo-leste
Twig has quit [Remote host closed the connection]
kiva has joined #maemo-leste
Wikiwide has joined #maemo-leste
<kiva>
uvos: I readed logs about weeks ago and you said: "i dont think anyone uses the pinephone in a major way besides testing even"...well I use! And for everything last 6 months...even banking and streaming tv-news from local broadcasting company web-site. Ok..I use it with Pinephone Keyboard, without it Leste quite hard to use (virtual keyboard is not
<kiva>
show to OS as keyboard device)...with it Leste is the best OS for it.
nmdv has quit [Remote host closed the connection]
nmdv has joined #maemo-leste
Livio has quit [Ping timeout: 248 seconds]
kiva has quit [Quit: Client closed]
arno11 has left #maemo-leste [#maemo-leste]
uvos has joined #maemo-leste
<uvos>
kiva: i was refering to leste devs there, but thats great, the pp deserves more testing exposure
<uvos>
sicelo: its not a rotation matrix for mapphones either, but then again that driver supports a bunch of chips, maybe some have the axis readings flipped vs others
<uvos>
sicelo: im not sure if that consitutes a bug or not
<uvos>
sicelo: actually im not sure that your matrix isent a rotation matrix, i gues andreas did the math, essentally this means that you cant solve the system of equations for values of alpha beta and gamma so that the matrix given equates to the general 3d roation matrix