| sunshavi | https://blog.emacsen.net/blog/2021/08/23/floss-mobile-os-aug-2021/ | 03:45 |
|---|---|---|
| dreamer | sunshavi: tssk. doesn't even mention maemo-leste | 08:22 |
| lel | parazyd created a repository: https://github.com/maemo-leste/openvpn-network-applet | 11:11 |
| uvos | tmlind_: we really need to get of ddk1.9 :( | 12:01 |
| tmlind_ | uvos: yeah that thing is a big blocker :( | 12:02 |
| uvos | could you update ts-buttons from the original repo next time | 12:03 |
| uvos | instead of merging it | 12:03 |
| uvos | there is a (minor) bug fix in there | 12:03 |
| uvos | i should also try again to merge it ..... | 12:03 |
| tmlind_ | ok i guess i should script it | 12:03 |
| tmlind_ | and i need to sort out all the sucky modem gsmtty stuff.. | 12:03 |
| uvos | so far i have not been able to get anyone to comment on it even on the input ml | 12:03 |
| tmlind_ | heh yeah | 12:04 |
| uvos | which is annoying | 12:04 |
| tmlind_ | hmm so what can we do get stuff working with ddk-1.17 instead of ddk-1.9? | 12:04 |
| uvos | no one is working on it right now | 12:04 |
| uvos | so in theory it should work but there are lots of bugs | 12:04 |
| tmlind_ | heh | 12:05 |
| uvos | and its allways really hard to decern if its the blobs fault | 12:05 |
| tmlind_ | you mean fmg's test app? | 12:05 |
| uvos | https://github.com/maemo-leste/bugtracker/issues/524 | 12:05 |
| uvos | read the log here | 12:05 |
| tmlind_ | ok | 12:05 |
| uvos | there are 2 methods | 12:06 |
| uvos | a main problem here being that none of us know if what glamor dose it to spec or not | 12:06 |
| tmlind_ | no idea | 12:07 |
| tmlind_ | so we currently get noting on the screen with pvr_egl_shim? | 12:07 |
| uvos | we do | 12:07 |
| tmlind_ | oh | 12:07 |
| uvos | its glamors own rendering that breaks | 12:08 |
| uvos | and then there is wierd stuff like pvr just breaking depending on where you glfinish | 12:08 |
| tmlind_ | sounds like it could be glamor missing some gles parts? | 12:08 |
| uvos | and n900 flat out not working at all | 12:08 |
| uvos | no it uses the egl/gbm interfaces in ways that are unclear if its compatible with gles | 12:09 |
| tmlind_ | heh ok | 12:09 |
| uvos | mesa swalows this fine but who knows | 12:09 |
| tmlind_ | can we somehow test the approach on gles without pvr on some hardware? | 12:10 |
| uvos | it works on radionsi | 12:10 |
| tmlind_ | but that's not gles? | 12:10 |
| uvos | i forced patched glamor into gles mode | 12:10 |
| uvos | radionsi also supports gles ofc | 12:11 |
| tmlind_ | ok.. may not still be gles only? | 12:11 |
| uvos | well its useing libgles | 12:11 |
| uvos | ofc the gl support in egl might make a difference | 12:11 |
| tmlind_ | hmm but i guess if you patched it to force gles that answers the question :) | 12:11 |
| uvos | i have no idea really | 12:11 |
| tmlind_ | anything else we can do to test it individually for smaller components? | 12:12 |
| uvos | not really so fmg wrote his test app and it narrows it down to a call that glamor dose | 12:13 |
| uvos | if you reproduce glamors path in it it breaks | 12:13 |
| uvos | and if you do it a different way it works | 12:13 |
| uvos | we dont know if the glamor path is illigal | 12:13 |
| uvos | or pvr is buggy | 12:14 |
| Wizzup | right, and I think you said that if what glamor does is illegal, we have to fix up all the places where it does it wrong | 12:14 |
| uvos | right | 12:15 |
| uvos | even then the performance is wierd, and fmg had to introduce glfinish in random places to make it work | 12:15 |
| Wizzup | That does kind of sound like pvr has some problems | 12:16 |
| Wizzup | but iirc we had no place to report potential issues, other than some forums, I guess? | 12:16 |
| uvos | no idea | 12:17 |
| uvos | i gues the best path is to repo it on some chip ti still has in its catalog | 12:17 |
| uvos | ie the industrial variants of the omap4 | 12:17 |
| tmlind_ | fyi, pvr ddk-1.17 with wayland works surprisingly well with the patches we carry, kind of makes me suspect the issue is in glamor | 12:18 |
| uvos | tmlind_: well one thing is | 12:18 |
| uvos | that the performance on plain drm/gbm is mutch lower than on wayland | 12:18 |
| uvos | which makes no sense | 12:18 |
| uvos | and is nothing we could be at fault for | 12:19 |
| Wizzup | uvos: which devices are that? | 12:19 |
| uvos | the d4 and yes this could be an interaction with the command mode display | 12:20 |
| Wizzup | uvos: sorry, I mean the supported ones | 12:20 |
| uvos | might be usefull to have mz617 working to ellimitae that possibility | 12:20 |
| uvos | AM4379 for instance | 12:22 |
| uvos | there are several | 12:22 |
| uvos | i think tmlind_ is knowlagble on what ti processors are based on omap4 platform | 12:22 |
| tmlind_ | i think am43 has still pvr530 | 12:24 |
| tmlind_ | for mz617, there seem to be lots of issues with drivers/gpu/drm/bridge currently, seems like many bridge drivers are having issues right now | 12:24 |
| tmlind_ | i guess the patches to move to use drm atomic functions caused some issues for bridges | 12:25 |
| uvos | thats good to hear in a way | 12:25 |
| tmlind_ | also bridges on i2c bus have extra issues with the two possible probe paths | 12:25 |
| uvos | at least a suspect problem is well known | 12:26 |
| uvos | i have not found the time yet to look at mz617 at all since i decided to get calls working first ;) | 12:26 |
| tmlind_ | yeah best to ask around from folks using bridges for mz617 and wait a bit to let things settle | 12:26 |
| tmlind_ | yeh me neither | 12:26 |
| tmlind_ | i doubt anybody at ti is going to spend any time on the pvr issue we have, we need to come up with some other solutions | 12:27 |
| uvos | we can probubly patch glamor to high heaven and make it work | 12:27 |
| uvos | but its not fun work | 12:28 |
| uvos | since it feals very random when pvr decides to work an when not | 12:28 |
| Wizzup | Could it be a problem in kernel comms somehow? | 12:28 |
| tmlind_ | could it be some pm related issue? | 12:28 |
| uvos | so manny questions :P | 12:28 |
| uvos | i wish i knew | 12:28 |
| tmlind_ | we need to establish some bounty for fixing this :) | 12:29 |
| Wizzup | we could probably | 12:29 |
| uvos | we can then have a modesetting ddx fork that we patch to load glamor-prv | 12:29 |
| uvos | and then have package it seperately | 12:29 |
| uvos | so a hacked ddx would be ok packaging wise | 12:29 |
| uvos | (ie you want to be able to use regular modesetting on pp) | 12:30 |
| tmlind_ | so what happens with pvr_egl_shim on pinephone? that should be gles only, right? | 12:31 |
| uvos | pp supports gl | 12:31 |
| tmlind_ | oh | 12:31 |
| tmlind_ | well wlroots needs some patches for the gles calls and i guess fmg fixed up xorg also for some gles calls | 12:33 |
| tmlind_ | are there any glTexSubImage2D GL_TEXTURE_2D calls in glamor path? | 12:34 |
| uvos | yeah | 12:35 |
| uvos | thats what breaks | 12:35 |
| uvos | on egl textures | 12:35 |
| uvos | not gl | 12:35 |
| uvos | EGL_KHR_ | 12:35 |
| tmlind_ | some calls need gles version specific handling | 12:35 |
| uvos | doc? | 12:36 |
| tmlind_ | mostly xcracer's wlroots patch | 12:36 |
| tmlind_ | but that patch does not include EGL_KHR_, not sure if wlroots already has some handling for those? | 12:37 |
| tmlind_ | yeah grepping wlroots for EGL_KHR_ shows some version specific handling | 12:38 |
| tmlind_ | $ git grep -C10 EGL_KHR_ | grep check_egl_ext | 12:39 |
| tmlind_ | render/egl.c- if (!check_egl_ext(client_exts_str, "EGL_EXT_platform_base")) { | 12:39 |
| tmlind_ | render/egl.c: if (check_egl_ext(client_exts_str, "EGL_KHR_debug")) { | 12:39 |
| tmlind_ | render/egl.c: if (check_egl_ext(display_exts_str, "EGL_KHR_image_base")) { | 12:39 |
| tmlind_ | render/egl.c- check_egl_ext(display_exts_str, "EGL_EXT_buffer_age"); | 12:39 |
| tmlind_ | render/egl.c: if (check_egl_ext(display_exts_str, "EGL_KHR_swap_buffers_with_damage")) { | 12:39 |
| tmlind_ | render/egl.c- } else if (check_egl_ext(display_exts_str, | 12:39 |
| uvos | could you link xcracer patch too | 12:42 |
| uvos | or the commit id | 12:43 |
| uvos | if its in mainline wlroots | 12:43 |
| tmlind_ | i think it's in the pmos bugzilla entry | 12:47 |
| tmlind_ | that should be added to the ml bug page if not there | 12:47 |
| tmlind_ | this one: https://gitlab.com/postmarketOS/pmaports/-/issues/932 | 12:48 |
| tmlind_ | see patch attached there, 0001-render-Don-t-use-GL_EXT_unpack_subimage-when-not-ava.patch | 12:50 |
| tmlind_ | heh see also the comment there: ".. I've tried xfce4 but the blobs are missing an extension (GL_OES_texture_border_clamp) required by glamor for modesetting plus according to the Maemo guys there's other issues with gles2 and glamor/modesetting." | 12:54 |
| uvos | i need to setup an enviroment to play with this again | 13:00 |
| uvos | i gues i have an extra xt875 i can dedicate to the task | 13:00 |
| tmlind_ | with wlroots, without the GL_TEXTURE_2D handling as in the patch there was no output in sway, just window frames | 13:20 |
| tmlind_ | maybe it's possible to test on some different hardware if pvr_egl_shim works with gles3 but fail with gles2 as on these pvr using devices | 13:35 |
| tmlind_ | like for example the pvr docs describe for GL_OES_texture_border_clamp at https://docs.imgtec.com/Architecture_Guides/Supported_Extensions_OpenGL_ES_EGL/topics/d0e7745.html | 13:36 |
| tmlind_ | hmm so maybe that page explains why GL_CLAMP_TO_EDGE is needed for gles2 | 13:44 |
| tmlind_ | i don't understand though, does these pages show how to implement the missing extensions for pvr or what? | 13:50 |
| tmlind_ | like does the example for GL_EXT_texture_border_clamp show how to implement it? https://docs.imgtec.com/Architecture_Guides/Supported_Extensions_OpenGL_ES_EGL/topics/d0e3348.html | 13:51 |
| tmlind_ | or is GL_EXT_texture_border_clamp just an extension name for gl? | 13:51 |
| * tmlind_ confused | 13:51 | |
| uvos | its a extension name for gles too | 13:52 |
| uvos | but its only implmented for gpus > sgx | 13:52 |
| tmlind_ | ok | 13:52 |
| tmlind_ | note to self, some more info on CLAMP_TO_EDGE at https://www.opengl.org/archives/resources/code/samples/sig99/advanced99/notes/node64.html | 13:56 |
| tmlind_ | heh maybe we can just file an xfce4 bug saying pvr with gles2 does not work :) | 14:00 |
| uvos | xD | 15:23 |
| freemangordon | uvos: IIRC, with the latest kernel I tried, gbm performance was ok | 20:06 |
| freemangordon | 5.10 or 5.11 | 20:06 |
| freemangordon | can;t remember | 20:06 |
| freemangordon | ok, it seems indent pointer bug is triggered by typedef-ed struct. It seems it thinks this is multiply, not declaration. | 20:15 |
| freemangordon | Wizzup: do you know any other tool than indent? | 20:17 |
| freemangordon | there is some uncrustify thingie, going to check it | 20:23 |
| uvos | you cant turn off it changeing the postion of * | 20:43 |
| uvos | ? | 20:43 |
| uvos | would be an obvious option to add | 20:43 |
| uvos | since its totaly impossible to detemine if something is a mult or a pointer based on just one source file | 20:43 |
| uvos | hm which makes me wonder | 20:49 |
| uvos | how dose the compiler know what this means: | 20:50 |
| uvos | int number = 10; | 20:50 |
| freemangordon | uvos: you can't turn it off | 20:50 |
| uvos | Klass *somepointer | 20:50 |
| freemangordon | uncrustify seems promising | 20:50 |
| uvos | some_function(number*somepointer); | 20:50 |
| freemangordon | it has couple of hundred options :D | 20:51 |
| uvos | freemangordon: heh | 20:51 |
| freemangordon | but seem syou can fine tune it, if you find the option you need, ofc ;) | 20:51 |
| uvos | so in the above example am i multiplying the pointer adress by 10 or am i derefencing it and mult that by 10 | 20:52 |
| uvos | how dose the compiler now | 20:52 |
| uvos | *know | 20:52 |
| uvos | oh right dereference would be number**somepointer | 20:52 |
| uvos | nvm | 20:53 |
| freemangordon | https://en.cppreference.com/w/c/language/operator_precedence | 20:53 |
| freemangordon | :p | 20:53 |
| freemangordon | but, as I am never sure, I always put braces | 20:53 |
| uvos | yeah nvm its not ambiguous | 20:55 |
| uvos | i was confused | 20:55 |
| freemangordon | I think this https://github.com/uncrustify/uncrustify will do the job | 20:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!