<Wizzup>
freemangordon: uvos: parazyd: I think it's time to try to figure out the components thing for our repos
<Wizzup>
I'm adding droid3 now, and I am not sure if we -really- want a droid3 component
<Wizzup>
like I am not sure if we really want a bionic component as well (even though we have it)
<bencoh>
I guess it's nice, but I wonder how many users we would have for those
<bencoh>
(not much I suppose?)
<bencoh>
not many*
<Wizzup>
well the point is mostly that I don't think we need the separate components
<Wizzup>
or if we do have them, we will also want some shared component(s)
<parazyd>
We should have a component for every device IMO.
<Wizzup>
like - where do the powervr packages go, now that they work for the n900,droid3,droid4,bionic and potentially more
<Wizzup>
can't be mapphone
<Wizzup>
so then what? powervr?
<parazyd>
And then have common components that can be shared between devices.
<Wizzup>
and how do those make it to the apt.sources
<parazyd>
Wizzup: I'd just rework the entire repos
<parazyd>
Just inform users to change it manually. It's not a big deal.
<parazyd>
And it's a one-time-thing.
<parazyd>
Otherwise we'll be constrained by providing some seamless update and hacking sources.list
<Wizzup>
I don't think we really have a way to reach out users mostly
<parazyd>
So in the end we won't be satisfied with the result
<Wizzup>
well, yes, or we just move for example powervr to main component
<uvos>
Wizzup: we want a hierachy
<Wizzup>
and then we don't need to change anything
<uvos>
so a device componant we want for sure
<parazyd>
main -> omap -> mapphone -> droid4
<parazyd>
main -> omap -> n900
<parazyd>
etc.
<Wizzup>
powervr isn't even omap specific
<uvos>
Wizzup: yes it is
<Wizzup>
I don't think so, we can easily add another arch from the ddk there
<Wizzup>
there is at least some exynos
<Wizzup>
if we put that in main now, we don't need to make these changes either
<uvos>
no
<uvos>
the um ddk needs to be the exact version used in the soc
<uvos>
it checks everything about the km module
<Wizzup>
the n900 was never supposed to be on this version
<Wizzup>
uvos: so, we can just add more to sgx-ddk-um ?
<uvos>
more blobs?
<uvos>
sure
<Wizzup>
for other tarets
<uvos>
sure but that dosent change that these blob packages are omap specific
<Wizzup>
the *files* currently in the package, yes
<uvos>
i think something like this:
<Wizzup>
but that won't have to stay that way
<Wizzup>
and then we would have to change the component again
<uvos>
leste->soc_family->soc->(optional device family)->device makes the most sense
<uvos>
i think
<uvos>
Wizzup: i not sure what you mean
<uvos>
Wizzup: if we add some other pvr soc, you need to add new blobs and the repo needs to build another pacakge for this soc no?
<uvos>
then that new soc pvr package can go into the soc componant
<uvos>
im not sure where the problem is
<Wizzup>
uvos: I am saying that (1) sgx-ddk-um can be used for things other than omap if we add more blob files (2) if we put in leste/main we don't need to f*ck around for n900 and other devices, manually having users change the components
<Wizzup>
so the problem is (2)
<uvos>
how would you have multiple versions of the same libs in the same package?
<uvos>
i dont follow
<uvos>
or do you want to have omap3-ddk-um and omap4-ddk-um and whatever-ddk-um packages in main?
<uvos>
Wizzup: yeah so that works ok for the blobs
<Wizzup>
see sgx-ddk-um-$arch there? I think we can just add more, potentially non0-omap ones
<Wizzup>
ok
<uvos>
but it falls apart if its something that lots of stuff depends on, yeah you could have lots of "provides some virtual package" but really thats way more of a mess than haveing a sane tree of componants
<Wizzup>
can we put a package in multiple components? I guess not
<Wizzup>
btw I think the hierarchy is great idea
<Wizzup>
I am just thinking about how to make this work here and now without requiring people to mess around too much
<Wizzup>
for beowulf+1 we already decided we would rework it
<Wizzup>
(and we can decide on that structure now, too)
<uvos>
[12:27] <Wizzup> I'm adding droid3 now, and I am not sure if we -really- want a droid3 component
<uvos>
not sure what this is about then
<Wizzup>
I changed my mind about it
<uvos>
ok
<Wizzup>
:)
<Wizzup>
so it's ok to put sgx-ddk-um in leste component?
<Wizzup>
and also the xf86-video-omap one
<uvos>
yeah sure as a temporary soultion
<Wizzup>
and then maybe we draft up a ticket on the components on the github issue tracker
<uvos>
prints sphone: adding window 0x5598200e15f0, text_view 0x5598200e87d0
<uvos>
sphone: removeing widget 0x5598200e15f0, data 0x5598201c25c0
<uvos>
no sure why data isent passed
vectis has quit [Ping timeout: 268 seconds]
pere has quit [Ping timeout: 264 seconds]
<Wizzup>
will check in a few hrs
pere has joined #maemo-leste
<uvos>
ok
<uvos>
in the mean time sphone now has a commtest module, its a communications backend that mocks calles and sutch
<uvos>
any sms you send to anyone it will echo back at you. if you call someone it will pick up after a time and then call you back once you hangup etc
<uvos>
any sms you send to anyone it will echo back at you. if you call someone it will pick up after a time and then call you back once you hangup etc
<bencoh>
fun
<sicelo>
call you from? :-/
<bencoh>
sicelo: *x-files theme*
* sicelo
doesn't know x-files, besides the name
<bencoh>
oh, nevermind then, I was just joking :)
pere has quit [Ping timeout: 252 seconds]
<uvos>
sicelo: nowhere the point is just that sphone goes though the motions of getting a call, like ringing, setting up audio routing, negotating machine state with mce, loging the event to rtcom-eventlogger, asking evoltion who the hell this is who is calling, and so on
<uvos>
without constanly haveing to call yourself :P
<sicelo>
ok
belcher has quit [Ping timeout: 268 seconds]
belcher has joined #maemo-leste
_inky has quit [Quit: Leaving.]
[TheBug] has quit [Ping timeout: 265 seconds]
[TheBug] has joined #maemo-leste
inky has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
cockroach has joined #maemo-leste
<freemangordon>
uvos: did you see Xorg logs of DDK 1.9 Wizzup provided?
<freemangordon>
it does triple-buffering ;)
<uvos>
yeah i see
<freemangordon>
so, I guess I shall teach MESA (pvr dri?) to request 3 buffers
<uvos>
sure
<Wizzup>
uvos: still want me to look at the code you linked?
<uvos>
Wizzup: yeah sure
<uvos>
Wizzup: i must not undersand something about gtk
<uvos>
and then call/message someone using the commtest backend
<Wizzup>
ok, I'd like to do it after we have 5.15 for -devel and droid3 stuff in -devel, and I did a bit of TP stuff...
<Wizzup>
so maybe not tonight
<uvos>
Wizzup: no rush
<uvos>
btw
<uvos>
what happend to cloudgps?
<Wizzup>
also, if you could help, I would appreciate it if you can find the modem gpio setup or the i2c setup in the stock-dts.bin for x860, but I fear it might be non trivial
<Wizzup>
hm, what about it?
<uvos>
i apears to be missing in repo
<Wizzup>
really? hm
<uvos>
yeah i dont have it installed i cant apt install cloudgps and its not in ham either
<uvos>
(i had to remove it for the ddk upgrade)
<Wizzup>
it looks like it's not in the repo
<Wizzup>
I'll look at that in a bit
<Wizzup>
btw now you can apt dist-upgrade and it should just work
<Wizzup>
in case you missed that
<uvos>
yeah i did read taht
<Wizzup>
ok
<uvos>
but i had allready upgraded all devices manually
<uvos>
i can take a look at the dtb sure
<uvos>
that stuff is not in the dtb tho
<uvos>
its in the gpiomap or what its called
<Wizzup>
ah, right
<Wizzup>
you emailed me that script
<Wizzup>
uvos: cloudgps is avail in repos now
uvos has quit [Ping timeout: 252 seconds]
inky has quit [Remote host closed the connection]
inky has joined #maemo-leste
<freemangordon>
uvos: implementing 3-buffering was a matter of implementing SwapLimitValidate and calling DRI2SwapLimit
<freemangordon>
FPS increase to 53, which is sill not ok, but better than 40
<freemangordon>
I am going to push that, but please, have a look when you have some time
<bencoh>
3-buffering gives beter fps?
<freemangordon>
sure
<bencoh>
better*
<freemangordon>
that's the point of it
<bencoh>
is that because otherwise it waits for the frame to be pushed to screen before starting to render another one?
<freemangordon>
yes
<bencoh>
so basically we have a buffer for display and another one for rendering?
<freemangordon>
one to display, one waiting for vsync and one for rendering
<bencoh>
vsync from gpu you mean?
<freemangordon>
vsync as 'vertical blank' I mean :)
<freemangordon>
or 'vertical blanking period'
<bencoh>
yeah but ...
<freemangordon>
hmm?
<bencoh>
vertical blanking sync should be the "display" sync
<bencoh>
hence me asking if the one you referred to was from gpu
<freemangordon>
yes, 'display' sync
<freemangordon>
GPU has no idea of 'vsync'
<freemangordon>
bencoh: if we want tear-free, then we cannot render on the front buffer, obviously
<freemangordon>
in the same time, when back buffer is ready to be displayed, we wait for vblank
<freemangordon>
the time we wait for vblank, is 'wasted' GPU time, as there is not free buffer GPU can render on
<freemangordon>
thus the 3rd buffer
<freemangordon>
though I was hoping to hit at least 60fps, but seems there is some issue in omapdrm with page flips
<freemangordon>
it should not take 6 ms to queue a flip
<freemangordon>
tmlind_: ^^^ any idea?
uvos has joined #maemo-leste
<uvos>
that only happens when the render time is greater than the display vblank period ofc
<freemangordon>
yeah
<uvos>
btw can we drop to double buffering when vblank_mode is 0?
<uvos>
ie no vsync?
<freemangordon>
not sure
<uvos>
ok its not a big deal
<ruleh>
does it even react to vblank_mode ?
<uvos>
but some games might want this
<uvos>
ruleh: we control the bit that would have to react
<freemangordon>
please, whoever might have an idea:
<ruleh>
is there a way to limit the fps of hildo-desktop?
<uvos>
not atm
<uvos>
but yeah
<uvos>
we should add
<Wizzup>
why would we want to, just curious?
<uvos>
Wizzup: battery life ofc
<uvos>
esp. on more powerfull hardware
<Wizzup>
right
<Wizzup>
I mean if the gpu is clocked high all the time when it's active, does it matter?
<uvos>
no need to spin up 32cores and 4 gpus on some wizbang 2022 soc to render hildon at 500fps
<uvos>
yeah
<uvos>
Wizzup: no on our current hardware it dosent matter mutch since pm is broken while the display is on
<uvos>
ofc the cpu gets to sleep a bit more if you limit it lower
<uvos>
but thats not the point
<uvos>
also the pinephone also exists
<Wizzup>
right
<Wizzup>
and a lot more hw to come :p
<freemangordon>
I think it doesn't make sense
<freemangordon>
as h-d is vsync-ed either ways
<uvos>
sure it dose. even with vsync
<uvos>
you can have 240hz pannels these days
<freemangordon>
well, yeah
<uvos>
really you want the user to be able to choose 120, 60 or even 30 fps caps
<uvos>
depending on his prioritys
<ruleh>
is the fps counter of CLUTTER_SHOW_FPS always accurate?
<freemangordon>
should be
<uvos>
its at least wrong in the sense that sometimes pushing the frame to the pannel fails on d4
<uvos>
which is something you can see as stuttering thats absent on bionic for instance.
<ruleh>
hmm... it shows up to 80fps when scrolling but it certainly doesn't feel like 80
<freemangordon>
on d4 with ddk 1.17?
<ruleh>
yeah
<freemangordon>
hmm, how's that possible?
<freemangordon>
I can't get anything above 40 (with double-buffering)
<ruleh>
I think it is something in xf86-video-omap
<freemangordon>
you use the one in experimental?
<ruleh>
no
<freemangordon>
ah
<ruleh>
well kinda
<freemangordon>
don't understand
<ruleh>
I use af94325a24bc3a3f4f8ba89ff9cbbf2cd39d6652 with some patches
<uvos>
*** FPS: 91 ***
<uvos>
i get 91
<uvos>
(just checked)
<uvos>
so hmm
<uvos>
i AM on regular experiamental
<freemangordon>
hmm, hmmm
<uvos>
not sure why that is impossible freemangordon
<uvos>
if it renders in less than frametime
<freemangordon>
sure, but here it renders 2 times slower
<uvos>
freemangordon: oh if i scrol to a hildon home screen with lots of icons
<uvos>
it drops abrouply to 40
<uvos>
this seams to check out
<freemangordon>
my desktop is empty
<uvos>
hmm
<uvos>
thats wierd
<freemangordon>
yeah
<freemangordon>
what I am missing?
<uvos>
what do you get with es2gears showing?
<freemangordon>
in h-d?
<uvos>
to eliminate differences in hildon home
<uvos>
yeah
<uvos>
run es2gears in forground
<freemangordon>
sec, to disable 3-buffer
<uvos>
and record hildon fps
<freemangordon>
hmm, wait
<freemangordon>
I am hittin 66 now
<freemangordon>
with 3-buffer that is
<freemangordon>
uvos: how do you start h-d?
<uvos>
about the same here with stock
<uvos>
freemangordon: for this expierament just hildon-desktop in ssh
<freemangordon>
ok
<freemangordon>
hmm, just hit 83 fps
<freemangordon>
this is crazy :(
<freemangordon>
268 frames in 5.0 seconds = 53.461 FPS
<ruleh>
meanwhile I get max 39fps with xorg-video-omap 0.5.0+2m7.4 when desktop scrolling
<uvos>
ruleh: empty desktop?
<ruleh>
yeah
<uvos>
have any windows open?
<ruleh>
gears is happy at 69 though
<uvos>
if i have gears open i get max 40 fps on desktop
<uvos>
that makes sense ofc
<uvos>
gpu is busy
<freemangordon>
I get 53 fith 3-buffer
<freemangordon>
lemme disable it
<ruleh>
the 39 is when nothing else is running
<uvos>
wierd
<freemangordon>
yes
<ruleh>
interestingly gears makes hildon fps jump up to 43
<uvos>
so i get 90 on empty desktop 40 on full desktop of with gears or firefox-esr open, gears showing makes it 60 fps in hildon and 70 in gears own counter
<uvos>
s/of/or
<freemangordon>
hmm, seems this fps I get is with driver from -experimentl
<freemangordon>
I mean - I just upgraded
<freemangordon>
but not with the one I complie here
<uvos>
optimiziation flags different?
<freemangordon>
in ddx?
<freemangordon>
how's that supposed to matter?
<uvos>
in mesa, but really mesa should be doing no work
<uvos>
freemangordon: no idea grasping at straws
<freemangordon>
yeah
<uvos>
is your device using the same ti-ddk-um commit?
<uvos>
-next vs latest stable ddk release?
<freemangordon>
hmm, I just restarted Xorg and fps dropped to 40
<freemangordon>
wth?
<uvos>
hmm should scrolling on hildon-desktop not also depend on how often xorg desicdes to update input events
<freemangordon>
sure
<uvos>
so a better test would be to change transition.ini
<uvos>
to make some animation take really long
<uvos>
and base fps off of the
<uvos>
animation
<uvos>
[launcher_in]
<uvos>
duration = 2500
<uvos>
*** FPS: 55 ***
<freemangordon>
with 3-buffer fps is 53
<freemangordon>
hmm, I am doing something wrong
<freemangordon>
but don't understand what
<freemangordon>
uvos: with 2-buffer fps is ~30
<ruleh>
hmm restarting xorg disconnects wifi. is it supposed to do that?
<uvos>
freemangordon: wait a minute
<freemangordon>
ruleh: no
<ruleh>
is there a way to find out why it's doing that?
<ruleh>
hmm it didn't do it this time, maybe I messed something up before
<uvos>
hm ok
<uvos>
wasent it
<uvos>
(i had a powervr.ini)
<freemangordon>
oh
<freemangordon>
me too
<freemangordon>
didn;t chage anything
<uvos>
yeah same here
<freemangordon>
but I'll reboot, just in case
<uvos>
really no idea why yours underperformes
<freemangordon>
what is weird is that it was hitting 83 fps
<freemangordon>
until I restarted Xorg
<uvos>
but i have to second ruleh here in that it dosent look like 80fps
<freemangordon>
I would say omapdrm misbehaves
<uvos>
you can also clearly see tearing btw
<freemangordon>
mhm
<freemangordon>
which is impossible in theory :D
<ruleh>
yeah it tears quite a bit
<freemangordon>
Wizzup: is it safe to dist-upgrade n900?
inky has quit [Ping timeout: 252 seconds]
Wikiwide_ has joined #maemo-leste
Wikiwide_ is now known as Wikiwide
<Wizzup>
freemangordon: no
<freemangordon>
ok
<Wizzup>
freemangordon: well, wait, on what repos
<freemangordon>
experimental :)
<Wizzup>
if you have your own kernel and u-boot it should be mostly
<freemangordon>
ok
<Wizzup>
(if I dist upgrade mine it will break since it will downgrade droid4-linux on my n900 and make it not boot)
<Wizzup>
you should be ok
<freemangordon>
ok
<Wizzup>
uvos: shall I build it now?
<uvos>
Wizzup: not sure anymore
<uvos>
Wizzup: its behavior dosent add up
<freemangordon>
hmm, it seems something is tottaly wring in DDX in regards to page flip
<freemangordon>
*wrong
panzeroceania has quit [Read error: Connection reset by peer]
<freemangordon>
enabling 3-buffer on n900 increased fps to 25, from 21
panzeroceania has joined #maemo-leste
devrtz[m] has quit [Ping timeout: 265 seconds]
inky has joined #maemo-leste
devrtz[m] has joined #maemo-leste
<freemangordon>
hmm, maybe tearing is because I invalidate framebuffer too often
<ruleh>
do you mean with drmmode_flush_scanout?
<freemangordon>
mhm
<ruleh>
I removed all those calls and it still tears
<freemangordon>
on d4?
<ruleh>
yeah
<freemangordon>
but, it does not update without that whn no compositing
<ruleh>
also reverted " use drmModeDirtyFB instead of drmModePageFlip to flush scanout changes" and added dirtyfb to the block handler or whatever that was called
<freemangordon>
how that helps?
<ruleh>
it makes the display update correctly but doesn't fix the tearing
<freemangordon>
why drmModeDirtyFB is not ok?
<ruleh>
since I called it from OMAPBlockHandler i felt that I didn't need it somewhere else
<ruleh>
It also seemed a bit more reliable there in case dri2 is disabled
<freemangordon>
hmm
<ruleh>
I think modesetting also calls it from a similar place