<Oksanaa>
I am very, very tired of the data fragmentation. Between (several devices, actually) Nokia N900, Fxtec Pro1, Nokia E71, and for-the-sake-of-taking-photographs Nokia 1.3 and Nokia N95... I have no idea how I will actually compile, in the distant future, a continuous history of SMS texts. Or a continuous photo album. Or notes. Or IRC history into a single IRC client.
<Oksanaa>
And I have no idea what device I want to use in the future. Fxtec Pro1? Perhaps, but I do not trust Sailfish OS to not brick it again - is there Maemo Leste image for it? Motorola Droid 4? Perhaps, but I do not have one, yet. Nokia N950? Perhaps, but it would need tricky soldering work to get SIM card slot working. Nokia N900? Perhaps, but it would need a repair of the charging port...
<freemangordon>
norayr: or simply add AM_GNU_GETTEXT_VERSION to configure.ac, IIUC
<Oksanaa>
At this rate, I would even be interested in a Maemo Leste image for Dragonbox Pyra: at least, this device (pre-ordered, not arrived yet) is not in need of repairs or data back-up. Granted, it's standard edition, not mobile edition, so it does not have cellular connectivity... Perhaps, I will (pre-)order another one, with cellular connectivity...
ceene has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
<norayr>
freemangordon: i think AM_GNU_GETTEXT_VERSION is in configure.ac, i checked.
<norayr>
but i'll check again
<norayr>
and yes, i wanted to say, i have very limited knowledge with autotools etc, so it would be great if you comment on my solutions
<norayr>
Oksanaa: i think last images were build in september.
xmn has joined #maemo-leste
alex1216 has joined #maemo-leste
<tmlind>
freemangordon: not sure if increasing the timeouts helps. maybe the issue is that n_gsm is unable to connect if no response initially?
<tmlind>
Wizzup, uvos: so i took a look at the tc358765 dsi bridge i2c transfers issues on mz617.. the chip seems super buggy for i2c
<tmlind>
heh, so for register writes, writes go to address + 1 instead of address :)
<tmlind>
and after a write, a short timeout is needed or else any following read or write will fail
<tmlind>
of course it could be some i2c pull-up issue.. but lm75 on the same i2c bus works just fine. also tried configuring the bus at 400khz
<tmlind>
the kernel tc358764 driver uses mipi_dsi reads and writes, and looks like the android driver for tc358765 only used i2c for dumping out the regs for debugging if i read the right code in the v3.0.8 tree..
<tmlind>
i guess i'll try to get the mipi_dsi reads and writes working too, then we can make sure i2c and mipi_dsi both read and write the same registers with the same values..
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__>
tmlind: thats wierd, might it also just be a special made to order motorola variant of the chip with one extra register that moves all the subisquent addresses +1?
<uvos__>
so if you hack the driver to just add 1 to the address on reads/writes dose it work?
<tmlind>
uvos__: no.. i found this out by reading and writing to the early regs and looking the results with i2cdump
<uvos__>
ok
<tmlind>
uvos__: any idea if the v3.0.8 kernel panel-mapphone-d2l.c is the one in use?
<uvos__>
i need to take apart my mz617 and charge it
<tmlind>
heh
<uvos__>
tmlind: no but should be easy to check
<tmlind>
looks like the tc358764 drivers in mainline kernel is finally fixed for the bridge api with some tested-by from the chromebook folks
<uvos__>
:)
<tmlind>
i guess i'll try to get that to work, then 765 presumably just has dual lane support compared to 764..
<Wizzup>
tmlind: heh @ register write offset. it would be super awesome if it can be mdae to work :)
<tmlind>
something along the lines of this to read a reg: i2ctransfer -f -y 1 w2@0x50 0x05 0x80 r4 to read idreg, forgot which way around the 0x0580 address offset had to be specified
<tmlind>
did not get that to work with android btw for dumping regs, android bus is 1 like above mainline 0
<tmlind>
but would be nice to have a register dump of the android regs naturally somehow
<tmlind>
also with i2ctools, writes work along the examples on that page, but the address needs to be addr - 1, and sleep 0.1 is needed before any other transfers..
<tmlind>
looks like reading the idreg just returns the value at 0x80, which can be written directly..
<tmlind>
while writing to idreg won't work
pere has quit [Ping timeout: 268 seconds]
<tmlind>
i tried i2ctransfer from busybox on android btw, maybe it's buggy
Pali has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
Pali has quit [Ping timeout: 244 seconds]
pere has joined #maemo-leste
<uvos__>
tmlind: might make sense to use androids own i2ctools
<uvos__>
use/try
<uvos__>
source is in the android tree ususally they are not installed on images unless you do a debug bild
<uvos__>
build
<freemangordon>
tmlind: since the increase, I saw no failures in registrering audio interface
<freemangordon>
also, it does not make sense not me _gsm to wait 8 seconds for command being send but audio driver to wait 1 second for response
<freemangordon>
*does not make sense to me n_gsm
adc has left #maemo-leste [#maemo-leste]
<tmlind>
freemangordon: ok great if it helps :)
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
<freemangordon>
do you plan to send tose patches for upstreaming soon?
<freemangordon>
*those
<tmlind>
me? which patches? serdev-gsm?
* tmlind
too many half done patches
<tmlind>
in case you're asking about serdev-gsm, those should be updated to use serdev read/write also for the client drivers
<freemangordon>
or do you mean we shall handle CIEV also in netreg?
<tmlind>
freemangordon: oh maybe we have it already then, i guess that already covers netreg too for kicking the usb qmi modem
<tmlind>
freemangordon: assuming they are on the same dlci
<tmlind>
hmm maybe ciev_notify() should just kick the qmi usb modem, maybe nothing else is really needed
<freemangordon>
mhm
<tmlind>
could be some generic cive handler, not limited to voicecall.c
<freemangordon>
in motmdm?
<tmlind>
yeah
<freemangordon>
motmdm.c
<tmlind>
yup
<tmlind>
then additionally voicecall.c can do what it needs to do with CIEV if anything
alex1216 has quit [Quit: WeeChat 2.3]
<freemangordon>
shall I add such handler?
<freemangordon>
hmm, why mot_qmi_trigger_events uses WMS no matter what has changed?
<freemangordon>
like, how is MSIM or CREG event related to WMS?
<freemangordon>
aren't those supposed to kick DMS, not WMS?
<freemangordon>
or it is just a fake call to wake-up USB?
<tmlind>
well anything that gets the usb qmimodem to check it's status should do, maybe there's a better way
<freemangordon>
ok
<freemangordon>
so, shall I add CIEV handler in motmdm.c?
<tmlind>
all the modem notifications only seem to come to the n_gsm interface, usb won't notice anything and i was unable to reconfigure the usb modem when i tired
<freemangordon>
ah, I see
<tmlind>
yeah it's worth trying, it could simplify things
<tmlind>
it's like the usb modem settings are read-only
rafael2k has quit [Ping timeout: 265 seconds]
<freemangordon>
ok, will do
<tmlind>
cool, look forward hearing what happens :)
rafael2k has joined #maemo-leste
<freemangordon>
and what we expect to happen differently?
<freemangordon>
like, what it the bug we try to fix? :)
<freemangordon>
*is the
<tmlind>
usb modem might start doing things on the notifications like it should
<freemangordon>
what things, in particular?
<tmlind>
like network status change, sim insert, data connected..
<freemangordon>
iiuc it already does
<tmlind>
well maybe yeah
<freemangordon>
but ok, one more cb should not hurt
<tmlind>
but does ciev_notify() always call mot_qmi_trigger_events()?
<freemangordon>
no
<tmlind>
ok then it's worth trying and see what happens :)
<tmlind>
also WAKEUP should do that if we don't have a handler for it
<freemangordon>
I guess I shall enable n_gsm debug to see all the unsol messages that come
<tmlind>
yeah or do sudo dmesg -w
<tmlind>
after loading with modprobe n_gsm debug=0xff
<freemangordon>
mhm
<tmlind>
right that's what you meant too, i misread enabling ofono debug..
<freemangordon>
ok, going to do it
<Wizzup>
17:39 < freemangordon> like, what it the bug we try to fix? :)
<Wizzup>
context activation often not workingf
<freemangordon>
umm... is that still there after latest fixes?
<Wizzup>
yes
<Wizzup>
on my d4 I often still have to send a sms to get it to activate
<Wizzup>
at least twice today
<Wizzup>
maybe it's something else that's odd
<Wizzup>
or rather: I have to send a sms for ofono to realise it's activated
<freemangordon>
hmm...
<freemangordon>
ok
<freemangordon>
do you have n_gsm traces?
<tmlind>
from android you mean?
<freemangordon>
no, from leste
<freemangordon>
when ctx activation fails
<tmlind>
no don't have any
<Wizzup>
no, but I can enable it again
<freemangordon>
I think it will be helpful to see if there is anything coming from the modem at all
<Wizzup>
there is, CIEV
<Wizzup>
brb
<freemangordon>
ok
<tmlind>
ok. hmm so what is the context activation event?
<Wizzup>
there are two that I saw
<freemangordon>
ugh, my d4 just hanged :(
<Wizzup>
one regarding radio tech and ciev
<tmlind>
but is it for the same operator?
<tmlind>
i mostly suffer from lost network connectivity not being notified and i have to manually reconnect to get pm working again..
<tmlind>
well there is some CIEV event for that
<tmlind>
again
<tmlind>
bbl
vagag has joined #maemo-leste
<Wizzup>
are you asking if I see the problems only on specific operators?
<tmlind>
just wondering what all is considered a context activation event
<Wizzup>
by modem (in at), or by ofono, or conceptually?
avoidr has quit [Quit: leaving]
rafael2k has quit [Ping timeout: 265 seconds]
<freemangordon>
tmlind: I will intercept ~+WAKEUP as well
<freemangordon>
Wizzup: tmlind: I suspect RSSI reported values are not in %
<Wizzup>
Ah
<Wizzup>
possible
<freemangordon>
onm android it reports 15-18 and UI displays full strangth
Pali has joined #maemo-leste
<freemangordon>
*strength
<Wizzup>
right
jeder[m] is now known as jedertheythem[m]
<freemangordon>
Network 'umts': '-78 dBm'
<freemangordon>
this is for RSSI 16
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
akossh has joined #maemo-leste
vagag has left #maemo-leste [Error from remote client]