weston-simple-egl fullscreen broken?

Vincent ABRIOU vincent.abriou at st.com
Wed Mar 8 17:16:31 UTC 2017


Hi,

I have investigate deeper the issue and it comes from the Mali400 
wayland library (at least in the r6p1-01rel0 version).

Actually, the Mali400 wayland library is creating very early the output 
surface taking into account the 250x250 default size because fullscreen 
information is not yet available at this moment.

Code from simple-egl.c:

static void
create_surface(struct window *window)
{
	struct display *display = window->display;
	EGLBoolean ret;

	window->surface =
		wl_compositor_create_surface(display->compositor);

	window->native =
		wl_egl_window_create(window->surface,
				     window->geometry.width,
				     window->geometry.height);
	window->egl_surface =
		weston_platform_create_egl_surface(display->egl.dpy,
						   display->egl.conf,
						   window->native,
						   NULL);
	/* Mali400 has already created its first 250x250 surface */

	...
	...

	/* Full screen information comes too late */
	if (window->fullscreen)
		zxdg_toplevel_v6_set_fullscreen(window->xdg_toplevel,
		NULL);
}


The mali400 library lock occurs while the eglSwapBuffer when the 250x250 
surface need to be committed whereas a fullscreen surface is expected.

I fix this issue in the Mali400 wayland library by avoiding to commit 
the surface if the size does not match the expected output surface size. 
Once the 250x250 surface is skipped during eglSwapBuffer it is then 
destroyed and created again with the right fullscreen parameters.

BR
Vincent


On 02/28/2017 09:12 AM, Fabien DESSENNE wrote:
> Hi,
>
> Thank you for your feedback.
> I am using ARM mali for GL rendering, and I found that there is something wrong with its EGL backend (stuck in a glxxx() call, probably wrong buffer init).
> I did not investigate deeper for the time being, but I hope Vincent will do ;)
>
> BR
>
> Fabien
>
>
>> -----Original Message-----
>> From: Daniel Stone [mailto:daniel at fooishbar.org]
>> Sent: mardi 28 février 2017 00:18
>> To: Arnaud Vrac <rawoul at gmail.com>
>> Cc: Fabien DESSENNE <fabien.dessenne at st.com>; wayland-
>> devel at lists.freedesktop.org
>> Subject: Re: weston-simple-egl fullscreen broken?
>>
>> Hi Arnaud,
>>
>> On 27 February 2017 at 23:12, Arnaud Vrac <rawoul at gmail.com> wrote:
>>> On Mon, Feb 27, 2017 at 11:18 PM Daniel Stone <daniel at fooishbar.org>
>> wrote:
>>>> On 6 February 2017 at 16:56, Fabien DESSENNE <fabien.dessenne at st.com>
>> wrote:
>>>>> I remember I used to get « weston-simple-egl -f » working fine.
>>>>> But it does not work anymore : nothing is displayed. From the logs
>>>>> I can see (among others) zxdg_toplevel_v6.configure and
>>>>> wl_surface.commit Testing with another client works fine:
>>>>> weston-terminal -f -> OK There may be something wrong with my
>>>>> environment since I am testing with the Daniel’s atomic version
>>>>> (forked from weston-1.12.0+), but I guess this is broken also with the official
>> version.
>>>>> If anyone can make a quick test and let me know.
>>>>
>>>> This also works fine for me, both upstream and on the atomic branch;
>>>> it's one of the main tests I do.
>>>
>>> I remember that weston-simple-egl -f was broken when using software
>>> rendering in mesa. From my irc log:
>>>
>>> 21:56:01< rawoul> 'weston-simple-egl -f' is also broken with
>>> LIBGL_ALWAYS_SOFTWARE=1 on libweston-desktop... That's a mesa bug
>>> though, the first commited buffer does not use the size sent in the
>>> configure event 22:02:04< SardemFF7> not sure it’s a mesa bug
>>> 22:04:32< SardemFF7> mesa doesn’t know about the shell protocol, and
>>> that’s a requirement from xdg_shell_v6 22:05:16< rawoul> SardemFF7:
>>> the client does properly calls wl_egl_window_resize with the correct
>>> size before the first call to eglSwapBuffers. It actually works with
>>> dri2, but it seems swrast defers the resize
>>
>> I'm pretty sure that Fabien is using a real GL driver; software GL would never
>> make it to scanout as it's a SHM buffer. Either way, I'm pretty sure this bug is
>> fixed in Mesa 17.0. :)
>>
>> Cheers,
>> Daniel


More information about the wayland-devel mailing list