sunshavi has quit [Remote host closed the connection]
sunshavi has joined #maemo-leste
inky_ has quit [Ping timeout: 252 seconds]
inky_ has joined #maemo-leste
joerg has quit [Ping timeout: 265 seconds]
joerg has joined #maemo-leste
<rafael2k>
_uvos_: where is it. sure!
<rafael2k>
did not know about sphone
rafael2k has quit [Ping timeout: 265 seconds]
rafael2k has joined #maemo-leste
Buttercat has joined #maemo-leste
<tmlind>
uvos: any idea what sets the d4 pwr + vol down reset time to 8 secs? looks like xyboard have it set to 12 secs, would be nice to set it to 1 sec for development :)
<tmlind>
maybe the cpcap firmware?
<tmlind>
did not see anything obvious diffing cpcap regs
<Wizzup>
rafael2k: not yet, will do today
uvos has joined #maemo-leste
n900 has quit [Ping timeout: 252 seconds]
<uvos>
tmlind: no idea, yeah might be part of the fw rom
<uvos>
rafael2k: it works mostly fine now and is quite usable allready. things to do would be:
<uvos>
port to gtk3
<uvos>
replace the awful sms ui with something that tracks conversations
<uvos>
make the ofono handling a pluging you can replace with other backends
<uvos>
any general ui improvements you can think of
<uvos>
my goal of sphone is for it to be a dialer that works on any dekstop linuxy distrobution but also has optional support for some maemo specific stuff
lyubov has quit [Ping timeout: 252 seconds]
lyubov has joined #maemo-leste
<tmlind>
cool
<tmlind>
uvos: i'll check if pressing vol down also changes some cpcap reg, maybe it's wired to cpcap gpio and handled by the fw
pere has quit [Ping timeout: 250 seconds]
Buttercat has quit [Quit: Leaving.]
<tmlind>
vol down does not seem to trigger anything in the cpcap regs
<uvos>
dosent mean anything
<uvos>
since neither dose headphone switch
<tmlind>
yeah
<uvos>
and the fw clearly handles that too
<tmlind>
yup
<tmlind>
can't find the cpcap fw on xyboard
<tmlind>
at least mz609 is super flakey after booting, memtester fails within seconds
<tmlind>
mz617 does not have the lvds bridge on i2c so best to do mz609 first btw
<tmlind>
also mz609 has the same backlight as xt894 so less moving things
<tmlind>
i have some debug statments for the bridge and omaprdm probe and it's a -EPROBE_DEFER loop where both fail :)
<uvos>
ok ram is fine in android right?
<tmlind>
looking for each other
<uvos>
dont have a mz609 but sounds like its the better target for now
<tmlind>
yeah android seems ok, i have not seen any crashes booted to android on my mz609
<uvos>
tmlind: haha ok :P
<tmlind>
this is without the emif node btw, so emif should be using android timings
<uvos>
yeah ok
<tmlind>
also diffed the cpcap regs, not much regulator changes there except for the always on regulator differences
<tmlind>
also mz609 can be reflashed so also a better target that way :)
<uvos>
ok wierd then :\
<uvos>
yeah the guy who wrote me an email claiming to have the file for mz617 just never responded again
<uvos>
:(
<tmlind>
oh bummer :( i'll try to sort out the memory issue naturally first
<tmlind>
my guess is upstream is busy trying to fix the drm bridge init loops looking at lore.kernel.org/dri-devel archive and searching for bridge
<tmlind>
so on mz617, the lvds bridge is controller via mpi dsi, i think the mainline driver has currently no support for that
<tmlind>
on mz609, the same lvds bridge can also be controlled over i2c that might work with the patched mainline bridge driver
<uvos>
ok
<uvos>
side note do we need to mess with the chip at all? its state should be set by the android kernel when we take over or? basic display output should just light up if the dsi is setup the same or?
<uvos>
or is the chip reset somehow
<tmlind>
yeah maybe, don't know yet
<tmlind>
oh mz609 also has the mdm9600 on the ohci bus like xt894 has mdm6600, so gps might be easier to do too
<tmlind>
mz617 has it on ehci that might need a phy driver
<uvos>
to bad only mz6xx has mdm9600 at all..
<uvos>
but yeah mz609 sounds like the better target
<tmlind>
yeah so it seems
<tmlind>
uvos: i think the bootloader needs to crank up the cpu speed to 1.2 to use the right android emif timings
<tmlind>
looks like i wrongly tried lowering the cpu speed in the bootloader.. i'll drop that hack
BenLand100 has quit [Quit: s/BenLand100//]
<uvos>
ok
<uvos>
note that on bionic the opp that the mainline kernel starts with after kexec seams random.
<tmlind>
ok
<tmlind>
note to self and others: we do this in the bootloader echo 1200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
<tmlind>
and the reason why it's needed is to put emif timings needed in place for 1.2gz
<tmlind>
uvos: a hack to test would be to start some cpu load while doing kexecboot :)
<uvos>
yeah
<uvos>
so mz609 android scales the ram bus clock with opp?
<uvos>
or whats happening here
<tmlind>
so it seems, at least the dumped emif reg values are different right now between linux and android for me, but looks like i patched in a lower cpu speed
<tmlind>
i'll check the emif values shortly again after removing my hack
<uvos>
did you check if this happens on xt8xx?
<uvos>
we might just be having luck
<uvos>
with those being stable
<tmlind>
yeah and it probably also explains why adding the default emif values make things flakey, they might be missing the 1.2 opp
<tmlind>
we should dump out all the android emif values for the various operating points and add them to the dts files..
<uvos>
sounds like
<uvos>
it
<uvos>
ill do xt875
<tmlind>
i'm using this to dump the emif values out:
<tmlind>
rwmem 0x4c000000+0xef
<tmlind>
rwmem 0x4d000000+0xef
<uvos>
ok
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
BenLand100 has joined #maemo-leste
<uvos>
i assume omap4-panda-common.dtsi and elpida_ecb240abacn.dtsi
<uvos>
are good examples wrt the dts bindings
<tmlind>
yeah and seems like also the moto kernel are using the same timings as those
<uvos>
on xt894 its also the same elpida chip afaik
<tmlind>
i think so at least.. but i think the mainline kernel might be missing the 1.2ghz values
<uvos>
at least looks like it on ifixit
<tmlind>
ok
BenLand100 has quit [Quit: s/BenLand100//]
Pali has joined #maemo-leste
BenLand100 has joined #maemo-leste
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
BenLand100 has quit [Quit: s/BenLand100//]
<Wizzup>
rafael2k: uvos: telepathy would also be on my mind
<tmlind>
uvos: i think we also want to set the scaling_governor to userspace in bootloader. will look into later on, later
<uvos>
Wizzup: "make the ofono handling a pluging you can replace with other backends"
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
BenLand100 has joined #maemo-leste
uvos has quit [Ping timeout: 265 seconds]
<Wizzup>
uvos: right
_inky has quit [Ping timeout: 252 seconds]
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 265 seconds]
Buttercat has joined #maemo-leste
<Wizzup>
freemangordon: do you think it would help if you dropped juha an email some time?
<Wizzup>
I will try to mail him one last time this week, but after that I'll probably not bother anymore
Buttercat has quit [Remote host closed the connection]
<freemangordon>
I don;t know him so I am not sure it would be of any help
<freemangordon>
but I may reply to your new mail once you send it
<freemangordon>
maybve we can try to ping him on #nemomobile or something
_inky has joined #maemo-leste
<Wizzup>
I didn't see him there
<Wizzup>
well I can continue without his help still I think
mrtux has quit [Quit: Ping timeout (120 seconds)]
mrtux has joined #maemo-leste
<rafael2k>
uvos: yay! tks!
<rafael2k>
Wizzup: ok!
<rafael2k>
uvos: Are you if'defing maemo specific code?
_inky has quit [Ping timeout: 260 seconds]
inky has quit [Ping timeout: 252 seconds]
_uvos_ has joined #maemo-leste
<_uvos_>
yes currently all maemo specific stuff is ifdefed
<_uvos_>
in the future i would like to modularize some stuff
<_uvos_>
so that maemo specific support van be optionaly loaded at runtime
<_uvos_>
like mce now works
<_uvos_>
i currently use sphon on leste and on plain debian on d4
<_uvos_>
an for development i just build it on my x86 machine on arch
_uvos_ has quit [Ping timeout: 252 seconds]
_uvos_ has joined #maemo-leste
<Wizzup>
_uvos_: did you ask the z617 again btw? (re: not responding)
drrty has joined #maemo-leste
<_uvos_>
Wizzup yeah i sent him 3 emails spaced over a couple of weaks
<_uvos_>
weeks even
<Wizzup>
mhm
sunshavi has quit [Read error: Connection reset by peer]
<_uvos_>
so yeah i think we have to resign on finding that file
<_uvos_>
since no one else who turned out to have a copy who was repsonsive
<Wizzup>
that'd suck
sunshavi has joined #maemo-leste
<_uvos_>
yeah
<_uvos_>
well at least we can still install kexecboot anyhow
<Wizzup>
right
<tmlind>
bummer
<tmlind>
i think my mz609 might really have bad memory, memtester on it fails also with my rootfs with the android kernel..
<Wizzup>
both uvos and I have one or more, so we could potentially run some tests if you want
<_uvos_>
no i dont
<_uvos_>
mine has briken flash
<_uvos_>
*broken
<Wizzup>
ok, I should check how many I have here then... :)
<tmlind>
i may have another one somewhere in my boxes, need to check
_uvos_ has quit [Ping timeout: 252 seconds]
_uvos_ has joined #maemo-leste
<sicelo>
would anyone have suggestions on how to debug (and possibly fix/improve) USSD 'dialogue' issues on the Droid 4, running stock Android 4.x?
<sicelo>
by dialogue, i mean - the opposite of a 'one-shot USSD query'. The Droid 4 is able to handle one shot queries, but once it becomes an ongoing request-response cycle, things break
<_uvos_>
stock android is not foss
<_uvos_>
try it with los
<_uvos_>
first
<_uvos_>
also try it using the qmi interface on mainline to elliminate the modem firmware simply being broken
<sicelo>
possibly some entered characters get lost - since in one of the dialogues, i have to enter a 5-digit password, but the prompt returned is to the effect that I have not entered 5 characters
<_uvos_>
ok
<sicelo>
i think it's the modem actually. iirc i've used qmicli with it in the past, but can retest. currently USSD (even one-shot) does not work with mainline, unless situation changed recently
_uvos_ has quit [Ping timeout: 252 seconds]
pere has joined #maemo-leste
<rafael2k>
uvos: cool! what is sphon?
<rafael2k>
uvos: ifdef is fine
<rafael2k>
; )
uvos has joined #maemo-leste
<Wizzup>
rafael2k: I imagine he meant sphone?
<uvos>
he did
<uvos>
sicelo: well if it is the modem we are out of luck since we cant change it
rafael2k has quit [Ping timeout: 265 seconds]
pere has quit [Read error: Connection reset by peer]
pere has joined #maemo-leste
<freemangordon>
kona: hmm, seems gio is stupid (in regards to tinyvfs) :(.
<freemangordon>
there is GFileInputStream GFileOutputStream and GFileIOStream
<freemangordon>
but, they are not interchangeable
<kona>
Yeah, you want me to try to test it with some changes?
<freemangordon>
the point is that modest tries to open stream read-only
<freemangordon>
but you can;t have read-only GFileIOStream
<freemangordon>
unless I am missing something
<kona>
It's going to have to be GFileIOStream, I think, the way the original tinyvfs was designed.
<kona>
Oh
<kona>
Grr
<freemangordon>
but this is always opened read-write
<freemangordon>
yeah
<kona>
If you have better things to do, I'll gladly figure this out, just don't want to duplicate effort
<freemangordon>
so, unless you have a better idea, I am going to implement run-time check for the type of stream that is passed to tny_vfs_stream_new
<freemangordon>
don;t worry, it will be trivial change, it is just that I was badly surprised by gio
<freemangordon>
also, I am about to finish modest port to gio
<freemangordon>
so I think it will be faster if I do it now my hands are anyways dirty with tinymail/modest code
<kona>
Ok, that sounds good. I was thinking switching to libsylph+litehtml someday maybe instead of tinymail, but I'm not yet convinced
<freemangordon>
if you have a better idea but a runtime check for the type of stream, please share
<kona>
It feels like there ought to a base class of stream that can be opened ro rw etc and cast to the others, but it looks like there is not, so a runtime check is the way we must go?
<kona>
I also wonder whether all of these can be cast to seekable...
<kona>
Tinymail-gnomevfs seemed to assume that, so tinymail-gio does, too
<freemangordon>
yes, all of these implement seekable, but they are not interchangeable
<freemangordon>
like, you cannot call g_output_stream_write on anything else but GFileOutputStream
<Wizzup>
are they not castable?
<freemangordon>
hmm, wait
<freemangordon>
Wizzup: no, they are not
<freemangordon>
all are GObject successors
<freemangordon>
however, you can call g_io_stream_get_input_stream and g_io_stream_get_output_stream
<kona>
I think the ossopdf PR cast some of them, and i think I incorrectly thought that meant I could cast all of them.
<kona>
Oh.
<Wizzup>
kona: if you find bugs in the pdf port, let me know ;)
<kona>
I can't prove any of it :)
<uvos>
well the pdf reader crashes all the time
<freemangordon>
kona: please, at least open in issue, something in the lines "hmm, this doesn;t look good" :)
<uvos>
its liekly not a good referance
<uvos>
we have an issue on it
<freemangordon>
if there are casts from iostream to inpitstream or outputstream, no wonder
<uvos>
for instance opening a file and then opening another causes segault 100% of the time
<freemangordon>
Wizzup: kona: seems GIOStream 'wraps' GInputStream and GOuptuStream, but, its 'stream' properties are read-only, so IIUC one cannot create 'empty' GIOstream and then assign input or output stream
<freemangordon>
what a stupid design
<freemangordon>
anyway, bbl
<kona>
freemangordon: in pdf port, will go have a look and then open an issue.
<kona>
osso-pdf-viewer PR looks fine, it casts GFileInputStream to seekable, and never tries to change to an output stream. But I erroneously assumed I could cast GFileIOStream to/from the other IOStream classes, and that was my bad.