<Wizzup>
(not the sending, but the nokia references)
<buZz>
hmhm, yeah like in the appmanager
<Wizzup>
right
<Wizzup>
actually this could just be fixed in weblate now
uvos has joined #maemo-leste
<sunshavi>
Wizzup: thx for the answer
<sunshavi>
nice pictures
<tmlind>
freemangordon: so i tested your patched mesa finally, glmark2-es2-wayland still causes sgx lockup oops
<uvos>
Wizzup: "hm I think having the battery guard without charge mode is quite tricky" ???
<uvos>
makes no sense to me battery guard IS charge mode
<uvos>
Wizzup: "uvos: I *think* it resets my device at like 35% battery" it powers the device off if it stops charging for more than 5 seconds
<uvos>
Wizzup: this never happens to me on my main charger but when connected to my laptop cpcap can jus stop charging for no reason
<uvos>
this causes a reboot because then the device will shut off as its not charging anymore
<uvos>
and then after some time mbm will trigger a boot again because the device is charging again.
<uvos>
this really is just a bug in the mapphone kernel unrelated to charge-mode
<uvos>
Wizzup: "hm now it says 2% charging, makes no sense" if the device is uncallibrated (very likely when entering charge-mode on d4) it just uses what the kernel reports as a voltage and current and estimates the charge state
<uvos>
unfortionatly this is wildy unaccurate
<uvos>
again this is more down to the fact that battery callibration dosent really work right on d4 (we dont save the charge counter becasue we lack nvram)
<Wizzup>
hi
<Wizzup>
what I meant was that my device was powered off when it wasn't really depleted, at least percentage wise, it wasn't being charged at the time, but yeah, later on I did try to charge it and I thought that was happening
<uvos>
Wizzup: cant parse
<uvos>
a more detailed desctiption of behavior please
<uvos>
freemangordon: so i dont see what the problem is with modesetting with your glamor replacement.
<tmlind>
uvos: would be nice to save the charge_full value into some cpcap scratch register for reboot, probably also a timestamp must be saved
<uvos>
tmlind: yeah
<uvos>
freemangordon: it tears, thats more or less unavoidable in x
<uvos>
freemangordon: its slow in rotation
<uvos>
freemangordon: well thats not really its department drm should expose accelerated rotation and modesetting should be using it
<uvos>
freemangordon: if its not working figureing out why would make more sense than to hack pvr2d acclerated rotation into a ddx
<uvos>
freemangordon: maybe look at wlroots it rotates fast
<uvos>
Wizzup: regaring the sphone problem
<tmlind>
uvos: i recall also with weston there is not a huge difference in fps in landscape compared to portrait mode, only tested looking at the es2gears output so not accurate
<uvos>
Wizzup: i just tryied repoducing that
<uvos>
tmlind: its "fine" for me in sway
<uvos>
tmlind: its a bit slower but not massively slow
<tmlind>
agreed, yeah it's just fine for me too
<uvos>
es2gears is a great test for this btw
<uvos>
it dose little work besides fliping the buffers
<tmlind>
ok
<uvos>
so its a test of buffer flipping perfomance :)
<uvos>
Wizzup: so cant repoduce the sphone problem atm
<Wizzup>
ok
<uvos>
Wizzup: i called myself
<Wizzup>
sorry, I will try to catch up momentarily
<uvos>
Wizzup: and hung up on the remote side
<Wizzup>
sphone also said it was 'not responding'
<uvos>
and the d4 stoped rinnging as expected
<uvos>
oh ok
<uvos>
hmm
<Wizzup>
yeah
<Wizzup>
it's ok, I'll debug later
<uvos>
sure
<Wizzup>
I was outside in the park showing my parents the device, hehe
<Wizzup>
so wasn't really able to debug
<uvos>
upps :P
<uvos>
ok can you still repo?
<Wizzup>
I can try later tonight
<Wizzup>
let me read up
<uvos>
ok ill do a relese of the sphone version in the repo atm
<uvos>
since thats what i use (and fixes the ui issues)
<Wizzup>
cool
<Wizzup>
looked like pavel was interested too
<Wizzup>
and a user filed a bug report about the headphones not working for calls :P
<uvos>
heh
<Wizzup>
when/if should we use sphone to non-devel? maybe just not yet, right
<uvos>
not yet
<Wizzup>
ok
<Wizzup>
I started porting yappari, it'll be quite some work
<Wizzup>
but made a start at least
<uvos>
not even considering how green my new sphone backend code is, calling needs to work right on some defice first
<uvos>
kernel wise
<Wizzup>
right
<Wizzup>
we actually don't have -devel documented anywhere, which is perhaps a bit silly
<uvos>
that is silly
<Wizzup>
yeah, ok
System_Error has quit [Ping timeout: 276 seconds]
<freemangordon>
tmlind: does glmark2-es2-wayland oopses the kernel for you?
<freemangordon>
uvos: keep in mind I am using kernel with latest tmlind's patches
<freemangordon>
not that I tried WL though
<freemangordon>
uvos: how did you test modesetting performance?
<freemangordon>
I mean - do you use pathced glamor?
<freemangordon>
*patched
<uvos>
freemangordon: ?
<uvos>
freemangordon: i did not test modesetting performance
<freemangordon>
"(21,54,14) uvos: freemangordon: so i dont see what the problem is with modesetting with your glamor replacement."
<freemangordon>
there are lots of problems
<uvos>
right that was more of a question
<freemangordon>
ah, ok
<uvos>
what is the problem rn?
<uvos>
sry that was unclearly worded
<uvos>
so you reported rotation is slow and tearing
<uvos>
what else?
<uvos>
thats what i wanted to say
<freemangordon>
not only the rotation, on n900 rendering is slow
<freemangordon>
even in landscape
<freemangordon>
with compositing that is
<uvos>
freemangordon: ok
<freemangordon>
this can be fixed
<freemangordon>
or at least optimized
<uvos>
ok and rotation needs to be solved in omapdrm if possible
<uvos>
omap4 should expose tiler as acclerated rotation
<uvos>
and on ompa3 im not sure
<freemangordon>
but, if bad rotated performance can't be solved, I don;t see a point in continuing in that direction
<freemangordon>
n900 does not have a tiler
<freemangordon>
omap3 that is
<freemangordon>
also, 16bpp does not work in modesetting
<uvos>
why not?
<freemangordon>
no idea
<uvos>
it should work according to docs
<uvos>
16bpp is unusable anyhow
<freemangordon>
well, es2gears work, but not hildon-desktop
<uvos>
since its really slow with clients
<uvos>
some clients dont work too
<freemangordon>
not maemo clients
<freemangordon>
they will have to be fixed
<uvos>
no its just over with that
<freemangordon>
we gain nothing from 24 bpp
<freemangordon>
says who?
<freemangordon>
uvos: please, lets not go into that
<freemangordon>
we have low resources devices which will benefit a lot of reducing the needed bus bandwidth twice
<freemangordon>
*lot from
<freemangordon>
esp n900
<freemangordon>
but, 16bpp is a small problem
<freemangordon>
rotation is major one IMO
<freemangordon>
in general - MS/glamor is created with desktop/opengl in mind
<freemangordon>
at least that's my understanding
<freemangordon>
uvos: oh, BTW, did you pull the latest pvr mesa?
<uvos>
freemangordon: not sure what is latest
<uvos>
why?
<freemangordon>
because I pushed a fix for WL segfaulting