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]
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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 copiedpasted
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
[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
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
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
Eric DEZERT wrote:
Can this modification be included in dvb-apps ?
No. dvbscan outputs MHz, and VDR reads MHz. You patch
would break it.
Johannes
--- /tmp/dump-vdr.c 2004-08-03 07:55:13.0 +0200
+++ /root/dvb-apps/util/scan/dump-vdr.c 2004-07-17 01:08:08.0 +0200
@@ -83,7
Roberto Ragusa wrote:
diff -ur /aaa/bbb/ccc-1.3 /aaa/bbb/ccc-1.3_modified mypatch.diff
(u=human readable, r=recursive)
Please always add -p (--show-c-function), it makes patches
much more readable.
Johannes
Eddie Olsson wrote:
All swedish stations and transmitters in a single file. I can split this
up if that would suite you guys better.
Yes, please. Give me patch that I can apply, or a tar ball with
properly named files.
Johannes
Alfred Zastrow 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
Roberto Ragusa wrote:
Johannes Stezenbach [EMAIL PROTECTED] wrote:
We were pretty sloppy when accepting patches in the past, however
DVB code is under public scrutiny on lkml, and C++ comments are
not accepted for kernel code.
OK, I simply tried to use the style of the rest of the file
Roberto Ragusa wrote:
Holger Waechtler [EMAIL PROTECTED] wrote:
struct dvb_fe_scan_spec {
unsigned freq_start;
unsigned freq_end;
unsigned srate_start;
unsigned srate_end;
}
A similiar approach works for the mt352 DVB-T demod, there the srate
fields are not
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
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
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
1 - 100 of 877 matches
Mail list logo
