Hi,
Just wondering whether anyone else has had any experience trying to get
the WinFast DTV1800 H card to work? Or has any advice on how to do so?
I'm happy to have a go at implementing support for this card (hopefully in
some ways it is fairly similar to the DTV1000, although it has analogue
t
Hi,
Just wondering whether anyone else has had any experience trying to get the
WinFast DTV1800 H card to work? Or has any advice on how to do so?
I'm happy to have a go at implementing support for this card (hopefully in
some ways it is fairly similar to the DTV1000, although it has analogue
t
On Sat, 2007-05-19 at 23:45 +0200, e9hack wrote:
> Thanks, I need only the dump with the running application and with the
> i2c-address 0xc (tda10021). I forgot, that exists
> some more devices on the i2c-bus. The windows driver uses a small buffer
> (188kB), in odd/even buffer mode. The line
>
On Wed, 2007-05-02 at 02:32 +0200, Oliver Endriss wrote:
> Jon Burgess wrote:
> > Sorry for the delay. I wanted to track down the DMA sync bug before I
> > came back to look at this again.
> >
> > I have added saa7146_vmalloc_destroy_pgtable() which frees the resources
On Wed, 2007-05-02 at 01:08 +0200, Oliver Endriss wrote:
> e9hack wrote:
> > Oliver Endriss wrote:
> > > Jon Burgess wrote:
> > >> It appears the problem is that the driver is using streamed PCI and
> > >> needs to explicitly sync the data otherwise it b
On Tue, 2007-05-01 at 11:41 +0200, Gregoire Favre wrote:
> Hello again,
>
> just forgot this :
>
> ksymoops 2.4.11 on x86_64 2.6.21. Options used
> -V (default)
> -k /proc/ksyms (default)
> -l /proc/modules (default)
> -o /lib/modules/2.6.21/ (default)
> -m /usr/src/linu
the error paths to ensure they free all allocated
resources on error.
Also included in this patch are the previous fixes for pci_unmap_sg()
and syncing the PCI streamed data to work with a SWIOTLB and match the
requirements documented in DMA-API.txt.
Jon
Signed-off-by: Jon Burgess <
On Mon, 2007-04-30 at 18:52 +0200, Gregoire Favre wrote:
> On Sat, Apr 28, 2007 at 09:14:37PM +0100, Jon Burgess wrote:
>
> > While the above patch works, it seems the underlying causes is that
> > vmalloc_32() is providing memory above 4Gb on x86-64 which is not what
> >
On Sat, 2007-04-28 at 18:17 +0100, Jon Burgess wrote:
> On Fri, 2007-04-27 at 18:06 -0400, Lee Revell wrote:
> > On 4/27/07, Jon Burgess <[EMAIL PROTECTED]> wrote:
> > > Interesting - I see similar symptoms after upgrading my PC:
> > > * old PC was AMD Athlon 6
On Fri, 2007-04-27 at 18:06 -0400, Lee Revell wrote:
> On 4/27/07, Jon Burgess <[EMAIL PROTECTED]> wrote:
> > Interesting - I see similar symptoms after upgrading my PC:
> > * old PC was AMD Athlon 64 3000 w/ 2GB of RAM which had no issues
> > * new PC is a Intel Core 2
On Fri, 2007-04-27 at 18:06 -0400, Lee Revell wrote:
> On 4/27/07, Jon Burgess <[EMAIL PROTECTED]> wrote:
> > Interesting - I see similar symptoms after upgrading my PC:
> > * old PC was AMD Athlon 64 3000 w/ 2GB of RAM which had no issues
> > * new PC is a Intel Core 2
On Fri, 2007-04-27 at 22:46 +0200, Markus Rechberger wrote:
> just for the completeness, what does dmesg show up?
> You forgot to mention what device you have too...
>
> Markus
>
> On 4/27/07, Gregoire Favre <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I have a computer (mother Asus Commando) wi
I've been looking at the sa7146 page table code and it looks like the
saa7146_pgtable_free function is used incorrectly in the error cases:
from budget-core.c:
ttpci_budget_init()
{
...
budget->grabbing = saa7146_vmalloc_build_pgtable(dev->pci,
budget->buffer_size, &budget->pt))
...
err:
On Sun, 2007-02-25 at 12:11 +0200, Antti P Miettinen wrote:
> Chris Johns <[EMAIL PROTECTED]> writes:
> > I see the same sequence that you do. Here is the specific part that
> > matches what I see. Your trace has:
>
> Hmm.. I guess I need to learn to decipher the logs. Meanwhile there's
> another
On Thu, 2007-02-01 at 08:22 -0800, Joe R wrote:
> Hello -
>
> I'm trying to get a Lifeview LR535 card working. It's in a minicard slot in
> an
> HEL-80 laptop, and I'm a little confused. If I lspci I don't see it there; if
> I lsusb I see "10fd:0535 Anubus Electronics Ltd." -- which implies it'
On Sat, 2007-01-06 at 23:49 +0200, Lokrain wrote:
> Hello all,
>
> I am trying to install VLC 0.8.5-1 na FC6. I checked that VLC for FC
> after version 4 doesn't exist.
It is available in the livna or freshrpms repos.
http://rpm.livna.org/ or http://zod.freshrpms.net
# yum list vlc\*
...
Availa
On Sun, 2006-10-29 at 20:47 +, Torgeir Veimo wrote:
> On 29 Oct 2006, at 16:09, Patrick Boettcher wrote:
>
> > Hi Torgeir,
> >
> >
> > On Sat, 28 Oct 2006, Torgeir Veimo wrote:
> >
> >>
> >> On 28 Oct 2006, at 00:35, Torgeir Veimo wrote:
> >>
> >>> Am not sure where to start looking. I've incl
On Sun, 2006-10-29 at 20:18 +, Torgeir Veimo wrote:
> On 29 Oct 2006, at 16:09, Patrick Boettcher wrote:
>
> > Hi Torgeir,
> >
> >
> > On Sat, 28 Oct 2006, Torgeir Veimo wrote:
> >
> >>
> >> On 28 Oct 2006, at 00:35, Torgeir Veimo wrote:
> >>
> >>> Am not sure where to start looking. I've incl
On Wed, 2006-10-18 at 23:34 +0100, Steve Brokenshire wrote:
> Hi,
>
> (Before I start, I'm running linuxtv-dvb-apps 1.1.1 with Linux kernel
> 2.6.17.11 on Debian 3.1, using a Freecom DVB-T USB stick and a Hauppauge
> PVR-350 card with VDR 1.3.41. I've done a quick skim on the linux-dvb mailing
Tim Hoad wrote:
Hi all,
I am having problems getting my VisionPlus DVB-t card to play nice with my SATA
HDD - video breaks up when disk is accessed. I am using a motherboard with
on-board SiI3112 SATA controller (ABIT NF7-s).
Are you using Linux-2.6 with VDR and a ext2/3 filesystem for the vide
Andreas Share wrote:
Hi,
I have around 1600-1800 interrupts per second, with the ss2 as secondary
device during epgscan.
OK, That is not excessive - an idle 2.6 machine has 1000 from the timer
interrupt alone.
One other thing: The Dbox2 related Tuxbox Project share the Api3 and the
most of the
Rene Bartsch wrote:
I'm having artefacts in the picture (VDR). The HDD (SATA) performs with
58 MB/s, so I assume it's related to the PCI-bus (on an i865PE board).
My setup has an i865G running with 4 x Nova-T PCI cards and I don't see
any problems so I suspect the PCI bus is not the cause.
D
Andreas Share wrote:
Hmm, my skystar2 rev 2.6c/stv0299 dies within 2-3h, but my nova (like
budget-ci) and my ff rev 1.5 sometimes run for ~12h...
i have seen the skystar2 irq_handler calls dvb_dmx_swfilter_packets() more
often than the other cards
if (adapter->capturing != 0) {
dvb_dmx_swfilter_p
Christian Schuld wrote:
Normally "ERROR: video data stream broken" indicates, that VDR doesn't get any
data out of the DVB-card. The reason might be a tuning failiure or this
mysterios bug, which happens only with VDR in a multi card setups. I suppose
none of the driver developers actually use s
Torbjörn Jansson wrote:
Maybe fedora have included some other kernel patches that breaks the osd? Or
maybe the dvb drivers in kernel 2.6.5 is broken?
The "4G-4G" feature of the FC2 kernels will break any incorrect direct
access to userspace data.
There is another example here
http://seclists.o
Scott White wrote:
I was wondering what solutions people are using for more than one card.
Can you get a digital capable amp/splitter for example?
I have 4 DVB-T cards and just use an regular 4 output TV amplifier from
a highstreet electronics store. This works fine for me at home.
I once had
Franck Arnaud wrote:
Ah, OK! I wondered why it had not been added earlier, and
I did not think about looking at this module (my card has no
CI, although I can imagine a CI version of same exists).
Thanks.
My card has no CI either, but I use the CI driver because it also
includes support for
I have 4 budget Nova-T PCI cards in my PC and it works OK. This is with
a reasonably spec'd normal desktop motherboard with a Intel 865G chipset
with a single standard 32bit/33MHz PCI bus (Gigabyte GA-8IG1000 Pro).
You could try changing the DMA burst settings. I believe the default
settings re
Johannes Stezenbach wrote:
IIRC the outcome of this discussion was "use BTN_x instead of
KEY_x if you don't want your remote control to generate
keyboard events".
2.6 has an "exclusive access" feature which can suck up these extra KEY
events from your remote preventing them from appearing as keyb
Q wrote:
Hi can anyone on this list tell me if there is a working Linux driver
for Wintv Nova-T?
Yes the linux-dvb driver code, see http://www.linuxtv.org/
Also what is the fron't end in Linux I should use to replace the WinTV
Windows based front end?
I would like to continue to be able to she
Danny Van Elsen wrote:
a question concerning my WinTV 350 Hauppauge PVR... it has an onboard
MPEG decoder an encoder, so what I
I think your problem is that this device is not a digital TV device. The
350 receives the analogue TV singal and then compresses it to MPEG2
which it then sends to the
Holger Waechtler wrote:
Alternatively it can "extracted" from the install cab files but this w
to be done in windows as I don't know of a linux version of extract.ex
Try http://www.kyz.uklinux.net/cabextract.php
I haven't used it myself, but I have seen it referenced elsewhere.
Jon
--
Inf
*Michal Dobrzynski wrote:
*> I'm not sure I understood. Do you mean:
..
>And why it be bad to do it this way:
...
I'm not sure what is the difference between the two you mention. There
is nothing particularly wrong with adding any extra cable, it is just
that the longer it is, the more distorted
Emil wrote:
> I mean between red and ground, green and ground, blue and ground.
I haven't tried wiring up this RGB lead myself but I've done a fair bit
of work with ananogue transmission line theory which explains why this
termination is required to get a good signal.
I believe the answer is a s
Olaf Titz wrote:
[1] mplayer (segfault)
I tried some HDTV sample files and found that mplayer would get an X11
error and segfault if I tried "-vo xv", but "-vo x11" worked ok, albeit
slowly. It appears that the XV support for my graphics card can not
handle the full 1920x1080 picture.
Jo
Emard wrote:
2.6 a more work is needed (can someone help me there
for the inspiration) to secure budgets on 2.6 because the
budget-core is loaded separately and MOD_INC_USE_COUNT
gets bound to budget-core and not to actual budget driver
...
Emard
You could get some inspiration from a patch I
Steve Wakelin wrote:
./vdr -Pstreamdev -Pdxr3
vdr: dxr3abstractiondevice.c:77: cDxr3AbsDevice::cDxr3AbsDevice():
Assertion `m_fdVideo >= 0' failed. Aborted
That error is reported when the code can not open the device
/dev/em8300_mv, have you created these device nodes?
xine and mplayer sho
Nick Manser wrote:
Firstly, is it possible to combine a DVB card with a harware MPEG-2 decoder
card and use them both to watch a digital TV stream? If so, how would I go
about doing this?
Yes you can do this. I have a similar setup with two Hauppauge DVB-T
cards and a Creative DXR3 card (which
Steffen Beyer wrote:
based cards? I can't do real testing because the DXR3 driver has no 2.6.0
support yet.
2.6 support is not yet in the main dxr3 codebase, but there are patches
available. There is a copy of the patch which I use at
http://www.jburgess.uklinux.net/linux-2.6.0-test9-dxr3.pat
Adam Lounds wrote:
whenever I run scan or dvbtune it doesn't work, but removing
FE_CAN_INVERSION_AUTO from the .caps fixes it.
Very new to this, but how does it work for anyone else?
I ran into the same problem as well when I ran scan recently. I didn't
notice the problem for a while because I
[EMAIL PROTECTED] wrote:
Neun Live, DSF, HOT, N24, VIVA. The recording with VDR gets lot of cTS2PES
errors and the recording is unusable. The systems with the rev 1.6 cards
records the same recordings at the same time without any problems. I think
that has something to do with the DVB driver and
Werner wrote:
> Hmmm ... at least I've tried the last patch of Jon (AFAIK it is now
> part of the current driver)
Yes, the changes have been merged into both DVB and dvb-kernel
> the bitstreamout plugin of VDR has seen a lot of duped TS frames.
> OK the plugin does not check about duped TS frames
John Pullan wrote:
I went with Petri's solution (delete compat.h) for now and it seems to
work. I'll do the job properly once I've got access to a fat pipe.
(Can't face downloading the kernel source over a modem)
You can get the pristine kernel.org source by installing the
kernel-.src.rpm package
Johannes Stezenbach wrote:
Recent scan uses INVERSION_OFF if the frontend driver says it
cannot do INVERSION_AUTO. It does not yet emulate AUTO by trying
both OFF and ON.
Ubfortunately the tda1004x driver says it can do auto inversion, but
rejects it when it is requested. If it didn't claim to su
The scan application doesn't want to work for me on Linux-2.6.0-test5.
When I run the dvb-kernel drivers on linux-2.4 it works OK.
I think i've tracked the problem down to the CRC check which occurs when
DMX_CHECK_CRC is selected by scan. Removing the flag in the scan code
makes it work OK.
I
The patch attached adds a couple of debug lines to say:
- What module has been registered for locking
- Each time the module gets locked and unlocked.
This works fine for me on linux-2.6.0-test5. I'm fairly sure it worked a
couple of days ago when I tested it on 2.4 as well.
Here is a log from me
Johannes Stezenbach wrote:
I just gave it a try with 2.4 and it didn't work. I was able
to unload dvb-ttpci while szap was running, resulting in an
Oops when I interrupted szap.
I did testing on both 2.4 and 2.6 with two budget Nova-T cards. I'm sure
I tried doing the same thing with tzap and it
The patch attached (for dvb-kernel only) causes the module use count to
be automatically incremented when any of the frontend, demux, etc
devices are openned.
When the device is closed the count decremented so the module can be
safely removed. I have only done a patch for the dvb-kernel driver.
Attached are two patches which tweak the handling of the INVERSION_AUTO
by the grundig_29504-401 and tda1004x frontends.
When reading through the grundig datasheet some time ago I noticed that
the driver already enables the "automatic TPS update" feature of the
frontend. I believe that this fea
When tuning to a new channel the first couple of packets are often junk,
but most of the following 64kB of data in the DMA ring is actually OK.
The patch attached moves a check for the 0x47 TS packet sync byte from
the vpeirq DMA receive code into the lower demux layer (so it makes the
decision
While looking through the code which sets up the DD1_INIT register in
the dvb-kernel driver I noticed that one of the settings looks
inconsistent with the rest:
[ttpci]$ grep -r DD1_INIT *
av7110.c: saa7146_write(dev, DD1_INIT, 0x0200);
av7110.c: saa7146_write(dev, DD1_INIT, 0x02
Robert Schlabbach wrote:
the SAA7146A to force the toggling of the field. See the DD1_INIT register
Thanks for that, it looks like none of the current code enables either
of the FIDESA/B interrupt signals.
Jon
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-d
Robert Schlabbach wrote:
The hardware does not generate any VSYNC signals, and thus no frame
signals. To utilize the odd/even field DMA mechanism, you have to program
the SAA7146A to force the toggling of the field. See the DD1_INIT register
settings for details.
OK, I was under the impression fro
Dr. Werner Fink wrote:
Btw: Could it be that with this patch (DVB-fix3.patch) the TS frames
are doubled now[1]?
The driver could be picking up stale data from the previous buffer fill.
My experiments seem to indicate that on my cards the DMA pointer always
fills the buffer completely before wr
Last night I tried another approach to fixing the DMA issues. Instead of
dealing with the awkward transition between the odd and even fields in
the middle of the buffer, I just avoid the problem by using the whole
buffer for both fields. This works fine for me on both the DVB &
dvb-kernel drive
Robert Schlabbach wrote:
The odd/even trick makes the SAA7146A automatically switch between two
buffers. The ugly side of this is that you have to busy-wait for it to
really switch buffers and then _copy_ the data out of the DMA buffer.
Yep, I tried doing a busy wait before I came up with the solu
Holger Waechtler wrote:
why do you want to do PID filtering on the RPS? it's done in software in
the current Nova driver anyway...
I thought Robert was hinting that you could get the device to DMA the
data straight into an output buffer which then gets returned to
usermode, without needing to
Stefan Betermieux wrote:
I will investigate the IRQ issue this evening. I am pretty sure that your
patch is executed half of time, because I inserted a syslog message inside
your if statement and in a newly created else statement another message. They
alternated in the log most of the time, I a
Michael Loose wrote:
Can you push my dumb bonehead a bit further into the documents
direction? Seems i can't find anything about firmware for the tda1004x
Try DVB/driver/frontends/README.tda1004x
Jon
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
su
Andreas Vierengel wrote:
Am So, 2003-08-31 um 18.28 schrieb Jon Burgess:
the vga-chip seems to be on bus 0. only onboard ethernet is on bus 1
together with all external pci-cards. here is a lspci output. I don't
know very much about today's motherboard internals, but are these 2
Several people have sent me emails over the last few days which they've
intended to send to the list.
All the other mailing lists I receive add a "reply-to: [EMAIL PROTECTED]"
header to all emails they send out, thereby making the default replies
go to the list autopmatically.
Does anyone else
Edward Wildgoose wrote:
Sorry, wasn't deliberate. To be clear. It completely fixes the problem for
me with the dvb_kernel branch. However, with the DVB branch, it is vastly
better, but there is still severe corruption (ie no way tolerable).
I took a look at the DVB code and it looks like it doe
Ed Wildgoose wrote:
Unfortunately just like with the DVB driver patch, I can't seem to get
it to detect several keys such as the "red" key, and the bottom left
"prev track" key. Nothing comes back, and some basic hacking of the
driver tends to suggest that some of these keys must be being
transmi
Stefan Betermieux wrote:
Hi,
unfortunatly, the patch doesn't do the trick for me, I still have to use
another PCI burst mode. I have taken a look at your patch and I have noticed
that your workaround is executed every second call of vpeirq() on my system.
Is this a normal behaviour?
I don't th
Robert Schlabbach wrote:
I think the odd/even buffer are used to overcome a sensitive timing issue -
keep in mind that there is no such thing as a "vertical blanking" in a DVB
data stream. The only "breathing time" between two MPEG-2 transport packets
are those 16 bytes Reed-Solomon redundancy. Now
Michael Loose wrote:
Linux video capture interface: v1.00
DVB: registering new adapter (TT-Budget/WinTV-NOVA-T PCI).
PCI: Enabling device 02:0c.0 (0004 -> 0006)
PCI: Assigned IRQ 9 for device 02:0c.0
tda1004x: Detected Philips TDA10045H.
tda1004x: Detected Philips TDM1316L tuner.
DVB: registering
Andreas Vierengel wrote:
hi,
your patch doesn't work for me (P4-Celeron 2.4GHz, i845GE Chipset).
sorry !
However I tested all combinations of burst and treshold settings for
Video-DMA-Channel #3 in PCI_BT_V1. Results are below.
However I actually do get stream corruption on my Nexus-s as well, bu
Julian Tibble wrote:
Btw, I've heard of people using some program called "evtest", I don't
evtest.c can be got from the linuxconsole SF project CVS at the link below:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/linuxconsole/ruby/utils/evtest.c?rev=HEAD&content-type=text/plain
Jon
Ed Wildgoose wrote:
However, curiously enough I already had loaded the driver:
dvb-ttpci-budget-ci
Your card must be one of the ones already supported by the driver then,
the patch would do nothing new for you.
And this does in fact seem to be picking up my remote and there is a
/dev/input/event
Lauri Tischler wrote:
Where do you apply that to DVB cvs ?
I haven't tried the DVB driver. Try the patch attached, it is completely
untested, but it looks like the code in the DVB driver is similar enough
for it to work the same.
Jon
diff -Nurw DVB/driver/av7110/av7110.c DVB-cvs/driver/av7110
Julian Tibble wrote:
As far as I can tell, av7110_ir.c is part of the driver for "fully featured"
cards, and budget-ci.c is for cards with a common interface connection for
pay-per-view. Neither of these apply to me (as far as I know), so can
I use the remote control?
The budget-ci is actually fo
I think it is becoming very clear that the choice of PCI burst used by the
budget driver is inappropriate for many chipsets, including common stuff
like the i845, many via boards, and also the i865 (my Asus P4P800)
I think the problem is a hardware bug in the DMA engine, see the other
email I just
Here is a patch which completely fixes all the stream distortion
problems i've been seeing on my P4 system. This works without needing to
apply any of the proposed PCI tweaks.
After many hours of debugging last night, it looks like the corruption
is caused by a hardware bug in the DMA engine us
Klaus Schmidinger wrote:
whether the currently displayed video on the DVB card is in PAL or NTSC mode.
Is there a way to get this information from the DVB driver?
I don't know about the full featured DVB code, but i'm fairly sure that
the dxr3device object in the vdr-dxr3 plugin keeps a record wh
I don't have any experience with DVB packets, but if it looks anything
like an multicast Ethernet frame then it should be:
MAC addresses are 6 bytes (48 bits)
For an IP multicast packet the multicast DA should be
01 00 5e xx xx xx
Where "xx xx xx" mapped from the least significat 3 bytes of
[EMAIL PROTECTED] wrote:
1) Has anyone built a VDR using RedHat 9?
To make VDR work on RH9 you need to follow the instructions regarding
NPTL as per the VDR INSTALL file. You need to set LD_ASSUME_KERNEL
variable to disable NPTL otherwise it breaks the VDR thread code.
Jon
--
Info:
To
Edward Wildgoose wrote:
io_ctl: SET_FRONTEND: invalid parameter
I had this at one time with my budget card.
It was caused by the channels.config having "INVERSION_AUTO" set, but
the frontend on the card doesn't supprt the auto inversion. Hence it
returns the error. Try changing this to INVERSION_
bigg wrote:
insmod), then I tried to run the scan utility, it would fail to find any
channels. However, if I first ran vdr and selected a channel on the
terrestrial card, then killed vdr (presumably simply tuning to a frequency
would also have worked), that the scan app could quite happily find al
Phil Space wrote:
There's definitely nothing wrong with the card (a
Hauppauge WinTV Nova-T) or aerial setup - it works
...
dvb-ttpci.o: init_module: No such device
The Nova-T card requires the "dvb-ttpci-budget.o" module
instead of the dvb-ttpci one.
Jon
--
Info:
To unsubscribe send a mail t
Robert Schlabbach wrote:
While we're at it, does anyone know what the "TMS320AV7200" is? I found
The TMS320 range is a very large series of chip based around a DSP core.
I think this is the number one line of CPU's made by TI.
The "AV" is presumably some variant which includes some audio/video b
This would really depend whether USB bandwidth is per direction or per total
of both. Not sure which it is, but I suspect total.
I'm fairly sure that USB is inherently half duplex at the hardware
level. There are 4 pins on the connector, 2 for power/gnd and a
differential pair for data.
I thi
David Mittelstädt wrote:
Thanks thats great, because i now have a stable picture but i wasnt able
to figure out how to switch between channels. Great work you did.
Try "h" & "k"
Jon
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
Nico wrote:
Feedback and suggestions are welcome.
I had to make a few tweaks to make it work for me. A patch is attached.
- Changes the frontend detection code to use the returned fe_info.type,
not the ioctl() return.
- When reading a terrestial channels.conf file it wasn't initialising
some
While inserting an removing the dvb-ttpci-budget module I noticed that
the module use count always stays at 0, even when the device is in use
by VDR. If I then try to remove the module then there is an oops when
what looks like the next IRQ is delivered from the hardware.
Surely the module use
Holger Waechtler wrote:
synchronized, I'll fix that. Can you please update your CVS and then
take the new grundig_29504-401.c as reference?
OK, I've been trying this out over the weekend and found that the chip
power control doesn't behave quite as you would expect. When the chip is
powered down
Holger Waechtler wrote:
Hi Jon,
that's illegal -- it would overwrite an attached EEPROM if we write
registers before we're sure that it's really a L64781. I just realized
OK, in understand. The trouble with this test is that the L64781 will
reponds after it is initialised. In fact the test a co
Holger Waechtler wrote:
Don't know if we should force the application to autoprobe the inversion
setting instead of implementing this in all drivers, in the ves1820 and
stv0299 driver there was a definite need to do it because there are
frontends out there with swapped I/Q pins where we simply d
Holger Waechtler wrote:
Could you please test his patch and report if it works flawlessly for
you? If so I'll commit it to the CVS source.
I tried his patch and it worked. I simplified it a bit more and this
works for me. See the patch attached.
Are the relevant datasheets available?
Yes, they'r
You could try booting Windows first then doing a warm restart into Linux.
Some of the kernel options which effect the PCI bus, for example try
adding "pci=nobios" to the kernel commandline
Alternatively, try using a kernel with ACPI enabled, this has its own
mechanisms for interacting with har
I noticed that if I remove and re-insert the grundig tuner and
dvb-ttpci-budget modules then the tuner module doesn't recognise the
hardware.
I tracked this down to two of the initialisation sanity checks failing
during the re-insertion. I have disabled these using the patch attached
and it wo
Holger Waechtler wrote:
I'm not sure about this. For the inversion setting this approach works
well, but would basically we need something similiar for all _AUTO
parameters if we want to provide a consistent API...
And probing all parameters can get pretty expensive.
I agree, it doesn't scale w
Andreas Oberritter wrote:
I think every application should check the capabilites (that's what they
are good for, aren't they?). But you should then - in case of no lock -
retry with inversion on.
I agree, but what we should try to avoid is that similar code ends up in
three different places: the
- The grundig_29504-401 apply_frontend_param() aborts and returns
"-EINVAL" if the application tries to set INVERSION_AUTO, but the
ioctl code which calls this function just ignores the return code.
A single line change fixes this.
Jon
Index: grundig_29504-401.c
I have attached two small patches to the scan application, the first
(scan-check-fe.diff) adds a check to report an error if there was a
problem setting the frontend parameters.
The second patch (scan-fallback.diff) queries the frontend capabilities
before trying to use "INVERSION_AUTO". I agre
The latest scan code defaults to using the "INVERSION_AUTO" parameter of
the frontend. Unfortunately this breaks my Nova-T card since the grundig
401 frontend does not support this mode.
This reveals a couple of problems:
- The scan and vdr-1.2.0 applications both ignore the frontend flag for
"
This patch fixes support for the various _AUTO frontend parameters to
the scan VDR output format. VDR uses "999" to indicate the automatic
mode for each parameter.
Please note that the INVERSION_AUTO (set by default in the recent scan
code) breaks my DVB-T grundig-401 tuner, which will be the s
96 matches
Mail list logo
