<tmlind>
interesting, so what's the minimal test case not working with chromeos mesa that is working with the ti blobs?
<tmlind>
not sure i've seen this issue with my use case
<tmlind>
freemangordon: hoping test/revert/fix the extra patches in droid4-pending-pvr-omapdrm-v5.15 branch today
<tmlind>
freemangordon: i can only test on d4 right now, if you can test the patch i sent at some point on n900 that would be great
<tmlind>
i only tested n900 so sgx loads and initializes
<freemangordon>
tmlind: ok, will do
<freemangordon>
the minimum test is glmark2-es2-drm
<freemangordon>
works with blobs, crashes SGX with chromeos
<tmlind>
ok
<tmlind>
crashes on d4 or also on n900?
<freemangordon>
only on d4
<tmlind>
ok
<freemangordon>
on n900 works perfect, giving glmar of 37
<freemangordon>
*glscore
<tmlind>
nice :)
uvos has joined #maemo-leste
<uvos>
freemangordon: did you run over how to use libebook while working on abook? specificly how do you get the default address book? old libebook has e_book_new_default_addressbook
<uvos>
but this is gone in newer versions
<uvos>
and you need to use e_book_client_connect(ESource *source)
<uvos>
no sure where the source is supposed to come from
<uvos>
something that points to eds somehow i gues
<freemangordon>
uvos: yes, sec
<freemangordon>
WTF? where did all the online libebook documentation go?
<freemangordon>
what's wrong with gnome/freedesktop guys?!?
<Wizzup>
so next time you find a dead link, just add 'developer-old.' before gnome.org
<freemangordon>
I simply cannot find any link
<freemangordon>
for example - search google for E_SOURCE_EXTENSION_ADDRESS_BOOK
<freemangordon>
or e_source_registry_new_sync
<freemangordon>
nothing!
<Wizzup>
freemangordon: what about the link I shared?
<freemangordon>
yes, but google knows nothing about it
<Wizzup>
I searhed for 'libebook-contacts documentation'
<freemangordon>
but, how do you know it is libebook-contacts?
<uvos>
yes this is excatly what i discoverd
<freemangordon>
the point is - a month or so ago it was enough to search for function name
<uvos>
even the link to documentation on gnome mainpage just goses to 404
<freemangordon>
not it is like those libs have never existed
<freemangordon>
uvos: :nod:
<freemangordon>
something weird is going on
<freemangordon>
*now it is like
belcher has quit [Ping timeout: 244 seconds]
<Wizzup>
well they always liked to break things every few years and reinvent it
<Wizzup>
probably just an accident with the docs
<Wizzup>
'they look prettier' 'but all the links are broken' 'oh, we will make it a new domain' 'the new domain is not visible in search engines' 'oh well'
<uvos>
the new documentation pages are way less usable too
<uvos>
eveything is closed by default
<uvos>
i cant even ctrl-f to find a symbol
<uvos>
freemangordon: btw e_book_* is depricated
<uvos>
freemangordon: replaced by e_book_client_*
<uvos>
according to headers
uvos has quit [Remote host closed the connection]
<freemangordon>
uvos: yes, it is
<freemangordon>
but...
belcher has joined #maemo-leste
<Wizzup>
better finish the RE before switching api eh :)
Pali has joined #maemo-leste
<tmlind>
ack i see segfault on d4 with glmark2-es2-drm
<freemangordon>
hmm
<freemangordon>
I don't see segfault but SGX HW recovery triggered
<freemangordon>
Wizzup: exactly :)
_uvos_ has joined #maemo-leste
<_uvos_>
sure just ensureing awarenis wrt deprication
<_uvos_>
sphone has some basic ebook support now :) shows contact names on incomeing calls and sutch
<_uvos_>
anyone here know sql querys well?
<_uvos_>
i could use some help (next week) with sphone-store
<sicelo>
Has its own db?
<_uvos_>
yeah for recent/missed calls/sms
<tmlind>
freemangordon: yeah you're right sgx hw recovery with glmark-es2-drm with chromeos mesa
_uvos__ has joined #maemo-leste
_uvos_ has quit [Ping timeout: 265 seconds]
<tmlind>
freemangordon: PVR_LINUX_MEM_AREA_USE_VMAP is no longer needed so reverting that one, seems it already got fixed somewhere in upstream, probably mainline linux
<freemangordon>
good
<freemangordon>
any difference?
<tmlind>
no, dropping PVR_LINUX_MEM_AREA_USE_VMAP does not seem to affect any of my test cases
<freemangordon>
:(
_uvos__ has quit [Ping timeout: 245 seconds]
<Wizzup>
uvos: I can help with bql
<tmlind>
freemangordon: ok pushed out updated droid4-pending-pvr-omapdrm-v5.15 with all the mystery patches reverted and the ocp patch applied
<Wizzup>
although we have osso rtcom for it, with sqlite format
<Wizzup>
could be a good db format maybe
<tmlind>
looks like reverting 33bc438d6d88 ("drm/omap: Fix page fault handling and flush what framebuffe wants flushed") causes almost constant trails on termite on sway at least on the left side of the lcd
<tmlind>
bbl
<Wizzup>
uvos: with sql
<tmlind>
heh termite is almost unusable with 33bc reverted.. some sgx flush or command mode lcd update is needed somewhere for sure
<tmlind>
is n900 updating the screen just fine or also showing old data on the lcd?
<freemangordon>
updates fine
<freemangordon>
actually it hangs without 33bc reverted :)
<tmlind>
ok, on droid4 hdmi seems to behave too so must be a command mode lcd issue
inky has joined #maemo-leste
<freemangordon>
mhm
<freemangordon>
I also have 'hangs' in glamor on d4
<freemangordon>
which do not happen on n900
<freemangordon>
vsync issue that is
<freemangordon>
as we already discussed back then - modesetting waits for vsyn to present next buffer, but it never comes
<freemangordon>
because there is no vsync
<tmlind>
i also see corrupt window titles on hdmi on droid4 with wlroots fyi
inky_ has quit [Ping timeout: 245 seconds]
<tmlind>
seems to be some wlroots issue
<tmlind>
freemangordon: if you have an idea where d4 needs the command mode update please let me know
<freemangordon>
tmlind: do you remember my idea for fake vsync back then?
<tmlind>
hmm no, we carry some patch for omapdrm right now for that though
<freemangordon>
lemme try to dig it
<tmlind>
ok
<freemangordon>
tmlind: "Re: xpresent/vsync and omapdrm", you're on CC
<freemangordon>
and then I hit 1.17 breakage on n900 and never sent this RFC patch :)
<tmlind>
heh ok
<freemangordon>
but, I think I described my idea pretty well, should be doable
<freemangordon>
or, we can do the same as WL and create a timer "if there is no vblank event in 20 ms, screw it and start presenting" in MS
<freemangordon>
but, this is really a nasty hack
<tmlind>
yeah event triggered variable refresh would be ideal
<freemangordon>
but, who triggers the event?
<tmlind>
right, no idea :)
<freemangordon>
I think this belongs to omapdrm
<tmlind>
seems like that's a whack a mole game for the triggering from various places
<freemangordon>
because the driver knows about details - is that a manual update display, is there TF interrupt, etc
<tmlind>
yeah seems like omapdrm should know it
<tmlind>
bbl
Twig has joined #maemo-leste
xmn has joined #maemo-leste
<freemangordon>
tmlind: what is the easiest way to increase CMA size?
<bencoh>
on many (most?) platforms you just either change the .config file, or define cma= at boot
<bencoh>
(assuming you're really using the CMA and not some custom allocator with its own pool)
<bencoh>
then what I mentionned should work afaict, unless it changed in recent kernels
<bencoh>
kernel should report cma size at boot btw
<bencoh>
([ 0.000000] cma: Reserved 400 MiB at 0x00000000a1800000 on some unrelated board)
<freemangordon>
16MiB
<freemangordon>
this is on n900
<freemangordon>
tmlind: just tested droid4-pending-pvr-omapdrm-v5.15 on n900, works like a charm. I have your prm patch too, on top
<tmlind>
freemangordon: ok great, good to hear & thanks for testing
<freemangordon>
just a sec to check if pvr is idle when it has to be
<freemangordon>
and also if pvr interrupts increase
<tmlind>
not sure if we need the ocp interrupts enabled on omap4 and later, but that's easy to disable by dropping the ocp area for the selected compatible in pvr-drv
<tmlind>
maybe let's consider dropping the omap4 ocp interrupts after we have the refresh issues fixed..
<freemangordon>
hmm, I was expecting OFF there. or, this is ok?
<freemangordon>
tmlind: ^^^
<tmlind>
it does hit off with fremantle kernel, right?
<freemangordon>
no idea
<freemangordon>
but I guess yes
<tmlind>
freemangordon: maybe try adding this for the sgx domain in omap_prm.c driver: .flags = OMAP_PRM_RET_WHEN_IDLE
<freemangordon>
ok, will do
<freemangordon>
tmlind: for some reason performance with glmark-es has increased
<sicelo>
:-)
<tmlind>
actually that flag may not help unless the sgx device is configured for autoidle which we don't know because of the broken ocp.. worth a try though
<freemangordon>
tmlind: cuold it be that missing workaround?
<tmlind>
what was the missing workaround again?
<freemangordon>
which you said is applicable only for boards with reset button :)
<tmlind>
weird that it show ina instead of ret or off though, maybe some bits are different
<tmlind>
oh that one, i think that's only for development boards with reset button
<freemangordon>
also, in genpd_debug (or somesuch) it shows off-0
<tmlind>
maybe the prm bits are swapped for sgx domain or something
<freemangordon>
anyway, this is not such an issue now
<tmlind>
yeah
<tmlind>
there's a comment about sgx not supporting retention in powerdomains3xxx_data.c
<tmlind>
best to check the related values on fremantle kernel
<freemangordon>
ok
<tmlind>
with grep sgx /sys/kernel/debug/pm_debug/count
<freemangordon>
will do, when it comes to it
<tmlind>
ok
<freemangordon>
glmark2 Score: 22
<freemangordon>
a bit better
inky has quit [Ping timeout: 244 seconds]
zhxt has joined #maemo-leste
R0b0t1` has quit [Ping timeout: 246 seconds]
<tmlind>
freemangordon: so does n900 hang for you if you make omap_gem_is_cached_coherent() always return false?
<tmlind>
or comment out the calls for omap_gem_is_cached_coherent() in both places or just one place?
<uvos>
Wizzup: i need to make this a module and add some new proparties to it
<uvos>
(eg what backend produced an event)
<freemangordon>
also, all the 2d rendering is done through mmaped VRAM
<freemangordon>
ttyl
<Wizzup>
freemangordon: ttyl
<uvos>
we can add a rtcom backend too
<uvos>
no problem
<Wizzup>
yeah, I need to look at rtcom, but I think it abstracts the sql away mostly
<Wizzup>
I can get a schema of the db in a bit from my n900
<uvos>
rtcom is closed source?
<uvos>
anyhow indipendant sphone path needs to continue to work
<uvos>
but having 2 modules for logging is no issue ofc
<Wizzup>
uvos: well the libraries are not, but the phone and sms app are also 'rtcom'
<uvos>
Wizzup: ok so are the librarys that specifcl do communications event logging closed source?
<freemangordon>
no
<Wizzup>
right they are not, but the handlers are, but sphone can be a handler
<uvos>
whats a handler in this context?
<Wizzup>
a program that listens to ofono sms notifications and stores them rtcom
<uvos>
right
<uvos>
sure sphone should be that
<uvos>
:P
<Wizzup>
(in the fremantle case they also have a ui)
<uvos>
well for phone events anyhow (not nesscarly sms)
Twig has quit [Ping timeout: 244 seconds]
<uvos>
btw since everything in sphone is just events on datapipes
<uvos>
thats very gui toolkit neutral
<uvos>
we could add another sms ui in qt
<uvos>
as a plugin
<uvos>
not sure if that makes sense
<Wizzup>
I am hoping to get that going soon (will have to)
<Wizzup>
qt plugin in gtk is probably tricky
<uvos>
Wizzup: its not gtk anymore its just glib
<uvos>
and its not very ticky at that point
<uvos>
i can wirte a quick example plugin
<uvos>
mostly its not even glib anymore just plain c
<uvos>
what you interact with
<Wizzup>
I mean gtk and qt in the same progress
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 244 seconds]
<Wizzup>
tomorrow around 1300 I am switching ISP, so leste.maemo.org will be down for an unknown time (same for jenkins), but hopefully less than an hour or so
akossh has joined #maemo-leste
Langoor_ is now known as Langoor
Langoor has quit [Remote host closed the connection]
<uvos>
Wizzup: slightly cursed version of sphone that uses the fact that on linux QAplication is just glib mainloop in a trenchcoat to allow qt and gtk to interoperate