| Wizzup | meego/symbian style blur is quite nice | 00:35 |
|---|---|---|
| tmlind | uvos: interesting, so where are you seeing some 0 or 1 option for the screen orientation for gps? | 06:15 |
| tmlind | i don't think we need that kernel patch btw, we can just inject time from userspace, i'll add some more options to droid4-agps for testing | 06:16 |
| tmlind | uvos: MPDTIME does not send orientation, it's just gps time and error looks like. so droid4-agps can do it with adjtimex() and tmx.maxerror i think | 06:21 |
| tmlind | uvos: then MPDOPEN has some unknown cookie type thing that seems like it's unused. if it's some session id, then i have no idea where it comes from | 06:22 |
| tmlind | ok pushed out updated droid4-agps with almanac and clear options, no extra kernel patch should be used: https://github.com/tmlind/droid4-agps/commits/master | 07:11 |
| tmlind | uvos: please test update.sh works any better now getting a fix :) | 07:12 |
| tmlind | no idea if the order of the commands matters or if gps should be stopped for updating or clearing.. seems like no need to stop gps for uploading almanac looking at the android logs though | 07:12 |
| tmlind | so my experience is that gps antenna works way better with the slider closed fyi | 07:15 |
| freemangordon | hmm POWER_SUPPLY_CHARGE_FULL=879099 | 08:38 |
| freemangordon | is that normal on d4? | 08:38 |
| uvos | freemangordon: 800-1100mAh remaining capacity is about usual for the batteries from 2012 supplied with the devices | 09:55 |
| uvos | note that compeared to my external lipo charger the d4 also underreports the capacity by 15-20% maybe | 09:58 |
| uvos | probubly because we dont charge to hvlipo voltages and because the kernel will note the capacity before it determines the battery to be empty because its under load | 09:59 |
| Wizzup | freemangordon: tmlind: btw this still causes problems in X/omap ddx, or even just in kernel: https://dpaste.com/7ZVLDPUXS.txt | 10:48 |
| Wizzup | this is the bionic, fwiw | 10:48 |
| Wizzup | doesn't seem to be related to dmabuf leaks (I checked, there were none) | 10:48 |
| Wizzup | maybe a script that turns the screen on and off can reproduce it, I can try | 10:49 |
| uvos | i can also repoduce a xorg segfault pretty fast | 10:50 |
| uvos | scrolling in orrery causes a segfault almost immidiatly | 10:51 |
| uvos | let me supply the package | 10:51 |
| Wizzup | is that in 3d? | 10:55 |
| uvos | no its just gtk2 | 10:57 |
| uvos | also its really hard to read its (aside from constants) one signle 15k source file | 10:58 |
| uvos | *15k loc | 10:58 |
| uvos | anyhow https://github.com/IMbackK/orrery | 10:59 |
| uvos | compile packages: http://uvos.xyz/maserati/orrery | 11:00 |
| Wizzup | so could be in exa? got a bt? | 11:01 |
| uvos | (i know the dependancies of the package are not correct yet) | 11:01 |
| uvos | Wizzup: dont have a bt yet, sure yeah could be exa | 11:01 |
| Wizzup | ok | 11:01 |
| Wizzup | I recall orrery from n900 times I think | 11:01 |
| sicelo | of course it's a maemo application ;-) | 11:01 |
| uvos | yeah i was hoping for something simmular to (ex-google) sky but its not so great | 11:03 |
| uvos | i gues the n900 dident have the hw for that too | 11:04 |
| * sicelo check if dev was able to provide some of his last/latest sources. there was something missing in orrery that i needed, and he had worked on it | 11:04 | |
| sicelo | hw for? | 11:05 |
| uvos | ex-google (now comunity/ foss) sky uses the magentometer to allow you to check what an object is by pointing the device there | 11:05 |
| sicelo | ah | 11:06 |
| uvos | i used to use that on d1 quite a bit | 11:06 |
| uvos | freemangordon: Wizzup: backtrace uvos.xyz/maserati/orrery/bt.txt | 11:11 |
| uvos | sicelo: yeah there are some datafiles missing in orrery soruce | 11:12 |
| uvos | sicelo: but they come from public a survey so they should be easy to reaquire | 11:13 |
| uvos | updated versions even | 11:13 |
| uvos | thats also the same place supertux2 crashes x | 11:17 |
| uvos | (PVRMapBo) | 11:17 |
| uvos | but repoducing that takes more time\ | 11:17 |
| Wizzup | uvos: I think at this point I spent more time being frustrated with ofono and rebooting it on the d4 than I would have spent fixing it | 13:20 |
| Wizzup | lol | 13:20 |
| uvos | Wizzup: :\ | 13:41 |
| rafael2k | hey, I'm rebasing the ov5640 and gc1245 andd sun6-csi to our 5.15 kernel | 13:54 |
| rafael2k | I could not find a ready-make pinephone patchset to 5.17... | 13:55 |
| rafael2k | better stick with 5.15 as it is stable and the pp patchset is well maintained | 13:55 |
| rafael2k | *ready-made | 13:55 |
| bencoh | wait, ov5640? | 13:55 |
| bencoh | ah, for the pinephone | 13:56 |
| rafael2k | then I can already advance with the libcamera thing | 13:56 |
| rafael2k | yes, for pp! | 13:56 |
| rafael2k | Wizzup: just confirming, new pp kernel from repo all good, up and running | 14:00 |
| enyc | 5.15 is now upstream kernel.org LTS, wasn't declared for some time... | 14:28 |
| uvos | idealy the pp comunity would get on with it wrt upstreaming the patches | 14:32 |
| uvos | then we would not need to maintain a kernel different from the mapphone/n900 one | 14:33 |
| enyc | uvos: (not) silly question can they take some encouragement? I observe theres a lot of disjointed efforts going on... | 14:47 |
| enyc | uvos: I reclal there was this story how 2.6.32 was used as LTS kernel in so many distros, not by accident, because many unofficially collaborated to arrange/suggest this in many ways =) | 14:47 |
| rafael2k | I'm fine with 5.15... and no breath holding for mainline support all pinephone bits... there are sooo many loose ends, and pine64 has no hired full time developer, so you can see most of pinephone support is being written by the usual suspects.. not a lot of people tbh | 15:51 |
| humpelstilzchen[ | Still I find it awesome what these people have done | 15:59 |
| freemangordon | uvos: is this the latests ddx (0.5.6)? | 16:14 |
| uvos | freemangordon: 0.5.6+2m7 yes | 16:15 |
| freemangordon | on d4? | 16:15 |
| uvos | yes | 16:16 |
| freemangordon | cool | 16:16 |
| uvos | but i can repo on bionic too | 16:16 |
| freemangordon | so, how to repro on d4? | 16:16 |
| uvos | run orrery (see source/binary packages i posted above) (or supertux2) and scroll around | 16:17 |
| uvos | supertux2 takes quite some time | 16:17 |
| freemangordon | ok | 16:17 |
| uvos | orrery will cause it in maybe 2-3 scrolls | 16:17 |
| freemangordon | thanks | 16:17 |
| freemangordon | hmm, DNS on d4 is broken? | 16:23 |
| freemangordon | Wizzup: ^^^? | 16:24 |
| freemangordon | so, is DNS broken for me only? | 16:58 |
| uvos | freemangordon: yes | 17:02 |
| freemangordon | ok, do you know of a recent change? I know something has been discussed | 17:03 |
| freemangordon | if I edit resolv.conf by hand and put my router IP tehre it works | 17:03 |
| freemangordon | *there | 17:04 |
| uvos | no not terrobly recent | 17:04 |
| uvos | also this was/is parazyds area | 17:04 |
| uvos | so idk really | 17:04 |
| freemangordon | https://github.com/maemo-leste/libicd-network-ipv4/commit/49afd837bf5a7764c0cc59854aad2b01175088a4 | 17:05 |
| freemangordon | fixed in the next commit | 17:07 |
| humpelstilzchen[ | so its already fixed and I can safely update? ;) | 17:08 |
| freemangordon | seems so | 17:09 |
| freemangordon | uvos: /usr/share/orrery/orreryLaunch is not executable | 18:07 |
| freemangordon | anyway, seems I am stupid, but: How to scroll? | 18:08 |
| freemangordon | ok, seems clicking on it crashed it | 18:08 |
| uvos | scroling happens by swiping the finger on the bottom left quadrant | 18:11 |
| freemangordon | ok | 18:12 |
| uvos | you probubly scrolled a bit by clicking | 18:12 |
| uvos | if it crashed x | 18:12 |
| uvos | *scroling happens by swiping the finger on the bottom RIGHT quadrant | 18:13 |
| freemangordon | uvos: could it be that we hit file descriptors limit? | 18:13 |
| uvos | no idea | 18:13 |
| uvos | looks like there is a bo | 18:13 |
| uvos | for every glyph | 18:13 |
| uvos | so maybe | 18:13 |
| freemangordon | because with only h-d and orreru running there is no crash | 18:14 |
| freemangordon | *orerry | 18:14 |
| uvos | not true | 18:14 |
| uvos | here | 18:15 |
| uvos | it crahses most repeatbly if you scroll to zenith | 18:15 |
| uvos | (where there is lots of text) | 18:15 |
| freemangordon | it does not scroll here, draws some green dots instead and zoom | 18:15 |
| uvos | it dosent refesh during swipe | 18:16 |
| uvos | only after | 18:16 |
| uvos | that is (poor) inteded behavior | 18:16 |
| freemangordon | ok | 18:16 |
| uvos | it zooms if you swipe top left or top right quadrant | 18:16 |
| uvos | it scrolls if you swipe bottom right quadrant | 18:16 |
| uvos | the dots are suposed to indicate how far it will scroll | 18:17 |
| uvos | yeah the interface is extreamly arcane | 18:17 |
| freemangordon | ah :) | 18:17 |
| freemangordon | anyway, so far I have 721 fds with h-d and orrery only | 18:17 |
| freemangordon | how to unzoom? | 18:18 |
| uvos | oh btw it helps the crash along if you enable the labes | 18:18 |
| uvos | whitch is a tap | 18:18 |
| uvos | you tap bottom left | 18:18 |
| uvos | so labels are hidden show with a tap in the bottom right quadrant | 18:18 |
| uvos | showing those causes the crash mutch sooner | 18:18 |
| freemangordon | I still see "ZOOMED" and cannot unzoom | 18:19 |
| freemangordon | but, 754 fds does not seem quite right | 18:19 |
| freemangordon | so I would bet we hit the 1024 fds limit | 18:19 |
| freemangordon | uvos: could you check the count on your device right before the crash? | 18:20 |
| freemangordon | yeah, definitely we exaust fds | 18:22 |
| freemangordon | well, seems we'll have to sacrifice a bit of performance | 18:22 |
| freemangordon | so map->use->unmap | 18:22 |
| freemangordon | those are 2 more ioctls per pixmap per copy | 18:24 |
| freemangordon | (copy == blit) | 18:24 |
| uvos | yeah i have over 962 fds open | 18:24 |
| uvos | by having one xterm | 18:24 |
| uvos | and showing the lables on orrery | 18:24 |
| uvos | and otherwise not scrolling from start | 18:24 |
| freemangordon | I guess 2-3 more terms and it will crash | 18:25 |
| uvos | or srolling to a screen with more text | 18:25 |
| freemangordon | mhm | 18:25 |
| uvos | it seams the amount of text shown is the key here | 18:25 |
| uvos | this probubly is also why supertux crashes | 18:25 |
| freemangordon | mhm | 18:25 |
| uvos | (eatch tile is a fd_ | 18:25 |
| uvos | ) | 18:25 |
| uvos | raise ulimit -n? | 18:26 |
| freemangordon | ok, I'll keep constant mapping for scanout buffers only | 18:26 |
| uvos | ok | 18:26 |
| freemangordon | uvos: no, if we have a leak it will soon take the system (Xorg) down | 18:26 |
| freemangordon | better scarifice the performance for stability | 18:27 |
| uvos | im worry what maping and umaping buffers in the low thousands will do to perf | 18:27 |
| uvos | but ok | 18:27 |
| freemangordon | the problem with map/use/unmap is that map sets SGX MMU | 18:28 |
| freemangordon | so we will have to set MMU for each copy op | 18:28 |
| freemangordon | maybe I shall keep some LRU list | 18:28 |
| uvos | could we check how many fds we have against ulimit and change behavior if there is pressure? | 18:28 |
| freemangordon | or maybe do not do GPU blit of small BOs | 18:30 |
| uvos | yeah that too | 18:30 |
| uvos | possibly its more expensive than having the cpu do it | 18:30 |
| freemangordon | mhm | 18:30 |
| freemangordon | but, OTOH I don;t know how would that affect coherency | 18:31 |
| freemangordon | ok, I will implement the most lame alog first (map->use->unmap) | 18:31 |
| freemangordon | lets see how bad it will get and then will decide | 18:31 |
| Wizzup | freemangordon: dns should work on deevel | 18:40 |
| Wizzup | -devel | 18:40 |
| Wizzup | wrt ipv4 | 18:41 |
| Wizzup | it is in repo I think | 18:41 |
| freemangordon | yep, upgraded and it got fixed | 18:59 |
| uvos | rafael2k: sphone on pp should be fixed wrt audio routing | 19:27 |
| uvos | rafael2k: plese test the fix (i cant ofc) | 19:27 |
| freemangordon | Wizzup: BTW, the issues you see on bionic are most-probably caused by missing panel initialization | 19:41 |
| uvos | tmlind: so the new dorid4-agps dosent appear to make a difference here, maybe lock times are somewhat improved, but one thing that strikes me is that in android the device starts reporting rssi for at least some sats almost immiatly (<4sec) even if it takes long to lock (like indoors) | 20:23 |
| uvos | while on mainline after droid4-agps --upload-only and droid4-agps --inject-time it will not report any thing for quite some time | 20:24 |
| tmlind | uvos: yeah ok | 20:29 |
| tmlind | uvos: so did you find some antenna orientation param? maybe something in MPDSTART? | 20:30 |
| uvos | tmlind: no i was just spculating on its exitance | 20:31 |
| uvos | tmlind: but im looking at it rn | 20:31 |
| tmlind | uvos: ok, yeah i'll dump data in both landscape and portrait orientation from android | 20:31 |
| tmlind | uvos: looks like i see a bunch of satellites after i inject time almost immediately, can't get time or fix though from the satellites on my dev system.. | 20:44 |
| uvos | then its somehow not working here | 20:44 |
| uvos | hmm | 20:44 |
| tmlind | uvos: so i power cycled the device, injected time, started gpspipe -r and a bunch of satellites show up in cgps | 20:45 |
| tmlind | let me try this again without injecting time | 20:45 |
| tmlind | my dev system is slide open in the rack so no signal.. | 20:45 |
| tmlind | uvos: btw i have chrony running, sudo chronyc tracking shows system time being very close to ntp time | 20:47 |
| uvos | i ran ntpdate-debian -4 right before upload | 20:48 |
| uvos | so should be very close | 20:48 |
| tmlind | the struct timex offset seems to be 0 for me | 20:48 |
| tmlind | so i did not add it to droid4-agps.c so far | 20:48 |
| tmlind | maybe printf the tmx.offset and see if it's 0 for you? | 20:49 |
| tmlind | in gsmtty_inject_time() in droid4-agps.c that is | 20:49 |
| uvos | tmlind: ok sec | 20:52 |
| tmlind | uvos: yup, my rack d4 does not show any satellites after a cold boot but immediately starts showing up a bunch of satellites after i inject time | 20:54 |
| uvos | tmlind: yeah | 20:54 |
| uvos | it fails at adjtimex silently | 20:54 |
| tmlind | hmm | 20:54 |
| tmlind | maybe glibc needs to use the whatever ntp_* call instead? | 20:55 |
| tmlind | i'm on musl | 20:55 |
| tmlind | ntp_adjtime() maybe? | 20:56 |
| uvos | tmlind: it returns TIME_ERROR | 20:56 |
| uvos | https://www.man7.org/linux/man-pages/man2/adjtimex.2.html | 20:56 |
| uvos | unfortinatly im suhre what all of these causes mean :P | 20:57 |
| uvos | *unsure | 20:57 |
| tmlind | no idea :) | 20:58 |
| tmlind | i guess my dev d4 is pretty much in a faraday cage as it does not get a fix :) | 20:59 |
| tmlind | i'll check changing the 0/1 params for MPDSTART if it affects the antenna | 20:59 |
| uvos | tmlind: so the code in droid4-agps is wrong for sur | 21:04 |
| uvos | e | 21:04 |
| uvos | since adjtimex for instance returning TIME_INS is not an error | 21:04 |
| tmlind | should check for errors < 0 then? | 21:07 |
| uvos | it retunring 5 is also an error | 21:07 |
| uvos | (or at least sugests time is not reliable) | 21:07 |
| tmlind | ok that would be nice to know and bail out | 21:08 |
| uvos | tmlind: ok so having chrony running makes it confident about the time | 21:13 |
| uvos | and wow yeah | 21:13 |
| uvos | it locked in like 7 sec | 21:13 |
| tmlind | nice :) | 21:13 |
| tmlind | i think i've heard of this.. it's called error handling? :) | 21:14 |
| uvos | this is pretty great | 21:16 |
| uvos | it locks sooo fast | 21:16 |
| uvos | event indoors | 21:16 |
| uvos | *even | 21:16 |
| tmlind | cool | 21:16 |
| uvos | i wonder how bad its is having crony sync every 60, battery wise | 21:16 |
| tmlind | well chrony used to be bad but now it has been behaving for pm for mew | 21:17 |
| tmlind | not sure if i tweaked some conf file back then | 21:17 |
| tmlind | i think i'm just using chrony default on alpine right now | 21:21 |
| uvos | we can probubly push minpoll up a bit | 21:21 |
| uvos | if its too mutch | 21:21 |
| tmlind | would be best to do that when connecting online, probably does not need to be done more than once a day? | 21:23 |
| tmlind | my chrony.conf just has these: | 21:24 |
| tmlind | pool pool.ntp.org iburst | 21:24 |
| tmlind | initstepslew 10 pool.ntp.org | 21:24 |
| tmlind | driftfile /var/lib/chrony/chrony.drift | 21:24 |
| tmlind | rtcsync | 21:24 |
| tmlind | cmdport 0 | 21:24 |
| uvos | dont know, depends on what causes the kernel to loos confidence in the time estimate | 21:24 |
| uvos | *loose | 21:25 |
| tmlind | well the driftfile should take care of that pretty fast, no? | 21:25 |
| uvos | depends on how mutch temperature drift the crystal has | 21:25 |
| uvos | it gets exposed to pretty varient temps after all | 21:25 |
| tmlind | ok | 21:25 |
| tmlind | yeah | 21:26 |
| tmlind | well making chrony to update time when starting gps would then make most sense | 21:26 |
| uvos | yes | 21:27 |
| tmlind | i think it's actually the kernel that steps the system time nowadays, so we should probably add the tmx.offset | 21:27 |
| tmlind | unless tmx.offset is just not used and always 0 | 21:28 |
| uvos | its 0 here | 21:28 |
| tmlind | yeah i wonder what it is in your non-working case? | 21:29 |
| uvos | 0 | 21:29 |
| tmlind | ok that can wait then until we start seeing some other values :) | 21:29 |
| uvos | also just ignoreing the TIME_ERROR caused it not to lock fast | 21:29 |
| uvos | it only started locking fast after chrony was run | 21:29 |
| tmlind | ok | 21:29 |
| uvos | and it retuned TIME_OK | 21:29 |
| tmlind | got some patch we can apply? | 21:30 |
| uvos | no but i can write | 21:30 |
| uvos | its trivial | 21:30 |
| tmlind | yeh ok that would be great, and print an error and bail out if time not ok? | 21:31 |
| uvos | yes ofc | 21:31 |
| tmlind | sounds good | 21:31 |
| tmlind | maybe some ntp geeks can tell how to make chronyc force update the time? | 21:31 |
| uvos | chronyc -4 -q | 21:32 |
| uvos | When run in this mode, chronyd will set the system clock once and exit. It will not detach from the terminal. | 21:32 |
| uvos | we can just have icd2 and location-deamon run that as required | 21:32 |
| tmlind | ok | 21:32 |
| tmlind | i think freemangordon had some concerns what updates the rtc | 21:33 |
| tmlind | i don't think ml messes with the system time? | 21:33 |
| uvos | not unless the user sets the time by hand | 21:33 |
| uvos | (ofc) | 21:33 |
| tmlind | ok | 21:33 |
| uvos | in the gui | 21:33 |
| tmlind | ok | 21:34 |
| tmlind | or sets the TZ? | 21:34 |
| uvos | possibly yeah | 21:34 |
| tmlind | sounds like a chrony config that does not set the rtc should be easy to add then | 21:34 |
| uvos | i dont see the point of not setting the rtc | 21:35 |
| uvos | but freemangordon might have something to add | 21:35 |
| tmlind | yeah there was some issue where m-l timed or something like that manages the rtc for alarms etc | 21:36 |
| uvos | tmlind: btw | 21:39 |
| uvos | tmlind: i noticed that setting iw phy phy0 set txpower fixed <some number> | 21:39 |
| uvos | causes the wifi range to be just as good as on android | 21:39 |
| uvos | seams like it dosent increase tx power enough in automatic mode | 21:39 |
| uvos | also througput is vastly improved | 21:40 |
| uvos | <some number> seams to hardly matter between 10000000 and 2000000000 | 21:41 |
| tmlind | oh interesting | 21:41 |
| tmlind | this one is fun for gps testing to set time: sudo chronyc -m makestep tracking | 21:42 |
| tmlind | with that i see: System time : 0.000000000 seconds fast of NTP time | 21:42 |
| uvos | System time : 0.000000000 seconds slow of NTP time | 21:43 |
| uvos | yeah | 21:43 |
| uvos | 60 sec update rate seams overkill | 21:43 |
| tmlind | yeah.. | 21:43 |
| tmlind | sudo chronyc tracking should allow monitoring it | 21:44 |
| tmlind | my guess is minor offsets don't matter, after all it's a serial port command to set the time :) | 21:45 |
| tmlind | and the injected time is in milliseconds | 21:47 |
| uvos | tmlind: right | 21:54 |
| uvos | tmlind: for this reason im also going to have TIME_ERROR print a warning only | 21:54 |
| uvos | might still work if the error is minor | 21:54 |
| tmlind | uvos: ok | 21:54 |
| tmlind | yeah worth trying | 21:54 |
| uvos | tmlind: http://uvos.xyz/maserati/patches/0001-Correctly-handle-the-return-values-of-adjtimex.patch | 21:57 |
| tmlind | uvos: ok thanks pushed to droid4-agps on github | 22:03 |
| tmlind | so i guess no need to try to figure out the MPDOPEN unknown variable any longer, it does not seem to matter :) | 22:04 |
| tmlind | i'll check the android logs for the orientation just in case | 22:04 |
| uvos | ok | 22:04 |
| tmlind | need to get some sleep here now though, ttyl | 22:04 |
| uvos | yeah it seams to work perfectly fine now here | 22:04 |
| tmlind | nice | 22:05 |
| uvos | good night! | 22:05 |
| tmlind | same | 22:05 |
| freemangordon | uvos: I am using ntpdate to set time occasionally on fremanltle | 22:14 |
| freemangordon | but I don't know if it sets rtc | 22:15 |
| freemangordon | however, ntpdate alone does not bring troubles | 22:15 |
| freemangordon | zzz | 22:15 |
| sicelo | You need to use hwclock afterwards to set the rtc | 22:16 |
| * sicelo uses ntpdate too on Fremantle, each time internet connectivity comes up | 22:16 | |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!