Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 25 4月, 2008 1 次提交
  3. 02 4月, 2008 4 次提交
  5. 20 3月, 2008 1 次提交
  7. 18 2月, 2008 2 次提交
  9. 26 1月, 2008 14 次提交
  11. 07 1月, 2008 1 次提交
  13. 12 12月, 2007 2 次提交
  15. 05 11月, 2007 2 次提交
    • T
      V4L/DVB (6392): bttv: Update initial image size when set via V4L1 VIDIOCMCAPTURE · a8ab68bf
      由 Trent Piepho 提交于 
      The V4L1 spec says that the image size should be with with VIDIOCSWIN before
requesting buffers with VIDIOCGMBUF and capturing into them with
VIDIOCMCAPTURE.

But it seems that many apps don't do this.  They set the size using the fields
in the VIDIOCMCAPTURE ioctl.  The driver doesn't know what size to capture
until it actually starts to capture.  In particular, it doesn't know what size
to capture until it has already mmap the captured buffers.  Which is quite
stupid.  Why V4L1 has size and format fields for VIDIOCMCAPTURE I have no idea.

Many drivers don't support this, including those using v4l1-compat.

The bttv does, which is probably the only reason such broken software is so
prevalent.

But, the driver doesn't adjust its idea of what size is being captured when it
is set this way.  If you try to query the driver's current setting with
v4l2-ctl, it won't be correct.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      a8ab68bf
    • T
      V4L/DVB (6391): bttv: SPICT ioctl doesn't work with vlc · 35378434
      由 Trent Piepho 提交于 
      The bttv driver instists that the depth specified in the call to VIDIOCSPICT
match the pixel format specified in the same call.

vlc doesn't set the depth field, which makes the SPICT ioctl always fail.

The V4L1 standard is not clear on how most operation are supposed to work, and
this is no exception.  The depth field would appear to be entirely redundant,
as the pixel format specifies a specific depth.  It could be that this field
was only meant for output from the *G*PICT ioctl and should be ignored in
*S*PICT.  This is in fact what the v4l1-compat wrapper does.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      35378434
  17. 22 10月, 2007 1 次提交
  19. 10 10月, 2007 4 次提交
  21. 19 7月, 2007 2 次提交
  23. 04 7月, 2007 1 次提交
    • T
      V4L/DVB (5808): Bttv: fix v4l1 breaking the driver · 333408f2
      由 Trent Piepho 提交于 
      If one uses a V4L *one* application, such as vlc or mplayer's v4l driver, as
the first user after the driver is loaded, the driver wedges itself and will
never capture properly.  Even if one uses a V4L2 application later, it still
won't work.

If one uses a V4L *two* application first, such as tvtime or mplayer's v4l2
driver, then the driver will be ok.  One can then run a V4L1 application, and
it will work.

It turns out the problem is with norm changing and the crop support that was
added in 2.6.21.  The driver defaults to PAL, and keeps the last norm it was
set too across opens.  If one changes the norm via V4L1, the cropping
parameters are not reset like they should be, and they'll remain broken across
device opens.

This patch removes the direct setting of btv->tvnorm in the V4L1 ioctl
VIDIOCSCHAN handler.  The norm is set via the existing call to set_input(),
which calls set_tvnorm(), which will reset the cropping values now that it is
able to detect the norm change.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      333408f2
  25. 28 4月, 2007 1 次提交
  27. 21 2月, 2007 2 次提交
    • M
      V4L/DVB (5156): Fix: dma free is being called with wrong arguments · feaba7a9
      由 Michael Schimek 提交于 
      Functions buffer_release() in bttv-driver.c and
vbi_buffer_release() in bttv-vbi.c are ending with:
      bttv_dma_free(&fh->cap,fh->btv,buf);
 
For vbi it seems to be wrong. Both functions should end with:
 
      bttv_dma_free(q,fh->btv,buf);
Thanks to Peter Schlaf <peter.schlaf@web.de> for pointing this.
Signed-off-by: NMichael H. Schimek <mschimek@gmx.at>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      feaba7a9
    • M
      V4L/DVB (5077): Bttv cropping support · e5bd0260
      由 Michael Schimek 提交于 
      Adds the missing VIDIOC_CROPCAP, G_CROP and S_CROP ioctls, permitting 
applications to capture or overlay a subsection of the picture or to 
extend the capture window beyond active video, into the VBI area and the 
horizontal blanking. VBI capturing can start and end on any line, 
including the picture area, and apps can capture different lines of each 
field and single fields.
For compatibility with existing applications, the open() function
resets the cropping and VBI capturing parameters and a VIDIOC_S_CROP
call is necessary to actually enable cropping. 
Regrettably in PAL-M, PAL-N, PAL-Nc and NTSC-JP mode the maximum image 
width will increase from 640 and 768 to 747 and 923 pixels respectively.
Like the VBI changes however, this should only affect applications which 
depend on former driver limitations, such as never getting more than 640 
pixels regardless of the requested width. 
Also, new freedoms require additional checks for conflicts and some 
applications may not expect an EBUSY error from the VIDIOC_QBUF and 
VIDIOCMCAPTURE ioctls. These errors should be rare though.
So far, the patch has been tested on a UP machine with a bt878 in PAL-
BGHI and NTSC-M mode using xawtv, tvtime, mplayer/mencoder, zapping/
libzvbi and these tools: http://zapping.sf.net/bttv-crop-test.tar.bz2
I'd be grateful about comments or bug reports.
Signed-off-by: NMichael H. Schimek <mschimek@gmx.at>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      e5bd0260
  29. 13 2月, 2007 1 次提交
  31. 28 12月, 2006 1 次提交