• I
    V4L/DVB (6717): ivtv: Initial merge of video48 yuv handling into the IVTV_IOC_DMA_FRAME framework · 77aded6b
    Ian Armstrong 提交于
    Previously, all yuv data written to /dev/video48 had only basic support with
    no double buffering to avoid display tearing.
    
    With this patch, yuv frames written to video48 are now handled by the existing
    IVTV_IOC_DMA_FRAME framework. As such, the frames are hardware buffered to
    avoid tearing, and honour scaling mode & field order options. Unlike the
    proprietary IVTV_IOC_DMA_FRAME ioctl, all parameters are controlled by the
    V4L2 API.
    
    Due to mpeg & yuv output restrictions being different, their V4L2 output
    controls have been separated. To control the yuv output, the V4L2 calls must
    be done via video48.
    
    If the ivtvfb module is loaded, there will be one side effect to this merge.
    The yuv output window will be constrained to the visible framebuffer area. In
    the event that a virtual framebuffer size is being used, the limit to the
    output size will be the virtual dimensions, but only the portion that falls
    within the currently visible area of the framebuffer will be shown.
    
    Like the IVTV_IOC_DMA_FRAME ioctl, the supplied frames must be padded to 720
    pixels wide. However the height must only be padded up the nearest multiple
    of 32. This would mean an image of 102 lines must be padded to 128. As long
    as the true source image size is given, the padding will not be visible in
    the final output.
    Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
    Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
    77aded6b
ivtv-driver.c 42.4 KB