weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2019-01-31T00:53:33Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/176Spews seen on running consecutive 2 client application on weston2019-01-31T00:53:33ZKamal ChandraSpews seen on running consecutive 2 client application on westonOn launching Weston with ivi-shell and running two instances of weston-simple-egl client application following spews are observed:
```
[09:09:37.228] ivi-shell: source rectangle is not yet set by ivi_layout_surface_set_source_rectangle
...On launching Weston with ivi-shell and running two instances of weston-simple-egl client application following spews are observed:
```
[09:09:37.228] ivi-shell: source rectangle is not yet set by ivi_layout_surface_set_source_rectangle
[09:09:37.229] ivi-shell: source rectangle is not yet set by ivi_layout_surface_set_source_rectangle
[09:09:37.262] ivi-shell: destination rectangle is not yet set by ivi_layout_surface_set_destination_rectangle
[09:09:37.295] ivi-shell: destination rectangle is not yet set by ivi_layout_surface_set_destination_rectangle
[09:09:37.329] ivi-shell: destination rectangle is not yet set by ivi_layout_surface_set_destination_rectangle
[09:09:37.362] ivi-shell: destination rectangle is not yet set by ivi_layout_surface_set_destination_rectangle
[09:09:37.395] ivi-shell: destination rectangle is not yet set by ivi_layout_surface_set_destination_rectangle
[09:09:37.428] ivi-shell: destination rectangle is not yet set by ivi_layout_surface_set_destination_rectangle
[09:09:37.461] ivi-shell: destination rectangle is not yet set by ivi_layout_surface_set_destination_rectangle
[09:09:37.494] ivi-shell: destination rectangle is not yet set by ivi_layout_surface_set_destination_rectangle
[09:09:37.527] ivi-shell: destination rectangle is not yet set by ivi_layout_surface_set_destination_rectangle
```
I'm using weston v2.0, wayland v1.13
Are these logs expected? Why does these logs occur, is something missing? How does the setting of source and destination rectangle takes place?
Weston is launched as:
weston --shell=ivi-shell.so
2 instances of client are launched consecutively as (copy these two commands and launch paste them on linux console in one go):
weston-simple-egl &
weston-simple-egl &
One more observation is that if these client applications are launched with some delay these spews are not observed.https://gitlab.freedesktop.org/wayland/weston/-/issues/184Spurious failure in ivi-layout test in CI2019-01-31T10:07:36ZAlexandros FrantzisSpurious failure in ivi-layout test in CIDuring an unrelated change I saw a failure in the ivi-layout test in CI:
https://gitlab.freedesktop.org/afrantzis/weston/-/jobs/77268
I haven't been able to reproduce the failure locally.
Rerunning the job in CI was a success: https://...During an unrelated change I saw a failure in the ivi-layout test in CI:
https://gitlab.freedesktop.org/afrantzis/weston/-/jobs/77268
I haven't been able to reproduce the failure locally.
Rerunning the job in CI was a success: https://gitlab.freedesktop.org/afrantzis/weston/-/jobs/77285Daniel Stonedaniel@fooishbar.orgDaniel Stonedaniel@fooishbar.orghttps://gitlab.freedesktop.org/wayland/weston/-/issues/243Remove my Developer access rights2020-08-13T18:55:22ZeucanRemove my Developer access rightsHello,
I will move to a different team at Bosch in the end of this month. Therefore, I will not have time to take care about ivi-shell merge requests.
I propose to grant developer access right to @efriedrich instead of me.
Best Regard...Hello,
I will move to a different team at Bosch in the end of this month. Therefore, I will not have time to take care about ivi-shell merge requests.
I propose to grant developer access right to @efriedrich instead of me.
Best Regards,
Emrehttps://gitlab.freedesktop.org/wayland/weston/-/issues/431Convert tests/ivi-shell-app-test.c to use weston_ini_setup2020-10-01T09:21:29ZIgor TorrenteConvert tests/ivi-shell-app-test.c to use weston_ini_setupWeston has a new method to write a weston.ini(wayland/weston!460), now we need convert the [tests/ivi-shell-app-test.c](https://gitlab.freedesktop.org/wayland/weston/-/blob/master/tests/ivi-shell-app-test.c#L43) to use this new method.Weston has a new method to write a weston.ini(wayland/weston!460), now we need convert the [tests/ivi-shell-app-test.c](https://gitlab.freedesktop.org/wayland/weston/-/blob/master/tests/ivi-shell-app-test.c#L43) to use this new method.https://gitlab.freedesktop.org/wayland/weston/-/issues/457Moving client leaves previous image on ivi-shell2020-11-30T01:54:22ZJunMoving client leaves previous image on ivi-shellI've changed a SoC chip from included arm gpu to imagination gpu recently.
I ran weston-simple-shm and moved the location from <0,0,250,250> to <100,100,250,250> with LayerManagerControl tool.
On chip with arm gpu, the previous image(0,0...I've changed a SoC chip from included arm gpu to imagination gpu recently.
I ran weston-simple-shm and moved the location from <0,0,250,250> to <100,100,250,250> with LayerManagerControl tool.
On chip with arm gpu, the previous image(0,0,250,250) is cleared, but on new chip with imagination gpu, the previous image remains.
So I reported to imagination that there is an issue, but they said that there is different implementation each vendor.
> "for EGL_BUFFER_DESTROYED, the spec. leave each GPU vendor decide if they want to destroy color buffer contents or change by the swapbuffer operation. From our previous debugging experience on ARM, it choose the first one.(destroy color buffer contents which might imply color buffer clear) IMG implement the second one.(changed by the swapbuffer operation which imply we just keep the content on color buffer so we will see the previous content) So if ARM EGL_SWAP_BEHAVIOR is this and if they will do color buffer clear for the EGL_BUFFER_DESTROYED swap behavior, we won't see this issue on ARM."
The arm gpu clears color buffer immediately, but img gpu keeps color buffer until eglSwapBuffers(). So If the GL_BLEND is enabled in first draw-call of gles context, img gpu refer to the previous image(framebuffer) and blending them. I attached dump of egl/gles calls.
![1606451068](/uploads/e2f3ccfa5b189f51f24045e26db91542/1606451068.png)
Additionally, I ran same test with pixman renderer and there is still previous image. So I confused that is this intended? or am I missing something?
Thanks.https://gitlab.freedesktop.org/wayland/weston/-/issues/598weston-ivi-shell-user-interface segfaults with qemu, yocto, virgl, aarch64 an...2022-04-22T13:45:01ZEdgar Neubauerweston-ivi-shell-user-interface segfaults with qemu, yocto, virgl, aarch64 and ivi shellWeston version is 9.0.0.
I try to run weston with virgl on yocto on qemu, x86 host, aarch64 guest. I use hmi controller in weston ini. It works under normal desktop shell, but if I switch to ivi shell then weston-ivi-shell-user-interfac...Weston version is 9.0.0.
I try to run weston with virgl on yocto on qemu, x86 host, aarch64 guest. I use hmi controller in weston ini. It works under normal desktop shell, but if I switch to ivi shell then weston-ivi-shell-user-interface ( and some other weston test apps) start crashing with segfault. This is the callstack:
```
(gdb) bt full
#0 0x0000007ff7fae214 in wl_proxy_marshal (proxy=0x0, opcode=opcode@entry=0) at ../wayland-1.19.0/src/wayland-client.c:793
args = {{i = 1431813888, u = 1431813888, f = 1431813888, s = 0x555557bf00 "/usr/share/weston/panel.png", o = 0x555557bf00, n = 1431813888, a = 0x555557bf00, h = 1431813888}, {i = 1002, u = 1002, f = 1002, s = 0x3ea <error: Cannot access memory at address 0x3ea>, o = 0x3ea, n = 1002, a = 0x3ea, h = 1002}, {i = 1431841984, u = 1431841984, f = 1431841984, s = 0x5555582cc0 "", o = 0x5555582cc0, n = 1431841984, a = 0x5555582cc0, h = 1431841984}, {i = 2001, u = 2001, f = 2001, s = 0x7d1 <error: Cannot access memory at address 0x7d1>, o = 0x7d1, n = 2001, a = 0x7d1, h = 2001}, {i = 1431670784, u = 1431670784, f = 1431670784, s = 0x5555559000 <file_create_dated+512> "\373sG\251@\003", o = 0x5555559000 <file_create_dated+512>, n = 1431670784, a = 0x5555559000 <file_create_dated+512>, h = 1431670784}, {i = -1520, u = 4294965776, f = -1520, s = 0x7ffffffa10 "P\372\377\377\177", o = 0x7ffffffa10, n = 4294965776, a = 0x7ffffffa10, h = -1520}, {i = 1431813888, u = 1431813888, f = 1431813888, s = 0x555557bf00 "/usr/share/weston/panel.png", o = 0x555557bf00, n = 1431813888, a = 0x555557bf00, h = 1431813888}, {i = -2272, u = 4294965024, f = -2272, s = 0x7ffffff720 "", o = 0x7ffffff720, n = 4294965024, a = 0x7ffffff720, h = -2272}, {i = -1381663488, u = 2913303808, f = -1381663488, s = 0xd33c55d8ada57d00 <error: Cannot access memory at address 0xd33c55d8ada57d00>, o = 0xd33c55d8ada57d00, n = 2913303808, a = 0xd33c55d8ada57d00, h = -1381663488}, {i = 0, u = 0, f = 0, s = 0x0, o = 0x0, n = 0, a = 0x0, h = 0}, {i = 0, u = 0, f = 0, s = 0x0, o = 0x0, n = 0, a = 0x0, h = 0}, {i = 0, u = 0, f = 0, s = 0x4052000000000000 <error: Cannot access memory at address 0x4052000000000000>, o = 0x4052000000000000, n = 0, a = 0x4052000000000000, h = 0}, {i = 0, u = 0, f = 0, s = 0x0, o = 0x0, n = 0, a = 0x0, h = 0}, {i = 0, u = 0, f = 0, s = 0xc00cc00000000000 <error: Cannot access memory at address 0xc00cc00000000000>, o = 0xc00cc00000000000, n = 0, a = 0xc00cc00000000000, h = 0}, {i = -1072955392, u = 3222011904, f = -1072955392, s = 0xc00cc00cc00c0000 <error: Cannot access memory at address 0xc00cc00cc00c0000>, o = 0xc00cc00cc00c0000, n = 3222011904, a = 0xc00cc00cc00c0000, h = -1072955392}, {i = 0, u = 0, f = 0, s = 0x0, o = 0x0, n = 0, a = 0x0, h = 0}, {i = 0, u = 0, f = 0, s = 0x0, o = 0x0, n = 0, a = 0x0, h = 0}, {i = 805515267, u = 805515267, f = 805515267, s = 0x3003300330033003 <error: Cannot access memory at address 0x3003300330033003>, o = 0x3003300330033003, n = 805515267, a = 0x3003300330033003, h = 805515267}, {i = 805515267, u = 805515267, f = 805515267, s = 0x3003300330033003 <error: Cannot access memory at address 0x3003300330033003>, o = 0x3003300330033003, n = 805515267, a = 0x3003300330033003, h = 805515267}, {i = -267390961, u = 4027576335, f = -267390961, s = 0xf00ff00ff00ff00f <error: Cannot access memory at address 0xf00ff00ff00ff00f>, o = 0xf00ff00ff00ff00f, n = 4027576335, a = 0xf00ff00ff00ff00f, h = -267390961}}
ap = {__stack = 0x7ffffff800, __gr_top = 0x7ffffff800, __vr_top = 0x7ffffff7d0, __gr_offs = -48, __vr_offs = -128}
#1 0x0000005555555114 in ivi_hmi_controller_UI_ready (ivi_hmi_controller=<optimized out>) at protocol/ivi-hmi-controller-client-protocol.h:165
No locals.
#2 UI_ready (controller=<optimized out>) at ../weston-9.0.0/clients/ivi-shell-user-interface.c:983
No locals.
#3 main (argc=<optimized out>, argv=<optimized out>) at ../weston-9.0.0/clients/ivi-shell-user-interface.c:1323
wlCtxCommon = {wlDisplay = 0x555557c020, wlRegistry = 0x555557d080, wlCompositor = 0x555557cb70, wlShm = 0x555557cc20, formats = 262147, wlSeat = 0x555557cc80, wlPointer = 0x0, wlTouch = 0x0, iviApplication = 0x555557cce0, hmiCtrl = 0x0, hmi_setting = 0x555557aba0, list_wlContextStruct = {prev = 0x555557ce30, next = 0x7ffffffa00}, enterSurface = 0x0, is_home_on = 0, cursor_theme = 0x0, cursors = 0x0, pointer_surface = 0x0, current_cursor = CURSOR_BOTTOM_LEFT, enter_serial = 0}
wlCtx_BackGround = 0x555557ce00
wlCtx_Panel = 0x555557ce50
wlCtx_Button_1 = {cmm = 0x7ffffffa50, wlSurface = 0x555557b140, wlBuffer = 0x555557b200, ctx_image = 0x555557afb0, data = 0x7ff6760000, id_surface = 1003, link = {prev = 0x7ffffff940, next = 0x555557ce80}}
wlCtx_Button_2 = {cmm = 0x7ffffffa50, wlSurface = 0x5555581fe0, wlBuffer = 0x55555820a0, ctx_image = 0x5555581e50, data = 0x7ff6757000, id_surface = 1004, link = {prev = 0x7ffffff980, next = 0x7ffffff900}}
wlCtx_Button_3 = {cmm = 0x7ffffffa50, wlSurface = 0x5555582400, wlBuffer = 0x55555824c0, ctx_image = 0x5555582270, data = 0x7ff674e000, id_surface = 1005, link = {prev = 0x7ffffff9c0, next = 0x7ffffff940}}
wlCtx_Button_4 = {cmm = 0x7ffffffa50, wlSurface = 0x5555582930, wlBuffer = 0x5555582c00, ctx_image = 0x55555827a0, data = 0x7ff6745000, id_surface = 1006, link = {prev = 0x7ffffffa40, next = 0x7ffffff980}}
wlCtx_HomeButton = {cmm = 0x7ffffffa50, wlSurface = 0x55555aa550, wlBuffer = 0x55555aa610, ctx_image = 0x55555aa3c0, data = 0x7ff673c000, id_surface = 1007, link = {prev = 0x7ffffffaa8, next = 0x7ffffffa40}}
wlCtx_WorkSpaceBackGround = {cmm = 0x7ffffffa50, wlSurface = 0x55555819f0, wlBuffer = 0x5555582ed0, ctx_image = 0x5555582cc0, data = 0x7ff7ff8000, id_surface = 2001, link = {prev = 0x7ffffffa00, next = 0x7ffffff9c0}}
launcher_wlCtxList = {prev = 0x7ffffff8c0, next = 0x7ffffff8c0}
ret = 0
hmi_setting = 0x555557aba0
pWlCtxSt = 0x0
i = <optimized out>
(gdb)
```
It looks like the hmi controller never registers itself so the resulting proxy is nullptr.
This is the weston.ini I use:
```
[core]
shell=ivi-shell.so
backend=fbdev-backend.so
#[output]
#name=DP1
#mode=1920x1080
[ivi-shell]
ivi-module=/usr/lib/weston/hmi-controller.so
ivi-shell-user-interface=/usr/libexec/weston-ivi-shell-user-interface
cursor-theme=default
cursor-size=32
base-layer-id=1000
workspace-background-layer-id=2000
workspace-layer-id=3000
application-layer-id=4000
background-image=/usr/share/weston/background.png
background-id=1001
panel-image=/usr/share/weston/panel.png
panel-id=1002
surface-id-offset=10
tiling-image=/usr/share/weston/tiling.png
tiling-id=1003
sidebyside-image=/usr/share/weston/sidebyside.png
sidebyside-id=1004
fullscreen-image=/usr/share/weston/fullscreen.png
fullscreen-id=1005
random-image=/usr/share/weston/random.png
random-id=1006
home-image=/usr/share/weston/home.png
home-id=1007
workspace-background-color=0x99000000
workspace-background-id=2001
[keyboard]
keymap_layout=de
```
Any ideas?
Regardshttps://gitlab.freedesktop.org/wayland/weston/-/issues/630Xdg-shell surface doesn't become keyboard active in ivi-shell.2022-09-29T07:51:20ZTomohito EsakiXdg-shell surface doesn't become keyboard active in ivi-shell.In ivi-shell, keyboard is not active for surfaces created with xdg-shell.
I confirmed with hmi-controller and [wayland-ivi-extension](https://github.com/COVESA/wayland-ivi-extension).
I seems that this is because whether the surface was...In ivi-shell, keyboard is not active for surfaces created with xdg-shell.
I confirmed with hmi-controller and [wayland-ivi-extension](https://github.com/COVESA/wayland-ivi-extension).
I seems that this is because whether the surface was created with the ivi-application protocol is checked in activate_binding().
```C
static struct ivi_shell_surface *
get_ivi_shell_surface(struct weston_surface *surface)
{
struct ivi_shell_surface *shsurf;
if (surface->committed != ivi_shell_surface_committed) //<-- here
return NULL;
shsurf = surface->committed_private;
assert(shsurf);
assert(shsurf->surface == surface);
return shsurf;
}
...
static void
activate_binding(struct weston_seat *seat,
struct weston_view *focus_view)
{
struct weston_surface *focus = focus_view->surface;
struct weston_surface *main_surface =
weston_surface_get_main_surface(focus);
if (get_ivi_shell_surface(main_surface) == NULL) //<-- here
return;
weston_seat_set_keyboard_focus(seat, focus);
}
```
Is there a reason for this?https://gitlab.freedesktop.org/wayland/weston/-/issues/846ivi-shell: setting surface visibility to 0 does not prevent the content from ...2023-12-04T14:30:55ZAlexandru N. Oneaivi-shell: setting surface visibility to 0 does not prevent the content from being renderedI am implementing a custom controller for the `ivi-shell` together with a custom protocol. The protocol defines a request that a client can make to the controller to remove an `ivi_surface` from a certain output. The implementation of th...I am implementing a custom controller for the `ivi-shell` together with a custom protocol. The protocol defines a request that a client can make to the controller to remove an `ivi_surface` from a certain output. The implementation of this request on the controller side, for the moment, just sets the visibility of the respective `ivi_layout_surface` to `0` and calls `commit_changes`. I was expecting that after that, the content of the surface is no longer visible on the screen, but it is.
Am I missing something?https://gitlab.freedesktop.org/wayland/weston/-/issues/881app_id and title are set after setting surface id2024-03-26T09:25:11ZWilliam Salmonapp_id and title are set after setting surface id
in my `weston.in` i have something like
```
[core]
shell=ivi-shell.so
require-input=false
modules=ivi-controller.so,systemd-notify.so
idle-time=0
[ivi-shell]
ivi-input-module=ivi-input-controller.so
ivi-id-agent-module=ivi-id-agent.so
...
in my `weston.in` i have something like
```
[core]
shell=ivi-shell.so
require-input=false
modules=ivi-controller.so,systemd-notify.so
idle-time=0
[ivi-shell]
ivi-input-module=ivi-input-controller.so
ivi-id-agent-module=ivi-id-agent.so
[desktop-app]
surface-id=3000
app-id=gtk-app
[desktop-app]
surface-id=2000
app-id=gstreamer-app
[desktop-app-default]
default-surface-id=5000
default-surface-id-max=5100
```
I also have configured the ivi-shell with the wayland-ivi-extentions
With weston version 10 both my gtk and my gstreamer apps have there `app-id` assigned correctly and end up with the right surface-id
With weston version 13 only the gstreamer app is correctly assigned
i have used WAYLAND_DEBUG=1
for the gstreamer app i see
```
ler[537]: [2480892.227] wl_callback@8.done(7)
ler[537]: [2480903.511] -> wl_compositor@4.create_surface(new id wl_surface@3)
ler[537]: [2480903.545] -> wl_compositor@4.create_surface(new id wl_surface@10)
ler[537]: [2480903.557] -> wl_subcompositor@5.get_subsurface(new id wl_subsurf>
ler[537]: [2480903.565] -> wl_subsurface@11.set_desync()
ler[537]: [2480903.574] -> wp_viewporter@6.get_viewport(new id wp_viewport@12,>
ler[537]: [2480903.583] -> wp_viewporter@6.get_viewport(new id wp_viewport@13,>
ler[537]: [2480903.589] -> wl_compositor@4.create_region(new id wl_region@14)
ler[537]: [2480903.594] -> wl_surface@10.set_input_region(wl_region@14)
ler[537]: [2480903.600] -> wl_region@14.destroy()
ler[537]: [2480903.607] -> xdg_wm_base@9.get_xdg_surface(new id xdg_surface@15>
ler[537]: [2480903.614] -> xdg_surface@15.get_toplevel(new id xdg_toplevel@16)
ler[537]: [2480903.621] -> xdg_toplevel@16.set_app_id("camera-controller")
ler[537]: [2480903.627] -> xdg_toplevel@16.unset_fullscreen()
ler[537]: [2480903.632] -> wl_surface@3.commit()
ler[537]: [2480904.048] wl_display@1.delete_id(14)
ler[537]: [2480904.058] xdg_toplevel@16.configure(0, 0, array[0])
ler[537]: [2480904.064] xdg_surface@15.configure(8)
ler[537]: [2480904.069] -> xdg_surface@15.ack_configure(8)
ler[537]: [2480904.108] ivi_wm@6.surface_created(2000)
```
for the gtk app i see
```
Feb 27 18:18:16 localhost test-workload[531]: [ 215386.522] wl_seat@13.name("default")
Feb 27 18:18:16 localhost test-workload[531]: [ 215386.530] wl_callback@17.done(2)
Feb 27 18:18:16 localhost test-workload[531]: [ 215386.538] -> wl_registry@2.bind(20, "xdg_wm_base", 5, new id [unknown]@17)
Feb 27 18:18:16 localhost test-workload[531]: [ 215546.590] -> wl_compositor@4.create_surface(new id wl_surface@7)
Feb 27 18:18:16 localhost test-workload[531]: [ 215546.752] -> xdg_wm_base@17.get_xdg_surface(new id xdg_surface@18, wl_surface@7)
Feb 27 18:18:16 localhost test-workload[531]: [ 215546.774] -> xdg_surface@18.get_toplevel(new id xdg_toplevel@19)
Feb 27 18:18:16 localhost test-workload[531]: [ 215546.801] -> xdg_toplevel@19.set_parent(nil)
Feb 27 18:18:16 localhost test-workload[531]: [ 215546.812] -> xdg_toplevel@19.set_title("test-workload")
Feb 27 18:18:16 localhost test-workload[531]: [ 215546.820] -> xdg_toplevel@19.set_app_id("test-workload")
Feb 27 18:18:16 localhost test-workload[531]: [ 215546.826] -> wl_surface@7.commit()
Feb 27 18:18:16 localhost test-workload[531]: [ 215547.513] -> xdg_toplevel@19.set_min_size(568, 46)
Feb 27 18:18:16 localhost test-workload[531]: [ 215547.537] -> xdg_toplevel@19.set_max_size(0, 0)
Feb 27 18:18:16 localhost test-workload[531]: [ 215547.622] wl_keyboard@12.repeat_info(40, 400)
Feb 27 18:18:16 localhost test-workload[531]: [ 215547.632] wl_keyboard@12.keymap(1, fd 8, 64703)
Feb 27 18:18:16 localhost test-workload[531]: [ 215550.683] xdg_toplevel@19.wm_capabilities(array[12])
Feb 27 18:18:16 localhost test-workload[531]: [ 215550.709] xdg_toplevel@19.configure(0, 0, array[0])
Feb 27 18:18:16 localhost test-workload[531]: [ 215550.715] xdg_surface@18.configure(3)
Feb 27 18:18:16 localhost test-workload[531]: [ 215550.730] -> xdg_surface@18.ack_configure(3)
Feb 27 18:18:16 localhost test-workload[531]: [ 215565.491] -> wl_shm@9.create_pool(new id wl_shm_pool@20, fd 9, 1228800)
Feb 27 18:18:16 localhost test-workload[531]: [ 215565.531] -> wl_shm_pool@20.create_buffer(new id wl_buffer@21, 0, 640, 480, 2560, 0)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.794] -> wl_surface@7.attach(wl_buffer@21, 0, 0)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.821] -> wl_surface@7.set_buffer_scale(1)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.828] -> wl_surface@7.damage(0, 0, 640, 480)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.834] -> xdg_toplevel@19.set_min_size(568, 46)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.838] -> xdg_toplevel@19.set_max_size(0, 0)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.843] -> xdg_surface@18.set_window_geometry(0, 0, 640, 480)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.848] -> wl_compositor@4.create_region(new id wl_region@22)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.853] -> wl_region@22.add(0, 0, 640, 480)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.858] -> wl_surface@7.set_opaque_region(wl_region@22)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.863] -> wl_region@22.destroy()
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.867] -> wl_surface@7.set_input_region(nil)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.882] -> wl_surface@7.frame(new id wl_callback@23)
Feb 27 18:18:16 localhost test-workload[531]: [ 215569.888] -> wl_surface@7.commit()
```
I added some extra debug to the ivi-extentions to show that at the point that weston is assigning surface numbers it thinks the gtk app has not set a id or title
```
[18:18:16.939] - app id not set
[18:18:16.939] - app title not set
[18:18:16.939] ivi-id-agent: No configuration for application adding to default layer
[18:18:16.939] id_surface is not created yet
[18:18:18.567] - app id: gstreamer-app
[18:18:18.567] - app title not set
[18:18:18.567] id_surface is not created yet
```
Is this because gtk3 is splitting creating the surface and setting the title over "wl_callback@17.done(2) and xdg_surface@18.configure(3)" but gstreamer does them both in "wl_callback@8.done(7)" ?
Its odd that weston-10 worked and weston-13 no longer does..
My gtk app is pretty close to hello world btw