Re: [linux-dvb] Locking problem in dvb_demux?
On Wed, Jan 23, 2008 at 10:46:30AM +0100, [EMAIL PROTECTED] wrote:
>
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547515]
> =
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547519] [ INFO: inconsistent lock
> state ]
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547521] 2.6.23.14 #5
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547523]
> -
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547525] inconsistent {softirq-on-W}
> -> {in-softirq-W} usage.
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547527] startup1.pl/13742
> [HC0[0]:SC1[1]:HE1:SE0] takes:
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547532] (&dvbdemux->lock){-+..}, at:
> [] dvb_dmx_swfilter_packets+0x1f/0x49 [dvb_core]
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547590] {softirq-on-W} state was
> registered at:
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547598] []
> __lock_acquire+0x4aa/0xc1a
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547615] []
> lock_acquire+0x7a/0x94
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547682] []
> _spin_lock+0x2e/0x58
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547712] []
> dvb_dmx_swfilter+0x21/0x104 [dvb_core]
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547737] []
> videobuf_dvb_thread+0x83/0x105 [video_buf_dvb]
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547752] []
> kthread+0x3b/0x63
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547804] []
> kernel_thread_helper+0x7/0x10
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547874] [] 0x
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547888] irq event stamp: 22178648
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547889] hardirqs last enabled at
> (22178648): [] tasklet_action+0x26/0xa8
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547893] hardirqs last disabled at
> (22178647): [] tasklet_action+0xb/0xa8
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547896] softirqs last enabled at
> (22178536): [] __do_softirq+0xe3/0xe9
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547899] softirqs last disabled at
> (22178645): [] do_softirq+0x61/0xc7
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547903]
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547903] other info that might help
> us debug this:
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547904] no locks held by
> startup1.pl/13742.
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547906]
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547906] stack backtrace:
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547908] []
> show_trace_log_lvl+0x1a/0x2f
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547911] []
> show_trace+0x12/0x14
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547914] []
> dump_stack+0x16/0x18
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547916] []
> print_usage_bug+0x140/0x14a
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547919] []
> mark_lock+0x12e/0x45b
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547921] []
> __lock_acquire+0x43a/0xc1a
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547923] []
> lock_acquire+0x7a/0x94
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547926] []
> _spin_lock+0x2e/0x58
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547928] []
> dvb_dmx_swfilter_packets+0x1f/0x49 [dvb_core]
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547937] []
> vpeirq+0xc0/0x130 [budget_core]
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547941] []
> tasklet_action+0x53/0xa8
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547943] []
> __do_softirq+0x6f/0xe9
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547946] []
> do_softirq+0x61/0xc7
> Jan 22 11:00:17 TEMERAIRE kernel: [ 218.547948] ===
> Jan 22 11:00:18 TEMERAIRE kernel: [ 219.745305] saa7146_i2c_writeout: timed
> out waiting for end of xfer
...
> Now, I am interpreting this as saying that the demux->lock used in
> dvb_dxm_swfilter and dvb_dmx_swfilter_packets has become inconsistent.
> I think this has happened because one of the locks was taken from a
> soft IRQ.
>
> Changing the spinlocks to spin_lock_irqsave/restore on that lock
> object in dvb_demux.c has stopped that error message.
I think the lockdep warning is bogus.
Disabling interrupts for extended periods of time
would cause latency problems for the rest of the
system, so spin_lock_irqsave is the wrong solution.
The problem is you have two different cards, one calling
dvb_dmx_swfilter from a kthread, and one calling it
from a softirq. But each card has its own demux->lock,
and the usage of these locks is consistent for each card.
dvb_dmx_swfilter was written to be used from hardirq
or softirq context. If it is called from a kernel thread,
the use of a spinlock is somewhat inappropriate.
Maybe you should talk to the lockdep guys to find out
what to do about this warning. Maybe a version of dvb_dmx_swfilter()
which uses demux->mutex for use by kthreads, and then
use this in videobuf-dvb.c, would solve it?
HTH,
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Mon, Nov 05, 2007, Johannes Stezenbach wrote:
>
> Of course you can have variable length args to ioctl(). It's
> just that you can't let dvb_usercopy() do the work anymore but
> have to call copy_from_user() yourself, but I would favor a simple,
> generic API anytime over one with unnecessary, arbitrary
> limits, so IMHO it's worth the little extra effort.
>
> #define DVB_TUNE _IOC(_IOC_WRITE,'o',82,0)
>
> plus
Here's a better patch, still untested but without
obvious bugs, I hope ;-) :
diff -r 1acfe4149714 linux/drivers/media/dvb/dvb-core/dvbdev.c
--- a/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 10:30:39 2007 -0200
+++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 18:41:43 2007 +0100
@@ -362,9 +362,11 @@ int dvb_usercopy(struct inode *inode, st
case _IOC_READ: /* some v4l ioctls are marked wrong ... */
case _IOC_WRITE:
case (_IOC_WRITE | _IOC_READ):
- if (_IOC_SIZE(cmd) <= sizeof(sbuf)) {
+ if (_IOC_SIZE(cmd) == 0)
+ parg = arg;
+ else if (_IOC_SIZE(cmd) <= sizeof(sbuf))
parg = sbuf;
- } else {
+ else {
/* too big to allocate from stack */
mbuf = kmalloc(_IOC_SIZE(cmd),GFP_KERNEL);
if (NULL == mbuf)
@@ -373,7 +375,7 @@ int dvb_usercopy(struct inode *inode, st
}
err = -EFAULT;
- if (copy_from_user(parg, (void __user *)arg, _IOC_SIZE(cmd)))
+ if (_IOC_SIZE(cmd) && copy_from_user(parg, (void __user *)arg,
_IOC_SIZE(cmd)))
goto out;
break;
}
@@ -390,7 +392,7 @@ int dvb_usercopy(struct inode *inode, st
{
case _IOC_READ:
case (_IOC_WRITE | _IOC_READ):
- if (copy_to_user((void __user *)arg, parg, _IOC_SIZE(cmd)))
+ if (_IOC_SIZE(cmd) && copy_to_user((void __user *)arg, parg,
_IOC_SIZE(cmd)))
err = -EFAULT;
break;
}
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Mon, Nov 05, 2007, Steven Toth wrote:
> Johannes Stezenbach wrote:
>>
>> struct dvb_tuning_param p[3] = {
>> { .id = MODULATION, .val = MOD_8VSB },
>> { .id = FREQUENCY, .val = 59125 },
>> { .id = 0 }
>> };
>> ioctl(fd, DVB_TUNE, p);
>
>
> You can't reliably pass in variably length arrays into the kernel, or none
> of the other kernel wide drivers do, they need to be fixed length for
> sanity reasons.
Of course you can have variable length args to ioctl(). It's
just that you can't let dvb_usercopy() do the work anymore but
have to call copy_from_user() yourself, but I would favor a simple,
generic API anytime over one with unnecessary, arbitrary
limits, so IMHO it's worth the little extra effort.
#define DVB_TUNE _IOC(_IOC_WRITE,'o',82,0)
plus
diff -r 1acfe4149714 linux/drivers/media/dvb/dvb-core/dvbdev.c
--- a/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 10:30:39 2007 -0200
+++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 18:23:41 2007 +0100
@@ -362,9 +362,11 @@ int dvb_usercopy(struct inode *inode, st
case _IOC_READ: /* some v4l ioctls are marked wrong ... */
case _IOC_WRITE:
case (_IOC_WRITE | _IOC_READ):
- if (_IOC_SIZE(cmd) <= sizeof(sbuf)) {
+ if (_IOC_SIZE(cmd) == 0)
+ parg = arg;
+ else if (_IOC_SIZE(cmd) <= sizeof(sbuf))
parg = sbuf;
- } else {
+ else {
/* too big to allocate from stack */
mbuf = kmalloc(_IOC_SIZE(cmd),GFP_KERNEL);
if (NULL == mbuf)
(untested)
(BTW, the majority of ioctls don't encode the argument size, this
feature was invented just a few years ago; see man ioctl_list)
Or you could encode the lenght seperately like e.g.
I2C_RDWR does with its struct i2c_rdwr_ioctl_data argument.
It's a matter of taste, not sanity or security.
> 1) I've made minor changes to dvb_core to interpret these messages and
> handle the ioctl. No changes have been made to the frontend drivers.
>
> 2) Adding support for s2 _inside_ the kernel will mean adding a single
> method to dvb_frontend_ops which allows the dvb_core to notify a new S2
> driver. The goal here is to minimize these changes also. I haven't
> demonstrated that code here, becuse I felt it was more important to show
> the impact to the userland API/ABI, knowing that DVB-S2 and other advanced
> types (including analog) would naturally fit well within this model.
>
> 3) This applies to all devs. I welcome all feedback, for sure the sytax
> might need some cleanup, but please don't shoot the idea down when it's
> only had 6-8 hours work of engineering behind it. It's proof of concept. It
> doesn't contain any of Manu's code so I don't feel bound politically or
> technically. I think given another 4-5 hours I could show the HVR4000
> working, and demonstrate many of the userland signal/statistic API's.
>
> At this stage I'm looking for a "Yes, in principle we like the idea, but
> show me how you do feature XYZ" from other devs. At which point I'll flush
> out more code this would probably lead to an RFC for your approval.
Seems like no one is interested.
BTW, since every DVB-S2 demod is also a DVB-S demod, why does
no one split the DVB-S parts of their driver for merging
first? It would make the users happy as it would change the
state from "card not supported" to "card works for 95% of existing
transponders". (Dunno how this fits into this thread but...)
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Sat, Nov 03, 2007, Manu Abraham wrote: > > Also, i forgot to mention one more thing, 16APSK is denoted as > 4 + 12 APSK, (for the demod) not sure why either. See 5.4.3 Bit mapping into 16APSK constellation. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Sat, Nov 03, 2007, Manu Abraham wrote: > > If you see H.2 and H.3, the difference is between CCM and VCM > (Note: that both are cases of multiple "TS's") > > H.2 (CCM) is applicable for DVB-T muxes. Here there is a HP/LP > stream selection in some fashion combined with the merger/slicer > where stream id is used. What makes you think there is HP/LP involved? All H.2 says is that two DVB-T streams are transmitted using one DVB-S2 transponder to a DVB-T transmitter. The DVB-T transmitter could then transmit them on two different frequencies in non-hierarchical mode. (Indeed H.2 says "two DTT MUXes at 24 Mbit/s each" indicating they are not hierarchical because you can't get that bitrate in DVB-T hierarchical mode. But even if it were DVB-T hierarchical mode it has nothing to do with DVB-S2 backwards compatible mode hierarchical modulation.) > It is a combination of both, rather than a simple stream id. > (In this case Rolloff=0.20, Pilots do not exist) in this case the > QPSK stream is with FEC 5/6 > > H.3 (VCM) is applicable for a HDTV/SDTV mux. here it is quite similar > to H.2 exception that (In this case Rolloff=0.25, Pilots do exist) > in this case the QPSK stream is with FEC 3/4 and the 16APSK stream > is with FEC 3/4 > > H.2 is playing with the DVB-S signal level (saturating a transponder) > where as H.3 is using differential protection. It is not very clear how > both of these are distinguished from each other. The thing is that you don't need to distinguish them in the demod API at all. DVB-S2 allows changing modulation parameters with every PLFRAME (for VCM), and the only way this can work is if the demod can figure them out by itself. This works because the PLHEADER is sent with a fixed coding and modulation which is independent from the rest of the PLFRAME. That's why you don't have to worry about the details of the transmission parameters, and why they don't exist in the EN 300 468 S2 satellite delivery system descriptor. (Those details are interesting for the broadcaster, of course, who needs to optimize throughput vs. receiption performance.) > Also, on the demod other than the MIS flag (according to the specs) > there is another bitfield to select the HP/LP stream, which makes it a > bit even more confusing. There exists some clarity, but again there are > some clouds which hinder how it looks. > > I am not really very clear on handling this. We will get more clarifications > the coming days. HP/LP is only used for backwards compatible (to DVB-S) mode, as one of two options. A DVB-S receiver will only see the HP stream, the DVB-S2 signal will appear as additional noise to it. OTOH a DVB-S2 receiver can choose between HP and LP. I don't know how this is implemented in DVB-S2 demods, it could be a selection bit in a register, or the demod could output the LP stream in DVB-S2 mode and the HP stream in DVB-S mode. That's how I think it works. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Sat, Nov 03, 2007, Manu Abraham wrote: > > When Johannes stated: handling multiple streams is as simple as setting > a stream id, well it is not that i blame him, the specs look that way. There > are couple of ways the same thing is done for example. You apply a > wrong one and the API is screwed and you have to bear that brunt for > a long time to come. Hey, if you know more than I do then please explain it to me. Until proven wrong I continue to believe that there isn't any more magic to handling multi stream mode than choosing one of them by writing the stream id into the appropriate demod register. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Fri, Nov 02, 2007, Steven Toth wrote:
>
> The design goals for me are:
>
> 1) We stop trying to predict what the API will need in 5 years, and focus
> on building a very simplistic ioctl API for getting and setting generic
> frontend properties, it should be basic enough to deal with any new
> modulation type (or advanced tuner) that we know of today.
good one
> 2) We change the tuning mechanism from being (mostly) atomic (SET_FRONTEND)
> to a looser command/sequence definition. (Thereby stepping away from fixed
> structs that define the ABI). With two new ioctls
> (get_property/set_property) and a simple property struct which specifies
> how generic types are passed to/from the kernel.
no so good
> 3) A userland library _may_ offer a number of helper functions to simplify
> in terms of applications development, turning this:
many people seem to hate ALSA, there's a lesson to be learned here
> command.id = BEGIN_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>
> command.id = SET_MODULATION
> command.arg = 8VSB
> ioctl(SET_PROPERTY, &command);
>
> command.id = SET_FREQUENCY
> command.arg = 59125
> ioctl(SET_PROPERTY, &command);
>
> command.id = VALIDATE_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>
> command.id = END_TRANSACTION
> ioctl(SET_PROPERTY, &command);
>
> Into a more human readable form like this:
>
> int tune_8vsb(frequency);
>
> It's a basic approach, we trade off multiple ioctls (at a very low rate)
> entering the kernel, for a very flexible tuning approach to frontend
> control.
Once you have those tag/value pairs, you could batch them
together in an array and pass them down in one ioctl. This
avoids the ugly transaction stuff and keeps it atomic.
And I think it wouldn't look too ugly in user code, e.g.:
struct dvb_tuning_param p[3] = {
{ .id = MODULATION, .val = MOD_8VSB },
{ .id = FREQUENCY, .val = 59125 },
{ .id = 0 }
};
ioctl(fd, DVB_TUNE, p);
But there's more work to do:
- need for .val being variable lenght or a union of different types?
- extend existing enums or define new ones for MODULATION etc?
- how to do FE_GET_FRONTEND
- etc.
I'm sure we could have endless debates over the details ;-)
I hope many others will comment which approach they like better,
or which one they think will be ready for prime time sooner.
Personally I don't care either way. I spent a lot of time discussing
the "multiproto" API and I believe it could be ready soon with
a few minor tweaks. OTOH this tag/value approach seems to be
more flexible, but who knows how much work it'll take to complete.
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] linuxtv.org fell in the blacklists trap
On Fri, Nov 02, 2007, Luca Olivetti wrote: > En/na Johannes Stezenbach ha escrit: >> On Tue, Oct 30, 2007, Luca Olivetti wrote: >>> El Tue, 30 Oct 2007 18:41:27 +0100 >>> >>>> is the first complaint since I switched to safe.dnsbl.sorbs.net >>>> about one year ago) >>> It doesn't surprise me, since those affected cannot contact you. It's >>> the perfect system to avoid complaints ;-) >> Bullshit. Just a suggestion: If you run your own mailserver >> you should probably read RFC 2821. > > Frankly, I didn't check if linuxtv.org follows rfc2821 (and now that I'm > delisted I cannot check), however most of the sites that blindly rely on > flawed blacklists don't usually honour rfc2821 either (I suppose you refer > to section 4.5.1). Yes. >> Or failing that, you could just ask someone else to >> forward a message for you, or ask Mauro or >> one of the other developers for help. > > Yes, there are workarounds for linuxtv.org. In other cases it may not be so > simple to contact the administrador (see above). And, again, I shouldn't go > through all this hassle: I did nothing wrong. Fighting spam is always a matter of effort. I didn't do the current setup (Ralf H. did), but I had to choose some replacement DNSBLs because those which were used originally went out of existance. Maybe there's a better replacement for safe.dnsbl.sorbs.net, I'll try to look into it at the weekend. But I don't have the time to change the whole setup now, and just installing spamd won't cut it as this thing eats too much CPU with the amount of spam that hits linuxtv.org. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Hi Steve, On Wed, Oct 31, 2007, Steven Toth wrote: > > You've miss-interpreted my comments. > > I suggested that the API should be defined, but not necessarily > implemented. I was suggesting that we define enough API to generate a > test tree and make some progress. Supporting your earlier statement, I > suggested that the small amount of unimplemented API (which you > suggested was inconsequential) could be implemented while other > developers were testing the core TV functionality. ... > I'm wasting my time here. I was hoping you would outline how you would like to proceed. Instead you ask Manu for his plans and then declare "I don't like it" -- IMHO that's a bit lame. May I suggest that you create a new tree which uses just the bits from Manu's tree which you intend to reuse (of course keeping copyright/authorship attribution intact), and rebase your HVR4000 on top of it? IMHO the userspace-visible API (i.e. the changes to include/linux/dvb/frontend.h only) was discussed extensively, and while there still are a few missing pieces I don't see the need to restart from scratch. I know that e.g. Felix Domke mentioned he'd prefer a more minimalistic frontend.h API change. Personally I wouldn't mind but I think the time to bang out a complete proposal, and discuss it and find supporters for it will take longer than just going with what we have now in Manu's tree. I haven't looked at Manu's dvb-core changes yet. Currently it is also not clear to me if your problem is with the code or just with the fact that Manu owns the code and you can't go forward without him. But the latter is what I tried to address with my proposal to create a repository which splits API/dvb-core changes from the STB0899 driver. Please outline what your actual problem is, maybe then I can help to resolve it. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] linuxtv.org fell in the blacklists trap
On Tue, Oct 30, 2007, Luca Olivetti wrote: > El Tue, 30 Oct 2007 18:41:27 +0100 > > > is the first complaint since I switched to safe.dnsbl.sorbs.net > > about one year ago) > > It doesn't surprise me, since those affected cannot contact you. It's > the perfect system to avoid complaints ;-) Bullshit. Just a suggestion: If you run your own mailserver you should probably read RFC 2821. Or failing that, you could just ask someone else to forward a message for you, or ask Mauro or one of the other developers for help. > > it has very low priority for me, sorry. > > Well, I hope you reconsider. As I said I was wrongly listed. Twice. One > day the same could happen to you, then you'll understand. I've made that experience already. Today I entrust my private mail to a buddy who knows his job. But I think the key problem is that if you choose the wrong hoster for your server, you'll gonna have problems... Anyway, I freely admit that I'm rather lame as a mail server admin. Changing the spam filter setup is on my TODO list, but I'm not going to rush it, I need more time to do it than I have atm. I'll add your IP address to the whitelist, though. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] linuxtv.org fell in the blacklists trap
On Tue, Oct 30, 2007, Luca Olivetti wrote: > > In a misguided attempt to curb spam, someone at linuxtv.org decided to > use the sorbs blacklist. ... > If you decide to go on relying on blacklists, at least use the one > listing confirmed sources of spam, not the broader one using arbitrary > and flawed criteria (like all supposedly dynamic/residential/adsl > addresses, or all the ip from china, etc.). We use safe.dnsbl.sorbs.net already. I've always wanted to upgrade the spam filtering to something better, smarter, but since the current setup works fairly well (your's is the first complaint since I switched to safe.dnsbl.sorbs.net about one year ago) it has very low priority for me, sorry. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Hi, On Tue, Oct 30, 2007, Manu Abraham wrote: > Johannes Stezenbach wrote: > > > > three weeks have passed since Steve expressed his > > discomfort with the HVR4000 merge being blocked > > waiting for multiproto. > > Before i state anything, Current DVB-S2 API status: [snip] Thanks, that's useful. > > Can you give us a time frame for when the multiproto > > merge will happen? > > > > Or, alternatively, can we split multiproto into > > two repositories, one with API + dvb-core changes > > and one (on top of it) with the STB0899 driver? > > It can be either way, which one of the following do you think is better in > your view ? > > (1) DVB-S2 API partly merged now and the rest of the S2 API later. > (2) Complete event list update and VCM and merge that also alongwith. > > in either case it can be with or without the STB0899 driver. > > What do you think ? I'd prefer to address the remaining API issues first, however what I primarily want to avoid is that Steve rewrites the HVR4000 driver to a competing API proposal due to frustration with the lack of progress. IMHO there should be a clear path of actions for Steve (or whoever else wants to help) to do that would allow merging the HVR4000 driver. I.e. instead of having to wait for some event beyond his control there should be a checklist, and the merge can happen when all items are resolved. Or something like that. Preferably Steve would comment how he'd like to go forward. Thanks, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DVB-S2 API vs. HVR4000: When?
Hi Manu, three weeks have passed since Steve expressed his discomfort with the HVR4000 merge being blocked waiting for multiproto. Can you give us a time frame for when the multiproto merge will happen? Or, alternatively, can we split multiproto into two repositories, one with API + dvb-core changes and one (on top of it) with the STB0899 driver? So that Steve can rebase his HVR4000 driver against current API + dvb-core changes and get it merged ASAP. Greetings, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 Multiple logical TS on the same frequency
On Mon, Oct 15, 2007, Manu Abraham wrote: > Johannes Stezenbach wrote: > > > > I'm very confident the output of the demod is a single TS in all > > cases, and this has nothing to do with the demux. > > Maybe, not very sure on that. Also the specifications additionally adds this: > > 5.2 SDTV and HDTV broadcasting with differentiated channel protection > > The DVB-S2 system may deliver broadcasting services over multiple Transport > Streams, > providing differentiated error protection per multiplex (VCM mode) (see > note). A typical > application is broadcasting of a highly protected multiplex for SDTV, and of > a less > protected multiplex for HDTV. Figure 17 shows an example configuration at the > transmitting > side. Assuming to transmit 27,5 Mbaud and to use 8PSK 3/4 and QPSK 2/3, 40 > Mbit/s > would be available for two HDTV programmes and 12 Mbit/s for two-three SDTV > programmes. That doesn't contradict what I said at all. E.g. the HDTV TS is packaged with ISI 0x23 and the SDTV has ISI 0x42. The ISI for each TS is in the EN 300 468 S2 delivery desc. When receiption conditions are good you can receive both TSs, when they are bad you can only receive the SDTV TS (the HDTV one will have too many errors). In all cases the output of the demod is a single TS. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 Multiple logical TS on the same frequency
On Sun, Oct 14, 2007, Manu Abraham wrote: > > You can have MIS in 2 cases again: > > 1) Transport Streams > > a) When it is SIS, it is similar to our normal DVB-S transmissions > b) When it is flagged MIS in the Baseband Header, we have Multiple Streams. > When it is MIS, if the logical streams are scrambled, we will need to > route the relevant > stream to the CA module, which means we have some additional job at the > demuxer level. > (this will be a bit of headache, coupled with a CA device) > > 2) Generic Streams (note this need not be a MPEG2 stream at all) > This at least we can pipe everything to userspace at least as a last > resort. > > Temporarily, we do not need to worry about Generic streams (Single or > Multiple), since they > aren't basically used in the broadcast profiles, _but_ MTS might be. ACK -- see old posting: http://article.gmane.org/gmane.linux.drivers.dvb/26040 However, contrary to what is written there I believe the demod recognizes SIS vs. MIS and dis/enables the stream filter automatically. I guess if you fail to set the correct ISI for MIS, you get no output (or the wrong one). For SIS the stream id filter is irrelevant, you can set it to any value. IMHO all you need is to add an u8 input_stream_identifier to struct dvbs2_params. You take the value and write it in a demod register -- done. You can get the input_stream_identifier (ISI) from the S2 satellite delivery system descriptor, see EN 300 468. (In the worst case the demod wouldn't en/disable the stream id filter automatically, so you'd need to read SIS/MIS flags from a register after tuning and do it manually -- but that's all internal to the driver and not in the API. I think.) (BTW, ARIB has a similar feature, transport_stream_id, see http://linuxtv.org/cgi-bin/viewcvs.cgi/dvb-kernel-v4/linux/include/linux/dvb/frontend.h?rev=1.20.2.2&only_with_tag=ARIB_extension&view=auto ) I'm very confident the output of the demod is a single TS in all cases, and this has nothing to do with the demux. Regards, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Hi, On Fri, Oct 12, 2007, Marcel Siegert wrote: > > can everybody _please_ stop this unnessessary discussion? When a developer deletes his mercurial repositories and announces he's going to rewrite the code to be independent of multiproto, then IMHO it is _necessary_ to find out why, and how to continue now. I have a vague idea about the state of multiproto now, but now I'm waiting for Steve to comment if he's happy if multiproto would be merged _now_, or if he wants to do something else, and explain what. Anyway, the decisions to make are not mine, I'm just trying to extract the information needed so all the cards are on the table for everyone to see easily. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
On Fri, Oct 12, 2007 at 11:56:21AM +0400, Manu Abraham wrote: > Johannes Stezenbach wrote: > > On Fri, Oct 12, 2007, Manu Abraham wrote: > >> Johannes Stezenbach wrote: > >>> Does that mean that Manu has no intentions to get > >>> his multiproto API changes merged? > >> It will be merged > > > > When? Why hasn't it been merged months ago when HVR4000 worked? > > HVR4000 was struggling even recently howto handle pilots, because it > had a hard time trying to figure out how pilots worked. Eventually, the > implementation from the STB0899 had to be copied to the same, for it > to work. The reason being CX24116 being mostly RE'd, AFAIH. Drivers will always have bugs, so what? The hg log suggests that the pilots should also be in the API, but Steve had to wait for you to deliver an updated API and thus fixed it internally. Within the scope of testing Steve could do the driver was presumably ready months ago -- I take Steve's word on this. > >>> (If so, then wtf was the point of doing them and keep > >>> everyone waiting? But I guess the "DVB API update" thread > >>> meant he isn't happy with it anymore.)) > >> As i wrote, there are more things in the S2 specification, also > >> currently stuff like proper statistics cannot be done for example > > > > As I tried to tell you in one of my replies in the "DVB API update" > > thread statistics is totally independent of DVB-S2. And the > > "more things" were not spelled out in detail by you -- and > > why don't you just fix the API if you know something is missing, > > instead of saying "something's missing, can't merge yet"? > > Please, Just look at the changesets for the same. I don't get it -- one mail you say something's missing, next mail you say already done. > > I just can't understand why you were dragging this out so long, > > usually I would expect the desire of any developer is to get > > the code merged ASAP. With a working HVR4000 driver you could've > > FYI, the STB0899 driver is much older than the HVR4000 driver, it has > been delayed because of > > 1) too much noise on the ML (you had bit much to do with it) > 2) The feedback that resulted from the discussions on the ML, were > not sufficient for a complete API, eventually STM chipped in, was a > lot of struggle at my side too. Ugh -- the monster thread in May 2006 got so large because _you_ didn't believe me when I said that his API doesn't match my understanding of the DVB-S2 spec, and you were unable to explain to me how it works. So we needed to go through the spec together trying to figure out how it works. In the end I concluded the only sane to proceed is to finish writing a driver to find out if the API _really_ works, and to fix any API bugs you'd might encounter during driver implementation. And now you acknowledge that this was right, and you even had to ask STM for help. So I really don't understand your repeated accusations that I create "too much noise" or "unneccessary discussions". > > got the API and dvb-core changes merged months ago -- which would've > > allowed you to merge the STB0899 driver in CONFIG_EXPERIMENTAL > > status to expose it to a wider audience if you'd wanted to. > > Your earlier statements resulted thus: > > * go experimental > * no experimental > * go experimental > > Looks like some square wave function. Are harmonics expected ? Here's a little trick question for you: Does CONFIG_EXPERIMENTAL apply to APIs visible to userspace? > > Instead you seem to have the desire to work on your private branch > > forever, adding patch upon patch to make it as big and important > > as possible. > > Can you please point to the changesets which cause you to mention > "adding patch upon patch to make it as big and important as possible" ? > If you can't point that, it is fairly evident that you are blindly accusing > me > and thereby blurting nonsense and sparking politics. Just a few lines above you said: "As i wrote, there are more things in the S2 specification, also currently stuff like proper statistics cannot be done for example". And see the "DVB API update" thread. Now you play the "what I say is irrelevant, only changesets count" game, and hurl the P-word at me once more. Thanks. > > Any not caring at all that you block Steve's work > > as a consequence. > > hmm.. accusations again. ATM, Steve was/is prejudiced because of something > else. What? Please elaborate. > > I asked you for your plans in this thread but I didn
Re: [linux-dvb] Future of Multiproto
On Fri, Oct 12, 2007, Manu Abraham wrote: > Johannes Stezenbach wrote: > > > > Does that mean that Manu has no intentions to get > > his multiproto API changes merged? > > It will be merged When? Why hasn't it been merged months ago when HVR4000 worked? > > (If so, then wtf was the point of doing them and keep > > everyone waiting? But I guess the "DVB API update" thread > > meant he isn't happy with it anymore.)) > > As i wrote, there are more things in the S2 specification, also > currently stuff like proper statistics cannot be done for example As I tried to tell you in one of my replies in the "DVB API update" thread statistics is totally independent of DVB-S2. And the "more things" were not spelled out in detail by you -- and why don't you just fix the API if you know something is missing, instead of saying "something's missing, can't merge yet"? I just can't understand why you were dragging this out so long, usually I would expect the desire of any developer is to get the code merged ASAP. With a working HVR4000 driver you could've got the API and dvb-core changes merged months ago -- which would've allowed you to merge the STB0899 driver in CONFIG_EXPERIMENTAL status to expose it to a wider audience if you'd wanted to. Instead you seem to have the desire to work on your private branch forever, adding patch upon patch to make it as big and important as possible. Any not caring at all that you block Steve's work as a consequence. I asked you for your plans in this thread but I didn't get an answer. Anyway, I don't know what has been said on irc and I can't be bothered to read the irc logs. I really don't care if the DVB-S2 API is done one way or the other, if you can't cooperate with Steve then you have to compete with him. IMHO the first one to have a fully working API + driver ready for merging wins. That's what I vote for. The requirements to make it mergable are still the same as in Nov. 2005 when the DVB-S2 API was discussed first: - don't break backwards compat - add complete support for all DVB-S2 features, or at least allow missing features be added later in a backwards compatible way - don't be completely ugly (like the Reelbox hack) - don't repeat past mistakes and design it to allow easier backwards compatible extensions in the future (like e.g. for DVB-H) Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
On Thu, Oct 11, 2007, Steven Toth wrote: > > After a disappointing multiproto debate on IRC today I've decided to > remove the ~stoth/multiproto and ~stoth/HVR4000 trees from linuxtv.org. > I no longer support the multiproto patches and I'm seeking alternative > ways to deliver the HVR4000 S2 driver to the community. > > For the time being I am no longer taking emails for HVR4000 related > issues, please do not contact me directly about any HVR4000 related > source code. > > All HVR4000 source code I've previously released is licensed under GPL > and that does not change, you are welcome to use it within the terms of > the license. IRC... Does that mean that Manu has no intentions to get his multiproto API changes merged? (If so, then wtf was the point of doing them and keep everyone waiting? But I guess the "DVB API update" thread meant he isn't happy with it anymore.)) Prior to your involvement in this thread I wasn't aware that the HVR4000 driver was ready for _months_ and was just waiting for Manu. I can understand why your level of frustration is so high. But the whole thing is totally idiotic, because the deal after the giant multiproto discussions last year was to get *one* driver ready to prove the API works. If HVR4000 did that, then the whole thing should've been merged months ago. > A new driver will be published in the near future. Could you please outline what your plans are wrt the API? Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
On Sun, Oct 07, 2007, Artem Makhutov wrote: > > I am wondering about the future of the Multiproto API. me too -- thanks for asking > Will the Multiproto API be part of the upcoming DVB-API, is it just a > short time solution to make the DVB-S2 devices work or is Multiproto the > new DVB-API? For a long time I believed the API was basically agreed upon and Manu and IIRC Steve were implementing drivers. Once the drivers were ready (and thus proved the API works) the whole thing would've been merged. But I lost track of the "DVB API update" thread. Maybe Manu and Steve could fill us in what their conclusion of this thread was and what the plan is now. Thanks, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
On Sun, Sep 30, 2007, Manu Abraham wrote: > Johannes Stezenbach wrote: > > > > The actual drift is totally irrelevant for the zig-zag scan. > > Zig-zag is a trial-and-error approach, and only needs to know > > - the step size (derived from the demod's carrier capture range) > > - max. the number of steps (derived from channel bandwidth) > > - the time to wait between steps (derived from the demod's > > worst case time to lock on a signal) > > This is what i am doing in the STB0899 driver. You are preaching to the choir. Then why don't you use the dvb-core implementation instead of reimplementing it in the STB0899 driver? > But what you said initially is different from what you are saying now. How so? I just added more detail for clarification, it doesn't contradict what I said earlier. > This zigzag method what STM generally use is called Fs/2 zigzag. > ie the zigzag is based on the sampling frequency, > ie optimized for the sampling at the nyquist rate, since the most important > part in a demodulator is the ADC clock, to put it short. Which is just a more complicated wy of saying "derived from the demod's carrier capture range", right? > > Why do you still try to single out stv0299 when I told you > > that almost all existing DVB-S frontends use it? > > (cx24116 being the one exception, as Georg Acher informed me.) > > > Intel CE6313 is different, Fujitsu MB86A15/16 is different, CX24123 is > different, and many others > The dst based one's are different. You can probably find more examples if you try hard enough, but just grep the code for "get_tune_settings" to see the current state of affairs (note that dvb_frontend.c enables zig-zag using default values for frontends which don't implement get_tune_settings). > The CX24116 has it's roots from the CX24123 demod, just like how the STB0899 > has some roots > in the STV0299. > > The reason is that they do not simply zigzag. The MB86A15/6 from Fujitsu for > example sweeps > the spectrum, not zigzag's. Different methods, that's all > > I am not just stating something stupid, but referring quite a lot of > demodulator specifications. > Not just one STV0299 or CX24116 > > For a person writing a driver for the first time, that device always > different. > Look at XC3028 as an example > > So the only common one's are the one's from STM. I am not trying to single > out the STV0299, > but i was looking at why there is a drastic difference in LOCK/tune times > with the STB0899 and the > STV0299, while the STB0899 what i am using is in STV0299 tuning algorithm > compatible way. Well, there are serveral years of development between stv0299 and stb0899, one would hope they used the time to improve their algorithms. And the stb0899 runs at higher clock rates and has more processing power. And the tuner and the whole electrical design of the card matters, etc. pp. I haven't used SAT equipment for serveral years now, I don't remember the stv0299 based FF cards we had at convergence as being slow. What card do you use for comparison? Did you do timing measurements? > I hope i am not loosing you, in what i am trying to say. > > What i am stating is that, there is a derivative of a Fs/2 zigzag in > dvb_frontend, which is not a > Fs/2 zigzag even, such that it can be adapted for others. > > > >> Ok, now that i explained the test scenario, how would you prefer LNB drift > >> be provided > >> to the frontend ? > >> > >> The criteria would be thus, that the user be able to specify the drift for > >> his LNB, since > >> people have small LO drift values to large LO drift values. ie it is not > >> fixed as it is originally > >> thought to be. > >> > >> Do you think it would be the best if the user specifies the drift ? Or > >> maybe in a user > >> specific library, for example the lnb.c that one could be extended further. > >> > >> What's your opinion ? > > > > Most people have no idea what drift their LNB has, nor should they > > ever have to care about it. > > Hmm .. > > Then i guess the swzigzag for the STV0299 in dvb_frontend is a bit bogus > thing, > which has been forced for other devices where it is not even applicable. Sorry, I can't follow that conclusion. The guys who implemented dvb_frontend noticed that all the vendor's "tuning algorithm" flow charts looked similar, and factored out common code into dvb-core to simplify the individual demod drivers. There's certainly room to improve and extend dvb_frontend, but why are you opposed to keep common code which _works_ for a variety of frontends? Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
On Sun, Sep 30, 2007 at 03:11:39AM +0400, Manu Abraham wrote: > Johannes Stezenbach wrote: > > On Sat, Sep 29, 2007, Manu Abraham wrote: > >> ... > > > > Instead of losing myself in the details of your questions, > > some background info: > > > >> 1) LNB drift > > > > That said, since we have different LNB LO drifts and the frontend driver > doesn't know > what the actual drift the LO is having, but that only a standard (vague ?) > definition of > the drift, The actual drift is totally irrelevant for the zig-zag scan. Zig-zag is a trial-and-error approach, and only needs to know - the step size (derived from the demod's carrier capture range) - max. the number of steps (derived from channel bandwidth) - the time to wait between steps (derived from the demod's worst case time to lock on a signal) Got it _now_? > i would like to experiment a bit with the stb0899 with regards on the same. > Since the STB0899 doesn't use the swzigzag from dvb_frontend.c, it is much > easier to > do it in the stb0899 driver. dvb_frontend lacks a hook which would allow one to implement auto-offset correction for the TU1216 DVB-T demod (I mean the +/- n * 125kHz or +/- n * 166kHz offset from the frequency given in the NIT used by some transmitters to reduce interference with adjacent channels.) If what you add for stb0899 would be usable for tu1216 etc. it would be useful. You must not break the exisiting sw zig-zag though. > (This is supposing on the basis that we are not fiddling around with the > STV0299) Why do you still try to single out stv0299 when I told you that almost all existing DVB-S frontends use it? (cx24116 being the one exception, as Georg Acher informed me.) > Ok, now that i explained the test scenario, how would you prefer LNB drift be > provided > to the frontend ? > > The criteria would be thus, that the user be able to specify the drift for > his LNB, since > people have small LO drift values to large LO drift values. ie it is not > fixed as it is originally > thought to be. > > Do you think it would be the best if the user specifies the drift ? Or maybe > in a user > specific library, for example the lnb.c that one could be extended further. > > What's your opinion ? Most people have no idea what drift their LNB has, nor should they ever have to care about it. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
On Sun, Sep 30, 2007 at 06:48:31AM +0400, Manu Abraham wrote: > Manu Abraham wrote: > > Johannes Stezenbach wrote: > >> On Sat, Sep 29, 2007, Manu Abraham wrote: > >>> Johannes Stezenbach wrote: > >>>> - LNBs have a constant error plus a temperature drift > >>>> (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range > >>>> of -40 ... +60 °C -- cheap no name equipment usually worse) > >>> This is the old LNB, the one's we use are generally based on PLL's > >>> have some 15 - 20k drift > >> If you make that 20kHz per °K then it's about the usual range > >> for Ku Band, maybe slightly better than average. > >> (An LNB with +/-20KHz drift over the full temperature range > >> would be ridiculously expensive.) > > > > ACK > > > > didn't account for the / K. But still for a LNB with 27 K, It amounts to > > around +/- 0.5MHz > > Which is still quite small for a 5 - 10 MHz window. > > > > As you said, maybe there are really bad ones with +/-1MHz drift, but i think > > +/-3MHz is a bit too exaggerated figure > > > > > http://www.satcomresources.com/SatelliteLnbs.jsp > http://www.servsat.com/eng/htmls/lnb%20English.htm > > with Prices And compare to the prices here: http://www.hardwareschotte.de/preise.php3?seachrange=all&searchstring=lnb http://www.shoppingfever.de/product_info.php?products_id=271159&campaign=hardwareschotte This is starting to get silly... Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
On Sat, Sep 29, 2007, Manu Abraham wrote: > Johannes Stezenbach wrote: > > > > - LNBs have a constant error plus a temperature drift > > (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range > > of -40 ... +60 °C -- cheap no name equipment usually worse) > > This is the old LNB, the one's we use are generally based on PLL's > have some 15 - 20k drift If you make that 20kHz per °K then it's about the usual range for Ku Band, maybe slightly better than average. (An LNB with +/-20KHz drift over the full temperature range would be ridiculously expensive.) Don't forget that your tuner also has maybe +/-50ppm tolerance. The errors can add up. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
On Sat, Sep 29, 2007, Manu Abraham wrote: > ... Instead of losing myself in the details of your questions, some background info: > 1) LNB drift - LNBs have a constant error plus a temperature drift (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range of -40 ... +60 °C -- cheap no name equipment usually worse) - the demod can only compensate for a limited frequency offset (e.g. both stv0299 and stb0899 QPSK are specced to +/-5% fM_CLK for "Carrier loop capture range", where fM_CLK is typically 88MHz for stv0299 and 108MHz for stb0899, thus 4.4 MHz vs. 5.4 MHz. But note that this are best case figures which only hold with good CNR.) - if the LNB error + drift is higer than what the demod can capture, then tuning fails - _only when initial tuning fails_ does the sw zig-zag kick in, and it attempts to tune in increasing steps around the nominal frequency until the demod either locks on the signal, or the scanned frequency range covers the complete channel bandwidth (we want to avoid locking on the neighbour channel; note that adjacent channels on satellite use different polarization so we can't lock there unless we really stepped way too far) - the parameters for sw zig-zag are provided by the demod driver in struct dvb_frontend_tune_settings int min_delay_ms; // when to assume tuning failed -> do next step int step_size;// size of zig-zag step int max_drift;// when to stop zig-zagging a demod driver can disable sw zig-zag by setting step_size and max_drift to zero (which is what DVB-T and DVB-C drivers do) - sw zig-zag is by no means stv0299 specific and is used by (almost?) all DVB-S demod drivers The bottom line is that: 1. zig-zag doesn't slow down tuning, because it only ever kicks in when the initial tuning attempt failed (however, it is possible that a driver sets min_delay_ms too small, then zig-zag kicks in too soon and ruins your day) 2. zig-zag tries harder to tune, and makes users happy, even if tuning might take some time; without zig-zag, all you can do is tell your user "sorry, no signal found" 3. once zig-zag succeeded, the offset (drift compensation) is stored and reused at the next channel switch -- thus not every tuning is slowed down even if there is a large offset 4. zig-zag could also be implemented in user space, but IMHO it's better the way it is now -- since some hw doesn't heed sw zig-zag, and the ones that need it need different parameters IIRC Andrew de Quincey spent significant time optimizing the zig-zag code and the parameters for various frontends. > 2) Inversion AUTO In the old days there were literally two wires with the I and Q signals running from the baseband processor to the QPSK modulator. It probably was a common mistake that someone messed up the wiring at the broadcaster. Nowadays the equipment is integrated and the inversion setting is just a check box in the control software. Still broadcasters seem to set it at random. Like Felix explained, at the receiver side you don't know if the spectrum is inverted. If the demod firmware doesn't handle it, you have to try both inversion settings in sw. And like with zig-zag, you could do it in userspace but IMHO it's better to let the core handle it. Apps which want to optimize tuning performance could use FE_GET_FRONTEND after successful tuning to get the real inversion setting, and use that instead of AUTO. The reason why scan/szap don't do this is that a) not all drivers get it right, and b) for DVB-C and DVB-S inversion settings can be regionally different -- we don't want channel lists which only work with some cards in some regions. HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote: > Johannes Stezenbach wrote: > > >> If you would like to fix that in V3, i would much appreciate. If you > >> would just like to keep talking only, maybe lets then not talk too much > >> about it. > > > > The recording filters are exactly the piece from V4 which has the > > "mmap DMA buffers" zero copy API. But to be honest, I don't think > > it's important on a PC which can copy > 1GByte/s in RAM. More > > interesting would be the ability to have multiple independant filtered > > TS outputs instead of just one dvr device. > > Currently have you tried playing back a High Bit rate H.264 stream > default of a DVB-S2 stream ? I guess not. > > If you have had, you will see my reasons why i am trying to optimize the > overheads. > BTW: it is not RAM that matters here, but CPU horsepower A demux doesn't decode, and what matters is memory bandwidth. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
On Tue, Sep 18, 2007, Manu Abraham wrote: > > Of course linuxtv.org being your private server (which you indirectly > said in one of the mails) doesn't mean that you can just talk whatever > you want ??? > I do feel so upset talking about such things. It is such a pathetic > state, that the so called community is just one person, who holds the > remote control of controlling all the people. ??? If this view is shared by others I will just go away. I do feel so upset that I wasted my time trying to give you good advice, and not only are you not listening but also just throwing shit at me in return. Thanks. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
On Tue, Sep 18, 2007, Manu Abraham wrote: > Johannes Stezenbach wrote: > > > I really don't think there is any problem in releasing API version 3.3 > > with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc. > > > > And I think it would be wrong to delay DVB-S2 support until you > > have all of DVB-H, DVB-T2, etc. properly hammered out. > > Johannes: why do you play this nasty thing ? > > Quoting yourself from your last mail: > > " new ioctl later for DVB-H etc. (DVB-SH, DVB-T2 > and DVB-C2 anyone?) " > > So who wrote about C2 and T2 (me ?) Sigh, that was just an example. Replace it with ARIB, ASI, demux and statistics if it makes you happier. I'm not trying to play games. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
On Mon, Sep 17, 2007, Steven Toth wrote: > Johannes Stezenbach wrote: >> >> But after all the discussions, and you and Steve have written >> drivers which I hope prove the API as working, why do you >> still think it is experimental? What would it take to make >> it non-experimental? > > My take on the patches is this: > > It's experimental. > > However, it's been experimental for about a year and it's not getting > traction, I've said this before on the ML - it needs to be driven. I've > been pinging Manu recently to put up a tree on linuxtv.org/hg, merged with > the latest v4l-dvb tree so people like myself can start testing, breaking > and patching the tree. > > No tree = no testers = no discussion = no review = no merge = no support in > Linux. > > I want to help start the ball rolling. Great, sounds like a good plan. >> I wish you'd just stop with all those private discussions and instead >> keep it on the list all the time. That way everyone would have all >> the relevant information, which is one of the key points of doing >> Open Source development: spreading not just the code but also the >> knowledge about the technology. mrec isn't completely wrong when he says >> that this list gives the appearance of a closed, elitist circle where >> everything interesting happens in backrooms. > > That's a little harsh Johannes. :) But I mean it. I used clear words so everyone would get it. > I contacted Manu privately and offered to help him with the patch. Why? > Because whenever I've tried to debate or encourage this via the ML it's > gone nowhere. The ML is only useful to a point, then it's meaningless and > 1-to-1 communication is required. Fair enough. The story behind this is that I had been Cc'd out of the blue in a private discussion about this (even after I told Manu serveral times that I don't want to participate in private technical discussions), and had I not pushed for taking it to the list then a new tree would have appeared on linuxtv, leaving many people oblivious to it's purpose and the story behind it's creation. It's very simple: If you want to work like that, then just leave me out of it. There is no need to get me involved. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
On Mon, Sep 17, 2007, Manu Abraham wrote: > > The problem is that, after making something experimental, throwing it > out to application authors stating here it is: the API update, again a > fix to the API will make anyone furious, nobody wants to keep tinkering > forever on the same thing. Exactly, that's why I blocked your initial attempt to merge the DVB-S2 API extensions. *That* it was experimental code (even completely untested). But after all the discussions, and you and Steve have written drivers which I hope prove the API as working, why do you still think it is experimental? What would it take to make it non-experimental? > I would prefer to say mark it experimental in > a tree dedicated to it, such that it is explicitly stated that it is not > a permanent solution and in the background, the fixes required for the > relevant can be done. IMHO application developers hate temporary APIs -- it means they have to rewrite their code later, and there are zero guarantees as to when you make the change to the "real" API and how big the required changes would be. > Don't you think so ? If someone asked me to keep working on with changes > every now and then i wouldn't be very happy, but if i were explicitly > told, look this is what as far what it stands as of now, it is expected > to change, for further support, that i could digest it a bit. Trying to > put myself into someone else's shoes. The magic word is "backward compatibility" -- as long as that is guaranteed, everyone _loves_ small incremental updates. They are much easier to handle than the one large mega update which changes the complete API. I really don't think there is any problem in releasing API version 3.3 with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc. And I think it would be wrong to delay DVB-S2 support until you have all of DVB-H, DVB-T2, etc. properly hammered out. > That said there are newer devices taking advantage of the full specs. As > we have seen as soon as there are devices, there are applications as > well. Vendors don't spend their funds on something nonsense and that too > a major chunk of it. Of course there are cases, but in this case i > highly doubt your claim. I have no idea what you want to say with this. Missing context? > > IIRC my closing words in the DVB-S2 API discussion were > > along the line of "we shouldn't merge an API without users > > into mainline now, we should wait until the first driver which > > uses it is ready and merge both at the same time". > > That is because a) we generally shouldn't add APIs without > > users, b) we shouldn't add APIs which are untested and > > thus not proven to work. > > IIRC, You only wrote sometime earlier, why work on something useless > such as DVB-S2. Why a change of thought ? You remember wrong, I never said this. What I said was that _at the time_ you wanted to merge your initial API proposal, there was no DVB-S2 equipment available in stores, and also no DVB-S2 transponder in operation. So your desire to get this merged _then_ was premature. > > Ever since, everyone's just been waiting for your > > "I'm ready with my driver, please merge" mail. > > I would be going on with an experimental tree after Wednesday. > > Still some more things to be polished in that CCM only case too. See the > first few posts on this DVB API update thread, The way the current API > is, well it is as good as no statistics, but just for kids play there > are some numbers scrolling up and down, ie the statistics do not hold > any value. Displaying some random numbers is not statistics. I have no idea what CCM is. If during the implementation of your DVB-S2 driver you found that the API still needs work, then why not just fix it -- that was the whole purpose of the exercise. The statistics thing is independant of DVB-S2, again I see no reason why to make the "merge DVB-S2" task bigger by dragging this into the picture. > Had a discussion with Steven too on this, since he has a driver as well. > Why this is experimental ? I guess you get all the answers from within > this mail itself. I wish you'd just stop with all those private discussions and instead keep it on the list all the time. That way everyone would have all the relevant information, which is one of the key points of doing Open Source development: spreading not just the code but also the knowledge about the technology. mrec isn't completely wrong when he says that this list gives the appearance of a closed, elitist circle where everything interesting happens in backrooms. > Sometime back you were the person who was against merging the same, now > that you seem to suddenly pull in all that you said crap a few mails > back. Wow, what a contradiction in statements. See above. If by "crap a few mails back" you mean the private discussion about this you tried to drag me into, I'm sorry but I will block any attempts by you (and others) to discuss important technical stuff in private. I'm very
Re: [linux-dvb] DVB API update
On Sat, Sep 15, 2007, Wolfgang Wegner wrote: > > - dvb_fe_type: DVB-S2 is missing and I personally would also like > to see ASI here... See my other mail, IMHO we should add the ASI defines at the same time we merge a driver which uses it. > - frontend status: > - BER is lacking a proper definition (to which base is it calculated?) > - signal strength: same problem, what are the ranges? > - snr: again, no base and ranges given The original Nokia DVB API spec had proper definitions, but Holger Waechtler and me decided to drop them in favour of "read hw register and scale to range 0..0x". The reasons for this were: - for some hw we didn't have info to implement it properly - for those hw where we had info we saw it wasn't worth the effort -- I believe the implementation in the demod firmware is just such a coarse approximation that it doesn't even make a difference if you take the logarithm or not (provided you scale back into the 16bit range) (of course you get different numbers, but none of them maps any better to what you'd expect) Someone once told me: Marketing requirement is that the signal quality bar is in the upper third when the picture is good, and in the lower third when the picture is bad. Everthing else is irrelevant and the numbers can be pure fantasy. And that's what I believe you get from most demods, and how it is implemented in most commercial receivers. But, well, that was a few years back and it was crappy hw, maybe the situation improved. I'm not opposed to it if you want to improve the situation, but IMHO you shouldn't put your expectations too high... HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
On Sun, Sep 16, 2007, Rainer.scherg wrote:
>
> - A runtime version check of the API is needed. Currently the API
> version is determined at compile time, which is useless, when
It is necessary in the same way as you have KERNEL_VERSION
or GLIB_MAJOR_VERSION etc.
> distributing binaries (one of the bad things on linux are
> incompatible API changes over time).
> A simple major.minor version number check will IMO do.
We dicided against it since a capabilities based interface
is much nicer to use. Or a simple "try new ioctl, if that
returns ENOTTY use old ioctl" approach...
> - a "user structure" for hardware specific data (e.g. retrieve
> special data from a special frontend chip would be nice.
> this should be optional (*NULL = not used or not implemented).
> otherwise something like:
>struct { char[xx] hw_info;
> specific data...
> } *;
I think this API sucks. DVB API V1 had a "read/write demod register"
ioctl for debugging, which was removed because you could also use
i2c-dev. It would be better to find a way to use i2c-dev with
proper locking wrt fe->sem than to cram arbitrary and probably
unspecified hw data with unversioned layout into the DVB API.
> - API 3 is missing a a function for retrieving current frontend
> settings (e.g. on SAT LNB settings). It would be sufficient, when
> simply the last parameters set are returned.
> Currently on API3 a "second dvb application" can change the frontend,
> whithout any chance for the "main dvb application" to detect this
> easily.
As already outlined by Manu it doesn't work. DiSEqC command
strings can be of arbitrary length, we don't buffer this in the driver.
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
Hi Manu, On Sat, Sep 15, 2007, Manu Abraham wrote: > > While being on the V3 frontend API overhaul, i found to much dismay that > it would be much better to revamp V4 into a newer API version such as > V5, rather than scratching with V3 for ages together, resulting in just > unnecessary talks and discussions. It is beyond me why you think creating a new API would result in less "unnecessary" discussions that improving the existing API... :-) Given that there already is well-discussed API enhancement proposal for DVB-S2, affectionately but wrongly called "multiproto" (MPE?), I don't know why you don't get this merged first instead of making that task bigger and have everyone wait longer for the end result? IIRC my closing words in the DVB-S2 API discussion were along the line of "we shouldn't merge an API without users into mainline now, we should wait until the first driver which uses it is ready and merge both at the same time". That is because a) we generally shouldn't add APIs without users, b) we shouldn't add APIs which are untested and thus not proven to work. Ever since, everyone's just been waiting for your "I'm ready with my driver, please merge" mail. > What i find interesting with the V4 API > * A better demuxer But it's also overcomplicated and like MiHu explained not targeted at PCI/USB cards. IMHO It would be useful to add a simple version of the recording filters to the V3 demux. > * ARIB extensions I don't see anyone writing a driver using that, so why bother? Given that we always need to stay backward compatible with old API versions, I believe it is much easier to improve the existing API in small incremental steps than to introduce a completely new API. (While working on V4, we were always thinking "hey, we can add backward compat later", but frankly I don't see how this could've worked out.) For DVB-S2 the problem was: - couldn't extend FE_SET_FRONTEND without breaking backwards compat - thus need new ioctl - to not repeat the same mistake I proposed to add "forward compatibility" so we could extend the new ioctl later for DVB-H etc. (DVB-SH, DVB-T2 and DVB-C2 anyone?) (V4L2 API does the same thing) See? Keep it simple. Do just one thing at a time. HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
On Sat, Sep 15, 2007, Markus Rechberger wrote: > The main discussion in this thread was about drivers in userspace > are bad because the API will allow binary drivers. The guy > who works for Hauppauge (again I also have good contacts > at Hauppauge Europe) writes it's bad - for no technical reason. It sends a shiver down my spine that seem to imply that you use your Hauppauge Europe contact to lobby against the efforts of Hauppauge USA employees to promote support for Open Source kernel drivers within their company. > If someone points out that it is bad (after reading the whole thread) > why don't we put X.org, bash, well everything into the kernel? > GPL is the saviour seems to be the saviour for some people in this > world, but in the end it's still if people want to go that way. > Much work has been done by other people before, my work > is also just an additional contribution and I (again) don't intend to > release binary drivers. (also keep in mind that ubuntu takes > everything which makes things work - this matters to the enduser) > > Hey I can also write I can help you to get things right with some other > people, and I can financially support people by giving away > hardware and even specs for free in some cases. Who is able > to do that from the old crufted v4l/dvb guys? > > Manu throws his drivers over the wall to the OSS community, although > I don't mind. > Mauro is copying the logic of my code and writes I told him I'm ok with > taking my code without just adding a single line of how his driver > got developed. (I still wonder why he skipped some significant parts > of the driver .. because he used the existing one as logic template) > > http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c > (not looking at the specific changeset but he copied the firmware > loading instructions without taking care about the copyright?) After you dismissed all arguments except your own as invalid, you've now moved on to the "post bullshit and personal accusations" stage. I hope this means we're now done with this "discussion". > > Now, doesn't _that_ get you thinking? > > oh yes. Yeah, right. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
On Sat, Sep 15, 2007, Markus Rechberger wrote: > > it gets me thinking. Some core developers who I met during > the last few weeks (kernel summit, suse conference in czech) > told me to go on with it actually because the final plan isn't that > bad.. I was referring to your code you posted for merging on linux-dvb, and which got rejected. Anyway, it's easy to agree with you if one has just heard _your_ version -- the purpose of this thread is to give people an alternate version of the story to complement yours, which would allow the people you talked to to think it over and change their mind. See if you can get of those people you talked to to post here to support you. > Beside that I'm just curious how much did you contribute > during the last 2 years to the lkml/linux kernel, and how much > do you want to contribute in future? (also from my side > talk is cheap (even for me) but getting something done costs > quite some time and feedback from other people) IOW you say if I don't write code I should shut up? Is that also what you tell users on your em28xx list when they dare to disagree with you? Nice... Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
On Fri, Sep 14, 2007, Markus Rechberger wrote: > > people do contribute to the em28xx project. ... > there's also an active and even problem solving oriented ML available: > http://mcentral.de/pipermail/em28xx/ > > Also if you look at the mercurial code you'll see several people > contributing to that project. Of course, people who own such a device and want to use it with Linux have no choice but to work with you. And you do a good job for your users, you support them well and in return they contribute info and patches to support new devices. But the thing is that at mcentral.de you're the man at the top, and your users will hardly disagree with you on core technical questions. (Well, admittedly I'm speculating here as I don't read your em28xx list.) On for drivers/media/ OTOH you are just one developer among others, and some of them choose to disagree with you. Even worse, IIRC there wasn't even _a single_ other developer willing to ACK your offending patch. Now, doesn't _that_ get you thinking? Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
On Fri, Sep 14, 2007, Markus Rechberger wrote: > On 9/14/07, Steven Toth <[EMAIL PROTECTED]> wrote: > > > > If you care about LinuxTV you'll work with the core subsystem developers > > to bring your em28xx tree inline. If you don't care then why are you here? > > It doesn't really work out to work with those 3-5 "core" people who are active > there. > It starts at the point where RFCs are submitted and not answered, > discussions are avoided and finally some people start to complain. > In case of pointing people to wrong or bad solutions, one "Maintainer" > pointed out it would be like manipulating others work ... this exactly > happened with the em28xx project. It's not only about the current > implementation, as from my side I also take upcoming products into > account and how long it would take to get something which isn't > supported by the API fixed.. it's just something that is too hard and > I don't want to debate about things where I know that the outcome > is that I have to wait till someone of those 3-5 "core" people come up > with an own idea. Maybe you still don't realize how tiresome it is to talk to you. What you present as "linuxtv people block my contributions" is IMHO "linuxtv people got fed up talking to you". Because when people disagree with you, you keep rambling on and on instead of just accepting it. See, working with an Open source community requires that you don't piss everyone off, but instead find ways to _motivate_ them to help you fix the problems which prevent your code from being merged. When people are doing software development _for fun_, then it should be a _pleasure_ for them to work with you, and not a pain in the ass. You code and your arguments in this discussion may be different than before, but the thread follows a familiar pattern and will likely go nowhere, just like the many discussions before. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
On Thu, Sep 13, 2007, Markus Rechberger wrote: > Let's add the LKML to this. > > On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > > I don't see any technical reason why tuner drivers should be moved to > > > userspace. Looking at xc3028 device, the driver is very simple and > > > doesn't require any special treatment that it isn't possible to be done > > > at kernel. There are already some implementations on kernelspace that > > > works fine. > > > > As from my side to support the xceive driver properly it needs a > > rewrite and a proper API description. Since it's not possible to > > discuss any API changes Not possible? We're doing it all the time... However, your ideas were rejected in this discussion, and you can't seem to get over it. > > don't get me wrong but the existing community is rather small and > > kicking off people who are interested in changing things. IMHO there is a lack of openness caused by people being burned in past flamewars. This makes it a bit difficult to see through what happens and why, and to participate. However, I think it is completely wrong to say that the community is "kicking off people". > > I'm against how the project works out at the moment and how it worked > > out in history. Exactly this way will kick off companies to be > > interested in future like Avermedia. A driver can easily be written > > within a few weeks and I've been struggling with it for 2 years(!!!) > > now just for nothing finally telling me that some guys want to steal > > my code and move it to kernelspace although it would raise more > > complications with upcoming and current devices which have even more > > requirements. Oh dear, there we go again... more flame bait... I reality, 95% of your driver code could have been merged without problems, but you refused to take the small, objectionable part out of the picture. (For those interested: http://mcentral.de/~mrec/patches/v4l-dvb/hg_v4l-dvb-experimental_01.patch The patch changed the internal tuner API and required changes to all tuner drivers.) Your all-or-nothing approach didn't work out. Out of curiosity: How does your userspace approach solve the hybrid (analog/digital TV) tuner problem which was the only objectionable part of your work? And why are the kernel parts of your new interface now less objectionable? What changed? Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
On Thu, Sep 13, 2007, Markus Rechberger wrote: > > We currently have an implementation that works, although > it works by downloading several firmwares for several devices > or even several countries. This is not what I want to have in > future since it's not needed and it's also hard to manage for > distributors. All those differences could be adjusted by > software even without module parameter hacks. This argument doesn't hold water. The unpleasant point for users and distributors isn't the "binary-only" thing, it's the "no right to distribute" problem. And that's the same for firmware blobs or binary-only userspace blobs. IOW, if you can get the right to redistribute a binary-only userspace blob which incudes the firmware inside, why shouldn't you be able to get the right to redistribute just the firmware? Or the other way round: Do you think your binary-only software will be important enough so distributors will go through all the trouble of trying to get a license to include it in their distribution? If so, why wouldn't they do the same for the plain firmware blobs for in-kernel drivers? Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asys P7131 Hybrid: DVB out of range
On Thu, Sep 06, 2007, Andreas Oberritter wrote: > > Quoting from the manpage of strtol(): > > The strtol() function returns the result of the conversion, unless the > value would underflow or overflow. If an underflow occurs, strtol() > returns LONG_MIN. If an overflow occurs, strtol() returns LONG_MAX. > In both cases, errno is set to ERANGE. Precisely the same holds for > strtoll() (with LLONG_MIN and LLONG_MAX instead of LONG_MIN and > LONG_MAX). You should've read on: NOTES Since strtol() can legitimately return 0, LONG_MAX, or LONG_MIN (LLONG_MAX or LLONG_MIN for str‐ toll()) on both success and failure, the calling program should set errno to 0 before the call, and then determine if an error occurred by checking whether errno has a non-zero value after the call. I think your patch is buggy, because errno is not guaranteed to be reset to zero after successful calls (see the errno manpage). Regards, Johannes > diff -r 1923f74d97ae util/szap/azap.c > --- a/util/szap/azap.cWed Jun 27 19:46:43 2007 +0200 > +++ b/util/szap/azap.cThu Sep 06 02:47:52 2007 +0200 > @@ -104,6 +104,8 @@ int parse_int(int fd, int *val) > }; > > *val = strtol(number, NULL, 10); > + if (errno == ERANGE) > + return -4; > > return 0; > } > diff -r 1923f74d97ae util/szap/tzap.c > --- a/util/szap/tzap.cWed Jun 27 19:46:43 2007 +0200 > +++ b/util/szap/tzap.cThu Sep 06 02:47:52 2007 +0200 > @@ -180,6 +180,8 @@ int parse_int(int fd, int *val) > }; > > *val = strtol(number, NULL, 10); > + if (errno == ERANGE) > + return -4; > > return 0; > } > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
On Mon, Aug 20, 2007, Manu Abraham wrote:
> Michael Krufky wrote:
>
> > -- this is a system-wide addition to the
> > dvb_frontend structure, because we are adding analog tuning
> > functionality to the dvb_frontend.
>
> Analog tuning is public to DVB core ? I don't think so. It would've been
> correct, if DVB core does analog operations, but DVB core doesn't do any
> Analog operations.
Well, supporting hybrid tuners means that analog and digital
worlds have to touch somewhere...
> > I agree that elegance is very important, and that is why I disagree with
> > the extra layers of complexity that you are proposing here.
>
> Every DVB demodulator driver that you write does this.
>
> struct dvb_frontend {
> struct dvb_frontend_ops ops;
> struct dvb_adapter *dvb;
> void* demodulator_priv;
> void* tuner_priv;
> void* frontend_priv;
> void* sec_priv;
> void* hybrid_priv;
> };
>
>
> So whatever that which dvb_core doesn't handle is "private". I don't
> understand what you mean by extra complex layer.
I think the rule of thumb is to use void* only when it points
to different things for each driver (e.g. struct tda8083_state*,
struct ves1820_state* etc.). If we know it will always point to
struct analog_parameters (or set_analog_params) then using
void* is IMHO wrong.
Using a forward decl for struct analog_parameters and putting
struct analog_parameters somewhere else like Hans suggested
would be OK, but doesn't seem that important to me. I mean the
whole separation of analog and digital tuning APIs is artificial
and is just a result of how development happend in two distinct
communities historically. Why spent any effort to keep them
completely seperate instead of letting them grow together?
Anyway, I think it's not a fundamental issue and could be
changed at any time without affecting the basic approach
this proposal takes to implement hybrid tuners.
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
On Sun, Aug 19, 2007, Oliver Endriss wrote: > > Questions: > - Why should dvb_shutdown_timeout==0 disable sleep mode? The use case was to watch video without any software running. Just program the hardware once and let it do it's job. Some people want that although I don't think it's really useful. (Works for FF cards only, of course.) > - Does it make any sense to have LNB power 'on' and the frontend in > sleep mode? No. > Imho these should be controlled by dvb_powerdown_on_sleep alone, > for example: Sounds good to me. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
On Sun, Aug 19, 2007, Oliver Endriss wrote: > > Does anyone know, why dvb_shutdown_timeout was introduced initially? That was a (IMHO stupid) hack by Holger with the purpose of speeding up tuning with szap a little bit by avoiding the FE_INIT after re-opening the frontend device. I.e. Holger's use-case was to run szap, terminate if with ^C, re-run szap for different program. FE_INIT reintializes all demod registers so can take noticable time if the i2c bus speed is slow. IMHO dvb_shutdown_timeout never had any practical relevance. BTW, Holger's preferred app for watching video was http://linuxtv.org/hg/dvb-apps/file/tip/test/video.c :-) Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
On Sun, Jul 22, 2007, Uwe Bugla wrote: > > As announced I've built a revised tarball plus a Debian package of the > current > dvb-apps repository, implying your patchset (i. e. human readable characters > as a switch for szap, tzap and czap. > > Unfortunately both packages were rejected without giving reason by the list > moderator of [EMAIL PROTECTED] If you look at the reject messages, they should say: Reason: Message body is too big: 404226 bytes with a limit of 60 KB and Reason: Message body is too big: 517891 bytes with a limit of 60 KB The limit is there to protect people who don't have broadband connectivity, and to protect the list server (with ~2000 list subscribers, these two mails would have caused ~1.8 GByte of traffic). Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [Em28xx] MPL-licensed V4L kernel modules (em2880)
On Thu, Jul 12, 2007 at 03:49:30AM +1000, Julian wrote: > Since this disscussion is public... > I'm going to put in my 2 cents. > > If you actually read his posts - Like alot of end users are. Its the flames > and personal attacks that are coming from the group mentality here (im sure > theres a wiki that can explain that too) Hm, Markus complains that the community doesn't work, and you're complaining that it _does_ work -- or what do you mean by "group mentality"? > So if we are talking about changes to the core and how v4l and dvb devices > will work under linux in the future. He/they with the best solution will win > via non-bias peer review and hopefully *beyond* the linuxtv project. So if > Markus persists enough (he seems the only one consistently reworking what he > has already done - but everyone seems to skim past that in his posts...) he > will succeed. > > I admire anyone that makes an effort against the status quo that fails to > move > anywhere really, and spends more effect resisting any kind of change than > actually doing anything or offering an alternative. > > Just because he is outnumbered with support here means absolutely nothing. > May the best code win. Markus always portrays it that way, that there is a group of evil guys who block his code, who mislead him, who want to retain the status quo etc. pp. And now he is the lonely hero who stands up against the establishment... IMHO that is complete rubbish. There isn't even a formal group of "linuxtv core developers". I'm glad that Mauro agreed to merge the DVB and V4L trees into one, and to do the patch handling for the combined tree. And I'm glad Mike and Trent do a lot of patch review and bugfixing work, unseen and unrewarded my most people. Does that give them any authority to ACK and NACK patches as they see fit? Hell, no! But the community process works that way that if someone reviews a patch and has objections, then these objections must either be addressed or shown to be wrong. (Read Documentation/ManagementStyle in the kernel to see how it works ;-) In Markus case, serveral people who looked at his patches had objections, but he refused to address them, but was unable to either show the objections as being wrong, or get a _single_ other developer to back up his position. Instead there were threats to "fork the linuxtv project" if his code wouldn't get merged... The sad thing is that only a relatively small part of Markus' code has problems, and the bulk of it could have been merged without it, leaving out the xc3028 v4l/dvb arbitration functionality. But Markus didn't want this. Anyway, there are many patches which are rejected from the Linux kernel or have to go through significant transformations before they are allowed into the kernel. You should read the linux kernel mailing list for a while, maybe you'd then see that the entry level for patches into v4l/dvb is fairly low compared to the high standards required for core kernel code like scheduler, timekeeping, networking, VM, block IO layer etc. > >Your attempts to force the merge with flames and ultimatums > >(yes, plural) failed. Surprise, surprise... > > how soft do people get with their drivers that they see a patch submission - > as a flame? That's not what I said, I can tell a patch submission from a flame quite well, thanks. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [Em28xx] MPL-licensed V4L kernel modules (em2880)
On Wed, Jul 11, 2007 at 05:18:35PM +0200, Markus Rechberger wrote: > > Remember all that code could have been in the kernel for around 1 year > without breaking any device if these few core people (and there are > really only very few ones <5) wouldn't have tried to hit it down. This "the bad linuxtv guys blocked my drivers for years" allegation is unsubstancial as I tried to show in http://www.linuxtv.org/pipermail/linux-dvb/2007-June/018853.html IMHO it is your inability to make compromises and work with the community which blocked the merge. Issues don't just magically resolve all by themselves if you just wait long enough. Your attempts to force the merge with flames and ultimatums (yes, plural) failed. Surprise, surprise... > I'm sure the project would go on way faster if everyone who has never > investigated the dvb core project and who has no experience with that > piece of code (and writing a dvb driver doesn't shed much light about > the dvb framework) would just stay out of everything. You think you're the only competent programmer, and everyone who dares to have different opinions just gets in the way and holds you up? Check this out: http://en.wikipedia.org/wiki/Narcissistic_personality_disorder#Diagnostic_criteria > It's now about 14.000 lines of code, around 7000 inkernel lines, and I > haven't received _any_ participation request of any developer and all > you get if you ask people to join the project is that they are busy > with their work (which is ok) but then don't try to manipulate someone > else's work in the end. > Nothing is getting better here if linuxtv.org people don't work together. If I look at hg or git logs I get the impression that the community still works. > Companies will for sure not like to rely on such a mess where finally > a few wannabes try to play the smart guys and are responsible that > support for alot devices won't get into the kernel. ... Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [Em28xx] MPL-licensed V4L kernel modules (em2880)
On Wed, Jul 11, 2007, Markus Rechberger wrote: > On 7/10/07, Trent Piepho <[EMAIL PROTECTED]> wrote: > > On Tue, 10 Jul 2007, Markus Rechberger wrote: > > > Stop that MPL discussion, I can put that code offline too and update > > > it with some probably nonfunctional code for several devices but it > > > won't help anyone in the end - so I won't do it. > > > I don't want my work to be stolen by linuxtv people in the end. It's > > > > It's funny you should say this, since 99% of the code you are distributing > > came from linuxtv in the first place! > > Trent, I believe you're smart enough to see the problem behind > everything .. the license stuff is the smallest part of everything; > I don't steal and obfuscate code and remove the copyrights. > And I for sure will not tell anyone how he has to do his work after a > discussion where I didn't seriously participate. > The code as it is will get removed sooner or later and replaced with a > smaller package which only contains the necessary drivers. > > I wonder what you try to gain by bothering about the license there all > you can win is the removal of the code there and the release of the > replacement of the around 80% finished reworked code. So please stay > serious and better try to fix the community problems that something > like that won't happen again. I wonder what you mean by "I don't want my work to be stolen by linuxtv people"? You had your code up for download on linuxtv.org and then on mcentral.de for months, and you asked lots of people to download and test it, which IMHO clearly is "distribution under the GPL". So everyone who downloaded it has every right granted by the GPL to modify and redistribute your code under the GPL, which implies it could be merged it into the main linuxtv.org tree and eventually the kernel. Of course it doesn't make sense to merge unsupported code (which even has known issues wich need to be resolved first), however if someone would adopt it I see no (legal) reason for not merging it. Maybe you don't like this to happen, but IMHO all the people who downloaded and tested your code, and contributed back in form of bug reports, hardware information, patches etc. wouldn't have done so if they had known that your code would not be merged into the mainline kernel. Some people might even have bought hardware after they read though your Wiki pages, under the impression that it was well supported by Linux. Of course you are free to do whatever you like with the code written by you, but everyone else is free to do what the GPL permits them with the code distributed by you under the GPL. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] removal em28xx from linuxtv.org
On Fri, Jun 29, 2007, Hans Verkuil wrote: > > I've been following this whole process for quite some time now and also > tried to help out. I've come to the conclusion that it is purely due to > bad chemistry between various personalities. Technically this stuff > should have been merged a year ago if not earlier. It is really sad, > but it happens sometimes. There also isn't one person to blame, > it's 'just' personality conflicts that caused this mess. I think there's more to it, see my other mail. Just as an example, I asked if there was anyone supporting Markus request to get his drivers merged, and there were _zero_ replies. http://marc.info/?l=linux-video&m=117606199829580&w=2 Why is that? Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] removal em28xx from linuxtv.org
On Thu, Jun 28, 2007, Markus Rechberger wrote: > On 6/28/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > > > In general, it is a good idea to have the manufacturer supporting their > > drivers. However, it won't make any sense to allow Empiatech to touch on > > low-level drivers for hardware not developed by them. The original > > patches were touching on every DVB driver, even on some Empiatech > > competitors drivers. > > And it added support for several cx88 and saa7134 based devices. The > base change was required to get the Empia drivers in, the rest was > optional. > There was a patch from another company which added full xc3028 support > for their saa7134 drivers to the repository on mcentral.de and by > doing what you did you now force me to rework what that company did. > The whole issue is a bigger than you imagine. I wondered about the reasons for your reply in http://marc.info/?l=linux-dvb&m=117940327206449&w=2 This now outlines what the problem is: You had a repository which contained code which you knew wasn't going to be merged because others disagreed, and instead of addressing the problem you decided to work in isolation for a year, piling patch upon patch. But the original problem is still unsolved, and instead of asking for help you try to force us to accept your code -- which naturally won't work. Knowing how difficult the situation was I tried to resolve it by suggesting to merge your code as-is, and then fix it up later until everyone's happy with the outcome. http://marc.info/?l=linux-video&m=117572695505842 ff. Everybody grudgingly agreed, and I thought the issue was resolved, and I even sent you in private mail a reminder to push your code in time to make the 2.6.22-rc1 merge window. I was surprised that you never did. A few weeks later you start all over again with the same "merge all my code" request, but this time I was thinking that the reason why you didn't push your patches earlier was that you don't want us to change anything to your code after it has been merged. Which you confirmed in http://marc.info/?l=linux-dvb&m=117940327206449&w=2 But your hybrid tuner dvb-core changes are too ugly to live, if we can't fix them up then your code can't be merged. A few people have offered to help you, but it seems you are unable to accept any help and rather pull the plug than to allow others to change your code. I have the impression that you didn't get the basic idea of what open source development is all about :-( Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Tue, Jun 05, 2007 at 09:16:26PM -0700, Trent Piepho wrote: > On Sat, 2 Jun 2007, Johannes Stezenbach wrote: > > > > Then I2C_M_STOP still makes sense, but the patch should document > > that it's used only a workaround for broken hardware. > > Well, I tried but no one on the i2c list liked the I2C_M_STOP idea. > http://lists.lm-sensors.org/pipermail/i2c/2007-May/001362.html > > The answer seems to be that one should have your i2c driver use it's own > mutex to insure that an i2c transaction with a stop is atomic. > > That won't work if you try to use both the stv0297 driver and i2cdump from > userspace at the same time, so the answer there is just to not do that. What Jean writes only applies if you have a struct i2c_client and i2c_driver to work with. the you can do lokcing in the i2c_driver. But we don't, IIRC because of problems with bus probing done yb the i2c-core. Not having an i2c_client is also the reason why we can't use the i2c_smbus_* functions. Well, maybe we could fix this and then use i2c_client and i2c_driver everywhere, but it still wouldn't solve the i2c-dev problem, which I2C_M_STOP would in a very simple and elegant way. I2C_M_STOP might also be useful to talk to devices behind a repeater/gate or hub. > If you want to dump the registers, you need to put a copy of i2cdump in the > kernel for each driver that you want a register dump from. Then the driver > can create a sysfs file with a register dump. That way the in-kernel > driver specific i2cdump can use driver's mutex to insure atomic bus access. > > I'm still unclear on exactly what the stv0297 requires. The datasheet says > one can't use a repeated start, but must have a stop between a read and a > write. That's simple enough, but has anyone actually verified that the > datasheet is really correct? I know many datasheets provide some > _examples_ of i2c transactions, but it's by no means an exahstive list. > Just because something isn't listed doesn't mean it won't work too. > > Does the stv0297 require that no other i2c traffic, to a different device, > appear between the write and the read? Something like: > > S stv_addr_W A reg_addr A P > S tuner_addr_W A tuner_data1 A tuner_data2 A P > S stv_addr_R A reg_data NA P > > Will the i2c message to the tuner between the two parts of the stv register > reading sequence be a problem? You can't know before you tried it. I think Philips doesn't offer an "i2c bus spec conformance" test (there is something for SMBus, though), so I'm quite sure there are a lot of devices with subtly broken i2c bus implementations. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] question about the zap utilities ,,, why so many?
On Sun, Jun 03, 2007, CityK wrote: > So there is: > - zap ... intended for developers > - azap ... for ATSC and N.A dig. cable (STCE 07) > - czap ... for DVB-C > - szap ... for DVB-S > - szap2 ... for DVB-S2 > - tzap ... for DVB-T > > Is there any technical reason why these 6 utilities aren't blended > together into a __single__ comprehensive tuning app ... say, "zaptune" > or whatever, for example? Well, I wrote szap at a time when the DVB API only supported DVB-S (for the first generation av7110 based Siemens/Technotrend/Hauppauge DVB-S cards), because I needed it for my work at convergence integrated media GmbH. The S in szap was supposed to mean "simple". It started as a really tiny testing tool. Later Holger added tzap and czap. Needless to say that I would've integrated T and S support into szap right from the start, but there was nothing I could do about it. So there's no technical reason, it's just a historical artefact. HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Fri, Jun 01, 2007, Oliver Endriss wrote: > e9hack wrote: > > Manu Abraham wrote: > > > e9hack wrote: > > >> Manu Abraham wrote: > > >>> Trent Piepho wrote: > > What the stv0297 wants is: > > S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P > > > > >>> The STV0297 is just a normal demod like the others, nothing special > > >>> about it (according to ST). Well of course i2cdump can be wrong. > > >> The stv0297 cannot handle a repeated start condition and it needs > > >> a little delay between the stop and the next start condition. A > > >> stop and a start condition cannot be on the same upload command > > >> of a saa7146 (on a TT 2300C). > > > > > > Any idea what the SAA7146 - STV0297 windows driver does ? > > > > > > > Good point. I can monitor any access to the saa7146 registers of the > > TT 2300C on Windows. I will check this issue. In the past, I was > > more interested in the high level part of the i2c-communication. > > Any news about this? > > Imho Trent's patch to add I2C_M_STOP makes sense. > > According to the stv0299 datasheet, the stv0299 requires this STOP > condition, too. This chip seems to be more tolerant though. > The current driver does not send STOP before READ, and it works. I re-read the i2c spec (conveniently available from http://i2c-bus.org/ ), and although it doesn't use very clear words I think it says that any device _must_ support repeated start conditions (e.g. section 9 FORMATS WITH 7-BIT ADDRESSES). There's also some more explanation: http://i2c-bus.org/RepeatedStartCondition/ Now, it could well be that the stv0297 i2c interface is broken (broken because it cannot safely be used on a bus with multiple masters), but it may also be quite possible that the stv0297 datasheet is just inaccurate. IMHO both possibilities are just as likely, however I trust adq has actually tested that repeat start doesn't work. http://linuxtv.org/hg/v4l-dvb/rev/c204a1d063aa Then I2C_M_STOP still makes sense, but the patch should document that it's used only a workaround for broken hardware. Regards, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB Networking Module
BTW, what's this? +source "drivers/media/dvb/dvbloop/Kconfig" Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB Networking Module
Hi, On Sun, May 27, 2007, Christian Prähauser wrote: > Johannes Stezenbach wrote: > > On Wed, May 16, 2007, Christian Praehauser wrote: > > > >> The branch is available at > >> http://www.cosy.sbg.ac.at/~cpraehaus/hg.cgi/v4l-dvb. What you did to include/linux/dvb/net.h is not allowed. You must not break backwards compatibility of userspace APIs. You can only add new ioctls or make backwards compatible changes to existing ioctls, but not delete or change them. Or add old cruft to Documentation/feature-removal-schedule.txt. (Well, I have no practical experience with dvb-net, and the API design is from Nokia, so maybe it's totally broken and no one uses it. But unless you are absolutely sure that there are no users you are not allowed to break it.) Have you looked at the ioctls which ifconfig uses? (man 2 ioctl_list) E.g. would it be possible to use SIOCGIFCONF to find the dvb-net interfaces? Could one use ifconfig e.g. to set the MAC? In general, I'm not convinced that it was a good idea to put dvb-net in the kernel at all, because I think usually MPE/ULE traffic would be encrypted (probably with your ISP's proprietary scheme), so you'd have a daemon in userspace which sets the section filters to receive the data, decrypt it, and feed packets into the network stack via a tun device. IMHO the overhead of doing it in userspace would be minor. It also makes it easy to use multiple PIDs which didn't work well with dvb-net (one PID per dvb net device). But again, I have no practical experience with dvb-net, you're the dvb-net expert now ;-), so I trust you to make the right decision. HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB Networking Module
On Wed, May 16, 2007, Christian Praehauser wrote: > > The branch is available at > http://www.cosy.sbg.ac.at/~cpraehaus/hg.cgi/v4l-dvb. This repository seems to be corrupted: $ hg clone http://www.cosy.sbg.ac.at/~cpraehaus/hg.cgi/v4l-dvb destination directory: v4l-dvb requesting all changes adding changesets adding manifests adding file changes abort: consistency error adding group! transaction abort! rollback completed > Along with the new dvb-net module, a new version of the dvbnet (DVB network > interface manager) > is (required and) available at the repository > http://www.cosy.sbg.ac.at/~cpraehaus/hg.cgi/dvb-apps. > It uses a simple command language, example: > dvbnet addmpe pid 300 Some people probably use dvbnet in scripts, so if you change the commandline syntax in a non backwards compatbile way it's better to give your version a different name and leave the old one alone. > I would like to discuss here (on the list) > - whether if it makes sense to this (from your point of view) > - what should be changed/added/removed > - any other comments > - if we should and how we can eventually integrate this into the main > v4l-dvb and dvb-apps branches couldn't look at your code, but: I think it was a design mistake in the current dvb-core that a card driver has to add code if it wants to support dvb-net. As soon as a card driver registers a demux, dvb-core should add dvb-net automatically, as there is zero card-specific code involved. It is useful to have CONFIG_DVB_NET. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Sun, May 20, 2007, e9hack wrote:
>
> With the attached patch, it works for the stv0297 functions. It
> doesn't solve the problem, why I've wrote the initial patch. I need a
> dump from the registers of the stv0297. I've attach a second patch.
> stv0297_attach() inserts a wrapper between i2ctransfer() and the
> transfer function of the saa7146. The add/del functions for the
> wrapper are a little bit
> dirty. I didn't find a clean way for the add/del function.
Hm, I was trying to tell you that the problem is in i2cdump,
not in saa7146 or stv0297.
i2cdump is simply limited to simple SMBUS-like transfers,
but I think it wouldn't be difficult to extend it or
write a new utility which uses the I2C_RDWR ioctl to
perform the transfer as required by stv0297.
http://lm-sensors.org/svn/lm-sensors/trunk/prog/dump/i2cdump.c
http://lm-sensors.org/svn/lm-sensors/trunk/kernel/include/i2c-dev.h
Something like that would do it (except for the race which I2C_M_STOP
should fix):
#include
#include
#include
#include
#include
#include
#include "i2c-dev.h"
int main()
{
unsigned char reg = 0x00;
unsigned char val;
struct i2c_msg msgs[] = {
{ .addr = 0x08, .flags = I2C_M_WR, .buf = ®, .len = 1 },
{ .addr = 0x08, .flags = I2C_M_RD, .buf = &val, .len = 1 }
};
struct i2c_rdwr_ioctl_data i2c_rdwr = {
.msgs = msgs,
.nmsgs = 2
};
int fd;
fd = open("/dev/i2c-1", O_RDWR);
if (fd < 0)
perror("open");
if (ioctl(fd, I2C_RDWR, &i2c_rdwr) == -1)
perror("ioctl I2C_RDWR");
close(fd);
printf("%02x\n", val);
return 0;
}
HTH,
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Sat, May 19, 2007, Trent Piepho wrote:
>
> I've written a patch that implements I2C_M_STOP. It would be used like this:
>
> char buf1[2] = {0x0b,0x3c}, buf2[1];
> struct i2c_msg msgs[2] = {
> { .addr = 0x61, .buf = buf1, .len = 2, .flags = I2C_M_STOP },
> { .addr = 0x61, .buf = buf2, .len = 1, .flags = I2C_M_RD } };
> i2c_transfer(adap, msgs, 2);
That's what I had in mind. Thanks for writing the patch!
> This would work for stv0297, wouldn't it?
It should ;-/
If you are going to submit this to the i2c maintainer, please
add I2C_M_STOP to Documentation/i2c/i2c-protocol.
Thanks,
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Fri, May 18, 2007, Manu Abraham wrote: > Johannes Stezenbach wrote: > > On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote: > > > >> IMHO, it isn't possible > >> to split a read request into a single write and a single read request > >> outside of the core device. The device must be locked during both > >> transfers. If the device isn't locked, it is possible that another > >> transfer will change the slave offset before the content is read. This > >> may occur with the current implementation. > > > > If locking is necessary the drivers would need to > > handle this explicitely (I think it isn't unless ou start > > messing mith /dev/i2c concurrently). > > even if you do a concurrent operation with /dev/i2c, the i2c bus driver > read/write provides concurrency locks, afiacs. Or am i missing something ? One i2c_transfer() is atomic, if you do two (as required by stv0297) another transfer could happen in between. So intead of e.g. stv0297 send register number stv0297 read register data i2c-dev send another register number i2c-dev read register data you might get stv0297 send register number i2c-dev send another register number stv0297 read register data i2c-dev read register data I don't think there is any lock which would prevent this, is there? (The BKL might protect two i2c-dev accesses from each other, but not against the accesses from the dvb_frontend_thread.) But I also think that messing with i2c-dev on the frontend i2c bus is a debug tool and not a regular use case. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote: > Johannes Stezenbach wrote: > > According to linux/Documentation/i2c/i2c-protocol.txt the correct > > way to get a STOP condition between two I2C messages is send them > > in seperate I2C transactions. > > I don't find this description in i2c-protocol. It's not written explicitly, but it says you need to use a "Simple send transaction" and/or a "Simple receive transaction" instead of a "Combined transaction" if you want a STOP bit in between. That's how i2c-core is designed. > IMHO, it isn't possible > to split a read request into a single write and a single read request > outside of the core device. The device must be locked during both > transfers. If the device isn't locked, it is possible that another > transfer will change the slave offset before the content is read. This > may occur with the current implementation. If locking is necessary the drivers would need to handle this explicitely (I think it isn't unless ou start messing mith /dev/i2c concurrently). Or you could propose a change to i2c-core to add a I2C_M_STOP flag (analogous to I2C_M_NOSTART), which then would have to be implemented by all i2c bus drivers. > > If i2cdump is not able to handle > > this, please fix i2cdump. > > I2cdump deals with /dev/i2c and has nothing to do with this problem. Then why did you say i2cdump is "not able to read the registers from the stv0297"? Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Fri, May 18, 2007, e9hack wrote: > > the stv0297 doesn't understand the repeated start condition on the > i2c-bus from a saa7146. The current frontend driver (stv0297.c) > handles this problem by splitting the read request into a write and a > read request. Other applications (e.g. i2cdump) are not able to read > the registers from the stv0297. The attached patch lets solve the > saa7146 this problem. If it is necessary, the driver inserts an > additional stop condition and moves the following start condition into > the next upload command for the saa7146. According to linux/Documentation/i2c/i2c-protocol.txt the correct way to get a STOP condition between two I2C messages is send them in seperate I2C transactions. If i2cdump is not able to handle this, please fix i2cdump. That said, I'm wondering why this state->config->stop_during_read cruft exists at all, as it should always be set to True? (I suspect that it's a misplaced kludge for the b2c2 driver.) Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
On Thu, May 17, 2007, Markus Rechberger wrote: > On 5/17/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > >On Thu, May 17, 2007, Markus Rechberger wrote: > >> > >> I will not go back anymore, instead a fork off seems to be a good > >> solution if the linuxtv project wants to stay stuck where it is at the > >> moment it should do so. > > > >Yep, we all know by know the linux-dvb crowd is not an easy one. > > > >So what? If your goal is to get your drivers merged, it > >seems the _fastest_ way is to take the detour, > >even if it means additional work for you. > > Ok, so it only keeps one possibility open to start another official > linuxtv project. > > The current approach is quite mature already, the other approaches are > incomplete or will just kick everything back where it was already a > long time ago. > > I redid the code 3 times already so I don't see another option, this > all seems very rude to me since there hasn't been any review on the > code either. > > Any last comments on all that? Well, I see the option of redoing the code a fourth time. I'm glad you asked. ;-) I'm sorry but I currently see no other way to get your code merged. But it's _your_ choice. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
On Thu, May 17, 2007, Markus Rechberger wrote: > > I will not go back anymore, instead a fork off seems to be a good > solution if the linuxtv project wants to stay stuck where it is at the > moment it should do so. Yep, we all know by know the linux-dvb crowd is not an easy one. So what? If your goal is to get your drivers merged, it seems the _fastest_ way is to take the detour, even if it means additional work for you. Sorry if that is a bitter pill to swallow, but I see little other chances to get going forward. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
Hi Markus, On Thu, May 17, 2007, Markus Rechberger wrote: > On 5/17/07, Michael Krufky <[EMAIL PROTECTED]> wrote: > > > >Don't get me wrong -- I am not suggesting that we duplicate this code > >and leave it in that state forever. What I am suggesting is that we go > >about this change in small steps. > > > >The proposed changes are simply too large and span too many source files > >to achieve a proper review by enough developers, especially in their > >"spare time," not to mention all the regression testing that needs to be > >done. > > In that case I'm willing to fork the linuxtv project if I did too much > to review. > I just spent too much time on it to throw it away without a serious > discussion. > > The tuner refactoring code has around 600-700 lines of code I think, > the rest are the additional drivers and other things. After the recent flamewar there was the opportunity for you to get the whole thing merged, if you had only pushed it out in time. IMHO em28xx even could have made it into 2.6.22... Life is full of compromises, some of them ugly. Don't you think it would be better to scarifice those 700 lines of code in order to get the thousands of lines of em28xx and xc3028 code merged _now_? (And, BTW, you should not take this personal. The amount of code written for the kernel, posted to lkml and then mercilessly pulled to pieces, and finally thrown away is HUGE.) While certainly not ideal, Mike's plan is at least a way to make progress, even if there's a little detour involved. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Simple question I hope
On Fri, May 04, 2007, Julian WILSON wrote: > > We are implementing the current linux dvb video and audio devices in > software for a media centre we are building. We are uncertain of the > best way to access the functions provided by the core to implement the > data paths needed. > > The first requirement is to support 192 byte transport stream packets > which have the 0x47 as byte 4. This is the format used on Blue Ray > disks. We are currently doing this by hooking into the > dvb_demux.dmx.write function. > > The second requirement is to receive payload data from the demux rather > than 188 byte chunks via the write_to_decoder function. > > The user will typically set up a pes filter with something like: > >PesFilter.input = DMX_IN_DVR; >PesFilter.output= DMX_OUT_DECODER; >PesFilter.pes_type = DMX_PES_VIDEO; >PesFilter.pid = Context->VideoId; >PesFilter.flags = DMX_IMMEDIATE_START; > >Result = ioctl (Context->DemuxVideoDevice, > DMX_SET_PES_FILTER, &PesFilter); > > The software will be running within the kernel and we would like to be > able to intercept this in such a way that the demuxed pes data can be > read from the various different feeds. Are there any mechanisms which > allow this kind of access. The reason for this is it seems pointless to > demux data that has already been filtered by the dvb-core functions. IMHO using the dvr device for playback would make sense if you have a hardware demux. If you're demuxing in software, then it's probably better to do it in userspace and feed video/audio packets directly to the decoder. This makes it easier to implement trick modes. (I also suspect the dvr playback code has locking problems, and is not tested much as it's only supported for av7110 cards, and isn't used by vdr or other software.) HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
On Fri, Apr 20, 2007, Mauro Carvalho Chehab wrote:
> Argh! Too much flood for two simple defines!
I _think_ the point Mike was driving at is that there
is an established coding pattern of having a
struct foo_config {
u8 i2c_addr;
...
};
If you use that then the #define is (at least) superflous,
"foo_tuner.i2c_addr = 0x62;" does the job.
If you don't use it, then the #define increases readability.
However, experience shows that soon enough there'll be
another similar device with a different i2c_addr so it makes
sense to use the pattern right from the start.
HTH,
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [Proposal] Unification of the v4L & dvb wikis
On Wed, Apr 18, 2007, David Liontooth wrote: > > Johannes Stezenbach, if I'm not mistaken, is in charge of the DVB wiki > -- what do you think? "In charge" as in "do software updates", "check for Wiki spam" etc. I haven't contributed significant content. Whatever is fine for the Wiki users is fine by me. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] EFF Europe petition against IPRED2
Hi, IANAL so forgive me if it is irrelevant, but to me it seems important enough to pass the information on. Quoting http://www.copycrime.eu/ : "On April 24th, the European Parliament will vote on IPRED2, the Second Intellectual Property Enforcement Directive. ... If IPRED2 passes in its current form, "aiding, abetting, or inciting" copyright infringement on a "commercial scale" in the EU will become a crime." The two key problems here are: 1. undefined meaning of "commercial scale" and "incitement" 2. it becoming a crime (as opposed to a a subject of civil law) My understanding is that e.g. it could become a crime to write software which could be used to record pay-TV without the broadcaster's consent, even though using a valid subscription. (But, again, IANAL, so my understanding could be wrong -- you have to decide for yourself. I think currently there is no law against writing such software, only using it might be a (minor) infringement.) The goal of the petition is to ask the European Parliament to amend IPRED2 with clear definitions of the language, and to clearly limit the scope to real criminals (i.e. people making money selling fake designer watches or cloned DVDs etc.). Visit http://www.copycrime.eu/ for more info and to sign the petition if you want to support it. Thanks, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [v4l-dvb-maintainer] DVB Maintainer
On Mon, Apr 16, 2007, Manu Abraham wrote: > Johannes Stezenbach wrote: > > On Mon, Apr 16, 2007, Manu Abraham wrote: > >> Would have appreciated your stand, if you had the same stand on other > >> threads as well. (IIRC your stand on the DVB-S2/multiproto threads were > >> completely opposite. You wanted to hold things back) > > > > That is not true. Your first proposal was crap, yet you asked > > Mauro the merge it and even got ACKs from others. So I > > pointed out that I thought it needs more work. > > Ok, if my first proposal was crap, it is crap still. After the driver > was completed _most_ of the stuff had to be done according to the old > proposal, because the delivery system does indeed need them (not just > useless params) > > You were asleep throughout the discussion. For Marcel's request you said > it was okay too. After that you had a dream or something like that and > even apologized for your last minute barging in, also that you didn't > understand about DVB-S2. > > It wasn't anyone else's fault that you NACK'd it after asking Mauro to > pull, but yours alone. You could have done it earlier too.. or just kept > quiet. Was a waste of time for so many people involved. I rejected the DVB-S2 proposal when I first read about it -- which was when you asked Mauro to merge it. The discussions about the DVB-S2 API that followed were dragged out over a period of serveral weeks, if not months. And at the end of the discussions your proposal looked totally different than your first one. And the agreement was that you and others implement a driver and show the API works in practice, then it can be merged. I'm sure you will tell us when you think it's ready. The list archives can tell the full story. Since you are so good at finding stuff in archives I'm confident you can find the key postings if you only want to. > > And if there was a "please review" or "Mauro, please merge" mail > > regarding multiproto recently, I must have missed it. > > Sorry. You said you didn't have the time after everything was done, > inspite of many mails sent to you. > > If someone NACK's something for a reason and when those things are > fixed, the same person could at least show a bit of courtesy by stating > the same problems are/were fixed. I told you many times that I'm not interested in DVB anymore, thus I won't spend my time reviewing code or discussing architecture, especially if it's sent to me in private. I'm really so out of it that the details escape me anyway. The reason why I speak up here occationally is that I do care about Linux' as a whole. I try to help out if I think things start to go wrong in DVB land. Too bad you see this as a personal attack or a Markus vs. Manu thing. :-( The merging of em28xx has in fact absolutely nothing to do with DVB-S2. So we merge em28xx now and DVB-S2 later. What's the problem? Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)
On Mon, Apr 16, 2007, Manu Abraham wrote: > > Johannes, > > you probably understand now. Well, you want to be DVB maintainer, so please try to think like one. How can you serve the project better? [ ] By putting all personal issues aside and merge em28xx anyway, even if it means getting your hands dirty and having to fix up possible problems and any ugliness caused by it? [ ] By further delaying it until Markus might one day*) wake up enligthened and would magically fix up all issues to your whole content himself? Choose wisely. It's OK that you defend your code and your proposal, but if you look at the big picture the the choice should be clear, right? Johannes *) In Germany we call this day "Sankt Nimmerleinstag" ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)
On Mon, Apr 16, 2007, Manu Abraham wrote:
> Johannes Stezenbach wrote:
>
> > I believe many people ("users") would like em28xx to be merged
> > asap, so I'm trying to find a way how it could be done.
>
> IMHO, code that which is bad should be fixed and then only be accepted
> into the project. I don't see any reason for any person/project to be
> given any special status and things should work just as normally.
>
> It is completely wrong to artificially create a huge importance/need
> and doing things -- Incorrect way of doing things.
It's not artificial. The em28xx merge has been delayed for more than
a year with little visible progress.
That's a disaster.
And it doesn't really matter whose fault it is.
If you have technical reasons why Markus' code shouln't be
merged (like "breaks support for the X card", or even
"breaks all non-em28xx cards" or "crashes under SMP" etc.),
then you should let us know about it.
Note that your hybrid tuner proposal is not dismissed
by merging Markus' code, however time is important here,
and I don't think it's OK to delay the merge another
couple of weeks/months until your proposal is fully
implemented, tested and merged.
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [Proposal] Unification of the v4L & dvb wikis
On Thu, Apr 12, 2007, CityK wrote: > Johannes Stezenbach wrote: > > But I think there's no way to do it without losing history > > (or at least the correct user attribution of changes). > > > The export pages function (under special pages) seems to imply that it > would work, but I'm not sure (or clear on it). Well, the export includes the information, but the usernames and ids in the other wiki don't necessarily match, so I think the import will ignore it. I haven't tried it, though. > Nonetheless, the license issue is indeed one that needs to be addressed > ... and something that I would love to get help with. For example, there > are also some nice templates available at > http://www.mythtv.org/wiki/index.php/Templates and also some at > Wikipedia, and also some svg images (such as the check mark and X on > Wikipedia ) that I would love to utilize. But I want to be careful about > adhering to licensing. However, I find that when I start looking at CC > licenses, GPL licences and so forth, I get bogged down and start to lose > it quickly...i.e. not a lot of patience to read through a lot of > unfamiliar legal mumbo jumbo text. IANAL but my understanding of the CC Attribution-ShareAlike license is that you can use them but must say so. E.g. put a statement like "This Wiki uses icons from the Tango theme from http://tango.freedesktop.org/"; in some suitable place. Johannes ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [Proposal] Unification of the v4L & dvb wikis
On Thu, Apr 12, 2007, CityK wrote: > Time, after time, after time, I have seen users express confusion about > information fragmentation. Lets put an end to this. > > I propose that there is no better time then the present to begin the > merger of the v4l & dvb wikis together under one roof - the LinuxTV > wiki. I also propose the creation of an active administrative body to > govern over the "new" wiki. I'm all for it. But I think there's no way to do it without losing history (or at least the correct user attribution of changes). Does someone think this is a problem? There's also the problem that the V4L Wiki says: "To keep these instructions free, all contributions to this wiki are automatically licensed under the GNU General Public License GPL. If you wish, you may specify in each case that your contribution is dual-licensed under the MIT License." But the DVB Wiki fails to give a license :-( I've no idea how to resolve this. > I have crafted a mock up of what a unified wiki could look like, as well > as outlined (in point form) some rationale for my proposals. But if you > want a reason in a nutshell -- it just makes sense to do so. Please see > http://www.linuxtv.org/wiki/index.php/User:CityK for further details. > > Looking forward to resultant comments and discussion (hopefully all > positive!) It looks really nice! A few comments: - you could put most if not all of the blurp at the top into http://www.linuxtv.org/wiki/index.php/LinuxTVWiki:About (the About link is at the bottom of every page) - I hope the icons are OK to use and your not grabbed them from somewhere without looking at the license? A big Thank You! for the huge amount of work you did for the DVB Wiki! Thanks, Johannes ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)
Hi,
[big snip]
C'mon guys, let's leave the past behind us and
not start fighting again.
I believe many people ("users") would like em28xx to be merged
asap, so I'm trying to find a way how it could be done.
It is unfortunate that em28xx depends on the hybrid tuner
API design, but we have to live with it.
> On 4/10/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> >http://marc.info/?l=linux-video&m=117571761928085&w=2
> >http://marc.info/?l=linux-video&m=117613833119350&w=2
If that proposal is _proven to work_ ("dummy_hybrid_tuner.c" doesn't
sound like it's been tested), _and_ has more supporters than
Markus' code, then I would ask him to rebase his code
on top of it. However, I don't think we should wait
another month for your proposal to be ready.
So currently I think if Markus code _works_, and
_doesn't break_ any non-em28xx/xc3028 devices, then it
should be merged.
But of course that requires that people test his
stuff with non-em28xx equipment, and report if it still works.
(And ideally someone who read through the code would
ACK it or let us know why it can't be ACKed.)
You or someone else can rewrite the whole hybrid tuner
stuff later once you have a proven better solution.
I don't care and I guess Markus wouldn't mind, too.
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)
On Thu, Apr 05, 2007, Markus Rechberger wrote: > I sent this proposal to several individual developers already around > 1-2 weeks ago, and received several comments, maybe I should give it a > try to push a very last discussion about it. > > Video4Linux/DVB Hybrid Tuner Support > ... > >Mauro wrote that requesting the tuner module first and afterwards call an > >init function within the driver > >which requested that module, this might be a solution for using > >initialization functions similar to > >usb_register/usb_deregister. > >on the other side this would break the dvb_attach approach and it might > >require much bigger changes in the > >dvb framework (?) > >This approach is currently partly implemented in v4l-dvb-kernel on > >mcentral (http://mcentral.de/hg/~mrec/v4l-dvb-kernel) > > a current implementation which uses the unified module approach and a > similar approach like dvb_attach can be found > at: > http://mcentral.de/hg/~mrec/v4l-dvb-experimental > (see tuner-core.c, v4l_dvb_tuner.h) In the discussions one month ago I had the impression that serveral people agreed on this or at least wanted to help to do the necessary work to get this merged. All private comments to Markus are fine, but if there's any interest in getting this stuff merged, you need to show it publicly. Any comments on the code are good. Not saying anything is bad. FWIW, I very briefly looked at http://mcentral.de/hg/~mrec/v4l-dvb-experimental/file/d1e8753a491b/linux/include/media/v4l_dvb_tuner.h and I think the V4L_OPS macro is invalid because it yields a pointer to a variable on the stack which just went out of scope. This might work by accident, but IMHO gcc is allowed to reuse the stack space for something else immediately after the closing brace. HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DSM-CC Synchronized Download Protocol
On Tue, Mar 13, 2007, Thomas Lagemann wrote: > I'm looking for information in the "DSM-CC Synchronized Download > Protocol". In an amandment to MPEG-2 "Systems" this is stated to be a > synchronous method of delivering data in an MPEG-2 stream. It's said > that the data is inserted into DSM-CC Download sections which carry a > PTS entry for synchronization. But i can't find any information about > this in 13818-6 which secifies DSM-CC. > Maybe someone can explain me this, or hand me an article for further > reading. I have no idea what it is but ISO lists this: ISO/IEC 13818-6:1998/Amd 2:2000 http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=33123&ICS1=35&ICS2=40&ICS3= HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [PATCH] dvb-core: Fix several locking related problems.
On Sun, Mar 04, 2007 at 05:45:54PM +, Simon Arlott wrote:
> Fix several instances of dvb-core functions using mutex_lock_interruptible
> and returning -ERESTARTSYS where the calling function will either never
> retry or never check the return value.
>
> These cause a race condition with dvb_dmxdev_filter_free and
> dvb_dvr_release, both of which are filesystem release functions whose
> return value is ignored and will never be retried. When this happens it
> becomes impossible to open dvr0 again (-EBUSY) since it has not been
> released properly.
>
> Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
Acked-By: Johannes Stezenbach <[EMAIL PROTECTED]>
I can't test this but to me it looks good.
Mauro, could you please pick it up and keep it in the
linuxtv.org repository for a while for testing?
Thanks,
Johannes
> ---
> On 04/03/07 15:41, Andreas Oberritter wrote:
> >please send an updated patch together with
> >Signed-off-by line to Mauro <[EMAIL PROTECTED]> and ask him to apply
> >it for inclusion into the -mm tree for further testing.
>
> Unless there are other -mm trees I've not heard about, presumably I should
> just do this myself. Doesn't linux-dvb have it's own development tree this
> would get better tested in?
>
> The dvb_dvr_release change has been working for me for 6 months and the
> dvb_dmxdev_filter_free (dvb_dmxdev_filter_free) change looks equivalent.
> See http://www.linuxtv.org/pipermail/linux-dvb/2007-February/016120.html
> for an example of the bug before and after fixing.
>
> All the other changes run ok for me but should have lockdep enabled when
> testing (if there's a possible deadlock somewhere, using _interruptible
> will hide it).
>
> drivers/media/dvb/dvb-core/dmxdev.c| 12 +++-
> drivers/media/dvb/dvb-core/dvb_demux.c | 21 +++--
> drivers/media/dvb/dvb-core/dvbdev.c|9 +++--
> 3 files changed, 13 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/media/dvb/dvb-core/dmxdev.c
> b/drivers/media/dvb/dvb-core/dmxdev.c
> index fc77de4..a5c0e1a 100644
> --- a/drivers/media/dvb/dvb-core/dmxdev.c
> +++ b/drivers/media/dvb/dvb-core/dmxdev.c
> @@ -180,8 +180,7 @@ static int dvb_dvr_release(struct inode *inode, struct
> file *file)
> struct dvb_device *dvbdev = file->private_data;
> struct dmxdev *dmxdev = dvbdev->priv;
>
> - if (mutex_lock_interruptible(&dmxdev->mutex))
> - return -ERESTARTSYS;
> + mutex_lock(&dmxdev->mutex);
>
> if ((file->f_flags & O_ACCMODE) == O_WRONLY) {
> dmxdev->demux->disconnect_frontend(dmxdev->demux);
> @@ -673,13 +672,8 @@ static int dvb_demux_open(struct inode *inode, struct
> file *file)
> static int dvb_dmxdev_filter_free(struct dmxdev *dmxdev,
> struct dmxdev_filter *dmxdevfilter)
> {
> - if (mutex_lock_interruptible(&dmxdev->mutex))
> - return -ERESTARTSYS;
> -
> - if (mutex_lock_interruptible(&dmxdevfilter->mutex)) {
> - mutex_unlock(&dmxdev->mutex);
> - return -ERESTARTSYS;
> - }
> + mutex_lock(&dmxdev->mutex);
> + mutex_lock(&dmxdevfilter->mutex);
>
> dvb_dmxdev_filter_stop(dmxdevfilter);
> dvb_dmxdev_filter_reset(dmxdevfilter);
> diff --git a/drivers/media/dvb/dvb-core/dvb_demux.c
> b/drivers/media/dvb/dvb-core/dvb_demux.c
> index fcff5ea..6d8d1c3 100644
> --- a/drivers/media/dvb/dvb-core/dvb_demux.c
> +++ b/drivers/media/dvb/dvb-core/dvb_demux.c
> @@ -673,8 +673,7 @@ static int dmx_ts_feed_stop_filtering(struct
> dmx_ts_feed *ts_feed)
> struct dvb_demux *demux = feed->demux;
> int ret;
>
> - if (mutex_lock_interruptible(&demux->mutex))
> - return -ERESTARTSYS;
> + mutex_lock(&demux->mutex);
>
> if (feed->state < DMX_STATE_GO) {
> mutex_unlock(&demux->mutex);
> @@ -748,8 +747,7 @@ static int dvbdmx_release_ts_feed(struct dmx_demux *dmx,
> struct dvb_demux *demux = (struct dvb_demux *)dmx;
> struct dvb_demux_feed *feed = (struct dvb_demux_feed *)ts_feed;
>
> - if (mutex_lock_interruptible(&demux->mutex))
> - return -ERESTARTSYS;
> + mutex_lock(&demux->mutex);
>
> if (feed->state == DMX_STATE_FREE) {
> mutex_unlock(&demux->mutex);
> @@ -916,8 +914,7 @@ static int dmx_section_feed_stop_filtering(struct
> dmx_section_feed *feed)
> struct dvb_demux *dvbdmx = dvbdmxfeed->demux;
> int ret;
>
> - if (mutex_lock_interruptible(&dvbdmx-&
Re: [linux-dvb] [RFC] Reviewed development procedures DVBMaintainer
Hi all, I've been thinking hard the last days what I could possibly say that would make things better and not worse. Mission Impossible :-( I apologize in advance if I step on someone's toes. But I'm not going to point fingers at anyone as I think this isn't a single person's fault but more of a collective fuckup. On Fri, Mar 09, 2007, Markus Rechberger wrote: > On 3/9/07, Steven Toth <[EMAIL PROTECTED]> wrote: > > > >I suspect the other person gave the best advice they could at the time. > >Maybe that advise is no longer true or valid. Either way, the person > >offered the best advise I suspect. Maybe in the future you should seek > >advise from multiple sources to validate any long term development > >approach. > > everyone is welcome to reply, but usually not too many participate here. Well, generally I have the impression that there is a lot of activity on linux-dvb. And just like you don't participate in _every_ thread, but just the ones which you are interested in, so is everyone else. No one participates in a discussion if - they don't get what it's all about - or they don't care about it - or they expect to be flamed or ignored Or the other way 'round, if you're interested in feedback: - explain the background so that _everyone_ can understand it, not just the "core developers"; if you can post patches instead of a description what the patches would look like, please do - show people why it is important _for them_ -- no one cares if it's only important for _you_ - be patient -- not everyone has time to fully dig into it right away, so the initial comments are likely to be superficial and/or just plain wrong; usually if you can show someone that their comment was wrong, they feel challenged to dig deeper into it to give you better comments; you must be careful not to hurt anyone's feelings, otherwise discussion stops pretty quickly Sounds like hard work? You bet it is! > >Likewise, the other developers have an obligation to review your ideas > >and discuss/describe the areas of concern, offering constructive > >feedback. It's unacceptable to refuse a colleagues patch and not offer > >any advise. I know this has NOT happened. I know alternatives were given > >to you. ... > >I suggest you stop the bickering and begin working with your Linux peers > >again, help us to find the right solution. > > sorry I'm getting pissed, for every approach I presented for now I had > some code as well and it gets nacked without improvement suggestions. > Also it has to be said that other hybrid implementations aren't well > implemented and still need some improvement.. About one year ago there was exactly the same thing: Clash of opinions about how to integrate xc3028, and then a huge (and to me completely incomprehensible) fight followed. Apparently everyone involved was so fed up with it that they didn't want to touch the issue for a year, and now: - the issue is still unsolved (surprise!) - last year's fight still hangs over it like a dark cloud and prevents any useful discussion I have no clue about the technical issues of this proposal and can't comment on it, however I am convinced that the technical issues are minor compared to the problems in the social interaction between the developers. I've read through the irc log, and I couldn't help noticing: http://linuxtv.org/irc/linuxtv/index.php?date=2007-02-27 - Both mrec and mkrufky seemed to have predetermined expectations on the outcome of the discussion: - mrec: they'll NAK it anyway - mkrufky: he won't listen to anyone anyway - It seems mws made a reasonable effort to understand mrec's proposal, but most of the time mws and mrec are talking past each other, and are finally arriving at the conclusion that the other one is just too stupid to get it. Maybe a hint that irc is not an adequate medium for this kind of discussions? - mkrufky coolly watches the action, apparently satisfied to see his preconceptions confirmed; otherwise doesn't seem to want to help the issue at all Commentary: - Apparently irc sucks. I believe the mailing list is a much better medium for this kind of discussions. - The proposal posting sucked (according to my criteria from above). http://linuxtv.org/pipermail/linux-dvb/2007-February/016302.html Especially since Markus says on irc he has working code, I can't understand why he didn't just post the patches. Then there would have been no guesswork, everyone could've seen immediately how it works and what the consequences of this change are. - I cannot see any malicious behaviour in this. Sure Mike was pretty unhelpful, which I think was lame measured by the role he plays among the DVB developers. But in the light of last years xc3028 trouble I can understand that he doesn't have any incentive to help the issue. - I doubt Mike would block a technically flawless patch just because he doesn't like the author. If he tried to, he wouldn't succeed becaus
Re: [linux-dvb] [RFC] Reviewed development procedures & DVB Maintainer
Markus Rechberger wrote: > I could > easily prove that I got misleaded here already several times. > I wonder how someone could respect a core developer who does that. Please prove it. If I understand correctly you say that a core developer _deliverately_ sabotaged your work. Which I find very hard to believe. That someone fucks up and talks bullshit, that's to be expected from a human being. But that's something entirely different than malice. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] dvb-core: Fix several locking related problems.
On Mon, Mar 05, 2007 at 06:19:01PM +0100, Oliver Endriss wrote: > > From 'Linux Device Drivers' (replace 'down' by 'mutex_lock'): > | ... > | down decrements the value of the semaphore and waits as long as need > | be. down_ interruptible does the same, but the operation is > | interruptible. The interruptible version is almost always the one you > | will want; it allows a user-space process that is waiting on a > | semaphore to be interrupted by the user. You do not, as a general > > | rule, want to use noninterruptible operations unless there truly is no > ^^ > | alternative. Noninterruptible operations are a good way to create > ^^^ > | unkillable processes (the dreaded D state seen in ps), and annoy > | your users. Using down_interruptible requires some extra care, > | however, if the operation is interrupted, the function returns a > | nonzero value, and the caller does not hold the semaphore. Proper use > | of down_interruptible requires always checking the return value and > | responding accordingly. > | ... I don't think this advice applies to mutexes (at least if the mutexes are used in the usual way to protect some common data). For event semaphores, you block waiting for an event, and if the event doesn't happen (maybe you wait for an irq), you need a way out or you're screwed. So using down_interruptible() is what you want. Mutexes, however, are supposed to be held only while manipulating some shared data. So the code looks *always* like this: mutex_lock(&mtx); do_something_with_shared_data(); mutex_unlock(&mtx); Now if some process sleeps uninterruptibly in mutex_lock(), some other process holds the mutex and sleeps in do_something(). If it wedges up, you either have some locking bug (someone forgot a mutex_unlock()), or it wedged up in do_something(), and you got to fix *that*. mutex_unlock_interruptible() would only help to paper over locking bugs, and its use in dvb-core comes from a straight conversion from down_interruptible(), which itself was used because it was once useful during development. How that the signal handling was found to be buggy I think it's much better to use mutex_lock() instead of fixing the mutex_unlock_interruptible() usage. BTW, some statistics: linux-2.6.20$ grep -r '\' . | wc -l 3080 linux-2.6.20$ grep -r '\' . | wc -l 236 Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] dvb-core: Fix several locking related problems.
On Mon, Mar 05, 2007 at 01:58:14AM +0100, Oliver Endriss wrote: > Simon Arlott wrote: > > Is any part of the patch going to be applied? I mentioned this > > problem in September last year and it looks like it's existed for > > years (the semaphore locking did the same thing). > > Well, I hoped that someone more familiar with the demuxer stuff would > comment on the patch. I am not very happy about using non-interruptible > lock operations... > > Anyway, I'll apply the patch to HG master if you submit an updated patch: > - Please add a line of comment to each mutex_lock() stating _why_ the > non-interruptible lock has to be used at this place. IMHO using mutex_lock_interruptible() is almost always wrong. The only use it has in dvb-core is to recover from locking bugs -- if it deadlocks you can Ctrl-C out of it (instead of being left with a non-killable program -> reboot). But with mutex_lock_interruptible() it's easy to introduce signal handling bugs, which Simon confirmed to exist. Fixing those up without reverting to mutex_lock() way might be possible, but is more difficult. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB/V4L/VDR MediaWiki update
On Sun, Feb 25, 2007 at 09:54:05PM +0100, Oliver Endriss wrote: > Johannes Stezenbach wrote: > > > > I updated the DVB, V4L and VDR Wikis on linuxtv.org > > to MediaWiki version 1.9.3. > > > > If you experience any problems due to the update, then > > please let me know about it. > > Don't know whether this is related: > linuxtv.org is no longer reachable from a web browser, > www.linuxtv.org works as usual. Hm, works for me. > Unfortunately, the HG repository pages use linuxtv.org... ;-( linuxtv.org and www.linuxtv.org resolve to the same address, you can use either to pull from hg. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DVB/V4L/VDR MediaWiki update
Hi, I updated the DVB, V4L and VDR Wikis on linuxtv.org to MediaWiki version 1.9.3. If you experience any problems due to the update, then please let me know about it. Thanks, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] mailing list cleanup
Patrick Boettcher wrote: > Can you please remove <[EMAIL PROTECTED]> from the > linux-dvb@linuxtv.org list? Everytime I send a mail to the list, the > mailserver kindly answers directly to me, that this address does not exist > anymore. Done. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] MPE pointer field too big
On Tue, Oct 17, 2006, Harnois Anne-Sophie wrote: > > Some of the MPEG-TS packets I receive contain a pointer field bigger > than 184 (continuity counter is correct). How to explain that? Shouldn't > Pointer field be inside 0 and 184? > Any comments? Are you sure PUSI is set in those packets? If not, no pointer field is present. Otherwise it is a bug in the TS generator, it must be 0 <= pointer <= 183. HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Where to find specifications for user-defined descriptor tags?
On Fri, Oct 06, 2006, Robert Schlabbach wrote:
> From: "Johannes Stezenbach" <[EMAIL PROTECTED]>
> > On Fri, Oct 06, 2006, Robert Schlabbach wrote:
> > > Obviously the broadcasters must have released the specifications to at
> > > least some receiver makers for implementation.
> >
> > Hm, it might be possible that these descriptors are handled
> > by some MHP application only.
>
> But the stations ARD and ZDF do not offer any receivers nor MHP
> implementations, so they must rely on independent receiver makers to
> implement their user-defined descriptors. Thus, I conclude that they must
> have created some specifications. But how/where would ARD/ZDF publish such
> specifications...?
ARD and ZDF both broadcast MHP applications which run on every
receiver conforming to the MHP standard. An MHP application ("Xlet")
is written in Java and can set arbitrary section filters and
parse any user defined descriptors.
See? No public descriptor spec necessary.
IIRC one of the ARD/ZDF Xlets is an EPG-like application.
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Where to find specifications for user-defined descriptor tags?
On Fri, Oct 06, 2006, Robert Schlabbach wrote: > Obviously the broadcasters must have released the specifications to at > least some receiver makers for implementation. Hm, it might be possible that these descriptors are handled by some MHP application only. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Big changes in the DVB-USB-framework (for 2.6.18 ?)
On Tue, Sep 19, 2006, Patrick Boettcher wrote: > Nevertheless I would like to have all this stuff ready to be included in > 2.6.18 . > > Is it too late? Yes. At -rc7 Linus will only take small bugfixes. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch 3/6] rename scan into dvbscan again
On Thu, Sep 07, 2006 at 03:08:20PM +0200, Ludwig Nussel wrote: > Change got lost during Makefile refactoring It isn't necessary to rename to source files for renaming the binaries. A small Makefile patch would be better. Thanks, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: What has happend to Manus repositories?
On Tue, Aug 29, 2006 at 10:06:44PM -0700, Trent Piepho wrote: > On Wed, 30 Aug 2006, Johannes Stezenbach wrote: > > On Tue, Aug 29, 2006, Steven Toth wrote: > > Manu had posted a large set of patches on July 25, and got zero > > responses, neither positive nor negative. Someone needs to > > review and test them etc. > > The massive patch bomb was impossible to follow. I did look over the > patches when I found a repository that had them applied, and did discuss > them with Manu. You can check the IRC logs. I looked at the front-ends > that I had knowledge of, and they were completely broken by the patches. My position was that the API cannot be merged into mainline before it is proven to work. In order tell Mauro to pull the API changes, one ideally should prepare a tree which doesn not just contain the frontend.h change, but also the consequential changes to dvb-core and drivers (if any), and at least one working driver which uses the new API features. Otherwise it cannot be tested. I guess Manu worked in this direction, which explains why there were so many patches. I have no idea if the work he did was going in the right direction, I haven't looked at it. I avoid using IRC (big time killer for me), and I think many others avoid it, too. linux-dvb currently has 1846 subscribers. How many hang out in IRC or read the IRC logs? If you don't post to the list the majority of people will never find out what's going on. > I tried to help with the new front-end API, but it was a work dynamic that > I don't wish to be part of. OK. Thanks, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: What has happend to Manus repositories?
On Tue, Aug 29, 2006, Steven Toth wrote: > > Manu, > > I've been working on a 3 week old tree you gave me from thadathil.net. > Thanks for this. I've added support for a new S2 demod and tuner (for > the WinTV-HVR4000). I'd like to get the entire tree up on linuxtv.org, > at least people can comment. > > I sense a level of frustration in your comments. Let me ask, in your > view what's the current position with multiprotocol? Is the ML close to > agreeing the general frontend ops/core changes? The thread has gone cold. > > In the mean time, from my perspective, commercial pressure to release > 'half baked' drivers and/or core framework changes (to customers in > vertical markets) leave me in a difficult position. I don't want to do > that. It's a horrible scenario. Neither do I want to be seen as pushing > a commercial agenda... simply because I'm not. I want what's best for > Linux, make no mistake about that. > > I'm happy to hold off my vertical customers until the ML has a workable > solution and has some kind of long term future... except we don't seem > to be discussing/planning or moving ahead with any multiprotocol > review/change cycle. > > Now I'm frustrated. > > Johannes, any comments in terms of multiprotocol generally? I have plenty of other things to do and essentially have stopped doing any linux-dvb development. Some people seem to think that because I spent lots of time reviewing and discussing the API proposal, it is my duty to spend even more time on it, to review it again and finally ACK it. However, I currently (and for the foreseeable future) stopped caring about linux-dvb, and thus won't do it. > How do we get this project back on the rails? Manu had posted a large set of patches on July 25, and got zero responses, neither positive nor negative. Someone needs to review and test them etc. If no one cares to do this work it won't happen. Or maybe you can just go and ask Mauro to merge them unreviewed. It's your responsibilty, I don't care and won't NACK anything anymore. HTH, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: What has happend to Manus repositories?
On Tue, Aug 29, 2006 at 04:26:46PM +0400, Manu Abraham wrote: > Per Dalén wrote: > > > > What has happened to Manus hg-repositories? > > I cannot pull/sync them anymore. > > I deleted my repositories at linuxtv.org, because of > > (1) a post on v4l-dvb-maintainer from Johannes Stezenbach > <[EMAIL PROTECTED]> asking people to remove of unnecessary trees. It was > getting quite hard to find out the trees from there as it was getting > real cluttered. Here's the posting, for reference: http://linuxtv.org/pipermail/v4l-dvb-maintainer/2006-August/001877.html Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DVB + V4L Wiki Update
Hi, I've updated the DVB and V4L Wikis to MediaWiki-1.7.1. In case there's a problem now, please let me know. Thanks, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Types and capabilites for HDTV ATSC.
Holger Waechtler wrote:
> struct dvb_atsc_parameters {
> fe_modulation_t modulation;
> /* anything more? maybe 8VSB or 16VSB? */
> };
>
>
> struct dvb_frontend_parameters {
> __u32 frequency;
> fe_spectral_inversion_t inversion;
> union {
> struct dvb_qpsk_parameters qpsk;
> struct dvb_qam_parameters qam;
> struct dvb_ofdm_parameters ofdm;
> struct dvb_atsc_parameters atsc;
> } u;
> };
But you better make sure dvb_atsc_parameters isn't larger
than any of the other ones; if the size of struct
dvb_frontend_parameters changes, you'll break binary
compatibility. Otherwise I think it should be no problem.
Johannes
[linux-dvb] Re: Progress on specifications for Twinhan/KWorld/CTS DVB-T USB Box
Patrick Boettcher wrote: > > DiBCom also provides a firmware for this device. Is it useful to put it in > a .h file and abandon the firmware_class usage in the usb-driver? What > does the kernel policy says about it? Kernel policy says that all firmware must be removed from the kernel. Some Distributions seem to be more relaxed about this, but e.g. Debian will patch these out of their kernel in the future. > I mean including the firmware into the kernel would make the usage of the > device much easier. Another option instead of extracting the firmware from > the windows driver file would be to put the firmware somewhere for free > download (like dvb-ttpci). This is quite easy and the kernel is not > being bloated. Once the firmware_loader method is well established this will not be much hassle for ordinary users. I see no downside to using it. > Today Twinhan Austria was contacting me. They told me, that they are in > contact with convergence and that they are offering PCI devices to > them, to support driver development for Linux. > Additionally Twinhan Austria told me, that convergence offered to write > drivers for the usb devices too. Is that correct, how far is this part? I > mean this is exactly what wanted to do and to avoid overlapping I'm asking > this. I can't comment on this now, but if we would have or work on a public driver for one of their cards we'd let you know. > With the help of tolerant and interested vendors a new frontend driver is > on its way and with it the support of at least three usb devices for > linux. Nice, isn't it? Indeed. Are they also opening specs for the CI parts of their PCI cards? Johannes
[linux-dvb] Re: [PATCH] Video V4 API
[EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote on 05/08/2004 12:00:12: > > [EMAIL PROTECTED] wrote: > > > 1. Added extra option DVB_VIDEO_CAP_PROFILE_LEVEL to capabilities to > allow > > > the decoder's [EMAIL PROTECTED] upper operation to be determined using the > > > ioctl DVB_VIDEO_GET_CAPS. Armed with this information, you can then > decide > > > whether the incoming bitstream can be fully, partially or not decoded. > > > > Shouldn't that be a bitset, or is it a requirement that a > > decoder that handles e.g. [EMAIL PROTECTED] can handle all profiles > > below it? > > It might make more sense to have a bitmask as not all [EMAIL PROTECTED] are > scalable. I just referred to the ISO/IEC13818-2 doccy Table 8-15 that > nicely refers to what decoder options are available. Shall I make a new > patch against your original source code? Yes, that would be great. > > > 4. I have added new presentation formats to > "dvb_video_presentation_format" > > > to help follow the DTG recommended guidelines on aspect ratio > signalling. > > > They are as follows: > > > > Hm, that's directly from the AFD spec, isn't it? > > Well, OK, but doesn't it make the DVB_VIDEO_SET_SCREEN_ASPECT_RATIO > > ioctl superflous? > > Good point. Yes it does make this ioctl irrelevant now - shall we remove > it? I guess we could also change the name from presentation format to dfc > (decoder format conversion) as this is what the decoder is doing to the > incoming image. I have no objections, but I'd like to wait on input from the toshiba guys on this topic. > > > 5) I have also added the capability to determine what presentation > formats > > > the video decoder can support. This is achieved by passing > > > DVB_VIDEO_CAP_PRESENTATION_FORMAT to the DVB_VIDEO_GET_CAPS ioctl. The > > > "val" field will then have a bitmask of what presentation formats it > can > > > handle. User-space applications can then determine the best method of > > > displaying images for a certain screen. > > > > OK, but why not drop enum dvb_video_cap_presentation_format and make > > enum dvb_video_presentation_format a bitset? > > Could do. I just didn't want to allow the user the option of setting more > than one presentation/dfc format at the same time and the driver having > additional sanity checks. What do you think? I think the implementation will already be implemented using switch() or similar, so sanity checks come for free. It might be confusing if something which looks as a bitset cannot be used that way, but we already do the same with other enums. Johannes
[linux-dvb] Re: Types and capabilites for HDTV ATSC.
Holger Waechtler wrote: > Mac Michaels wrote: > >I am the owner of a FunsionHDTV 3 Gold card. I have the > >analog TV and audio working with my modificatons to the > >CX88 driver. I am working on the Digital TV (HDTV ATSC) and > >want to integrate it into DVB as I seems to be a good fit. > >The FusionHDTV card produces a transport stream that seems > >to fit well with DVB. I found Chris Pascoe's modifications > >to the cx88 driver and plan to adapt them for my card. The > >LGDT3302 frontend provides some of the signal quality data > >the other DVB demodulators provide. It tunes the same > >physical frequency bands as U.S. analog TV. > > > >I am not sure which fe_type I should use for the driver. > >FE_QAM seems appropriate for QAM 64/256 that is supported > >by the card. What existing or new type is ATSC HDTV? Does > >the driver register 2 interfaces, one for each type? > > I'd propose FE_ATSC because it's not straight QAM but QAM encapsulated > in 8VSB -- similiar to the DVB-T/OFDM demods which encapsulate a QPSK or > QAM modulation in a OFDM multiplexing scheme. That's what I would do, too. BTW, Christopher Pascoe mailed me privately (in response to the Hauppauge cx88 Nova driver announcement), so maybe there's a new driver coming soon... > >I think a new fe_caps may be needed for 8VSB ATSC. How > >about: > > > >FE_CAN_VSB_8 I would prefer FE_CAN_8VSB. > >For fe_type FE_QAM the fe_caps should probably be > > > >FE_CAN_QAM_64 | FE_QAM_256 > > sounds good. Yep. Johannes
[linux-dvb] Re: [RFC][ANNOUNCE] blindscan: auto search everything
Holger Waechtler wrote: > Roberto Ragusa wrote: > > > >>(BTW, typedefs are deprecated for kernel code (only allowed > >>for explicitly opaque data types)). > > > > > >Until now, I've been contested: > > > >1) "&buf" instead of "buf" > >2) "//" comments > >3) use of typedef > > > >the funny part is that > > > >1) I copied&pasted existing code Please tell us where you copied from, so we can fix the bug there, too. > >2) "//" comments are everywhere > >3) typedef are everywhere in frontend.h > > > >:-) :-) :-) > > In the days when we defined this header the common consensus was that > atomic types can get typedef'd, somposite structs and unions should not. > I did not followed the recent babbles of the fanatic codingstyle priests > on the lkml, so I don't know the current policy. Removing the typedefs > afterwards from pulic API headers would break userspace applications. The DVB API was originally created by Nokia, and the V3 API header files still retain much of the Nokia coding style. Look at the V4 API stuff and you will see much cleaner code. Please don't take this style bashing personally, but whenever Michael post a bunch of DVB patches to lkml we get flamed for out coding style "bugs". Johannes
[linux-dvb] Re: [RFC][ANNOUNCE] blindscan: auto search everything
Roberto Ragusa wrote:
>
> OK, so I propose this:
>
> - you use FE_SET_FRONTEND as usual
> - then, you call FE_SET_AUTO_SEARCH passing something as
>
> struct dvb_autosearch {
> fe_autosearch_t parameter;
> __u32 lower limit;
> __u32 higher limit;
> }
>
> typedef enum fe_autosearch_t {
> FE_AUTO_SYMBOL_RATE
> }
>
> - then you use FE_GET_FRONTEND to read the sr
If I understand it correctly, all parameters passed
to FE_SET_FRONTEND would be set to AUTO, except for the
frequency? If so, then it would make more sense to me
to add the frequency to struct dvb_autosearch, and not
use FE_SET_FRONTEND for scanning.
This also needs to avoid the zigzag scan which FE_SET_FRONTEND
normally does.
(BTW, typedefs are deprecated for kernel code (only allowed
for explicitly opaque data types)).
> Thinking about it, we're converging to the original idea
> from Holger.
> But we shouldn't merge all the paramers together as he has done
> in his example, so we save hw independence.
>
> He proposed many ioctl (START_SCAN, CONTINUE_SCAN, STOP_SCAN),
> and they may be useful in the future even if they are not needed
> at the moment.
These are only useful if the hardware can indeed scan a frequency
range automatically. If not, they are useless as userspace can
only check (a small band around) one frequency, and retrieve the
result (no signal, or a full parameter set). So please check
the data sheets again (for mt352 and mt312) to see if this is
true.
Johannes
[linux-dvb] Re: Possible bug in dvb_frontend.c [Was: "Video datastream brocken" - origin (maybe) found]
Alfred Zastrow wrote: > Johannes Stezenbach wrote: > > >>I tried this patch in the 2.4_branch of dvb-kernel and it doesn't solves > >>my problem with my two rev. 1.3-cards. The first (vdr-)recording after a > >>cold boot got disturbed. > >>My workaround right now is the usage of the (attached) old frontend > >>driver. > > >It doesn't help if you repost that old driver. What would help > >would be if you (or someone else who can reproduce the problem) > >would try to find out what difference between both drivers > >causes the problem, by gradually copying code snippets back and > >forth until either the old driver stops working or the new one works. > > You are right. > > I will begin with that this evening. I used to hope that there would be > a solution to save this work, because my vdr-box is only accessible via > network. > > It has neither a monitor nor a keyboard attached und it has only a > runtime system. I have to cross-compile everything. ;-) I see. As you have a working solution there is no need for you to hurry -- there a re also others who share the problem and could do some testing. But in the end someone will have to do the work... It's always like that. Johannes
[linux-dvb] Re: RE : Re: RE : Re: small modification to scan utilfrom dvb-apps
Sergei Haller wrote: > On Tue, 3 Aug 2004, Johannes (J) wrote: > > J> ... and VDR reads MHz ... > > man 5 vdr: > > > > >Frequency > > The transponder frequency (as an integer). For DVB-S this > > value is in MHz. For DVB-C and DVB-T it can be given either > > in MHz, kHz or Hz (the actual value given will be > > multiplied by 1000 until it is larger than 100). So VDR is trying to be smart... I was just looking at the channels.conf.cable distributed with VDR, which has MHz and works for me. Johannes
