System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
Pali has quit [Ping timeout: 240 seconds]
vectis_ has quit [Ping timeout: 256 seconds]
vectis_ has joined #maemo-leste
<tmlind>
uvos: interesting, so where are you seeing some 0 or 1 option for the screen orientation for gps?
<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
joerg has quit [Ping timeout: 256 seconds]
<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
joerg has joined #maemo-leste
macros__ has joined #maemo-leste
macros_ has quit [Ping timeout: 250 seconds]
<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
<tmlind>
uvos: please test update.sh works any better now getting a fix :)
<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
<tmlind>
so my experience is that gps antenna works way better with the slider closed fyi
<uvos>
freemangordon: 800-1100mAh remaining capacity is about usual for the batteries from 2012 supplied with the devices
<uvos>
note that compeared to my external lipo charger the d4 also underreports the capacity by 15-20% maybe
<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
Pali has joined #maemo-leste
_inky has joined #maemo-leste
<Wizzup>
freemangordon: tmlind: btw this still causes problems in X/omap ddx, or even just in kernel: https://dpaste.com/7ZVLDPUXS.txt
<Wizzup>
this is the bionic, fwiw
<Wizzup>
doesn't seem to be related to dmabuf leaks (I checked, there were none)
<Wizzup>
maybe a script that turns the screen on and off can reproduce it, I can try
<uvos>
i can also repoduce a xorg segfault pretty fast
<uvos>
scrolling in orrery causes a segfault almost immidiatly
<uvos>
let me supply the package
<Wizzup>
is that in 3d?
<uvos>
no its just gtk2
<uvos>
also its really hard to read its (aside from constants) one signle 15k source file
<uvos>
(i know the dependancies of the package are not correct yet)
<uvos>
Wizzup: dont have a bt yet, sure yeah could be exa
<Wizzup>
ok
<Wizzup>
I recall orrery from n900 times I think
<sicelo>
of course it's a maemo application ;-)
<uvos>
yeah i was hoping for something simmular to (ex-google) sky but its not so great
<uvos>
i gues the n900 dident have the hw for that too
* 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
<sicelo>
hw for?
<uvos>
ex-google (now comunity/ foss) sky uses the magentometer to allow you to check what an object is by pointing the device there
<uvos>
sicelo: yeah there are some datafiles missing in orrery soruce
<uvos>
sicelo: but they come from public a survey so they should be easy to reaquire
<uvos>
updated versions even
<uvos>
thats also the same place supertux2 crashes x
<uvos>
(PVRMapBo)
<uvos>
but repoducing that takes more time\
peetah has quit [Ping timeout: 250 seconds]
peetah has joined #maemo-leste
pere has quit [Ping timeout: 250 seconds]
rafael2k has joined #maemo-leste
Oksanaa has quit [Ping timeout: 256 seconds]
<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
<Wizzup>
lol
<uvos>
Wizzup: :\
<rafael2k>
hey, I'm rebasing the ov5640 and gc1245 andd sun6-csi to our 5.15 kernel
<rafael2k>
I could not find a ready-make pinephone patchset to 5.17...
<rafael2k>
better stick with 5.15 as it is stable and the pp patchset is well maintained
<rafael2k>
*ready-made
pere has joined #maemo-leste
<bencoh>
wait, ov5640?
<bencoh>
ah, for the pinephone
<rafael2k>
then I can already advance with the libcamera thing
<rafael2k>
yes, for pp!
<rafael2k>
Wizzup: just confirming, new pp kernel from repo all good, up and running
System_Error has quit [Ping timeout: 276 seconds]
<enyc>
5.15 is now upstream kernel.org LTS, wasn't declared for some time...
System_Error has joined #maemo-leste
<uvos>
idealy the pp comunity would get on with it wrt upstreaming the patches
<uvos>
then we would not need to maintain a kernel different from the mapphone/n900 one
sunshavi has quit [Ping timeout: 256 seconds]
<enyc>
uvos: (not) silly question can they take some encouragement? I observe theres a lot of disjointed efforts going on...
<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 =)
<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
<humpelstilzchen[>
Still I find it awesome what these people have done
<freemangordon>
uvos: is this the latests ddx (0.5.6)?
<uvos>
freemangordon: 0.5.6+2m7 yes
<freemangordon>
on d4?
<uvos>
yes
<freemangordon>
cool
<uvos>
but i can repo on bionic too
<freemangordon>
so, how to repro on d4?
<uvos>
run orrery (see source/binary packages i posted above) (or supertux2) and scroll around
<uvos>
supertux2 takes quite some time
<freemangordon>
ok
<uvos>
orrery will cause it in maybe 2-3 scrolls
<freemangordon>
thanks
<freemangordon>
hmm, DNS on d4 is broken?
<freemangordon>
Wizzup: ^^^?
pere has quit [Ping timeout: 240 seconds]
<freemangordon>
so, is DNS broken for me only?
<uvos>
freemangordon: yes
<freemangordon>
ok, do you know of a recent change? I know something has been discussed
<freemangordon>
if I edit resolv.conf by hand and put my router IP tehre it works
<humpelstilzchen[>
so its already fixed and I can safely update? ;)
<freemangordon>
seems so
macros__ has quit [Remote host closed the connection]
macros__ has joined #maemo-leste
sunshavi has quit [Read error: Connection reset by peer]
<freemangordon>
uvos: /usr/share/orrery/orreryLaunch is not executable
<freemangordon>
anyway, seems I am stupid, but: How to scroll?
<freemangordon>
ok, seems clicking on it crashed it
<uvos>
scroling happens by swiping the finger on the bottom left quadrant
<freemangordon>
ok
<uvos>
you probubly scrolled a bit by clicking
<uvos>
if it crashed x
<uvos>
*scroling happens by swiping the finger on the bottom RIGHT quadrant
<freemangordon>
uvos: could it be that we hit file descriptors limit?
<uvos>
no idea
<uvos>
looks like there is a bo
<uvos>
for every glyph
<uvos>
so maybe
<freemangordon>
because with only h-d and orreru running there is no crash
<freemangordon>
*orerry
<uvos>
not true
<uvos>
here
<uvos>
it crahses most repeatbly if you scroll to zenith
<uvos>
(where there is lots of text)
<freemangordon>
it does not scroll here, draws some green dots instead and zoom
<uvos>
it dosent refesh during swipe
<uvos>
only after
<uvos>
that is (poor) inteded behavior
<freemangordon>
ok
<uvos>
it zooms if you swipe top left or top right quadrant
<uvos>
it scrolls if you swipe bottom right quadrant
<uvos>
the dots are suposed to indicate how far it will scroll
<uvos>
yeah the interface is extreamly arcane
<freemangordon>
ah :)
<freemangordon>
anyway, so far I have 721 fds with h-d and orrery only
<freemangordon>
how to unzoom?
<uvos>
oh btw it helps the crash along if you enable the labes
<uvos>
whitch is a tap
<uvos>
you tap bottom left
<uvos>
so labels are hidden show with a tap in the bottom right quadrant
<uvos>
showing those causes the crash mutch sooner
<freemangordon>
I still see "ZOOMED" and cannot unzoom
<freemangordon>
but, 754 fds does not seem quite right
<freemangordon>
so I would bet we hit the 1024 fds limit
<freemangordon>
uvos: could you check the count on your device right before the crash?
<freemangordon>
yeah, definitely we exaust fds
<freemangordon>
well, seems we'll have to sacrifice a bit of performance
<freemangordon>
so map->use->unmap
<freemangordon>
those are 2 more ioctls per pixmap per copy
<freemangordon>
(copy == blit)
<uvos>
yeah i have over 962 fds open
<uvos>
by having one xterm
<uvos>
and showing the lables on orrery
<uvos>
and otherwise not scrolling from start
<freemangordon>
I guess 2-3 more terms and it will crash
<uvos>
or srolling to a screen with more text
<freemangordon>
mhm
<uvos>
it seams the amount of text shown is the key here
<uvos>
this probubly is also why supertux crashes
<freemangordon>
mhm
<uvos>
(eatch tile is a fd_
<uvos>
)
<uvos>
raise ulimit -n?
<freemangordon>
ok, I'll keep constant mapping for scanout buffers only
<uvos>
ok
<freemangordon>
uvos: no, if we have a leak it will soon take the system (Xorg) down
<freemangordon>
better scarifice the performance for stability
<uvos>
im worry what maping and umaping buffers in the low thousands will do to perf
<uvos>
but ok
<freemangordon>
the problem with map/use/unmap is that map sets SGX MMU
<freemangordon>
so we will have to set MMU for each copy op
<freemangordon>
maybe I shall keep some LRU list
<uvos>
could we check how many fds we have against ulimit and change behavior if there is pressure?
<freemangordon>
or maybe do not do GPU blit of small BOs
<uvos>
yeah that too
<uvos>
possibly its more expensive than having the cpu do it
<freemangordon>
mhm
<freemangordon>
but, OTOH I don;t know how would that affect coherency
<freemangordon>
ok, I will implement the most lame alog first (map->use->unmap)
<freemangordon>
lets see how bad it will get and then will decide
<Wizzup>
freemangordon: dns should work on deevel
<Wizzup>
-devel
<Wizzup>
wrt ipv4
<Wizzup>
it is in repo I think
<freemangordon>
yep, upgraded and it got fixed
pere has joined #maemo-leste
<uvos>
rafael2k: sphone on pp should be fixed wrt audio routing
<uvos>
rafael2k: plese test the fix (i cant ofc)
<freemangordon>
Wizzup: BTW, the issues you see on bionic are most-probably caused by missing panel initialization
pere has quit [Ping timeout: 256 seconds]
<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)
<uvos>
while on mainline after droid4-agps --upload-only and droid4-agps --inject-time it will not report any thing for quite some time
<tmlind>
uvos: yeah ok
<tmlind>
uvos: so did you find some antenna orientation param? maybe something in MPDSTART?
<uvos>
tmlind: no i was just spculating on its exitance
<uvos>
tmlind: but im looking at it rn
<tmlind>
uvos: ok, yeah i'll dump data in both landscape and portrait orientation from android
<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..
<uvos>
then its somehow not working here
<uvos>
hmm
<tmlind>
uvos: so i power cycled the device, injected time, started gpspipe -r and a bunch of satellites show up in cgps
<tmlind>
let me try this again without injecting time
<tmlind>
my dev system is slide open in the rack so no signal..
<tmlind>
uvos: btw i have chrony running, sudo chronyc tracking shows system time being very close to ntp time
<uvos>
i ran ntpdate-debian -4 right before upload
<uvos>
so should be very close
<tmlind>
the struct timex offset seems to be 0 for me
<tmlind>
so i did not add it to droid4-agps.c so far
<tmlind>
maybe printf the tmx.offset and see if it's 0 for you?
<tmlind>
in gsmtty_inject_time() in droid4-agps.c that is
<uvos>
tmlind: ok sec
<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
<uvos>
tmlind: yeah
<uvos>
it fails at adjtimex silently
<tmlind>
hmm
<tmlind>
maybe glibc needs to use the whatever ntp_* call instead?