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:dan...@fooishbar.org]
>> Sent: mardi 28 février 2017 00:18
>> To: Arnaud Vrac <raw...@gmail.com>
>> Cc: Fabien DESSENNE <fabien.desse...@st.com>; wayland-
>> de...@lists.freedesktop.org
>> Subject: Re: weston-simple-egl fullscreen broken?
>>
>> Hi Arnaud,
>>
>> On 27 February 2017 at 23:12, Arnaud Vrac <raw...@gmail.com> wrote:
>>> On Mon, Feb 27, 2017 at 11:18 PM Daniel Stone <dan...@fooishbar.org>
>> wrote:
>>>> On 6 February 2017 at 16:56, Fabien DESSENNE <fabien.desse...@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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to