Archived
14
0
Fork 0
Commit graph

3 commits

Author SHA1 Message Date
Michael H. Schimek
67f1570a06 V4L/DVB (3178): bttv VBI fixes
- V4L2_(G|S|TRY)_FMT returned incorrect VBI start lines for PAL-M,
NTSC-JP, and PAL-60. They also returned an inaccurate VBI offset.
- V4L2_(G|S)_FMT and V4L2_TRY_FMT disagreed about the start of VBI
capturing in PAL and SECAM second field. Note the start line fixes
may break applications using VIDIOCSVBIFMT because this ioctl fails
when the driver does not support exactly the requested parameters.
- V4L2_TRY_FMT did not clear the reserved field in struct
v4l2_vbi_format.
- V4L2_(S|TRY)_FMT did not expect very large or small VBI start or
count values, returning wrong (but safe) counts due to an overflow.
- VIDIOCGVBIFMT confused V4L and V4L2 VBI flags. However this had no
effect because the flags have the same value and bttv never sets
them.
- In v4l_compat_translate_ioctl() the VIDIOC(G|S)VBIFMT code did not
expect V4L2 drivers supporting VBI formats besides V4L2_PIX_FMT_GREY.

Signed-off-by: Michael H. Schimek <mschimek@gmx.at>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
2006-01-09 15:25:27 -02:00
Mauro Carvalho Chehab
24a70fdce8 [PATCH] v4l: BTTV updates and card additions
- Remove $Id CVS logs for V4L files
- Added DVICO FusionHDTV 5 Lite card.
- Added Acorp Y878F.
- CodingStyle fixes.
- Added tuner_addr to bttv cards structure.
- linux/version.h replaced by linux/utsname.h on bttvp.h
- kernel module for acquiring RDS data from a SAA6588.
- Allow multiple open() and reading calls to /dev/radio on bttv-driver.c
- added i2c address for lgdt330x.

Signed-off-by: Hans J. Koch <koch@hjk-az.de>
Signed-off-by: Michael Krufky <mkrufky@m1k.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 13:57:49 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00