| freemangordon | Wizzup: qt gl load fails on beowulf as well, I guess the reason being https://github.com/qt/qtbase/commit/aa21ac1043d58b9749077a237aab51e14f06d16e | 09:09 |
|---|---|---|
| freemangordon | so, we have no option but to build 'our' gl plugins | 09:10 |
| freemangordon | Wizzup: https://github.com/maemo-leste/qt-platform-maemo/pull/1 | 09:28 |
| Wizzup | freemangordon: ty, building for chimaera | 10:27 |
| freemangordon | Wizzup: tried to build locally on d4, ended up with: | 10:28 |
| freemangordon | dpkg-shlibdeps: warning: symbol __aeabi_atexit@CXXABI_ARM_1.3.3 used by debian/qt-platform-maemo/usr/lib/arm-linux-gnueabihf/libQt5XcbMaemoQpa.so.5.15.2 found in none of the libraries | 10:28 |
| freemangordon | any idea what that might be? | 10:28 |
| freemangordon | hmm https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978551 | 10:30 |
| Wizzup | freemangordon: looks like CI failed too | 10:32 |
| Wizzup | but only on amd64 | 10:32 |
| freemangordon | failed? weird, I saw no issue in the VM | 10:33 |
| Wizzup | sorry | 10:34 |
| Wizzup | amd64 was fine | 10:34 |
| Wizzup | armhf/arm64 is not | 10:34 |
| freemangordon | oh | 10:34 |
| freemangordon | #include <xcb/glx.h> | 10:34 |
| freemangordon | forgot that dependency | 10:35 |
| freemangordon | lemme fix it | 10:35 |
| Wizzup | ok | 10:35 |
| Wizzup | freemangordon: you can push & retag, no need for a new PR | 10:35 |
| freemangordon | sure | 10:36 |
| freemangordon | WTF? : | 10:40 |
| freemangordon | "maemo platform not yet supported" | 10:40 |
| Wizzup | hm? | 10:40 |
| freemangordon | qtwebbrowser | 10:40 |
| Wizzup | yes this is what uvos said | 10:40 |
| Wizzup | it hardcodes some platforms it seems | 10:40 |
| freemangordon | how nice | 10:40 |
| Wizzup | iiuc | 10:40 |
| freemangordon | seems I have missed what uvos said :) | 10:41 |
| freemangordon | so, who maintains that? | 10:41 |
| Wizzup | well the package is maintained by him, but it's not clear if this is in the package or in the lib the package uses | 10:42 |
| Wizzup | grep -r platform doesn't give any hits in the repo | 10:42 |
| freemangordon | /usr/lib/arm-linux-gnueabihf/libQt5WebEngineCore.so.5 | 10:44 |
| Wizzup | yeah. if we can avoid forking that... | 10:44 |
| freemangordon | lemme see | 10:44 |
| Wizzup | maybe we can change our name in the json and not in the plugin or something silly | 10:44 |
| freemangordon | yeah | 10:44 |
| Wizzup | see maemo.json for the name I think | 10:45 |
| Wizzup | Q_PLUGIN_METADATA(IID QPlatformIntegrationFactoryInterface_iid FILE "maemo.json") | 10:45 |
| freemangordon | lemme first see what it looks for | 10:45 |
| Wizzup | 17:45 < uvos> qwebengine is (or was in beowulf at least) hardcoded to only try gles on xcb or wayland platform modules | 10:46 |
| Wizzup | 17:46 < uvos> it tests(ed) on name | 10:46 |
| freemangordon | https://code.qt.io/cgit/qt/qtwebengine.git/tree/src/core/content_browser_client_qt.cpp?h=5.15.12#n234 | 10:50 |
| freemangordon | we cannot easily duplicate the platform name | 10:57 |
| freemangordon | as we don;t control the order the plugins are created in | 10:57 |
| freemangordon | I think what we shall do is replace xcb plugin | 11:00 |
| freemangordon | dpkg-divert and such | 11:00 |
| uvos__ | thats a terrible idea | 11:17 |
| uvos__ | since plenty of applications dont work with the maemo plugin | 11:17 |
| uvos__ | also since for now qwebengine not using gles is a blessing in disguise, since it renders black with plenty of errors | 11:18 |
| uvos__ | so we have time | 11:18 |
| freemangordon | uvos__: well, what is the other option? fork qwebengine? | 11:19 |
| uvos__ | so why dont we try petition qt to add "maemo" or give qwebengine a envvar to overide the list | 11:19 |
| freemangordon | I am fine, but Wizzup does not seem to like it :) | 11:19 |
| uvos__ | sure we would have to fork it then at least until debian next | 11:20 |
| freemangordon | ok | 11:20 |
| freemangordon | and we have to fix chrome engine to actually work | 11:20 |
| uvos__ | wrt opengl errors | 11:21 |
| freemangordon | right | 11:21 |
| uvos__ | yeah that needs to be fixed first | 11:21 |
| uvos__ | unill then it trying gles is good anyhow | 11:21 |
| uvos__ | *no trying | 11:21 |
| uvos__ | *not | 11:21 |
| uvos__ | grr | 11:21 |
| freemangordon | well, we already fixed that on chimaera | 11:21 |
| freemangordon | 'fixed' | 11:22 |
| freemangordon | so it tries and fails | 11:22 |
| uvos__ | ok | 11:22 |
| freemangordon | I wonder why it aborts instead if just not loading gl | 11:22 |
| uvos__ | ok | 11:23 |
| uvos__ | this is different than on beowulf | 11:23 |
| uvos__ | there it rendered black | 11:23 |
| uvos__ | but otherwise "worked" | 11:23 |
| freemangordon | no, it is same | 11:23 |
| freemangordon | if you do QT_QPA_PLATFORM=xcb it will render black | 11:24 |
| uvos__ | yes ok its the same | 11:24 |
| uvos__ | i thougt abort ment it asserted or something | 11:24 |
| freemangordon | with QT_QPA_PLATFORM=maemo (and fixed maemo platform plugin), it aborts, because of https://code.qt.io/cgit/qt/qtwebengine.git/tree/src/core/content_browser_client_qt.cpp?h=5.15.12#n260 | 11:24 |
| freemangordon | yes,, qFatal() | 11:24 |
| uvos__ | right i mean with xcb | 11:25 |
| uvos__ | with maemo it did not abort on beowulf | 11:25 |
| uvos__ | it worked in sw | 11:25 |
| freemangordon | Wizzup: please, fork qtwebengine from chimaera | 11:25 |
| freemangordon | uvos__: right, but maemo platform plugin was not supporting gl plugins | 11:26 |
| freemangordon | now it does https://github.com/maemo-leste/qt-platform-maemo/commit/613a6e48eca1679bf315e4720079b1dae764afc9 | 11:26 |
| uvos__ | hmm but it got to the code there "%s platform not yet supported" | 11:26 |
| uvos__ | on beowulf | 11:26 |
| uvos__ | thats how i knew | 11:26 |
| uvos__ | about this list | 11:26 |
| freemangordon | no idea how did you manage to do it | 11:27 |
| uvos__ | hm | 11:27 |
| norayr | I broke my xperia's screen in the late december so for days i only have droid4 and pinephone. I don't want another android phone and i dont want to spend money on such a thing, so i will exclusively live under these two - droid4 and pp. | 12:48 |
| norayr | On pp under maemo currently it is impossible to charge the kbd and phone. If left alone without load on charge it looses 2% per day. | 12:50 |
| norayr | I know there are kbd charging improvements in newer kernels on pmos, not sure about mainline. | 12:51 |
| sicelo | 2% per day? that's kbd or phone? | 13:01 |
| Wizzup | freemangordon: we can fork it but it will take days to compile iirc | 13:03 |
| freemangordon | Wizzup: so, what are the options? | 13:05 |
| freemangordon | there is some bug in chromium we shall fix either ways | 13:05 |
| Wizzup | ok | 13:06 |
| Wizzup | I just hope it will work on ci | 13:06 |
| Wizzup | we'll see | 13:06 |
| freemangordon | git does not | 13:06 |
| freemangordon | apt-get source did | 13:06 |
| freemangordon | (in VM) | 13:06 |
| Wizzup | right, we need to get it from salsa | 13:07 |
| freemangordon | yes, from salsa ;) | 13:07 |
| Wizzup | uvos__: btw, any info and code you can share on elogind is welcome, I can't even install blueman without it | 13:08 |
| Wizzup | or just a status so I can take a look and start helping out | 13:09 |
| freemangordon | udisks2 depends on it too | 13:14 |
| uvos__ | Wizzup: theres not more than is packaged, besides some hacks to vaious init scipts i have on a local machine to avoid loading things that break in the xdg session, avoid loading the xsession etc | 13:16 |
| uvos__ | so packaged here is autologin/h-s/tindm | 13:17 |
| uvos__ | but as mentined before the session work is tangential, since you dont have to use elogind, jus have it installed | 13:18 |
| uvos__ | so what we really need is expiramental packages that remove the conflicts with elogind and remvoe the forks that disable it (like in xorg) | 13:18 |
| uvos__ | and then running the old xsession and seeing what breaks | 13:19 |
| uvos__ | i can runn most everything via hildon-session in vm however with elogind with no issues | 13:19 |
| uvos__ | that i have found anyhow | 13:19 |
| uvos__ | (besides dependancy hell in the init scripts) | 13:19 |
| Wizzup | uvos__: ok, so I need to start with the packages you made and then check conflicts? | 13:50 |
| Wizzup | what will run the x session? | 13:50 |
| uvos__ | h-s runs the scripts of the xsession itself | 13:51 |
| uvos__ | well most of them, i have jus the basic ones in there on vm | 13:51 |
| uvos__ | Wizzup: best thing for you to do | 13:52 |
| uvos__ | would be first to remvoe elogind conflicts and the xorg logind disable and depends on the xsession/xorg/h-d init script in expiramental | 13:53 |
| uvos__ | since setting up hildon-session with those in place is a pain | 13:53 |
| uvos__ | (you have to build x + meta localy and edit alot of scripts to get anything to work) | 13:54 |
| Wizzup | uvos__: ok | 14:10 |
| Wizzup | uvos__: I will set up the chimaera -testing, -devel and -experimental parts | 14:11 |
| Wizzup | norayr: that sounds good @ kbd | 14:18 |
| Wizzup | freemangordon: chimaera, chimaera-testing, chimaera-devel, chimaera-experimental ? | 14:46 |
| freemangordon | mhm | 14:47 |
| freemangordon | uvos__: seems glslcompiler error is 'fixed' if --no-sandbox is passed to chromium | 15:31 |
| uvos__ | that makes sense | 15:34 |
| uvos__ | not that i know why exactly its hapening | 15:34 |
| uvos__ | but the engine sanbox is a pretty radical enviroment to dlopen a lib in | 15:35 |
| Wizzup | freemangordon: so do you want me to try to build qtwebengine fork? | 16:05 |
| freemangordon | yes, why not | 16:05 |
| Wizzup | ok | 16:06 |
| Wizzup | this is to patch qt platform filter? | 16:06 |
| freemangordon | not only | 16:06 |
| freemangordon | and to hopefully fix qtwebengine to work on PVR | 16:06 |
| freemangordon | 31161 @1 glTexSubImage2D(target = GL_TEXTURE_2D, level = 0, xoffset = 0, yoffset = 0, width = 256, height = 256, format = GL_BGRA, type = GL_UNSIGNED_BYTE, pixels = blob(262144)) | 16:14 |
| freemangordon | 31161: warning: glGetError(glTexSubImage2D) = GL_INVALID_OPERATION | 16:14 |
| freemangordon | that's our issue with qtwebengine | 16:14 |
| freemangordon | glTexSubImage2D does not support GL_BGRA in es2 | 16:15 |
| freemangordon | afaik | 16:16 |
| freemangordon | hmm, actually it should be supported | 16:18 |
| freemangordon | because driver supports EXT_texture_format_BGRA8888 | 16:18 |
| Wizzup | freemangordon: this is the jail problem? | 16:59 |
| freemangordon | no | 16:59 |
| freemangordon | this is why qtwebbrowser does not work | 17:00 |
| Wizzup | ok | 17:00 |
| freemangordon | hmm, this smells like a bug in pvr driver :( | 17:29 |
| Wizzup | we have afd at least :) | 17:31 |
| freemangordon | do we? | 17:31 |
| freemangordon | I guess I have to create a basic test-case | 17:33 |
| freemangordon | Wizzup: do you remember how PVR trace was enabled? | 17:51 |
| Wizzup | freemangordon: no,sorry | 18:26 |
| freemangordon | oh, maybe the issue is with our mesa: | 21:01 |
| freemangordon | Mesa warning: Couldn't add glTexStorage2DEXT to the Mesa dispatch table | 21:01 |
| freemangordon | oh, ok, we have a couple of those | 21:05 |
| freemangordon | yep, this is the issue | 21:58 |
| freemangordon | our mesa does not support GL_EXT_texture_storage/glTexStorage2DEXT | 21:59 |
| freemangordon | why it returns pointer to noop function instead of NULL when eglGetProcAddress("glTexStorage2DEXT") is called is mystery to me :( | 22:01 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!