Thanks Ander for your education. 1. I debugged Weston with simple-efl and found that wl_buffer isn't WL_BUFFER_RELEASE by weston_surface_attach (though there is weston_buffer_reference). It's good.
2. My failure case is in webkit which creates an internal wayland server, I will try more to see its difference from Weston. In webkit, my case failed with backtrace: #0 0xb77a5424 in __kernel_vsyscall () #1 0xb5724b9b in poll () from /lib/libc.so.6 #2 0xb47f8074 in wl_display_dispatch_queue () from /lib/libwayland-client.so.0 #3 0xb4d18c21 in dri2_swap_buffers () from /lib/libEGL.so.1 #4 0xb4d0c3b5 in eglSwapBuffers () from /lib/libEGL.so.1 #5 0xb658e157 in WebCore::EGLWindowSurface::swapBuffers (this=0x8d5bb60) at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebCore/platform/graphics/surfaces/egl/EGLWaylandSurface.cpp:95 #6 0xb6dd601e in swapPlatformSurfaces (this=0x8bd7c00) at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebCore/platform/graphics/efl/tizen/AcceleratedPlatformLayer.cpp:320 #7 WebCore::AcceleratedPlatformLayer::swapPlatformSurfaces (this=0x8bd7c00) at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebCore/platform/graphics/efl/tizen/AcceleratedPlatformLayer.cpp:313 #8 0xb59b179e in WebCore::WebGraphicsLayer::swapPlatformSurfaces (this=0x9304b18) at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebKit2/WebProcess/WebPage/LayerTreeCoordinator/WebGraphicsLayer.cpp:884 #9 0xb59ab733 in WebKit::LayerTreeCoordinator::flushPendingLayerChanges (this=this@entry=0x88ab4e8) at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebKit2/WebProcess/WebPage/LayerTreeCoordinator/LayerTreeCoordinator.cpp:312 #10 0xb59aecb1 in flushPendingLayerChanges (this=0x88ab4e8) at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebKit2/WebProcess/WebPage/LayerTreeCoordinator/LayerTreeCoordinator.cpp:286 #11 performScheduledLayerFlush (this=0x88ab4e8) > -----Original Message----- > From: Ander Conselvan de Oliveira [mailto:conselv...@gmail.com] > Sent: Wednesday, September 04, 2013 5:12 PM > To: Zhao, Halley > Cc: wayland-devel@lists.freedesktop.org; Kondapally, Kalyan; Kristensen, > Kristian H; Beauchesne, Gwenole > Subject: Re: how to deal with the last video frame buffer (wl_buffer)? > > On 09/03/2013 03:26 AM, Zhao, Halley wrote: > > More questions: > > > > 1.I searched inside mesa code, there is wl_display_create_queue(), > but > > no wl_event_queue_destroy(), is it a bug? > > That seems to be missing from the clean up path. However, before > destroying the queue, we need to make sure there is no proxy that uses > that queue, otherwise a crash would happen if the proxy received an > event after the queue was destroyed. > > > 2.I searched inside Weston code, there is no wl_buffer_send_release(), > > is there other way to send the event of WL_BUFFER_RELEASE? > > Look at weston_buffer_reference() in compositor.c. That function uses > wl_resource_queue_event() to add the event to the connection buffer > without flushing it and causing a context switch(). > > > 3.What's the design philosophy of wl_buffer_send_release? > > > > a)I had thought the event is sent when server doesn't use wl_buffer > > any longer > > That is correct. > > > i.when a new wl_buffer is committed (release previous committed > > buffer) > > > > ii.When the corresponding wl_surface is destroying (release the > > committed buffer) > > > > iii.When a second wl_buffer is attached before commit (release the > > previous attached one) > > For the case of SHM buffers, the release event is sent after a texture > upload, because at that moment a copy of the buffer is created. However, > EGL buffers aren't copied so the release event is only sent when the > buffer is replaced by a new one. > > > b)However, the above assumption doesn't work well with mesa. With > > nested server in webkit. > > > > Seems mesa requires wayland server send wl_buffer_send_release upon > attach. > > Could you elaborate on that? > > > Cheers, > Ander _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel