lyubov_ has quit [Ping timeout: 268 seconds]
lyubov_ has joined #maemo-leste
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
<dreamer> sunshavi: tssk. doesn't even mention maemo-leste
inky_ has quit [Ping timeout: 252 seconds]
inky has quit [Ping timeout: 252 seconds]
inky_ has joined #maemo-leste
<lel> parazyd created a repository: https://github.com/maemo-leste/openvpn-network-applet
uvos has joined #maemo-leste
<uvos> tmlind_: we really need to get of ddk1.9 :(
<tmlind_> uvos: yeah that thing is a big blocker :(
<uvos> could you update ts-buttons from the original repo next time
<uvos> instead of merging it
<uvos> there is a (minor) bug fix in there
<uvos> i should also try again to merge it .....
<tmlind_> ok i guess i should script it
<tmlind_> and i need to sort out all the sucky modem gsmtty stuff..
<uvos> so far i have not been able to get anyone to comment on it even on the input ml
<tmlind_> heh yeah
<uvos> which is annoying
<tmlind_> hmm so what can we do get stuff working with ddk-1.17 instead of ddk-1.9?
<uvos> no one is working on it right now
<uvos> so in theory it should work but there are lots of bugs
<tmlind_> heh
elastic_dog has quit [Ping timeout: 240 seconds]
<uvos> and its allways really hard to decern if its the blobs fault
<tmlind_> you mean fmg's test app?
<uvos> read the log here
<tmlind_> ok
<uvos> there are 2 methods
<uvos> a main problem here being that none of us know if what glamor dose it to spec or not
<tmlind_> no idea
<tmlind_> so we currently get noting on the screen with pvr_egl_shim?
<uvos> we do
<tmlind_> oh
<uvos> its glamors own rendering that breaks
<uvos> and then there is wierd stuff like pvr just breaking depending on where you glfinish
<tmlind_> sounds like it could be glamor missing some gles parts?
<uvos> and n900 flat out not working at all
<uvos> no it uses the egl/gbm interfaces in ways that are unclear if its compatible with gles
<tmlind_> heh ok
<uvos> mesa swalows this fine but who knows
<tmlind_> can we somehow test the approach on gles without pvr on some hardware?
<uvos> it works on radionsi
<tmlind_> but that's not gles?
<uvos> i forced patched glamor into gles mode
elastic_dog has joined #maemo-leste
<uvos> radionsi also supports gles ofc
<tmlind_> ok.. may not still be gles only?
<uvos> well its useing libgles
<uvos> ofc the gl support in egl might make a difference
<tmlind_> hmm but i guess if you patched it to force gles that answers the question :)
<uvos> i have no idea really
<tmlind_> anything else we can do to test it individually for smaller components?
<uvos> not really so fmg wrote his test app and it narrows it down to a call that glamor dose
<uvos> if you reproduce glamors path in it it breaks
<uvos> and if you do it a different way it works
<uvos> we dont know if the glamor path is illigal
<uvos> or pvr is buggy
<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
<uvos> right
<uvos> even then the performance is wierd, and fmg had to introduce glfinish in random places to make it work
<Wizzup> That does kind of sound like pvr has some problems
<Wizzup> but iirc we had no place to report potential issues, other than some forums, I guess?
<uvos> no idea
<uvos> i gues the best path is to repo it on some chip ti still has in its catalog
<uvos> ie the industrial variants of the omap4
<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
<uvos> tmlind_: well one thing is
<uvos> that the performance on plain drm/gbm is mutch lower than on wayland
<uvos> which makes no sense
<uvos> and is nothing we could be at fault for
<Wizzup> uvos: which devices are that?
<uvos> the d4 and yes this could be an interaction with the command mode display
<Wizzup> uvos: sorry, I mean the supported ones
<uvos> might be usefull to have mz617 working to ellimitae that possibility
<uvos> AM4379 for instance
<uvos> there are several
<uvos> i think tmlind_ is knowlagble on what ti processors are based on omap4 platform
<tmlind_> i think am43 has still pvr530
<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
<tmlind_> i guess the patches to move to use drm atomic functions caused some issues for bridges
<uvos> thats good to hear in a way
<tmlind_> also bridges on i2c bus have extra issues with the two possible probe paths
<uvos> at least a suspect problem is well known
<uvos> i have not found the time yet to look at mz617 at all since i decided to get calls working first ;)
<tmlind_> yeah best to ask around from folks using bridges for mz617 and wait a bit to let things settle
<tmlind_> yeh me neither
<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
<uvos> we can probubly patch glamor to high heaven and make it work
<uvos> but its not fun work
<uvos> since it feals very random when pvr decides to work an when not
<Wizzup> Could it be a problem in kernel comms somehow?
<tmlind_> could it be some pm related issue?
<uvos> so manny questions :P
<uvos> i wish i knew
<tmlind_> we need to establish some bounty for fixing this :)
<Wizzup> we could probably
<uvos> we can then have a modesetting ddx fork that we patch to load glamor-prv
<uvos> and then have package it seperately
<uvos> so a hacked ddx would be ok packaging wise
<uvos> (ie you want to be able to use regular modesetting on pp)
<tmlind_> so what happens with pvr_egl_shim on pinephone? that should be gles only, right?
<uvos> pp supports gl
<tmlind_> oh
<tmlind_> well wlroots needs some patches for the gles calls and i guess fmg fixed up xorg also for some gles calls
<tmlind_> are there any glTexSubImage2D GL_TEXTURE_2D calls in glamor path?
<uvos> yeah
<uvos> thats what breaks
<uvos> on egl textures
<uvos> not gl
<uvos> EGL_KHR_
<tmlind_> some calls need gles version specific handling
<uvos> doc?
<tmlind_> mostly xcracer's wlroots patch
<tmlind_> but that patch does not include EGL_KHR_, not sure if wlroots already has some handling for those?
inky has joined #maemo-leste
<tmlind_> yeah grepping wlroots for EGL_KHR_ shows some version specific handling
<tmlind_> $ git grep -C10 EGL_KHR_ | grep check_egl_ext
<tmlind_> render/egl.c- if (!check_egl_ext(client_exts_str, "EGL_EXT_platform_base")) {
<tmlind_> render/egl.c: if (check_egl_ext(client_exts_str, "EGL_KHR_debug")) {
<tmlind_> render/egl.c: if (check_egl_ext(display_exts_str, "EGL_KHR_image_base")) {
<tmlind_> render/egl.c- check_egl_ext(display_exts_str, "EGL_EXT_buffer_age");
<tmlind_> render/egl.c: if (check_egl_ext(display_exts_str, "EGL_KHR_swap_buffers_with_damage")) {
<tmlind_> render/egl.c- } else if (check_egl_ext(display_exts_str,
inky_ has quit [Ping timeout: 250 seconds]
<uvos> could you link xcracer patch too
<uvos> or the commit id
<uvos> if its in mainline wlroots
<tmlind_> i think it's in the pmos bugzilla entry
<tmlind_> that should be added to the ml bug page if not there
<tmlind_> see patch attached there, 0001-render-Don-t-use-GL_EXT_unpack_subimage-when-not-ava.patch
<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."
<uvos> i need to setup an enviroment to play with this again
<uvos> i gues i have an extra xt875 i can dedicate to the task
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #maemo-leste
<tmlind_> with wlroots, without the GL_TEXTURE_2D handling as in the patch there was no output in sway, just window frames
Danct12 has quit [Remote host closed the connection]
<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
<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
<tmlind_> hmm so maybe that page explains why GL_CLAMP_TO_EDGE is needed for gles2
<tmlind_> i don't understand though, does these pages show how to implement the missing extensions for pvr or what?
<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
<tmlind_> or is GL_EXT_texture_border_clamp just an extension name for gl?
* tmlind_ confused
<uvos> its a extension name for gles too
<uvos> but its only implmented for gpus > sgx
<tmlind_> ok
<tmlind_> heh maybe we can just file an xfce4 bug saying pvr with gles2 does not work :)
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 248 seconds]
inky_ has quit [Remote host closed the connection]
inky has joined #maemo-leste
inky has quit [Ping timeout: 240 seconds]
<uvos> xD
inky has joined #maemo-leste
inky_ has joined #maemo-leste
xmn has joined #maemo-leste
inky has quit [Ping timeout: 240 seconds]
inky has joined #maemo-leste
mardy has quit [Quit: WeeChat 2.8]
Pali has joined #maemo-leste
xmn has quit [Ping timeout: 248 seconds]
inky has quit [Quit: IRC for Sailfish 0.9]
inky has joined #maemo-leste
inky has quit [Client Quit]
inky has joined #maemo-leste
<freemangordon> uvos: IIRC, with the latest kernel I tried, gbm performance was ok
<freemangordon> 5.10 or 5.11
<freemangordon> can;t remember
inky has quit [Quit: Leaving]
inky has joined #maemo-leste
<freemangordon> ok, it seems indent pointer bug is triggered by typedef-ed struct. It seems it thinks this is multiply, not declaration.
<freemangordon> Wizzup: do you know any other tool than indent?
<freemangordon> there is some uncrustify thingie, going to check it
<uvos> you cant turn off it changeing the postion of *
<uvos> ?
<uvos> would be an obvious option to add
<uvos> since its totaly impossible to detemine if something is a mult or a pointer based on just one source file
lexik has quit [Quit: Bella ciao.]
lexik has joined #maemo-leste
<uvos> hm which makes me wonder
<uvos> how dose the compiler know what this means:
<uvos> int number = 10;
<freemangordon> uvos: you can't turn it off
<uvos> Klass *somepointer
<freemangordon> uncrustify seems promising
<uvos> some_function(number*somepointer);
<freemangordon> it has couple of hundred options :D
<uvos> freemangordon: heh
<freemangordon> but seem syou can fine tune it, if you find the option you need, ofc ;)
<uvos> so in the above example am i multiplying the pointer adress by 10 or am i derefencing it and mult that by 10
<uvos> how dose the compiler now
<uvos> *know
<uvos> oh right dereference would be number**somepointer
<uvos> nvm
<freemangordon> :p
<freemangordon> but, as I am never sure, I always put braces
<uvos> yeah nvm its not ambiguous
<uvos> i was confused
<freemangordon> I think this https://github.com/uncrustify/uncrustify will do the job
Danct12 has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
_inky has joined #maemo-leste
inky has quit [Quit: Leaving]
uvos has quit [Ping timeout: 252 seconds]
Pali has quit [Ping timeout: 248 seconds]