tmlind | interesting, so what's the minimal test case not working with chromeos mesa that is working with the ti blobs? | 08:47 |
---|---|---|
tmlind | not sure i've seen this issue with my use case | 08:48 |
tmlind | freemangordon: hoping test/revert/fix the extra patches in droid4-pending-pvr-omapdrm-v5.15 branch today | 09:15 |
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 | 09:15 |
tmlind | i only tested n900 so sgx loads and initializes | 09:16 |
freemangordon | tmlind: ok, will do | 09:16 |
freemangordon | the minimum test is glmark2-es2-drm | 09:17 |
freemangordon | works with blobs, crashes SGX with chromeos | 09:17 |
tmlind | ok | 09:22 |
tmlind | crashes on d4 or also on n900? | 09:23 |
freemangordon | only on d4 | 09:23 |
tmlind | ok | 09:23 |
freemangordon | on n900 works perfect, giving glmar of 37 | 09:23 |
freemangordon | *glscore | 09:24 |
tmlind | nice :) | 09:24 |
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 | 10:15 |
uvos | but this is gone in newer versions | 10:15 |
uvos | and you need to use e_book_client_connect(ESource *source) | 10:15 |
uvos | no sure where the source is supposed to come from | 10:15 |
uvos | something that points to eds somehow i gues | 10:16 |
freemangordon | uvos: yes, sec | 10:25 |
freemangordon | WTF? where did all the online libebook documentation go? | 10:30 |
freemangordon | what's wrong with gnome/freedesktop guys?!? | 10:30 |
Wizzup | yeah it all disappeared | 10:31 |
freemangordon | but...but.. why? | 10:32 |
Wizzup | where was it before? | 10:33 |
Wizzup | https://developer-old.gnome.org/libebook-contacts/stable/ | 10:34 |
freemangordon | everywhere :) | 10:34 |
Wizzup | freemangordon: I think developer-old. helps | 10:34 |
freemangordon | uvos: https://github.com/maemo-leste/osso-abook/blob/84e785a82737fd2b7238df87c6942bacada786b2/lib/osso-abook-util.c#L162 | 10:35 |
freemangordon | I think this is what you need | 10:35 |
Wizzup | so next time you find a dead link, just add 'developer-old.' before gnome.org | 10:35 |
freemangordon | I simply cannot find any link | 10:36 |
freemangordon | for example - search google for E_SOURCE_EXTENSION_ADDRESS_BOOK | 10:36 |
freemangordon | or e_source_registry_new_sync | 10:37 |
freemangordon | nothing! | 10:37 |
Wizzup | freemangordon: what about the link I shared? | 10:37 |
freemangordon | yes, but google knows nothing about it | 10:37 |
Wizzup | I searhed for 'libebook-contacts documentation' | 10:38 |
freemangordon | but, how do you know it is libebook-contacts? | 10:39 |
uvos | yes this is excatly what i discoverd | 10:39 |
freemangordon | the point is - a month or so ago it was enough to search for function name | 10:39 |
uvos | even the link to documentation on gnome mainpage just goses to 404 | 10:40 |
freemangordon | not it is like those libs have never existed | 10:40 |
freemangordon | uvos: :nod: | 10:40 |
freemangordon | something weird is going on | 10:40 |
freemangordon | *now it is like | 10:40 |
Wizzup | well they always liked to break things every few years and reinvent it | 10:41 |
Wizzup | probably just an accident with the docs | 10:41 |
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' | 10:42 |
uvos | the new documentation pages are way less usable too | 10:42 |
uvos | eveything is closed by default | 10:42 |
uvos | i cant even ctrl-f to find a symbol | 10:42 |
uvos | freemangordon: btw e_book_* is depricated | 10:45 |
uvos | freemangordon: replaced by e_book_client_* | 10:46 |
uvos | according to headers | 10:46 |
freemangordon | uvos: yes, it is | 10:51 |
freemangordon | but... | 10:52 |
Wizzup | better finish the RE before switching api eh :) | 11:04 |
tmlind | ack i see segfault on d4 with glmark2-es2-drm | 11:09 |
freemangordon | hmm | 11:12 |
freemangordon | I don't see segfault but SGX HW recovery triggered | 11:12 |
freemangordon | Wizzup: exactly :) | 11:13 |
_uvos_ | sure just ensureing awarenis wrt deprication | 11:32 |
_uvos_ | sphone has some basic ebook support now :) shows contact names on incomeing calls and sutch | 11:33 |
_uvos_ | anyone here know sql querys well? | 11:33 |
_uvos_ | i could use some help (next week) with sphone-store | 11:34 |
sicelo | Has its own db? | 11:35 |
_uvos_ | yeah for recent/missed calls/sms | 11:36 |
tmlind | freemangordon: yeah you're right sgx hw recovery with glmark-es2-drm with chromeos mesa | 11:44 |
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 | 11:53 |
freemangordon | good | 11:57 |
freemangordon | any difference? | 11:58 |
tmlind | no, dropping PVR_LINUX_MEM_AREA_USE_VMAP does not seem to affect any of my test cases | 11:58 |
freemangordon | :( | 11:58 |
Wizzup | uvos: I can help with bql | 12:19 |
tmlind | freemangordon: ok pushed out updated droid4-pending-pvr-omapdrm-v5.15 with all the mystery patches reverted and the ocp patch applied | 12:19 |
Wizzup | although we have osso rtcom for it, with sqlite format | 12:20 |
Wizzup | could be a good db format maybe | 12:20 |
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 | 12:21 |
tmlind | bbl | 12:21 |
Wizzup | uvos: with sql | 12:22 |
tmlind | heh termite is almost unusable with 33bc reverted.. some sgx flush or command mode lcd update is needed somewhere for sure | 12:42 |
tmlind | is n900 updating the screen just fine or also showing old data on the lcd? | 12:43 |
freemangordon | updates fine | 12:48 |
freemangordon | actually it hangs without 33bc reverted :) | 12:48 |
tmlind | ok, on droid4 hdmi seems to behave too so must be a command mode lcd issue | 12:48 |
freemangordon | mhm | 12:49 |
freemangordon | I also have 'hangs' in glamor on d4 | 12:49 |
freemangordon | which do not happen on n900 | 12:49 |
freemangordon | vsync issue that is | 12:49 |
freemangordon | as we already discussed back then - modesetting waits for vsyn to present next buffer, but it never comes | 12:50 |
freemangordon | because there is no vsync | 12:50 |
tmlind | i also see corrupt window titles on hdmi on droid4 with wlroots fyi | 12:51 |
tmlind | seems to be some wlroots issue | 12:51 |
tmlind | freemangordon: if you have an idea where d4 needs the command mode update please let me know | 12:57 |
freemangordon | tmlind: do you remember my idea for fake vsync back then? | 12:58 |
tmlind | hmm no, we carry some patch for omapdrm right now for that though | 12:58 |
freemangordon | lemme try to dig it | 12:59 |
tmlind | ok | 12:59 |
freemangordon | tmlind: "Re: xpresent/vsync and omapdrm", you're on CC | 13:00 |
freemangordon | and then I hit 1.17 breakage on n900 and never sent this RFC patch :) | 13:05 |
tmlind | heh ok | 13:06 |
freemangordon | but, I think I described my idea pretty well, should be doable | 13:06 |
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 | 13:07 |
freemangordon | but, this is really a nasty hack | 13:08 |
tmlind | yeah event triggered variable refresh would be ideal | 13:08 |
freemangordon | but, who triggers the event? | 13:09 |
tmlind | right, no idea :) | 13:09 |
freemangordon | I think this belongs to omapdrm | 13:09 |
tmlind | seems like that's a whack a mole game for the triggering from various places | 13:09 |
freemangordon | because the driver knows about details - is that a manual update display, is there TF interrupt, etc | 13:10 |
tmlind | yeah seems like omapdrm should know it | 13:10 |
tmlind | bbl | 13:21 |
freemangordon | tmlind: what is the easiest way to increase CMA size? | 14:30 |
bencoh | on many (most?) platforms you just either change the .config file, or define cma= at boot | 14:31 |
bencoh | (assuming you're really using the CMA and not some custom allocator with its own pool) | 14:32 |
freemangordon | it is CMO | 14:34 |
freemangordon | *CMA | 14:34 |
freemangordon | cma: cma_alloc: reserved: alloc failed, req-size: 375 pages, ret: -12 | 14:34 |
bencoh | then what I mentionned should work afaict, unless it changed in recent kernels | 14:35 |
bencoh | kernel should report cma size at boot btw | 14:36 |
bencoh | ([ 0.000000] cma: Reserved 400 MiB at 0x00000000a1800000 on some unrelated board) | 14:36 |
freemangordon | 16MiB | 14:39 |
freemangordon | this is on n900 | 14:39 |
freemangordon | tmlind: just tested droid4-pending-pvr-omapdrm-v5.15 on n900, works like a charm. I have your prm patch too, on top | 15:19 |
tmlind | freemangordon: ok great, good to hear & thanks for testing | 15:21 |
freemangordon | just a sec to check if pvr is idle when it has to be | 15:21 |
freemangordon | and also if pvr interrupts increase | 15:22 |
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 | 15:22 |
tmlind | maybe let's consider dropping the omap4 ocp interrupts after we have the refresh issues fixed.. | 15:23 |
freemangordon | sgx_pwrdm (INA),OFF:1,RET:0,INA:10,ON:11,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 | 15:25 |
freemangordon | hmm, I was expecting OFF there. or, this is ok? | 15:26 |
freemangordon | tmlind: ^^^ | 15:26 |
tmlind | it does hit off with fremantle kernel, right? | 15:26 |
freemangordon | no idea | 15:27 |
freemangordon | but I guess yes | 15:27 |
tmlind | freemangordon: maybe try adding this for the sgx domain in omap_prm.c driver: .flags = OMAP_PRM_RET_WHEN_IDLE | 15:29 |
freemangordon | ok, will do | 15:30 |
freemangordon | tmlind: for some reason performance with glmark-es has increased | 15:31 |
sicelo | :-) | 15:31 |
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 | 15:32 |
freemangordon | tmlind: cuold it be that missing workaround? | 15:32 |
tmlind | what was the missing workaround again? | 15:33 |
freemangordon | which you said is applicable only for boards with reset button :) | 15:33 |
tmlind | weird that it show ina instead of ret or off though, maybe some bits are different | 15:33 |
tmlind | oh that one, i think that's only for development boards with reset button | 15:34 |
freemangordon | also, in genpd_debug (or somesuch) it shows off-0 | 15:34 |
tmlind | maybe the prm bits are swapped for sgx domain or something | 15:34 |
freemangordon | anyway, this is not such an issue now | 15:34 |
tmlind | yeah | 15:35 |
tmlind | there's a comment about sgx not supporting retention in powerdomains3xxx_data.c | 15:36 |
tmlind | best to check the related values on fremantle kernel | 15:36 |
freemangordon | ok | 15:36 |
tmlind | with grep sgx /sys/kernel/debug/pm_debug/count | 15:37 |
freemangordon | will do, when it comes to it | 15:37 |
tmlind | ok | 15:37 |
freemangordon | glmark2 Score: 22 | 15:37 |
freemangordon | a bit better | 15:37 |
tmlind | freemangordon: so does n900 hang for you if you make omap_gem_is_cached_coherent() always return false? | 15:51 |
tmlind | or comment out the calls for omap_gem_is_cached_coherent() in both places or just one place? | 15:52 |
freemangordon | tmlind: will try later on | 16:02 |
tmlind | ok | 16:44 |
freemangordon | tmlind: hmm: https://gitlab.freedesktop.org/xorg/xserver/-/commit/db9e9d45e8ba73510f11eb9e534c176102f6623e | 17:30 |
Wizzup | looks like we want that | 17:33 |
freemangordon | ъеах | 17:33 |
freemangordon | yeah | 17:33 |
freemangordon | I am going to take the whole ms directory into our xserver | 17:34 |
freemangordon | to see how/if it will work | 17:34 |
Wizzup | can we not use latest xorg? | 17:35 |
Wizzup | or did that have the dependency hell | 17:35 |
freemangordon | abi has changed | 17:36 |
freemangordon | I guess we can just pick whatever patches are needed | 17:36 |
freemangordon | if it makes sense | 17:36 |
Wizzup | ok | 17:36 |
freemangordon | hmm, actually we need only modesetting driver | 17:43 |
freemangordon | well, we will need stuff from chimaera when and if it comes to building it in the repos | 17:44 |
freemangordon | but, I am not sure how close we are to that :) | 17:44 |
Wizzup | right | 18:05 |
Wizzup | you probably know better than we do | 18:05 |
freemangordon | hmm, this one seems to support 16 bpp as well, at least by looking at the commits | 18:31 |
Wizzup | fun | 18:41 |
freemangordon | upstream master xorg build finished, lets see if there will be any difference | 19:06 |
_uvos_ | freemangordon: so a drm ioctl exists that updates the display | 19:30 |
_uvos_ | and xorg for sure can use it with radion/amdgpu | 19:30 |
_uvos_ | i have a vrr display that shows update frequency | 19:30 |
_uvos_ | and it works fine there | 19:30 |
_uvos_ | so maybe investigating how it works there might be prudent | 19:31 |
_uvos_ | the missing tiles is a different issue | 19:32 |
_uvos_ | at least i think so | 19:32 |
_uvos_ | modesetting has an optin to turn this on | 19:33 |
_uvos_ | cant check rn | 19:33 |
_uvos_ | google it or wait untill i can look at my xorg config | 19:34 |
freemangordon | we're getting there :) | 19:46 |
freemangordon | with upstream xserver I no longer see excessive CPU usage on n900 | 19:47 |
Wizzup | yay | 19:48 |
freemangordon | lets see what glmark will say | 19:51 |
freemangordon | but better do that with traces disbled :D | 19:52 |
freemangordon | hmm, after I disabled the traces, high CPU usage is back hhere | 19:58 |
freemangordon | still: | 19:59 |
freemangordon | glmark2 Score: 25 | 19:59 |
freemangordon | that's better | 19:59 |
freemangordon | oh, ok, we need that FlushBehaviour set to 2 | 20:01 |
Wizzup | and then high cpu is gone? | 20:08 |
freemangordon | mhm | 20:08 |
Wizzup | neat | 20:11 |
uvos | .BI "Option \*qVariableRefresh\*q \*q" boolean \*q | 20:43 |
uvos | Enables support for enabling variable refresh on the Screen's CRTCs when an suitable application is flipping via the Present extension. | 20:43 |
uvos | https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/modesetting.man | 20:43 |
freemangordon | glmark2 Score: 26 :) | 20:45 |
uvos | thats pretty bad compeared to on drm no? | 20:45 |
freemangordon | 37 | 20:46 |
freemangordon | not *that* bad | 20:46 |
uvos | i gues | 20:46 |
uvos | survivable | 20:46 |
freemangordon | I think I can improve it a bit | 20:46 |
Wizzup | sorry for asking, but I have to ask, does h-d work with a sample app, say osso-xterm ? | 20:46 |
Wizzup | :D | 20:46 |
uvos | im more concernd with it working that it having full perf anyhow | 20:46 |
Wizzup | just excited | 20:46 |
freemangordon | yes | 20:46 |
freemangordon | but, there are terrible rendering artifacts | 20:47 |
Wizzup | aha | 20:47 |
freemangordon | I suspect because my glamor replacement doesnt implement TFP yet | 20:47 |
uvos | Wizzup: so sql was about https://github.com/maemo-leste/sphone/blob/master/src/utils/store.c | 20:47 |
uvos | Wizzup: i need to make this a module and add some new proparties to it | 20:47 |
uvos | (eg what backend produced an event) | 20:47 |
freemangordon | also, all the 2d rendering is done through mmaped VRAM | 20:48 |
freemangordon | ttyl | 20:48 |
Wizzup | freemangordon: ttyl | 20:48 |
uvos | we can add a rtcom backend too | 20:48 |
uvos | no problem | 20:48 |
Wizzup | yeah, I need to look at rtcom, but I think it abstracts the sql away mostly | 20:48 |
Wizzup | I can get a schema of the db in a bit from my n900 | 20:48 |
uvos | rtcom is closed source? | 20:49 |
uvos | anyhow indipendant sphone path needs to continue to work | 20:49 |
uvos | but having 2 modules for logging is no issue ofc | 20:49 |
Wizzup | uvos: well the libraries are not, but the phone and sms app are also 'rtcom' | 20:52 |
uvos | Wizzup: ok so are the librarys that specifcl do communications event logging closed source? | 20:53 |
freemangordon | no | 20:54 |
Wizzup | right they are not, but the handlers are, but sphone can be a handler | 20:54 |
uvos | whats a handler in this context? | 20:55 |
Wizzup | a program that listens to ofono sms notifications and stores them rtcom | 20:55 |
uvos | right | 20:55 |
uvos | sure sphone should be that | 20:55 |
uvos | :P | 20:55 |
Wizzup | (in the fremantle case they also have a ui) | 20:55 |
uvos | well for phone events anyhow (not nesscarly sms) | 20:55 |
uvos | btw since everything in sphone is just events on datapipes | 20:55 |
uvos | thats very gui toolkit neutral | 20:56 |
uvos | we could add another sms ui in qt | 20:56 |
uvos | as a plugin | 20:56 |
uvos | not sure if that makes sense | 20:56 |
Wizzup | I am hoping to get that going soon (will have to) | 20:57 |
Wizzup | qt plugin in gtk is probably tricky | 20:57 |
uvos | Wizzup: its not gtk anymore its just glib | 20:57 |
uvos | and its not very ticky at that point | 20:58 |
uvos | i can wirte a quick example plugin | 20:58 |
uvos | mostly its not even glib anymore just plain c | 20:58 |
uvos | what you interact with | 20:58 |
Wizzup | I mean gtk and qt in the same progress | 20:59 |
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 | 21:11 |
uvos | Wizzup: https://github.com/maemo-leste/sphone/tree/sphone-qt | 23:31 |
Wizzup | heh.... I wish and you make it happen eh | 23:32 |
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 | 23:32 |
uvos | if you load the test module | 23:32 |
uvos | which i dident push | 23:33 |
uvos | upps sec | 23:33 |
uvos | ok | 23:34 |
uvos | so if you load test https://github.com/maemo-leste/sphone/blob/sphone-qt/src/modules/test.cpp | 23:34 |
Wizzup | but, so this has gtk and qt live in the same application? | 23:34 |
uvos | yeah | 23:34 |
uvos | sphone will show you a qt widget when you click on "contacts" in the gtk dialer window | 23:34 |
Wizzup | ok | 23:35 |
uvos | so now you can go create a sphone-sms ui that is in qt or we can slowly port it or whatever | 23:35 |
uvos | port it (the ui) to qt that is | 23:35 |
Wizzup | ok | 23:35 |
uvos | so anyhow i wont merge this into mainline sphone - unless you want to go this route in some way | 23:36 |
uvos | (since it forces a link to both qt and gtk wich is strange and scary :P) | 23:36 |
Wizzup | I need a few more days before I start hacking on yappari and turn it into conversations stuff | 23:37 |
Wizzup | I want to start on it now, but I need to finish other stuff first | 23:37 |
Wizzup | then I'll look at what makes sense integration wise | 23:37 |
uvos | ok | 23:37 |
Wizzup | great that you hacked this up already, though :) | 23:37 |
Wizzup | as in, I think we need a news post first now :P | 23:37 |
Wizzup | I'm travelling on tuesday, but after that I'm on my own for ~2 weeks so should have lots of leste time | 23:38 |
uvos | great :) | 23:38 |
uvos | anyhow ttyl getting some sleep | 23:38 |
Wizzup | ttyl! | 23:38 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!