| freemangordon | Wizzup: YAY! finally, YT sound on d4 :) | 09:13 |
|---|---|---|
| freemangordon | but not in FF, weird | 09:21 |
| Wizzup | maybe fx is muted? | 09:23 |
| freemangordon | but how and where. and by whom? | 09:26 |
| Wizzup | freemangordon: pulse can mute per app | 09:30 |
| Wizzup | maybe check pavucontrol | 09:30 |
| freemangordon | checked | 09:32 |
| freemangordon | firefox is there and is 100% | 09:32 |
| Wizzup | ok | 09:33 |
| freemangordon | it seems FF itself does not send any audio | 09:33 |
| freemangordon | seems default autoplay setting is "block audio" | 09:40 |
| freemangordon | nice | 09:40 |
| Wizzup | heh.. | 09:45 |
| freemangordon | yeah, setting UA to iphone makes all the diffference :) | 10:05 |
| freemangordon | I'll have to look at XV soon | 10:10 |
| freemangordon | Wizzup: BTW, do I need to run some manual calibration on wifi? | 10:14 |
| freemangordon | niiice, headphones work :) | 10:19 |
| Wizzup | freemangordon: calibration should be automatic | 10:52 |
| freemangordon | ok | 10:58 |
| Wizzup | on first boot at least | 11:13 |
| Wizzup | (of fresh sd card) | 11:13 |
| uvos | Wizzup: so charging sdl is still broken, because you remvoed directfb but did not enable kmsdrm in sdl2 | 12:01 |
| Wizzup | hmm | 12:17 |
| Wizzup | --enable-video-kmsdrm --disable-kmsdrm-shared \ | 12:17 |
| Wizzup | is that not ok? | 12:17 |
| uvos | https://github.com/maemo-leste-upstream-forks/libsdl2/blob/maemo/beowulf-devel/debian/rules | 12:18 |
| uvos | dont see it | 12:18 |
| uvos | oh you forgot to merge it into devel | 12:18 |
| Wizzup | argh | 12:22 |
| Wizzup | I merged locally but didn't push | 12:23 |
| Wizzup | let me fix | 12:23 |
| Wizzup | thanks for checking | 12:23 |
| Wizzup | building | 12:23 |
| uvos | great thanks | 12:24 |
| freemangordon | Wizzup: uvos: (^\s*xkb_symbols\s\"(.*)\"*.)?{((?:[^}{]*(?R)?)*+)} | 12:28 |
| freemangordon | I plan to use that to match in xkb symbols file | 12:28 |
| freemangordon | is there any obvious flaw? | 12:28 |
| uvos | i gues the obvious flaw is that is really hard for me to accern what this regex dose :P | 12:34 |
| uvos | but that might just be me | 12:34 |
| freemangordon | well, I am very bad at regexes so I use regex101 :) | 12:35 |
| freemangordon | but in short - it should extract symbols and contents of each symbols group | 12:35 |
| uvos | i get that | 12:36 |
| uvos | there sould be a full parser for xcb files too right? | 12:37 |
| uvos | why not use that? | 12:37 |
| freemangordon | because tehre is no | 12:37 |
| freemangordon | *there | 12:37 |
| uvos | really? | 12:37 |
| freemangordon | mhm | 12:37 |
| freemangordon | you can use some parser if you know what you look for | 12:37 |
| freemangordon | but, there is no ready lib that can provide you all the info in xkb files | 12:38 |
| uvos | ok wierd | 12:38 |
| freemangordon | at least I was not able to find one | 12:38 |
| freemangordon | agree | 12:38 |
| freemangordon | this is the latest (xkb_symbols\s\"(.*)\".*)?{((?:[^}{]*(?R)?)*+)} | 12:40 |
| Wizzup | uvos: libsdl2 is in repo | 12:48 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/sgx-ddk-um/pull/1 (weaken glib 2.29 symbol in libGLESv1) | 12:54 |
| Wizzup | building for -devel | 12:56 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste-extras/neverball-gles | 12:56 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste-extras/openlara | 12:57 |
| Wizzup | uvos: ^ | 12:58 |
| lel | IMbackK opened an issue: https://github.com/maemo-leste/bugtracker/issues/608 (Petition upstream debian/devuan to re enable GLESv1) | 13:00 |
| uvos | Wizzup: great | 13:01 |
| Wizzup | freemangordon: can you look at this? https://phoenix.maemo.org/job/sgx-ddk-um-binaries/architecture=armhf,label=armhf/31/console | 13:02 |
| Wizzup | freemangordon: looks like the RE'd code doesn't want to build | 13:02 |
| Wizzup | (also looks like we aren't actually shipping that RE'd code yet then?) | 13:02 |
| freemangordon | no, we are not | 13:02 |
| Wizzup | ok | 13:03 |
| freemangordon | will look at it later, have to attend work mtg | 13:03 |
| Wizzup | np | 13:03 |
| Wizzup | uvos: btw if you can please make sure the extras pkgs have this base64 encoded icon and maybe create a wiki entry for it | 13:06 |
| uvos | Wizzup: ok | 13:10 |
| uvos | Wizzup: btw, non urgent, but if you find the time at some point could you try sphone on the pp (all functions, calls sms etc). | 13:11 |
| uvos | Wizzup: if it works there compleatly ill promote it to stable for the first time | 13:11 |
| Wizzup | ok | 13:11 |
| Wizzup | yeah I can try that some time this week I think | 13:11 |
| uvos | Wizzup: aaand charging sdl still dosent work | 18:20 |
| uvos | Wizzup: now it segfaults in SDL_CreateWindow.. while on my localy build sdl2 its fine | 18:20 |
| Wizzup | uvos: hm, same HEAD? | 18:28 |
| uvos | no | 18:28 |
| uvos | i have --disable-video-opengl | 18:28 |
| Wizzup | hm, it'd not be ideal to have to add that | 18:33 |
| uvos | yeah | 18:33 |
| uvos | EGL client APIs: OpenGL OpenGL_ES | 18:35 |
| uvos | im thinking this might be a problem | 18:36 |
| uvos | (this is eglinfo) | 18:36 |
| uvos | its not reporting opengl as unavailbale | 18:36 |
| uvos | as it should | 18:36 |
| uvos | freemangordon: ^^^ | 18:38 |
| Wizzup | well is it not available via llvmpipe? | 18:53 |
| Wizzup | I guess not for this renderer | 18:53 |
| uvos | Wizzup: freemangordon: ok so i "fixed" it for now by having charge-mode force sdl to use a gles2 context, but there is a real problem here | 19:39 |
| uvos | creating a gl context via egl causes a segfault | 19:39 |
| uvos | it should just fail | 19:39 |
| Wizzup | understood | 19:45 |
| sicelo | fwiw, there's a real chance that pmOS will deprecate charging-sdl in the near future, in favor of lvgl based stuff. at least the sdl FDE unlocker is already in process of deprecation | 20:03 |
| uvos | our charging_sdl shares nothing with postmarket os's at this point except the code that draws the icon texture | 20:05 |
| uvos | so thats not a concern | 20:05 |
| uvos | sicelo: hmmm charging-lvgl basicly works like our charging-sdl | 20:12 |
| uvos | sicelo: and the defficanies reported in pmos -sdl is essantly what i thought too when i changed how it works | 20:12 |
| uvos | so this is failed co-operation at its finest | 20:14 |
| freemangordon | uvos: can you test with blobs? | 20:23 |
| sicelo | you mean you sent your charging-sdl patches or issues upstream and they didn't cooperate? | 20:24 |
| uvos | sicelo: no its also my fault, i thought the unesscarly complex way it worked in pmos was as intended | 20:25 |
| uvos | freemangordon: not right away | 20:25 |
| freemangordon | though, they may have disabled GL in mesa | 20:25 |
| uvos | probubly | 20:25 |
| freemangordon | this https://github.com/maemo-leste-upstream-forks/mesa/blob/maemo/beowulf-devel/src/mesa/drivers/dri/pvr/mesa_context.c#L93 is in original pvr_dri as well | 20:26 |
| uvos | for sgx 545 | 20:26 |
| uvos | i assume | 20:26 |
| freemangordon | no | 20:26 |
| uvos | yes | 20:26 |
| uvos | sgx 545 supports desktop gl | 20:27 |
| freemangordon | this is in 443x blobs | 20:27 |
| uvos | so those blobs support omap4470 | 20:27 |
| freemangordon | could be | 20:28 |
| freemangordon | however, they do dload of the relevant blobs | 20:28 |
| freemangordon | but, there is no libOGL, so I don't know how is that supposed to work | 20:29 |
| freemangordon | lemme check how chromeos deals with that | 20:29 |
| uvos | chomeos is for series6 | 20:30 |
| uvos | that also supports ogl | 20:30 |
| uvos | in all variants afaik | 20:30 |
| freemangordon | ok, lemme see 343x blob | 20:30 |
| freemangordon | uvos: hmm, actually no | 20:31 |
| uvos | hmm? | 20:32 |
| freemangordon | chromeos mesa pvr does not report PVRDRI_API_GL IIUC | 20:32 |
| uvos | ok | 20:32 |
| freemangordon | https://github.com/maemo-leste-upstream-forks/mesa/blob/fd8f099834b7b7c5767435104a36fe5ed3ef6b53/src/mesa/drivers/dri/pvr/pvrdri.c#L547 | 20:35 |
| freemangordon | this is chromeos | 20:35 |
| uvos | ok | 20:35 |
| freemangordon | https://github.com/maemo-leste-upstream-forks/mesa/blob/maemo/beowulf-devel/src/mesa/drivers/dri/pvr/pvrdri.c#L529 | 20:36 |
| freemangordon | this is the blob | 20:36 |
| uvos | maybe just remove the opengl line then | 20:36 |
| uvos | since it cant do any good | 20:36 |
| freemangordon | yes, but I wonder how is that supposed to work | 20:36 |
| uvos | it might be here for sgx545 and this is a subtle bug in the blobs | 20:37 |
| uvos | ie it dosent | 20:37 |
| freemangordon | yeah | 20:37 |
| freemangordon | lemme check how it loads the libs | 20:38 |
| uvos | have to check if this porblem exitst in full blob setup | 20:38 |
| freemangordon | mhm | 20:38 |
| freemangordon | blob tries to load libPVROGL.so | 20:39 |
| freemangordon | uvos: do you have some mesa build around? | 20:42 |
| freemangordon | as it will take me hours to build here | 20:42 |
| uvos | no sry | 20:43 |
| freemangordon | ok | 20:43 |
| freemangordon | also, how to test that the fix is proper? by using eglinfo? | 20:43 |
| uvos | good question | 20:45 |
| freemangordon | uvos: hmm, for X11 platform only OpenGL_ES is reported | 20:45 |
| uvos | yeah | 20:45 |
| uvos | its only a problem in plain drm | 20:45 |
| uvos | GBM platform: EGL client APIs: OpenGL OpenGL_ES | 20:45 |
| freemangordon | 'GBM platform' | 20:46 |
| freemangordon | mh | 20:46 |
| uvos | right | 20:46 |
| freemangordon | but why the difference? | 20:46 |
| uvos | no idea | 20:46 |
| freemangordon | Wizzup: ^^^ | 20:46 |
| freemangordon | so, we shall be consistent, no? | 20:46 |
| uvos | in x11 also sdl is fine | 20:46 |
| uvos | its with the kmsdrm backend it thinks it can go opengl | 20:46 |
| freemangordon | ok, lemme check in what state my mesa tree on d4 is | 20:47 |
| uvos | also its interesting that the GBM platform also dosent report any valid gl configs | 20:48 |
| uvos | but i gues thats to late for sdl | 20:48 |
| freemangordon | yeah, seems the decision has already been taken | 20:48 |
| freemangordon | ok, I'll just #ifdef OGL in pvr dri | 20:49 |
| freemangordon | bencoh: did you manage to do some mesa cross-compile instructions? | 20:50 |
| freemangordon | uvos: BTW, it is the same in 343x blob | 20:53 |
| freemangordon | so it is not about 545 | 20:54 |
| freemangordon | maybe they just limit the API with mesa build | 20:54 |
| freemangordon | hmm, actually why don;t we disable OGL in mesa? | 21:09 |
| freemangordon | I mean - it is already disabled for x11 | 21:09 |
| freemangordon | why shall we keep it for gbm? | 21:09 |
| freemangordon | Wizzup: ^^^ | 21:09 |
| Wizzup | hey | 21:19 |
| Wizzup | freemangordon: we build mesa for all devices | 21:19 |
| Wizzup | some can support opengl | 21:19 |
| Wizzup | e.g. pinephone does | 21:19 |
| Wizzup | and most adreno based devices will | 21:19 |
| freemangordon | Wizzup: the point is that opengl is disabled for x11 | 21:24 |
| freemangordon | why shall it be enabled for gbm? | 21:24 |
| freemangordon | we either enable it for bot or disable it for both, IIUC | 21:24 |
| freemangordon | *both | 21:24 |
| uvos | its not disabled for x11 is it | 21:26 |
| uvos | (explicitly, by us) | 21:27 |
| uvos | ? | 21:27 |
| uvos | afaik we disabled GLX on omap | 21:27 |
| uvos | but thats totaly unrleated to egl | 21:27 |
| freemangordon | well then why OGL is not reported for X11? | 21:29 |
| uvos | i dont know | 21:29 |
| * freemangordon boots PP | 21:30 | |
| freemangordon | on PP we have "EGL client APIs: OpenGL OpenGL_ES" for x11 | 21:35 |
| freemangordon | could it be some bug in mesa? | 21:35 |
| uvos | its possible | 21:36 |
| uvos | but hard to tell without some mesa supported gles only gpu | 21:36 |
| uvos | (are there any even !?) | 21:36 |
| freemangordon | also, I wonder how is a particular API detected | 21:36 |
| freemangordon | because you cannot create OGL context on sgx | 21:36 |
| freemangordon | unless I introduced some bug | 21:37 |
| * freemangordon checks | 21:37 | |
| uvos | freemangordon: well one thing that your re dosent do that the blobs did | 21:37 |
| uvos | was use llvmpipe in glx | 21:37 |
| uvos | glx now just fails | 21:37 |
| uvos | previously mesa just used llvmpipe | 21:37 |
| freemangordon | are you sure? | 21:38 |
| uvos | yes | 21:38 |
| uvos | but blobs here is ddk 1.9 | 21:38 |
| uvos | so im not sure its relevant | 21:38 |
| freemangordon | ah | 21:38 |
| freemangordon | test with 1.17 blobs | 21:38 |
| uvos | how | 21:38 |
| uvos | xorg dosent work | 21:39 |
| uvos | so no glx | 21:39 |
| freemangordon | LD_LIBRARY_PATH/LD_PRELOAD | 21:39 |
| uvos | GLX? | 21:39 |
| freemangordon | ah, yeah | 21:39 |
| freemangordon | sorry | 21:39 |
| freemangordon | well, I don;t know what they did | 21:39 |
| freemangordon | but do we really want llvmpipe for glx? | 21:39 |
| uvos | well there are apps that just dont work this way | 21:40 |
| uvos | but did work before | 21:40 |
| uvos | like linuxcnc | 21:40 |
| uvos | (even had fine performanec on llvmpipe) | 21:40 |
| uvos | also extreamly niche i know, but some cfd scientific software i use renders still images using glx, an i could view computation results on d4 over network/iglx before | 21:42 |
| freemangordon | uvos: I am afraid that if we enable glx, lot sof applications will prefer it over gles2 | 21:42 |
| uvos | freemangordon: sure but glx is a parameter in xorg.conf | 21:43 |
| uvos | freemangordon: so we could have it work on llvm and then disable it | 21:43 |
| uvos | but its not a big issue | 21:43 |
| uvos | this opengl reporing over egl on kms/drm is much more annyoing | 21:43 |
| freemangordon | uvos: I think you can override with export MESA_LOADER_DRIVER_OVERRIDE=swrast or somesuch | 21:45 |
| bencoh | freemangordon: afaict once you have a crosscompilation container ready it's pretty straightforward | 21:46 |
| freemangordon | uvos: MESA_LOADER_DRIVER_OVERRIDE=swrast glxgears works on d4 | 21:47 |
| uvos | ah ok | 21:48 |
| freemangordon | bencoh: where should I get one from? :) | 21:48 |
| uvos | the reason mesa dosent cose llvmpipe in the first place then is probubly because we need MESA_LOADER_DRIVER_OVERRIDE=pvr | 21:48 |
| bencoh | Wizzup: do we have a public lxc image for the crossbuilder somewhere? | 21:48 |
| freemangordon | no idea | 21:48 |
| freemangordon | bencoh: but anyway, I am already compiling on device | 21:48 |
| bencoh | ah :( | 21:49 |
| freemangordon | [600/2515] | 21:49 |
| freemangordon | :) | 21:49 |
| bencoh | want me to build it? :D | 21:49 |
| freemangordon | no, as I want to be able to make changes to test | 21:49 |
| bencoh | I see | 21:49 |
| bencoh | I wonder how large my current lxc container is, maybe I could share it | 21:50 |
| Wizzup | bencoh: no, would be nice if we did | 21:50 |
| bencoh | actually I could rebuild one and upload it maybe | 21:50 |
| bencoh | (3mbps upload from here) | 21:51 |
| bencoh | freemangordon: apparently the last version I've built here is maemo/beowulf-experimental (f4b8c04bede) | 21:55 |
| bencoh | freemangordon: which branch/commit should I pick? (I wanna test it) | 21:55 |
| freemangordon | mesa? | 21:55 |
| bencoh | yeah, mesa | 21:55 |
| freemangordon | maemo/beowulf-devel | 21:56 |
| bencoh | alright, lemme see | 21:56 |
| bencoh | iirc we had to fiddle with some build deps from devuan 4 (chimaera) right? | 21:57 |
| bencoh | like clang/llvm | 21:57 |
| Wizzup | bencoh: sounds good @ rebuild and upload | 21:57 |
| Wizzup | bencoh: what you need is in the repos | 21:57 |
| freemangordon | bencoh: everything should be in backports | 21:57 |
| bencoh | Wizzup: which repos though? | 21:57 |
| Wizzup | ours | 21:57 |
| freemangordon | and devaun backports | 21:57 |
| Wizzup | if it works in the ci, it works with our repos | 21:57 |
| freemangordon | (meson/ninja) | 21:57 |
| Wizzup | freemangordon: we imported libllvm8 | 21:57 |
| bencoh | freemangordon: yeah I think I manually fetched that from devuan's backports back then | 21:57 |
| Wizzup | hmm I don't think you need that newer meson but ok | 21:58 |
| freemangordon | you do | 21:58 |
| Wizzup | clearly our CI does't need it | 21:58 |
| Wizzup | doesn't* | 21:58 |
| bencoh | hmm | 21:58 |
| freemangordon | yes, you do | 21:58 |
| Wizzup | maybe our ci uses backports | 21:58 |
| freemangordon | mhm | 21:58 |
| Wizzup | it's possible | 21:58 |
| bencoh | lemme test what I have, if it works I'll try to upload it as it is first | 21:58 |
| Wizzup | in any case not chimaera | 21:58 |
| freemangordon | yeah | 21:58 |
| bencoh | then we'll start thinking | 21:58 |
| bencoh | dpkg-checkbuilddeps: error: Unmet build dependencies: libdrm-dev (>= 2.4.107-4) llvm-8-dev libclang-8-dev libclang-cpp11-dev | 22:00 |
| bencoh | guess I didn't build it in that specific container ... let's make a new one than | 22:00 |
| bencoh | Wizzup: which repository should I use for leste backport? and which key should I import for leste's repositories (545FEC4E0927F6FD and 2700BD8E6604EC2E) ? | 22:13 |
| bencoh | (I suppose the keys are the *.asc from http://maedevu.maemo.org/) | 22:13 |
| Wizzup | there is no leste backports, there is devuan backports | 22:14 |
| Wizzup | https://maedevu.maemo.org/testing-key.asc this is the key for the repos | 22:15 |
| Wizzup | https://maedevu.maemo.org/extras-key.asc this is the key for extras | 22:15 |
| bencoh | ah, alright | 22:15 |
| bencoh | thx | 22:15 |
| freemangordon | uvos: I don;t think this OGL context comes from pvr dri | 22:20 |
| freemangordon | see https://pastebin.com/Y25uS2W9 | 22:21 |
| freemangordon | this is the result from LIBGL_DEBUG=verbose eglinfo | 22:22 |
| freemangordon | on d4 | 22:22 |
| freemangordon | uvos: how to repro that segfault? | 22:23 |
| uvos | freemangordon: build the previous version of charge-mode, rung charging_sdl in vt with unset DISPLAY | 22:25 |
| uvos | freemangordon: or | 22:25 |
| uvos | freemangordon: https://github.com/maemo-leste/bugtracker/issues/606 | 22:25 |
| uvos | the code here should also work | 22:25 |
| freemangordon | ok | 22:25 |
| uvos | if you dont set SDL_GL_CONTEXT_PROFILE_ES | 22:26 |
| uvos | and set SDL_GL_CONTEXT_MAJOR_VERSION to something sane for opengl | 22:26 |
| uvos | like 2.1 | 22:26 |
| freemangordon | ok | 22:26 |
| uvos | no sure what im supposed to see in your eglinfo | 22:29 |
| uvos | *not | 22:29 |
| freemangordon | see when libpvr_dri_support.so is loaded and unloaded | 22:29 |
| freemangordon | gbm vs x11 | 22:30 |
| uvos | ah yeah | 22:30 |
| freemangordon | this means all this info does not come from pvr | 22:30 |
| uvos | so its llvmpipe or soemthing | 22:30 |
| freemangordon | mhm | 22:30 |
| uvos | but why no worky then :P | 22:30 |
| freemangordon | well... | 22:30 |
| uvos | also why should pvr not work on gbm | 22:31 |
| uvos | and it _dose_ work | 22:31 |
| uvos | (if you choose gles) | 22:31 |
| uvos | looking at eglinfo on my desktop machine makes me thing this (mesa) is buggy | 22:33 |
| uvos | i get all contexts as possible on x11 | 22:34 |
| freemangordon | why not? | 22:34 |
| uvos | but on gbm i dont get opengl | 22:34 |
| freemangordon | ah | 22:34 |
| uvos | but then opengl works if i run sdl in a vt with kmsdrm backend | 22:34 |
| uvos | and EGL client APIs: OpenGL OpenGL_ES | 22:35 |
| uvos | is the same in both cases | 22:35 |
| freemangordon | SDL_GL_CONTEXT_PROFILE_ES=1 LIBGL_DEBUG=verbose ./egltest segfaults | 22:35 |
| freemangordon | do I miss something? | 22:35 |
| uvos | SDL_GL_CONTEXT_PROFILE_ES | 22:36 |
| uvos | thats not how that works | 22:36 |
| uvos | you have to set the flag in code, its not an envvar | 22:36 |
| freemangordon | ah, ok | 22:36 |
| freemangordon | but it is already set | 22:37 |
| freemangordon | SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES); | 22:37 |
| uvos | hmm | 22:37 |
| uvos | printenv | grep SDL ? | 22:37 |
| freemangordon | ah, yeah | 22:37 |
| uvos | also we are trying on kmsdrm right? | 22:38 |
| freemangordon | no idea | 22:38 |
| freemangordon | SDL_RENDER_DRIVER=? | 22:38 |
| freemangordon | kmsdrm? | 22:38 |
| uvos | export SDL_VIDEODRIVER=kmsdrm | 22:38 |
| uvos | to force it | 22:38 |
| uvos | the sdl backend | 22:38 |
| freemangordon | root@devuan-droid4:/tmp# printenv | grep SDL | 22:39 |
| freemangordon | SDL_VIDEODRIVER=kmsdrm | 22:39 |
| freemangordon | still segfaults | 22:39 |
| freemangordon | or, this is expected? | 22:39 |
| uvos | hmm | 22:39 |
| uvos | no | 22:39 |
| uvos | not with SDL_GL_CONTEXT_PROFILE_ES | 22:39 |
| uvos | export SDL_RENDER_DRIVER=opengles2 ? | 22:40 |
| freemangordon | segfault | 22:40 |
| freemangordon | lemme try with swrast | 22:40 |
| uvos | hmm | 22:40 |
| uvos | so charging sdl dosent set SDL_GL_RED_SIZE etc3 | 22:40 |
| uvos | the diff might be the test app requesting 16 bit | 22:41 |
| freemangordon | lemme comment it | 22:41 |
| uvos | ofc that should not segfault either | 22:41 |
| uvos | if thats the cause | 22:41 |
| freemangordon | uvos: why the "xcb_connection_has_error() returned true" message | 22:42 |
| uvos | is that what SDL_GetError() reports? | 22:43 |
| freemangordon | no idea | 22:43 |
| uvos | well whats the output? | 22:43 |
| freemangordon | this | 22:44 |
| uvos | also unset DISPLAY ofc | 22:44 |
| uvos | just in case | 22:44 |
| freemangordon | root@devuan-droid4:/tmp# ./egltest | 22:44 |
| freemangordon | xcb_connection_has_error() returned true | 22:44 |
| freemangordon | Segmentation fault | 22:44 |
| freemangordon | hmm | 22:44 |
| uvos | that dosent make any sense to me | 22:45 |
| freemangordon | yep, DISPLAY was set | 22:45 |
| freemangordon | but, it still segfaults | 22:45 |
| uvos | ok just to check | 22:46 |
| uvos | so in a vt where there is not xorg running as root (clean env sudo su - or root login) with SDL_VIDEODRIVER=kmsdrm and SDL_RENDER_DRIVER=opengles2 and SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES); | 22:46 |
| uvos | it segfaults? | 22:46 |
| freemangordon | Xorg is stopped | 22:46 |
| uvos | oh and | 22:47 |
| freemangordon | this is ssh session, is that an issue? | 22:47 |
| uvos | no | 22:47 |
| uvos | ah maybe its gles1 | 22:47 |
| uvos | SDL_GL_CONTEXT_MAJOR_VERSION | 22:47 |
| uvos | 2 and SDL_GL_CONTEXT_MINOR_VERSION 0 | 22:48 |
| freemangordon | sec | 22:48 |
| freemangordon | INFO: Suscess | 22:49 |
| uvos | ok | 22:49 |
| uvos | yeah gles 1 dosent work | 22:49 |
| uvos | because of a glibc2.29 symbol | 22:49 |
| freemangordon | mhm | 22:49 |
| freemangordon | ok, how to make it crash now? | 22:50 |
| freemangordon | SDL_VIDEO_X11_FORCE_EGL=1 | 22:50 |
| freemangordon | no, this is for X11 | 22:50 |
| uvos | unset SDL_RENDER_DRIVER=opengles2, remove SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES); | 22:50 |
| freemangordon | ok | 22:50 |
| uvos | ie make it auto detect | 22:50 |
| uvos | it will auto detect opengl and segfault | 22:50 |
| uvos | expected beahvior: autodetect gles2 or maybe use opengl with llvmpipe | 22:51 |
| freemangordon | mhm | 22:51 |
| freemangordon | I have copmmented the version lines as well | 22:52 |
| freemangordon | *commented | 22:52 |
| freemangordon | and now it segfaults | 22:52 |
| freemangordon | but, it segfaults even with export SDL_RENDER_DRIVER=opengles2 | 22:53 |
| uvos | yeah | 22:53 |
| uvos | that hint is ignored most of the time | 22:54 |
| uvos | some sdl modules read it | 22:54 |
| uvos | and its exposed to applications to read | 22:54 |
| uvos | viea SDLhints | 22:54 |
| freemangordon | ok | 22:54 |
| uvos | i just reccomended you set it before because im not sure it dosent do something else too | 22:54 |
| freemangordon | ok | 22:56 |
| freemangordon | hmm | 22:56 |
| freemangordon | 0xb6f5ef46 in KMSDRM_DestroyWindow (_this=0x412b28, window=0x435780) at ./src/video/kmsdrm/SDL_kmsdrmvideo.c:1471 | 22:57 |
| freemangordon | (gdb) p windata | 22:58 |
| freemangordon | $1 = (SDL_WindowData *) 0x0 | 22:58 |
| freemangordon | I would say this is a bug in sdl | 22:58 |
| uvos | it lacks error checking | 22:59 |
| uvos | but it reads opengl as its abckend | 23:00 |
| uvos | and then cant create a context | 23:00 |
| uvos | so there is bug in mesa/egl here | 23:00 |
| uvos | (it claims opengl support but cant back it up) | 23:00 |
| freemangordon | do you know how does it detects backends? | 23:00 |
| freemangordon | *detect | 23:00 |
| uvos | hmm what backends? sdl reading render backends? | 23:01 |
| freemangordon | is there a way to enable some SDL traces? | 23:01 |
| uvos | video backends? | 23:01 |
| freemangordon | whatever you mean by "it reads opengl as its abckend" | 23:01 |
| freemangordon | how does it read opengl? | 23:02 |
| uvos | SDL_egl.c | 23:03 |
| uvos | it reads from egl what it supports | 23:03 |
| uvos | as you can see in eglinfo | 23:04 |
| uvos | this reports opengl | 23:04 |
| freemangordon | ah, right | 23:04 |
| uvos | and then it goes to create a context | 23:04 |
| uvos | and that fails | 23:04 |
| freemangordon | mhm | 23:04 |
| uvos | then sdl has a bug that this isent handled | 23:04 |
| uvos | but thats beside the point | 23:04 |
| uvos | egl should not be lieing | 23:04 |
| freemangordon | uvos: well, I would say this is a bug in sdl | 23:05 |
| freemangordon | because it may request context that is not supported | 23:05 |
| freemangordon | and it will still fail the creation | 23:05 |
| uvos | but it isent | 23:05 |
| uvos | egl claims suport | 23:05 |
| uvos | yes it should handle the error | 23:05 |
| freemangordon | mhm | 23:05 |
| uvos | but still egl should not claim support it dosent have | 23:05 |
| freemangordon | agree | 23:06 |
| freemangordon | 650 files to compile | 23:06 |
| freemangordon | will take few more hours, so will continue tomorrow | 23:06 |
| freemangordon | when I will be able to play with pvr | 23:06 |
| freemangordon | night! | 23:17 |
| bencoh | 'night :) | 23:19 |
| bencoh | uploading tarball btw, you'll supposedly just need to install the mesa build-deps / add your backport packages | 23:20 |
| bencoh | (currently uploading a non-backport image because I want it clean) | 23:21 |
| bencoh | freemangordon, Wizzup: http://bencoh.notk.org/maemo/leste-builder-lxc-20220214.tar.xz | 23:29 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!