Hello Vladimir,

The behavior of the wayland egl window resize is dependent on the GPU(EGL) driver you are using,
Some additional information is here:
https://lists.freedesktop.org/archives/mesa-dev/2018-June/196474.html

It looks like with you EGL driver you need to render one frame or it might be sufficient to call wl_display_flush (but I have a little hope for it because if the wayland buffers where recreated inside of the EGL it would also call wl_display_flush).
Please also find some comments below..

Best regards

Eugen Friedrich
Engineering Software Multimedia 1 (ADITG/ESM1)

Tel. +49 5121 49 6921

wl_egl_window_create is not sending anything to compositor in some implementations
You should export WAYLAND_DEBUG=1 variable before running you application to check the low level wayland logs...

It is a bit hard to follow per email, but the ILM_NOTIFICATION_CONFIGURED will tell you which size the original buffer is!
In the application-controller you have to decide how and where to put the surface by setting the source and destination regions.
Exactly this explicit control is the reason why ivi-shell exist! If don't need this control don't use it, you could use xdg shell but in this case the Weston-xdg-shell will decide where to put you application and it will just follow the size of the applications buffer.

In the ivi-shell we have actually a feature which might  help you:

Use ilm_surfaceSetType([SURFACE_ID], ILM_SURFACETYPE_DESKTOP);
This will enable setting of the source and destination regions automatically inside of the ivi-shell, but keep in mind the position on the display is still taken from the destination x and y coordinates.
It should be  0,0 per default, or you could set it also directly after ilm_surfaceSetType, ( negative values for width and height parameter in the ilm_surfaceSetDestinationRectangle will be ignored and not used in the compositor, this way you could only set the position)

If you would like to ensure the wayland communication is in sync you should call wl_display_roundtrip();

Hi,

My device uses a Mali blob, which (I was told) has million bugs.
See below for lots of comments :)

Mit freundlichen Grüßen

i. A. Vladimir Jovic
ifm ecomatic gmbh

I tried all kind of things. "wl_display_flush()" does not seem to do anything.
Could it be device driver bug?

I tried that, and it didn't really help. Here is just relevant part of the log, which shows that the compositor should get the right values.

[896386.409] wl_output@10.geometry(0, 0, 292, 109, 0, "unknown", "unknown", 0)
[896386.528] wl_output@10.mode(3, 1280, 480, 59933407)
[896386.595] ivi_wm@11.layer_created(1)
[896386.624] ivi_input@12.seat_created("default", 6)
[896386.671] ivi_wm_screen@9.screen_id(0)
[896386.700] ivi_wm_screen@9.connector_name("Unknown-1")
[896386.731] wl_callback@13.done(1)
[898835.027]  -> wl_compositor@3.create_surface(new id wl_surface@13)
[898835.104]  -> ivi_application@5.surface_create(5242880, wl_surface@13, new id ivi_surface@14)
[898835.179]  -> wl_display@1.sync(new id wl_callback@15)
[898835.481] wl_display@1.delete_id(15)
[898835.558] wl_callback@15.done(1)
[898835.649]  -> wl_display@1.sync(new id wl_callback@15)
[898835.714] ivi_wm@11.surface_created(5242880)
[898835.870] ivi_input@12.input_acceptance(5242880, "default", 1)
[898835.985] wl_display@1.delete_id(15)
[898836.465]  -> mali_buffer_sharing@8.create_buffer(new id wl_buffer@16, 200, 100, 800, 3, 1, 0)
[898842.573]  -> ivi_wm@11.layer_add_surface(1, 5242880)
[898842.703]  -> ivi_wm@11.commit_changes()
[898842.732]  -> wl_display@1.sync(new id wl_callback@17)
[898842.850] wl_display@1.delete_id(17)
[898842.885] wl_callback@17.done(1)
[898842.943]  -> wl_display@1.sync(new id wl_callback@17)
[898843.028] wl_display@1.delete_id(17)
[898843.060] wl_callback@17.done(1)
[898843.090]  -> ivi_wm@11.surface_sync(5242880, 0)
[898843.133]  -> wl_display@1.sync(new id wl_callback@17)
[898843.214] wl_display@1.delete_id(17)
[898843.245] wl_callback@17.done(1)
[898844.107]  -> ivi_wm@11.layer_add_surface(1, 5242880)
[898844.169]  -> ivi_wm@11.layer_clear(1)
[898844.399]  -> ivi_wm@11.layer_add_surface(1, 5242880)
[898844.458]  -> wl_surface@13.frame(new id wl_callback@17)
[898844.509]  -> wl_surface@13.attach(wl_buffer@16, 0, 0)
[898844.569]  -> wl_surface@13.damage(0, 0, 4096, 4096)
[898844.638]  -> wl_surface@13.commit()
[898844.666]  -> ivi_wm@11.set_surface_source_rectangle(5242880, 0, 0, 720, 576)
[898844.766]  -> ivi_wm@11.set_surface_destination_rectangle(5242880, 0, 30, 300, 220)
[898844.858]  -> ivi_wm@11.set_surface_visibility(5242880, 1)
[898844.907]  -> ivi_wm@11.commit_changes()
[898844.930]  -> wl_display@1.sync(new id wl_callback@18)
[898845.071] ivi_wm@11.surface_size(5242880, 200, 100)
[898845.243] wl_display@1.delete_id(18)
[898845.275] ivi_wm@11.surface_source_rectangle(5242880, 0, 0, 720, 576)
[898845.373] ivi_wm@11.surface_destination_rectangle(5242880, 0, 30, 300, 220)
[898845.522] ivi_wm@11.surface_visibility(5242880, 1)
[898845.588] wl_callback@18.done(1)
[898847.697] wl_display@1.delete_id(17)
[898929.852] wl_callback@17.done(613473103)
[898929.922]  -> wl_display@1.sync(new id wl_callback@17)
[898930.042] wl_display@1.delete_id(17)
[898930.047] wl_callback@17.done(1)
[898930.111]  -> wl_buffer@16.destroy()
[898933.278]  -> mali_buffer_sharing@8.create_buffer(new id wl_buffer@17, 720, 576, 2880, 3, 1, 0)
[898936.818]  -> wl_surface@13.frame(new id wl_callback@18)
[898936.863]  -> wl_surface@13.attach(wl_buffer@17, 0, 0)
[898936.919]  -> wl_surface@13.damage(0, 0, 4096, 4096)
[898936.986]  -> wl_surface@13.commit()
[898937.631] wl_display@1.delete_id(16)
[898937.673] ivi_wm@11.surface_size(5242880, 720, 576)
[898939.931] wl_display@1.delete_id(18)
[898971.411]  -> mali_buffer_sharing@8.create_buffer(new id wl_buffer@16, 720, 576, 2880, 3, 2, 0)
[898974.646] wl_callback@18.done(613473196)
[898974.700]  -> wl_surface@13.frame(new id wl_callback@18)
[898974.738]  -> wl_surface@13.attach(wl_buffer@16, 0, 0)
[898974.793]  -> wl_surface@13.damage(0, 0, 4096, 4096)
[898974.858]  -> wl_surface@13.commit()
[898977.667] wl_display@1.delete_id(18)
[899012.708] wl_buffer@17.release()
[899012.746] wl_callback@18.done(613473233)
[899012.780]  -> wl_surface@13.frame(new id wl_callback@18)
[899012.820]  -> wl_surface@13.attach(wl_buffer@17, 0, 0)
[899012.875]  -> wl_surface@13.damage(0, 0, 4096, 4096)
[899012.940]  -> wl_surface@13.commit()
[899015.667] wl_display@1.delete_id(18)
[899052.654] wl_buffer@16.release()

So, you see that I do render, then set source region, destination region, visibility, add surface to the layer, and set the rendering order. However, what is displayed is as the surface had size of 200x100 (created size of the surface).
Now if I change anything, for example source region, as in log below, the image is displayed fine:

[954092.456] wl_callback@18.done(613528311)
[954092.492]  -> wl_surface@13.frame(new id wl_callback@18)
[954092.532]  -> wl_surface@13.attach(wl_buffer@16, 0, 0)
[954092.587]  -> wl_surface@13.damage(0, 0, 4096, 4096)
[954092.654]  -> wl_surface@13.commit()
[954095.370] wl_display@1.delete_id(18)
[954116.791] ivi_wm@11.surface_source_rectangle(5242880, 0, 0, 719, 575)
[954132.559] wl_buffer@17.release()
[954132.645] wl_callback@18.done(613528351)
[954132.686]  -> wl_surface@13.frame(new id wl_callback@18)
[954132.727]  -> wl_surface@13.attach(wl_buffer@17, 0, 0)
[954132.783]  -> wl_surface@13.damage(0, 0, 4096, 4096)
[954132.848]  -> wl_surface@13.commit()
[954136.136] wl_display@1.delete_id(18)
[954172.405] wl_buffer@16.release()

No, I need to set the position - that is why we chose IVI.

I looked into IVI source code, and I saw that "ilm_commitChanges()" is actually doing that, and I am committing changes everywhere.

The problem is definitely in "wl_egl_window_resize()". Somehow this change gets to the weston's compositor only on next ivi function call. When I create a window with "wl_egl_window_create( wlSurface, 1024, 1024 )" - that means bigger size then I need - then everything works fine.

Anyway, thank you for all help.

Cheers,
Vladimir

Hello Vladimir,

Please find the commented log from below:
[898836.465]  -> mali_buffer_sharing@8.create_buffer(new id wl_buffer@16, 200, 100, 800, 3, 1, 0)
Application creates buffer with 200x100

[898842.573]  -> ivi_wm@11.layer_add_surface(1, 5242880)
[898842.703]  -> ivi_wm@11.commit_changes()
[898842.732]  -> wl_display@1.sync(new id wl_callback@17)
[898842.850] wl_display@1.delete_id(17) [898842.885] wl_callback@17.done(1)
[898842.943]  -> wl_display@1.sync(new id wl_callback@17)
[898843.028] wl_display@1.delete_id(17)
[898843.060] wl_callback@17.done(1)
[898843.090]  -> ivi_wm@11.surface_sync(5242880, 0)
[898843.133]  -> wl_display@1.sync(new id wl_callback@17)
[898843.214] wl_display@1.delete_id(17)
[898843.245] wl_callback@17.done(1)
[898844.107]  -> ivi_wm@11.layer_add_surface(1, 5242880)
[898844.169]  -> ivi_wm@11.layer_clear(1)
[898844.399]  -> ivi_wm@11.layer_add_surface(1, 5242880)
[898844.458]  -> wl_surface@13.frame(new id wl_callback@17)
[898844.509]  -> wl_surface@13.attach(wl_buffer@16, 0, 0)
[898844.569]  -> wl_surface@13.damage(0, 0, 4096, 4096)
This is a bug in a mali egl driver but I guess it is not relevant for the current issue, size of the damage area is wrong!

[898844.638]  -> wl_surface@13.commit()
[898844.666]  -> ivi_wm@11.set_surface_source_rectangle(5242880, 0, 0, 720, 576)
How are you guessing the source size? You buffer is 200 to 100 so just set it to
ivi_wm@11.set_surface_source_rectangle(5242880, 0, 0, 200, 100)
if you are using values bigger then the source dimensions, the ivi-shell will calculate weird transformation matrix which will be used for the view calculation in the weston, this weird result you are seeing on the screen!!!
Fix it!

[898844.766]  -> ivi_wm@11.set_surface_destination_rectangle(5242880, 0, 30, 300, 220)
[898844.858]  -> ivi_wm@11.set_surface_visibility(5242880, 1)
[898844.907]  -> ivi_wm@11.commit_changes()
[898844.930]  -> wl_display@1.sync(new id wl_callback@18)
[898845.071] ivi_wm@11.surface_size(5242880, 200, 100)
Actually you should set the source and destination only after this call here you will know how big the surface really is
Use this parameter always for source region

[898845.243] wl_display@1.delete_id(18)
[898845.275] ivi_wm@11.surface_source_rectangle(5242880, 0, 0, 720, 576)
Settting again wrong values will not help buffer is still 200x100

[898845.373] ivi_wm@11.surface_destination_rectangle(5242880, 0, 30, 300, 220)
[898845.522] ivi_wm@11.surface_visibility(5242880, 1)
[898845.588] wl_callback@18.done(1)
[898847.697] wl_display@1.delete_id(17)
[898929.852] wl_callback@17.done(613473103)
[898929.922]  -> wl_display@1.sync(new id wl_callback@17)
[898930.042] wl_display@1.delete_id(17)
[898930.047] wl_callback@17.done(1)
[898930.111]  -> wl_buffer@16.destroy()
[898933.278]  -> mali_buffer_sharing@8.create_buffer(new id wl_buffer@17, 720, 576, 2880, 3, 1, 0)
[898936.818]  -> wl_surface@13.frame(new id wl_callback@18)
[898936.863]  -> wl_surface@13.attach(wl_buffer@17, 0, 0)
[898936.919]  -> wl_surface@13.damage(0, 0, 4096, 4096)
[898936.986]  -> wl_surface@13.commit()
[898937.631] wl_display@1.delete_id(16)
[898937.673] ivi_wm@11.surface_size(5242880, 720, 576)
Now application commited new buffers with expected size, time to update the source region,
Here of course you could argue that you already set the expected source size but the implementation between weston and ivi-shell is not always straightforward AND ivi-shell provides possibility to control the layout of the composition and expects that application controller will also do it, so ivi-shell will not do some automatic reaction or realignment on its own....

Best regards

Eugen Friedrich
Engineering Software Multimedia 1 (ADITG/ESM1)

Tel. +49 5121 49 6921

[ef] your comments are very welcome and I totally agree with the point about the documentation, we need to fix it!

Actually, 200x100 is the initial window size, which is later changed to 720x576. I am not guessing the size, that is the size of the camera image.
I change the window size with "wl_egl_window_resize()", but for some reason that change is not taking place right away.
I tried "glFlush()" and "wl_surface_commit()" and "wl_display_roundtrip()" and nothing worked. The size is somehow updated later.
The question is, is this a bug? Or do I need to somehow flush this change?
I found a workaround by creating a bigger initial window (1024x1024) and not using "wl_elg_window_resize()" later. But that will only work until someone connects a camera with bigger resolution. So, I would need a proper solution.

Hello Vladimir,

Best regards

Eugen Friedrich
Engineering Software Multimedia 1 (ADITG/ESM1)

Tel. +49 5121 49 6921

[EF] to be honest not idea if you can call it a bug, but definitely there is different behavior of wl_elg_window_create and wl_elg_window_resize in different EGL implementations, if you will take a look to the resent one: provided by wayland package there are callbacks which have to be implemented in the EGL stack. So it's implementation dependent and the question is would those calls create/recreate and flush the wayland buffers or not!

If not application would need to render at least one frame to see effect of the wl_elg_window_resize. In this case the EGL implementation should recognize the change and recreate the native buffers for rendering and this seems to be the case in you mali-EGL implementation.

The proper solution with ivi-shell is to react on the surface configure events [ivi_wm@11.surface_size(5242880, 720, 576)] and set the source/destination regions accordingly.
Look here:
https://github.com/GENIVI/wayland-ivi-extension/blob/master/ivi-layermanagement-examples/layer-add-surfaces/src/layer-add-surfaces.c#L42

for you use-case, modification of the callback is of cause required: you should not remove the Notification and you could differentiate between first and following size changes...
Please let me know if this approach is working or more important NOT working for you!