Re: [PATCH weston] autotools: Fix AC_PATH_PROG call
On Mon, Sep 2, 2013 at 5:21 AM, Stefan Schmidt wrote:
> Hello.
>
>
> On 08/24/2013 07:36 PM, Quentin Glidic wrote:
>>
>> From: Quentin Glidic
>>
>> Signed-off-by: Quentin Glidic
>> ---
>>
>> Sorry for the noise, this one is the good fix
>>
>> configure.ac | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 156237f..4be0e4a 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -424,8 +424,10 @@ if test "x$have_lcms" = xyes; then
>> fi
>> AM_CONDITIONAL(HAVE_LCMS, [test "x$have_lcms" = xyes])
>>
>> -AC_PATH_PROG([wayland_scanner], [wayland-scanner],
>> -[AC_MSG_ERROR("wayland-scanner is needed to compile
>> weston")])
>> +AC_PATH_PROG([wayland_scanner], [wayland-scanner])
>> +if test x$wayland_scanner = x; then
>> + AC_MSG_ERROR([wayland-scanner is needed to compile weston])
>> +fi
>>
>> AC_CONFIG_FILES([Makefile
>> shared/Makefile
>
>
> This patch fixes the problem for me. Now able again to use latest wayland
> and weston. Thanks a lot.
Yup, I saw the discussion go by - thanks for confirming.
Kristian
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: how to deal with the last video frame buffer (wl_buffer)?
More questions: 1. I searched inside mesa code, there is wl_display_create_queue(), but no wl_event_queue_destroy(), is it a bug? 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? 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 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) 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. From: wayland-devel-bounces+halley.zhao=intel@lists.freedesktop.org [mailto:wayland-devel-bounces+halley.zhao=intel@lists.freedesktop.org] On Behalf Of Zhao, Halley Sent: Monday, September 02, 2013 10:12 AM To: wayland-devel@lists.freedesktop.org Subject: how to deal with the last video frame buffer (wl_buffer)? When a wl_buffer (of video frame) is committed to wayland server, this buffer keeps being used by server until a second buffer is committed. It means a wl_buffer isn't ready to destroy in frame callback, but wl_buffer_send_release(). And the buffer (in media pipeline) should also be retained for some time after it is committed to server side. This expose additional questions for the last video buffer. 1. Should we commit empty wl_buffer upon stopping of video playback? a) Does Weston support it ? (use empty buffer to replace previous committed buffer) b) If yes, is there any example to use it? 2. When to destroy the event queue if it is used? Usually media creates an event queue, wl_buffer is also set to this queue. It comes a question that when to destroy this event queue, since wl_buffer_send_release() (on this event queue) happens after media stop. a) Should we have an event like wl_surface_send_release() to give the chance to destroy this event queue? b) If not, then we have to destroy this event queue upon wl_buffer_send_release of the last buffer. i. Is it ok to destroy the event queue in the callback function of the event in this queue? ii. It creates complexity to sycn on the last buffer release event in media. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] compositor-drm: Add hardware accelerated capture of screen using libva
On Fri, Aug 30, 2013 at 06:25:30PM +0300, Ander Conselvan de Oliveira wrote: > On 08/30/2013 07:37 AM, Kristian Høgsberg wrote: > >On Fri, Aug 23, 2013 at 05:15:48PM +0300, Ander Conselvan de Oliveira wrote: > >>From: Ander Conselvan de Oliveira > >> > >>This patch adds a feature to the DRM backend that uses libva for > >>encoding the screen contents in H.264. Screen recording can be > >>activated by pressing mod-shift-space q. A file named capture.h264 > >>will be created in the current directory, which can be muxed into > >>an MP4 file with gstreamer using > > > >I tried it out and it worked like a charm. I have IvyBridge here and > >I didn't get the hang you mention. It's very cool how it encodes h264 > >direectly and doesn't seem to load the system very when doing so. > >Newer Intel GPUs have a dedicated hw video encoder so it shouldn't > >take away CPU or GPU resources from whatever weston and clients are > >doing. They're still competing for memory bandwidth of course. I > >wonder what the impact of capturing a GPU intensive app (like a modern > >game, potentially under xwayland) might be. > > > >Anyway, I feel like we're better off merging this sooner rather than > >later. The feature is basically working and for all we know the > >crasher could be SandyBridge specific. Do you see a problem in > >committing this now and fixing the rest of the issues incrementally? > > Yeah, let's do that. Though, I'm not entirely sure if this plugs > with the drm backend in an optimal way. The frame signal is sent > just before a flip, and it is in that moment that the front buffer > is read and sent to be encoded. I guess it would make more sense to > do that just after a flip. But then we wouldn't use the frame signal > at all, and instead hook things up with the page flip handler. If this causes noticable stalls then we just need to teach the kernel that different gpu engines are allowed to concurrently read fromt the same buffer object. Atm the starting of the libva encoding will switch the buffer object to the video ring, but the subsequent pageflip will then switch it back to blitter/render rings. So you'll stall for the encoding to finish right now. That ignores that libva itself isn't too great with properly queueing up rendering :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] compositor-drm: Add hardware accelerated capture of screen using libva
On Fri, Aug 23, 2013 at 05:15:48PM +0300, Ander Conselvan de Oliveira wrote: > From: Ander Conselvan de Oliveira > > This patch adds a feature to the DRM backend that uses libva for > encoding the screen contents in H.264. Screen recording can be > activated by pressing mod-shift-space q. A file named capture.h264 > will be created in the current directory, which can be muxed into > an MP4 file with gstreamer using > > gst-launch filesrc location=capture.h264 ! h264parse ! mp4mux ! \ >filesink location=file.mp4 > > This is limitted to the DRM compositor in order to avoid a copy when > submitting the front buffer to libva. The code in vaapi-recorder.c > takes a dma_buf fd referencing it, does a colorspace conversion using > the video post processing pipeline and then uses that as input to the > encoder. > > I'm sending this now so I get comments, but this is not ready for > prime time yet. I have a somewhat consistent GPU hang when using > i915 with SandyBridge. Sometimes a page flip never completes. If you > want to try this anyway and your system get stuck, you might need to > run the following: > > # echo 1 > /sys/kernel/debug/dri/0/i915_wedged Does this still happen on latest drm-intel-nightly branches? In the past few kernel releases we've massively improved hangcheck detection, especially interactions with pageflips. Although just recently there's been a patch to fix a deadlock (re)introduced in 3.8: https://patchwork.kernel.org/patch/2852865/ Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] autotools: Fix AC_PATH_PROG call
Hello.
On 08/24/2013 07:36 PM, Quentin Glidic wrote:
From: Quentin Glidic
Signed-off-by: Quentin Glidic
---
Sorry for the noise, this one is the good fix
configure.ac | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 156237f..4be0e4a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -424,8 +424,10 @@ if test "x$have_lcms" = xyes; then
fi
AM_CONDITIONAL(HAVE_LCMS, [test "x$have_lcms" = xyes])
-AC_PATH_PROG([wayland_scanner], [wayland-scanner],
-[AC_MSG_ERROR("wayland-scanner is needed to compile
weston")])
+AC_PATH_PROG([wayland_scanner], [wayland-scanner])
+if test x$wayland_scanner = x; then
+ AC_MSG_ERROR([wayland-scanner is needed to compile weston])
+fi
AC_CONFIG_FILES([Makefile
shared/Makefile
This patch fixes the problem for me. Now able again to use latest
wayland and weston. Thanks a lot.
regards
Stefan Schmidt
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
