<Wizzup>
freemangordon: looks like the RE'd code doesn't want to build
<Wizzup>
(also looks like we aren't actually shipping that RE'd code yet then?)
<freemangordon>
no, we are not
rafael2k has quit [Ping timeout: 272 seconds]
<Wizzup>
ok
<freemangordon>
will look at it later, have to attend work mtg
<Wizzup>
np
<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
<uvos>
Wizzup: ok
<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).
<uvos>
Wizzup: if it works there compleatly ill promote it to stable for the first time
<Wizzup>
ok
<Wizzup>
yeah I can try that some time this week I think
inky has joined #maemo-leste
_inky has quit [Ping timeout: 252 seconds]
_inky has joined #maemo-leste
mepy has quit [Ping timeout: 250 seconds]
pere has quit [Ping timeout: 240 seconds]
pere has joined #maemo-leste
mepy has joined #maemo-leste
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 272 seconds]
_inky has quit [Ping timeout: 252 seconds]
_inky has joined #maemo-leste
_inky has quit [Ping timeout: 252 seconds]
xmn has joined #maemo-leste
macros_ has joined #maemo-leste
_inky has joined #maemo-leste
macros__ has quit [Ping timeout: 250 seconds]
pere has quit [Ping timeout: 252 seconds]
uvos has quit [Remote host closed the connection]
pere has joined #maemo-leste
rafael2k has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
Wizzup: aaand charging sdl still dosent work
<uvos>
Wizzup: now it segfaults in SDL_CreateWindow.. while on my localy build sdl2 its fine
<Wizzup>
uvos: hm, same HEAD?
<uvos>
no
<uvos>
i have --disable-video-opengl
<Wizzup>
hm, it'd not be ideal to have to add that
<uvos>
yeah
<uvos>
EGL client APIs: OpenGL OpenGL_ES
<uvos>
im thinking this might be a problem
<uvos>
(this is eglinfo)
<uvos>
its not reporting opengl as unavailbale
<uvos>
as it should
<uvos>
freemangordon: ^^^
<Wizzup>
well is it not available via llvmpipe?
<Wizzup>
I guess not for this renderer
pere has quit [Ping timeout: 240 seconds]
<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
<uvos>
creating a gl context via egl causes a segfault
<uvos>
it should just fail
rafael2k has quit [Ping timeout: 240 seconds]
<Wizzup>
understood
akossh has joined #maemo-leste
<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
<uvos>
our charging_sdl shares nothing with postmarket os's at this point except the code that draws the icon texture
<uvos>
so thats not a concern
macros__ has joined #maemo-leste
<uvos>
sicelo: hmmm charging-lvgl basicly works like our charging-sdl
<uvos>
sicelo: and the defficanies reported in pmos -sdl is essantly what i thought too when i changed how it works
<uvos>
so this is failed co-operation at its finest
<freemangordon>
uvos: can you test with blobs?
<sicelo>
you mean you sent your charging-sdl patches or issues upstream and they didn't cooperate?
<uvos>
sicelo: no its also my fault, i thought the unesscarly complex way it worked in pmos was as intended
<uvos>
freemangordon: not right away
<freemangordon>
though, they may have disabled GL in mesa
<uvos>
its with the kmsdrm backend it thinks it can go opengl
<freemangordon>
ok, lemme check in what state my mesa tree on d4 is
<uvos>
also its interesting that the GBM platform also dosent report any valid gl configs
<uvos>
but i gues thats to late for sdl
<freemangordon>
yeah, seems the decision has already been taken
<freemangordon>
ok, I'll just #ifdef OGL in pvr dri
<freemangordon>
bencoh: did you manage to do some mesa cross-compile instructions?
<freemangordon>
uvos: BTW, it is the same in 343x blob
<freemangordon>
so it is not about 545
<freemangordon>
maybe they just limit the API with mesa build
<freemangordon>
hmm, actually why don;t we disable OGL in mesa?
<freemangordon>
I mean - it is already disabled for x11
<freemangordon>
why shall we keep it for gbm?
<freemangordon>
Wizzup: ^^^
<Wizzup>
hey
<Wizzup>
freemangordon: we build mesa for all devices
<Wizzup>
some can support opengl
<Wizzup>
e.g. pinephone does
<Wizzup>
and most adreno based devices will
sunshavi has joined #maemo-leste
<freemangordon>
Wizzup: the point is that opengl is disabled for x11
<freemangordon>
why shall it be enabled for gbm?
<freemangordon>
we either enable it for bot or disable it for both, IIUC
<freemangordon>
*both
<uvos>
its not disabled for x11 is it
<uvos>
(explicitly, by us)
<uvos>
?
<uvos>
afaik we disabled GLX on omap
<uvos>
but thats totaly unrleated to egl
<freemangordon>
well then why OGL is not reported for X11?
<uvos>
i dont know
* freemangordon
boots PP
<freemangordon>
on PP we have "EGL client APIs: OpenGL OpenGL_ES" for x11
<freemangordon>
could it be some bug in mesa?
<uvos>
its possible
<uvos>
but hard to tell without some mesa supported gles only gpu
<uvos>
(are there any even !?)
<freemangordon>
also, I wonder how is a particular API detected
<freemangordon>
because you cannot create OGL context on sgx
<freemangordon>
unless I introduced some bug
* freemangordon
checks
<uvos>
freemangordon: well one thing that your re dosent do that the blobs did
<uvos>
was use llvmpipe in glx
<uvos>
glx now just fails
<uvos>
previously mesa just used llvmpipe
<freemangordon>
are you sure?
<uvos>
yes
<uvos>
but blobs here is ddk 1.9
<uvos>
so im not sure its relevant
<freemangordon>
ah
<freemangordon>
test with 1.17 blobs
<uvos>
how
<uvos>
xorg dosent work
<uvos>
so no glx
<freemangordon>
LD_LIBRARY_PATH/LD_PRELOAD
<uvos>
GLX?
<freemangordon>
ah, yeah
<freemangordon>
sorry
<freemangordon>
well, I don;t know what they did
<freemangordon>
but do we really want llvmpipe for glx?
<uvos>
well there are apps that just dont work this way
<uvos>
but did work before
<uvos>
like linuxcnc
<uvos>
(even had fine performanec on llvmpipe)
<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
<freemangordon>
uvos: I am afraid that if we enable glx, lot sof applications will prefer it over gles2
<uvos>
freemangordon: sure but glx is a parameter in xorg.conf
<uvos>
freemangordon: so we could have it work on llvm and then disable it
<uvos>
but its not a big issue
<uvos>
this opengl reporing over egl on kms/drm is much more annyoing
<freemangordon>
uvos: I think you can override with export MESA_LOADER_DRIVER_OVERRIDE=swrast or somesuch
<bencoh>
freemangordon: afaict once you have a crosscompilation container ready it's pretty straightforward
<freemangordon>
uvos: MESA_LOADER_DRIVER_OVERRIDE=swrast glxgears works on d4
<uvos>
ah ok
<freemangordon>
bencoh: where should I get one from? :)
<uvos>
the reason mesa dosent cose llvmpipe in the first place then is probubly because we need MESA_LOADER_DRIVER_OVERRIDE=pvr
<bencoh>
Wizzup: do we have a public lxc image for the crossbuilder somewhere?
<freemangordon>
no idea
<freemangordon>
bencoh: but anyway, I am already compiling on device
<bencoh>
ah :(
<freemangordon>
[600/2515]
<freemangordon>
:)
<bencoh>
want me to build it? :D
<freemangordon>
no, as I want to be able to make changes to test
<bencoh>
I see
<bencoh>
I wonder how large my current lxc container is, maybe I could share it
<Wizzup>
bencoh: no, would be nice if we did
<bencoh>
actually I could rebuild one and upload it maybe
<bencoh>
(3mbps upload from here)
<bencoh>
freemangordon: apparently the last version I've built here is maemo/beowulf-experimental (f4b8c04bede)
<bencoh>
freemangordon: which branch/commit should I pick? (I wanna test it)
<freemangordon>
mesa?
<bencoh>
yeah, mesa
<freemangordon>
maemo/beowulf-devel
<bencoh>
alright, lemme see
<bencoh>
iirc we had to fiddle with some build deps from devuan 4 (chimaera) right?
<bencoh>
like clang/llvm
<Wizzup>
bencoh: sounds good @ rebuild and upload
<Wizzup>
bencoh: what you need is in the repos
<freemangordon>
bencoh: everything should be in backports
<bencoh>
Wizzup: which repos though?
<Wizzup>
ours
<freemangordon>
and devaun backports
<Wizzup>
if it works in the ci, it works with our repos
<freemangordon>
(meson/ninja)
<Wizzup>
freemangordon: we imported libllvm8
<bencoh>
freemangordon: yeah I think I manually fetched that from devuan's backports back then
<Wizzup>
hmm I don't think you need that newer meson but ok
<freemangordon>
you do
<Wizzup>
clearly our CI does't need it
<Wizzup>
doesn't*
<bencoh>
hmm
<freemangordon>
yes, you do
<Wizzup>
maybe our ci uses backports
<freemangordon>
mhm
<Wizzup>
it's possible
<bencoh>
lemme test what I have, if it works I'll try to upload it as it is first
<bencoh>
guess I didn't build it in that specific container ... let's make a new one than
<bencoh>
Wizzup: which repository should I use for leste backport? and which key should I import for leste's repositories (545FEC4E0927F6FD and 2700BD8E6604EC2E) ?
<freemangordon>
xcb_connection_has_error() returned true
<freemangordon>
hmm
<uvos>
that dosent make any sense to me
_inky has quit [Ping timeout: 252 seconds]
<freemangordon>
yep, DISPLAY was set
<freemangordon>
but, it still segfaults
<uvos>
ok just to check
<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);
<uvos>
it segfaults?
<freemangordon>
Xorg is stopped
<uvos>
oh and
<freemangordon>
this is ssh session, is that an issue?