genivi-ivi-layer-management@lists.genivi.org

development mailing list for GENIVI LayerManagement

View all threads

wl_egl_window_resize does not

JV
Jovic, Vladimir
Tue, May 28, 2019 11:38 AM

Hi,

In my program, I am creating an EGL window with
nativeWindow = wl_egl_window_create( wlSurface, 200, 100 );
create context, etc. I see the surface with "LayerManagerControl get scene", and it has 0x0 origin size.
Then I do:
wl_egl_window_resize( nativeWindow, 500, 400, 0, 0 );
eglSwapBuffers( eglDisplay, surface );
Then I see that the origin size changes to 200x100, not to 500x400.
Then I set source region. Then destination. And then visibility. The origin changes to 500x400, but what is rendered to the screen is as is the window was 200x100. Then I see source region again, and the image is rendered normally 500x400.

I registered the callback using "ilm_surfaceAddNotification()" and the callback gets called for every change above, and the parameters for origin are 200x100 until the last ILM_NOTIFICATION_CONFIGURED, when they change to 500x400, but the image is still little.

So, is there a way to somehow bump the Weston to update the parameters? Do I need to call "wl_surface_commit()"? Or "wl_display_roundtrip()"? Or anything else?

Mit freundlichen Grüßen

i. A. Vladimir Jovic
ifm ecomatic gmbh

Hi, In my program, I am creating an EGL window with nativeWindow = wl_egl_window_create( wlSurface, 200, 100 ); create context, etc. I see the surface with "LayerManagerControl get scene", and it has 0x0 origin size. Then I do: wl_egl_window_resize( nativeWindow, 500, 400, 0, 0 ); eglSwapBuffers( eglDisplay, surface ); Then I see that the origin size changes to 200x100, not to 500x400. Then I set source region. Then destination. And then visibility. The origin changes to 500x400, but what is rendered to the screen is as is the window was 200x100. Then I see source region again, and the image is rendered normally 500x400. I registered the callback using "ilm_surfaceAddNotification()" and the callback gets called for every change above, and the parameters for origin are 200x100 until the last ILM_NOTIFICATION_CONFIGURED, when they change to 500x400, but the image is still little. So, is there a way to somehow bump the Weston to update the parameters? Do I need to call "wl_surface_commit()"? Or "wl_display_roundtrip()"? Or anything else? Mit freundlichen Grüßen i. A. Vladimir Jovic ifm ecomatic gmbh
FE
Friedrich, Eugen (ADITG/ESM1)
Fri, May 31, 2019 5:18 PM

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

-----Original Message-----
From: genivi-ivi-layer-management <genivi-ivi-layer-management-
bounces@lists.genivi.org> On Behalf Of Jovic, Vladimir
Sent: Dienstag, 28. Mai 2019 13:40
To: genivi-ivi-layer-management@lists.genivi.org
Subject: wl_egl_window_resize does not

Hi,

In my program, I am creating an EGL window with
nativeWindow = wl_egl_window_create( wlSurface, 200, 100 );
create context, etc. I see the surface with "LayerManagerControl get scene",
and it has 0x0 origin size.

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...

Then I do:
wl_egl_window_resize( nativeWindow, 500, 400, 0, 0 );
eglSwapBuffers( eglDisplay, surface );
Then I see that the origin size changes to 200x100, not to 500x400.
Then I set source region. Then destination. And then visibility. The origin
changes to 500x400, but what is rendered to the screen is as is the window
was 200x100. Then I see source region again, and the image is rendered
normally 500x400.

I registered the callback using "ilm_surfaceAddNotification()" and the
callback gets called for every change above, and the parameters for origin are
200x100 until the last ILM_NOTIFICATION_CONFIGURED, when they change
to 500x400, but the image is still little.

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)

So, is there a way to somehow bump the Weston to update the parameters?
Do I need to call "wl_surface_commit()"? Or "wl_display_roundtrip()"? Or
anything else?

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

Mit freundlichen Grüßen

i. A. Vladimir Jovic
ifm ecomatic gmbh


genivi-ivi-layer-management mailing list
genivi-ivi-layer-management@lists.genivi.org
http://lists.genivi.org/mailman/listinfo/genivi-ivi-layer-
management_lists.genivi.org

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 > -----Original Message----- > From: genivi-ivi-layer-management <genivi-ivi-layer-management- > bounces@lists.genivi.org> On Behalf Of Jovic, Vladimir > Sent: Dienstag, 28. Mai 2019 13:40 > To: genivi-ivi-layer-management@lists.genivi.org > Subject: wl_egl_window_resize does not > > Hi, > > In my program, I am creating an EGL window with > nativeWindow = wl_egl_window_create( wlSurface, 200, 100 ); > create context, etc. I see the surface with "LayerManagerControl get scene", > and it has 0x0 origin size. 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... > Then I do: > wl_egl_window_resize( nativeWindow, 500, 400, 0, 0 ); > eglSwapBuffers( eglDisplay, surface ); > Then I see that the origin size changes to 200x100, not to 500x400. > Then I set source region. Then destination. And then visibility. The origin > changes to 500x400, but what is rendered to the screen is as is the window > was 200x100. Then I see source region again, and the image is rendered > normally 500x400. > > I registered the callback using "ilm_surfaceAddNotification()" and the > callback gets called for every change above, and the parameters for origin are > 200x100 until the last ILM_NOTIFICATION_CONFIGURED, when they change > to 500x400, but the image is still little. 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) > > So, is there a way to somehow bump the Weston to update the parameters? > Do I need to call "wl_surface_commit()"? Or "wl_display_roundtrip()"? Or > anything else? If you would like to ensure the wayland communication is in sync you should call wl_display_roundtrip(); > > > Mit freundlichen Grüßen > > i. A. Vladimir Jovic > ifm ecomatic gmbh > > > > _______________________________________________ > genivi-ivi-layer-management mailing list > genivi-ivi-layer-management@lists.genivi.org > http://lists.genivi.org/mailman/listinfo/genivi-ivi-layer- > management_lists.genivi.org
JV
Jovic, Vladimir
Tue, Jun 4, 2019 9:50 AM

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

-----Ursprüngliche Nachricht-----
Von: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com
Gesendet: Freitag, 31. Mai 2019 19:19
An: Jovic, Vladimir vladimir.jovic@ifm.com; genivi-ivi-layer-
management@lists.genivi.org
Betreff: RE: wl_egl_window_resize does not

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://urldefense.proofpoint.com/v2/url?u=https-
3A__lists.freedesktop.org_archives_mesa-2Ddev_2018-
2DJune_196474.html&d=DwIFAw&c=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8x0nH
a2EM0&r=8wfdsMUxnRudpdLb_Cg4rnnnKI-
gQZ4ykr3tjUrejXg&m=GJFPmypftkG2Gg0m9fVKBCI6wDoBM1W_QJkk0-4-
z18&s=tFpHQHsmhBy0UJuEz4n9vuwTd0vFgkEH3_2apd8EMws&e=

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..

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

Best regards

Eugen Friedrich
Engineering Software Multimedia 1 (ADITG/ESM1)

Tel. +49 5121 49 6921

-----Original Message-----
From: genivi-ivi-layer-management <genivi-ivi-layer-management-
bounces@lists.genivi.org> On Behalf Of Jovic, Vladimir
Sent: Dienstag, 28. Mai 2019 13:40
To: genivi-ivi-layer-management@lists.genivi.org
Subject: wl_egl_window_resize does not

Hi,

In my program, I am creating an EGL window with
nativeWindow = wl_egl_window_create( wlSurface, 200, 100 ); create
context, etc. I see the surface with "LayerManagerControl get scene",
and it has 0x0 origin size.

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...

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()

Then I do:
wl_egl_window_resize( nativeWindow, 500, 400, 0, 0 );
eglSwapBuffers( eglDisplay, surface ); Then I see that the origin
size changes to 200x100, not to 500x400.
Then I set source region. Then destination. And then visibility. The
origin changes to 500x400, but what is rendered to the screen is as is
the window was 200x100. Then I see source region again, and the image
is rendered normally 500x400.

I registered the callback using "ilm_surfaceAddNotification()" and the
callback gets called for every change above, and the parameters for
origin are
200x100 until the last ILM_NOTIFICATION_CONFIGURED, when they change
to 500x400, but the image is still little.

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)

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

So, is there a way to somehow bump the Weston to update the parameters?
Do I need to call "wl_surface_commit()"? Or "wl_display_roundtrip()"?
Or anything else?

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

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

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 > -----Ursprüngliche Nachricht----- > Von: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com> > Gesendet: Freitag, 31. Mai 2019 19:19 > An: Jovic, Vladimir <vladimir.jovic@ifm.com>; genivi-ivi-layer- > management@lists.genivi.org > Betreff: RE: wl_egl_window_resize does not > > 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://urldefense.proofpoint.com/v2/url?u=https- > 3A__lists.freedesktop.org_archives_mesa-2Ddev_2018- > 2DJune_196474.html&d=DwIFAw&c=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8x0nH > a2EM0&r=8wfdsMUxnRudpdLb_Cg4rnnnKI- > gQZ4ykr3tjUrejXg&m=GJFPmypftkG2Gg0m9fVKBCI6wDoBM1W_QJkk0-4- > z18&s=tFpHQHsmhBy0UJuEz4n9vuwTd0vFgkEH3_2apd8EMws&e= > > 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.. I tried all kind of things. "wl_display_flush()" does not seem to do anything. Could it be device driver bug? > > Best regards > > Eugen Friedrich > Engineering Software Multimedia 1 (ADITG/ESM1) > > Tel. +49 5121 49 6921 > > > -----Original Message----- > > From: genivi-ivi-layer-management <genivi-ivi-layer-management- > > bounces@lists.genivi.org> On Behalf Of Jovic, Vladimir > > Sent: Dienstag, 28. Mai 2019 13:40 > > To: genivi-ivi-layer-management@lists.genivi.org > > Subject: wl_egl_window_resize does not > > > > Hi, > > > > In my program, I am creating an EGL window with > > nativeWindow = wl_egl_window_create( wlSurface, 200, 100 ); create > > context, etc. I see the surface with "LayerManagerControl get scene", > > and it has 0x0 origin size. > > 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... > 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() > > Then I do: > > wl_egl_window_resize( nativeWindow, 500, 400, 0, 0 ); > > eglSwapBuffers( eglDisplay, surface ); Then I see that the origin > > size changes to 200x100, not to 500x400. > > Then I set source region. Then destination. And then visibility. The > > origin changes to 500x400, but what is rendered to the screen is as is > > the window was 200x100. Then I see source region again, and the image > > is rendered normally 500x400. > > > > I registered the callback using "ilm_surfaceAddNotification()" and the > > callback gets called for every change above, and the parameters for > > origin are > > 200x100 until the last ILM_NOTIFICATION_CONFIGURED, when they change > > to 500x400, but the image is still little. > > 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) > No, I need to set the position - that is why we chose IVI. > > > > So, is there a way to somehow bump the Weston to update the parameters? > > Do I need to call "wl_surface_commit()"? Or "wl_display_roundtrip()"? > > Or anything else? > If you would like to ensure the wayland communication is in sync you should call > wl_display_roundtrip(); I looked into IVI source code, and I saw that "ilm_commitChanges()" is actually doing that, and I am committing changes everywhere.
JV
Jovic, Vladimir
Tue, Jun 4, 2019 1:52 PM

-----Ursprüngliche Nachricht-----
Von: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com
Gesendet: Freitag, 31. Mai 2019 19:19
An: Jovic, Vladimir vladimir.jovic@ifm.com; genivi-ivi-layer-
management@lists.genivi.org
Betreff: RE: wl_egl_window_resize does not

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://urldefense.proofpoint.com/v2/url?u=https-
3A__lists.freedesktop.org_archives_mesa-2Ddev_2018-
2DJune_196474.html&d=DwIFAw&c=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8x0nH
a2EM0&r=8wfdsMUxnRudpdLb_Cg4rnnnKI-
gQZ4ykr3tjUrejXg&m=GJFPmypftkG2Gg0m9fVKBCI6wDoBM1W_QJkk0-4-
z18&s=tFpHQHsmhBy0UJuEz4n9vuwTd0vFgkEH3_2apd8EMws&e=

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..

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

> -----Ursprüngliche Nachricht----- > Von: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com> > Gesendet: Freitag, 31. Mai 2019 19:19 > An: Jovic, Vladimir <vladimir.jovic@ifm.com>; genivi-ivi-layer- > management@lists.genivi.org > Betreff: RE: wl_egl_window_resize does not > > 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://urldefense.proofpoint.com/v2/url?u=https- > 3A__lists.freedesktop.org_archives_mesa-2Ddev_2018- > 2DJune_196474.html&d=DwIFAw&c=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8x0nH > a2EM0&r=8wfdsMUxnRudpdLb_Cg4rnnnKI- > gQZ4ykr3tjUrejXg&m=GJFPmypftkG2Gg0m9fVKBCI6wDoBM1W_QJkk0-4- > z18&s=tFpHQHsmhBy0UJuEz4n9vuwTd0vFgkEH3_2apd8EMws&e= > > 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.. 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
FE
Friedrich, Eugen (ADITG/ESM1)
Tue, Jun 4, 2019 6:04 PM

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

-----Original Message-----
From: Jovic, Vladimir vladimir.jovic@ifm.com
Sent: Dienstag, 4. Juni 2019 15:53
To: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com; genivi-ivi-
layer-management@lists.genivi.org
Subject: AW: wl_egl_window_resize does not

-----Ursprüngliche Nachricht-----
Von: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com
Gesendet: Freitag, 31. Mai 2019 19:19
An: Jovic, Vladimir vladimir.jovic@ifm.com; genivi-ivi-layer-
management@lists.genivi.org
Betreff: RE: wl_egl_window_resize does not

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://urldefense.proofpoint.com/v2/url?u=https-
3A__lists.freedesktop.org_archives_mesa-2Ddev_2018-

2DJune_196474.html&d=DwIFAw&c=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8
x0nH

a2EM0&r=8wfdsMUxnRudpdLb_Cg4rnnnKI-
gQZ4ykr3tjUrejXg&m=GJFPmypftkG2Gg0m9fVKBCI6wDoBM1W_QJkk0-4-
z18&s=tFpHQHsmhBy0UJuEz4n9vuwTd0vFgkEH3_2apd8EMws&e=

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..

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.

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

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 > -----Original Message----- > From: Jovic, Vladimir <vladimir.jovic@ifm.com> > Sent: Dienstag, 4. Juni 2019 15:53 > To: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com>; genivi-ivi- > layer-management@lists.genivi.org > Subject: AW: wl_egl_window_resize does not > > > > -----Ursprüngliche Nachricht----- > > Von: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com> > > Gesendet: Freitag, 31. Mai 2019 19:19 > > An: Jovic, Vladimir <vladimir.jovic@ifm.com>; genivi-ivi-layer- > > management@lists.genivi.org > > Betreff: RE: wl_egl_window_resize does not > > > > 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://urldefense.proofpoint.com/v2/url?u=https- > > 3A__lists.freedesktop.org_archives_mesa-2Ddev_2018- > > > 2DJune_196474.html&d=DwIFAw&c=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8 > x0nH > > a2EM0&r=8wfdsMUxnRudpdLb_Cg4rnnnKI- > > gQZ4ykr3tjUrejXg&m=GJFPmypftkG2Gg0m9fVKBCI6wDoBM1W_QJkk0-4- > > z18&s=tFpHQHsmhBy0UJuEz4n9vuwTd0vFgkEH3_2apd8EMws&e= > > > > 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.. > > > 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. [ef] your comments are very welcome and I totally agree with the point about the documentation, we need to fix it! > > Cheers, > Vladimir
JV
Jovic, Vladimir
Tue, Jun 11, 2019 8:24 AM

-----Ursprüngliche Nachricht-----
Von: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com
Gesendet: Dienstag, 4. Juni 2019 20:05
An: Jovic, Vladimir vladimir.jovic@ifm.com; genivi-ivi-layer-
management@lists.genivi.org
Betreff: RE: wl_egl_window_resize does not

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

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.

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

-----Original Message-----
From: Jovic, Vladimir vladimir.jovic@ifm.com
Sent: Dienstag, 4. Juni 2019 15:53
To: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com;
genivi-ivi- layer-management@lists.genivi.org
Subject: AW: wl_egl_window_resize does not

-----Ursprüngliche Nachricht-----
Von: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com
Gesendet: Freitag, 31. Mai 2019 19:19
An: Jovic, Vladimir vladimir.jovic@ifm.com; genivi-ivi-layer-
management@lists.genivi.org
Betreff: RE: wl_egl_window_resize does not

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://urldefense.proofpoint.com/v2/url?u=https-
3A__lists.freedesktop.org_archives_mesa-2Ddev_2018-

2DJune_196474.html&d=DwIFAw&c=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8
x0nH

a2EM0&r=8wfdsMUxnRudpdLb_Cg4rnnnKI-
gQZ4ykr3tjUrejXg&m=GJFPmypftkG2Gg0m9fVKBCI6wDoBM1W_QJkk0-4-
z18&s=tFpHQHsmhBy0UJuEz4n9vuwTd0vFgkEH3_2apd8EMws&e=

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..

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.

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

Cheers,
Vladimir

> -----Ursprüngliche Nachricht----- > Von: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com> > Gesendet: Dienstag, 4. Juni 2019 20:05 > An: Jovic, Vladimir <vladimir.jovic@ifm.com>; genivi-ivi-layer- > management@lists.genivi.org > Betreff: RE: wl_egl_window_resize does not > > 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 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. > 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 > > -----Original Message----- > > From: Jovic, Vladimir <vladimir.jovic@ifm.com> > > Sent: Dienstag, 4. Juni 2019 15:53 > > To: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com>; > > genivi-ivi- layer-management@lists.genivi.org > > Subject: AW: wl_egl_window_resize does not > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com> > > > Gesendet: Freitag, 31. Mai 2019 19:19 > > > An: Jovic, Vladimir <vladimir.jovic@ifm.com>; genivi-ivi-layer- > > > management@lists.genivi.org > > > Betreff: RE: wl_egl_window_resize does not > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https- > > > 3A__lists.freedesktop.org_archives_mesa-2Ddev_2018- > > > > > 2DJune_196474.html&d=DwIFAw&c=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8 > > x0nH > > > a2EM0&r=8wfdsMUxnRudpdLb_Cg4rnnnKI- > > > gQZ4ykr3tjUrejXg&m=GJFPmypftkG2Gg0m9fVKBCI6wDoBM1W_QJkk0-4- > > > z18&s=tFpHQHsmhBy0UJuEz4n9vuwTd0vFgkEH3_2apd8EMws&e= > > > > > > 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.. > > > > > > 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. > [ef] your comments are very welcome and I totally agree with the point about the > documentation, we need to fix it! > > > > Cheers, > > Vladimir >
FE
Friedrich, Eugen (ADITG/ESM1)
Tue, Jun 11, 2019 11:09 AM

Hello Vladimir,

Best regards

Eugen Friedrich
Engineering Software Multimedia 1 (ADITG/ESM1)

Tel. +49 5121 49 6921

-----Original Message-----
From: Jovic, Vladimir vladimir.jovic@ifm.com
Sent: Dienstag, 11. Juni 2019 10:24
To: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com; genivi-ivi-
layer-management@lists.genivi.org
Subject: AW: wl_egl_window_resize does not

-----Ursprüngliche Nachricht-----
Von: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com
Gesendet: Dienstag, 4. Juni 2019 20:05
An: Jovic, Vladimir vladimir.jovic@ifm.com; genivi-ivi-layer-
management@lists.genivi.org
Betreff: RE: wl_egl_window_resize does not

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]  ->

[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]  ->

  1. [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

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.

[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!

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,

[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]  ->

[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

-----Original Message-----
From: Jovic, Vladimir vladimir.jovic@ifm.com
Sent: Dienstag, 4. Juni 2019 15:53
To: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com;
genivi-ivi- layer-management@lists.genivi.org
Subject: AW: wl_egl_window_resize does not

-----Ursprüngliche Nachricht-----
Von: Friedrich, Eugen (ADITG/ESM1) efriedrich@de.adit-jv.com
Gesendet: Freitag, 31. Mai 2019 19:19
An: Jovic, Vladimir vladimir.jovic@ifm.com; genivi-ivi-layer-
management@lists.genivi.org
Betreff: RE: wl_egl_window_resize does not

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://urldefense.proofpoint.com/v2/url?u=https-
3A__lists.freedesktop.org_archives_mesa-2Ddev_2018-

2DJune_196474.html&d=DwIFAw&c=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8

x0nH

a2EM0&r=8wfdsMUxnRudpdLb_Cg4rnnnKI-

gQZ4ykr3tjUrejXg&m=GJFPmypftkG2Gg0m9fVKBCI6wDoBM1W_QJkk0-4-

z18&s=tFpHQHsmhBy0UJuEz4n9vuwTd0vFgkEH3_2apd8EMws&e=

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..

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.

[ef] your comments are very welcome and I totally agree with the point

about the

documentation, we need to fix it!

Cheers,
Vladimir

Hello Vladimir, Best regards Eugen Friedrich Engineering Software Multimedia 1 (ADITG/ESM1) Tel. +49 5121 49 6921 > -----Original Message----- > From: Jovic, Vladimir <vladimir.jovic@ifm.com> > Sent: Dienstag, 11. Juni 2019 10:24 > To: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com>; genivi-ivi- > layer-management@lists.genivi.org > Subject: AW: wl_egl_window_resize does not > > > > -----Ursprüngliche Nachricht----- > > Von: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com> > > Gesendet: Dienstag, 4. Juni 2019 20:05 > > An: Jovic, Vladimir <vladimir.jovic@ifm.com>; genivi-ivi-layer- > > management@lists.genivi.org > > Betreff: RE: wl_egl_window_resize does not > > > > 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 > > 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. [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! > > > > > 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 > > > -----Original Message----- > > > From: Jovic, Vladimir <vladimir.jovic@ifm.com> > > > Sent: Dienstag, 4. Juni 2019 15:53 > > > To: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com>; > > > genivi-ivi- layer-management@lists.genivi.org > > > Subject: AW: wl_egl_window_resize does not > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Friedrich, Eugen (ADITG/ESM1) <efriedrich@de.adit-jv.com> > > > > Gesendet: Freitag, 31. Mai 2019 19:19 > > > > An: Jovic, Vladimir <vladimir.jovic@ifm.com>; genivi-ivi-layer- > > > > management@lists.genivi.org > > > > Betreff: RE: wl_egl_window_resize does not > > > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https- > > > > 3A__lists.freedesktop.org_archives_mesa-2Ddev_2018- > > > > > > > > 2DJune_196474.html&d=DwIFAw&c=riR7jviByh3sGm7GIiSlHkFN0_aSATB6A8 > > > x0nH > > > > a2EM0&r=8wfdsMUxnRudpdLb_Cg4rnnnKI- > > > > > gQZ4ykr3tjUrejXg&m=GJFPmypftkG2Gg0m9fVKBCI6wDoBM1W_QJkk0-4- > > > > z18&s=tFpHQHsmhBy0UJuEz4n9vuwTd0vFgkEH3_2apd8EMws&e= > > > > > > > > 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.. > > > > > > > > > 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. > > [ef] your comments are very welcome and I totally agree with the point > about the > > documentation, we need to fix it! > > > > > > Cheers, > > > Vladimir > > >