Unable to run hildon-desktop: Failed to create texture 2d due to size/format constraints

[craftyguy]

I successfully built/packaged tinygles and glshim, and have replaced the corresponding mesa bits with these libraries. When running hildon-desktop (which usese gtk2/clutter), I get the following error from X server:

expr: warning: '^/dev/tty[0-9]\+$': using '^' as the first character
of a basic regular expression is not portable; it is ignored

X.Org X Server 1.19.3
Release Date: 2017-03-15
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.19 armv8l Alpine Linux
Current Operating System: Linux localhost 4.13.3 #3-postmarketOS PREEMPT Sat Sep 23 21:09:49 GMT 2017 armv7l
Kernel command line: init=/init.sh rw console=tty0 console=tty02
Build Date: 20 September 2017  07:53:06AM

Current version of pixman: 0.34.0
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan  1 13:05:31 1970
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
MESA-LOADER: failed to retrieve device information
gbm: failed to open any driver (search paths /usr/lib/xorg/modules/dri)
gbm: Last dlopen error: Error loading shared library /usr/lib/xorg/modules/dri/omapdrm_dri.so: No such file or directory
failed to load driver: omapdrm
EGL_MESA_drm_image required.

(hildon-desktop:8424): GModule-CRITICAL **: g_module_close: assertion 'module->ref_count > 0' failed

(hildon-desktop:8424): GModule-CRITICAL **: g_module_close: assertion 'module->ref_count > 0' failed

(hildon-desktop:8424): GModule-CRITICAL **: g_module_close: assertion 'module->ref_count > 0' failed

(hildon-desktop:8424): Clutter-CRITICAL **: Unable to initialize Clutter: Unable to initialize the Clutter backend: no available drivers found.
libGL:loaded: libGLESv1_CM.so
glGet: option not implemented: d32
gl_enable_disable(): 0x0BC0 not supported

(hildon-desktop:8424): Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
xinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.

Couldn't get a file descriptor referring to the console

[lunixbochs]

Can you build tinygles with debug symbols and set up ltrace or something so we can see the function call that's failing?

For just this, you could also put a printf on the first line of glTexImage2D with all the arguments.

I think I specifically didn't bother giving TinyGLES full texture support because glshim already has it, so one more thing to try: https://github.com/lunixbochs/glshim supports a much wider range of OpenGL, including more texture options, and can use tinygles as a backend: if you run clutter in GLES mode but use glshim as the ES implementation, it will end up with more API support.

[lunixbochs]

Also note if you use glshim you should cherry-pick this commit to better support tinygles' limited texture format options: https://github.com/lunixbochs/glshim/commit/062c9bf2469eaabd2fe78567d712dcf466ee3d7e

[craftyguy]

I will try to build tinygles with symbols and ltrace it.

if you run clutter in GLES mode but use glshim as the ES implementation, it will end up with more API support.

Ah, so this is where my knowledge of clutter, GL, GLES, etc breaks down. I'm not sure how to try what you are suggesting, so I tried some experiments:

1) I tried setting CLUTTER_DRIVER=gles2, but that didn't have any effect. I'm not sure if clutter is actually paying attention to these env. variables like their docs say it should, since other options didn't do anything either.

2) I also tried removing libGLESv1_CM.so (from tinygles) from the equation, the output is below. hildon-desktop didn't start, but the texture error is gone:

(==) Log file: "/var/log/Xorg.7.log", Time: Thu Jan  1 18:07:23 1970
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
MESA-LOADER: failed to retrieve device information
gbm: failed to open any driver (search paths /usr/lib/xorg/modules/dri)
gbm: Last dlopen error: Error loading shared library /usr/lib/xorg/modules/dri/omapdrm_dri.so: No such file or directory
failed to load driver: omapdrm
Couldn't open libEGL.so.1: Error loading shared library libEGL.so.1: No such file or directory
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
Couldn't get a file descriptor referring to the console

Naturally I would install mesa-egl, which provides libEGL.so.1, but in this case I'm not sure if there's a way to tell clutter "use GLES instead" (since the env. variable didn't work), or if it moves to EGL because I removed tinygles..

[lunixbochs]

One problem with glshim/tinygles is they only provide a glx interface, not an egl interface. If there's an opengl 1.1 clutter driver, that might work with glshim -> tinygles, which does provide glx.

[craftyguy]

I see. I suspect a good portion of this is just be being confused about all these different permutations of the letters E, G, S, and L :)

I'll look into rebuilding clutter with opengl1.1 only

[lunixbochs]

GL: oldest desktop graphics api ES: smaller mobile api GLX: api that gives you a new GL 1.x context EGL: api that gives you a new anything context (but glshim and tinygles don't expose)

tinygles exposes ES and GLX with an X11 and CPU backend (which is probably confusing to anything but glshim) glshim exposes GL and GLX with an EGL (or GLX) and ES backend

[NotKit]

I'm trying to get cogl-hello (https://github.com/GNOME/cogl/blob/master/examples/cogl-hello.c) to run with tinygles. cogl had be to hacked for context creation, since it uses some not implemented GLX functions: https://hastebin.com/revadamala.diff

Now it crashes on glDrawArrays: https://hastebin.com/unajexisir.log. Is it ok that glshim's glArrayElement got called instead the one in TinyGLES?

[ollieparanoid]

@lunixbochs: Sorry for cluttering this issue, we can move it over to the postmarketOS tracker if you prefer.

@NotKit: cogl seems to support various GL backends. I guess you could switch between them with some kind of environment variable, however I have not found out how to do this yet. We could also select the gles (v1?) backend at compile time (by disabling all others):

https://github.com/alpinelinux/aports/blob/b940a4d85b7cac14d0f646d4f9e378cfa3c2fbac/main/cogl/APKBUILD#L25-L38

I guess if we do it that way, you should not need to patch the source.

[lunixbochs]

A crash on glDrawArrays would be from a VBO if the crashing pointer is a low number.

On Sep 29, 2017, at 9:40 AM, Oliver Smith notifications@github.com wrote:

@lunixbochs: Sorry for cluttering this issue, we can move it over to the postmarketOS tracker if you prefer.

@NotKit: cogl seems to support various GL backends. I guess you could switch between them with some kind of environment variable, however I have not found out how to do this yet. We could also select the gles (v1?) backend at compile time (by disabling all others):

https://github.com/alpinelinux/aports/blob/b940a4d85b7cac14d0f646d4f9e378cfa3c2fbac/main/cogl/APKBUILD#L25-L38

I guess if we do it that way, you should not need to patch the source.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[NotKit]

Are VBOs supported by TinyGLES? They are part of GLES1, but I couldn't find any code for them in TinyGLES.

[lunixbochs]

It should be glshim's job to polyfill them, but it doesn't do that yet. They wouldn't be too hard to implement.