- 21 Feb, 2007 40 commits
-
-
Mauro Carvalho Chehab authored
Signed-off-by:Mauro Carvalho Chehab <mchehab@infradead.org>
-
Mauro Carvalho Chehab authored
v4l2_tvnorm were meant to describe video standards and its names to V4L2 API. However, this were doing by some static structures at the driver. This patch changes the internals in a way that, at the driver, only a v4l2_tvnorm (a 64 bit integer) should be filled, with all supported tvnorms. videodev will dynamically generate the proper API array based on supported standards. Signed-off-by: -
Mauro Carvalho Chehab authored
video_mux is renamed to cx88_video_mux to be exported to cx88-blackbird Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
video_ioctl2 handler provides V4L2 API parsing. Using it makes the driver simpler, and isolates API parsing. This allows future reusage of driver controls using other ways, like sysfs and/or procfs and increases isolation of driver-specific handling from the generic common ioctl processing. Signed-off-by: -
Pantelis Koukousoulas authored
With the previous patch, mplayer started but was polling the video device forever without any video actually coming out. Further analysis showed that it does a VIDIOC_S_FMT with width and height set to -1 (!!!). The code handling this only cares that both are lower than the minimum range allowed so it ends up setting the size to 19x17 (!!) This pretty much breaks the encoder here. Even if this breakage is yet another (TM) result of my setup, setting the size to 19x17 by default would surprise most users IMHO. So, special case for -1 and interpret this to be a request for the default size, please. Users can then set their favorite size both through mplayer and through sysfs. With this patch, mplayer finally works in pvr:// mode (not that we really gain anything over operating it through sysfs with lirc, sometime I might actually get off my lazy a** and contribute this setup too) Signed-off-by:
Pantelis Koukousoulas <pakt223@freemail.gr> Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
-
Pantelis Koukousoulas authored
This should allow mplayer pvr:// to start. The trick is that no matter what actual input we use under this "fake" one, it will be able to do stereo :-) Signed-off-by:
-
Mike Isely authored
Audio mode changes are not private to the audio chip - other I2C modules need to see this as well. And since the command in question is VIDIOC_S_TUNER which is a standard v4l2 command, we really should be broadcasting it out. This change sets up a broadcast pathway for VIDIOC_S_TUNER and also eliminates the now redundant code from the audio chip handler. This fix enables stereo reception for the FM radio Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Ahmed S. Darwish authored
Signed-off-by:
Ahmed S. Darwish <darwish.07@gmail.com> Signed-off-by:
-
Mike Isely authored
Attempts to enumerate or operate on a group of EXT_CTRLS where the group size is zero is OK; don't fail on such operations. At least one application uses this to probe for the existence of this API so let it succeed. Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
This bug caused uninitalized data to be returned during a G_TUNER status poll. Signed-off-by:
-
Mike Isely authored
The lack of a break statement in the handling of VIDIOC_S_TUNER caused errors to result. Fixed. Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
Rather than hardcoding frequency ranges everywhere, rely on VIDIOC_G_TUNER results wherever we can. Signed-off-by:
-
Mike Isely authored
The automodeswitch control was a feature that enable automatic radio / tv switching based on the selected frequency. However since frequency ranges can overlap and also since apparently in some cases it's possible for the same frequency range to be both tv and radio in a specific region, then this feature can't safely work. So it's removed. Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
Clean up use of VIDIOC_G_TUNER; we now correctly gather info from all the I2C client modules. Also abide by V4L2_TUNER_CAP_LOW appropriately. Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Michael Schimek authored
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:
Michael H. Schimek <mschimek@gmx.at> Signed-off-by:
-
Alexey Dobriyan authored
If assigned minor is 10 or greater, terminator will be put beyound the end. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Mike Isely authored
Switch back to the previous input selection when the radio device is closed - but only do that if the current input selection is still the radio (i.e. it appears that it hasn't been messed with). Signed-off-by:
-
Mike Isely authored
When the input is switched by opening /dev/radioX, we must also commit that change into the driver core. Signed-off-by:
-
Mike Isely authored
Clean up and tighten logic involving stream configuration. This mainly involves changes to pvrusb2-v4l2.c, where we better clarify how we use the stream configuration enum and implement a cleaner means to control streaming for a given device node. Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
The default volume of 65535 is too high. Make is something smaller. Note that this _only_ changes the default value. Specifically, there are no scaling or other more intrusive changes here. I'm just sick of constantly having to reduce the volume every time I plug in and test the device! (And unfortunately we can't do a better fix like scaling the volume so that 65535 makes sense because doing so will screw up any app - like MythTV - which expects the old scaling.) Too bad V4L controls don't have better defined ranges. Signed-off-by:
-
Mike Isely authored
Trying to temporarily check that the stream is not claimed during open of the radio device is at best a race condition. What's to stop another app from claiming the stream anyway the instant after the check is done? The implementation for this was dicey anyway. So it's removed. The only "price" for this is that if /dev/radioX is opened while streaming video, then the video stream is just going to switch to radio mode anyway. If a user does this, he gets what he expects... Signed-off-by:
-
Mike Isely authored
Separate track radio versus tv frequency so that when we switch modes we can also switch to a sane frequency appropriate for the mode. Also implement logic to automate mode switching in certain cases. Signed-off-by:
-
Mike Isely authored
Implement new method for doing integer range checking, so that we can more intelligently range-check radio and tv ranges at once. Signed-off-by:
-
Mike Isely authored
These changes implement correct audio routing for radio mode on a 24xxx device. Signed-off-by:
-
Mike Isely authored
Report and set correctly converted frequency to/from a V4L2 app. Signed-off-by:
-
Mike Isely authored
Frequency units in V4L2 are apparently different when in radio mode compared to tv mode. Why? Who knows. This change adapts the driver appropriately - so that internally we always only deal in Hz and don't have to muck with craziness like this. Signed-off-by:
-
Mike Isely authored
A conversion from Hz to V4L frequency units was accidentally removed by an earlier change. Restore it. Signed-off-by:
-
