[RFC] compositor-drm: Add hardware accelerated capture of screen using libva

[Ander Conselvan de Oliveira]

On 09/02/2013 05:57 PM, Daniel Vetter wrote:
> On Fri, Aug 23, 2013 at 05:15:48PM +0300, Ander Conselvan de Oliveira wrote:
>> From: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira at intel.com>
>>
>> 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/

I couldn't reproduce the problem with drm-intel-nightly of a few nights 
ago. Bisection indicated an rc6 related change [1] fixed(?) the problem.


[1] 
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next&id=351aa5666d02062b52329bcfe4bcf9d1f882fba9


Ander