<rafael2k>
hey, sorry, ended up sleeping yesterday
<rafael2k>
uvos: tks (for sphone info - I will try it out)
<rafael2k>
Wizzup: my pp keyboard should arrive in the next days
<rafael2k>
Wizzup: sound is still clogged with pa here, pa is shit, I'll check mobian setup
pere has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
pere has quit [Ping timeout: 250 seconds]
<humpelstilzchen[>
oh can we go without pa? :)
pere has joined #maemo-leste
<rafael2k>
humpelstilzchen[: I'd like too, but some software rely on it, like sphone and other I think
<humpelstilzchen[>
rafael2k: I wonder if apulse emulation helps
<rafael2k>
lets try to fix pa first... seems to be some detail
<humpelstilzchen[>
oh, dead project. What a pitty
<sicelo>
keep pa. you probably just need a simple config or sth.
<Wizzup>
freemangordon: I don't think we want to fork every daemon we don't want to restart, but yes, that is a potential solution for ofono and such
<Wizzup>
humpelstilzchen[: rafael2k: maemo needs pa
<freemangordon>
sure I didn;t mean to fork, but we shall fix our daemons we don't want to be restarted
<freemangordon>
my point was more than dsme is already ok in that regard
<freemangordon>
BTW, what happens if ofono cashes?
<freemangordon>
*crashes
<Wizzup>
not sure, either it stays down or it gets started again via dbus activation
<freemangordon>
tmlind: hmm, I think omap ddx commit 478fcc45e0b9d93dbe1a2c1f842441af529a3c04 is the reason why we see dma_buf leaks
<freemangordon>
"[PATCH] omap: Fix missing usage count decrease in OMAPDRI2DestroyBuffer"
<freemangordon>
it decreases usage count, but doesn;t check if it become zero afterwards
<freemangordon>
Wizzup: could you have a look too, please?
<Wizzup>
I mean it sounds very sensible
<freemangordon>
ok, will fix the logic to my understanding, lets see what tmlind will say
<rafael2k>
Wizzup: ok! pa stays!
<freemangordon>
:)
<rafael2k>
Wizzup: I can get sound, but there is some samplerate mismatch... interesting that what triggered the issue was the more recent alsa driver
<rafael2k>
some new kernel behavior... dunno yet
<freemangordon>
Wizzup: I guess this is the reason for CMA failures on n900 too
<freemangordon>
ugh, we have a leak on rotation too
<Wizzup>
freemangordon: yes, I think so @ rotation
<freemangordon>
but this is another leak
<Wizzup>
ok
uvos has joined #maemo-leste
<sicelo>
remind me again what's your lowest mW rate on Droid 4? with my battery script in background, i'm averaging 100mW atm. I hope/suppose that's not excessively bad
<sicelo>
@4V ... so around 25mA. i think i'm okay with that :-)
<Wizzup>
I get less I think
<sicelo>
i should think so, yes. no doubt my script has an impact (i don't even know if using sleep and while loop in the script is a good idea for cpu)
<Wizzup>
you can get it from upower
inky has quit [Read error: Connection reset by peer]
inky has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
<tmlind>
freemangordon: ok sounds reasonable
<tmlind>
sounds like something else might be wrong too if the calls are not paired
<freemangordon>
tmlind: it starts with refcount of 1
<tmlind>
sicelo: i'm seeing about 75mW idle with 3g networking active
uvos has quit [Quit: Konversation terminated!]
<tmlind>
freemangordon
<tmlind>
so are you saying it should free at 1 then?
<freemangordon>
I think so
<freemangordon>
well, it should free at 0
<freemangordon>
because this works for both front and back buffers
<freemangordon>
but for front buffers it was checking if it was non-zero *before* decrementing
<freemangordon>
which can never be true obviously
<tmlind>
ok
<freemangordon>
tmlind: do you say that OMAPDRI2DestroyBuffer shall be called more than once?
<freemangordon>
or, that someone else shall decrement too?
Pali has joined #maemo-leste
<tmlind>
freemangordon: i recall only increment was added that never got decremented earlier
<tmlind>
that elapsed real time is claimed to be in ms units too in the java examples, but seems more like system uptime to me?
<tmlind>
yeah i guess mCachedNtpElapsedRealtime in the examples is how long the system has been up when doing the query so system clock can be used to calculate ntp time offset later on
<dsc_>
im starting to integrate telepathy into conversations
<Wizzup>
:)
<tmlind>
so looks like the GpsInterface_inject_time() values are from android boot, and describe the offset to system clock and don't directly related to the MPDTIME values as those are somehow based on current time
inky has joined #maemo-leste
rafael2k has quit [Ping timeout: 240 seconds]
rafael2k has joined #maemo-leste
<Pali>
Hello! Same situation with N900 U-Boot port again happens... On ML are some patches waiting for more than half of year without answer and now are trying to remove N900 code again.
<Pali>
Wizzup: I added you to CC
<sicelo>
:-(
huckg has joined #maemo-leste
inky has quit [Ping timeout: 256 seconds]
<Wizzup>
Pali: yeah I need to work on the dm stuff
<Wizzup>
will reply later today
<Pali>
note that I have already WIP patches for dm-keyboard and dm-video
<Pali>
I have not sent them yet because other N900 patches are waiting on the list for review (for 1/2 year)
<Wizzup>
iirc this was about usb
<Pali>
yes, now I recalled...
<Pali>
there is missing dm-usb, dm-video and dm-keyboard
<Pali>
and Tom started talking about dm-usb in dm-video thread
<Wizzup>
yeah I volunteered for dm-usb
pere has quit [Ping timeout: 240 seconds]
inky has joined #maemo-leste
pere has joined #maemo-leste
inky has quit [Remote host closed the connection]
inky has joined #maemo-leste
inky_ has joined #maemo-leste
_inky has joined #maemo-leste
inky has quit [Ping timeout: 240 seconds]
inky_ has quit [Ping timeout: 256 seconds]
inky_ has joined #maemo-leste
Twig has joined #maemo-leste
<reinob>
I have a question regarding the flashing of u-boot replacing the maemo5 kernel. I'm reading https://leste.maemo.org/Nokia_N900 and see that I can flash u-boot-2013.04-2.bin, which will replace the existing u-boot/kernel with the new u-boot. But I don't know which default options (bootmenu.scr?) will be used.
<reinob>
Can I assume that if something bootable (the leste image) is in the SD card it will boot?
<reinob>
or do I need to store a bootmenu.scr on the SD card?
<reinob>
(my ultimate goal would be to wipe mmcblk1 (Mydocs and /opt) and use it with Leste, so that booting only requires mtdblock* and the sd card itself)
<freemangordon>
reinob: don;t you already have u-boot?
<freemangordon>
if you have, there is no ned to flash u-boot
<freemangordon>
*need
<reinob>
yup. But I want it to be independent of mmcblk1. As far as I know currently it is reading bootmenu.scr from Mydocs (or is it just a copy, and the actual one is stored together with u-boot on mtd3, or whereever the kernel was?)
<freemangordon>
unless I am missing something as I didn't really read that wiki page
<freemangordon>
ah, I see
<freemangordon>
Pali: ^^^
<reinob>
I'd like to at least format "Mydocs" as ext4 to use it from within Leste, but I fear that by doing this U-boot won't be able to boot anything.
<Pali>
reinob: Hi! U-Boot reads bootmenu.scr from MyDocs. If it does not exist then it use default bootmenu (which is compiled in U-Boot).
<Pali>
New version of U-Boot first reads bootmenu.scr from SD card. If it does not exist then fallback to MyDocs
<reinob>
OK! so if I flash the new u-boot and prepare a suitable bootmenu.scr on the SD card (first partition? or where exactly), then it should be OK
<Pali>
so if you want to be independent of eMMC, just move/rename bootmenu.scr from all eMMC partitions
<Pali>
reinob: only first partition of SD card and only first partition of eMMC
<reinob>
BTW does overclocking work with the Leste kernel? I tried playing with scaling_max_freq but no dice..
<freemangordon>
no, it does not :)
<reinob>
OK! :). I'll see if in the coming days I have some time to play with this.. and hope I can stay a bit in touch..
huckg has quit [Quit: Client closed]
xmn has joined #maemo-leste
<tmlind>
heh i think i figured out the MPDTIME.. current_gps_time = ntp_time converted to gps_time based on system uptime, current_gps_time / 0xffffffff is the 308 part, current_gps_time % 0xffffffff is the remainder in ms