uvos has quit [Ping timeout: 256 seconds]
pere has quit [Ping timeout: 268 seconds]
Pali has quit [Ping timeout: 240 seconds]
Oksanaa has joined #maemo-leste
Oksanaa has quit [Ping timeout: 268 seconds]
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
macros_ has quit [Ping timeout: 250 seconds]
joerg has joined #maemo-leste
macros__ has joined #maemo-leste
<freemangordon> Wizzup: if we don;t want daemon to restart on upgrade, there is no need for hacks etc
<freemangordon> see -r
<freemangordon> hmm, dsme already does that
<freemangordon> maybe I am missing the issue
mardy has joined #maemo-leste
<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
<freemangordon> what happens on the last decrement? refrcnt becomes zero and then nothing
<freemangordon> unless I am missing the whole point
<tmlind> yeah i guess no free then
_inky has quit [Ping timeout: 256 seconds]
inky has quit [Ping timeout: 240 seconds]
<tmlind> uvos: here are few gps ntp time injection examples dumped from los 14.1 after inject from gpstest
<tmlind> ntp_time_ms elapsd rt/2 ??? ?????????? rt/2
<tmlind> GpsInterface_inject_time( 1549911987370, 65652, 76 ) AT+MPDTIME=287,1291573419,76
<tmlind> GpsInterface_inject_time( 1642918214110, 91427, 290 ) AT+MPDTIME=308,4105031436,290
<tmlind> GpsInterface_inject_time( 1642939067175, 51203, 14 ) AT+MPDTIME=308,4124400839,14
<tmlind> GpsInterface_inject_time( 1642940045748, 55924, 21 ) AT+MPDTIME=308,4125358112,21
<tmlind> ntp_time_ms = ntp time from server in milliseconds
<tmlind> elapsd = elapsed real time for the ntp query
<tmlind> rt/2 = round trip time / 2
<tmlind> anybody have any idea what the two unknown values for MPDTIME are?
<tmlind> the longer one seems to be some time in milliseconds
<tmlind> i think los 14.1 is buggy, it seems to query ntp only once on bootup, after that all the gps time inject commands use the old ntp value..
<tmlind> so the GpsInterface_inject_time() values only get updated after a reboot :)
<tmlind> not sure what the elapsed real time really means, here are some java examples: https://www.javatips.net/api/android.net.sntpclient
<tmlind> if anybody wants to trace other modem related commands, these commands with los 14.1 will work:
<tmlind> adb root
<tmlind> adb shell 'echo 0x7fffffff > /sys/module/ts27010mux/parameters/debug_level'
<tmlind> adb logcat -b all
<buZz> MPD is 'mobile platform device' , gee, TIL
<tmlind> won't work with the stock android
<tmlind> buZz: ok so one mystery less then :)
<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
<Pali> partition has to be either fat or ext2/3/4
<reinob> thx!
<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
* tmlind gives it a try
__20h__ has quit [Quit: WeeChat 3.0.1]
__20h__ has joined #maemo-leste
pere has quit [Ping timeout: 268 seconds]
mardy has quit [Quit: WeeChat 2.8]
pere has joined #maemo-leste
Twig has quit [Ping timeout: 250 seconds]
_inky has quit [Ping timeout: 256 seconds]
_inky has joined #maemo-leste