<freemangordon>
uvos: maybe you shall consider doing some rtcom/abook integration in sphone. using sphone/ofono/sphone as local account name and telefone number for remote (which is uri, so it should be something like tel://12345678) does not help much :) much :)
<freemangordon>
maybe look at your fremantle el_db to guess what data you shall log
<freemangordon>
but, in general, just set the correct local_id
<freemangordon>
when getting the contact from adressbook
<freemangordon>
uvos: you should use e_contact_get_const(contact, E_CONTACT_UID) for RTCOM_LOG_VIEW_COL_ECONTACT_UID, tp_account_get_path_suffix(account) for RTCOM_LOG_VIEW_COL_LOCAL_ACCOUNT and tel://12345678 or sms://12345678 for RTCOM_LOG_VIEW_COL_REMOTE_ACCOUNT, IIUC
<freemangordon>
those defines are just hint what to put where
rafael2k has joined #maemo-leste
rafael2k has quit [Remote host closed the connection]
rafael2k has joined #maemo-leste
Pali has joined #maemo-leste
rafael2k has quit [Ping timeout: 264 seconds]
<sicelo>
mmm, Wizzup, tmlind - 7058e68c2fedf54a5b49ca6f6a4b63edfaea8464 on linux kernel - isn't this what we use on N900?
<freemangordon>
I think we use something else for debug leds
<freemangordon>
but lets tmlind confirm
* sicelo
is still tracking N900 musb/isp1704 issues on 5.19+ ... and may end up giving up :(
Pali has quit [Ping timeout: 246 seconds]
<freemangordon>
sicelo: hmm, does pvr work on 5.19?
<freemangordon>
or you are booting to shell only?
<freemangordon>
also, why don;t you send mail to the omap ML with the issue?
<sicelo>
i just using plain X. and yes, i have thought that it's time to send a mail to some ML, not sure which one though
<freemangordon>
linux-omap at vger.kernel.org maybe
<sicelo>
i thought it was something i could bisect and find, but seems i've chewed more than i can bite here
<freemangordon>
what is the issue with bisecting?
<freemangordon>
it gives false results?
<sicelo>
yes, took me to amdgpu commits :p
<freemangordon>
:)
<freemangordon>
well, I guess you fed it with wrong data then
<sicelo>
but i'm trying it in a different way now, git bisect start 'v5.19' 'v5.18' '--' 'drivers/usb'
<freemangordon>
is that vanilla tree?
<sicelo>
checked out from master, yes. no changes besides the defconfig
<freemangordon>
ok
<freemangordon>
should be easy then
<freemangordon>
so, it boots 5.18 omap2plus_defconfig with no issues?
<sicelo>
now i'm on commit 9fe15316563c ("ARM: omap1: innovator: move ohci phy power handling to board file", 2019-08-06) ... and have a different problem ... blank display. so i don't know if it's good, or bad commit :-D
<sicelo>
freemangordon: yes, i'd say so @ 5.18 + omap2plus
<freemangordon>
write that down somewhere and try try with good first
<freemangordon>
if you get bogus results, reset the bisect to that and next tmie choose bad
<freemangordon>
or, reset bisect and use last working as good and first bad as bad
<sicelo>
thanks. that's a nice hint
<freemangordon>
tmlind may know better approach, but I don;t :)
<freemangordon>
sorry, last bad, not first bad
<freemangordon>
eventually you will hit blank display issue, but there will be less steps to go through
* sicelo
is reminded to build a serial contraption ... i have the needed diodes and level convertor
<sicelo>
this blank display wouldn't be an issue if i had done this already. *me kicks hisself*
uvos__ has joined #maemo-leste
<uvos__>
freemangordon: im not responsable for how sphone uses the fields in rtcomm
<uvos__>
thats Wizzups department
<Wizzup>
if you want to do the bisects another way, then you can optionally apply commits that fix the other (boot) problems every time you do a next bisect
<Wizzup>
that's what I did for the n900 pm bisects
<sicelo>
understood. actually it's more than just display being blank. the device turns completely off a short while later. but yeah, i should probably find list of those commits to cherry-pick
<Wizzup>
maybe bisect that problem first, or the fix for it
<Wizzup>
and right, that's what I did
<Wizzup>
I had some script to see if problematic commits were part of the current commit history, and if they were, I'd apply them
rafael2k has joined #maemo-leste
<Wizzup>
rafael2k: let me know when I should sync
rafael2k_ has joined #maemo-leste
rafael2k has quit [Ping timeout: 252 seconds]
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
<freemangordon>
uvos__: ah, ok, didn't know
<freemangordon>
Wizzup: see my notes ^^^
<freemangordon>
in regards to rtcom logging
rafael2k_ is now known as rafael2k
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
<Wizzup>
didn't know rtcom was my department but ok :)
<Wizzup>
all I did was fix the field swap
<uvos__>
well.. you did the investigation what goes where
<uvos__>
so idk if freemangordon is right wrt what needs to go there
<Wizzup>
yup, and I've also mentioned some problems resolving stuff from abook or names not showing