<mighty17[m]>
also `LibGL: DRI_IMAGE (supported version: 8 - max version: 19)` ig DRI_IMAGE is working fine
Pali has joined #maemo-leste
<mighty17[m]>
`PVR:(Error): PVRContextCheckGLES2: Unsupported context flags: 0x4. [0, ]` also what is this?
pere has quit [Ping timeout: 246 seconds]
norayr has joined #maemo-leste
pere has joined #maemo-leste
<mighty17[m]>
`libEGL debug: EGL user error 0x3009 (EGL_BAD_MATCH) in eglCreateContext: dri2_create_context`
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
norayr has quit [Excess Flood]
Daanct12 has quit [Ping timeout: 250 seconds]
Daanct12 has joined #maemo-leste
devrtz[m] has quit [Quit: You have been kicked for being idle]
xmn has quit [Quit: ZZZzzz…]
uvos has joined #maemo-leste
ceene has joined #maemo-leste
<bencoh>
hm, I'm trying to run torus-trooper with gl4es, but it dies with "abagames.util.sdl.sdlexception.SDLInitFailedException@src/abagames/util/sdl/sdlexception.d(13): Unable to create SDL screen: X11 driver not configured with OpenGL"
<bencoh>
ldd reports both libSDL-1.2 and libSDL-2
<bencoh>
how is it linked against both?
<bencoh>
(apparently both libsdl1 and libsdl2 come from the leste repos)
<Wizzup>
uvos suggested we set SDL_RENDER_DRIVER=opengles2
<mighty17[m]>
:o thats pretty interesting it working for you and not me
<uvos>
it also dosent work for me so idk what bencoh is doing
<bencoh>
uh
<bencoh>
I'm running -stable, maybe that's why
<bencoh>
I haven't fiddled that much with my leste install, so ... :)
<buZz>
i've played with puredata+GEM (its OpenGL library) on a droid4 with gl4es installed
<buZz>
zero issues and pretty decent performance
<buZz>
install gl4es, restart Xorg, get functional OpenGL
<buZz>
honestly, i didnt try glxgears cause i dont really consider that a worthwhile test :P
pagurus has quit [Ping timeout: 246 seconds]
duuude has joined #maemo-leste
<bencoh>
alright, so ... that thing uses libsd1.2 apparently, and the error means that sdl was built without GLX support
pere has quit [Ping timeout: 268 seconds]
ceene has quit [Remote host closed the connection]
<uvos>
bencoh: it was disabled for some time
<uvos>
bencoh: but its been reenabled in devel
<bencoh>
oh
<bencoh>
well, I rebuilt libsdl1.2 with it, it looks like it runs, I'll see if it displays something at home
<bencoh>
the issue with gl4es and allowing some kind of broken GLX compat layer to run is that I have a feeling it will break many detection mechanisms
<bencoh>
which is a bit sad
<uvos>
that is correct
<uvos>
most things will prefer gl when offered
<bencoh>
I think mpv 0.29 did that as well, I built the latest version from debian's git repository, and now it doesn't accept x11 anymore (I think it got deprecated / disabled by default)
<bencoh>
(ie it frowns when I pass gpu-context=x11, and works properly with x11egl)
pere has joined #maemo-leste
<freemangordon>
ugh, what a nasty bug there is in rtcom_widget_set_account
<freemangordon>
they pass G_STRUCT_OFFSET(RtcomWidgetIface, store_settings) instead of RTCOM_WIDGET_GET_IFACE(obj)->store_settings as a function to g_signal_handlers_disconnect_matched() call
<freemangordon>
or rather it is G_STRUCT_OFFSET(RTCOM_TYPE_WIDGET, store_settings)
<bencoh>
the fact that n900/fremantle proves to be usable is some kind of mystery/miracle to me :)
<freemangordon>
:D
<bencoh>
I mean, we've been using it for years, it really works ... but how :]
<freemangordon>
yeah, agree
<freemangordon>
I have a colleague of mine which has a theory about "quantum programming" :D
<bencoh>
^.^
<freemangordon>
the real question is whether I introduced more bug with REing that I fixed :p
<freemangordon>
*bugs
<bencoh>
at least debugging it should be more accessible to others
<freemangordon>
yeah
<freemangordon>
deffinitely
<freemangordon>
definitely
<bencoh>
which reminds me, I wonder if we still have that odd memory leak when double-pressing powerbutton to blank screen (I think that was the source of it)
<freemangordon>
first time I hear about that
<freemangordon>
it that in CSSU?
<freemangordon>
*is that
<bencoh>
not -devel, but yeah, years ago we tried to investigate a memory leak around blanking/unlocking screen
<freemangordon>
in tklock? I think I run systemui against valgrind back then and the was no memleak
<freemangordon>
I remember I even added code to run it as a standalone program, (iirc)
<bencoh>
yeah I remember you checked that, I think you even fixed something along the process, and I remember we didn't manage to find the source of it in the end
<bencoh>
but I could still see memory usage rise slightly at each screen blanking (when double-pressing power)
<freemangordon>
hmm
<bencoh>
(I use some gesture to blank, so it hasn't bothered me for years, and I stopped thinking about it)
<bencoh>
well, maybe I'll play a bit with that on droid4 and see if anything pops
<freemangordon>
well, we have all the sources already so you may want to check it in leste
<freemangordon>
mhm
<freemangordon>
actually you can run systemui in valgrind, leaving tklock only
<bencoh>
leaving tklock only?
<freemangordon>
that should give you full details on what's goiing on
<freemangordon>
as a module
<bencoh>
I think the systemui menu is the cause btw
<freemangordon>
what is "systeui menu"? powerkey-menu?
<bencoh>
yeah
<bencoh>
iirc they have some hack, where it catches the first press and waits for a second one