<freemangordon>
hmm, on the first reboot after kernel upgrade, wifi connected on the first try
<freemangordon>
dunno if it is because kernel upgrade or icd plugin upgrade, but still :)
<freemangordon>
uvos: "4.582580] of: /cpus/cpu@1: Couldn't find opp node"
<freemangordon>
tmlind: ^^^
<Wizzup>
which version is this?
pere has quit [Ping timeout: 252 seconds]
<freemangordon>
Wizzup: Linux devuan-droid4 6.1.67 #1 SMP PREEMPT Thu Dec 14 01:53:20 UTC 2023 armv7l GNU/Linux
<Wizzup>
ok
uvos__ has joined #maemo-leste
<uvos__>
hmm yeah i see
<uvos__>
so i updted omap4 from opp-1 to opp-2, wierd is that despite this warning cpu1 has an opp table (that it shares with cpu0 anyhow since they share a common clock)
<uvos__>
so i probubly just forgot to mark this fact somehow
<uvos__>
*has an opp table in sysfs
<uvos__>
so i need to figure out why its complaining, but it has no practical effect
<freemangordon>
maybe you have to mark cpu0 table as shared or common, or, dunno
<uvos__>
i thought i did
<uvos__>
but clearly not correctly
<freemangordon>
yeah
<freemangordon>
uvos__: hmm: "opp-shared: Indicates that device nodes using this OPP Table Node's phandle switch their DVFS state together, i.e. they share clock/voltage/current lines. Missing property means devices have independent clock/voltage/current lines, but they share OPP tables."
<Wizzup>
this should be fairly easy to add to maeotp right?
<Wizzup>
(testing it now btw)
Evil_Bob has quit [Quit: brb]
<sicelo>
yes, in fact i was thinking to use some C library for it.
<Wizzup>
sicelo: that worked
<sicelo>
awesome :-)
<Wizzup>
sicelo: either that or depend on basez and shell :p
<Wizzup>
let me look
<Wizzup>
libbaseencode1 is in apt
<Wizzup>
it seems to suggest to use libcotp
<Wizzup>
but that is only for version 2, and we have 12 (1.2) in debian I guess :)
<Wizzup>
in any case should we detect whether the key is in base32 or not in the app and just do the right thing? or do you want to make it explicit
<Wizzup>
(checkbox for 'this is base32 encoded')
<Wizzup>
sicelo: we can modify return_if_ok and have it check if the key is base32 ?
<sicelo>
i am not able to look at the code yet, but back when i ported it, my C-fu was no-existent. I'm a but better now, and I think I could improve it
Evil_Bob has joined #maemo-leste
<Wizzup>
if you want I can give it a quick try now
<sicelo>
surr, please feel free :-)
<sicelo>
basez and shell are definitely not good options. i think it's that libcotp indeed
<Wizzup>
I will use libbaseencode-dev until we move to a debian that has the newer libcotp
<Wizzup>
it's the same guy, same code, but only from v2 it has base32 in the main lib
<Wizzup>
also, good job on C-fu :)
pere has quit [Ping timeout: 264 seconds]
<arno11>
sicelo: Wizzup: now with boost (and PA user mode) and if we use 16bpp by default and recent sicelo cmtspeech PR, calls work 100% on n900 with no priority stuff or other tweaks, just need to load cmt_pulse at the right moment
<arno11>
idealy after pin code
<arno11>
or as late as possible during boot
<freemangordon>
arno11: did you manage to find what makes it faster on your device?
<freemangordon>
OC?
<freemangordon>
faster == faster scrolling
pere has joined #maemo-leste
<arno11>
probably oc
<freemangordon>
ok, I'll try later on with the new kernel to see if it is better
<arno11>
and scrolling is @80% good
<arno11>
ok
<freemangordon>
we shall make 16bpp default
<arno11>
definitely
<arno11>
it makes a huge diff
<freemangordon>
hmm, what is the xorg conf key for bpp?
<uvos__>
it is impossible for mce to miss a power button click, no matter how slow the device is
<uvos__>
at worst it will register a erronious long-press
<uvos__>
i think there is a stall in systemui
<uvos__>
the menu with the battery/connui etc also takes way to long to show up sometimes
<freemangordon>
or dbus
<freemangordon>
also, it is not missing it
<freemangordon>
but there is a huge lag\like more than a second
<uvos__>
yeah
<uvos__>
same on d4
<freemangordon>
no
<uvos__>
yes
<freemangordon>
ah, yes
<freemangordon>
xorg?
<uvos__>
like the drop down with connui takes forever
<uvos__>
no i think its specificly connui stalling systemui
<uvos__>
the plugin
<freemangordon>
no, dropdown is just fine
<uvos__>
its not every time
<freemangordon>
here it appears in a split second
<uvos__>
but often enough it stalls for several seconds
<uvos__>
even
<uvos__>
when opening the drop down
<freemangordon>
yeah, but that's not what I am talking about
<uvos__>
ok
<uvos__>
then not sure
<uvos__>
anytow that stall is connui stalling systemui i think
<freemangordon>
pressing power button with device locked (and display off): it takes more than a second for dsplay to be turned on
<freemangordon>
even on d4
<uvos__>
i mean just issuing xset dpms force on takes like 500ms
<freemangordon>
right
<freemangordon>
why is that?
<uvos__>
so this is mostly kernel/xorg
<uvos__>
not sure
<freemangordon>
half a second to enable backlight?
<freemangordon>
weird
<freemangordon>
but well
<uvos__>
i mean it has to clear the display framebuffer
<uvos__>
and setup dsi again
<uvos__>
since it sleeps it
<uvos__>
but still
<uvos__>
im not sure why it takes so long
<uvos__>
to be fair it takes pretty long on android too
<uvos__>
not quite as long
<uvos__>
but long
<freemangordon>
ok, but n900 with fremantle turns display on in couple of ms
<freemangordon>
umm...
<freemangordon>
couple hundreds
<freemangordon>
the same takes 1-2 seconds on leste
<freemangordon>
so this is not HW, for sure
<uvos__>
so is xset just as slow on n900?
<freemangordon>
no idea
<uvos__>
ok
<freemangordon>
just powered the device off :)
<freemangordon>
will test tomorrow
<uvos__>
well on d4 not using vtllock helps alot
<uvos__>
so something in that chain
<uvos__>
is def also pretty slow
<freemangordon>
on n900 ( with fremantle and vtlkock) are those 200-400 ms
<uvos__>
thres several dbus systemui mce round trips in there
<uvos__>
so any one of those
<freemangordon>
maybe dbus roudtrip
<freemangordon>
will do some timing
<freemangordon>
when it comes to it
Juest has quit [Ping timeout: 264 seconds]
<arno11>
freemangordon: when you have time, plz check 2023-10-16 irc log, 18:19, 18:20 :P
<freemangordon>
arno11: yeah, sorry abou tthat
<freemangordon>
however, back then we were thinking max boost frequency is not automatically enabled
<arno11>
indeed
<arno11>
i'll have a look and try to find a trick in cpufreq
arno11 has left #maemo-leste [#maemo-leste]
uvos__ has quit [Remote host closed the connection]
k1r1t0_N900 has quit [Ping timeout: 276 seconds]
arno11 has joined #maemo-leste
<arno11>
ok so for devices not able to run @850MHz the trick is to run powersave governor, enable boost, choose min and max freq in cpufreq and then back to ondemand/conservative mode
<freemangordon>
how are you sure powersave will not switch to 850 in the meanwhile?
<freemangordon>
esp during boot
<arno11>
impossible
<freemangordon>
what is impossible?
<arno11>
device is locked @600 max during boot
<arno11>
and powersave locked @250
<arno11>
boost or not
<arno11>
and remember, boost is available but not enable on boot
<freemangordon>
ok, maybe I don;t know how powersave works
<freemangordon>
does it lock the lowest freq?
<arno11>
yes exactly
<freemangordon>
ok
<arno11>
currently 250
<freemangordon>
yeah
<freemangordon>
min 250 makes lots of difference
<arno11>
indeed
<arno11>
and 500 a bit more :P
<freemangordon>
that affects battery life
<freemangordon>
the correct way is to implement devfreq in sgx driver
<arno11>
ok but i didn't notice any inpact, really
<freemangordon>
because it is already bad (battery life) :)
<arno11>
currently 10-12h in use for me but with polarcell...
pere has quit [Ping timeout: 256 seconds]
Juest has joined #maemo-leste
ac_laptop has joined #maemo-leste
<ac_laptop>
hello people, I've looked a bit further about my battery problem, and, as you suggested, swapping batteries is definitely one of the reasons. I thought at first that swapping betteries of the same capacity would be ok, but no, the problem occurs if I swap two batteries of the exact same model. Which is an issue, because maemo-leste is drawing power so fast (a 1600 mAh battery lasts less than a
<ac_laptop>
day, with maemo leste mostly idle) that I will swap batteries often.
<ac_laptop>
So I guess I will mostly use fremantle on my N900 and boot under leste when it's really necessary. Now I have to find a way to make fremantle somewhat enjoyable to use
ceene has quit [Ping timeout: 260 seconds]
<arno11>
ac_laptop: hi, when u say 'less than a day' you mean less than 24 hours idle with a 1600mA bat ?
dos has quit [Quit: Kabum!]
dos has joined #maemo-leste
Juest has quit [Ping timeout: 264 seconds]
<ac_laptop>
arno11: yeah, somewhere around 8 hours
<arno11>
??? ugh
<arno11>
idle is around 50mA actually
<arno11>
70 with wifi On and Modem
<arno11>
are you sure 1600mA is the real capacity ?
Juest has joined #maemo-leste
maxwelld has quit [Quit: Gateway shutdown]
<Wizzup>
ac_laptop: do you run any particular programs on leste that can drain the battery?
<ac_laptop>
arno11: I'm sure, it's the polarcell battery recommended here
<ac_laptop>
and I have two of them
<ac_laptop>
Wizzup: I usually let it idel with a terminal open and wifi on. the only daemon I can think of is sshd.
<Wizzup>
arno11: building new leste-config
<ac_laptop>
But I'm going to make further tests, I have a question
<Wizzup>
ac_laptop: do you have wifi connected to something all the time, like using mosh?
<arno11>
Wizzup: ok ty
<arno11>
8 hours with a polarcell means 200mA constantly
<arno11>
that's a lot
<ac_laptop>
suppose I have a new n900 device and I have flashed u-boot on it and put leste on its mSD card, only to realise later that the fremantle on it is PR1.2, not 1.3
<ac_laptop>
can I flash 1.3 now ? is there a risk that is messes with the bootloader ?
<Wizzup>
I think in general you can always re-flash fremantle, all you need to do from there is to re-enable cssu and set up u-boot again
<sicelo>
ac_laptop: 'nice' to know there's nothing weird about Fremantle. i've looked at the battery and charging drivers quite a bit, and of course, i'm no expect, but they do seem to be really well-written drivers
<ac_laptop>
sicelo: they must be, my n900 easily lasts idle on fremantle for about a week
<sicelo>
sorry, I meant Leste
<sicelo>
:-P
<sicelo>
but yes, Fremantle uses much less on idle, so that explains why you can't get a week out of Leste on the same charge
<Wizzup>
that's the diff between RET/OFF and no RET at all (n900 currently)
<sicelo>
yes i'll look at it as soon as i get a chance. i'm excited about any improvement for maeotp
<Wizzup>
I think it just works and it's a small change
<Wizzup>
brb work mtg
pere has joined #maemo-leste
<ac_laptop>
I'm going to flash PR1.3 on n900 n°2 then I will be able to change the boot menu, then I'll be able to compare the two devices to make sure there's isn't a hardware issue
<Wizzup>
freemangordon: I also mentioned it earlier
<freemangordon>
ah, yes, didn't see it
<freemangordon>
and yes, I agree its cool
xmn has joined #maemo-leste
<Wizzup>
honestly my first thought was 'we are not ready for this' but then I also realised that it's great to have someone think about (and potentially work on) these things
<freemangordon>
mhm
<freemangordon>
'we' will never be ready :p
<Wizzup>
who knows :)
* dsc_
pretends he is not here
arno11 has joined #maemo-leste
<arno11>
btw 16bpp by default is ok
<arno11>
i mean after update and reboot
<Wizzup>
:)
akossh has quit [Read error: Connection reset by peer]
<arno11>
Wizzup: freemangordon: for the cmtspeech improvement, it's over my skills but iirc alsa_test.c is not involved with cmt_pulse. it is just a latency test
<Wizzup>
okay, it was the main thing that I saw clearly changed
<arno11>
otoh i was pretty sure something was wrong with audio_generate in utils/audio.c but failed to fix it
<arno11>
iiuc it generates the tone when you call someone
<arno11>
and it was buggy before sicelo commits
<ac_laptop>
hum I created the file /etc/bootmenu.d/30-maemo-leste.item, I ran u-boot-update-bootmenu under fremantle and I still have to use the flasher to get a boot menu, what did I miss ?
akossh has joined #maemo-leste
<arno11>
keyboard was opened ?
<ac_laptop>
arno11: yes, but I think I've found the solution
<ac_laptop>
I installed u-boot-flasher and now it works