On Tue, Jun 26, 2018 at 4:09 PM, Brad Love wrote:
> Hi Mauro,
>
> It turns out this patch breaks DualHD multiple tuner capability. When
> alt mode is set in start_streaming it immediately kills the other tuners
> stream. Essentially both tuners cannot be used together when this is
> applied. I unf
Reviewed-by: Devin Heitmueller
Devin
On Tue, May 22, 2018 at 1:09 PM, Gustavo A. R. Silva
wrote:
> This code has been there for nine years now, and it has been
> working "good enough" since then [1].
>
> Remove duplicate code by getting rid of the if-else statement.
>
>> diff -u -p drivers/media/dvb-frontends/au8522_decoder.c
>> /tmp/nothing/media/dvb-frontends/au8522_decoder.c
>> --- drivers/media/dvb-frontends/au8522_decoder.c
>> +++ /tmp/nothing/media/dvb-frontends/au8522_decoder.c
>> @@ -280,14 +280,9 @@ static void setup_decoder_defaults(struc
>>
389208e1173e097590856ed24a505551510f78d4.
Thanks to Daniel Glöckner for spotting the actual bug after I spent
several days trying to chase down the issue.
Signed-off-by: Devin Heitmueller
Thanks-to: Daniel Glöckner
Cc: Hans Verkuil
---
drivers/media/pci/cx88/cx88-vbi.c | 1 -
1 file changed, 1 deletion
Hi Daniel,
My apologies for the delayed replies; been out of town for the last
couple of days.
On Fri, Apr 20, 2018 at 5:54 PM, Daniel Glöckner wrote:
> for some reason I feel like buffer_queue in cx88-vbi.c should not be
> calling cx8800_start_vbi_dma as it is also called a few lines further
>
Hello Daniel,
See below.
Devin
[ 68.750805] cx88[0]: irq vid [0x18080] vbi_risc2* vbi_sync opc_err*
[ 68.750805] cx88[0]/0: video risc op code error
[ 68.750809] cx88[0]: video y / packed - dma channel status dump
[ 68.750811] cx88[0]: cmds: initial risc: 0x8aa98000
[ 68.750813] cx88
Hi Daniel,
Thanks for the feedback.
On Tue, Apr 17, 2018 at 12:53 AM, Daniel Glöckner wrote:
>> [ 54.427224] cx88[0]: irq vid [0x10088] vbi_risc1* vbi_risc2* opc_err*
>> [ 54.427232] cx88[0]/0: video risc op code error
>> [ 54.427238] cx88[0]: video y / packed - dma channel status dump
>
Hello,
I received a report of a case where cx88 video capture was failing on
start and the dmesg was reporting an invalid opcode on the video IRQ
handler. I did a bisect, and it looks like it's a result of the
videobuf2 conversion done back in late 2014. A few notes:
1. It only seems to occur
On Tue, Feb 27, 2018 at 12:42 PM, Mauro Carvalho Chehab
wrote:
> While coherent memory is cheap on x86, it has problems on
> arm. So, stop using it.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> I wrote this patch in order to check if this would make things better
> for ISOCH transfers on Ra
On Fri, Feb 23, 2018 at 2:37 PM, Devin Heitmueller
wrote:
> On Fri, Feb 23, 2018 at 2:30 PM, Federico Allegretti
> wrote:
>> i noticed that my pinnacle 300i could accept full resolution settings:
>> v4l2-ctl --set-fmt-video=width=720,height=576
>>
>> only the f
On Fri, Feb 23, 2018 at 2:30 PM, Federico Allegretti
wrote:
> i noticed that my pinnacle 300i could accept full resolution settings:
> v4l2-ctl --set-fmt-video=width=720,height=576
>
> only the first time the command is fired.
>
> after that, evey time i try to set that resolution with the same
>
Hi Laurent,
On Mon, Feb 19, 2018 at 11:19 AM, Laurent Pinchart
wrote:
> I've tested VLC (2.2.8) and haven't noticed any issue. If a program is
> directed to the metadata video node and tries to capture video from it it will
> obviously fail. That being said, software that work today should contin
Hi Sakari,
I tried this patch, and I no longer see the messages in dmesg output
when closing the V4L2 device node.
Tested-by: Devin Heitmueller
Thanks,
Devin
On Fri, Feb 2, 2018 at 8:57 AM, Devin Heitmueller
wrote:
> Hello Sakari,
>
> Thanks for proposing this patch. I'll
Hello Sakari,
Thanks for proposing this patch. I'll give it a try this weekend.
Regards,
Devin
On Fri, Feb 2, 2018 at 5:08 AM, Sakari Ailus
wrote:
> If buffers were prepared or queued and the buffers were released without
> starting the queue, the finish mem op (corresponding to the prepare m
o you see any
reason where at least for my local tree I cannot simply revert this
patch until a real solution is found?
Cheers,
Devin
On Mon, Jan 29, 2018 at 8:44 PM, Devin Heitmueller
wrote:
> Hello Sakari,
>
> Thanks for taking the time to investigate. See comments inline.
>
> On S
Hello Sakari,
Thanks for taking the time to investigate. See comments inline.
On Sun, Jan 28, 2018 at 5:23 PM, Sakari Ailus
wrote:
> Hi Devin,
>
> On Sun, Jan 28, 2018 at 09:12:44AM -0500, Devin Heitmueller wrote:
>> Hello all,
>>
>> I recently updated to the latest
Hello all,
I recently updated to the latest kernel, and I am seeing the following
dumped to dmesg with both au0828 and em28xx based devices whenever I
exit tvtime (my kernel is compiled with CONFIG_VIDEO_ADV_DEBUG=y by
default):
[ 129.219666] vb2: counters for queue 88026463ac48:
[ 129.2196
Hi Brad,
My documents indicate that Register 0x5D and 0x5E are read-only, and
populated based on the eeprom programming.
On your device, what is the value of those registers prior to you changing them?
If you write to those registers, do they reflect the new values if you
read them back?
Does c
> I think I wrote the driver more than 10 years ago and somebody later
> submitted it
> to the kernel.
I'm pretty sure that was me, or perhaps I was the first person to get
it to work with a device upstream - it was so long ago.
> I don't know if there is a anybody still maintaining this. Is it
Hi Oleh,
On Mon, Oct 23, 2017 at 5:37 AM, Sean Young wrote:
> Hi Oleh,
>
> On Sun, Oct 22, 2017 at 05:01:05PM +0300, Oleh Kravchenko wrote:
>> Hi,
>>
>> I'm trying add support remote control for tuners:
>> - EvroMedia Full Hybrid Full HD
>> - Astrometa T2hybrid
>>
>> But I'm stuck. Can anybody re
Hi Andy,
> 5. Rx and IR Learn both use the same external hardware. Not
> coordinating Rx with Learn mode in the same driver, will prevent Learn
> operation from working. That is, if Learn mode is ever implemented.
> (Once upon a time, I was planning on doing that. But I have no time
> for that
> There's an ir_lock mutex in the driver to prevent simultaneous access to the
> Rx and Tx functions of the z8. Accessing Rx and Tx functions of the chip
> together can cause it to do the wrong thing (sometimes hang?), IIRC.
>
> I'll see if I can dig up my old disassembly of the z8's firmware to
On Sun, Sep 17, 2017 at 5:42 PM, Nigel Kettlewell
wrote:
> I propose the following patch to support Hauppauge HVR-1200 analog video,
> nothing more than a clone of HVR-1500. Patch based on Linux 4.9 commit
> 69973b830859bc6529a7a0468ba0d80ee5117826
>
> I have tested composite and S-Video inputs.
>
> I've accepted the other patches in this patch series for the media subsystem,
> but this patch should go through the USB subsystem. Cc-ed linux-usb.
>
> Acked-by: Hans Verkuil
I'm not sure who on the linux-usb mailing list would need to deal with
this, but would be great if we could get this
On Mon, May 1, 2017 at 10:11 AM, Frank Schäfer
wrote:
>
> Am 01.05.2017 um 13:38 schrieb Mauro Carvalho Chehab:
>> Right now, all devices use bus 0 for eeprom. However, newer
>> versions of Terratec H6 use a different buffer for eeprom.
>>
>> So, add support to use a different I2C address for eepr
them.
Note: we also had to tweak the API to mxl111sf_ctrl_msg to pass
the pointer to the state struct rather than the device, since
we need it inside the function to access the buffers and the
mutex. This patch adjusts the callers to match the API change.
Signed-off-by: Devin Heitmueller
>> I had always interpreted it such that the STREAMON call just
>> controlled whether the DMA engine was running, and thus you could do
>> anything else with the decoder before calling STREAMON other than
>> actually receiving video buffers.
>
> Indeed there's an ambiguity there, although I always
inputs from 1300ms down to
600ms (as measured by "time v4l2-ctl -i 0")
Note this does not address outstanding issues related to the management
of the module clocks and power control for the various blocks, which
will be done in a separate patch.
Signed-off-by: Devin Heitmueller
---
dri
stent with other functions). Note
this change has no practical effect at this time as none of the
callers inspect the return value.
Signed-off-by: Devin Heitmueller
---
drivers/media/tuners/xc5000.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --
The Kconfig format is strict enough where if the indentation isn't
correct then the "make menuconfig" will break.
Fix the indentation to match all the other entries.
Signed-off-by: Devin Heitmueller
---
drivers/media/rc/Kconfig | 8
1 file changed, 4 insertions(
We need to set the initial modulation on driver setup, or else any
calls to GET_FRONTEND prior to the first SET_FRONTEND call will get
back garbage.
Signed-off-by: Devin Heitmueller
---
drivers/media/dvb-frontends/au8522_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media
n actually interfere with the operation of the bus.
Signed-off-by: Devin Heitmueller
---
drivers/media/dvb-frontends/au8522_decoder.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/au8522_decoder.c
b/drivers/media/dvb-frontends/au8522_decoder.c
index 12a5c2c..7811
startup, in particular when starting up ALSA
audio streaming in parallel - the sysfs entries created by
snd-usb-audio on streaming startup would result in unsupported control
messages being sent during tuning which would put the chip into an
unknown state.
Signed-off-by: Devin Heitmueller
only supported way to access VBI on
this device.
Signed-off-by: Devin Heitmueller
---
drivers/media/dvb-frontends/au8522_decoder.c | 38
1 file changed, 38 deletions(-)
diff --git a/drivers/media/dvb-frontends/au8522_decoder.c
b/drivers/media/dvb-frontends/au8522_deco
I got this working a couple of years ago. Remove it from the
list of known issues.
Signed-off-by: Devin Heitmueller
---
drivers/media/dvb-frontends/au8522_decoder.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/au8522_decoder.c
b/drivers/media/dvb-frontends
The leading bit in register values is actually an indicator as to
whether to perform a read or write, so remove the bit from the
register values, since the au8522_writereg() is now responsible
for adding this bit automatically.
Signed-off-by: Devin Heitmueller
---
drivers/media/dvb-frontends
Only looking at the lock register causes the status to float
between locked and not locked when there is no signal. So improve
the logic to also examine the state of the FSC PLL, which results
in the lock status being consistently reported.
Signed-off-by: Devin Heitmueller
---
drivers/media
For reasons unclear, we intermittently see a case where the tune
is successful but the bulk stream fails to deliver any packets.
Add a timer to automatically stop/start the data pump if we
encounter such a case.
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/au0828/au0828-dvb.c | 30
: Devin Heitmueller
---
drivers/media/dvb-frontends/au8522_dig.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/media/dvb-frontends/au8522_dig.c
b/drivers/media/dvb-frontends/au8522_dig.c
index d117ddb..3f3635f 100644
--- a/drivers/media/dvb-frontends
This is a series of mostly minor cleanups/fixes for the HVR-950q
driver. We'll get this stuff merged since it's non-controversial,
and then we can argue about the more invasive patches to follow.
Devin Heitmueller (12):
au8522: don't attempt to configure unsupported VBI slicer
ession was introduced in the following commit:
commit ccd6f1d488e7 ("[media] cx88: move width, height and field to core
struct")
Author: Hans Verkuil
Date: Sat Sep 20 09:23:44 2014 -0300
[media] cx88: move width, height and field to core struct
Signed-off-by: Devin Heitmueller
--
Hello all,
I'm in the process of putting together a bunch of long-standing fixes
for HVR-950q driver, and I ran into a regression related to the way
the video decoder is being managed. Before we dig into the details
here's the general question:
Should a user be able to interrogate video decoder
>> For what it's worth, I doubt most of the em28xx designs have the
>> tvp5150 interrupt request line connected in any way.
>
> True. But, on embedded hardware, such line may be connected into the
> SoC. Actually, from the IGEPv3 expansion diagram:
>
>
> https://www.isee.biz/support/downlo
> Currently, the driver doesn't support (2), because, at the time
> I wrote the driver, I didn't find a way to read the interrupts generated
> by tvp5150 at em28xx[1], due to the lack of em28xx documentation,
> but adding support for it shoudn't be hard. I may eventually do it
> when I have some ti
> lsusb:
> Bus 003 Device 002: ID 0573:0400 Zoran Co. Personal Media Division (Nogatech)
> D-Link V100
The Zoran usbvision driver has been a mess for years, and it's not
going to get better anytime soon. It's a *really* old design and
there hasn't been any interest from any of the developers to
Hi George,
The big problem is that almost none of the hardware tuners out there
which support FM have support for RDS. You generally need an extra
chip, and very few devices have it (IIRC, none of the ones that are
supported in Linux have been available in retail for a number of
years).
Don't ge
Hi Mauro,
> With that, I completed the tests on HVR-950. My tests covered:
> - S-Video, Composite, TV
> - 480i and 480p
> - Closed Captions (with HVR-350 - it seems that MediaMVP doesn't
> produce NTSC CC).
FYI: the MediaMVP HD can be configured to output NTSC CC over VBI.
If you want that fun
Hi Mauro, Laurent,
I tried out Mauro's latest patch (9:46am EST), and it appears to at
least partially address the issue, but still doesn't work. In fact,
whereas before I was getting stable video with a chroma issue, with
the patch applied I'm now getting no video at all (i.e. tvtime is
complete
Hello Javier, Mauro, Laurent,
I hope all is well with you. Mauro, Laurent: you guys going to
ELC/Portland in February?
Looks like the refactoring done to tvp5150 in January 2016 for
s_stream() to support some embedded platform caused breakage in the
30+ em28xx products that also use the chip.
> OK, but what can the application do with that event? If the glitch didn't
> affect the video, then it is pointless.
>
> If the lock is lost, then normally you loose video as well. If not, then
> applications are not interested in the event.
What about free running mode (where some decoders deliv
Hi Matt,
> Need some input for the video pixel data types, which the device we
> are using (see datasheet links below) is outputting pixel data in
> little endian 16-bit of which a 12-bits signed value is used. Does it
> make sense to do some basic processing on the data since greyscale is
> goin
On Mon, Sep 19, 2016 at 8:51 PM, Alexandre-Xavier Labonté-Lamoureux
wrote:
> Hi people,
>
> In the file "/linux/drivers/media/pci/ngene/ngene-core.c", there is a
> null pointer dereference at line 1480.
>
> Code in the function "static int init_channel(struct ngene_channel *chan)"
> ==
On Mon, Sep 19, 2016 at 8:51 PM, Alexandre-Xavier Labonté-Lamoureux
wrote:
> Hi people,
>
> In the file "/linux/drivers/media/pci/ngene/ngene-core.c", there is a
> null pointer dereference at line 1480.
>
> Code in the function "static int init_channel(struct ngene_channel *chan)"
> ==
Hi Steve,
> We have two models of the StarTech in use: SVID2USB2 and SVID2USB23. The
> "23" version is the only version currently listed on StarTech's website. It
> is available via Amazon in the USA but I'm not sure about other countries.
Have you actually opened these units up and confirmed
On Wed, Jun 8, 2016 at 4:10 PM, Marcin Kałuża
wrote:
> Hello!
> I'm looking for someone who was able to successfully use Octopus Dual
> CI bridge by Digital Devices under Linux. We got it _almost_ working -
> we have a strange problem of the module dropping TS packets in sets of
> 30-33 packets ra
> Appreciate some advice.
Return it and get an HVR-950q. This has been a known issue for more
than 5 years and nobody's gotten around to fixing it (largely because
of limitations inside the V4L2 framework).
Devin
(a.k.a. the guy who added the original support for the HVR-850).
--
Devin J. Heit
On Wed, Jan 6, 2016 at 1:27 PM, Schubert, Matthew R.
(LARC-D319)[TEAMS2] wrote:
> Hello,
>
> We are attempting to use a StarTech Video Capture cable (Part# SVID2USB2)
> with our CentOS 6.7 machine with no success. The em28xx driver seems to load
> but cannot properly ID the capture cable. Below
On Tue, Dec 29, 2015 at 1:53 PM, Insu Yun wrote:
> Since kmalloc can be failed in memory pressure,
> if not properly handled, NULL dereference can be happend
>
> Signed-off-by: Insu Yun
> ---
> drivers/media/usb/cx231xx/cx231xx-417.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/dri
> I've dug a bit deeper and discovered that the reason the
> em28xx_info(...) lines that I'd added to em2874_polling_getkey()
> weren't appearing is because I'd loaded the wrong version of the
> em28xx-rc module! (Doh!)
Ok, good.
> The polling function *is* being called regularly, but
> em28xx_ir
On Sun, Nov 15, 2015 at 3:49 PM, Chris Rankin wrote:
> Hi,
>
> My Hauppauge RC5 remote control finally broke, and the PCTV T2 290e's
> native RC5 remote control isn't suitable for VDR, and so I bought a
> cheap RC6 remote as a replacement. The unit I chose was the Ortek
> VRC-1100 Vista MCE Remote
> I actually refer to CX23418 chip, which I don't find its datasheet (I
> saw in code that cx18 can work in YUV raw capture, so I wanted to
> verify that CX23418 can capture YUV raw format).
The cx23418 datasheets are not publicly available, although I have
them under NDA and can likely answer spe
Hi Malcolm,
>> The capabilities call interacting with the oneshot setting is rather weird
>> and maybe unexpected.
>>
>>
>
> No, because in normal mode it can do auto inversion.
This isn't my area of expertise, but I suspect this is going to cause
some pretty confusing behavior. Generally speaki
> Look at the em28xx driver and you will probably see why it does not work as
> expected. For my eyes, according to em28xx driver, it looks like that bus
> control is aimed for bridge driver. You or em28xx is wrong.
Neither are wrong. In some cases the call needs to be intercepted by
the frontend
> It's not "new" IC. It's XC5000C. Maybe i was interpreted wrong.
> As I have understood, such behaviour can depends from FW version.
> HW vendor says, that with his latest FW he always gets response 0x14b4.
Ah, so you're running a completely different firmware image? Well in
that case that would
> IMHO, the best is to get the latest firmware licensed is the best
> thing to do.
>
> Does that "new" xc5000c come with a firmware pre-loaded already?
I've got firmware here that is indicated as being for the xc5300 (i.e.
0x14b4). That said, I am not sure if it's the same as the original
5000c f
> i also get this with make xconfig. just running ./build, however, works
Yeah, I've seen that before. It's a whitespace bug in the KConfig
file. Just open it in a text editor, go to the line in question, and
fix the leading whitespace to match all the other entries (If I
recall, you'll actually
Hi Pier,
On Sun, Mar 22, 2015 at 6:37 PM, pier@libero.it wrote:
> Hello,
>
> I was wondering if anyone had any idea of how much latency a DVB-T receiver
> can add, in the path between radiofrequency and the MPEG-TS stream. I have
> 100ms of unwanted latency I can't explain in an application I
> Note however that it is perfectly fine if the driver detects the presence
> of such an onboard header when it is loaded and then only exposes those
> extra inputs if the header is present. It just can't change the list later
> unless do you an rmmod and modprobe of the driver. It's probably what
> I'm looking to enhance video input/output enumeration support in
> GStreamer using VIDIOC_ENUMINPUT/VIDIOC_ENUMOUTPUT ioctls and after some
> discussions we wonder if the input/output list can change dynamically at
> runtime or not.
>
> So, is v4l2 allow this input/output list to be dynamic ?
I
On Fri, Mar 13, 2015 at 10:18 PM, Shuah Khan wrote:
> au0828 s_std and s_input are missing queue busy checks. Add
> vb2_is_busy() calls to s_std and s_input and return -EBUSY
> if found busy.
These checks are only needed on devices which support more than a
single format (typically for devices wh
> These are just the issues I would like to implement drivers as standard I2C
> driver model =) Attaching driver for one chip twice is ugly hack!
While I'm not arguing the merits of using the standard I2C driver
model, it won't actually help in this case since we would still need a
structure repre
> I would request you to add a comment here indicating the
> hybrid case scenario to avoid any future cleanup type work
> deciding there is no need to set priv->firmware to null
> since priv gets released in hybrid_tuner_release_state(priv);
No, I'm not going to rebase my tree and regenerate the p
t we don't call
release_firmware() twice.
This problem was detected in the HVR-950q where plugging/unplugging the
device multiple times would intermittently show panics in completely
unrelated areas of the kernel.
Signed-off-by: Devin Heitmueller
Cc: Shuah Khan
---
drivers/media/tune
Hi Hans,
On Mon, Feb 16, 2015 at 9:46 AM, Hans Verkuil wrote:
> On 02/16/2015 03:39 PM, Devin Heitmueller wrote:
>>> Except for PVR-500, I can't remember any case where the same tuner is used
>>> more than once.
>>>
>>> There is the case of a device
> Except for PVR-500, I can't remember any case where the same tuner is used
> more than once.
>
> There is the case of a device with two tuners, one for TV and another one
> for FM. Yet, on such case, the name of the FM tuner will be different,
> anyway. So, I don't think this is a current issue,
> It is actually trivial to get the device nodes once you have the
> major/minor. The media-ctl library does that for you. See:
No objection then.
On a related note, you would be very well served to consider testing
your dvb changes with a device that has more than one DVB tuner (such
as the hvr-
> For media-ctl, it is easier to handle major/minor, in order to identify
> the associated devnode name. Btw, media-ctl currently assumes that all
> devnode devices are specified by v4l.major/v4l.minor.
I suspect part of the motivation for the "id" that corresponds to the
adapter field was to make
Hi Shuah,
> TRY_FMT and S_FMT both don't handle invalid pixelformats. Looks like
> there is reason behind this based on the comments:
>
> /* format->fmt.pix.width only support 720 and height 480 */
> if (width != 720)
> width = 720;
> if (height != 480)
>
>> - fh->type = type;
>> - fh->dev = dev;
>> - v4l2_fh_init(&fh->fh, vdev);
>> - filp->private_data = fh;
>> + dprintk(1,
>> + "%s called std_set %d dev_state %d stream users %d users
>> %d\n",
>> + __func__, dev->std_set_in_tuner_core, dev
> I couldn't reproduce what I was seeing when I did patch v2 series
> work. What I noticed was that I was seeing a few too many green screens
> and I had to re-tune xawtv when the timeout code is in place. My
> thinking was that this timeout handling could be introducing blank
> green frames when t
Hi Shuah,
On Mon, Jan 12, 2015 at 9:56 PM, Shuah Khan wrote:
> au0828 does video and vbi buffer timeout handling to prevent
> applications such as tvtime from hanging by ensuring that the
> video frames continue to be delivered even when the ITU-656
> input isn't receiving any data. This work-aro
> As we've discussed on IRC channel, it would be good to add support
> for format enumeration on it, but the changes don't seem to be
> trivial. I'm not willing to do it, due to my lack of time, but,
> if someone steps up for doing that, then we can wait for those
> patches before bumping the versi
>> In short, that code cannot be removed.
>
> Sure it can. I just tried tvtime and you are right, it blocks the GUI.
> But the fix is very easy as well. So now I've updated tvtime so that
> it timeouts and gives the GUI time to update itself.
That's a nice change to tvtime and I'm sure it will mak
> No, tvtime no longer hangs if no frames arrive, so there is no need for
> this timeout handling. I'd strip it out, which can be done in a separate
> patch.
Did you actually try it? Do you have some patches to tvtime which
aren't upstream?
I wrote the comment in question (and added the associate
> My understanding is that it covers that specific firmware file.
In this case the license was actually against the header file. I was
responsible for generating the binary blob based on the header files
in the Xceive sources (and got the appropriate permission). There
should be no licensing iss
> With regards to CC decoding, IMHO, the best would be to add a parser
> for ISDB CC at libdvbv5.
It probably makes more sense to extend one of the existing libraries
that supports captions/subtitles to include support for ISDB (such as
libzvbi or ccextractor). The libdvbv5 library has no infrast
> I realize captions is an application-layer function, and intend to work with
> the CCExtractor team. Do any other applications already have ISDB caption
> support?
Based on a Google search, it looks like dvbviewer can decode them:
http://www.dvbviewer.tv/forum/topic/41933-brazilian-terrestrial-
Hi David,
ISDB-T subtitles are done in a similar manner to DVB-T subtitles -
there is a PID in the stream which contains the subtitle data, which
needs to be decoded by the application (just as you would handle DVB-T
subtitles or ATSC closed captions). It's entirely an application
level function,
On Thu, Oct 30, 2014 at 9:37 AM, Mauro Carvalho Chehab
wrote:
> Yeah, if nobody is using such devices, then we should get rid of them,
> but I prefer to have this on a separate patch, in order to give
> people the opportunity to complain.
Yes, I would definitely suggest a separate patch. There's
au8522 demodulator, in the case of the
> Hauppauge HVR950Q).
>
> This patch works with all XC5000 firmware versions.
>
> Signed-off-by: Richard Vollkommer
> Cc: Devin Heitmueller
> Signed-off-by: Michael Ira Krufky
Reviewed-by: Devin Heitmueller
--
Devin J. Heitmueller
> Well, perhaps you could add a printk message warning the user that
> the driver is not using the latest firmware and performance/quality
> could be badly affected.
I wouldn't use the term "badly affected". There are tens of thousands
of units out there for which users are quite happy with the c
Hi Mauro,
> Syncronize it and put them on the same order as found at au0828
> driver, as all the au0828 devices with analog TV need the
> same quirks.
The MXL and Woodbury boards don't support analog under Linux, so
probably shouldn't be included in the list of quirks.
That said, the MXL and Woo
> this seems like a feature, not a bug. PulseAudio starts streaming before
> clients push any data and likewise keeps sources active even after for some
> time after clients stop recording. Closing VLC in your example doesn't
> immediately close the ALSA device. look for module-suspend-on-idle in y
> Sorry, I'm not convinced by that. If the device has to be controlled
> exclusively, the right position is the open/close. Otherwise, the
> program cannot know when it becomes inaccessible out of sudden during
> its operation.
I can say that I've definitely seen cases where if you configure a
d
Hello Shuah,
>> What about G_INPUT and G_TUNER? Consider the following use case, which is
>> entirely legal in the V4L2 API:
>
> Did you mean G_INPUT and G_STD here? I didn't see G_TUNER mentioned
> below in the use-case.
It can be either ENUM_INPUT or G_TUNER. Both return status
information th
> Well, au8522_rc_set is defined as:
>
> #define au8522_rc_set(ir, reg, bit) au8522_rc_andor(ir, (reg), (bit),
> (bit))
Ah, ok. It's just a really poorly named macro. Nevermind then.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this lis
On Thu, Aug 7, 2014 at 9:46 AM, Mauro Carvalho Chehab
wrote:
> When the DVB code sets the frontend, it disables the IR
> INT, probably due to some hardware bug, as there's no code
> there at au8522 frontend that writes on register 0xe0.
>
> Fixing it at au8522 code is hard, as it doesn't know if t
> I am trying to troubleshoot a (non-linux related) DVB-T issue and I basically
> want to create statistics about both DVB and MPEG framing, errors, corruption,
> missing frames, etc.
>
> The reason is that I believe there is a problem on the transmitting radio
> tower, RF is fine between the tower
> diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
> index 2b3d514..d1f539c 100644
> --- a/drivers/media/tuners/xc5000.c
> +++ b/drivers/media/tuners/xc5000.c
> @@ -85,6 +85,7 @@ struct xc5000_priv {
> /* Product id */
> #define XC_PRODUCT_ID_FW_NOT_LOADED0x2000
> #
Hello,
I'm in the process of adding support for a new video decoder. However
in this case it's an IP block on a USB bridge as opposed to the
typical case which is an I2C device. Changing registers for the
subdev is the same mechanism as changing registers in the rest of the
bridge (a specific re
1 - 100 of 1456 matches
Mail list logo