Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 12月, 2008 1 次提交
  3. 18 10月, 2008 1 次提交
  5. 13 10月, 2008 1 次提交
  7. 12 10月, 2008 1 次提交
  9. 20 7月, 2008 1 次提交
  11. 05 6月, 2008 1 次提交
  13. 14 5月, 2008 1 次提交
  15. 30 4月, 2008 1 次提交
  17. 25 4月, 2008 2 次提交
  19. 26 1月, 2008 2 次提交
    • 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
    • I
      V4L/DVB (6712): ivtv: ivtv yuv stream handling change · c240ad00
      由 Ian Armstrong 提交于 
      Currently the yuv output stream buffer is divided into blocks whose size
depend on the broadcast standard selected during the driver init phase.
However, the standard can be changed after the init phase. This effectively
breaks the yuv output stream handler, since it relies on the different yuv
planes being block aligned.

This patch changes the setup, so that the block size is always the same. The
decoder dma function has been modified to cope with the fact that the second
yuv plane may no longer be block aligned. The start of the yuv frame must
still be at the beginning of a block, so the stream write function has also
been modified to ensure this is always true.

Also, the stream write function will now initiate a yuv dma transfer as soon
as a full frame is ready. It will not wait until the current write request
has completed, or the stream buffer becomes full.
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>
      c240ad00
  21. 22 10月, 2007 3 次提交
  23. 10 10月, 2007 12 次提交
  25. 30 9月, 2007 1 次提交
  27. 15 9月, 2007 1 次提交
  29. 31 7月, 2007 2 次提交
  31. 21 7月, 2007 2 次提交
  33. 19 7月, 2007 1 次提交
  35. 08 6月, 2007 1 次提交
  37. 09 5月, 2007 1 次提交
  39. 28 4月, 2007 3 次提交