development mailing list for GENIVI LayerManagement
View all threadsHi,
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
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
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.
-----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
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
-----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
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] ->
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