| Wizzup | dhclient doesn't respond to sigusr1, hehe | 10:31 |
|---|---|---|
| Wizzup | which means we have to kill it and start it again | 10:33 |
| Wizzup | ok this is more work than I had hoped | 10:54 |
| Wizzup | parazyd: ok I added resolvconf to udhcpc | 11:16 |
| parazyd | Alright | 11:19 |
| parazyd | Did you split the functionality into multiple scripts? | 11:19 |
| parazyd | I think that might be good, so we make it a bit more modular. | 11:20 |
| Wizzup | not atm, it's like ~4 lines atm | 11:21 |
| Wizzup | I'll submit a PR in a second | 11:22 |
| Wizzup | as rfc | 11:22 |
| Wizzup | The domain directive is an obsolete name for the search directive that handles one search list entry only. | 11:25 |
| Wizzup | ah... | 11:25 |
| lel | MerlijnWajer opened a pull request: https://github.com/maemo-leste/libicd-network-ipv4/pull/3 (etc/50_ipv4_network_setup: use resolvconf) | 11:35 |
| Wizzup | parazyd: ^^ | 11:35 |
| Wizzup | I don't know what the purpose of LEASE_PARAMS is there | 11:36 |
| uvos | impoverish the american middle class | 11:39 |
| Wizzup | uvos: huh? :p | 11:42 |
| uvos | was a joke, aperantly not a great one: the steriotype being that broke americans who get a decent job immidatly impoverish themselves again by leasing a mustang or somth. at terrible contractual conditions. | 11:45 |
| uvos | *stereotype | 11:45 |
| Wizzup | ah | 11:46 |
| Wizzup | yeah I figured it was a lease joke | 11:46 |
| Wizzup | hehe | 11:46 |
| Wizzup | anyway I think this resolv/dns problem is resolved | 11:46 |
| uvos | yay | 11:46 |
| Wizzup | I rely on sphone all the time for my 3g connections hehe | 11:47 |
| Wizzup | (I send myself a sms when I start activating the interface to make sure ofono wakes up) | 11:48 |
| uvos | oof | 11:49 |
| uvos | yeah ofono issues are another pressing concern | 11:50 |
| uvos | the interfaces sphone needs all work very well at least | 11:50 |
| uvos | i have never seen it not ring | 11:51 |
| Wizzup | yeah I think it's probably a relatively minor tweak | 11:51 |
| Wizzup | it could just be a matter of adding some g_at_chat_register to motorola_sms_probe | 11:52 |
| Wizzup | i.e. "kick" things | 11:52 |
| Wizzup | ^^ above is not correct I think | 11:55 |
| Wizzup | as in it's ot the g_at_chat_register that's required | 11:56 |
| Wizzup | otherwise it wouldn't miss the sim changes I think | 11:56 |
| Wizzup | what I find surprising is the CIEV messages (set to 5,1,0 or something) when internet is being activated | 11:58 |
| Wizzup | maybe voicecall.c catched that and doesn't kick or something | 11:59 |
| Wizzup | heh: | 12:01 |
| Wizzup | # cat /run/resolvconf/interface/wwan3.udhcpc | 12:02 |
| Wizzup | nameserver 0.0.0.0 | 12:02 |
| Wizzup | nameserver 0.0.0.0 | 12:02 |
| Wizzup | yeah it gets that via env, so it's not the fault of my resolvconf changes.. | 12:04 |
| Wizzup | dns=0.0.0.0 0.0.0.0 | 12:04 |
| Wizzup | seems that goes wrong somewhere in ofono libs or so | 12:07 |
| Wizzup | freemangordon: this is for later, but looks like ctx->settings->dns in libicd-network-ofono is 0.0.0.0 when it is not in the ofono context | 12:09 |
| Wizzup | btw, uvos, what's the best way to get max ofono debug, it's not quite clear to me | 12:14 |
| Wizzup | (in case you know) | 12:14 |
| uvos | i dont, when debugging the calls state not being repored thing i just steped though with gdb | 12:20 |
| Wizzup | ok | 12:31 |
| uvos | Wizzup: parazyd: http://uvos.xyz/maserati/hp | 13:59 |
| uvos | here are the headphone jack detection patches | 13:59 |
| uvos | also tmlind | 13:59 |
| freemangordon | PVR:(Error): KEGLGetDrawableParameters: Couldn't recreate drawable | 14:16 |
| freemangordon | :) | 14:16 |
| freemangordon | this is with one function ( PVRDRIDrawableRecreate() ) not implementsd | 14:16 |
| Wizzup | freemangordon: what is the context? | 14:32 |
| Wizzup | uvos: right and then (later) for mainlining we'd need to make a separate codec/card right? | 14:33 |
| Wizzup | uvos: this is great, thanks, I think we should probably add it -devle kernel soon | 14:33 |
| uvos | maybe, i think the changes to graph-card should be universally fine, but i dont relly know enough about how its used to say for certain | 14:43 |
| uvos | there is something wrong with how the cpcap codec reports the hp jack for sure | 14:44 |
| uvos | asoc warns ASoC: DAPM unknown pin Headphones | 14:44 |
| uvos | but if i report on a different pin that dose exist like Headphone Jack | 14:44 |
| uvos | it dosent work | 14:44 |
| uvos | its just not reported to userspace | 14:45 |
| uvos | which is wierd | 14:45 |
| uvos | so yeah the patches are def wip | 14:45 |
| uvos | but they do work fine | 14:45 |
| uvos | this is related to how headset_jack_pins is defined | 14:46 |
| uvos | see sound/soc/codecs/cpcap.c | 14:46 |
| uvos | not sure why reporting on an existing widget dosent work | 14:46 |
| uvos | maybe ^^^ tmlind knows | 14:46 |
| freemangordon | Wizzup: one more functionm remaining, from blob pvr_dri | 14:50 |
| uvos | freemangordon: so your reing the differences from the blob into chomeos source? | 14:51 |
| freemangordon | yes | 14:51 |
| freemangordon | though it is more like total RE | 14:52 |
| freemangordon | but yeah | 14:52 |
| freemangordon | hopefully with that glmark will no longer hand and we'll have the correct x11 support | 14:52 |
| freemangordon | *hang | 14:52 |
| freemangordon | kmscube works :D | 15:14 |
| freemangordon | so is glmark2 :) | 15:15 |
| freemangordon | ok, will clean-up the code a bit and will push | 15:18 |
| uvos | what remaining problem exist then? | 15:18 |
| uvos | xorg resize/move stil hangs? | 15:18 |
| uvos | what else? | 15:18 |
| freemangordon | no idea, I havent' tested with this pvr_dri | 15:19 |
| uvos | ok | 15:19 |
| freemangordon | I mean - I just made the very first test with it (kmscube and glmark) | 15:20 |
| Wizzup | freemangordon: nice work! | 16:58 |
| tmlind | freemangordon: nice job :) | 17:06 |
| tmlind | uvos: good to see the headset interrupt handler :) | 17:06 |
| tmlind | uvos: please check your patches with checkpatch.pl --strict to avoid pointless trivial comment noise on the mailing lists ;) | 17:07 |
| tmlind | uvos: then after -rc1, please send the asoc patches to the asoc list, morimoto san probably will provide comments and help to get the issue fixed | 17:09 |
| uvos | tmlind: im not going to try merging this yet | 17:10 |
| uvos | tmlind: see the issues wrt the affect dapm pin | 17:10 |
| tmlind | uvos: hmm let me check | 17:13 |
| uvos | also really | 17:13 |
| uvos | i dont know if the changes to graph-card are proper | 17:14 |
| uvos | i mean i call set_jack with NULL for user data | 17:14 |
| uvos | no idea if some codec that can be used either with graph-card or some sepical driver | 17:14 |
| uvos | wont strongly dislike the driver specific parameter being NULL | 17:14 |
| uvos | if so i dont see any way other than to fork graph-card/wirte a new cpcap driver | 17:15 |
| uvos | which is preferable anyhow | 17:15 |
| uvos | so not sure if it makes sense to try and upstream this, rather than just keeping it as a leste specific patch until the cpcap audio situation can be overhauled by granting mapphones a own driver | 17:16 |
| tmlind | uvos: well the good news is all the issues i had with the graph-card got promtly fixed after sending an attempted fix | 17:17 |
| tmlind | uvos: so yeah i think your patch is ok to send to discuss it on the lists for sure | 17:17 |
| tmlind | s/promtly/promptly/ | 17:18 |
| tmlind | uvos: not sure how else to handle the dapm pin, either a gpio or device specific call is needed depending on the hardware | 17:20 |
| uvos | tmlind: hmm? | 17:21 |
| uvos | so snd_soc_jack reports a incomeing snd_soc_jack_report on a specific widget | 17:22 |
| uvos | you can see this in amixer -c0 controles | 17:22 |
| uvos | i can go and report on any widget i like | 17:22 |
| tmlind | uvos: but it currently expects a gpio right? and there are cases where it's not a gpio | 17:22 |
| uvos | no this is something else | 17:22 |
| tmlind | ok | 17:23 |
| uvos | currtently i report on the Headset Right Playback Route and Headset Left Playback Route and Headphones widget | 17:23 |
| uvos | this means that userspace gets a signal | 17:23 |
| uvos | that this widget has become available/unavailable when SND_JACK_HEADPHONE is reported through snd_soc_jack_report | 17:23 |
| uvos | the Headphones dosent really exist | 17:24 |
| uvos | so i get a warning | 17:24 |
| uvos | but only this widget really causes userspace to react | 17:24 |
| uvos | (ie pa/ alsa userspace) | 17:24 |
| uvos | not sure why | 17:24 |
| tmlind | no idea :) | 17:24 |
| tmlind | Wizzup: the voice call audio routing has issues where the linux driver has no clue whatsoever right now what's going beyond the hacked in set_tdm_slot function | 17:29 |
| tmlind | the solution there (and a nice project for somebody into patching linux audio stuff) is to make the cpcap voice call codec driver a child devices of the cpcap or cpcap audio codec instead of being a child of the mcbsp device | 17:30 |
| tmlind | then the voice call codec driver can communicate with the cpcap audio codec driver with set_tdm_slot etc | 17:31 |
| tmlind | freemangordon: so seems like with wayland the path is something like libmesa_dri_drivers.so -> libpvr_dri_support.so -> libsrv_um.so -> libdbm.so -> kernel dri, no pvr_dri involved there? | 17:35 |
| freemangordon | pvr_dri is a symlink to libmesa_dri_drivers.so ;) | 17:38 |
| tmlind | ah ok :) | 17:38 |
| freemangordon | what do you think - shall I crate a commit on top of current uvos' mesa or shall I crate a new branch and add everything from scratch? | 17:39 |
| freemangordon | or maybe squash to a single commit? | 17:40 |
| tmlind | well uvos's branch is based on some imported patches too? i guess we have no commit from the chromeos guys? | 17:40 |
| freemangordon | yeah, we have no commit from them | 17:40 |
| freemangordon | ok, I'll squash everything to s single commit | 17:41 |
| tmlind | i'd do the patches against what jonathan bakker applied then if possible, maybe uvos used that as a base too | 17:41 |
| freemangordon | yes, this is what I made the changes against, however the change is so big I doubt it will be of any use as a commit on top | 17:42 |
| uvos | yes i just merged our mesa (ie debain/) with bakker | 17:42 |
| uvos | so really makes no difference | 17:42 |
| tmlind | maybe pick whatever makes most sense from git diff point of view :) | 17:42 |
| freemangordon | ok, I'll do another branch and will squash jonathan bakker commits with mine, to a single commit | 17:44 |
| freemangordon | glmark2 Score: 62 | 17:44 |
| uvos | vsync? | 17:45 |
| freemangordon | yeah | 17:45 |
| freemangordon | this is on d4 | 17:45 |
| freemangordon | most of the tests afre with fps of 82 | 17:46 |
| tmlind | nice, 62 is very close to 63 i seem to have reported earlier with wayland | 17:46 |
| freemangordon | this is -drm tough | 17:46 |
| tmlind | terrain is the slowest for sure, something like 2fps right now :) | 17:47 |
| freemangordon | 1fps here :) | 17:47 |
| freemangordon | but yeah | 17:47 |
| freemangordon | oh, I have to beutify one function before that | 17:48 |
| freemangordon | it is full of labels and gotos ATM | 17:49 |
| tmlind | hmm so why do you want to squash this with jonathan's changes? just add one or more patches on top? | 17:50 |
| freemangordon | also, x11 does not work with this pvr_dri | 17:50 |
| uvos | :( | 17:50 |
| tmlind | heh | 17:50 |
| freemangordon | that's to be expected | 17:50 |
| freemangordon | I mean - Xorg starts | 17:51 |
| uvos | ? | 17:51 |
| freemangordon | but es2gears (for example) complains: | 17:51 |
| freemangordon | PVRImageDrawableGetNativeInfo: Image get buffers call failed | 17:51 |
| freemangordon | it could be a bug I introduced, btu, we have a working code for reference, not much of an issue | 17:52 |
| uvos | ok why is its behvior worse than chomeos pvr_dri | 17:52 |
| uvos | ok bug | 17:52 |
| uvos | ok | 17:52 |
| freemangordon | or, missing code | 17:52 |
| freemangordon | chromeos code somehow works, I will have to understand how | 17:53 |
| freemangordon | again, not a biggie, I will fix that | 17:53 |
| freemangordon | tmlind: oh, ok, but trust me, this commit will be huge nad more or less useless (in terms of history) | 17:53 |
| freemangordon | but ok | 17:53 |
| uvos | how different is your pvr_dri from chomeos now anyways | 17:53 |
| uvos | i gues i can see for myself wen you push it.. | 17:54 |
| freemangordon | very | 17:54 |
| freemangordon | I mean - almost everyting is different | 17:54 |
| tmlind | heh | 17:58 |
| lel | halftux closed a pull request: https://github.com/maemo-leste-extras/mihphoto/pull/2 (Update mihphoto.desktop) | 18:27 |
| freemangordon | this meson/ninja/whatever is so stupid that it spins full rebuild on a simple configuration change in one of the subdirs :( | 18:28 |
| Wizzup | but... but... progress! | 18:29 |
| freemangordon | yeah | 18:29 |
| freemangordon | progree | 18:29 |
| freemangordon | *progress | 18:29 |
| Wizzup | parazyd: want to try to libicd-network-ipv4 PR? | 18:42 |
| Wizzup | I tested it on wifi and it works well, gprs had some trouble I don't think that was related to the patch, but rather something in libicd-network-ofono, so no regression there | 18:43 |
| Wizzup | wireguard switching works as expected, and all the interface files are gone | 18:43 |
| Wizzup | I'll just merge it then | 19:11 |
| lel | MerlijnWajer closed an issue: https://github.com/maemo-leste/bugtracker/issues/583 (Installing resolvconf breaks our dnsmasq setup) | 19:15 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/libicd-network-ipv4/pull/3 (etc/50_ipv4_network_setup: use resolvconf) | 19:15 |
| parazyd | Wizzup: Thanks, lgtm :) | 19:18 |
| Wizzup | wow the issue was closed automatically by me merging the branch (manually) of the open pull request that only mentioned the issue | 19:19 |
| Wizzup | next level.. | 19:19 |
| parazyd | Yes :) | 19:20 |
| parazyd | It does so also if you write 'Closes: #number' in the commit message. | 19:21 |
| Wizzup | well, maybe see if it doesn't break stuff (still building for armhf) | 19:22 |
| parazyd | Yep I'll try the upgrade | 19:22 |
| freemangordon | this: https://github.com/freemangordon/mesa/commit/b1b8c75d0d49827e38feb29566bbb4101fb9d85e | 19:41 |
| freemangordon | tmlind: ^^^ | 19:42 |
| freemangordon | please test if possible | 19:50 |
| tmlind | ok | 20:02 |
| tmlind | nice only 26 steps to rebuild | 20:04 |
| tmlind | pvrimage.c:108:5: error: implicit declaration of function 'PVRDRIBufferDestroy' | 20:05 |
| freemangordon | hmm | 20:05 |
| freemangordon | lemme check | 20:05 |
| tmlind | forgot to git add something? | 20:07 |
| freemangordon | pushing a fix | 20:07 |
| tmlind | k | 20:07 |
| freemangordon | tmlind: done, please pull | 20:09 |
| tmlind | ok | 20:09 |
| freemangordon | mesa taking ages to build doesn;t really help :( | 20:10 |
| tmlind | pvrdri.c:375:42: error: 'PTHREAD_MUTEX_RECURSIVE_NP' undeclared | 20:11 |
| freemangordon | hmm, not sure why is that, it is defined here in pthread.h | 20:12 |
| freemangordon | tmlind: what distro do you use? what libc actually | 20:13 |
| freemangordon | could you do: | 20:13 |
| freemangordon | grep -r PTHREAD_MUTEX_RECURSIVE_NP /usr/include/ | 20:13 |
| freemangordon | maybe I shall include pthread.h | 20:15 |
| freemangordon | oh, it is already included | 20:15 |
| tmlind | hmm not seeing it, this on alpine with musl | 20:16 |
| freemangordon | oh, seems to be non-portable glibc extension :( | 20:17 |
| tmlind | uh | 20:17 |
| freemangordon | please remove _NP suffix and try with it | 20:18 |
| tmlind | ok brb | 20:18 |
| freemangordon | _NP is for 'fast' mutexes it seems | 20:18 |
| freemangordon | whatever 'fast' is suppposed to mean | 20:18 |
| uvos | mutexes, but painted red | 20:18 |
| freemangordon | :) | 20:18 |
| freemangordon | oh, it is kinda my fault actually | 20:20 |
| freemangordon | we have PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP in pthread.h | 20:20 |
| freemangordon | so I should simply use PTHREAD_MUTEX_RECURSIVE | 20:20 |
| freemangordon | going to push a fix | 20:20 |
| freemangordon | tmlind: fixed, please pull | 20:22 |
| tmlind | pvrimage.c:659: undefined reference to `PVRDRIBufferGetModifier' | 20:43 |
| tmlind | and one warning fyi: pvrdri.c:638:7: warning: this statement may fall through | 20:44 |
| freemangordon | ignore the warning | 20:46 |
| tmlind | looks like dri_support.h needs to be included | 20:46 |
| freemangordon | hmm, lemme check about undefined reference | 20:46 |
| tmlind | hmm no it's some linker error | 20:46 |
| freemangordon | but how it was able to link it here?!? | 20:47 |
| freemangordon | progress, yeah | 20:48 |
| freemangordon | ok, just hit that here, so I can test the fix :) | 20:51 |
| tmlind | ok | 20:53 |
| freemangordon | tmlind: fixed, please pull | 20:55 |
| tmlind | ok | 20:55 |
| tmlind | i still get sgx lockup oops with both glmark2-es2-wayland and glmark2-es2-drm looks like | 21:10 |
| tmlind | ah did not do sudo ninja -C build install :) | 21:11 |
| freemangordon | well, you can copy the resulting binary by hand | 21:12 |
| freemangordon | and rename it to pvr_dri.so | 21:12 |
| freemangordon | tmlind: any progress? | 21:23 |
| tmlind | kmscube works but no luck with anything else so far it seems | 21:28 |
| freemangordon | weird | 21:28 |
| * uvos starts compileing | 21:29 | |
| freemangordon | are you sure /usr/lib/arm-linux-gnueabihf/dri/pvr_dri.so has been updated? | 21:29 |
| freemangordon | tmlind: ^^^ | 21:29 |
| freemangordon | ok, xorg support is there too :) | 21:37 |
| freemangordon | hmm: | 21:41 |
| freemangordon | [build] use-vbo=false: FPS: 107 FrameTime: 9.346 ms | 21:41 |
| freemangordon | this is in xorg | 21:42 |
| uvos | neat | 21:43 |
| freemangordon | isn;t that too much to be true? | 21:43 |
| uvos | no idea android glmark is constantly locked to vsync | 21:44 |
| uvos | sec let me look at wayland results | 21:44 |
| uvos | [build] use-vbo=false: FPS: 100 FrameTime: 9.995 ms | 21:45 |
| uvos | (sway ti blobs) | 21:45 |
| freemangordon | oh, so it similar | 21:45 |
| freemangordon | *it is | 21:45 |
| uvos | yeah | 21:45 |
| uvos | sounds sane | 21:45 |
| freemangordon | but with chromiumos build one it was 80 | 21:46 |
| uvos | ? it never worked at all for me | 21:46 |
| freemangordon | which sounds more sane :D | 21:46 |
| uvos | oh on xorg it worked? | 21:46 |
| freemangordon | yeah | 21:46 |
| uvos | ok | 21:46 |
| freemangordon | hmm, glmark run out of memory, seems there is a mamory leak somewhere | 21:47 |
| freemangordon | *memory | 21:47 |
| tmlind | freemangordon: looks like i have /usr/lib/xorg/modules/dri/pvr_dri.so, that is up to date | 21:47 |
| freemangordon | tmlind: no idea what's wrong, here even xorg works with latest commit | 21:48 |
| uvos | Meson version is 0.49.2 but project requires >= 0.52. how did we get around this | 21:48 |
| uvos | i forgot | 21:48 |
| freemangordon | I think I installed the one from chimaera | 21:49 |
| freemangordon | uvos: 0.56.1-1~bpo10+1 | 21:49 |
| freemangordon | no idea where did I get that from | 21:49 |
| uvos | im pretty sure thats not what i did | 21:49 |
| freemangordon | oh, I know what's going on | 21:49 |
| freemangordon | glmark2-es2-drm is vsynced | 21:49 |
| freemangordon | and it shows ~80fps | 21:49 |
| freemangordon | PRESENT is not | 21:50 |
| uvos | ok | 21:50 |
| freemangordon | so it shows higher FPS | 21:50 |
| uvos | thats sane | 21:50 |
| freemangordon | tmlind: hmm, what? | 21:51 |
| freemangordon | usr/lib/xorg/modules/dri/pvr_dri.so | 21:51 |
| freemangordon | are you sure about the path? | 21:51 |
| uvos | yeah thats wrong | 21:52 |
| uvos | its not a xorg dri module | 21:52 |
| freemangordon | I mean: it should be /usr/lib/arm-linux-gnueabihf/dri/pvr_dri.so | 21:52 |
| tmlind | musl | 21:53 |
| freemangordon | hmm? | 21:54 |
| uvos | arm-linux-musleabihf | 21:54 |
| uvos | i presume | 21:54 |
| freemangordon | well, yeah | 21:54 |
| tmlind | nah, just /usr/lib here | 21:57 |
| freemangordon | well /usr/lib/dri then | 21:58 |
| freemangordon | but make sure you dont have more blobs than needed :) | 21:58 |
| uvos | yeah | 21:59 |
| tmlind | yeah maybe i have some extra blob somewhere | 21:59 |
| tmlind | pvr_dri.so is in /usr/lib/xorg/modules/dri as configured, no extra one in /usr/lib/dri | 22:00 |
| tmlind | hmm | 22:00 |
| uvos | /usr/lib/xorg/modules/dri sounds very wrong | 22:00 |
| freemangordon | it should not be there | 22:01 |
| uvos | xorg dri is a thing but its mostly unrelated to this kind of dri | 22:01 |
| tmlind | just using what the distro config options | 22:01 |
| freemangordon | tmlind: maybe strace to see if the corrce lib is being loaded | 22:04 |
| freemangordon | *correct | 22:04 |
| tmlind | yeah will figure it out | 22:05 |
| tmlind | i guess no extra config options got added that needs meson --reconfigure or something? | 22:06 |
| freemangordon | no | 22:07 |
| freemangordon | only one more file was added in pvr directory | 22:08 |
| uvos | [5/753] | 22:08 |
| uvos | here we go | 22:09 |
| freemangordon | :) | 22:09 |
| tmlind | it's only a flesh wound :) | 22:10 |
| uvos | hopefully me disableing everything not needed for the pvr classic mesa driver is enough | 22:12 |
| uvos | to get a resonable time | 22:12 |
| uvos | btw classic mesa driver support (ie pvr_dir) is going away | 22:13 |
| uvos | so this stuff will only work with upstream mesa for a litte while longer | 22:13 |
| tmlind | weird so strace -o /tmp/glmark.log glmark2-es2-drm runs fine for me | 22:17 |
| uvos | thats the heisenbug the chomeos pvr_dir had | 22:18 |
| freemangordon | that means you;re loading chromeos pvr_dri from somewhere | 22:18 |
| freemangordon | tmlind: which branch did you compile? | 22:18 |
| uvos | clearly yours | 22:19 |
| uvos | since he had the errors | 22:19 |
| freemangordon | right | 22:19 |
| freemangordon | :) | 22:19 |
| tmlind | so strace shows open("/usr/lib/libpvr_dri_support.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4 | 22:19 |
| uvos | [250/753] | 22:19 |
| freemangordon | but there are some chromeos remnants still | 22:19 |
| freemangordon | tmlind: did you copy 'my' pvr_dri to /usr/lib/dri? | 22:20 |
| freemangordon | no, libpvr_dri_support.so is fine | 22:20 |
| freemangordon | this is opened by pvr_dri.so | 22:20 |
| freemangordon | the question is which pvr_dri.so gets opened | 22:20 |
| tmlind | oh right | 22:21 |
| tmlind | not seeing pvr_dri.so in strace output at all | 22:21 |
| freemangordon | that's strange | 22:21 |
| freemangordon | keep in mind it is dload()-ed | 22:22 |
| freemangordon | not linked | 22:22 |
| tmlind | hmm i did grep open /tmp/glmark.log | 22:22 |
| freemangordon | maybe run from gdb and pu a breakpoint in PVRDRIInitScreen | 22:23 |
| freemangordon | *put | 22:23 |
| tmlind | hmm does not run in gdb while it runs with strace, need to continue debugging sunday night earliest most likely | 22:27 |
| freemangordon | but, you can break in gdb and do 'info shared' | 22:28 |
| tmlind | ok just a sec | 22:30 |
| tmlind | seems to use the correct /usr/lib/xorg/modules/dri/omapdrm_dri.so | 22:31 |
| freemangordon | thid is not the correct module | 22:31 |
| freemangordon | *this | 22:31 |
| freemangordon | try with 'export MESA_LOADER_DRIVER_OVERRIDE=pvr' | 22:31 |
| tmlind | ah sorry getting tired | 22:31 |
| tmlind | ok | 22:31 |
| tmlind | ok now /usr/lib/xorg/modules/dri/pvr_dri.so | 22:34 |
| freemangordon | and? does it work? | 22:34 |
| tmlind | yes with that export it now works :) but why is that now needed? | 22:35 |
| freemangordon | no idea, but somehow mesa is unable to load the correctr dri driver | 22:35 |
| tmlind | weird | 22:36 |
| tmlind | maybe some version check for preference? | 22:36 |
| freemangordon | will have to investigate but that's of low prio TBH | 22:36 |
| freemangordon | have to fix the resource leak first :) | 22:36 |
| uvos | glmark2 Score: 72 | 22:39 |
| uvos | (this is android) | 22:39 |
| uvos | (ddk1.9) | 22:39 |
| tmlind | fyi no luck with starting sway here with that export, sgx is found but complains about some dmabuf stuff | 22:39 |
| freemangordon | well, I removed some not supported stuff, maybe I shaved too much | 22:40 |
| freemangordon | will need steps to repro, to see what is missing | 22:40 |
| uvos | android results are interesing | 22:40 |
| uvos | some stuff is slower | 22:40 |
| uvos | some stuff is way faster | 22:40 |
| uvos | wierd | 22:41 |
| uvos | gets 28 fps on desktop with blur | 22:41 |
| tmlind | freemangordon: looks like the error with wlroots and sway is [wlr] [render/egl.c:718] Failed to query number of dmabuf formats, needs to check that it works with my old branch i guess | 22:42 |
| freemangordon | hmm, yeah | 22:43 |
| freemangordon | could I have removed more than have to | 22:43 |
| tmlind | anyways nice to see that at least glmrk2-es2-drm now finally works :) | 22:43 |
| freemangordon | keep in mind I reverted "egl_dri2: Don't expose EXT_image_dma_buf_import_modifiers" patch | 22:44 |
| tmlind | i guess i should try that with my old branch (jonathan's stuff) with the export | 22:44 |
| freemangordon | could be related | 22:44 |
| tmlind | i think i have that reverted too | 22:44 |
| tmlind | i also had few experimental backports from upstream mesa while debugging the render node usage issues with wlroots | 22:45 |
| tmlind | ah right no, jonathan added that because of wlroots, let me try adding it back | 22:47 |
| tmlind | yup with that added back sway now also works for me :) | 22:51 |
| freemangordon | :) | 22:51 |
| freemangordon | I only need to fix that memleak and we're fine | 22:51 |
| tmlind | looks like glmark2-es2-wayland no longer causes sgx oops, but a segfault now | 22:52 |
| freemangordon | heh | 22:53 |
| freemangordon | that's better, no? | 22:53 |
| tmlind | sure | 22:54 |
| tmlind | (gdb) | 22:54 |
| tmlind | #0 0xb6ef322e in wl_proxy_add_listener () from /usr/lib/libwayland-client.so.0 | 22:54 |
| tmlind | #1 0xb6d27502 in wl_buffer_add_listener (data=0xb6d50840, listener=0xb6d44358 <wl_buffer_listener>, wl_buffer=<optimized out>) at /usr/include/wayland-client-protocol.h:1943 | 22:54 |
| tmlind | #2 dri2_wl_swap_buffers_with_damage (disp=0xb6d4ece0, draw=0xb6d50840, rects=0x0, n_rects=0) at ../src/egl/drivers/dri2/platform_wayland.c:1105 | 22:54 |
| tmlind | #3 0xb6d20304 in dri2_swap_buffers (disp=0xb6d4ece0, surf=0xb6d50840) at ../src/egl/drivers/dri2/egl_dri2.c:2001 | 22:54 |
| tmlind | #4 0xb6d1888a in eglSwapBuffers (dpy=0xb6d4ece0, surface=<optimized out>) at ../src/egl/main/eglapi.c:1341 | 22:54 |
| freemangordon | you should install debug symbols for /usr/lib/libwayland-client.so.0 | 22:55 |
| tmlind | yeh will do that when i get a chance, early wakeup coming, ttyl | 22:57 |
| freemangordon | ttyl | 22:57 |
| uvos | wierd my build dident make pvr_dir.so at all | 23:32 |
| uvos | configure shows dri-drivers [pvr] | 23:32 |
| uvos | hmm | 23:32 |
| uvos | anyhow gn8 | 23:33 |
| freemangordon | yes, it doesn;t | 23:33 |
| freemangordon | it does one huge so called mesa_drivers_something.so | 23:33 |
| uvos | oh ok | 23:33 |
| uvos | do builing it via dpkg-buildpackage must use other options | 23:34 |
| freemangordon | libmesa_dri_drivers.so | 23:34 |
| uvos | that builds the drivers seperate | 23:34 |
| freemangordon | you should rename that to pvr_dri.so | 23:34 |
| freemangordon | and copy it | 23:34 |
| freemangordon | hmm, somehow I fixed the memory leak :) | 23:34 |
| freemangordon | and xorg glmark now runs fine :) | 23:35 |
| freemangordon | glmark2 Score: 81 | 23:36 |
| uvos | ok i can confirm glmark -drm works now | 23:36 |
| freemangordon | this score ^^^ is from glmark xorg | 23:37 |
| uvos | thats nuts | 23:37 |
| uvos | that exceeds android | 23:37 |
| freemangordon | drm shows less because of vsync | 23:37 |
| freemangordon | no java here ;) | 23:37 |
| uvos | wel glmark is a ndk application | 23:37 |
| uvos | but yeah newer drivers too | 23:37 |
| freemangordon | let me see what will be the result with --fullscreen | 23:38 |
| uvos | whait how big was that frame? | 23:38 |
| uvos | android result is fs ofc | 23:38 |
| freemangordon | default :) | 23:38 |
| uvos | ok android glmark can only do fullscreen | 23:38 |
| freemangordon | no idea what glmark/xorg use for default | 23:38 |
| freemangordon | it is slower on fullscreen | 23:40 |
| freemangordon | fullscreen glmark2 Score: 73 | 23:44 |
| freemangordon | still more than android | 23:44 |
| sicelo | have you had a chance to check it out on N900? what's the performance like there? | 23:58 |
| freemangordon | no, will do tomorrow | 23:58 |
| freemangordon | but I expect similar results | 23:59 |
| freemangordon | I mean - not 73 ofc | 23:59 |
| freemangordon | but something like 40-45 | 23:59 |
| freemangordon | too late here | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!