| uvos | freemangordon: so here are ofono logs: http://uvos.xyz/maserati/ofonodbg | 00:01 |
|---|---|---|
| uvos | so ofono.log and n_gsm.log show the sequence of: boot -> sim unlock -> ofono connects -> ofono looses signal -> signal never regained until ofono is restarted | 00:02 |
| uvos | restarting ofono bings back the signal instantly | 00:03 |
| uvos | and sudo qmicli --device=/dev/cdc-wdm0 --device-open-proxy --nas-get-serving-system attests that the signal is never lost | 00:03 |
| uvos | ofonosms.log is me trying to send a sms | 00:03 |
| uvos | this sms ends up as forever PENDING state in ofono ./list-messages | 00:04 |
| uvos | nothing happens in dmesg at all when this happens | 00:04 |
| uvos | i cant send sms at all anymore since the ofono bug fixing rounds | 00:04 |
| norayr | which driver to install? on droid? | 02:19 |
| freemangordon | uvos: try with higher res, this https://archive.org/download/BigBuckBunny/big_buck_bunny_480p_h264.mov for example | 07:26 |
| freemangordon | norayr: just upgrade | 07:26 |
| freemangordon | uvos: hmm, even with your example I see 30% vs 100% (x11 vs xv) | 07:30 |
| freemangordon | keep in mind mpv will use xv by default, so you must specify -vo x11 to test without xv | 07:31 |
| freemangordon | oh, it seems mpv uses 'gpu' by default | 07:33 |
| freemangordon | well, we are comparing gles vs gles :) | 07:33 |
| freemangordon | uvos: compare mpv big_buck_bunny_480p_h264.mov -vo gpu vs mpv big_buck_bunny_480p_h264.mov -vo xv | 07:44 |
| freemangordon | I wonder why mpv struggles to play that, nor mplayer neither gstreamer have issues with it | 07:45 |
| freemangordon | oh, ok, it seems tmlind's patch is needed after all | 07:54 |
| freemangordon | or not? | 08:08 |
| freemangordon | wait, what? https://www.ti.com/tool/C64XPLUSCODECS | 08:32 |
| freemangordon | uvos: mpv somehow succeeds to break gpu playback | 09:08 |
| freemangordon | after several attempts, fullscreen xv renders with 2 fps, but that happens only after mpv was used | 09:09 |
| freemangordon | also, sometimes when mpv is switched to fullscreen, with gpu vo, the video is misrendered (it looks like wrong pitch is assumed) | 09:11 |
| freemangordon | ok, no idea what mpv is doing, but it uses 30-40% more CPU than mplayer, no matter xv or gpu vo | 09:22 |
| freemangordon | mplayer with xv is capable of playing even big_buck_bunny_720p_h264.mov with just a few frames dropped | 09:22 |
| uvos | freemangordon: iths was -vo vs -vo gpu | 10:05 |
| uvos | so xv is accellerated via gles in your ddx? | 10:06 |
| _uvos_ | ofc -vo x11 is mutch slower | 10:12 |
| freemangordon | uvos: well, it is not gles, but through gpu | 10:45 |
| freemangordon | basically bot end up in shaders | 10:45 |
| freemangordon | *both | 10:45 |
| freemangordon | I guess IMG/TI shaders are better optimized than generic ones in mpv | 10:46 |
| freemangordon | uvos: as I said, compare xv vs gpu on big_buck_bunny_480p_h264.mov | 10:51 |
| freemangordon | with gpu it drops frames like crazy | 10:52 |
| uvos | ok | 11:22 |
| uvos | i dont really see why -vo gpu must be slower, but no matter | 11:22 |
| uvos | anyhow did you see the ofono logs? | 11:22 |
| freemangordon | no, will look at them later | 11:23 |
| uvos | ok | 11:23 |
| uvos | speaking of gpu acceleration, a gpu accelerated browser would be pretty rad, qwebengine gets petty close it seams, it just renders black with gles enabled (try qtwebbrowser -platform xcb) | 11:24 |
| freemangordon | uvos: most-probably -vo gpu uses shader that is not optimized, while -vo xv uses either very optimized shader or specialized video processing HW/instructions in the GPU | 11:34 |
| buZz | uvos: chromium seems hw accelerated | 11:37 |
| buZz | or its just magically very fast | 11:37 |
| freemangordon | it is not | 11:37 |
| buZz | the latter then :D | 11:37 |
| freemangordon | yes, it is fast, but not HW accelerated | 11:38 |
| freemangordon | it does not support gles2 AFAIK | 11:38 |
| uvos | i think it was dropped | 11:38 |
| uvos | but in deb 10 it probubly still dose | 11:38 |
| buZz | probably does upstream but devuan/debian prefers to not compile it? :) | 11:38 |
| uvos | anyhow its not hw accelerated | 11:38 |
| freemangordon | :nod: | 11:38 |
| uvos | but yeah both ff and chomeium do fairly well with sw rendering | 11:38 |
| uvos | to my suprise | 11:38 |
| freemangordon | I hope this will get better when I accelerate compositing | 11:39 |
| buZz | what changes about battery calibration btw? i cant seem to get it back | 11:39 |
| buZz | changed* | 11:39 |
| freemangordon | this will release more CPU for them to render | 11:39 |
| uvos | freemangordon: well without hildon it is faster still yes | 11:39 |
| uvos | everything is | 11:39 |
| buZz | not debugging maemo or hildon issues, uvos :) | 11:40 |
| freemangordon | yeah, but once we have aHW compositing, the difference should become minimal | 11:40 |
| uvos | right | 11:40 |
| uvos | that was my point hw composting should help | 11:40 |
| uvos | since no compositing dose | 11:40 |
| freemangordon | XV was a general rehearsal for that | 11:40 |
| freemangordon | because it uses SGXQueryTransfer function, that is not part of the public API | 11:41 |
| freemangordon | and I had to RE a pile of structures | 11:41 |
| freemangordon | good news is that some of TI SGX SDKs come with debug symbols | 11:41 |
| uvos | [4461:4483:1003/114142.601287:ERROR:gles2_cmd_decoder.cc(2603)] [.RenderWorker-0x5e8f08]GL ERROR :GL_INVALID_OPERATION : ScopedTextureBinder::dtor: <- error from previous GL command | 11:41 |
| buZz | weird, my /var/lib/droid4-battery-calibration/charge_full is just empty :( | 11:42 |
| freemangordon | so it is not *that* hard | 11:42 |
| uvos | thats what qwebengine fails at btw | 11:42 |
| uvos | probubly assumes an extension we dont have | 11:42 |
| freemangordon | yeah | 11:42 |
| freemangordon | uvos: btw mpv crashes GPU with 720p bunny | 11:43 |
| uvos | buZz: we delete it if the battery goes below -20% full | 11:43 |
| freemangordon | and I am sure the issue is with mpv | 11:43 |
| uvos | or above 120% full | 11:43 |
| uvos | that can happen for various reasons | 11:43 |
| uvos | one being that your spike triggers low prematurely | 11:43 |
| uvos | and then you discharge further untill the battery is way below "low" | 11:44 |
| uvos | the logic is there because we have no idea when the user inserts a new battery, so the values are sanity checked | 11:44 |
| buZz | uvos: this changed recently? | 11:44 |
| uvos | no | 11:44 |
| buZz | weird, never seen before | 11:44 |
| uvos | i added this to the kernel >1 year ago | 11:44 |
| buZz | feels pretty unfriendly | 11:45 |
| uvos | no, why should the kernel keep callibration thats for sure totaly wrong? | 11:45 |
| buZz | seems the only user that ever swaps batteries around is you :P | 11:46 |
| buZz | lol, i put "1000000" into 'charge_full' with a 40% full battery, poweroff through hildon, poweron, boom, uncalibrated , var/lib/droid4-bat-cal/charge_full -again- empty :D | 11:50 |
| uvos | where are you putting the value? | 11:50 |
| buZz | lol where do you think :P | 11:50 |
| uvos | idk | 11:50 |
| uvos | changeing var/lib/droid4-bat-cal/charge_full has no effect | 11:50 |
| freemangordon | there is a file in /usr/share | 11:51 |
| freemangordon | does it not? | 11:51 |
| uvos | no | 11:51 |
| freemangordon | if you stop the service? | 11:51 |
| uvos | then sure | 11:51 |
| freemangordon | well... | 11:51 |
| uvos | but the right way is tell the kenrel | 11:51 |
| uvos | by putting the value into the file in sys | 11:51 |
| freemangordon | ah | 11:51 |
| uvos | the value from the kernel then gets saved as normal | 11:51 |
| buZz | uvos: i changed /sys/class/power_supply/battery/charge_full obviously | 11:51 |
| uvos | on shutdown | 11:51 |
| uvos | the shtudown also needs to be clean ofc | 11:51 |
| buZz | and the init script didnt save it | 11:51 |
| uvos | thats wierd | 11:51 |
| buZz | it was a clean shutdown, battery is ~40% | 11:52 |
| uvos | the script is failing on your system then | 11:52 |
| uvos | for some reason | 11:52 |
| uvos | try running it by hand | 11:52 |
| uvos | check serial output on shutdown | 11:52 |
| buZz | hence me asking what changed | 11:52 |
| uvos | nothing | 11:52 |
| uvos | all of this is very old | 11:53 |
| buZz | ah, it didnt get started | 11:53 |
| buZz | 'cat write error invalid argument' on starting, great | 11:53 |
| uvos | thats normal | 11:53 |
| uvos | if you have no var/lib/droid4-bat-cal/charge_full | 11:54 |
| buZz | its preventing the init script to execute | 11:54 |
| uvos | right there should be a ignored return value there | 11:54 |
| buZz | thus not able to -stop- the init script later | 11:54 |
| uvos | the install sctipt touches var/lib/droid4-bat-cal/charge_full | 11:54 |
| uvos | so its not really a problem | 11:54 |
| buZz | thats wrong then | 11:55 |
| buZz | as the emptystring inside prevents the init script from working | 11:55 |
| uvos | ok | 11:55 |
| buZz | alright, putting "1000000" into /var/lib/droid4-bat-cal/cha-fu and starting/stopping the script works | 11:57 |
| uvos | buZz: if its missing could you add || true | 11:57 |
| buZz | its? | 11:57 |
| freemangordon | buZz: please make a PR for that too | 11:58 |
| uvos | the return value of the cat line on startup should be ignored | 11:58 |
| uvos | if its not | 11:58 |
| buZz | the file was there, it was empty , leading to the 'cat' failing and the whole init script stopping | 11:58 |
| uvos | please add it | 11:58 |
| uvos | just looked at the script | 12:00 |
| buZz | but that wont help | 12:00 |
| uvos | yeah no touch | 12:00 |
| buZz | https://github.com/maemo-leste/droid4-battery-calibration/blob/master/scripts/openrc/droid4-battery-calibration , see line 21 | 12:00 |
| uvos | it checks if charge_full exits | 12:00 |
| buZz | it doesnt check if there's a valid input | 12:00 |
| uvos | but the saveing on shtudown dose | 12:00 |
| buZz | it just blindly stores it | 12:00 |
| uvos | so there should be no possiblity of it being emtpy | 12:00 |
| uvos | unless you mess with the file | 12:00 |
| buZz | beside the method you said that deletes the value | 12:00 |
| uvos | no | 12:01 |
| buZz | when battery is 20% full ? | 12:01 |
| uvos | thats the kernel | 12:01 |
| buZz | what did you mean by that then | 12:01 |
| uvos | the kernel deletes its internal value | 12:01 |
| uvos | reading the value then gives an empty file in sys | 12:01 |
| buZz | which gets copied as new calibration on line 21 | 12:01 |
| uvos | wich the script handels | 12:01 |
| uvos | and dosent just save | 12:01 |
| buZz | it doesnt ? | 12:01 |
| buZz | it does save, there's no check | 12:01 |
| uvos | if [ $? -ne 0 ]; then | 12:02 |
| buZz | thats the errorlevel of cat | 12:02 |
| uvos | rm -f /var/lib/droid4-battery-calibration/charge_full | 12:02 |
| uvos | i know | 12:02 |
| uvos | the read on the kernel fails | 12:02 |
| uvos | with ENODATA | 12:02 |
| buZz | not the contents of sys/class/power_supply/battery/charge_full | 12:02 |
| uvos | yes but if the kernel delete the value | 12:02 |
| uvos | the read fails | 12:02 |
| buZz | i think you're overestimating what cat file > otherfile will do :P | 12:03 |
| uvos | well idk what cat is supposed to do if read() returns !=1 | 12:03 |
| uvos | *0 | 12:03 |
| uvos | surely not return 0 | 12:03 |
| uvos | anyhow still adding || true to the cat is a good idea | 12:03 |
| uvos | since the user might mess with the file | 12:03 |
| buZz | alright | 12:03 |
| buZz | wont that then -never- hit $? -ne 0 ? | 12:04 |
| uvos | no why | 12:04 |
| uvos | if the kernel has no value | 12:04 |
| buZz | because it would always be true | 12:04 |
| uvos | that will still be hit | 12:04 |
| buZz | ok | 12:04 |
| uvos | your adding || true to the restore cat | 12:04 |
| uvos | not the save cat | 12:04 |
| uvos | the check is on save | 12:04 |
| uvos | ah wait | 12:04 |
| uvos | no i see the problem | 12:04 |
| uvos | the script exits at line 21 | 12:05 |
| uvos | if the kernel cant give a value | 12:05 |
| uvos | on save | 12:05 |
| buZz | exactly | 12:05 |
| uvos | thats how you end up with a emtpy file | 12:05 |
| uvos | sorry im slow | 12:05 |
| uvos | yeah | 12:05 |
| uvos | ok | 12:05 |
| uvos | this is a real problem | 12:05 |
| buZz | \o yay | 12:05 |
| buZz | :P | 12:05 |
| uvos | um dose /sbin/openrc-run support the option to ingore all return values? | 12:06 |
| buZz | why are we using cat anyway, why not just read the file into a var, check the var, and then output it? | 12:06 |
| uvos | it grew that way since it was just a cat at first | 12:06 |
| uvos | and nothing else | 12:06 |
| uvos | but yeah | 12:07 |
| buZz | i think we can afford the couple clockcycles :P | 12:07 |
| buZz | oh, -20% , not 20% | 12:09 |
| buZz | wait, is 'sudo poweroff' perhaps a 'non-decent shutdown' vs hildon's 'switch off' button ? | 14:17 |
| buZz | or 'sudo reboot' ? | 14:17 |
| uvos | no | 14:27 |
| uvos | but untill recently d4 would crash often on shutdown | 14:27 |
| buZz | hmm ok, but 'hildon menu -> switch off' takes quite a long time, vs 'sudo reboot' or 'sudo poweroff' | 15:42 |
| buZz | always felt to me that it was doing something special | 15:42 |
| uvos | not really | 15:42 |
| uvos | the difference is jus a dbus signal | 15:43 |
| freemangordon | that's the issue that was fixed recently | 15:43 |
| buZz | ah, nice freemangordon ! | 15:43 |
| freemangordon | with serial oopsing on shutdown | 15:43 |
| uvos | freemangordon: im not sure its fixed | 15:43 |
| buZz | or which issue do you mean, the time difference? | 15:43 |
| buZz | oh ok | 15:43 |
| uvos | freemangordon: im mean thats fixed | 15:43 |
| uvos | freemangordon: but my device sill hanged yesterday during shutdown | 15:43 |
| freemangordon | yes, but that's another issue I think | 15:43 |
| uvos | right | 15:43 |
| uvos | but buZz might be encountering this | 15:44 |
| buZz | not sure, it seems to shutdown totally fine, just takes longer | 15:44 |
| buZz | would that be the symptom? | 15:44 |
| uvos | a hang | 15:45 |
| uvos | im pretty sure its permanent or at least very long | 15:46 |
| buZz | lemme try measuring the difference i'm seeing | 15:48 |
| buZz | 'sudo poweroff' = 49 seconds | 15:50 |
| buZz | *booting back up* :) | 15:50 |
| uvos | sounds way to long for a regular shutdown | 15:50 |
| uvos | something is delaying at the least | 15:51 |
| uvos | maybe shutdown with serial attached | 15:51 |
| buZz | this was just with a usb charger attached (and usb doctor so i can see when shutdown finishes) | 15:51 |
| buZz | i still havent made 'the' serial cable yet | 15:51 |
| buZz | but no doubt something could be delaying it | 15:52 |
| buZz | ah, almost booted back up | 15:52 |
| buZz | btw , 49 seconds for a poweroff doesnt feel that bad to me | 15:52 |
| uvos | well debian shutsdown in like 5sec | 15:54 |
| uvos | leste dose take a bit longer | 15:54 |
| buZz | oh sure, if you just kill -9 all processes? | 15:54 |
| uvos | but not nearly a minute here | 15:54 |
| uvos | buZz: ? | 15:54 |
| uvos | just a regular shutdown | 15:54 |
| buZz | well, normally you run services on a debian? | 15:54 |
| uvos | yes | 15:54 |
| buZz | and shutdown would let those services shutoff? | 15:55 |
| uvos | yes | 15:55 |
| uvos | its regular systemd shutdown | 15:55 |
| uvos | it wait | 15:55 |
| uvos | s | 15:55 |
| buZz | systemd? :D | 15:55 |
| buZz | i dont think 5 seconds is realistic for even shutting down hildon | 15:55 |
| uvos | systemd is mutch faster at everyting ofc | 15:55 |
| uvos | than openrc | 15:55 |
| buZz | yes, thats why its 2M lines of code | 15:55 |
| uvos | due to the hevy usage of scripts | 15:55 |
| freemangordon | well, we have parallel boot disabled | 15:55 |
| uvos | buZz: thats irrelivant | 15:55 |
| freemangordon | we can enable it | 15:55 |
| freemangordon | and it will be faster | 15:56 |
| uvos | the thing is that systemd implements everything in c | 15:56 |
| buZz | either way, lets see how long 'hildon switchoff' takes, that was my point | 15:56 |
| uvos | that is implemented in shell in openrc | 15:56 |
| buZz | not rust? | 15:56 |
| uvos | so it just has an advantage there wrt speed | 15:56 |
| buZz | or C#? | 15:56 |
| uvos | this is mindless systemd hate | 15:56 |
| uvos | if you want to critisize systemd pick something real | 15:56 |
| uvos | there are real issues | 15:56 |
| uvos | anyhow | 15:57 |
| uvos | i was just descibing one reason why debian might be faster than leste | 15:57 |
| buZz | ? i wasnt talking about systemd , you were | 15:57 |
| buZz | either way, hildon switchoff takes exactly as long as sudo poweroff :) either it was the serial issue, or something else | 15:58 |
| uvos | not suppising | 15:58 |
| buZz | tnx for letting me measure | 15:58 |
| uvos | the only difference is hildon power off signals mce to turn of the display | 15:58 |
| uvos | (and changes dsme state) | 15:59 |
| uvos | (but i dont think this has a real effect) | 15:59 |
| buZz | the dsme state? yeah no clue | 16:01 |
| buZz | freemangordon: would parallel boot also do parallel shutdown? | 16:10 |
| freemangordon | I guess so | 16:10 |
| freemangordon | ok, XV works over HDMI too :) | 17:51 |
| Wizzup | sweet | 17:51 |
| freemangordon | mhm | 17:51 |
| uvos | https://github.com/robclark/libdce next i guess | 17:52 |
| freemangordon | I pushed 2 fixes recently, now it should be 100% stable | 17:52 |
| uvos | plenty-o-work | 17:52 |
| uvos | and the implementaion is bad | 17:52 |
| uvos | (just over remoteproc vs real kernel driver) | 17:52 |
| freemangordon | I already have (had) lots of experience with gst-dsp | 17:52 |
| uvos | ok | 17:52 |
| uvos | but rember its very different on omap4 | 17:53 |
| uvos | since the cpu can acess the dsp at all | 17:53 |
| uvos | *cant | 17:53 |
| freemangordon | the same on omap3 | 17:53 |
| freemangordon | uvos: fyi https://talk.maemo.org/showthread.php?t=77695 | 17:54 |
| freemangordon | but year, remoteproc is new to me | 17:55 |
| freemangordon | *yeah | 17:55 |
| uvos | on omap3 the dsp is connected to the main cpu cluster | 17:55 |
| uvos | on omap4 its connected to the other cpu cluster | 17:55 |
| uvos | ie the cortex m3 one | 17:55 |
| uvos | that dosent exist on omap3 | 17:55 |
| uvos | you have to communicate with the fw on the m3 cluster to do anything with the dsp | 17:56 |
| freemangordon | I see | 17:56 |
| freemangordon | well, that makes it a bit harder I guess | 17:56 |
| uvos | so all the code to do this is floating around | 17:56 |
| uvos | the driver was once in stageing iirc | 17:56 |
| uvos | but was removed | 17:57 |
| freemangordon | which driver? | 17:57 |
| freemangordon | tidspbridge? | 17:57 |
| uvos | remoteproc bridge driver | 17:57 |
| freemangordon | ah | 17:57 |
| uvos | for ducati | 17:57 |
| uvos | (the m3 cpu cluster) | 17:57 |
| freemangordon | I dont; think DSP is something I will play with soon though | 17:58 |
| freemangordon | we have too many other issues | 17:58 |
| uvos | sure | 17:58 |
| freemangordon | also, I think we would like to implement va-api if anythink | 17:58 |
| freemangordon | *anything | 17:58 |
| uvos | yes ofc | 17:58 |
| * freemangordon is about to try XV on n900 :) | 17:59 | |
| freemangordon | crashes there, most-probably difference in sgx structure | 18:31 |
| freemangordon | yeah, sgx transfer structure is smaller there | 18:40 |
| buZz | Wizzup: ooo https://android.googlesource.com/device/sample/+/master/etc/apns-full-conf.xml | 22:13 |
| buZz | ah, nevermind, its not new enough :P | 22:13 |
| freemangordon | ok, now XV works on both d4 and n900 :) | 22:28 |
| Wizzup | nice | 22:28 |
| freemangordon | yep | 22:28 |
| norayr | shell i update? | 22:28 |
| freemangordon | tomorrow will try to find ofono bugs that uvos has reported and then will try to implement HW compositing | 22:28 |
| freemangordon | norayr: yep, why not | 22:29 |
| buZz | xv seems to work well in mpv :) | 23:44 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!