[PATCH] tm6000: Prevent Kernel Oops changing channel when stream is still on.
do a streamoff before setting standard to prevent kernel oops by irq_callback if changing of channel is done while streaming is still on-going. Signed-off-by: Bee Hock Goh beeh...@gmail.com diff --git a/drivers/staging/tm6000/tm6000-video.c b/drivers/staging/tm6000/tm6000-video.c index c53de47..32f625d 100644 --- a/drivers/staging/tm6000/tm6000-video.c +++ b/drivers/staging/tm6000/tm6000-video.c @@ -1081,8 +1086,8 @@ static int vidioc_s_std (struct file *file, void *priv, v4l2_std_id *norm) struct tm6000_fh *fh=priv; struct tm6000_core *dev = fh-dev; + vidioc_streamoff(file, priv, V4L2_BUF_TYPE_VIDEO_CAPTURE); rc=tm6000_set_standard (dev, norm); - fh-width = dev-width; fh-height = dev-height; -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] TI WL1273 FM Radio Driver v2.
On Friday 30 April 2010 14:59:45 Matti J. Aaltonen wrote: Hello. I've implemented most of the changes proposed on the previous review round. There are some things to be done in the RDS handling... I've left the region handling as it was because neither of the chip's regions cover the complete range. Japan is from 76 - 90MHz and Europe/US is 87.5 to 108 MHz. Some of the private IOCTL were not necessary because corresponding standardized controls already exist. And for setting the audio mode to digital or analog I created an ALSA control because that's an audio thing anyway. A couple of private IOCTLs are still there: 1. WL1273_CID_FM_REGION for setting the region. This may not be a good candidate for standardization as the region control shouldn't exist in the kernel in general... Is this region relevant for receive, transmit or both? 2. WL1273_CID_FM_SEEK_SPACING: defines what resolution is used when scanning automatically for stations (50KHz, 100KHz or 200KHz). This could be useful in genaral. Could this be a field in the v4l2_hw_freq_seek struct? I think this belongs in v4l2_hw_freq_seek. 3. WL1273_CID_FM_RDS_CTRL for turning on and off the RDS reception / transmission. To me this seems like a useful standard control... This already exists. You can enable/disable RDS by setting the V4L2_TUNER_SUB_RDS subchannel bit when calling S_TUNER or S_MODULATOR. 4. WL1273_CID_SEARCH_LVL for setting the threshold level when detecting radio channels when doing automatic scan. This could be useful for fine tuning because automatic scanning seems to be kind of problematic... This could also be a field in the v4l2_hw_freq_seek struct? This too seems reasonable to add to v4l2_hw_freq_seek. Although what sort of unit this level would have might be tricky. What is the unit for your hardware? 5. WL1273_CID_FM_RADIO_MODE: Now the radio has the following modes: off, suspend, rx and tx. It probably would be better to separate the powering state (off, on, suspend) from the FM radio state (rx, tx)... Could the VIDIOC_S_MODULATOR and VIDIOC_S_TUNER IOCTLs be used for setting the TX/RX mode? Not entirely sure what you want to achieve here. I gather that the radio is either receiving, transmitting or off? So it can't receive and transmit at the same time, right? I would expect in that case that calling S_TUNER or S_MODULATOR would switch it to either receive or transmit mode. S_HW_FREQ_SEEK would of course also switch it to receive mode. There isn't anything to turn off the radio at the moment. Perhaps you can just automatically turn it off if nobody has the radio device or alsa device open? Now there already exits a class for fm transmitters: V4L2_CTRL_CLASS_FM_TX. Should a corresponding class be created for FM tuners? I'm not sure that we need any. I think the only control that we need is to set the region, and I think that is more appropriate as a private (?) user control since it is definitely something that users should be easily able to change. This probably should be discussed a bit more. Regards, Hans B.R. Matti A. Matti J. Aaltonen (3): MFD: WL1273 FM Radio: MFD driver for the FM radio. WL1273 FM Radio: Digital audio codec. V4L2: WL1273 FM Radio: Controls for the FM radio. drivers/media/radio/Kconfig| 15 + drivers/media/radio/Makefile |1 + drivers/media/radio/radio-wl1273.c | 1849 drivers/mfd/Kconfig|6 + drivers/mfd/Makefile |2 + drivers/mfd/wl1273-core.c | 609 include/linux/mfd/wl1273-core.h| 323 +++ sound/soc/codecs/Kconfig |6 + sound/soc/codecs/Makefile |2 + sound/soc/codecs/wl1273.c | 587 sound/soc/codecs/wl1273.h | 40 + 11 files changed, 3440 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/radio-wl1273.c create mode 100644 drivers/mfd/wl1273-core.c create mode 100644 include/linux/mfd/wl1273-core.h create mode 100644 sound/soc/codecs/wl1273.c create mode 100644 sound/soc/codecs/wl1273.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Pushdown bkl from v4l ioctls
On Thursday 29 April 2010 09:10:42 Laurent Pinchart wrote: Hi Hans, On Thursday 29 April 2010 08:44:29 Hans Verkuil wrote: On Thursday 29 April 2010 05:42:39 Frederic Weisbecker wrote: Hi, Linus suggested to rename struct v4l2_file_operations::ioctl into bkl_ioctl to eventually get something greppable and make its background explicit. While at it I thought it could be a good idea to just pushdown the bkl to every v4l drivers that have an .ioctl, so that we actually remove struct v4l2_file_operations::ioctl for good. It passed make allyesconfig on sparc. Please tell me what you think. I much prefer to keep the bkl inside the v4l2 core. One reason is that I think that we can replace the bkl in the core with a mutex. Still not ideal of course, so the next step will be to implement proper locking in each driver. For this some additional v4l infrastructure work needs to be done. I couldn't proceed with that until the v4l events API patches went in, and that happened yesterday. So from my point of view the timeline is this: 1) I do the infrastructure work this weekend. This will make it much easier to convert drivers to do proper locking. And it will also simplify v4l2_priority handling, so I'm killing two birds with one stone :-) 2) Wait until Arnd's patch gets merged that pushes the bkl down to v4l2-dev.c 3) Investigate what needs to be done to replace the bkl with a v4l2-dev.c global mutex. Those drivers that call the bkl themselves should probably be converted to do proper locking, but there are only about 14 drivers that do this. The other 60 or so drivers should work fine if a v4l2-dev global lock is used. At this point the bkl is effectively removed from the v4l subsystem. 4) Work on the remaining 60 drivers to do proper locking and get rid of the v4l2-dev global lock. This is probably less work than it sounds. Since your patch moves everything down to the driver level it will actually make this work harder rather than easier. And it touches almost all drivers as well. Every driver will need to be carefully checked to make sure the BKL can be replaced by a v4l2-dev global mutex. Why would it be more difficult to do so if the BKL is pushed down to the drivers ? The main reason is really that pushing the bkl into the v4l core makes it easier to review. I noticed for example that this patch series forgot to change the video_ioctl2 call in ivtv-ioctl.c to video_ioctl2_unlocked. And there may be other places as well that were missed. Having so many drivers changed also means a lot of careful reviewing. But I will not block this change. However, I do think it would be better to create a video_ioctl2_bkl rather than add a video_ioctl2_unlocked. The current video_ioctl2 function *is* already unlocked. So you are subtle changing the behavior of video_ioctl2. Not a good idea IMHO. And yes, grepping for video_ioctl2_bkl is also easy to do and makes it more obvious that the BKL is used in drivers that call this. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Pushdown bkl from v4l ioctls
On Saturday 01 May 2010 11:55:37 Hans Verkuil wrote: However, I do think it would be better to create a video_ioctl2_bkl rather than add a video_ioctl2_unlocked. The current video_ioctl2 function is already unlocked. So you are subtle changing the behavior of video_ioctl2. Not a good idea IMHO. And yes, grepping for video_ioctl2_bkl is also easy to do and makes it more obvious that the BKL is used in drivers that call this. Yes, that makes sense. It also allows working towards a goal of 'removing video_ioctl2_bkl', which is easier to understand than 'converting video_ioctl2 users to video_ioctl2_unlocked and later renaming that'. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Pushdown bkl from v4l ioctls
I much prefer to keep the bkl inside the v4l2 core. One reason is that I think that we can replace the bkl in the core with a mutex. Still not ideal of course, so the next step will be to implement proper locking in I did look at this a long time ago - it doesn't really work becaue the mutex you propose then has to be dropped and taken in the sleeping parts of each ioctl to avoid app problems and in some cases threaded apps deadlocking. I think Arnd is right on his approach to this, having tried the other way. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.35]
The following changes since commit d3be2fab3a10b6c798a5f9970146d166d3345c37: Jean-François Moine (1): V4L/DVB: gspca - zc3xx: Fix the gamma calculation from the contrast are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc Three fixes and one simplification. The prio changes are trivial but prepare the way for moving prio handling into the core framework. Hans Verkuil (4): Documentation: fix small error in the ENUMINPUT doc. bttv: remove bogus prio check in g_frequency. v4l2-common: simplify prio utility functions tvp7002: fix query_dv_preset. Documentation/DocBook/v4l/vidioc-enuminput.xml |2 +- drivers/media/video/bt8xx/bttv-driver.c| 23 +-- drivers/media/video/cpia2/cpia2_v4l.c |4 ++-- drivers/media/video/cx18/cx18-controls.c |2 +- drivers/media/video/cx18/cx18-fileops.c|2 +- drivers/media/video/cx18/cx18-ioctl.c | 16 drivers/media/video/davinci/vpfe_capture.c |2 +- drivers/media/video/davinci/vpif_capture.c |8 drivers/media/video/davinci/vpif_display.c |4 ++-- drivers/media/video/ivtv/ivtv-fileops.c|2 +- drivers/media/video/ivtv/ivtv-ioctl.c |2 +- drivers/media/video/pvrusb2/pvrusb2-v4l2.c |6 +++--- drivers/media/video/saa7134/saa7134-video.c| 14 +++--- drivers/media/video/tvp7002.c | 13 + drivers/media/video/v4l2-common.c | 22 +- drivers/staging/cx25821/cx25821-audups11.c |6 +++--- drivers/staging/cx25821/cx25821-video.c| 10 +- drivers/staging/cx25821/cx25821-video0.c |6 +++--- drivers/staging/cx25821/cx25821-video1.c |6 +++--- drivers/staging/cx25821/cx25821-video2.c |6 +++--- drivers/staging/cx25821/cx25821-video3.c |6 +++--- drivers/staging/cx25821/cx25821-video4.c |6 +++--- drivers/staging/cx25821/cx25821-video5.c |6 +++--- drivers/staging/cx25821/cx25821-video6.c |6 +++--- drivers/staging/cx25821/cx25821-video7.c |6 +++--- drivers/staging/cx25821/cx25821-videoioctl.c |6 +++--- drivers/staging/cx25821/cx25821-vidups10.c |6 +++--- drivers/staging/cx25821/cx25821-vidups9.c |6 +++--- include/media/v4l2-common.h|8 29 files changed, 100 insertions(+), 112 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Technisat SkyStar USB plus
Ubuntu 10.4, standard kernel v4l-dvb sources (just updated) Technisat SkyStar USB plus DVB-S USB device, output from lsusb: Bus 001 Device 011: ID 0b48:3009 TechnoTrend AG Hello, I own a Technisat SkyStar USB plus USB DVB-S device. It's a rebranded Technotrend TT-connect S-2400, but it has a different USB_PID (0x3009 instead of 0x3006). After editing this in dvb-ids.h in the v4l-sources, compiling and installing the drivers and adding the firmware file dvb-usb-tt-s2400-01.fw, the device works fine on Ubuntu 10.4. Please add the device with USB_PID 0x3009 to the v4l-dvb drivers. Greetings Carsten -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Doing a stable v4l-utils release
On Friday 30 April 2010 08:43:23 Hans Verkuil wrote: On Wednesday 28 April 2010 08:22:03 Hans Verkuil wrote: On Tuesday 27 April 2010 10:08:06 Hans de Goede wrote: Hi, On 04/26/2010 09:55 AM, Hans Verkuil wrote: On Monday 26 April 2010 09:35:23 Hans de Goede wrote: Hi all, Currently v4l-utils is at version 0.7.91, which as the version suggests is meant as a beta release. As this release seems to be working well I would like to do a v4l-utils-0.8.0 release soon. This is a headsup, to give people a chance to notify me of any bugs they would like to see fixed first / any patches they would like to add first. This is a good opportunity to mention that I would like to run checkpatch over the libs and clean them up. I also know that there is a bug in the control handling code w.r.t. V4L2_CTRL_FLAG_NEXT_CTRL. I have a patch, but I'd like to do the clean up first. If no one else has major patch series that they need to apply, then I can start working on this. The clean up is just purely whitespace changes to improve readability, no functionality will be touched. I've no big changes planned on the short term, so from my pov go ahead. As you noticed I have cleaned up the includes, libv4l1 and libv4l2. libv4lconvert is a lot more work, so I will do that bit by bit, hopefully this week. I just finished doing the checkpatch conversions (phew!). This weekend I will push the control bug fix and I also have a v4l2-ctl enhancement pending that I will try to upstream today. I've finished with my changes, so as far as I am concerned you can prepare a new release. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.35] sn9c20x updates
The following changes since commit d3be2fab3a10b6c798a5f9970146d166d3345c37: Jean-François Moine (1): V4L/DVB: gspca - zc3xx: Fix the gamma calculation from the contrast are available in the git repository at: git://gitorious.org/v4l-dvb/v4l-dvb.git devel Brian Johnson (3): gspca - sn9c20x: Add another laptop to upsidedown device list gspca - sn9c20x: Add another MSI laptop to upsidedown device list gspca - sn9c20x: HAS_BUTTON flag - HAS_NO_BUTTON flag drivers/media/video/gspca/sn9c20x.c | 30 ++ 1 files changed, 22 insertions(+), 8 deletions(-) Regards, Brian Johnson -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Pushdown bkl from v4l ioctls
On Sat, May 01, 2010 at 11:55:37AM +0200, Hans Verkuil wrote: On Thursday 29 April 2010 09:10:42 Laurent Pinchart wrote: Hi Hans, On Thursday 29 April 2010 08:44:29 Hans Verkuil wrote: On Thursday 29 April 2010 05:42:39 Frederic Weisbecker wrote: Hi, Linus suggested to rename struct v4l2_file_operations::ioctl into bkl_ioctl to eventually get something greppable and make its background explicit. While at it I thought it could be a good idea to just pushdown the bkl to every v4l drivers that have an .ioctl, so that we actually remove struct v4l2_file_operations::ioctl for good. It passed make allyesconfig on sparc. Please tell me what you think. I much prefer to keep the bkl inside the v4l2 core. One reason is that I think that we can replace the bkl in the core with a mutex. Still not ideal of course, so the next step will be to implement proper locking in each driver. For this some additional v4l infrastructure work needs to be done. I couldn't proceed with that until the v4l events API patches went in, and that happened yesterday. So from my point of view the timeline is this: 1) I do the infrastructure work this weekend. This will make it much easier to convert drivers to do proper locking. And it will also simplify v4l2_priority handling, so I'm killing two birds with one stone :-) 2) Wait until Arnd's patch gets merged that pushes the bkl down to v4l2-dev.c 3) Investigate what needs to be done to replace the bkl with a v4l2-dev.c global mutex. Those drivers that call the bkl themselves should probably be converted to do proper locking, but there are only about 14 drivers that do this. The other 60 or so drivers should work fine if a v4l2-dev global lock is used. At this point the bkl is effectively removed from the v4l subsystem. 4) Work on the remaining 60 drivers to do proper locking and get rid of the v4l2-dev global lock. This is probably less work than it sounds. Since your patch moves everything down to the driver level it will actually make this work harder rather than easier. And it touches almost all drivers as well. Every driver will need to be carefully checked to make sure the BKL can be replaced by a v4l2-dev global mutex. Why would it be more difficult to do so if the BKL is pushed down to the drivers ? The main reason is really that pushing the bkl into the v4l core makes it easier to review. I noticed for example that this patch series forgot to change the video_ioctl2 call in ivtv-ioctl.c to video_ioctl2_unlocked. And there may be other places as well that were missed. Having so many drivers changed also means a lot of careful reviewing. Indeed, that's because I did it in a half automated way and my script didn't took the direct calls to video_ioctl2() into account, so I had to check them manually and probably missed a few, I will fix this one and double check. But I will not block this change. However, I do think it would be better to create a video_ioctl2_bkl rather than add a video_ioctl2_unlocked. The current video_ioctl2 function *is* already unlocked. So you are subtle changing the behavior of video_ioctl2. Not a good idea IMHO. And yes, grepping for video_ioctl2_bkl is also easy to do and makes it more obvious that the BKL is used in drivers that call this. Totally agreed, will respin with this rename. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
av7110 crash when unloading.
I just grabbed the latest hg tree and got the following when I tried to unload the drivers for my nexus-s: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077154] Oops: [#1] SMP Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077156] last sysfs file: /sys/devices/virtual/vtconsole/vtcon0/uevent Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077193] Process rmmod (pid: 5099, ti=f6a54000 task=f5311490 task.ti=f6a54000) Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077300] CR2: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077296] EIP: [f98dfeaa] v4l2_device_unregister+0x14/0x4f [videodev] SS:ESP 0068:f6a55e7c Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077273] Code: 89 c3 8b 00 85 c0 74 0d 31 d2 e8 90 91 8c c7 c7 03 00 00 00 00 5b c3 57 85 c0 56 89 c6 53 74 42 e8 da ff ff ff 8b 5e 04 83 c6 04 8b 3b eb 2f 89 d8 e8 fb fe ff ff f6 43 0c 01 74 0c 8b 43 3c 85 Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077195] Stack: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077211] Call Trace: The modules wouldn't unload and a reboot was needed to clear it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat May 1 19:00:19 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14619:ee9826bc7106 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: d3be2fab3a10b6c798a5f9970146d166d3345c37 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc1-armv5-davinci: OK linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc1-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc1-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc1-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.35]
On Saturday 01 May 2010 13:32:22 Hans Verkuil wrote: The following changes since commit d3be2fab3a10b6c798a5f9970146d166d3345c37: Jean-François Moine (1): V4L/DVB: gspca - zc3xx: Fix the gamma calculation from the contrast are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc Three fixes and one simplification. The prio changes are trivial but prepare the way for moving prio handling into the core framework. Added another bug fix: em28xx: g_tuner must set type field. Setting a frequency with v4l2-ctl -f freq didn't work with em28xx because of this bug. Regards, Hans Hans Verkuil (4): Documentation: fix small error in the ENUMINPUT doc. bttv: remove bogus prio check in g_frequency. v4l2-common: simplify prio utility functions tvp7002: fix query_dv_preset. Documentation/DocBook/v4l/vidioc-enuminput.xml |2 +- drivers/media/video/bt8xx/bttv-driver.c| 23 +-- drivers/media/video/cpia2/cpia2_v4l.c |4 ++-- drivers/media/video/cx18/cx18-controls.c |2 +- drivers/media/video/cx18/cx18-fileops.c|2 +- drivers/media/video/cx18/cx18-ioctl.c | 16 drivers/media/video/davinci/vpfe_capture.c |2 +- drivers/media/video/davinci/vpif_capture.c |8 drivers/media/video/davinci/vpif_display.c |4 ++-- drivers/media/video/ivtv/ivtv-fileops.c|2 +- drivers/media/video/ivtv/ivtv-ioctl.c |2 +- drivers/media/video/pvrusb2/pvrusb2-v4l2.c |6 +++--- drivers/media/video/saa7134/saa7134-video.c| 14 +++--- drivers/media/video/tvp7002.c | 13 + drivers/media/video/v4l2-common.c | 22 +- drivers/staging/cx25821/cx25821-audups11.c |6 +++--- drivers/staging/cx25821/cx25821-video.c| 10 +- drivers/staging/cx25821/cx25821-video0.c |6 +++--- drivers/staging/cx25821/cx25821-video1.c |6 +++--- drivers/staging/cx25821/cx25821-video2.c |6 +++--- drivers/staging/cx25821/cx25821-video3.c |6 +++--- drivers/staging/cx25821/cx25821-video4.c |6 +++--- drivers/staging/cx25821/cx25821-video5.c |6 +++--- drivers/staging/cx25821/cx25821-video6.c |6 +++--- drivers/staging/cx25821/cx25821-video7.c |6 +++--- drivers/staging/cx25821/cx25821-videoioctl.c |6 +++--- drivers/staging/cx25821/cx25821-vidups10.c |6 +++--- drivers/staging/cx25821/cx25821-vidups9.c |6 +++--- include/media/v4l2-common.h|8 29 files changed, 100 insertions(+), 112 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx sliced VBI
Hi all, I played a bit with my HVR900 and tried the sliced VBI API. Unfortunately I discovered that it is completely broken. Part of it is obvious: lots of bugs and code that does not follow the spec, but I also wonder whether it ever actually worked. Can anyone shed some light on this? And is anyone interested in fixing this driver? I can give pointers and help with background info, but I do not have the time to work on this myself. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.35] Split off vbi subdev ops in a separate category
The following changes since commit d3be2fab3a10b6c798a5f9970146d166d3345c37: Jean-François Moine (1): V4L/DVB: gspca - zc3xx: Fix the gamma calculation from the contrast are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git vbi Currently many subdev drivers implement g/try/s_fmt. However, these calls should be converted to the new g/try/s_mbus_fmt. But before we can start that conversion we should first split off the VBI operations since the _fmt calls are also used for VBI format configuration. This patch series creates a new v4l2_subdev_vbi_ops and moves all VBI related functions to that new struct. Regards, Hans Hans Verkuil (13): v4l: move vbi-specific video ops to a new vbi ops struct v4l: add new subdev vbi ops to handle raw and sliced vbi. saa7115: support new vbi ops to set/get VBI format cx25840: support new vbi ops to set/get VBI format cx18: support new vbi ops to set/get VBI format saa7127: support new vbi ops to set/get VBI format tvp5150: support new vbi ops to set/get VBI format ivtv: switch to new vbi subdev ops cx18: switch to new vbi subdev ops. pvrusb2: switch to new vbi subdev ops cx231xx: switch to new vbi subdev ops em28xx: switch to new vbi subdev ops cx18/cx25840/saa7115/tvp5150: remove vbi support from s_fmt drivers/media/video/cx18/cx18-av-core.c | 21 drivers/media/video/cx18/cx18-av-core.h |5 +- drivers/media/video/cx18/cx18-av-vbi.c | 42 +++-- drivers/media/video/cx18/cx18-ioctl.c |6 +- drivers/media/video/cx18/cx18-streams.c |5 ++- drivers/media/video/cx18/cx18-vbi.c |2 +- drivers/media/video/cx231xx/cx231xx-video.c |4 +- drivers/media/video/cx25840/cx25840-core.c | 17 --- drivers/media/video/cx25840/cx25840-core.h |5 +- drivers/media/video/cx25840/cx25840-vbi.c | 40 +++- drivers/media/video/em28xx/em28xx-video.c |4 +- drivers/media/video/ivtv/ivtv-ioctl.c |6 +- drivers/media/video/ivtv/ivtv-streams.c |5 ++- drivers/media/video/ivtv/ivtv-vbi.c | 16 +++--- drivers/media/video/pvrusb2/pvrusb2-hdw.c |2 +- drivers/media/video/saa7115.c | 43 -- drivers/media/video/saa7127.c | 31 drivers/media/video/tvp5150.c | 67 +-- include/media/v4l2-subdev.h | 66 -- 19 files changed, 220 insertions(+), 167 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[dvb-apps] Updated initial scan file for hr-All
--- hr-All 2010-05-02 01:32:22.0 +0200 +++ hr-All.new 2010-05-02 01:30:14.0 +0200 @@ -12,9 +12,9 @@ T 59400 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 61800 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 64200 8MHz 3/4 NONE QAM64 8k 1/4 NONE -T 65000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 65800 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 66600 8MHz 2/3 NONE QAM64 8k 1/4 NONE +T 67400 8MHz 2/3 NONE QAM64 8k 1/8 NONE # HD - Split, Marjan T 68200 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 69000 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 71400 8MHz 3/4 NONE QAM64 8k 1/4 NONE -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT] preferred video apps?
On 1/05/10 10:48 AM, Mauro Carvalho Chehab wrote:
Please, _do_not_ reply privately ;)
I've found VLC useful for testing reception quality by eye,
though it's not obvious how to force usage of a particular tuner.
I am pretty sure it can record.
Also '{c,s,t}zap' ow w-zap are helpful for quick tests of basic
functionality like tuning, and with the signaltest.pl script
( http://linuxtv.org/wiki/index.php/Testing_reception_quality)
I use MythTV in 'production' but I find it a bit clumsy for testing with.
Cheers
Vince
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
