Bug 89385

Summary:	gl_renderer: poor error messages when config matching fails
Product:	Wayland	Reporter:	Bruno <bonbons>
Component:	weston	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium	CC:	goetzchrist
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Bruno 2015-03-01 21:58:42 UTC

On a rather old system (i855GM), trying to start weston (1.6.1) fails with rather unclear error message:
[21:49:59.073] Loading module '/usr/lib/weston/drm-backend.so'
[21:49:59.078] initializing drm backend
[21:49:59.084] using /dev/dri/card0
[21:49:59.084] Loading module '/usr/lib/weston/gl-renderer.so'
[21:49:59.157] failed to choose EGL config
[21:49:59.157] EGL error state: EGL_SUCCESS (0x3000)
[21:49:59.157] failed to initialize egl
[21:49:59.168] fatal: failed to create compositor

The reason of that failure is that the system does not provide any config matching expectation.

System only provides configs with EGL_RENDERABLE_TYPE=EGL_OPENGL_ES_BIT | EGL_OPENGL_BIT while weston wants EGL_OPENGL_ES2_BIT.

In addition EGL_*_SIZE is requested with 1-bit size while system has either 16bit (R=5,G=6,B=5) or 32bit (A=8,R=8,G=8,B=8) pixels.


It would be good if weston's gl_renderer could handle GLESv1 systems and, until then, provide a more explicit error message.

Comment 1 Daniel Stone 2015-03-02 04:39:43 UTC

Unfortunately GLESv1 support would mean rewriting the entire renderer. It's a very niche usecase - even mobile has supported GLESv2 for several years now.

The config matching of 1bpc is actually one or greater - see the eglChooseConfig documentation.

We could definitely improve the error message though ...

Comment 2 Bruno 2015-03-02 10:07:42 UTC

(In reply to Daniel Stone from comment #1)
> Unfortunately GLESv1 support would mean rewriting the entire renderer. It's
> a very niche usecase - even mobile has supported GLESv2 for several years
> now.

My box predates the mobile fury!
I'm fine with a "copy" of gl_renderer to handle older hardware. That one would not need any fancyness (so no need for extra shadows, bluring or whatever effects, except simple argb transparency).
Software rendering is rather (very) slow.

> The config matching of 1bpc is actually one or greater - see the
> eglChooseConfig documentation.

Ok, I missed that detail while searching through Khronos EGL documentation for understanding why loading failed.

Comment 3 Daniel Stone 2015-03-02 10:23:18 UTC

(In reply to Bruno from comment #2)
> I'm fine with a "copy" of gl_renderer to handle older hardware. That one
> would not need any fancyness (so no need for extra shadows, bluring or
> whatever effects, except simple argb transparency).
> Software rendering is rather (very) slow.

Hmm, the problem is that it's not just a copy, but in fact a near-total rewrite of the renderer, since we operate everything with shaders rather than the fixed-function pipeline from GLESv1.

Given that this is a pretty extreme corner-case, I honestly wouldn't hold your breath to see this happen: it's not a priority at all upstream.

Comment 4 Giulio Camuffo 2015-03-19 13:10:37 UTC

While the GLESv1  problem is specific to very old GPUs, i'm also currently hitting this problem, introduced with mesa 10.5 as far as i can see. Weston looks for an EGL config with the xrgb8888 format by default and that is not provided anymore. Instead, on my system at least, only argb8888 and rgb565 are available.
On older mesa versions xrgb8888 was available.

Comment 5 GitLab Migration User 2018-06-08 23:53:51 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/wayland/weston/issues/64.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.