<tmlind>
Wizzup: yeah ok let's hope his email still works
<Wizzup>
mhm
<Wizzup>
I'm going to see if I can quickly identify why 5.10.y doesn't idle at 0.007A but rather at 0.012A
<Wizzup>
it seems to be related to the panel being probed
<Wizzup>
as in, on v5.9 having panel probed doesn't cause the extra power hit
<Wizzup>
but there were only two small panel changes, so I suspect something else perhaps
<dsc_>
uvos: when you have time kindly test latest `conversations`, it may have fixed the SMS thingy
<dsc_>
devel is updated
<uvos>
dsc_: works
<dsc_>
thanks!
<uvos>
but it dosent pick up the contact names
<dsc_>
im reading `remote_uid` from table `Events`
<Wizzup>
tmlind: as in, it's not normal for the panel to use more power just when it's probed, right? or do I need to do additional work to idle it properly beyond setting backlight to 0
<uvos>
right but sphone saves the number there
<uvos>
sphone saves the contact name in local_name so that it dosent have to look up the contacts so often in eds (its slow)
<uvos>
but i dont know if thats correct
<Wizzup>
there is a table in rtcom with remote info
<Wizzup>
so that it doesn't need to go in the event
<uvos>
the ones with names are just special numbers
<uvos>
or chat contacts that are unsernames
<uvos>
not contact names
<uvos>
sphone saves the remote user name or number in remote_uid
<uvos>
(ie what the backend needs to send a message to this person)
<dsc_>
kk
<uvos>
and the name the user has saved in contacts for this person as local_name
<uvos>
but saving it in some other table might be better yeah
<uvos>
looks like your freemantle database dosent sue it at all
<dsc_>
dont think there is another table for that
<dsc_>
local_name is fine
<dsc_>
ill fix it
<uvos>
no idea why they need selfhandle since the outgoing incoming prop also exists
inky has quit [Ping timeout: 260 seconds]
<dsc_>
right
inky has joined #maemo-leste
<Wizzup>
afaik the table 'remotes' to be checked here
<Wizzup>
that is what the remote_uid is for?
<uvos>
[11:39] <uvos> sphone saves the remote user name or number in remote_uid
<uvos>
[11:39] <uvos> (ie what the backend needs to send a message to this person)
<uvos>
thats also what it looks to be for
<dsc_>
oh.
<uvos>
the better question what the heck local_name is for if remotes table exists
<Wizzup>
likely librtcom-el has functions to match remote uids
<Wizzup>
local_name is *yourself*
<Wizzup>
local_uid TEXT, -- plugin local uid ('account' on a plugin/protocol)
<Wizzup>
local_name TEXT, -- seems to own irc nickname, etc <SelfHandle> for telepathy-ring
<Wizzup>
why it is necessary is a good question
_inky has quit [Read error: Connection reset by peer]
<Wizzup>
tmlind: ok it's probably some drm interaction, I'll have to check that later, not sure how to continue atm - v5.10 is broken without stable patches (and also those need at least one commit reverted to work, so bisect might be quite hard)
<dsc_>
the big question is, does the rtcomlib do a JOIN in order to resolve remote_uid's or not
<Wizzup>
use the source luke :-p
<Wizzup>
brb
<dsc_>
ok
<dsc_>
uvos: use the `Remote` table and set `remote_uid` accordingly :P
<tmlind>
Wizzup: yeah that's time consuming with extra patches carried for bisect
inky has quit [Ping timeout: 240 seconds]
belcher has quit [Ping timeout: 260 seconds]
<uvos>
dsc_: wait no
<uvos>
dsc_: its not right
<uvos>
dsc_: now it dosent show commtest threads
<uvos>
those are saved as RTCOM_EL_SERVICE_CHAT RTCOM_EL_EVENTTYPE_CHAT_MESSAGE
<dsc_>
thats right, I'm only filtering for SMS currently
<uvos>
ok
<dsc_>
I need to make a navigation bar where you can specify/filter on message types
<uvos>
ok
<uvos>
generally id also like a way to see what backend a thread is on, but im sure you have it planned
<dsc_>
right
<dsc_>
ill most likely change the chat window title for that `Conversations (SMS)`
<dsc_>
`Conversations (IRC)`
<dsc_>
suggestions welcome though :P
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
_inky has joined #maemo-leste
belcher has joined #maemo-leste
Danct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
Danct12 has quit [Client Quit]
Danct12 has joined #maemo-leste
Danct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
pere has quit [Ping timeout: 250 seconds]
Danct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
Danct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
inky has joined #maemo-leste
<Wizzup>
dsc_: re: backends, we'll get to that
<Wizzup>
I have some ideas about that too :)
<Wizzup>
tmlind: maybe I can rebase v5.10 and remove the other regressions (or insert the fixes right next to the offending commits) and bisect that rebased branch
pere has joined #maemo-leste
<Wizzup>
uvos: btw when/if you have an idea about glamor and gles let me know and I'll try to build xorg-server on the pp
<Wizzup>
if we can alleviate some of the pains it's likely quite worth it
<Wizzup>
freemangordon: also if you recall what patches were needed for newer X / how you built it, please lmk
<Wizzup>
uvos: btw got a droid razr and droid razr maxx in post (shipped with this droid3)
<Wizzup>
not sure if they still work
<freemangordon>
Wizzup: for sure I disabled XWayland
<Wizzup>
but that would just be a configure, so you build it on your own device I guess, not with dpkg-buildpackage ?
<tmlind>
Wizzup: you can carry extra commits with git bisect, forgot the option for that
<Wizzup>
tmlind: ok
<tmlind>
Wizzup: see git bisect --help for hot-fix
<tmlind>
there's a sample script for bisecting with a hot-fix, i'm pretty sure there was some git specific command earlier for that, but i guess it's gone
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 250 seconds]
<Wizzup>
ok
<Wizzup>
someone on the internet suggests this: git cherry-pick --no-commit hot-fix
<uvos>
Wizzup: what version of xt91x exactly?
<freemangordon>
Wizzup: I used debian packaging of 'our' xserver
<Wizzup>
freemangordon: ok, any new xproto required?
<freemangordon>
also, some newer xorg-protocols or somesich
<freemangordon>
uvos: I agree about glFinish() patch, but others are different
<Wizzup>
freemangordon: maybe you can comment on the above issue tomorrow
yanu has quit [Quit: Lost terminal]
inky_ has joined #maemo-leste
<Wizzup>
tmlind: hm, my testing with the two commits I mentioned earlier reverted shows fee5be18524f961de653fe6103f927c84ebbfd38 as the first bad commit, but I am not sure how to interpret that since it's a merge
<Wizzup>
since it seems to relate to s390 fixes mostly?
<Wizzup>
I suppose that could happen if the behaviour was racy or something
<uvos>
hmm
<uvos>
thats a wierd commit
<uvos>
even if racy that dosent make any sense
<Wizzup>
right
<uvos>
whats this for?
<uvos>
the modem?
<Wizzup>
no, this is the extra power usage from v5.9 to v510
<Wizzup>
when panel driver is loaded
<Wizzup>
is could just relate to the async probing somehow perhaps, but I have that reverted
<Wizzup>
from my earlier testing v5.9 idles fine at 0.007A whereas v5.10 idles at 0.012A or so
<Wizzup>
(both are in off)
<Wizzup>
rmmod on the panel module makes the problem go away on v5.10
<Wizzup>
I guess the problem is I probably made a good/bad mistake somewhere or something, and it's just inherently racy perhaps
<Wizzup>
it's definitely real though
<uvos>
yeah
<uvos>
one thing tho
<uvos>
the pannel
<uvos>
its stopped working at some point
<uvos>
there was a initalization race
<uvos>
i think this was around this time
<Wizzup>
yes, sre fixed that I think in this serise
<Wizzup>
that's only one of the two commits that touch the panel
<Wizzup>
but surely even if the panel now worked, it shouldn't use 0.005A more just because it's enabled (not on or anythign)
<Wizzup>
also at least in v5.9 I can turn off the panel without problems by loading the module, but yeah, maybe it's a panel pm thing or something...
<uvos>
the solution to the race was to reset the pannel again right?
<Wizzup>
that's what the commit said yeah
<uvos>
well the race might not be fully solved and the pannel ends up in a different hw state
<uvos>
ok but reseting the pannel should be quite sage
<uvos>
*safe
<Wizzup>
see 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a
<Wizzup>
well that was a waste of then, I'm no closer to a solution :)
sunshavi has quit [Remote host closed the connection]
<Wizzup>
uvos: selectively reverting 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a does seem to suggest it idles better without...
<uvos>
and keeping 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a and cyceling the pannel on and off
<uvos>
?
<Wizzup>
how would I do that?
<uvos>
dpms?
<Wizzup>
uh I don't have basically any /dev nodes
<Wizzup>
let alone X or anythign else
<uvos>
we are gonna need dev nodes :P
<uvos>
you can use my program .. but it dident work
<uvos>
acutally
<uvos>
this might be related
<Wizzup>
I think I might give up on this one in a bit for now
<uvos>
since dpms fails in my dpms off program
<uvos>
that suggests something is wrong with it
<uvos>
the pannel driver that is
<uvos>
ok yeah giving up is also an option
<uvos>
its "just" 15mW
<Wizzup>
I meant for now mostly
<Wizzup>
I don't know how to debug this properly, I'll try a few more things: going to 5.15 and remove panel driver and see how that acts
<Wizzup>
and also go back to v5.9 once more and just confirm that indeed it's more stable / better pm
<Wizzup>
maybe sre can give it a look if it's clear the panel module probing has an effect
sunshavi has joined #maemo-leste
<Wizzup>
it's also possible that the panel drivers waits for drm and some other interaction for it to fully idle or something
<uvos>
i dont see why it should
<uvos>
except as a bug
<uvos>
but sure
<Wizzup>
yeah, what I mean is that I am testing in one specific way
<uvos>
could be hw bug that causes it to not idle untill the first frame even
<uvos>
or something like that
<Wizzup>
mhm
<Wizzup>
whatever it is, it's not present in v5.9
<Wizzup>
but if that's because it never actually resets, yeah...
<Wizzup>
as in my test doesn't involve *using* the panel
<Wizzup>
I only probe the module to lower power usage for my tests (turn off screen, basically)
sicelo_ has quit [Remote host closed the connection]
<Wizzup>
I think it might be best to send a mail about this so I don't forget but not investigate further - on 5.15 with my reverts/additions at least off mode it hit sometimes with the panel not probed, but there seems to be another power regression mostly preventing off mode since v5.10 and 5.15
BlagovestPetrov[ has joined #maemo-leste
eniac_petrov has joined #maemo-leste
blago_ has joined #maemo-leste
eniac_petrov has quit [Client Quit]
blago_ has quit [Client Quit]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
<Wizzup>
hey with both panel commits from v5.10 reverted it does go back to lower power
<Wizzup>
ok...
<Wizzup>
so it was 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a
<Wizzup>
if I can figure out what makes plain v5.11 not boot (it says it cannot execute init=/bin/bash) then I can could hopefully trace the last off mode problem
<sicelo>
5.11 used to boot for me, and 5.12
<Wizzup>
plain v5.11?
<Wizzup>
as in 'git checkout v5.11' ?
<Wizzup>
5.11.y, v5.11 with stable patches boots form e
<Wizzup>
but that is useless for bisect since the first thing the bisect will do ignore all the stable patches
<Wizzup>
so I need to find the specific commits in 5.11.y and apply them at every bisect step if the offending commit is present during the bisect
<Wizzup>
which is *hands in hair*
<sicelo>
I see. Well it's been a while, so I am no longer too sure which particular 5.11/.12 I was booting
<Wizzup>
it's ok, I think I might have found it
<Wizzup>
I figured I might as well continue while I still the energy and will to work on this stuff
<Wizzup>
ah.
<uvos>
7c4bada12d320d8648ba3ede6f9b6f9e10f1126a is unlikely to be the real issue here
<uvos>
its just that without it the pannel is in some other state
<uvos>
that it happens to idle in
<uvos>
and after 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a its in power on reset
<Wizzup>
uvos: could be, but I hope that sre can take a look
<Wizzup>
btw v5.11 needs the mmc swap commit (1baa29c660b8b75c1cd06e743d9faca7ee323b1f)
inky_ has quit [Ping timeout: 268 seconds]
<sicelo>
Yeah @mmc swap
sunshavi has quit [Remote host closed the connection]
_inky has quit [Ping timeout: 250 seconds]
akossh has quit [Read error: Connection reset by peer]
<Wizzup>
uvos: it might make sense to check if OMAP4_THERMAL makes on the d4 too
<Wizzup>
makes a difference*
cockroach has joined #maemo-leste
<Wizzup>
ok
<Wizzup>
I think that's all I can do wrt idle right now - there's a reproducible test case wrt mmc that causes panics when the system idles, and on 5.15.y we can now hit off mode with init=/bin/bash and idle at 27mW
<Wizzup>
when I boot to maemo leste rescue mode I can actually hit RET sometimes, but not yet OFF