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: Mauro Carvalho Chehab <mchehab@infradead.org>
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: Pantelis Koukousoulas <pakt223@freemail.gr>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This bug caused uninitalized data to be returned during a G_TUNER status poll.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The lack of a break statement in the handling of VIDIOC_S_TUNER caused
errors to result. Fixed.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Rather than hardcoding frequency ranges everywhere, rely on
VIDIOC_G_TUNER results wherever we can.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
When the input is switched by opening /dev/radioX, we must also commit
that change into the driver core.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
These changes implement correct audio routing for radio mode on a
24xxx device.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Report and set correctly converted frequency to/from a V4L2 app.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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 <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
A conversion from Hz to V4L frequency units was accidentally removed
by an earlier change. Restore it.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
We can't allocate v4l device structures in a block, since the v4l core
governs when each device actually gets freed. This bug was introduced
as part of the core radio implementation. Fix it.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Support specification of vbi and radio device minor numbers in a
manner similar to the video device minor number.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Ensure we don't accidentally broadcast the standard while in radio mode.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The initial radio implementation used different units for tuning when
in radio mode. This changes everything to Hz.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Use separate enum for get/store of minor number; we want pvr2_config
to go away eventually and since it really means something different,
don't use it here
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The "main" V4L2 interface patch. This is yet very incomplete, incorrect and
probably inappropriate for inclusion as-is, but at least with this I 'm able
to tune and play radio through a V4L2 program (pvr-radio.c, a "thumb" version
of ivtv-radio.c with just the essentials).
Therefore, it kinda gives an idea of what is needed to support this, hm,
interface (partly used also by e.g., kradio). Please point out any mistakes
on this code. I 'm sure I 'm messing up some struct initialization somewhere
but currently I 'm too lazy to actually think this through until I complete
the functionality (e.g., handle the VIDIOC_S_STD, ENUMINPUT, etc ioctls
appropriately).
Signed-off-by: Pantelis Koukousoulas <pakt223@freemail.gr>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Add (and expose) a new function, pvr2_channel_check_stream_no_lock(), in
pvrusb2-context.c. This is hopefully the last V4L2 interface related patch
to change anything outside pvrusb2-v4l2.c.
We need this to implement the open() for the radio device. The reason is
that within the *enter_context() section of open() we need to ensure nobody
is streaming and if we cannot, we should cleanup after ourselves and return
-EBUSY. We cannot just use claim_stream() because:
1) That would cause a deadlock trying to re-acquire the context lock
2) We only need to ensure that nobody is streaming. We don't need to
actually acquire the stream.
Again, this is a kinda ugly patch. Feel free to improve.
Signed-off-by: Pantelis Koukousoulas <pakt223@freemail.gr>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This is the first patch in preparation of the V4L2/IVTV radio interface.
It does away with the assumption of only one minor per device. It also
adds a file to show the radio minor as well. This can be useful for a
program like pvr-radio.c (when it grows up), since this way it can search
for the minor of the /dev/radioX device it opened and use the video minor
of the same driver instance to get to the actual stream.
The implementation looks kinda ugly. Feel free to improve (that is the
reason behind separate patches anyway).
Signed-off-by: Pantelis Koukousoulas <pakt223@freemail.gr>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
In the previous patch we exploited the get_{min,max}_value facility to adjust
min/max allowable frequencies on the fly, depending on tuner mode.
Unfortunately, this facility was not used inside the *sym_to_val() function
that translates what we echo to sysfs, which means we got an -ERANGE despite
asking for a frequency between what we read to be min/max.
This patch corrects this small omission.
Signed-off-by: Pantelis Koukousoulas <pakt223@freemail.gr>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This is the logic that:
a) Ensures /sys/class/pvrusb2/sn-*/ctl_frequency/{max,min}_val are
"automagically" reset to sane values on each mode change.
b) Allows tuning to a radio frequency by something like:
echo `perl -e "print int(94.9*16000 + 0.5)"` \
> /sys/class/pvrusb2/sn-*/ctl_input/cur_val
The trick was to take advantage of the already existing .get_{min,max}_value
function pointers in pvr2_ctrl, to "dynamically override" the hardcoded values
for min/max frequency at runtime.
For a moment I thought to dispose of the hardcoded MIN/MAX_FREQ and use the
hirange/lowrange fields of the v4l2_tuner struct instead, but then I see that
tuner-core.c kinda hardcodes these as well, so I decided to not bother.
Signed-off-by: Pantelis Koukousoulas <pakt223@freemail.gr>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This is the logic that supports switching modes via e.g.,
echo radio > /sys/class/pvrusb2/sn-*/ctl_input/cur_val.
To do the mode switching we need to:
a) broadcast AUDC_SET_RADIO and
b) issue the CX2341X_ENC_MUTE_VIDEO command to the encoder.
The first is done by adding a new pvr2_i2c_op and having it trigger on
input change, the second by adding this command in pvr2_encoder_start()
and requesting an encoder restart on input change by setting
stale_subsys_mask appropriately.
The clues about AUDC_SET_RADIO and CX2341X_ENC_MUTE_VIDEO were kindly
provided by Hans Verkuil on the pvrusb2 mailing list. The idea to
implement mode switching this way (on input change) is due to Mike Isely.
Why AUDC_SET_RADIO/VIDIOC_S_STD are used for switching? I can 't be sure,
but I think this can be traced to a cornell student being the first to
implement radio support in ivtv "as a different standard". I think the
rest just evolved from there (it 's in the ivtv ML archives).
Signed-off-by: Pantelis Koukousoulas <pakt223@freemail.gr>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The commands CX2341X_DEC_SET_AUDIO_OUTPUT, CX2341X_DEC_SET_AV_DELAY and
CX2341X_ENC_SET_3_2_PULLDOWN are not implemented in the Conexant firmware.
So these commands are removed. This also means that the V4L2_CID_MPEG_VIDEO_PULLDOWN
control in cx2341x.c and pvrusb2-hdw.c is removed.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the
beginning of the declaration specifiers in a declaration is an
obsolescent feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Declare the parent device of i2c_adapter devices each time we can
easily do so. It makes the i2c_adapter appear at the right place in
the device tree, rather than as a platform device.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Len Brown <len.brown@intel.com>
Cc: Jordan Crouse <jordan.crouse@amd.com>
Cc: Jody McIntyre <scjody@modernduck.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: v4l-dvb-maintainer@linuxtv.org
Cc: Petr Vandrovec <vandrove@vc.cvut.cz>
Many struct file_operations in the kernel can be "const". Marking them const
moves these to the .rodata section, which avoids false sharing with potential
dirty data. In addition it'll catch accidental writes at compile time to
these shared resources.
[akpm@sdl.org: dvb fix]
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix long-standing issue which prevented use of 24xxx devices at any
horizontal resolution other an 720. The problem is in the cx25840
module, if no attempt is made to initialize VBI there. Such a thing
should not be needed, but the pvrusb2 driver is updated now to deal
with this.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Unlike 29xxx devices, the 24xxx model series does not have a dedicated
I2C device for reception of IR codes. Instead IR is handled directly
by the FX2 microcontroller and the results are communicated via
commands to the FX2. Rather than implement a whole new IR reception
pathway for 24xxx devices, this changeset instead emulates the
presence of the 29xxx device's I2C based IR receiver by intercepting
commands to that chip and issuing appropriate FX2 commands to do the
needed action. This has the result of allowing all the usual IR
frameworks (ir-kbd-i2c or lirc) to continue working unmodified for
24xxx devices.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
