dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
<freemangordon>
uvos: mpv somehow succeeds to break gpu playback
<freemangordon>
after several attempts, fullscreen xv renders with 2 fps, but that happens only after mpv was used
<freemangordon>
also, sometimes when mpv is switched to fullscreen, with gpu vo, the video is misrendered (it looks like wrong pitch is assumed)
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
<freemangordon>
ok, no idea what mpv is doing, but it uses 30-40% more CPU than mplayer, no matter xv or gpu vo
<freemangordon>
mplayer with xv is capable of playing even big_buck_bunny_720p_h264.mov with just a few frames dropped
pere has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
xmn has quit [Read error: Connection reset by peer]
xmn has joined #maemo-leste
akossh has joined #maemo-leste
<uvos>
freemangordon: iths was -vo vs -vo gpu
<uvos>
so xv is accellerated via gles in your ddx?
xmn has quit [Ping timeout: 260 seconds]
_uvos_ has joined #maemo-leste
<_uvos_>
ofc -vo x11 is mutch slower
_uvos_ has quit [Ping timeout: 246 seconds]
<freemangordon>
uvos: well, it is not gles, but through gpu
<freemangordon>
basically bot end up in shaders
<freemangordon>
*both
<freemangordon>
I guess IMG/TI shaders are better optimized than generic ones in mpv
norayr has left #maemo-leste [Error from remote client]
<freemangordon>
uvos: as I said, compare xv vs gpu on big_buck_bunny_480p_h264.mov
<freemangordon>
with gpu it drops frames like crazy
mglbg[m] has quit [Quit: You have been kicked for being idle]
norayr has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
<uvos>
ok
<uvos>
i dont really see why -vo gpu must be slower, but no matter
<uvos>
anyhow did you see the ofono logs?
<freemangordon>
no, will look at them later
<uvos>
ok
<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)
akossh has quit [Read error: Connection reset by peer]
norayr has left #maemo-leste [Disconnected: Replaced by new connection]
norayr has joined #maemo-leste
<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
<buZz>
uvos: chromium seems hw accelerated
<buZz>
or its just magically very fast
<freemangordon>
it is not
<buZz>
the latter then :D
<freemangordon>
yes, it is fast, but not HW accelerated
<freemangordon>
it does not support gles2 AFAIK
<uvos>
i think it was dropped
<uvos>
but in deb 10 it probubly still dose
<buZz>
probably does upstream but devuan/debian prefers to not compile it? :)
<uvos>
anyhow its not hw accelerated
<freemangordon>
:nod:
<uvos>
but yeah both ff and chomeium do fairly well with sw rendering
<uvos>
to my suprise
<freemangordon>
I hope this will get better when I accelerate compositing
<buZz>
what changes about battery calibration btw? i cant seem to get it back
<buZz>
changed*
<freemangordon>
this will release more CPU for them to render
<uvos>
freemangordon: well without hildon it is faster still yes
<uvos>
everything is
<buZz>
not debugging maemo or hildon issues, uvos :)
<freemangordon>
yeah, but once we have aHW compositing, the difference should become minimal
<uvos>
right
<uvos>
that was my point hw composting should help
<uvos>
since no compositing dose
<freemangordon>
XV was a general rehearsal for that
<freemangordon>
because it uses SGXQueryTransfer function, that is not part of the public API
<freemangordon>
and I had to RE a pile of structures
<freemangordon>
good news is that some of TI SGX SDKs come with debug symbols
<buZz>
weird, my /var/lib/droid4-battery-calibration/charge_full is just empty :(
<freemangordon>
so it is not *that* hard
<uvos>
thats what qwebengine fails at btw
<uvos>
probubly assumes an extension we dont have
<freemangordon>
yeah
<freemangordon>
uvos: btw mpv crashes GPU with 720p bunny
<uvos>
buZz: we delete it if the battery goes below -20% full
<freemangordon>
and I am sure the issue is with mpv
<uvos>
or above 120% full
<uvos>
that can happen for various reasons
<uvos>
one being that your spike triggers low prematurely
<uvos>
and then you discharge further untill the battery is way below "low"
<uvos>
the logic is there because we have no idea when the user inserts a new battery, so the values are sanity checked
<buZz>
uvos: this changed recently?
<uvos>
no
<buZz>
weird, never seen before
<uvos>
i added this to the kernel >1 year ago
akossh has joined #maemo-leste
<buZz>
feels pretty unfriendly
<uvos>
no, why should the kernel keep callibration thats for sure totaly wrong?
<buZz>
seems the only user that ever swaps batteries around is you :P
<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
<uvos>
where are you putting the value?
<buZz>
lol where do you think :P
<uvos>
idk
<uvos>
changeing var/lib/droid4-bat-cal/charge_full has no effect
<freemangordon>
there is a file in /usr/share
<freemangordon>
does it not?
<uvos>
no
<freemangordon>
if you stop the service?
<uvos>
then sure
<freemangordon>
well...
<uvos>
but the right way is tell the kenrel
<uvos>
by putting the value into the file in sys
<freemangordon>
ah
<uvos>
the value from the kernel then gets saved as normal
<buZz>
uvos: i changed /sys/class/power_supply/battery/charge_full obviously
<uvos>
on shutdown
<uvos>
the shtudown also needs to be clean ofc
<buZz>
and the init script didnt save it
<uvos>
thats wierd
<buZz>
it was a clean shutdown, battery is ~40%
<uvos>
the script is failing on your system then
<uvos>
for some reason
<uvos>
try running it by hand
<uvos>
check serial output on shutdown
<buZz>
hence me asking what changed
<uvos>
nothing
<uvos>
all of this is very old
<buZz>
ah, it didnt get started
<buZz>
'cat write error invalid argument' on starting, great
<uvos>
thats normal
<uvos>
if you have no var/lib/droid4-bat-cal/charge_full
<buZz>
its preventing the init script to execute
<uvos>
right there should be a ignored return value there
<buZz>
thus not able to -stop- the init script later
<uvos>
the install sctipt touches var/lib/droid4-bat-cal/charge_full
<uvos>
so its not really a problem
<buZz>
thats wrong then
<buZz>
as the emptystring inside prevents the init script from working
<uvos>
ok
norayr has left #maemo-leste [Error from remote client]
<buZz>
alright, putting "1000000" into /var/lib/droid4-bat-cal/cha-fu and starting/stopping the script works
<uvos>
buZz: if its missing could you add || true
<buZz>
its?
<freemangordon>
buZz: please make a PR for that too
<uvos>
the return value of the cat line on startup should be ignored
<uvos>
if its not
<buZz>
the file was there, it was empty , leading to the 'cat' failing and the whole init script stopping