Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Oliver Endriss]

Mauro Carvalho Chehab wrote:
 IMO, we should really focus on some code proposition and work on it, until 
 have most of us happy, not risking break any driver.
 
 That's said, we should really try to cope together for having a solution.
 
 From my side, I've actively reviewed all Markus patch series. The changes 
 are not so big, but, since he replaced the usage of the main dvb frontend 
 struct to a newer one, all drivers needed to be changed. His series looks 
 ok, but, as touches on all frontends, the internal API should be tested 
 for all drivers.

I did some quick tests with Markus' patchset. Cards which use the
stv0299 frontend cause an kernel oops. While it is not hard to fix,
it proves that the patchset really breaks some drivers...

 The proposed an alternative patch series I've worked were just adding the 
 newer fields needed from his approach into dvb_frontend struct.
 
 My suggestion is to you all to take a look on those changes. If the 
 direction (on Marcus original series or on my series) is ok, we can 
 improve the corresponding patch series as needed, with contributions from 
 the developers.
 
 The API changes(*) on my proposed series are all at:
 
   http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch
 
 (*) Please ignore the removal of xc3028.c from the patch above - The 
 driver were renamed on Markus tree and moved to another directory. If all 
 accept this approach, I will move that part to the patch that creates 
 tuner-xc3028.c.

Is this approach ok for the v4l people?

Adding new private pointers to struct dvb_frontend is cheap and _cannot_
break any existing driver. For me this is the preferable way to go.
(Maybe you should prefix the new fields with the name of the component
which will use the pointer, as it was done for tuner_priv, sec_priv etc)

What was the reason not to use this approach in the first place?

CU
Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/



___
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

[Markus Rechberger]

On 5/19/07, Oliver Endriss [EMAIL PROTECTED] wrote:

Mauro Carvalho Chehab wrote:
 IMO, we should really focus on some code proposition and work on it, until
 have most of us happy, not risking break any driver.

 That's said, we should really try to cope together for having a solution.

 From my side, I've actively reviewed all Markus patch series. The
changes
 are not so big, but, since he replaced the usage of the main dvb frontend
 struct to a newer one, all drivers needed to be changed. His series looks
 ok, but, as touches on all frontends, the internal API should be tested
 for all drivers.

I did some quick tests with Markus' patchset. Cards which use the
stv0299 frontend cause an kernel oops. While it is not hard to fix,
it proves that the patchset really breaks some drivers...



Thanks alot for testing and pointing to that problem I added another
patchset which should fix that issue.


 The proposed an alternative patch series I've worked were just adding the
 newer fields needed from his approach into dvb_frontend struct.

 My suggestion is to you all to take a look on those changes. If the
 direction (on Marcus original series or on my series) is ok, we can
 improve the corresponding patch series as needed, with contributions from
 the developers.

 The API changes(*) on my proposed series are all at:

http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch

 (*) Please ignore the removal of xc3028.c from the patch above - The
 driver were renamed on Markus tree and moved to another directory. If all
 accept this approach, I will move that part to the patch that creates
 tuner-xc3028.c.

Is this approach ok for the v4l people?

Adding new private pointers to struct dvb_frontend is cheap and _cannot_
break any existing driver. For me this is the preferable way to go.
(Maybe you should prefix the new fields with the name of the component
which will use the pointer, as it was done for tuner_priv, sec_priv etc)

What was the reason not to use this approach in the first place?



The reason is that alot work already relies on it and given the fact
that earlier discussions lead nowhere it's time to face the
sideeffect. As I wrote requests from my side are over now, I'm going
on with development again,

Markus

___
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

[Uwe Bugla]

Am Freitag, 18. Mai 2007 08:33 schrieben Sie:
 Sollte ich von dir auf der video4linux Mailingliste oder DVB
 Mailingliste noch einmal eine beleidigende Mail mir gegenüber sehen
 werde ich rechtliche Schritte gegen Dich einleiten welche auch mit
 Kosten verbunden sind.

 Es ist nicht tragbar das du öffentlich Rufschädigung betreibst,
 niemand der von dir genannten Personen hat Dir irgendetwas
 persönliches getan.

Irrtum, Herr Rechberger:
Ins Pinnacle-Forum zum Beispiel habe ich monatelange Arbeit investiert, und 
zwar nicht per Geschwätz, sondern de Facto: Ich habe Treiber gebaut, dort 
reingestellt, sie in meiner Freizeit betreut, Useranfragen bearbeitet, 
unbezahlte Hilfestellung geleistet und so viel mehr.
Die ganze Schmutzarbeit gemacht, monatelang.
Ohne auch nur eine Sekunde lang nach Geld zu fragen.

Gäbe es Leute wie mich nicht, wüssten die dortigen User bis heute nicht, wie 
man überhaupt Linux schreibt - das ist eine Tatsache.

Administrationsrechte oder Moderatorenrechte habe ich dort bis heute nicht 
gesehen, aus welchem Grund auch immer.
Stattdessen hat man mir eine Person vor die Nase gesetzt, die mich erst am 
Telefon ausgehorcht hat. Im Gefolge hat diese Person beflissentlich alle 
meine Beiträge nach Gutsherrenart behandelt, und solange gemobbt, in der 
Hoffnung, dass ich endlich verschwinde.

Es ist schlichtweg die unterste denkbare Stufe, so etwas überhaupt nur auf 
einer IRC-Chatliste zu zitieren, ohne auch nur eine Sekunde lang nach dem 
Wieso, Warum, Weshalb zu fragen.
Jeder halbwegs intelligente Mensch fragt erstmal nach, bevor er so etwas tut.
Sind die Motive, so etwas zu tun, erklärtermassen niedrigster Natur, werden 
natürlich alle weiteren Fragen in dieser Richtung erst gar nicht gestellt.
Man will seine Ellenbogen durchsetzen, koste es, was es wolle.
Und wer sich nicht beugt, der wird gemobbt. Und auch noch bedroht.

Doch mit dem Missbrauch von Forum-Links zur Diskreditierung anderer Personen, 
ohne auch nur ansatzweise die Frage nach dem Wieso und Warum zu stellen (in 
dem Fall betrifft es meine Person, und das genau IST Rufschädigung) scheint 
es noch nicht genug zu sein:

Es ist eine Tatsache, Herr Rechberger, dass SIE persönlich der treibende 
Faktor waren, sind und bleiben, als es darum ging, eine lang ersehnte 
Versorgungslücke im Sinne von besserer Qualität dadurch zu etablieren, dass 
linuxtv.org endlich einen erfahrenen eigenständigen DVB maintainer bekommt 
und mithin eine fähige und eloquente Person, die von der Materie am meisten 
versteht. Erklärtermassen mehr als SIE jedenfalls.

Es ist ferner unerträglich und in keinster Weise hinnehmbar, dass IHNEN, Herr 
Rechberger, auf diesem Wege auch noch Mauro Carvalho Chehab gefolgt ist.
Den Schaden, der dadurch angerichtet wird, trägt nicht nur die komplette 
linuxtv-Nutzergemeinde, sondern darüberhinaus die zentrale Kernelverwaltung 
in direkter Konsequenz.

Wenn die Dummheit über die Intelligenz siegt, nennt man das Barbarei.
Wer aus Deutschland oder Österreich stammt, sollte dies eigentlich ganz genau 
wissen, so er seine eigene Geschichte überhaupt kennt.

 Dies ist die einzige und letzte Warnung, sollte ich noch irgendetwas
 sehen werde ich die notwendigen Schritte gegen Dich einleiten.
 Es gibt derzeit bereits eine Mail wo dies bereits mit mehreren Leuten
 diskutiert wird.

Yep. Und damit diese mehreren Leute auch den Sachverhalt verstehen, mache ich 
diese Drohung hiermit öffentlich. Wer eine Übersetzung ins Englische 
benötigt, darf mich gerne darum bitten.
Ich werde weder Zeit noch Mühe scheuen, diese Klarstellung ins Englische zu 
übersetzen, so Bedarf besteht, die Dinge zu klären, wie sie wirklich sind, 
und eben nicht so, wie SIE, Herr Rechberger, sie gerne hätten.

Die komplettermassen sachlich völlig entleerte Schmutzpropaganda, die SIE, 
Herr Rechberger, in Bezug auf die Herren Krufky und Abraham in 
deutschsprachigen Foren zu verantworten haben, in denen Ihr Name als 
deutlicher und alleiniger Autor zu lesen ist, sei hierbei nur am Rande 
erwähnt.

Ich möchte ferner darauf hinweisen, dass nicht nur ich persönlich in privaten 
Mails mehrfach mit freundlichstem Unterton versucht habe, IHNEN, Herr 
Rechberger, so etwas wie eine goldene Brücke zu bauen.
Offensichtlich vergeblich, denn gegen Sturheit und Ellenbogenmentalität kommt 
das beste Argument, ein Höchstmaß an Eloquenz offensichtlich nicht an.


 Gruß,
 Markus

Mit freundlichen Grüssen

Uwe Bugla

P. S.: Ich bin bescheiden: Eine öffentliche Entschuldigung gegenüber den 
betroffenen Leuten, ein eleganter Schritt zurück, tut es voll und ganz.
Es muss nur ernst gemeint sein, und deutlich und unmissverständlich 
rüberkommen, weiter nichts.


 On 5/18/07, Uwe Bugla [EMAIL PROTECTED] wrote:
  Am Donnerstag, 17. Mai 2007 20:30 schrieb Oliver Endriss:
   Markus Rechberger wrote:
On 5/15/07, Oliver Endriss [EMAIL PROTECTED] wrote:
 Markus Rechberger wrote:
  to be more accurate where all the changes happened:
   

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[e9hack]

Uwe Bugla wrote:
 P. S.: Ich bin bescheiden: Eine öffentliche Entschuldigung gegenüber den 
 betroffenen Leuten, ein eleganter Schritt zurück, tut es voll und ganz.
 Es muss nur ernst gemeint sein, und deutlich und unmissverständlich 
 rüberkommen, weiter nichts.
 

This is a joke. The guy, which insults everybody, expects that everybody does 
apologize to him...

- Hartmut

___
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

[Uwe Bugla]

Am Freitag, 18. Mai 2007 14:11 schrieb e9hack:
 Uwe Bugla wrote:
  P. S.: Ich bin bescheiden: Eine öffentliche Entschuldigung gegenüber den
  betroffenen Leuten, ein eleganter Schritt zurück, tut es voll und ganz.
  Es muss nur ernst gemeint sein, und deutlich und unmissverständlich
  rüberkommen, weiter nichts.

 This is a joke. The guy, which insults everybody, expects that everybody
 does apologize to him...

 - Hartmut

No, it is not a joke at all, although I know that I am not the friendliest 
person if such strange things happen to me and others.
Above that I did not insult everybody, but only especially two persons, maybe 
three. So please read carefully the context, then state, not vice versa.

The demand behind is to get rid of people who do nothing but play bad and 
compromiseless policy. And if their ellbows have destroyed everything on the 
human layer, then they just keep on by threatening the whole susbsystem as a 
next step. So, on two layers, the human and the technical one, there will be 
nothing but damage and chaos in the end, provoked by those persons.

So if you, Hartmut, and / or others, keep on picking out what they want to 
persevere and simply ignore the rest, then I offer to translate the whole 
thing into English, just for the people watching this and really wanting to 
comprehend the context, which takes work of course.

So please do not take anything personal but just help to avoid superficial 
statements like this one.
Who wants changes first must state what the truth is.
That cannot be done in a friendly way in all situations, as humans are humans, 
and such not perfect at all.

Uwe

P. S.: I fundamentally changed my mind as far as Manu is concerned.
If I can change my mind, then others can also.
Ellbow mentalities and stubborn minds do seem to be hopeless in this case.
I never intended to ever insult Markus or others.
But there are behaviours in fact as far as the mentioned persons are 
concerned, who do not offer you any kind of choice when you ask yourself how 
to deal with them. In so far flames seem to be inevitable, unfortunately.
Its also a basic necessity to stop ellbow oriented stubborn people in order to 
prevent damage from the whole community. To ensure this, one must go upright 
instead of stating superficial remarks ripped out of a voluntary context.


 ___
 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] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Michael Krufky]

Uwe Bugla wrote:
 Am Freitag, 18. Mai 2007 14:11 schrieb e9hack:
 Uwe Bugla wrote:
 P. S.: Ich bin bescheiden: Eine öffentliche Entschuldigung gegenüber den
 betroffenen Leuten, ein eleganter Schritt zurück, tut es voll und ganz.
 Es muss nur ernst gemeint sein, und deutlich und unmissverständlich
 rüberkommen, weiter nichts.
 This is a joke. The guy, which insults everybody, expects that everybody
 does apologize to him...

 - Hartmut
 
 No, it is not a joke at all, although I know that I am not the friendliest 
 person if such strange things happen to me and others.
 Above that I did not insult everybody, but only especially two persons, maybe 
 three. So please read carefully the context, then state, not vice versa.
 
 The demand behind is to get rid of people who do nothing but play bad and 
 compromiseless policy. And if their ellbows have destroyed everything on the 
 human layer, then they just keep on by threatening the whole susbsystem as a 
 next step. So, on two layers, the human and the technical one, there will be 
 nothing but damage and chaos in the end, provoked by those persons.
 
 So if you, Hartmut, and / or others, keep on picking out what they want to 
 persevere and simply ignore the rest, then I offer to translate the whole 
 thing into English, just for the people watching this and really wanting to 
 comprehend the context, which takes work of course.
 
 So please do not take anything personal but just help to avoid superficial 
 statements like this one.
 Who wants changes first must state what the truth is.
 That cannot be done in a friendly way in all situations, as humans are 
 humans, 
 and such not perfect at all.
 
 Uwe
 
 P. S.: I fundamentally changed my mind as far as Manu is concerned.
 If I can change my mind, then others can also.
 Ellbow mentalities and stubborn minds do seem to be hopeless in this case.
 I never intended to ever insult Markus or others.
 But there are behaviours in fact as far as the mentioned persons are 
 concerned, who do not offer you any kind of choice when you ask yourself how 
 to deal with them. In so far flames seem to be inevitable, unfortunately.
 Its also a basic necessity to stop ellbow oriented stubborn people in order 
 to 
 prevent damage from the whole community. To ensure this, one must go upright 
 instead of stating superficial remarks ripped out of a voluntary context.

The only thing that these emails do is cause those people who actually are
interested in developmental discussions to lose interest in reading the mailing
lists.

People are reading a thread, expecting all emails in that thread to be about a
given discussion, and then they wind up on emails like these, causing them to
believe that any productive discussion has ended.

Uwe, I understand that you are trying to help.  Everybody helps in their own
way.  On the contrary, all you've done is cause people like me to stop reading
our email.  If you _really_ want to help, then please just leave us all alone.

-- 
Michael Krufky


___
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

[Tobias Stoeber]

Michael Krufky schrieb:
 The only thing that these emails do is cause those people who
 actually are interested in developmental discussions to lose interest
 in reading the mailing lists.

Fully agreeing. Just to add my 2cent: There are not only developers on 
this list, actively discussing technical problems. There may be also a 
lot of people - like myself - who receive this list for keeping track 
development of some devices and / or changes in general.


First of all let me say, that I deeply appreciate anyone's contribution 
and I'm not the person - as I'm only the user of your work - who will 
ever judge on technical problems etc.


For what I've seen, this kind of email-ping-pong, has nothing to do with 
 taking up a certain position and in the end is couterproductive.


It's only the utmost childish behavior, I've seen so far in a mailing 
list - Oh Joe has taken away my toy - No John did. ... those childs 
then go to daddy to complain (or in this case to Linus).


Many emails - especially yours Uwe - go far away from being normal email 
discussions. There is certainly a difference between an argument one has 
in person, face to face and a discussion via email.


There are people who are more easily offended than others. Maybe it 
would just help to


a) THINK, WRITE IT DOWN, LET IT REST for a while (24hrs),
   READ it AGAIN, THINK AGAIN and THEN send it out
b) reduce mails to factual things and technical discussion

It is - in my view - also not excusable that there are mails forwarded 
(in replies) to the list, that have obviously been sent in 'private' 
discussion!


If this were a company's mailing list, certainly there would be a 
'superior person' who would take consequences and some people would get 
fired - REGARDLESS of who was right and who was wrong.


In the real world (workspace) you simly have to comply to certain common 
rules and you HAVE TO work with people. Teasing people or trying to just 
making friends on the one side and enemies on the other won't help at 
all. One time Uwe, Mauro is your enemy and now he your friend again, 
well maybe next week a unpopular decision makes him your enemy again, Uwe?


If you have a point to make, please do this in a rational manner.

If someone in charge of certain things on this list makes a decision, 
accept it or give rational and substantiated reasons why you don't 
accept it or want it changed. And if you've done so, I believe it will 
reached the eyes and minds of the people concerned. But if you just keep 
on picking on people and repeating things over and over again nobody 
will listen (any more, because it just gets boring and annoying).


Quote: That cannot be done in a friendly way in all situations, as 
humans are humans, and such not perfect at all.


That is certainly true, nobody is perfect. And certain things may need 
unfriendly methods - but this does not justify personal insults in 
either direction. Maybe an unfriendly solution would be forking out 
parts of the project or offering your solution on your own server - 
whatever. You are free to do so and I believe nobody would delete a hint 
on the wiki to such a solution, others could try it and if its accepted 
by a certain userbase it would - over time - find its way in.


An old saying goes The cleverer give in, maybe some just should 
remember that. It does not mean, that you should give up. If anyone 
thinks he/she has found a problem, present a solution and give people 
time to test it and think about. Pressing it forward won't help.


Quote: Who wants changes first must state what the truth is.

Only half true. It seems to be common habit - and often found in Germany 
- to loudly state the (assumed) truth. Good thing, well done. Does it 
help? Nooo. Find a solution, rethink this solution and present it in a 
way people can understand it and judge it's value. Often enough you will 
then find for yourself, that it's not a good solution, ot it does need 
more explanation etc.


If you are confident in your solution and/or in the points you have to 
make, you should not have to bloodcurdling scream out loudly. Another 
German saying goes Wer schreit hat unrecht (Who screams is wrong).


I also don't understand why people can/may run mentally amok on the 
internet. People may forget sometime in the future, but not the 
internet. All this crazy stuff will be there for a long time, possibly 
forever. Everone can read it  and maybe time will come when you seek 
a job or just have to work/deal with people, who then type in your name 
and it all will fall back on you - and in this case nobody is interested 
in who started all this and what you will have to say about it.


At least I am not at all interested in figuring it out for this case 
 and I don't think there are many whou would or actually even could!


Best regards, Tobias


Uwe Bugla wrote:


Am Freitag, 18. Mai 2007 14:11 schrieb e9hack:


Uwe Bugla wrote:


P. S.: Ich bin bescheiden: Eine öffentliche 

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[hermann pitton]

Hi,

Am Donnerstag, den 17.05.2007, 17:56 +0200 schrieb hermann pitton:
 Am Montag, den 14.05.2007, 13:39 -0700 schrieb Trent Piepho:
  On Mon, 14 May 2007, Markus Rechberger wrote:
   Hi all,
  
   I exported the patches of my v4l-dvb-experimental repository against
   the current v4l-dvb repository on linuxtv.org.
  
   The single patchfiles are available on mcentral.de
   http://mcentral.de/~mrec/patches/v4l-dvb/
  [93 patches]
 
 actually 78 and on missing 16 i stopped, seeing your clashes already.
 
  It's really hard for anyone to make sense of a patch bomb like this.
  There's just too many changes, and none of the patches even have comments
  longer than one line.
  
  The organization of the patches is really hard to follow too.  For example,
  patch 19 adds a NULL pointer check to tuner-core (why is this necessary?)
  and then also adds two register names names to the dvb zl10353 driver.
  Those changes have nothing to do with each other.  It's patch 20 that
  actually adds the code to zl10353 that uses the new registers, and it even
  changes the names used in patch 19.
  
 
 Trent, any chance to get it up to current level for testing and to make
 next time less hard? I'm willing to waste time (and devices) on it.
 

They at least all apply and testing is possible to give feedback!

I really hope there is a fair and widely accepted solution soon for
Markus, XCeive support is a highly relevant global issue.

Thanks,
Hermann





___
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

[Uwe Bugla]

Am Freitag, 18. Mai 2007 16:44 schrieben Sie:
 Uwe Bugla wrote:
  Am Freitag, 18. Mai 2007 14:11 schrieb e9hack:
  Uwe Bugla wrote:
  P. S.: Ich bin bescheiden: Eine öffentliche Entschuldigung gegenüber
  den betroffenen Leuten, ein eleganter Schritt zurück, tut es voll und
  ganz. Es muss nur ernst gemeint sein, und deutlich und
  unmissverständlich rüberkommen, weiter nichts.
 
  This is a joke. The guy, which insults everybody, expects that everybody
  does apologize to him...
 
  - Hartmut
 
  No, it is not a joke at all, although I know that I am not the
  friendliest person if such strange things happen to me and others.
  Above that I did not insult everybody, but only especially two persons,
  maybe three. So please read carefully the context, then state, not vice
  versa.
 
  The demand behind is to get rid of people who do nothing but play bad and
  compromiseless policy. And if their ellbows have destroyed everything on
  the human layer, then they just keep on by threatening the whole
  susbsystem as a next step. So, on two layers, the human and the technical
  one, there will be nothing but damage and chaos in the end, provoked by
  those persons.
 
  So if you, Hartmut, and / or others, keep on picking out what they want
  to persevere and simply ignore the rest, then I offer to translate the
  whole thing into English, just for the people watching this and really
  wanting to comprehend the context, which takes work of course.
 
  So please do not take anything personal but just help to avoid
  superficial statements like this one.
  Who wants changes first must state what the truth is.
  That cannot be done in a friendly way in all situations, as humans are
  humans, and such not perfect at all.
 
  Uwe
 
  P. S.: I fundamentally changed my mind as far as Manu is concerned.
  If I can change my mind, then others can also.
  Ellbow mentalities and stubborn minds do seem to be hopeless in this
  case. I never intended to ever insult Markus or others.
  But there are behaviours in fact as far as the mentioned persons are
  concerned, who do not offer you any kind of choice when you ask yourself
  how to deal with them. In so far flames seem to be inevitable,
  unfortunately. Its also a basic necessity to stop ellbow oriented
  stubborn people in order to prevent damage from the whole community. To
  ensure this, one must go upright instead of stating superficial remarks
  ripped out of a voluntary context.

 The only thing that these emails do is cause those people who actually are
 interested in developmental discussions to lose interest in reading the
 mailing lists.

 People are reading a thread, expecting all emails in that thread to be
 about a given discussion, and then they wind up on emails like these,
 causing them to believe that any productive discussion has ended.

 Uwe, I understand that you are trying to help.  Everybody helps in their
 own way.  On the contrary, all you've done is cause people like me to stop
 reading our email.  If you _really_ want to help, then please just leave us
 all alone.

Michael,
I've been pointing out technical issues more than once, wioth you CCed.
I did not offer perfect solutions, I instead offered partial solutions or 
simply basic ideas, that's all.

I did experience that you simply ignore those issues, if you either do not 
know an answer, or if you are moody, or perhaps just lazy.

This latest remark done by yourself may contain justified criticism.
I would deeply appreciate you to reflect whether the two last sentences are 
helpful at all.
My answer you can just guess easily.

Uwe

___
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

[Michael Krufky]

Uwe Bugla wrote:
 Am Freitag, 18. Mai 2007 16:44 schrieben Sie:
   
 Uwe Bugla wrote:
 
 Am Freitag, 18. Mai 2007 14:11 schrieb e9hack:
   
 Uwe Bugla wrote:
 
 P. S.: Ich bin bescheiden: Eine öffentliche Entschuldigung gegenüber
 den betroffenen Leuten, ein eleganter Schritt zurück, tut es voll und
 ganz. Es muss nur ernst gemeint sein, und deutlich und
 unmissverständlich rüberkommen, weiter nichts.
   
 This is a joke. The guy, which insults everybody, expects that everybody
 does apologize to him...

 - Hartmut
 
 No, it is not a joke at all, although I know that I am not the
 friendliest person if such strange things happen to me and others.
 Above that I did not insult everybody, but only especially two persons,
 maybe three. So please read carefully the context, then state, not vice
 versa.

 The demand behind is to get rid of people who do nothing but play bad and
 compromiseless policy. And if their ellbows have destroyed everything on
 the human layer, then they just keep on by threatening the whole
 susbsystem as a next step. So, on two layers, the human and the technical
 one, there will be nothing but damage and chaos in the end, provoked by
 those persons.

 So if you, Hartmut, and / or others, keep on picking out what they want
 to persevere and simply ignore the rest, then I offer to translate the
 whole thing into English, just for the people watching this and really
 wanting to comprehend the context, which takes work of course.

 So please do not take anything personal but just help to avoid
 superficial statements like this one.
 Who wants changes first must state what the truth is.
 That cannot be done in a friendly way in all situations, as humans are
 humans, and such not perfect at all.

 Uwe

 P. S.: I fundamentally changed my mind as far as Manu is concerned.
 If I can change my mind, then others can also.
 Ellbow mentalities and stubborn minds do seem to be hopeless in this
 case. I never intended to ever insult Markus or others.
 But there are behaviours in fact as far as the mentioned persons are
 concerned, who do not offer you any kind of choice when you ask yourself
 how to deal with them. In so far flames seem to be inevitable,
 unfortunately. Its also a basic necessity to stop ellbow oriented
 stubborn people in order to prevent damage from the whole community. To
 ensure this, one must go upright instead of stating superficial remarks
 ripped out of a voluntary context.
   
 The only thing that these emails do is cause those people who actually are
 interested in developmental discussions to lose interest in reading the
 mailing lists.

 People are reading a thread, expecting all emails in that thread to be
 about a given discussion, and then they wind up on emails like these,
 causing them to believe that any productive discussion has ended.

 Uwe, I understand that you are trying to help.  Everybody helps in their
 own way.  On the contrary, all you've done is cause people like me to stop
 reading our email.  If you _really_ want to help, then please just leave us
 all alone.
 

 Michael,
 I've been pointing out technical issues more than once, wioth you CCed.
 I did not offer perfect solutions, I instead offered partial solutions or 
 simply basic ideas, that's all.

 I did experience that you simply ignore those issues, if you either do not 
 know an answer, or if you are moody, or perhaps just lazy.

 This latest remark done by yourself may contain justified criticism.
 I would deeply appreciate you to reflect whether the two last sentences are 
 helpful at all.
 My answer you can just guess easily.

 Uwe
   
Uwe,

Just because somebody emails me doesn't mean that I have to reply to them.

For my full time job, my work has absolutely nothing to do with DVB. 
DVB is a hobby of mine, that I enjoy spending some of my personal free
time on.  I do this work because it is an opportunity to be creative in
an area of development different from that which I normally earn a living.

You only have my email address because I use it to sign my changesets
and those changesets in which I sponsor.  I am in this for my own
enjoyment.  I do not wish to take part in any of the drama that you
throw at me, and that is why you haven't seen replies to the private
emails that you sent to me.

If I were to diligently reply to any and every email that is sent to me,
then I would never have the time to touch any code ever again.

I made my choice to participate in open source development.  I did not
make a choice to participate in email drama.

Now you know.

-Mike


___
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

[Markus Rechberger]

On 5/16/07, Manu Abraham [EMAIL PROTECTED] wrote:

hermann pitton wrote:
 Manu,
 


I am writing this reply with quite a lot of reluctance/hesitation, since
some people create unnecessary noise alone: people being stubborn,
practically creating a waste of time for others.

Removing all those CC's since they are already addressed on the ML's.
Sometimes it is better to keep quiet, seeing all those *noise*. The main
issue: half knowledge is too dangerous!

 what do you think already could have a GO?
 
 Markus can't invade like that, but must have a next safe harbour to

 continue to work on it.
 
 The hybrid stuff will invade the planet for long, and then ... die.


Convergence of media is not a new thing. Now it is Analog stuff added
in, the reason for a vendor: it does not make much of a difference in
terms of cost to make a chip like that, but with regards to marketing it
makes a huge difference. Later on, we will be seeing the convergence of
other media as well.

 Do you think to share tuners between digital and analog is really
 impossible, or just wait until these zilliards are gone?

I don't think it is impossible, just that it needs sufficient efforts to
do so. Now there are 2 types of designs, the analog interface is thrown
in additionally into each of them.

1) using a Single chip, bus interface + demodulator + tuner
2) using Two chips, chip1 = bus interface, chip2 = demodulator + tuner
3) using 3 chips, chip1 = bus interface, chip2 = demodulator, chip3 = tuner



I am aware of this constellation, but again I'm refering to the code now.
The dvb subsystem already uses a way to modularize some tuners.
The approach which is implemented in the em28xx/hybrid repository interfaces 
this design and all it does is to abstract the function arguments and adds 
support for it to the analogue framework.

As for the DVB side there is no redesign involved at all with that method, so 
everything else would still work the same way as it worked before.

I'll explain it more detailed:

The dvb framework already uses a broken out tuner approach. The structs look 
like following:

struct dvb_tuner_ops {

   struct dvb_tuner_info info;

   int (*release)(struct dvb_frontend *fe);
   int (*init)(struct dvb_frontend *fe);
   int (*sleep)(struct dvb_frontend *fe);

   /** This is for simple PLLs - set all parameters in one go. */
   int (*set_params)(struct dvb_frontend *fe, struct 
dvb_frontend_parameters *p);

   /** This is support for demods like the mt352 - fills out the supplied 
buffer with what to write. */
   int (*calc_regs)(struct dvb_frontend *fe, struct dvb_frontend_parameters 
*p, u8 *buf, int buf_len);

   int (*get_frequency)(struct dvb_frontend *fe, u32 *frequency);
   int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);

#define TUNER_STATUS_LOCKED 1
   int (*get_status)(struct dvb_frontend *fe, u32 *status);

   /** These are provided seperately from set_params in order to facilitate 
silicon
* tuners which require sophisticated tuning loops, controlling each 
parameter seperately. */
   int (*set_frequency)(struct dvb_frontend *fe, u32 frequency);
   int (*set_bandwidth)(struct dvb_frontend *fe, u32 bandwidth);
};

The updates struct looks like:
struct v4l_dvb_tuner_ops {

   void *priv; /* some privat data for internal use */
   void *dev; /* v4l private data for tuner-core */
   struct dvb_frontend *fe; /* dvb_frontend, for dvb only drivers, internal 
use */

   struct dvb_tuner_info info;

   int (*ioctl)(struct v4l_dvb_tuner_ops *dev, int cmd, int arg);

   int (*release)(struct v4l_dvb_tuner_ops *fe);
   int (*init)(struct v4l_dvb_tuner_ops *fe);
   int (*sleep)(struct v4l_dvb_tuner_ops *fe);

   /** This is for simple PLLs - set all parameters in one go. */
   int (*set_params)(struct v4l_dvb_tuner_ops *fe, struct 
dvb_int_frontend_parameters *p);

   /** This is support for demods like the mt352 - fills out the supplied 
buffer with what to write. */
   int (*calc_regs)(struct v4l_dvb_tuner_ops *fe, struct 
dvb_int_frontend_parameters *p, u8 *buf, int buf_len);

   int (*get_frequency)(struct v4l_dvb_tuner_ops *fe, u32 *frequency);
   int (*get_bandwidth)(struct v4l_dvb_tuner_ops *fe, u32 *bandwidth);

#define TUNER_STATUS_LOCKED 1
   int (*get_status)(struct v4l_dvb_tuner_ops *fe, u32 *status);

   /** These are provided seperately from set_params in order to facilitate 
silicon
* tuners which require sophisticated tuning loops, controlling each 
parameter seperately. */
   int (*set_frequency)(struct v4l_dvb_tuner_ops *fe, u32 frequency);
   int (*set_bandwidth)(struct v4l_dvb_tuner_ops *fe, u32 bandwidth);

   int (*set_mode)(struct v4l_dvb_tuner_ops *dev, struct 
dvb_int_frontend_parameters *params);
};

So the parameters change to not directly having a dependency to dvb_frontend, 
this is the only change at the dvb framework, of 

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Markus Rechberger]

On 5/17/07, Michael Krufky [EMAIL PROTECTED] wrote:

Mauro Carvalho Chehab wrote:

 I do frown upon code duplication, however, in this case it is a safer
 alternative to the one currently on the table.  Earlier versions of
 the xc3028 tuner driver were bound to the video4linux tuner.ko
 module, for the sake of tuning analog television stations.  There was
 a wrapper present inside the em2880-dvb driver that allowed the dvb
 subsystem to access the xc3028 via tuner.ko.  I am not a big fan of
 this solution, however, it does not touch any core subsystem code.
 DVB-only devices can use a separate module in order to access the
 xc3028 without imposing dependencies on the v4l core.

 Duplicating a driver is not a solution, just a terrible hack. We
 should focus on a way to use the same tuner driver for both Analog and
 Digital TV.

Mauro,

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.



As much as we try to come to an agreement about this right now, I fear
that it will be very difficult -- this debate has gone on for over a
year and reaching an agreement will not be easy.

I think that the only way to move forward while keeping everybody happy
would be to proceed in the following order:

1) merge xc3028 support into tuner.ko for analog support*

2) break apart tuner.ko into modularized sub-modules*

3) add xc3028-fe.ko module for dvb-only support**

4) merge in updates to the em28xx driver***

5) add xc3028 support to other card drivers***

6) restart discussions about hybrid / tuner inter-subsystem API

7) apply changes agreed upon in step 6, to migrate the tuner modules to
the new tuner internal api, while removing the duplicated xc3028 module.


*(1) and (2) may be reversed

** http://linuxtv.org/~mkrufky/xc-bluebird.patch

*** analog functionality should use tuner.ko only
*** digital functionality should use xc3028-fe.ko only

---

Please take note, that if we proceed in the order above, this will allow
us to merge the majority of Markus' changes, leaving only the api
changes behind.  At this point, the remainder of the changesets will be
MUCH smaller, and much easier to review.

Under the conditions that we'll be under after step 5, it will be much
more conducive to a productive developer discussion on the issue.

At this point, there has been so much noise about this topic, that I
feel confident that many developers will be able to participate in this
review.  I, for one, would love to have this taken care of, and put this
issue behind us.

After step 5, with the majority of the changesets already being merged,
the pressure on the author and reviewers will be lessened, and
discussions should be able to take place with clear heads.

What I am asking for here is very sensible --  This should not be
difficult for everybody to agree to.  It allows us to merge in changes
one step at a time, while adding support for all devices gradually.
Through this means, we will ultimately achieve the goal of being able to
discuss the actual requirements and reasons for why Markus is making
this proposal to change the tuner api.

I repeat:  huge changes will never blow over well.  The only way to do
this in small steps is to do it in such a way that I've described in
this email.

If you simply shoot me down for the idea of temporarily having a
separate dvb module for the dvb subsystem to interface with the xc3028
tuner,  then you are not seeing the big picture.

Regards,

Mike Krufky






--
Markus Rechberger

___
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

[Johannes Stezenbach]

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] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Markus Rechberger]

On 5/17/07, Johannes Stezenbach [EMAIL PROTECTED] wrote:

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.




I have some other work pending which relies on this too since I don't
want to get stuck I want to get forward asap.
The reason why I redid it back than was I tried to find a better
solution and in case of that I'm fine with that solution now since it
works flawlessly with the saa7134 and cx88 too.
The last discussion before this one was to get the patches ready for
merging with the upstream code, I exported it again and now again it's
having a hard time. I just one more time spent another full day with
doing and testing all that.

This is not acceptable for me anymore, and I'm very sure that this
time wasting mentality will go on with other projects too which join
the current linuxtv project.

I seriously discussed this way in private with some developers,
surprisingly some of them had nearly the same idea as I wrote already.
There are many ways devices can be built, there will never be one way
which will cover all board designs, Manu listed some possibilities,
maybe he should also have written what about devices which do not have
a tuner either and are directly fed with input data. My current work
is based on what is available now on the market.
All the tuners which are written as dvb tuner modules at the moment
are i2c tuners, using dvb_attach it's still possible to override the
structs with completly different callbacks.

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.

I'm very sure almost noone even had a look at the code. Since around 1
1/2 years there hasn't been any solution, linuxtv can go for another
10 years I don't mind but then without em28xx(analogue/digital)
support which is very popular at the moment, and also lacking support
for the xc3028 hybrid devices.

Markus

___
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

[Johannes Stezenbach]

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

[Markus Rechberger]

On 5/17/07, Johannes Stezenbach [EMAIL PROTECTED] wrote:

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.



It's ok I won't write another further replies about it and I do not
share this opinion since during the history there have been enough
offers from my side to include the code.

bye,
Markus

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[hermann pitton]

Am Montag, den 14.05.2007, 13:39 -0700 schrieb Trent Piepho:
 On Mon, 14 May 2007, Markus Rechberger wrote:
  Hi all,
 
  I exported the patches of my v4l-dvb-experimental repository against
  the current v4l-dvb repository on linuxtv.org.
 
  The single patchfiles are available on mcentral.de
  http://mcentral.de/~mrec/patches/v4l-dvb/
 [93 patches]

actually 78 and on missing 16 i stopped, seeing your clashes already.

 It's really hard for anyone to make sense of a patch bomb like this.
 There's just too many changes, and none of the patches even have comments
 longer than one line.
 
 The organization of the patches is really hard to follow too.  For example,
 patch 19 adds a NULL pointer check to tuner-core (why is this necessary?)
 and then also adds two register names names to the dvb zl10353 driver.
 Those changes have nothing to do with each other.  It's patch 20 that
 actually adds the code to zl10353 that uses the new registers, and it even
 changes the names used in patch 19.
 

Trent, any chance to get it up to current level for testing and to make
next time less hard? I'm willing to waste time (and devices) on it.

Greetings,
Hermann






___
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

[Mauro Carvalho Chehab]

Michael,

On Wed, 16 May 2007, Michael Krufky wrote:


Mauro Carvalho Chehab wrote:



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.

As much as we try to come to an agreement about this right now, I fear
that it will be very difficult -- this debate has gone on for over a
year and reaching an agreement will not be easy.

Please take note, that if we proceed in the order above, this will allow
us to merge the majority of Markus' changes, leaving only the api
changes behind.  At this point, the remainder of the changesets will be
MUCH smaller, and much easier to review.

If you simply shoot me down for the idea of temporarily having a
separate dvb module for the dvb subsystem to interface with the xc3028
tuner,  then you are not seeing the big picture.


I think you have only a partial view of the big picture.

We should remind that we've started discussing a common code for tuners 
even before Markus iniciative, when we've re-designed tuner-simple to look 
like dvb-pll in a way that the same code could handle both functions.


Every time someone tries to work on this direction, people run away, 
opting to the path of duplicating the code. Until now, the argues in favor 
of the duplication relies in the fact that the duplicated code on dvb-pll 
and tuner-simple is not big. For xc3028, however, it is a big code 
duplication. Also, I can't foresee any hope on a common code in the near 
future if we go to the duplication path.


To make things worse, duplicating xc3028 code means a complete rework on 
em28xx code. This doesn't seem to be good and won't solve the issue.


IMO, we should really focus on some code proposition and work on it, until 
have most of us happy, not risking break any driver.


That's said, we should really try to cope together for having a solution.

From my side, I've actively reviewed all Markus patch series. The changes 
are not so big, but, since he replaced the usage of the main dvb frontend 
struct to a newer one, all drivers needed to be changed. His series looks 
ok, but, as touches on all frontends, the internal API should be tested 
for all drivers.


The proposed an alternative patch series I've worked were just adding the 
newer fields needed from his approach into dvb_frontend struct.


My suggestion is to you all to take a look on those changes. If the 
direction (on Marcus original series or on my series) is ok, we can 
improve the corresponding patch series as needed, with contributions from 
the developers.


The API changes(*) on my proposed series are all at:

http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch

(*) Please ignore the removal of xc3028.c from the patch above - The 
driver were renamed on Markus tree and moved to another directory. If all 
accept this approach, I will move that part to the patch that creates 
tuner-xc3028.c.


Cheers,
Mauro.

___
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

[Oliver Endriss]

Markus Rechberger wrote:
 On 5/15/07, Oliver Endriss [EMAIL PROTECTED] wrote:
  Markus Rechberger wrote:
   to be more accurate where all the changes happened:
b/linux/drivers/media/tuners/Kconfig|   14
b/linux/drivers/media/tuners/Makefile   |7
b/linux/drivers/media/tuners/xc3028-tuner.c |  601 
b/linux/drivers/media/tuners/xc3028-tuner.h |   20
b/linux/drivers/media/video/em28xx/em2880-dvb.c |  748 
b/linux/drivers/media/video/em28xx/em28xx-audio.c   |  439 ++
b/linux/drivers/media/video/em28xx/em28xx-webcam.c  |  365 ++
b/linux/include/media/v4l_dvb_tuner.h   |  131
linux/Documentation/video4linux/CARDLIST.cx88   |3
linux/Documentation/video4linux/CARDLIST.em28xx |   69
linux/Documentation/video4linux/CARDLIST.tuner  |1
linux/drivers/media/Kconfig |2
linux/drivers/media/Makefile|1
linux/drivers/media/common/ir-keymaps.c |  221 +
linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c |   21
linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c   |   34
linux/drivers/media/dvb/dvb-core/dmxdev.c   |6
linux/drivers/media/dvb/dvb-core/dmxdev.h   |1
linux/drivers/media/dvb/dvb-core/dvb_demux.c|3
linux/drivers/media/dvb/dvb-core/dvb_demux.h|3
linux/drivers/media/dvb/dvb-core/dvb_frontend.c |   29
linux/drivers/media/dvb/dvb-core/dvb_frontend.h |   64
linux/drivers/media/dvb/dvb-core/dvb_net.c  |   29
linux/drivers/media/dvb/dvb-core/dvb_net.h  |1
linux/drivers/media/dvb/dvb-usb/af9005-fe.c |   12
linux/drivers/media/dvb/dvb-usb/au6610.c|3
linux/drivers/media/dvb/dvb-usb/cxusb.c |  150
linux/drivers/media/dvb/dvb-usb/cxusb.h |2
linux/drivers/media/dvb/dvb-usb/dib0700_devices.c   |7
linux/drivers/media/dvb/dvb-usb/dibusb-common.c |6
linux/drivers/media/dvb/dvb-usb/dibusb-mb.c |   17
linux/drivers/media/dvb/dvb-usb/digitv.c|7
linux/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c   |   11
linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h   |2
linux/drivers/media/dvb/dvb-usb/dvb-usb.h   |8
linux/drivers/media/dvb/dvb-usb/gl861.c |3
linux/drivers/media/dvb/dvb-usb/m920x.c |   14
linux/drivers/media/dvb/dvb-usb/opera1.c|3
linux/drivers/media/dvb/dvb-usb/ttusb2.c|3
linux/drivers/media/dvb/dvb-usb/umt-010.c   |3
linux/drivers/media/dvb/frontends/at76c651.c|2
linux/drivers/media/dvb/frontends/bsbe1.h   |3
linux/drivers/media/dvb/frontends/bsru6.h   |3
linux/drivers/media/dvb/frontends/cx22700.c |2
linux/drivers/media/dvb/frontends/cx22702.c |2
linux/drivers/media/dvb/frontends/cx24110.c |2
linux/drivers/media/dvb/frontends/dib3000mb.c   |2
linux/drivers/media/dvb/frontends/dib3000mc.c   |2
linux/drivers/media/dvb/frontends/dib7000m.c|2
linux/drivers/media/dvb/frontends/dib7000p.c|2
linux/drivers/media/dvb/frontends/dvb-pll.c |   65
linux/drivers/media/dvb/frontends/dvb-pll.h |   19
linux/drivers/media/dvb/frontends/dvb_dummy_fe.c|2
linux/drivers/media/dvb/frontends/l64781.c  |2
linux/drivers/media/dvb/frontends/lgdt330x.c|6
linux/drivers/media/dvb/frontends/mt2060.c  |   43
linux/drivers/media/dvb/frontends/mt2060.h  |6
linux/drivers/media/dvb/frontends/mt312.c   |2
linux/drivers/media/dvb/frontends/mt352.c   |   15
linux/drivers/media/dvb/frontends/mt352.h   |3
linux/drivers/media/dvb/frontends/nxt200x.c |2
linux/drivers/media/dvb/frontends/nxt6000.c |2
linux/drivers/media/dvb/frontends/or51132.c |2
linux/drivers/media/dvb/frontends/qt1010.c  |   59
linux/drivers/media/dvb/frontends/qt1010.h  |4
linux/drivers/media/dvb/frontends/s5h1420.c |6
linux/drivers/media/dvb/frontends/sp8870.c  |2
linux/drivers/media/dvb/frontends/sp887x.c  |4
linux/drivers/media/dvb/frontends/stv0297.c |2
linux/drivers/media/dvb/frontends/stv0299.c |4
linux/drivers/media/dvb/frontends/tda10021.c|2
linux/drivers/media/dvb/frontends/tda10023.c|   

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Uwe Bugla]

Am Donnerstag, 17. Mai 2007 20:30 schrieb Oliver Endriss:
 Markus Rechberger wrote:
  On 5/15/07, Oliver Endriss [EMAIL PROTECTED] wrote:
   Markus Rechberger wrote:
to be more accurate where all the changes happened:
 b/linux/drivers/media/tuners/Kconfig|   14
 b/linux/drivers/media/tuners/Makefile   |7
 b/linux/drivers/media/tuners/xc3028-tuner.c |  601 
 b/linux/drivers/media/tuners/xc3028-tuner.h |   20
 b/linux/drivers/media/video/em28xx/em2880-dvb.c |  748 
 b/linux/drivers/media/video/em28xx/em28xx-audio.c   |  439 ++
 b/linux/drivers/media/video/em28xx/em28xx-webcam.c  |  365 ++
 b/linux/include/media/v4l_dvb_tuner.h   |  131
 linux/Documentation/video4linux/CARDLIST.cx88   |3
 linux/Documentation/video4linux/CARDLIST.em28xx |   69
 linux/Documentation/video4linux/CARDLIST.tuner  |1
 linux/drivers/media/Kconfig |2
 linux/drivers/media/Makefile|1
 linux/drivers/media/common/ir-keymaps.c |  221 +
 linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c |   21
 linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c   |   34
 linux/drivers/media/dvb/dvb-core/dmxdev.c   |6
 linux/drivers/media/dvb/dvb-core/dmxdev.h   |1
 linux/drivers/media/dvb/dvb-core/dvb_demux.c|3
 linux/drivers/media/dvb/dvb-core/dvb_demux.h|3
 linux/drivers/media/dvb/dvb-core/dvb_frontend.c |   29
 linux/drivers/media/dvb/dvb-core/dvb_frontend.h |   64
 linux/drivers/media/dvb/dvb-core/dvb_net.c  |   29
 linux/drivers/media/dvb/dvb-core/dvb_net.h  |1
 linux/drivers/media/dvb/dvb-usb/af9005-fe.c |   12
 linux/drivers/media/dvb/dvb-usb/au6610.c|3
 linux/drivers/media/dvb/dvb-usb/cxusb.c |  150
 linux/drivers/media/dvb/dvb-usb/cxusb.h |2
 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c   |7
 linux/drivers/media/dvb/dvb-usb/dibusb-common.c |6
 linux/drivers/media/dvb/dvb-usb/dibusb-mb.c |   17
 linux/drivers/media/dvb/dvb-usb/digitv.c|7
 linux/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c   |   11
 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h   |2
 linux/drivers/media/dvb/dvb-usb/dvb-usb.h   |8
 linux/drivers/media/dvb/dvb-usb/gl861.c |3
 linux/drivers/media/dvb/dvb-usb/m920x.c |   14
 linux/drivers/media/dvb/dvb-usb/opera1.c|3
 linux/drivers/media/dvb/dvb-usb/ttusb2.c|3
 linux/drivers/media/dvb/dvb-usb/umt-010.c   |3
 linux/drivers/media/dvb/frontends/at76c651.c|2
 linux/drivers/media/dvb/frontends/bsbe1.h   |3
 linux/drivers/media/dvb/frontends/bsru6.h   |3
 linux/drivers/media/dvb/frontends/cx22700.c |2
 linux/drivers/media/dvb/frontends/cx22702.c |2
 linux/drivers/media/dvb/frontends/cx24110.c |2
 linux/drivers/media/dvb/frontends/dib3000mb.c   |2
 linux/drivers/media/dvb/frontends/dib3000mc.c   |2
 linux/drivers/media/dvb/frontends/dib7000m.c|2
 linux/drivers/media/dvb/frontends/dib7000p.c|2
 linux/drivers/media/dvb/frontends/dvb-pll.c |   65
 linux/drivers/media/dvb/frontends/dvb-pll.h |   19
 linux/drivers/media/dvb/frontends/dvb_dummy_fe.c|2
 linux/drivers/media/dvb/frontends/l64781.c  |2
 linux/drivers/media/dvb/frontends/lgdt330x.c|6
 linux/drivers/media/dvb/frontends/mt2060.c  |   43
 linux/drivers/media/dvb/frontends/mt2060.h  |6
 linux/drivers/media/dvb/frontends/mt312.c   |2
 linux/drivers/media/dvb/frontends/mt352.c   |   15
 linux/drivers/media/dvb/frontends/mt352.h   |3
 linux/drivers/media/dvb/frontends/nxt200x.c |2
 linux/drivers/media/dvb/frontends/nxt6000.c |2
 linux/drivers/media/dvb/frontends/or51132.c |2
 linux/drivers/media/dvb/frontends/qt1010.c  |   59
 linux/drivers/media/dvb/frontends/qt1010.h  |4
 linux/drivers/media/dvb/frontends/s5h1420.c |6
 linux/drivers/media/dvb/frontends/sp8870.c  |2
 linux/drivers/media/dvb/frontends/sp887x.c  |4
 linux/drivers/media/dvb/frontends/stv0297.c |2
 linux/drivers/media/dvb/frontends/stv0299.c |

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Markus Rechberger]

Hi Hermann,

On 5/16/07, hermann pitton [EMAIL PROTECTED] wrote:

Am Dienstag, den 15.05.2007, 19:00 +0200 schrieb Markus Rechberger:
 On 5/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
   If I compare that solution with the
  solution I provided your one is
   only half way done, you add a dependency for a structure which will
   never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will
   be used).
 
  As I said, this is a sugestion. For sure, improvements can be done.
  The main point is not risking breaking other drivers.
 
   If you look at v4l_dvb_tuner_ops it's clear what it intends to be and
   in no way it adds extra struct definitions which do not belong there,
   if you look at dvb_frontend in tuner-core.c it has nothing to do with
   the tuner, it also contains the callbacks for the digital demod.
  
   It also requires all the dvb headers.
   #include dvb_frontend.h
  
   #include linux/dvb/frontend.h
   #include dvbdev.h
  
   dvbdev.h is not needed at all either, even if gcc might wipe out the
   defined functions because they're not used.
 
  I can't see any troubles including those headers, except for a slower
  compilation. Later, somebody may write a patch reorganizing the
includes.
 
   We shouldn't care about hacks to keep the noise on the ML low, put the
   technical aspect (which includes a solution for all the requirements)
   infront of everything then I might agree with your patch.
 
  It is not a matter of keeping noise low, but, instead, avoid breaking
  existing drivers. This is a technical issue: smaller changes means less
  lines to check, and more unlikely to break an existing driver.
 

 I really understand that issue I just want to point to the saa7114
 changes which broke the em28xx MSI devices in the kernel, there was
 neither a revert or something else. If I'd have to rate the patch I
 sent to the v4l maintainer list I'd give it 3/10 pts. the driver is
 still broken even in the v4l-dvb-experimental repository since I
 haven't ported that change from the v4l-dvb-kernel repository to the
 experimental one yet. It's important to avoid breaking devices that
 for it should be tested and discussed. But again I see everyone here
 is writing around the whole issue. Oliver wrote that the patches are
 too big and that it will take alot time to review them (it was also
 alot time to write them, so telling me about a time factor is more
 than unfair).
 I suggest to get your hands dirty with it and start to test it and
 comment the outstanding points I wrote in the first email.


Manu,

what do you think already could have a GO?

Markus can't invade like that, but must have a next safe harbour to
continue to work on it.

The hybrid stuff will invade the planet for long, and then ... die.

Do you think to share tuners between digital and analog is really
impossible, or just wait until these zilliards are gone?

Why, please? GNU/Linux is surely dead on this after it.



As for this why rely on another developer? Please go through the
source and get your own opinion about it.
Manu has a voice too but noone should rely on what another developer
writes here, I'd strongly appreciate if someone would start to review
it and those who don't understand something feel free to ask about the
specific parts on the ML.

Silently I took care about some parts from earlier discussions, for
example where Mike called the em2880-dvb driver to be wrong, I
recognized what he tried to explain and finally removed the demod
duplication from that driver.
Back then it would have been more helpful to just write, why don't you
put the demod parameters which are currently missing into the demod
drivers? This little sentence would have improved that part without
writing around that issue and letting me guess what he meant. In the
end I have to write that this idea was the right way to go.

Markus

___
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

[Manu Abraham]

hermann pitton wrote:
 Manu,
 

I am writing this reply with quite a lot of reluctance/hesitation, since
some people create unnecessary noise alone: people being stubborn,
practically creating a waste of time for others.

Removing all those CC's since they are already addressed on the ML's.
Sometimes it is better to keep quiet, seeing all those *noise*. The main
issue: half knowledge is too dangerous!

 what do you think already could have a GO?
 
 Markus can't invade like that, but must have a next safe harbour to
 continue to work on it.
 
 The hybrid stuff will invade the planet for long, and then ... die.

Convergence of media is not a new thing. Now it is Analog stuff added
in, the reason for a vendor: it does not make much of a difference in
terms of cost to make a chip like that, but with regards to marketing it
makes a huge difference. Later on, we will be seeing the convergence of
other media as well.

 Do you think to share tuners between digital and analog is really
 impossible, or just wait until these zilliards are gone?

I don't think it is impossible, just that it needs sufficient efforts to
do so. Now there are 2 types of designs, the analog interface is thrown
in additionally into each of them.

1) using a Single chip, bus interface + demodulator + tuner
2) using Two chips, chip1 = bus interface, chip2 = demodulator + tuner
3) using 3 chips, chip1 = bus interface, chip2 = demodulator, chip3 = tuner

the usage in case 1) is highly vendor specific and we can't say much
about it. ie, it might be a certain way from vendor A and another way
from vendor B

in 2 cases except for (1), there are each 2 ways a tuner is interfaced

a) on a separate bus
In this case, the tuner is directly connected to an I2C/SPI/GPIO bus. In
this case things are very simple and the tuner is accessible always.
Plain and simple, no hassles in accessing the tuner.

b) on a bus which is private to the demodulator
In this case, the tuner is behind a demodulator, or another device too
(maybe some damned device which is not even a demodulator, even
proprietary ones you can imagine here). In the normal case that we have,
the tuner is just behind the demodulator.

Now the demodulator alone controls access to the tuner. No probes,
nothing will work if the demodulator has disabled access. (ie the tuner
is completely unaccessible without the demodulator control) You can
imagine a road which is blocked by a barrier, which is controlled by an
entity (the demodulator in this case) the access is private to the
demodulator and the demodulator alone has access to the same. How the
access is controlled only the demodulator knows. Some demodulators keep
it open all the time once a request is issued. Some close the access
based on some criteria (again the criteria is device specific)

There are advantages and disadvantages of both these methods.
(a)
* this requires an additional bus, or in some cases the tuner is just on
another address on the same bus
this additional bus in some cases would mean an additional cost, in some
case it could be just some unused GPIO used as bit-banging.

* quite simple hardware as the hardware designer doesn't have to bother
much, since it is a straight forward design
* the downside is that a bus which is left open/unterminated, creates a
lot of noise. Such devices have typically lower SNR and are much
susceptible to noise (gaussian noise is cumulative, ie additive)

(b)
* this on the same bus, just like a barrier on the same road an entity
controlling the barrier
* the advantages in this case are
 1) once the gate is closed, no further communication occurs -- lesser
noise results

One might think: about the amount of noise created @ 100 khz etc, mind
you newer devices all use 400 khz as default, some do even have options
for going faster still (even though the devices what we have now just
use 400k as standard) At this rate, it is possible for an open bus to
create harmonics, especially and that too quite near to a RF stage (the
tuner is the first block, looking at any RF design) is sufficient enough
to reduce the SNR.

In this case, once the device has successfully tuned, no further
communication occurs and there is absolute silence on the bus.

In such a case, it contributes to an overall slightly higher SNR.

 2) reduced usage of pins
just 2 pins are used for communication with the demodulator and no
further pins are needed for communication with the tuner.

* the disadvantage is that it adds in a small additional complication
such as communication bus control in terms of switching.

That is mostly about the hardware.

Now, for a hybrid device approach,

* the minimal changes it has to be applied to a running system, the
better it is. The larger the changes, the worser it is to fix when there
is another new category of devices. (Small is beautiful)

* even though there needs to be a hybrid between 2 systems, it doesn't
mean that one necessarily has to pull in stuff from one part of the
system to the 

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[hermann pitton]

Am Mittwoch, den 16.05.2007, 23:48 +0400 schrieb Manu Abraham:
 hermann pitton wrote:
  Manu,
  
 
 I am writing this reply with quite a lot of reluctance/hesitation, since
 some people create unnecessary noise alone: people being stubborn,
 practically creating a waste of time for others.
 
 Removing all those CC's since they are already addressed on the ML's.
 Sometimes it is better to keep quiet, seeing all those *noise*. The main
 issue: half knowledge is too dangerous!
 
  what do you think already could have a GO?
  
  Markus can't invade like that, but must have a next safe harbour to
  continue to work on it.
  
  The hybrid stuff will invade the planet for long, and then ... die.
 
 Convergence of media is not a new thing. Now it is Analog stuff added
 in, the reason for a vendor: it does not make much of a difference in
 terms of cost to make a chip like that, but with regards to marketing it
 makes a huge difference. Later on, we will be seeing the convergence of
 other media as well.
 
  Do you think to share tuners between digital and analog is really
  impossible, or just wait until these zilliards are gone?
 
 I don't think it is impossible, just that it needs sufficient efforts to
 do so. Now there are 2 types of designs, the analog interface is thrown
 in additionally into each of them.
 
 1) using a Single chip, bus interface + demodulator + tuner
 2) using Two chips, chip1 = bus interface, chip2 = demodulator + tuner
 3) using 3 chips, chip1 = bus interface, chip2 = demodulator, chip3 = tuner
 
 the usage in case 1) is highly vendor specific and we can't say much
 about it. ie, it might be a certain way from vendor A and another way
 from vendor B
 
 in 2 cases except for (1), there are each 2 ways a tuner is interfaced
 
 a) on a separate bus
 In this case, the tuner is directly connected to an I2C/SPI/GPIO bus. In
 this case things are very simple and the tuner is accessible always.
 Plain and simple, no hassles in accessing the tuner.
 
 b) on a bus which is private to the demodulator
 In this case, the tuner is behind a demodulator, or another device too
 (maybe some damned device which is not even a demodulator, even
 proprietary ones you can imagine here). In the normal case that we have,
 the tuner is just behind the demodulator.
 
 Now the demodulator alone controls access to the tuner. No probes,
 nothing will work if the demodulator has disabled access. (ie the tuner
 is completely unaccessible without the demodulator control) You can
 imagine a road which is blocked by a barrier, which is controlled by an
 entity (the demodulator in this case) the access is private to the
 demodulator and the demodulator alone has access to the same. How the
 access is controlled only the demodulator knows. Some demodulators keep
 it open all the time once a request is issued. Some close the access
 based on some criteria (again the criteria is device specific)
 
 There are advantages and disadvantages of both these methods.
 (a)
 * this requires an additional bus, or in some cases the tuner is just on
 another address on the same bus
 this additional bus in some cases would mean an additional cost, in some
 case it could be just some unused GPIO used as bit-banging.
 
 * quite simple hardware as the hardware designer doesn't have to bother
 much, since it is a straight forward design
 * the downside is that a bus which is left open/unterminated, creates a
 lot of noise. Such devices have typically lower SNR and are much
 susceptible to noise (gaussian noise is cumulative, ie additive)
 
 (b)
 * this on the same bus, just like a barrier on the same road an entity
 controlling the barrier
 * the advantages in this case are
  1) once the gate is closed, no further communication occurs -- lesser
 noise results
 
 One might think: about the amount of noise created @ 100 khz etc, mind
 you newer devices all use 400 khz as default, some do even have options
 for going faster still (even though the devices what we have now just
 use 400k as standard) At this rate, it is possible for an open bus to
 create harmonics, especially and that too quite near to a RF stage (the
 tuner is the first block, looking at any RF design) is sufficient enough
 to reduce the SNR.
 
 In this case, once the device has successfully tuned, no further
 communication occurs and there is absolute silence on the bus.
 
 In such a case, it contributes to an overall slightly higher SNR.
 
  2) reduced usage of pins
 just 2 pins are used for communication with the demodulator and no
 further pins are needed for communication with the tuner.
 
 * the disadvantage is that it adds in a small additional complication
 such as communication bus control in terms of switching.
 
 That is mostly about the hardware.
 
 Now, for a hybrid device approach,
 
 * the minimal changes it has to be applied to a running system, the
 better it is. The larger the changes, the worser it is to fix when there
 is another new category of devices. (Small 

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Michael Krufky]

Mauro Carvalho Chehab wrote:

 I do frown upon code duplication, however, in this case it is a safer
 alternative to the one currently on the table.  Earlier versions of
 the xc3028 tuner driver were bound to the video4linux tuner.ko
 module, for the sake of tuning analog television stations.  There was
 a wrapper present inside the em2880-dvb driver that allowed the dvb
 subsystem to access the xc3028 via tuner.ko.  I am not a big fan of
 this solution, however, it does not touch any core subsystem code. 
 DVB-only devices can use a separate module in order to access the
 xc3028 without imposing dependencies on the v4l core.

 Duplicating a driver is not a solution, just a terrible hack. We
 should focus on a way to use the same tuner driver for both Analog and
 Digital TV.

Mauro,

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.

As much as we try to come to an agreement about this right now, I fear
that it will be very difficult -- this debate has gone on for over a
year and reaching an agreement will not be easy.

I think that the only way to move forward while keeping everybody happy
would be to proceed in the following order:

1) merge xc3028 support into tuner.ko for analog support*

2) break apart tuner.ko into modularized sub-modules*

3) add xc3028-fe.ko module for dvb-only support**

4) merge in updates to the em28xx driver***

5) add xc3028 support to other card drivers***

6) restart discussions about hybrid / tuner inter-subsystem API

7) apply changes agreed upon in step 6, to migrate the tuner modules to
the new tuner internal api, while removing the duplicated xc3028 module.


*(1) and (2) may be reversed

** http://linuxtv.org/~mkrufky/xc-bluebird.patch

*** analog functionality should use tuner.ko only
*** digital functionality should use xc3028-fe.ko only

---

Please take note, that if we proceed in the order above, this will allow
us to merge the majority of Markus' changes, leaving only the api
changes behind.  At this point, the remainder of the changesets will be
MUCH smaller, and much easier to review.

Under the conditions that we'll be under after step 5, it will be much
more conducive to a productive developer discussion on the issue.

At this point, there has been so much noise about this topic, that I
feel confident that many developers will be able to participate in this
review.  I, for one, would love to have this taken care of, and put this
issue behind us.

After step 5, with the majority of the changesets already being merged,
the pressure on the author and reviewers will be lessened, and
discussions should be able to take place with clear heads.

What I am asking for here is very sensible --  This should not be
difficult for everybody to agree to.  It allows us to merge in changes
one step at a time, while adding support for all devices gradually. 
Through this means, we will ultimately achieve the goal of being able to
discuss the actual requirements and reasons for why Markus is making
this proposal to change the tuner api.

I repeat:  huge changes will never blow over well.  The only way to do
this in small steps is to do it in such a way that I've described in
this email.

If you simply shoot me down for the idea of temporarily having a
separate dvb module for the dvb subsystem to interface with the xc3028
tuner,  then you are not seeing the big picture.

Regards,

Mike Krufky



___
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

[Oliver Endriss]

Markus Rechberger wrote:
 to be more accurate where all the changes happened:
  b/linux/drivers/media/tuners/Kconfig|   14
  b/linux/drivers/media/tuners/Makefile   |7
  b/linux/drivers/media/tuners/xc3028-tuner.c |  601 
  b/linux/drivers/media/tuners/xc3028-tuner.h |   20
  b/linux/drivers/media/video/em28xx/em2880-dvb.c |  748 
  b/linux/drivers/media/video/em28xx/em28xx-audio.c   |  439 ++
  b/linux/drivers/media/video/em28xx/em28xx-webcam.c  |  365 ++
  b/linux/include/media/v4l_dvb_tuner.h   |  131
  linux/Documentation/video4linux/CARDLIST.cx88   |3
  linux/Documentation/video4linux/CARDLIST.em28xx |   69
  linux/Documentation/video4linux/CARDLIST.tuner  |1
  linux/drivers/media/Kconfig |2
  linux/drivers/media/Makefile|1
  linux/drivers/media/common/ir-keymaps.c |  221 +
  linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c |   21
  linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c   |   34
  linux/drivers/media/dvb/dvb-core/dmxdev.c   |6
  linux/drivers/media/dvb/dvb-core/dmxdev.h   |1
  linux/drivers/media/dvb/dvb-core/dvb_demux.c|3
  linux/drivers/media/dvb/dvb-core/dvb_demux.h|3
  linux/drivers/media/dvb/dvb-core/dvb_frontend.c |   29
  linux/drivers/media/dvb/dvb-core/dvb_frontend.h |   64
  linux/drivers/media/dvb/dvb-core/dvb_net.c  |   29
  linux/drivers/media/dvb/dvb-core/dvb_net.h  |1
  linux/drivers/media/dvb/dvb-usb/af9005-fe.c |   12
  linux/drivers/media/dvb/dvb-usb/au6610.c|3
  linux/drivers/media/dvb/dvb-usb/cxusb.c |  150
  linux/drivers/media/dvb/dvb-usb/cxusb.h |2
  linux/drivers/media/dvb/dvb-usb/dib0700_devices.c   |7
  linux/drivers/media/dvb/dvb-usb/dibusb-common.c |6
  linux/drivers/media/dvb/dvb-usb/dibusb-mb.c |   17
  linux/drivers/media/dvb/dvb-usb/digitv.c|7
  linux/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c   |   11
  linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h   |2
  linux/drivers/media/dvb/dvb-usb/dvb-usb.h   |8
  linux/drivers/media/dvb/dvb-usb/gl861.c |3
  linux/drivers/media/dvb/dvb-usb/m920x.c |   14
  linux/drivers/media/dvb/dvb-usb/opera1.c|3
  linux/drivers/media/dvb/dvb-usb/ttusb2.c|3
  linux/drivers/media/dvb/dvb-usb/umt-010.c   |3
  linux/drivers/media/dvb/frontends/at76c651.c|2
  linux/drivers/media/dvb/frontends/bsbe1.h   |3
  linux/drivers/media/dvb/frontends/bsru6.h   |3
  linux/drivers/media/dvb/frontends/cx22700.c |2
  linux/drivers/media/dvb/frontends/cx22702.c |2
  linux/drivers/media/dvb/frontends/cx24110.c |2
  linux/drivers/media/dvb/frontends/dib3000mb.c   |2
  linux/drivers/media/dvb/frontends/dib3000mc.c   |2
  linux/drivers/media/dvb/frontends/dib7000m.c|2
  linux/drivers/media/dvb/frontends/dib7000p.c|2
  linux/drivers/media/dvb/frontends/dvb-pll.c |   65
  linux/drivers/media/dvb/frontends/dvb-pll.h |   19
  linux/drivers/media/dvb/frontends/dvb_dummy_fe.c|2
  linux/drivers/media/dvb/frontends/l64781.c  |2
  linux/drivers/media/dvb/frontends/lgdt330x.c|6
  linux/drivers/media/dvb/frontends/mt2060.c  |   43
  linux/drivers/media/dvb/frontends/mt2060.h  |6
  linux/drivers/media/dvb/frontends/mt312.c   |2
  linux/drivers/media/dvb/frontends/mt352.c   |   15
  linux/drivers/media/dvb/frontends/mt352.h   |3
  linux/drivers/media/dvb/frontends/nxt200x.c |2
  linux/drivers/media/dvb/frontends/nxt6000.c |2
  linux/drivers/media/dvb/frontends/or51132.c |2
  linux/drivers/media/dvb/frontends/qt1010.c  |   59
  linux/drivers/media/dvb/frontends/qt1010.h  |4
  linux/drivers/media/dvb/frontends/s5h1420.c |6
  linux/drivers/media/dvb/frontends/sp8870.c  |2
  linux/drivers/media/dvb/frontends/sp887x.c  |4
  linux/drivers/media/dvb/frontends/stv0297.c |2
  linux/drivers/media/dvb/frontends/stv0299.c |4
  linux/drivers/media/dvb/frontends/tda10021.c|2
  linux/drivers/media/dvb/frontends/tda10023.c|2
  linux/drivers/media/dvb/frontends/tda1004x.c|2
  linux/drivers/media/dvb/frontends/tda10086.c|4
  linux/drivers/media/dvb/frontends/tda8083.c |2
  

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Markus Rechberger]

On 5/15/07, Oliver Endriss [EMAIL PROTECTED] wrote:

Markus Rechberger wrote:
 to be more accurate where all the changes happened:
  b/linux/drivers/media/tuners/Kconfig|   14
  b/linux/drivers/media/tuners/Makefile   |7
  b/linux/drivers/media/tuners/xc3028-tuner.c |  601 
  b/linux/drivers/media/tuners/xc3028-tuner.h |   20
  b/linux/drivers/media/video/em28xx/em2880-dvb.c |  748 
  b/linux/drivers/media/video/em28xx/em28xx-audio.c   |  439 ++
  b/linux/drivers/media/video/em28xx/em28xx-webcam.c  |  365 ++
  b/linux/include/media/v4l_dvb_tuner.h   |  131
  linux/Documentation/video4linux/CARDLIST.cx88   |3
  linux/Documentation/video4linux/CARDLIST.em28xx |   69
  linux/Documentation/video4linux/CARDLIST.tuner  |1
  linux/drivers/media/Kconfig |2
  linux/drivers/media/Makefile|1
  linux/drivers/media/common/ir-keymaps.c |  221 +
  linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c |   21
  linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c   |   34
  linux/drivers/media/dvb/dvb-core/dmxdev.c   |6
  linux/drivers/media/dvb/dvb-core/dmxdev.h   |1
  linux/drivers/media/dvb/dvb-core/dvb_demux.c|3
  linux/drivers/media/dvb/dvb-core/dvb_demux.h|3
  linux/drivers/media/dvb/dvb-core/dvb_frontend.c |   29
  linux/drivers/media/dvb/dvb-core/dvb_frontend.h |   64
  linux/drivers/media/dvb/dvb-core/dvb_net.c  |   29
  linux/drivers/media/dvb/dvb-core/dvb_net.h  |1
  linux/drivers/media/dvb/dvb-usb/af9005-fe.c |   12
  linux/drivers/media/dvb/dvb-usb/au6610.c|3
  linux/drivers/media/dvb/dvb-usb/cxusb.c |  150
  linux/drivers/media/dvb/dvb-usb/cxusb.h |2
  linux/drivers/media/dvb/dvb-usb/dib0700_devices.c   |7
  linux/drivers/media/dvb/dvb-usb/dibusb-common.c |6
  linux/drivers/media/dvb/dvb-usb/dibusb-mb.c |   17
  linux/drivers/media/dvb/dvb-usb/digitv.c|7
  linux/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c   |   11
  linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h   |2
  linux/drivers/media/dvb/dvb-usb/dvb-usb.h   |8
  linux/drivers/media/dvb/dvb-usb/gl861.c |3
  linux/drivers/media/dvb/dvb-usb/m920x.c |   14
  linux/drivers/media/dvb/dvb-usb/opera1.c|3
  linux/drivers/media/dvb/dvb-usb/ttusb2.c|3
  linux/drivers/media/dvb/dvb-usb/umt-010.c   |3
  linux/drivers/media/dvb/frontends/at76c651.c|2
  linux/drivers/media/dvb/frontends/bsbe1.h   |3
  linux/drivers/media/dvb/frontends/bsru6.h   |3
  linux/drivers/media/dvb/frontends/cx22700.c |2
  linux/drivers/media/dvb/frontends/cx22702.c |2
  linux/drivers/media/dvb/frontends/cx24110.c |2
  linux/drivers/media/dvb/frontends/dib3000mb.c   |2
  linux/drivers/media/dvb/frontends/dib3000mc.c   |2
  linux/drivers/media/dvb/frontends/dib7000m.c|2
  linux/drivers/media/dvb/frontends/dib7000p.c|2
  linux/drivers/media/dvb/frontends/dvb-pll.c |   65
  linux/drivers/media/dvb/frontends/dvb-pll.h |   19
  linux/drivers/media/dvb/frontends/dvb_dummy_fe.c|2
  linux/drivers/media/dvb/frontends/l64781.c  |2
  linux/drivers/media/dvb/frontends/lgdt330x.c|6
  linux/drivers/media/dvb/frontends/mt2060.c  |   43
  linux/drivers/media/dvb/frontends/mt2060.h  |6
  linux/drivers/media/dvb/frontends/mt312.c   |2
  linux/drivers/media/dvb/frontends/mt352.c   |   15
  linux/drivers/media/dvb/frontends/mt352.h   |3
  linux/drivers/media/dvb/frontends/nxt200x.c |2
  linux/drivers/media/dvb/frontends/nxt6000.c |2
  linux/drivers/media/dvb/frontends/or51132.c |2
  linux/drivers/media/dvb/frontends/qt1010.c  |   59
  linux/drivers/media/dvb/frontends/qt1010.h  |4
  linux/drivers/media/dvb/frontends/s5h1420.c |6
  linux/drivers/media/dvb/frontends/sp8870.c  |2
  linux/drivers/media/dvb/frontends/sp887x.c  |4
  linux/drivers/media/dvb/frontends/stv0297.c |2
  linux/drivers/media/dvb/frontends/stv0299.c |4
  linux/drivers/media/dvb/frontends/tda10021.c|2
  linux/drivers/media/dvb/frontends/tda10023.c|2
  linux/drivers/media/dvb/frontends/tda1004x.c|2
  linux/drivers/media/dvb/frontends/tda10086.c|4
  

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Mauro Carvalho Chehab]

Hi Michael and others,

I know we've been over this, but I need to state my feelings on the 
matter, otherwise I would have to simply keep quiet, and that doesn't 
help the situation for anybody. I _strongly_ feel that the core changes 
being proposed here will hurt the integrity of the dvb subsystem.


I don't think they will hurt the integrity of the subsystem, but a large 
amount of changes can really affect the driver stability, even being 
trivial changes. Such patch series, if applied, will need acks for the 
active driver maintainers that should make sure this won't break any other 
driver.


I would, instead, use a different approach, without losing the required 
functionalities for xc3028.


To give my $2 cents of contribution, I've sent a modified version of dvb 
integration for xc3028 sometime ago to Markus, as a sugestion.


It should be noticed that I didn't tested the patchset (as currently I 
don't have em288x+xc3028 DVB hardware). If someone wants to take a look, 
the patch series it is available (at quilt format) at:

http://linuxtv.org/~mchehab/mrec2/

The required changes on DVB are minimal (just adding a few newer fields 
at frontend core). Also, there's no need to change any stuff on dvb or v4l 
drivers. So, it wouln't break any existing drivers.


The diffstat for the core changes is:

 linux/drivers/media/Kconfig |2
 linux/drivers/media/Makefile|1
 linux/drivers/media/dvb/dvb-core/dvb_frontend.h |   29 ++
 linux/drivers/media/video/tuner-core.c  |  156 ++-
 linux/include/media/tuner.h |6
 linux/include/media/v4l2-common.h   |2
 v4l/Makefile|4
 v4l/scripts/gentree.pl  |1

All API changes on DVB are at the first patch:
http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch

It should be noticed that the comments at the patches may not be correct 
anymore, since I've folded some patches, and modified some API calls on 
Markus original series to be compatible with the way I did the integration 
on DVB frontend. If we go to this path, some work is still required.


I do frown upon code duplication, however, in this case it is a safer 
alternative to the one currently on the table.  Earlier versions of the 
xc3028 tuner driver were bound to the video4linux tuner.ko module, for 
the sake of tuning analog television stations.  There was a wrapper 
present inside the em2880-dvb driver that allowed the dvb subsystem to 
access the xc3028 via tuner.ko.  I am not a big fan of this solution, 
however, it does not touch any core subsystem code.  DVB-only devices 
can use a separate module in order to access the xc3028 without imposing 
dependencies on the v4l core.


Duplicating a driver is not a solution, just a terrible hack. We should 
focus on a way to use the same tuner driver for both Analog and Digital 
TV.


--
Cheers,
Mauro Carvalho Chehab
http://linuxtv.org
[EMAIL PROTECTED]

___
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

[Markus Rechberger]

On 5/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:

Hi Michael and others,

 I know we've been over this, but I need to state my feelings on the
 matter, otherwise I would have to simply keep quiet, and that doesn't
 help the situation for anybody. I _strongly_ feel that the core changes
 being proposed here will hurt the integrity of the dvb subsystem.

I don't think they will hurt the integrity of the subsystem, but a large
amount of changes can really affect the driver stability, even being
trivial changes. Such patch series, if applied, will need acks for the
active driver maintainers that should make sure this won't break any other
driver.

I would, instead, use a different approach, without losing the required
functionalities for xc3028.

To give my $2 cents of contribution, I've sent a modified version of dvb
integration for xc3028 sometime ago to Markus, as a sugestion.

It should be noticed that I didn't tested the patchset (as currently I
don't have em288x+xc3028 DVB hardware). If someone wants to take a look,
the patch series it is available (at quilt format) at:
http://linuxtv.org/~mchehab/mrec2/

The required changes on DVB are minimal (just adding a few newer fields
at frontend core). Also, there's no need to change any stuff on dvb or v4l
drivers. So, it wouln't break any existing drivers.

The diffstat for the core changes is:

  linux/drivers/media/Kconfig |2
  linux/drivers/media/Makefile|1
  linux/drivers/media/dvb/dvb-core/dvb_frontend.h |   29 ++
  linux/drivers/media/video/tuner-core.c  |  156 ++-
  linux/include/media/tuner.h |6
  linux/include/media/v4l2-common.h   |2
  v4l/Makefile|4
  v4l/scripts/gentree.pl  |1

All API changes on DVB are at the first patch:
http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch

It should be noticed that the comments at the patches may not be correct
anymore, since I've folded some patches, and modified some API calls on
Markus original series to be compatible with the way I did the integration
on DVB frontend. If we go to this path, some work is still required.

 I do frown upon code duplication, however, in this case it is a safer
 alternative to the one currently on the table.  Earlier versions of the
 xc3028 tuner driver were bound to the video4linux tuner.ko module, for
 the sake of tuning analog television stations.  There was a wrapper
 present inside the em2880-dvb driver that allowed the dvb subsystem to
 access the xc3028 via tuner.ko.  I am not a big fan of this solution,
 however, it does not touch any core subsystem code.  DVB-only devices
 can use a separate module in order to access the xc3028 without imposing
 dependencies on the v4l core.

Duplicating a driver is not a solution, just a terrible hack. We should
focus on a way to use the same tuner driver for both Analog and Digital
TV.



If I compare that solution with the solution I provided your one is
only half way done, you add a dependency for a structure which will
never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will
be used).

If you look at v4l_dvb_tuner_ops it's clear what it intends to be and
in no way it adds extra struct definitions which do not belong there,
if you look at dvb_frontend in tuner-core.c it has nothing to do with
the tuner, it also contains the callbacks for the digital demod.

It also requires all the dvb headers.
#include dvb_frontend.h

#include linux/dvb/frontend.h
#include dvbdev.h

dvbdev.h is not needed at all either, even if gcc might wipe out the
defined functions because they're not used.

We shouldn't care about hacks to keep the noise on the ML low, put the
technical aspect (which includes a solution for all the requirements)
infront of everything then I might agree with your patch.

Markus

___
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

[Mauro Carvalho Chehab]

If I compare that solution with the 

solution I provided your one is

only half way done, you add a dependency for a structure which will
never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will
be used).


As I said, this is a sugestion. For sure, improvements can be done.
The main point is not risking breaking other drivers.


If you look at v4l_dvb_tuner_ops it's clear what it intends to be and
in no way it adds extra struct definitions which do not belong there,
if you look at dvb_frontend in tuner-core.c it has nothing to do with
the tuner, it also contains the callbacks for the digital demod.

It also requires all the dvb headers.
#include dvb_frontend.h

#include linux/dvb/frontend.h
#include dvbdev.h

dvbdev.h is not needed at all either, even if gcc might wipe out the
defined functions because they're not used.


I can't see any troubles including those headers, except for a slower 
compilation. Later, somebody may write a patch reorganizing the includes.



We shouldn't care about hacks to keep the noise on the ML low, put the
technical aspect (which includes a solution for all the requirements)
infront of everything then I might agree with your patch.


It is not a matter of keeping noise low, but, instead, avoid breaking 
existing drivers. This is a technical issue: smaller changes means less 
lines to check, and more unlikely to break an existing driver.


Cheers,
Mauro Carvalho Chehab
http://linuxtv.org
[EMAIL PROTECTED]

___
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 - cx878 project

[Uwe Bugla]

Am Dienstag, 15. Mai 2007 17:55 schrieb Markus Rechberger:
 On 5/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
  Hi Michael and others,
 
   I know we've been over this, but I need to state my feelings on the
   matter, otherwise I would have to simply keep quiet, and that doesn't
   help the situation for anybody. I _strongly_ feel that the core changes
   being proposed here will hurt the integrity of the dvb subsystem.
 
  I don't think they will hurt the integrity of the subsystem, but a large
  amount of changes can really affect the driver stability, even being
  trivial changes. Such patch series, if applied, will need acks for the
  active driver maintainers that should make sure this won't break any
  other driver.
 
  I would, instead, use a different approach, without losing the required
  functionalities for xc3028.
 
  To give my $2 cents of contribution, I've sent a modified version of dvb
  integration for xc3028 sometime ago to Markus, as a sugestion.
 
  It should be noticed that I didn't tested the patchset (as currently I
  don't have em288x+xc3028 DVB hardware). If someone wants to take a look,
  the patch series it is available (at quilt format) at:
  http://linuxtv.org/~mchehab/mrec2/
 
  The required changes on DVB are minimal (just adding a few newer fields
  at frontend core). Also, there's no need to change any stuff on dvb or
  v4l drivers. So, it wouln't break any existing drivers.
 
  The diffstat for the core changes is:
 
linux/drivers/media/Kconfig |2
linux/drivers/media/Makefile|1
linux/drivers/media/dvb/dvb-core/dvb_frontend.h |   29 ++
linux/drivers/media/video/tuner-core.c  |  156 ++-
linux/include/media/tuner.h |6
linux/include/media/v4l2-common.h   |2
v4l/Makefile|4
v4l/scripts/gentree.pl  |1
 
  All API changes on DVB are at the first patch:
  http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch
 
  It should be noticed that the comments at the patches may not be correct
  anymore, since I've folded some patches, and modified some API calls on
  Markus original series to be compatible with the way I did the
  integration on DVB frontend. If we go to this path, some work is still
  required.
 
   I do frown upon code duplication, however, in this case it is a safer
   alternative to the one currently on the table.  Earlier versions of the
   xc3028 tuner driver were bound to the video4linux tuner.ko module, for
   the sake of tuning analog television stations.  There was a wrapper
   present inside the em2880-dvb driver that allowed the dvb subsystem to
   access the xc3028 via tuner.ko.  I am not a big fan of this solution,
   however, it does not touch any core subsystem code.  DVB-only devices
   can use a separate module in order to access the xc3028 without
   imposing dependencies on the v4l core.
 
  Duplicating a driver is not a solution, just a terrible hack. We should
  focus on a way to use the same tuner driver for both Analog and Digital
  TV.

 If I compare that solution with the solution I provided your one is
 only half way done, you add a dependency for a structure which will
 never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will
 be used).

 If you look at v4l_dvb_tuner_ops it's clear what it intends to be and
 in no way it adds extra struct definitions which do not belong there,
 if you look at dvb_frontend in tuner-core.c it has nothing to do with
 the tuner, it also contains the callbacks for the digital demod.

 It also requires all the dvb headers.
 #include dvb_frontend.h

 #include linux/dvb/frontend.h
 #include dvbdev.h

 dvbdev.h is not needed at all either, even if gcc might wipe out the
 defined functions because they're not used.

 We shouldn't care about hacks to keep the noise on the ML low, put the
 technical aspect (which includes a solution for all the requirements)
 infront of everything then I might agree with your patch.

 Markus


Hi everybody,
This is what I found at http://www.bttv-gallery.de. Perhaps this helps to 
clear up misunderstandings and helps to finish that discussion / thread – 
original author of the german text is Peter Hettkamp:

Point 4:
„Data transfer from QSPK-Chip into the PC-Random Access Memory. All further 
processings are done by relevant software. To enable that the data must be 
transferred into RAM over the PCI bus. Within the PCTV SAT this is done by 
the CN878 chip over its audio DMA.“

Well, and now comes the misleading part:

„The whole video part of the chip rests functionless during the DVB capture, 
and can on the contrary be used parallely for recording analog video (SVHS 
and Composite input) under Linux. The bttv driver is loaded anyhow... 
Done by my driver, API does not exist on that.“ 

Markus Rechberger said on Monday, May 16th, 16:23:
„* full 

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Markus Rechberger]

On 5/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:

 If I compare that solution with the
solution I provided your one is
 only half way done, you add a dependency for a structure which will
 never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will
 be used).

As I said, this is a sugestion. For sure, improvements can be done.
The main point is not risking breaking other drivers.

 If you look at v4l_dvb_tuner_ops it's clear what it intends to be and
 in no way it adds extra struct definitions which do not belong there,
 if you look at dvb_frontend in tuner-core.c it has nothing to do with
 the tuner, it also contains the callbacks for the digital demod.

 It also requires all the dvb headers.
 #include dvb_frontend.h

 #include linux/dvb/frontend.h
 #include dvbdev.h

 dvbdev.h is not needed at all either, even if gcc might wipe out the
 defined functions because they're not used.

I can't see any troubles including those headers, except for a slower
compilation. Later, somebody may write a patch reorganizing the includes.

 We shouldn't care about hacks to keep the noise on the ML low, put the
 technical aspect (which includes a solution for all the requirements)
 infront of everything then I might agree with your patch.

It is not a matter of keeping noise low, but, instead, avoid breaking
existing drivers. This is a technical issue: smaller changes means less
lines to check, and more unlikely to break an existing driver.



I really understand that issue I just want to point to the saa7114
changes which broke the em28xx MSI devices in the kernel, there was
neither a revert or something else. If I'd have to rate the patch I
sent to the v4l maintainer list I'd give it 3/10 pts. the driver is
still broken even in the v4l-dvb-experimental repository since I
haven't ported that change from the v4l-dvb-kernel repository to the
experimental one yet. It's important to avoid breaking devices that
for it should be tested and discussed. But again I see everyone here
is writing around the whole issue. Oliver wrote that the patches are
too big and that it will take alot time to review them (it was also
alot time to write them, so telling me about a time factor is more
than unfair).
I suggest to get your hands dirty with it and start to test it and
comment the outstanding points I wrote in the first email.

thanks,
Markus

___
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

[hermann pitton]

Am Dienstag, den 15.05.2007, 19:00 +0200 schrieb Markus Rechberger:
 On 5/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
   If I compare that solution with the
  solution I provided your one is
   only half way done, you add a dependency for a structure which will
   never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will
   be used).
 
  As I said, this is a sugestion. For sure, improvements can be done.
  The main point is not risking breaking other drivers.
 
   If you look at v4l_dvb_tuner_ops it's clear what it intends to be and
   in no way it adds extra struct definitions which do not belong there,
   if you look at dvb_frontend in tuner-core.c it has nothing to do with
   the tuner, it also contains the callbacks for the digital demod.
  
   It also requires all the dvb headers.
   #include dvb_frontend.h
  
   #include linux/dvb/frontend.h
   #include dvbdev.h
  
   dvbdev.h is not needed at all either, even if gcc might wipe out the
   defined functions because they're not used.
 
  I can't see any troubles including those headers, except for a slower
  compilation. Later, somebody may write a patch reorganizing the includes.
 
   We shouldn't care about hacks to keep the noise on the ML low, put the
   technical aspect (which includes a solution for all the requirements)
   infront of everything then I might agree with your patch.
 
  It is not a matter of keeping noise low, but, instead, avoid breaking
  existing drivers. This is a technical issue: smaller changes means less
  lines to check, and more unlikely to break an existing driver.
 
 
 I really understand that issue I just want to point to the saa7114
 changes which broke the em28xx MSI devices in the kernel, there was
 neither a revert or something else. If I'd have to rate the patch I
 sent to the v4l maintainer list I'd give it 3/10 pts. the driver is
 still broken even in the v4l-dvb-experimental repository since I
 haven't ported that change from the v4l-dvb-kernel repository to the
 experimental one yet. It's important to avoid breaking devices that
 for it should be tested and discussed. But again I see everyone here
 is writing around the whole issue. Oliver wrote that the patches are
 too big and that it will take alot time to review them (it was also
 alot time to write them, so telling me about a time factor is more
 than unfair).
 I suggest to get your hands dirty with it and start to test it and
 comment the outstanding points I wrote in the first email.
 

Manu,

what do you think already could have a GO?

Markus can't invade like that, but must have a next safe harbour to
continue to work on it.

The hybrid stuff will invade the planet for long, and then ... die.

Do you think to share tuners between digital and analog is really
impossible, or just wait until these zilliards are gone?

Why, please? GNU/Linux is surely dead on this after it.

Hermann



___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Trent Piepho]

On Mon, 14 May 2007, Markus Rechberger wrote:
 Hi all,

 I exported the patches of my v4l-dvb-experimental repository against
 the current v4l-dvb repository on linuxtv.org.

 The single patchfiles are available on mcentral.de
 http://mcentral.de/~mrec/patches/v4l-dvb/
[93 patches]

It's really hard for anyone to make sense of a patch bomb like this.
There's just too many changes, and none of the patches even have comments
longer than one line.

The organization of the patches is really hard to follow too.  For example,
patch 19 adds a NULL pointer check to tuner-core (why is this necessary?)
and then also adds two register names names to the dvb zl10353 driver.
Those changes have nothing to do with each other.  It's patch 20 that
actually adds the code to zl10353 that uses the new registers, and it even
changes the names used in patch 19.

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Markus Rechberger]

On 5/14/07, Trent Piepho [EMAIL PROTECTED] wrote:

On Mon, 14 May 2007, Markus Rechberger wrote:
 Hi all,

 I exported the patches of my v4l-dvb-experimental repository against
 the current v4l-dvb repository on linuxtv.org.

 The single patchfiles are available on mcentral.de
 http://mcentral.de/~mrec/patches/v4l-dvb/
[93 patches]

It's really hard for anyone to make sense of a patch bomb like this.
There's just too many changes, and none of the patches even have comments
longer than one line.

The organization of the patches is really hard to follow too.  For example,
patch 19 adds a NULL pointer check to tuner-core (why is this necessary?)


if the struct is initialized as NULL it won't be possible to access
the member of it without crashing the kernel.


and then also adds two register names names to the dvb zl10353 driver.
Those changes have nothing to do with each other.  It's patch 20 that
actually adds the code to zl10353 that uses the new registers, and it even
changes the names used in patch 19.



I see the order is a problem there, I've redone the whole tree 3 times
because of problems with some folks on the ML earlier since I wanted
to keep the extra changes as small as possible I merged some patches
finally.

As from my side I don't have the time to do a major rewrite or doing
some reordering again, please try to make the best out of what's
available now.

The patches include more than 9000 lines of codechanges through the
v4l and dvb framework, these changes have been done during the last 1
1/2 years of split development from the main v4l-dvb code, I know it's
alot but it's worth to get it done now. It's not only about adding
support for one new device only.

Markus

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Markus Rechberger]

On 5/15/07, Markus Rechberger [EMAIL PROTECTED] wrote:

On 5/14/07, Trent Piepho [EMAIL PROTECTED] wrote:
 On Mon, 14 May 2007, Markus Rechberger wrote:
  Hi all,
 
  I exported the patches of my v4l-dvb-experimental repository against
  the current v4l-dvb repository on linuxtv.org.
 
  The single patchfiles are available on mcentral.de
  http://mcentral.de/~mrec/patches/v4l-dvb/
 [93 patches]

 It's really hard for anyone to make sense of a patch bomb like this.
 There's just too many changes, and none of the patches even have comments
 longer than one line.

 The organization of the patches is really hard to follow too.  For
example,
 patch 19 adds a NULL pointer check to tuner-core (why is this necessary?)

if the struct is initialized as NULL it won't be possible to access
the member of it without crashing the kernel.

 and then also adds two register names names to the dvb zl10353 driver.
 Those changes have nothing to do with each other.  It's patch 20 that
 actually adds the code to zl10353 that uses the new registers, and it even
 changes the names used in patch 19.


I see the order is a problem there, I've redone the whole tree 3 times
because of problems with some folks on the ML earlier since I wanted
to keep the extra changes as small as possible I merged some patches
finally.

As from my side I don't have the time to do a major rewrite or doing
some reordering again, please try to make the best out of what's
available now.

The patches include more than 9000 lines of codechanges through the
v4l and dvb framework, these changes have been done during the last 1
1/2 years of split development from the main v4l-dvb code, I know it's
alot but it's worth to get it done now. It's not only about adding
support for one new device only.


to be more accurate where all the changes happened:
b/linux/drivers/media/tuners/Kconfig|   14
b/linux/drivers/media/tuners/Makefile   |7
b/linux/drivers/media/tuners/xc3028-tuner.c |  601 
b/linux/drivers/media/tuners/xc3028-tuner.h |   20
b/linux/drivers/media/video/em28xx/em2880-dvb.c |  748 
b/linux/drivers/media/video/em28xx/em28xx-audio.c   |  439 ++
b/linux/drivers/media/video/em28xx/em28xx-webcam.c  |  365 ++
b/linux/include/media/v4l_dvb_tuner.h   |  131
linux/Documentation/video4linux/CARDLIST.cx88   |3
linux/Documentation/video4linux/CARDLIST.em28xx |   69
linux/Documentation/video4linux/CARDLIST.tuner  |1
linux/drivers/media/Kconfig |2
linux/drivers/media/Makefile|1
linux/drivers/media/common/ir-keymaps.c |  221 +
linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c |   21
linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c   |   34
linux/drivers/media/dvb/dvb-core/dmxdev.c   |6
linux/drivers/media/dvb/dvb-core/dmxdev.h   |1
linux/drivers/media/dvb/dvb-core/dvb_demux.c|3
linux/drivers/media/dvb/dvb-core/dvb_demux.h|3
linux/drivers/media/dvb/dvb-core/dvb_frontend.c |   29
linux/drivers/media/dvb/dvb-core/dvb_frontend.h |   64
linux/drivers/media/dvb/dvb-core/dvb_net.c  |   29
linux/drivers/media/dvb/dvb-core/dvb_net.h  |1
linux/drivers/media/dvb/dvb-usb/af9005-fe.c |   12
linux/drivers/media/dvb/dvb-usb/au6610.c|3
linux/drivers/media/dvb/dvb-usb/cxusb.c |  150
linux/drivers/media/dvb/dvb-usb/cxusb.h |2
linux/drivers/media/dvb/dvb-usb/dib0700_devices.c   |7
linux/drivers/media/dvb/dvb-usb/dibusb-common.c |6
linux/drivers/media/dvb/dvb-usb/dibusb-mb.c |   17
linux/drivers/media/dvb/dvb-usb/digitv.c|7
linux/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c   |   11
linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h   |2
linux/drivers/media/dvb/dvb-usb/dvb-usb.h   |8
linux/drivers/media/dvb/dvb-usb/gl861.c |3
linux/drivers/media/dvb/dvb-usb/m920x.c |   14
linux/drivers/media/dvb/dvb-usb/opera1.c|3
linux/drivers/media/dvb/dvb-usb/ttusb2.c|3
linux/drivers/media/dvb/dvb-usb/umt-010.c   |3
linux/drivers/media/dvb/frontends/at76c651.c|2
linux/drivers/media/dvb/frontends/bsbe1.h   |3
linux/drivers/media/dvb/frontends/bsru6.h   |3
linux/drivers/media/dvb/frontends/cx22700.c |2
linux/drivers/media/dvb/frontends/cx22702.c |2
linux/drivers/media/dvb/frontends/cx24110.c |2
linux/drivers/media/dvb/frontends/dib3000mb.c   |2
linux/drivers/media/dvb/frontends/dib3000mc.c   |2
linux/drivers/media/dvb/frontends/dib7000m.c|2
linux/drivers/media/dvb/frontends/dib7000p.c|2

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Michael Krufky]

Markus Rechberger wrote:
 As from my side I don't have the time to do a major rewrite or doing
 some reordering again, please try to make the best out of what's
 available now.
 
 The patches include more than 9000 lines of codechanges through the
 v4l and dvb framework, these changes have been done during the last 1
 1/2 years of split development from the main v4l-dvb code, I know it's
 alot but it's worth to get it done now. It's not only about adding
 support for one new device only.

I know we've been over this, but I need to state my feelings on the matter, 
otherwise I would have to simply keep quiet, and that doesn't help the 
situation for anybody.

I _strongly_ feel that the core changes being proposed here will hurt the 
integrity of the dvb subsystem.  The main arguments for accepting these changes 
is that it adds support for over 60 devices and that the author doesn't have 
any more time to spend on this.

The argument currently on the table, is that these changes get merged now, and 
we fix any problems later.  I feel that this sets a bad president.  Who is to 
stop the NEXT developer from changing around the subsystem core  against the 
desires of those developers actively maintaining the project? 

We have an established internal API, and developers should keep subsystem 
codingstyle intact.  If we merge this now, who is to say that we will _ever_ 
get around to 'fixing' it?  We are having enough problems as it is trying to 
agree on a way to merge the xc3028 driver into the kernel -- how will we ever 
agree on the 'fixup' method later?  The answer is simple -- we'll never agree.

What does this mean?  It means that we have to compromise.  The ability to 
compromise is very important when more than one person is working on a project. 
 Heck, the word 'compromise' always comes up when people talk about marriage, 
living situations, etc.  It also applies to discussions such as this.

Again, as I understand, the most significant argument for pushing this in,  is 
to finally get driver support for these sixty some-odd devices into the kernel. 
 Please keep in mind that we're talking about a single tuner ic (xc3028) and 
the sixty devices that depend on the presence of the xc3028 driver.  We _are_ 
talking about a single device (ic).

Even still, if the priority is to merge support for the xc3028 tuner ic into 
the kernel in the quickest way possible, then there is a _much_ lesser evil 
available as an option.

I do frown upon code duplication, however, in this case it is a safer 
alternative to the one currently on the table.  Earlier versions of the xc3028 
tuner driver were bound to the video4linux tuner.ko module, for the sake of 
tuning analog television stations.  There was a wrapper present inside the 
em2880-dvb driver that allowed the dvb subsystem to access the xc3028 via 
tuner.ko.  I am not a big fan of this solution, however, it does not touch any 
core subsystem code.  DVB-only devices can use a separate module in order to 
access the xc3028 without imposing dependencies on the v4l core.

I have already written such a module, based on Markus' work, and it has already 
been proven in the field as a working solution.  see xc3028-fe.c in: 
http://www.linuxtv.org/~mkrufky/xc-bluebird.patch

The only argument against this method, is that it requires some code 
duplication -- two drivers for the xc3028.  One for analog via the v4l 
subsystem, the other for dvb via the dvb subsystem.  I repeat -- I am NOT 
promoting code duplication, however, given the circumstances, and the fact that 
the reason for all the controversy is that people want the xc3028 driver merged 
into the kernel asap, this solution is truly the lesser of two evils.  We 
already have some code duplicated for simple pll's such as the fmd1216me and 
lgh06xf tuners -- the only difference is the size of the code.

If we decide to go this route, it will truly be the best compromise -- It will 
allow us to merge in support for the sixty some-odd devices that Markus is 
talking about, and it will allow for easy development of newer devices that use 
this tuner ic.  The major benefit of this method is that it _will_ allow for us 
developers to put our heads together after the fact, and find better ways of 
supporting hybrid tuners.  At that point, the pressure of 'trying to merge 
support for sixty devices' will be gone.  Developers will finally be able to 
discuss this issue without the pressure of the current pending issues, and we 
_will_ be able to find a better solution.

As far as I can tell, it seems that this is the only way for us to push this 
through, while not upsetting other developers.  However, I must repeat that 
following my proposal does create a maintenance problem -- It means that any 
changes to the xc3028-tuner module will have to be carried over to the 
xc3028-fe module.  Once the two modules get merged, however, it will become 
more apparent to developers as to the reasons why we need a better solution. 

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[hermann pitton]

Am Montag, den 14.05.2007, 20:22 -0400 schrieb Michael Krufky:
 Markus Rechberger wrote:
  As from my side I don't have the time to do a major rewrite or doing
  some reordering again, please try to make the best out of what's
  available now.
  
  The patches include more than 9000 lines of codechanges through the
  v4l and dvb framework, these changes have been done during the last 1
  1/2 years of split development from the main v4l-dvb code, I know it's
  alot but it's worth to get it done now. It's not only about adding
  support for one new device only.
 
 I know we've been over this, but I need to state my feelings on the matter, 
 otherwise I would have to simply keep quiet, and that doesn't help the 
 situation for anybody.
 
 I _strongly_ feel that the core changes being proposed here will hurt the 
 integrity of the dvb subsystem.  The main arguments for accepting these 
 changes is that it adds support for over 60 devices and that the author 
 doesn't have any more time to spend on this.
 
 The argument currently on the table, is that these changes get merged now, 
 and we fix any problems later.  I feel that this sets a bad president.  Who 
 is to stop the NEXT developer from changing around the subsystem core  
 against the desires of those developers actively maintaining the project? 
 
 We have an established internal API, and developers should keep subsystem 
 codingstyle intact.  If we merge this now, who is to say that we will _ever_ 
 get around to 'fixing' it?  We are having enough problems as it is trying to 
 agree on a way to merge the xc3028 driver into the kernel -- how will we ever 
 agree on the 'fixup' method later?  The answer is simple -- we'll never agree.
 
 What does this mean?  It means that we have to compromise.  The ability to 
 compromise is very important when more than one person is working on a 
 project.  Heck, the word 'compromise' always comes up when people talk about 
 marriage, living situations, etc.  It also applies to discussions such as 
 this.
 
 Again, as I understand, the most significant argument for pushing this in,  
 is to finally get driver support for these sixty some-odd devices into the 
 kernel.  Please keep in mind that we're talking about a single tuner ic 
 (xc3028) and the sixty devices that depend on the presence of the xc3028 
 driver.  We _are_ talking about a single device (ic).
 
 Even still, if the priority is to merge support for the xc3028 tuner ic into 
 the kernel in the quickest way possible, then there is a _much_ lesser evil 
 available as an option.
 
 I do frown upon code duplication, however, in this case it is a safer 
 alternative to the one currently on the table.  Earlier versions of the 
 xc3028 tuner driver were bound to the video4linux tuner.ko module, for the 
 sake of tuning analog television stations.  There was a wrapper present 
 inside the em2880-dvb driver that allowed the dvb subsystem to access the 
 xc3028 via tuner.ko.  I am not a big fan of this solution, however, it does 
 not touch any core subsystem code.  DVB-only devices can use a separate 
 module in order to access the xc3028 without imposing dependencies on the v4l 
 core.
 
 I have already written such a module, based on Markus' work, and it has 
 already been proven in the field as a working solution.  see xc3028-fe.c in: 
 http://www.linuxtv.org/~mkrufky/xc-bluebird.patch
 
 The only argument against this method, is that it requires some code 
 duplication -- two drivers for the xc3028.  One for analog via the v4l 
 subsystem, the other for dvb via the dvb subsystem.  I repeat -- I am NOT 
 promoting code duplication, however, given the circumstances, and the fact 
 that the reason for all the controversy is that people want the xc3028 driver 
 merged into the kernel asap, this solution is truly the lesser of two evils.  
 We already have some code duplicated for simple pll's such as the fmd1216me 
 and lgh06xf tuners -- the only difference is the size of the code.
 
 If we decide to go this route, it will truly be the best compromise -- It 
 will allow us to merge in support for the sixty some-odd devices that Markus 
 is talking about, and it will allow for easy development of newer devices 
 that use this tuner ic.  The major benefit of this method is that it _will_ 
 allow for us developers to put our heads together after the fact, and find 
 better ways of supporting hybrid tuners.  At that point, the pressure of 
 'trying to merge support for sixty devices' will be gone.  Developers will 
 finally be able to discuss this issue without the pressure of the current 
 pending issues, and we _will_ be able to find a better solution.
 
 As far as I can tell, it seems that this is the only way for us to push this 
 through, while not upsetting other developers.  However, I must repeat that 
 following my proposal does create a maintenance problem -- It means that any 
 changes to the xc3028-tuner module will have to be carried over to the 
 

Re: [linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88

[Markus Rechberger]

On 5/15/07, hermann pitton [EMAIL PROTECTED] wrote:

Am Montag, den 14.05.2007, 20:22 -0400 schrieb Michael Krufky:
 Markus Rechberger wrote:
  As from my side I don't have the time to do a major rewrite or doing
  some reordering again, please try to make the best out of what's
  available now.
 
  The patches include more than 9000 lines of codechanges through the
  v4l and dvb framework, these changes have been done during the last 1
  1/2 years of split development from the main v4l-dvb code, I know it's
  alot but it's worth to get it done now. It's not only about adding
  support for one new device only.

 I know we've been over this, but I need to state my feelings on the
matter, otherwise I would have to simply keep quiet, and that doesn't help
the situation for anybody.

 I _strongly_ feel that the core changes being proposed here will hurt the
integrity of the dvb subsystem.  The main arguments for accepting these
changes is that it adds support for over 60 devices and that the author
doesn't have any more time to spend on this.

 The argument currently on the table, is that these changes get merged now,
and we fix any problems later.  I feel that this sets a bad president.  Who
is to stop the NEXT developer from changing around the subsystem core
against the desires of those developers actively maintaining the project?

 We have an established internal API, and developers should keep subsystem
codingstyle intact.  If we merge this now, who is to say that we will _ever_
get around to 'fixing' it?  We are having enough problems as it is trying to
agree on a way to merge the xc3028 driver into the kernel -- how will we
ever agree on the 'fixup' method later?  The answer is simple -- we'll never
agree.

 What does this mean?  It means that we have to compromise.  The ability to
compromise is very important when more than one person is working on a
project.  Heck, the word 'compromise' always comes up when people talk about
marriage, living situations, etc.  It also applies to discussions such as
this.

 Again, as I understand, the most significant argument for pushing this in,
 is to finally get driver support for these sixty some-odd devices into the
kernel.  Please keep in mind that we're talking about a single tuner ic
(xc3028) and the sixty devices that depend on the presence of the xc3028
driver.  We _are_ talking about a single device (ic).

 Even still, if the priority is to merge support for the xc3028 tuner ic
into the kernel in the quickest way possible, then there is a _much_ lesser
evil available as an option.

 I do frown upon code duplication, however, in this case it is a safer
alternative to the one currently on the table.  Earlier versions of the
xc3028 tuner driver were bound to the video4linux tuner.ko module, for the
sake of tuning analog television stations.  There was a wrapper present
inside the em2880-dvb driver that allowed the dvb subsystem to access the
xc3028 via tuner.ko.  I am not a big fan of this solution, however, it does
not touch any core subsystem code.  DVB-only devices can use a separate
module in order to access the xc3028 without imposing dependencies on the
v4l core.

 I have already written such a module, based on Markus' work, and it has
already been proven in the field as a working solution.  see xc3028-fe.c in:
http://www.linuxtv.org/~mkrufky/xc-bluebird.patch

 The only argument against this method, is that it requires some code
duplication -- two drivers for the xc3028.  One for analog via the v4l
subsystem, the other for dvb via the dvb subsystem.  I repeat -- I am NOT
promoting code duplication, however, given the circumstances, and the fact
that the reason for all the controversy is that people want the xc3028
driver merged into the kernel asap, this solution is truly the lesser of two
evils.  We already have some code duplicated for simple pll's such as the
fmd1216me and lgh06xf tuners -- the only difference is the size of the code.

 If we decide to go this route, it will truly be the best compromise -- It
will allow us to merge in support for the sixty some-odd devices that Markus
is talking about, and it will allow for easy development of newer devices
that use this tuner ic.  The major benefit of this method is that it _will_
allow for us developers to put our heads together after the fact, and find
better ways of supporting hybrid tuners.  At that point, the pressure of
'trying to merge support for sixty devices' will be gone.  Developers will
finally be able to discuss this issue without the pressure of the current
pending issues, and we _will_ be able to find a better solution.

 As far as I can tell, it seems that this is the only way for us to push
this through, while not upsetting other developers.  However, I must repeat
that following my proposal does create a maintenance problem -- It means
that any changes to the xc3028-tuner module will have to be carried over to
the xc3028-fe module.  Once the two modules get merged, however, it