On 30/04/07 22:17, Markus Rechberger wrote:
> Trent Piepho wrote another patch for it, it just completes Uwe's patch
> in the end.
> From my side I do not see any problem with that patch, if someone else
> has a problem with it please state out the reason.
I have no problem with the patch since it has nothing to do with my DVB
card but you're only encouraging Uwe to be abusive since it seems to
help get him what he wants:
On 01/05/07 00:05, Uwe Bugla wrote:
> Piepho, you are a devil, and your links do not work at all!
> Uwe
On 01/05/07 00:40, Uwe Bugla wrote:
> Go to hell, Manuel Abraham, and do not return at all to absolutely no thinkable condition at all, and never come back to this place once more again
> Just goto hell, you goddamn deeply asocial miserable sonofabitch!!
>
> Uwe
> On 4/30/07, Markus Rechberger <[email protected]> wrote:
>> it's enough, I told him that I'll look at it and try to get some other
>> people involved if it really breaks something it should get stated
>> out; and I'll refuse any further help if he starts to write any more
>> abusive mail.
It's not working. Patches should still be applied on the basis of what
they do and how, not why they were made, of course.
--
Simon Arlott
On 5/1/07, Simon Arlott <[email protected]> wrote:
> On 30/04/07 22:17, Markus Rechberger wrote:
> > Trent Piepho wrote another patch for it, it just completes Uwe's patch
> > in the end.
> > From my side I do not see any problem with that patch, if someone else
> > has a problem with it please state out the reason.
>
> I have no problem with the patch since it has nothing to do with my DVB
> card but you're only encouraging Uwe to be abusive since it seems to
> help get him what he wants:
>
> On 01/05/07 00:05, Uwe Bugla wrote:
> > Piepho, you are a devil, and your links do not work at all!
> > Uwe
>
> On 01/05/07 00:40, Uwe Bugla wrote:
> > Go to hell, Manuel Abraham, and do not return at all to absolutely no
> thinkable condition at all, and never come back to this place once more
> again
> > Just goto hell, you goddamn deeply asocial miserable sonofabitch!!
> >
> > Uwe
>
> > On 4/30/07, Markus Rechberger <[email protected]> wrote:
> >> it's enough, I told him that I'll look at it and try to get some other
> >> people involved if it really breaks something it should get stated
> >> out; and I'll refuse any further help if he starts to write any more
> >> abusive mail.
>
> It's not working. Patches should still be applied on the basis of what
> they do and how, not why they were made, of course.
this patch was written by Trent, and it seems like he already had that
idea earlier too.
I really don't care if that patch goes in or not in the end, there's
just no need to flame around for it.
The only reason I see is that it's not needed to link it statically
against the bt878 module and there isn't even much work to do.
Uwe's Makefile patch worked as expected, but it wasn't clean/complete
enough that was a reason to not include it.
Now with Trent's patch I don't see that as a valid argument against it anymore.
And the email from Manu claiming that it generates alot work (which is
btw. 2 years old) doesn't seem to be valid either.
Markus
-------- Original-Nachricht --------
Datum: Tue, 1 May 2007 11:00:44 +0200
Von: "Markus Rechberger" <[email protected]>
An: "Simon Arlott" <[email protected]>
CC: Manu Abraham <[email protected]>, [email protected], [email protected], Jan Engelhardt <[email protected]>, [email protected], [email protected], [email protected]
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
> On 5/1/07, Simon Arlott <[email protected]> wrote:
> > On 30/04/07 22:17, Markus Rechberger wrote:
> > > Trent Piepho wrote another patch for it, it just completes Uwe's patch
> > > in the end.
> > > From my side I do not see any problem with that patch, if someone else
> > > has a problem with it please state out the reason.
> >
> > I have no problem with the patch since it has nothing to do with my DVB
> > card but you're only encouraging Uwe to be abusive since it seems to
> > help get him what he wants:
> >
> > On 01/05/07 00:05, Uwe Bugla wrote:
> > > Piepho, you are a devil, and your links do not work at all!
> > > Uwe
> >
> > On 01/05/07 00:40, Uwe Bugla wrote:
> > > Go to hell, Manuel Abraham, and do not return at all to absolutely no
> > thinkable condition at all, and never come back to this place once more
> > again
> > > Just goto hell, you goddamn deeply asocial miserable sonofabitch!!
> > >
> > > Uwe
> >
> > > On 4/30/07, Markus Rechberger <[email protected]> wrote:
> > >> it's enough, I told him that I'll look at it and try to get some
> other
> > >> people involved if it really breaks something it should get stated
> > >> out; and I'll refuse any further help if he starts to write any more
> > >> abusive mail.
> >
> > It's not working. Patches should still be applied on the basis of what
> > they do and how, not why they were made, of course.
>
> this patch was written by Trent, and it seems like he already had that
> idea earlier too.
>
> I really don't care if that patch goes in or not in the end, there's
> just no need to flame around for it.
>
> The only reason I see is that it's not needed to link it statically
> against the bt878 module and there isn't even much work to do.
> Uwe's Makefile patch worked as expected, but it wasn't clean/complete
> enough that was a reason to not include it.
> Now with Trent's patch I don't see that as a valid argument against it
> anymore.
> And the email from Manu claiming that it generates alot work (which is
> btw. 2 years old) doesn't seem to be valid either.
>
> Markus
Thank you, Markus - you are a real fine and straight chap.
You should be team leader of this community.
BTW:
Are my latest attempts sent to you already involved in the latest development state
(Read: Is dvb-pll.c deselectable now without breaking support for lgdt330)?
I simply stumbled over that lgdt330 binding in module dvb-bt8xx.c, line 641 or so.
Anything else I resolved at least from my personal side.
A thousands of thanks to you and Trent - well done!
>
> _______________________________________________
> linux-dvb mailing list
> [email protected]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
On Tue, 1 May 2007, Simon Arlott wrote:
> On 30/04/07 22:17, Markus Rechberger wrote:
> > From my side I do not see any problem with that patch, if someone else
> > has a problem with it please state out the reason.
>
> I have no problem with the patch since it has nothing to do with my DVB
> card but you're only encouraging Uwe to be abusive since it seems to
> help get him what he wants:
I've been aware of the problem with dst not fully using the dvb customization
systems(*) for a long time. It came up when dvb_attach() et al were first
being integrated, well before any rejected patches or strongly worded emails
or whatever from certain people that I'm aware of.
I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and since
I already know about the issues here, I felt I should post a patch for them
any other reasonable developers who might spend time on this.
If there is an abusive person, I'm not going to let it affect my behavior.
You lose if you let them influence your decisions one way, or influence them
another way.
(*) There are two customization/dependency control systems in DVB. One is
dvb_attach(), the other is DVB_FE_CUSTOMISE. They are not two entirely
separate systems, but overlap in their design a great deal.
The significant part, common to both, is the overall design of the driver
framework. DVB uses what I would describe as an object oriented system. A
driver for a certain type of hardware exports a single attach function, which
returns an object for one instance of that hardware. All control of that
hardware is done via methods defined in this object. There is typical
hierarchy, where an 'adapter' object will contain a 'frontend' object which
will contain a 'tuner' object. Of course hardware designers are not
constrained by the software frameworks we create, so sometimes it's more
complex (e.g., dst).
This design means the actual hard link between different drivers is limited to
each driver's single attach function (**). By breaking this one link, we can
control which drivers must be loaded or linked to only those necessary or
wanted. dvb_attach() and DVB_FE_CUSTOMISE are two different ways of
controlling these links.
dvb_attach() is based on symbol_request()
A. It's only useful with modules
B. It doesn't prevent drivers from being compiled
C. It allows one to build support for hardware, yet not actually load that
support until it is needed. This allows supporting a wide array of
possible hardware without a large amount of wasted resources, useful for
distribution kernels for example.
DVB_FE_CUSTOMISE is based on Kconfig and static inline stub functions
A. It works with drivers compiled into the kernel, not using modules.
B. It prevents drivers from even being compiled in the first place.
C. Disabled drivers are truly disabled, it is not possible to have support
for hardware and yet not load it.
This is useful for the smallest & simplest kernel, for set top boxes and the
like. It's entirely possible to use both at once: compile some drivers into
your kernel, leave others as modules, not compile modules for hardware you
don't have, only load the modules for the hardware you are using at the
moment, and still support hardware you might connect later.
(**) The dvb-pll module still exports more symbols than just dvb_pll_attach(),
that is why the customization systems don't fully work with it yet. It also
exports dvb_pll_configure(), an obsolete interface which only a couple
remaining users that have yet been converted. And it exports PLL definition
structs, which isn't a difficult problem and I know several ways to fix it, we
just haven't decided or actually done it yet.
Trent Piepho wrote:
> On Tue, 1 May 2007, Simon Arlott wrote:
>> On 30/04/07 22:17, Markus Rechberger wrote:
>>> From my side I do not see any problem with that patch, if someone else
>>> has a problem with it please state out the reason.
>> I have no problem with the patch since it has nothing to do with my DVB
>> card but you're only encouraging Uwe to be abusive since it seems to
>> help get him what he wants:
>
> I've been aware of the problem with dst not fully using the dvb customization
> systems(*) for a long time. It came up when dvb_attach() et al were first
> being integrated, well before any rejected patches or strongly worded emails
> or whatever from certain people that I'm aware of.
>
Well, your understanding of the device is quite limited and hence your
comments and patches.
The DST as it refers to is an embedded system a x86 Compatible RISC core
[1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own
IO and 2 DMA channels. What we have is a PQFP device
This is the case in most cases. On some cheaper cards the embedded
system is replaced by an 8 bit host microcontroller, to cut down costs
where all the features are not required for a specific model
Additionally this embedded system has a fast shovelling engine for the
MPEG2 TS routing in between the
This embedded system is connected to an actual
(1) DVB frontend [2]
(2) DVB CA interface [3]
(3) Analog tuner
(4) Audio interfaces
These features are not the characteristics of a DVB Frontend. Here there
is a DVB frontend like the normal ones which is hidden behind another
pseudo bridge (So you don't have *any* access to the frontend at large)
It is not necessary that *all* the dst cards (there are around ~15
different variants of the same) do have the very same feature set.
It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
fact it is a combo driver supporting the entire devices using a common
command set
In such a case it has more characteristics of the PCI bridge and in fact
heavily tied to it and has it's own advantages.
> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and since
> I already know about the issues here, I felt I should post a patch for them
> any other reasonable developers who might spend time on this.
>
I would think that it would be *extremely* rude for a person to send in
patches for a device that which you don't understand at all, when it is
for limiting the capability of the said device
> If there is an abusive person, I'm not going to let it affect my behavior.
> You lose if you let them influence your decisions one way, or influence them
> another way.
>
>
> (*) There are two customization/dependency control systems in DVB. One is
> dvb_attach(), the other is DVB_FE_CUSTOMISE. They are not two entirely
> separate systems, but overlap in their design a great deal.
>
Here we have the attach method attaching different objects, but
basically it can be handled for the frontend devices only (and that too
that share a very common trait, in this case, frontends are coupled
using the i2c bus) and not for other devices. Situation changes when you
use another interface such as SPI, where the interface is not well defined.
In the DVB OO concept we have, where the objects are at different
levels, the basic concept is that an object is indeed a smaller subset,
depending on the level that which it pertains to. In such a case the
frontend is limited to do just frontend related operations. There could
be other ways that things can be done maybe the DVB API can be redone to
have all DVB operations through the frontend alone. But that is not at
all decent way of doing it.
> The significant part, common to both, is the overall design of the driver
> framework. DVB uses what I would describe as an object oriented system. A
> driver for a certain type of hardware exports a single attach function, which
> returns an object for one instance of that hardware. All control of that
> hardware is done via methods defined in this object. There is typical
> hierarchy, where an 'adapter' object will contain a 'frontend' object which
> will contain a 'tuner' object. Of course hardware designers are not
> constrained by the software frameworks we create, so sometimes it's more
> complex (e.g., dst).
It is a bit more complex than you think. You can imagine the entire
DVB-CORE along with proprietory vendor specific tuning algorithms (on
all devices, specific to the hardware onbaord. Algorithms do change from
slight change of hardware such as demodulators and or CA interface
stacks) on CA devices it has an onboard EN50221 CA stack from SCM [4]
called the Sunplus CI stack. On Hybrid DST devices they do feature in
analog core support in there as well as Audio too on some cards.
It is not a constraint as what you might think, as the DST is complete
hardware solution of the interfaces that you are talking about. (There
are 2 approaches, (1) do everything in hardware (2) do everything in
software) there are merits and demerits equally to both the approaches.
So here we are talking about 3 different subsystems DVB, V4L and ALSA.
Currently the DST supports *only* DVB and that too it is limited. There
is more to DVB than what you see in the DST as of now.
Support for multiple delivery systems do not exists as of now (requires
the multiproto DVB API patches)
With these said, i wouldn't want to close the window for the dst to be a
DVB frontend alone, as that's what you are trying to do
> This design means the actual hard link between different drivers is limited to
> each driver's single attach function (**). By breaking this one link, we can
> control which drivers must be loaded or linked to only those necessary or
> wanted. dvb_attach() and DVB_FE_CUSTOMISE are two different ways of
> controlling these links.
dvb_attach will have to go away for the DST. It doesn't work for the
mentioned reasons that it is just pushing the device to a corner as a
DVB frontend whereas it is not a DVB Frontend at all.
[1] R8820 CPU core
http://jusst.de/manu/misc/R8820-F19.pdf
[2] DVB Fontend
A DVB Frontend consists of a Demodulator
(http://www.linuxtv.org/wiki/index.php/Demodulator) and a tuner
[3] DVB CA interface
A CA Interface consists of a CI slot
(http://www.linuxtv.org/wiki/index.php/Common_Interface) and a
CA module (http://www.linuxtv.org/wiki/index.php/CAM)
[4] http://www.scmmicro.com/
-------- Original-Nachricht --------
Datum: Wed, 02 May 2007 17:30:32 +0400
Von: Manu Abraham <[email protected]>
An: Trent Piepho <[email protected]>
CC: Simon Arlott <[email protected]>, Linux Kernel Mailing list <[email protected]>, [email protected], Jan Engelhardt <[email protected]>, [email protected], [email protected], Linux DVB <[email protected]>
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
> Trent Piepho wrote:
> > On Tue, 1 May 2007, Simon Arlott wrote:
> >> On 30/04/07 22:17, Markus Rechberger wrote:
> >>> From my side I do not see any problem with that patch, if someone else
> >>> has a problem with it please state out the reason.
> >> I have no problem with the patch since it has nothing to do with my DVB
> >> card but you're only encouraging Uwe to be abusive since it seems to
> >> help get him what he wants:
> >
> > I've been aware of the problem with dst not fully using the dvb
> customization
> > systems(*) for a long time. It came up when dvb_attach() et al were
> first
> > being integrated, well before any rejected patches or strongly worded
> emails
> > or whatever from certain people that I'm aware of.
> >
>
> Well, your understanding of the device is quite limited and hence your
> comments and patches.
>
> The DST as it refers to is an embedded system a x86 Compatible RISC core
> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own
> IO and 2 DMA channels. What we have is a PQFP device
>
> This is the case in most cases. On some cheaper cards the embedded
> system is replaced by an 8 bit host microcontroller, to cut down costs
> where all the features are not required for a specific model
>
> Additionally this embedded system has a fast shovelling engine for the
> MPEG2 TS routing in between the
> This embedded system is connected to an actual
> (1) DVB frontend [2]
> (2) DVB CA interface [3]
> (3) Analog tuner
> (4) Audio interfaces
>
> These features are not the characteristics of a DVB Frontend. Here there
> is a DVB frontend like the normal ones which is hidden behind another
> pseudo bridge (So you don't have *any* access to the frontend at large)
>
> It is not necessary that *all* the dst cards (there are around ~15
> different variants of the same) do have the very same feature set.
>
> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
> fact it is a combo driver supporting the entire devices using a common
> command set
>
> In such a case it has more characteristics of the PCI bridge and in fact
> heavily tied to it and has it's own advantages.
>
> > I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and
> since
> > I already know about the issues here, I felt I should post a patch for
> them
> > any other reasonable developers who might spend time on this.
> >
>
> I would think that it would be *extremely* rude for a person to send in
> patches for a device that which you don't understand at all, when it is
> for limiting the capability of the said device
Hi Manu,
now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it.
Fact is:
Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did...
Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level.
So please why, instead of marking other people as "rude" whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level?
Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen...
And this would conform to practising the synergetic principle, wouldn't it?
Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do).
Above that:
1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality.
2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all) it is no good start at all if your humble effort is being thrown off after the first or second reject. That's highly discouraging, and if it happens very often the bad experience remains in one's own subjective perception filter.
3. When I wrote patches since then I never gave up until there weren't any
a. fuzz factors
b. rejections
anymore. Instead I highly tried to put Andrew's "The perfect patch"-guidelines into practice. Although this kind of perfection reduces maintainers to gatekeepers in some cases - the borders of what is what and who is who are highly mutual...
So the basic thing is just:
1. To understand that everyone develops, independent from the knowledge and understanding level.
2. To understand that everyone has good ideas at least sometimes, independent from knowledge and understanding level.
And, even if you do not want to understand it out of whatever reason, it is no fun for any person to sound or act "abusive".
We're all just trying to search and find solutions, that's all.
Above that I want to thank you for the theoretical introduction that you gave.
And I hope it helps after all.
But I am still very sad that the cx878 project died the way it died, so very close before its maturity to be implied into Mercurial tree. I did my best to help, but in the end I nothing but wasted time - and after all, I do not remember where the repository resides, after thaddatil.net has been down for months now... What a pity!
Cheers
Uwe
>
> > If there is an abusive person, I'm not going to let it affect my
> behavior.
> > You lose if you let them influence your decisions one way, or influence
> them
> > another way.
> >
> >
> > (*) There are two customization/dependency control systems in DVB. One
> is
> > dvb_attach(), the other is DVB_FE_CUSTOMISE. They are not two entirely
> > separate systems, but overlap in their design a great deal.
> >
>
>
> Here we have the attach method attaching different objects, but
> basically it can be handled for the frontend devices only (and that too
> that share a very common trait, in this case, frontends are coupled
> using the i2c bus) and not for other devices. Situation changes when you
> use another interface such as SPI, where the interface is not well
> defined.
>
> In the DVB OO concept we have, where the objects are at different
> levels, the basic concept is that an object is indeed a smaller subset,
> depending on the level that which it pertains to. In such a case the
> frontend is limited to do just frontend related operations. There could
> be other ways that things can be done maybe the DVB API can be redone to
> have all DVB operations through the frontend alone. But that is not at
> all decent way of doing it.
>
>
> > The significant part, common to both, is the overall design of the
> driver
> > framework. DVB uses what I would describe as an object oriented system.
> A
> > driver for a certain type of hardware exports a single attach function,
> which
> > returns an object for one instance of that hardware. All control of
> that
> > hardware is done via methods defined in this object. There is typical
> > hierarchy, where an 'adapter' object will contain a 'frontend' object
> which
> > will contain a 'tuner' object. Of course hardware designers are not
> > constrained by the software frameworks we create, so sometimes it's more
> > complex (e.g., dst).
>
> It is a bit more complex than you think. You can imagine the entire
> DVB-CORE along with proprietory vendor specific tuning algorithms (on
> all devices, specific to the hardware onbaord. Algorithms do change from
> slight change of hardware such as demodulators and or CA interface
> stacks) on CA devices it has an onboard EN50221 CA stack from SCM [4]
> called the Sunplus CI stack. On Hybrid DST devices they do feature in
> analog core support in there as well as Audio too on some cards.
>
> It is not a constraint as what you might think, as the DST is complete
> hardware solution of the interfaces that you are talking about. (There
> are 2 approaches, (1) do everything in hardware (2) do everything in
> software) there are merits and demerits equally to both the approaches.
>
> So here we are talking about 3 different subsystems DVB, V4L and ALSA.
> Currently the DST supports *only* DVB and that too it is limited. There
> is more to DVB than what you see in the DST as of now.
> Support for multiple delivery systems do not exists as of now (requires
> the multiproto DVB API patches)
>
> With these said, i wouldn't want to close the window for the dst to be a
> DVB frontend alone, as that's what you are trying to do
>
> > This design means the actual hard link between different drivers is
> limited to
> > each driver's single attach function (**). By breaking this one link,
> we can
> > control which drivers must be loaded or linked to only those necessary
> or
> > wanted. dvb_attach() and DVB_FE_CUSTOMISE are two different ways of
> > controlling these links.
>
> dvb_attach will have to go away for the DST. It doesn't work for the
> mentioned reasons that it is just pushing the device to a corner as a
> DVB frontend whereas it is not a DVB Frontend at all.
>
> [1] R8820 CPU core
> http://jusst.de/manu/misc/R8820-F19.pdf
>
> [2] DVB Fontend
> A DVB Frontend consists of a Demodulator
> (http://www.linuxtv.org/wiki/index.php/Demodulator) and a tuner
>
> [3] DVB CA interface
> A CA Interface consists of a CI slot
> (http://www.linuxtv.org/wiki/index.php/Common_Interface) and a
> CA module (http://www.linuxtv.org/wiki/index.php/CAM)
>
> [4] http://www.scmmicro.com/
>
> _______________________________________________
> linux-dvb mailing list
> [email protected]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Uwe Bugla wrote:
> -------- Original-Nachricht --------
> Datum: Wed, 02 May 2007 17:30:32 +0400
> Von: Manu Abraham <[email protected]>
> An: Trent Piepho <[email protected]>
> CC: Simon Arlott <[email protected]>, Linux Kernel Mailing list <[email protected]>, [email protected], Jan Engelhardt <[email protected]>, [email protected], [email protected], Linux DVB <[email protected]>
> Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
>
>> Trent Piepho wrote:
>>> On Tue, 1 May 2007, Simon Arlott wrote:
>>>> On 30/04/07 22:17, Markus Rechberger wrote:
>>>>> From my side I do not see any problem with that patch, if someone else
>>>>> has a problem with it please state out the reason.
>>>> I have no problem with the patch since it has nothing to do with my DVB
>>>> card but you're only encouraging Uwe to be abusive since it seems to
>>>> help get him what he wants:
>>> I've been aware of the problem with dst not fully using the dvb
>> customization
>>> systems(*) for a long time. It came up when dvb_attach() et al were
>> first
>>> being integrated, well before any rejected patches or strongly worded
>> emails
>>> or whatever from certain people that I'm aware of.
>>>
>> Well, your understanding of the device is quite limited and hence your
>> comments and patches.
>>
>> The DST as it refers to is an embedded system a x86 Compatible RISC core
>> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own
>> IO and 2 DMA channels. What we have is a PQFP device
>>
>> This is the case in most cases. On some cheaper cards the embedded
>> system is replaced by an 8 bit host microcontroller, to cut down costs
>> where all the features are not required for a specific model
>>
>> Additionally this embedded system has a fast shovelling engine for the
>> MPEG2 TS routing in between the
>> This embedded system is connected to an actual
>> (1) DVB frontend [2]
>> (2) DVB CA interface [3]
>> (3) Analog tuner
>> (4) Audio interfaces
>>
>> These features are not the characteristics of a DVB Frontend. Here there
>> is a DVB frontend like the normal ones which is hidden behind another
>> pseudo bridge (So you don't have *any* access to the frontend at large)
>>
>> It is not necessary that *all* the dst cards (there are around ~15
>> different variants of the same) do have the very same feature set.
>>
>> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
>> fact it is a combo driver supporting the entire devices using a common
>> command set
>>
>> In such a case it has more characteristics of the PCI bridge and in fact
>> heavily tied to it and has it's own advantages.
>>
>>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and
>> since
>>> I already know about the issues here, I felt I should post a patch for
>> them
>>> any other reasonable developers who might spend time on this.
>>>
>> I would think that it would be *extremely* rude for a person to send in
>> patches for a device that which you don't understand at all, when it is
>> for limiting the capability of the said device
>
> Hi Manu,
> now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it.
>
> Fact is:
> Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did...
>
> Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level.
>
> So please why, instead of marking other people as "rude" whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level?
> Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen...
> And this would conform to practising the synergetic principle, wouldn't it?
>
> Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do).
>
> Above that:
> 1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality.
> 2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all) it is no good start at all if your humble effort is being thrown off after the first or second reject. That's highly discouraging, and if it happens very often the bad experience remains in one's own subjective perception filter.
i did really start very small during those early stages. Johannes did
help me a lot in many areas, he gave me a lot of valuable information,
for which i am thankful to him. The same goes to Ralph Metzler and many
others who gave me a big hand to bootup. Can't forget Andrew, Marcel et
all in this regard (I did try to pass on such information to some
people, they thought i was trying to sabotage their project etc. I
stopped responding publicly as you might have seen. At one point i did
throw away all DVB development, i did write the same on the #linuxtv IRC
channel, did send a mail to Johannes too on that) It was just one user
who got me back again on it, a North American DVB user
In many cases it would be very nerving to work on hardware that is
extremely undocumented. Sometimes you will have to wait for weeks for a
certain person (persons who worked on the chips etc. On top of this
people who worked on the devices will move away to newer organizations.
Currently facing the same with another chip) to be free to provide an
answer for the question. In short requires a lot of patience. On top of
this when someone flames you in the little time one has.. well, many a
times i lost my temper, yes.
Sorry, if i was real bad.
> 3. When I wrote patches since then I never gave up until there weren't any
> a. fuzz factors
> b. rejections
> anymore. Instead I highly tried to put Andrew's "The perfect patch"-guidelines into practice. Although this kind of perfection reduces maintainers to gatekeepers in some cases - the borders of what is what and who is who are highly mutual...
>
> So the basic thing is just:
> 1. To understand that everyone develops, independent from the knowledge and understanding level.
> 2. To understand that everyone has good ideas at least sometimes, independent from knowledge and understanding level.
>
> And, even if you do not want to understand it out of whatever reason, it is no fun for any person to sound or act "abusive".
> We're all just trying to search and find solutions, that's all.
>
> Above that I want to thank you for the theoretical introduction that you gave.
> And I hope it helps after all.
> But I am still very sad that the cx878 project died the way it died, so very close before its maturity to be implied into Mercurial tree. I did my best to help, but in the end I nothing but wasted time - and after all, I do not remember where the repository resides, after thaddatil.net has been down for months now... What a pity!
No, the cx878 project never died. thadathil.net was hosted at my office.
When the office moved a bit and some other complications, thadathil.net
went offline. on top of that, at work i was given additional
responsibilities for which i was struggling real hard. work with regards
to DVB i just do it in my spare time, but i try to steal away some time
from office work as well.
Christoph usually used to review all my code as well as some others.
With the upcoming KDE4, he was working more with kaffeine and had little
time, himself.
And as you might be aware i was working with a new delivery system
DVB-S2. When one works with a new delivery system, the existing API
proved too restrictive. Then working on which i trampled onto many
issues (not even referring to the new delivery system, or the issues
with the demodulator, mind you S2 is a bit complex and can really
confuse people.) with DVB-CORE itself, which led to another API update
other than multiproto, the Adapter API extensions. while on this again
stumbled where advanced operations where performed at the in kernel
demuxer, not forgetting an additional DSS demuxer is also needed in
kernel for DSS support.
With all these and struggling hard with 4 hours sleep, well i couldn't
take all those flames (More than what you see on the ML's many people
tend to send private mails for some reason or the other for help.
Normally i don't reject anyone's request), you can say i was kind of
worn out. Above all these some developers were very "unfriendly", some
did mischief (politics) too, which led to a larger rift.
So i chose to remain silent. That's all.
During this period, Julian was kind enough to provide me hosting for my
requirements. I will try to get thadathil.net up soon (many people used
to have firmware downloads from there, also some people had access there
for hosting test repo's and so on)
Well, that was a long rant
Uwe Bugla wrote:
> -------- Original-Nachricht --------
> Datum: Wed, 02 May 2007 17:30:32 +0400
> Von: Manu Abraham <[email protected]>
> An: Trent Piepho <[email protected]>
> CC: Simon Arlott <[email protected]>, Linux Kernel Mailing list <[email protected]>, [email protected], Jan Engelhardt <[email protected]>, [email protected], [email protected], Linux DVB <[email protected]>
> Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
>
>> Trent Piepho wrote:
>>> On Tue, 1 May 2007, Simon Arlott wrote:
>>>> On 30/04/07 22:17, Markus Rechberger wrote:
>>>>> From my side I do not see any problem with that patch, if someone else
>>>>> has a problem with it please state out the reason.
>>>> I have no problem with the patch since it has nothing to do with my DVB
>>>> card but you're only encouraging Uwe to be abusive since it seems to
>>>> help get him what he wants:
>>> I've been aware of the problem with dst not fully using the dvb
>> customization
>>> systems(*) for a long time. It came up when dvb_attach() et al were
>> first
>>> being integrated, well before any rejected patches or strongly worded
>> emails
>>> or whatever from certain people that I'm aware of.
>>>
>> Well, your understanding of the device is quite limited and hence your
>> comments and patches.
>>
>> The DST as it refers to is an embedded system a x86 Compatible RISC core
>> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own
>> IO and 2 DMA channels. What we have is a PQFP device
>>
>> This is the case in most cases. On some cheaper cards the embedded
>> system is replaced by an 8 bit host microcontroller, to cut down costs
>> where all the features are not required for a specific model
>>
>> Additionally this embedded system has a fast shovelling engine for the
>> MPEG2 TS routing in between the
>> This embedded system is connected to an actual
>> (1) DVB frontend [2]
>> (2) DVB CA interface [3]
>> (3) Analog tuner
>> (4) Audio interfaces
>>
>> These features are not the characteristics of a DVB Frontend. Here there
>> is a DVB frontend like the normal ones which is hidden behind another
>> pseudo bridge (So you don't have *any* access to the frontend at large)
>>
>> It is not necessary that *all* the dst cards (there are around ~15
>> different variants of the same) do have the very same feature set.
>>
>> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
>> fact it is a combo driver supporting the entire devices using a common
>> command set
>>
>> In such a case it has more characteristics of the PCI bridge and in fact
>> heavily tied to it and has it's own advantages.
>>
>>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and
>> since
>>> I already know about the issues here, I felt I should post a patch for
>> them
>>> any other reasonable developers who might spend time on this.
>>>
>> I would think that it would be *extremely* rude for a person to send in
>> patches for a device that which you don't understand at all, when it is
>> for limiting the capability of the said device
>
> Hi Manu,
> now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it.
>
> Fact is:
> Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did...
>
> Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level.
>
> So please why, instead of marking other people as "rude" whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level?
> Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen...
> And this would conform to practising the synergetic principle, wouldn't it?
>
> Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do).
>
> Above that:
> 1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality.
> 2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all) it is no good start at all if your humble effort is being thrown off after the first or second reject. That's highly discouraging, and if it happens very often the bad experience remains in one's own subjective perception filter.
i did really start very small during those early stages. Johannes did
help me a lot in many areas, he gave me a lot of valuable information,
for which i am thankful to him. The same goes to Ralph Metzler and many
others who gave me a big hand to bootup. Can't forget Andrew, Marcel et
all in this regard (I did try to pass on such information to some
people, they thought i was trying to sabotage their project etc. I
stopped responding publicly as you might have seen. At one point i did
throw away all DVB development, i did write the same on the #linuxtv IRC
channel, did send a mail to Johannes too on that) It was just one user
who got me back again on it, a North American DVB user
In many cases it would be very nerving to work on hardware that is
extremely undocumented. Sometimes you will have to wait for weeks for a
certain person (persons who worked on the chips etc. On top of this
people who worked on the devices will move away to newer organizations.
Currently facing the same with another chip) to be free to provide an
answer for the question. In short requires a lot of patience. On top of
this when someone flames you in the little time one has.. well, many a
times i lost my temper, yes.
Sorry, if i was real bad.
> 3. When I wrote patches since then I never gave up until there weren't any
> a. fuzz factors
> b. rejections
> anymore. Instead I highly tried to put Andrew's "The perfect patch"-guidelines into practice. Although this kind of perfection reduces maintainers to gatekeepers in some cases - the borders of what is what and who is who are highly mutual...
>
> So the basic thing is just:
> 1. To understand that everyone develops, independent from the knowledge and understanding level.
> 2. To understand that everyone has good ideas at least sometimes, independent from knowledge and understanding level.
>
> And, even if you do not want to understand it out of whatever reason, it is no fun for any person to sound or act "abusive".
> We're all just trying to search and find solutions, that's all.
>
> Above that I want to thank you for the theoretical introduction that you gave.
> And I hope it helps after all.
> But I am still very sad that the cx878 project died the way it died, so very close before its maturity to be implied into Mercurial tree. I did my best to help, but in the end I nothing but wasted time - and after all, I do not remember where the repository resides, after thaddatil.net has been down for months now... What a pity!
No, the cx878 project never died. thadathil.net was hosted at my office.
When the office moved a bit and some other complications, thadathil.net
went offline. on top of that, at work i was given additional
responsibilities for which i was struggling real hard. work with regards
to DVB i just do it in my spare time, but i try to steal away some time
from office work as well.
Christoph usually used to review all my code as well as some others.
With the upcoming KDE4, he was working more with kaffeine and had little
time, himself.
And as you might be aware i was working with a new delivery system
DVB-S2. When one works with a new delivery system, the existing API
proved too restrictive. Then working on which i trampled onto many
issues (not even referring to the new delivery system, or the issues
with the demodulator, mind you S2 is a bit complex and can really
confuse people.) with DVB-CORE itself, which led to another API update
other than multiproto, the Adapter API extensions. while on this again
stumbled where advanced operations where performed at the in kernel
demuxer, not forgetting an additional DSS demuxer is also needed in
kernel for DSS support.
With all these and struggling hard with 4 hours sleep, well i couldn't
take all those flames (More than what you see on the ML's many people
tend to send private mails for some reason or the other for help.
Normally i don't reject anyone's request), you can say i was kind of
worn out. Above all these some developers were very "unfriendly", some
did mischief (politics) too, which led to a larger rift.
So i chose to remain silent. That's all.
During this period, Julian was kind enough to provide me hosting for my
requirements. I will try to get thadathil.net up soon (many people used
to have firmware downloads from there, also some people had access there
for hosting test repo's and so on)
Well, that was a long rant
On 5/2/07, Manu Abraham <[email protected]> wrote:
> Uwe Bugla wrote:
> > -------- Original-Nachricht --------
> > Datum: Wed, 02 May 2007 17:30:32 +0400
> > Von: Manu Abraham <[email protected]>
> > An: Trent Piepho <[email protected]>
> > CC: Simon Arlott <[email protected]>, Linux Kernel Mailing list
> <[email protected]>, [email protected], Jan
> Engelhardt <[email protected]>, [email protected],
> [email protected], Linux DVB <[email protected]>
> > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was:
> Critical points about ...)
> >
> >> Trent Piepho wrote:
> >>> On Tue, 1 May 2007, Simon Arlott wrote:
> >>>> On 30/04/07 22:17, Markus Rechberger wrote:
> >>>>> From my side I do not see any problem with that patch, if someone else
> >>>>> has a problem with it please state out the reason.
> >>>> I have no problem with the patch since it has nothing to do with my DVB
> >>>> card but you're only encouraging Uwe to be abusive since it seems to
> >>>> help get him what he wants:
> >>> I've been aware of the problem with dst not fully using the dvb
> >> customization
> >>> systems(*) for a long time. It came up when dvb_attach() et al were
> >> first
> >>> being integrated, well before any rejected patches or strongly worded
> >> emails
> >>> or whatever from certain people that I'm aware of.
> >>>
> >> Well, your understanding of the device is quite limited and hence your
> >> comments and patches.
> >>
> >> The DST as it refers to is an embedded system a x86 Compatible RISC core
> >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own
> >> IO and 2 DMA channels. What we have is a PQFP device
> >>
> >> This is the case in most cases. On some cheaper cards the embedded
> >> system is replaced by an 8 bit host microcontroller, to cut down costs
> >> where all the features are not required for a specific model
> >>
> >> Additionally this embedded system has a fast shovelling engine for the
> >> MPEG2 TS routing in between the
> >> This embedded system is connected to an actual
> >> (1) DVB frontend [2]
> >> (2) DVB CA interface [3]
> >> (3) Analog tuner
> >> (4) Audio interfaces
> >>
> >> These features are not the characteristics of a DVB Frontend. Here there
> >> is a DVB frontend like the normal ones which is hidden behind another
> >> pseudo bridge (So you don't have *any* access to the frontend at large)
> >>
> >> It is not necessary that *all* the dst cards (there are around ~15
> >> different variants of the same) do have the very same feature set.
> >>
> >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
> >> fact it is a combo driver supporting the entire devices using a common
> >> command set
> >>
> >> In such a case it has more characteristics of the PCI bridge and in fact
> >> heavily tied to it and has it's own advantages.
> >>
> >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and
> >> since
> >>> I already know about the issues here, I felt I should post a patch for
> >> them
> >>> any other reasonable developers who might spend time on this.
> >>>
> >> I would think that it would be *extremely* rude for a person to send in
> >> patches for a device that which you don't understand at all, when it is
> >> for limiting the capability of the said device
> >
> > Hi Manu,
> > now if this is your evalution about it all, then let me tell you that I
> feel deeply sorry about it.
> >
> > Fact is:
> > Noone ever intended to send in patches limiting the capability of the said
> device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others
> never did...
> >
> > Instead of this we all have very different knowledge and understanding
> levels, with you obviously being the one with the most elaborate and
> sophisticated level.
> >
> > So please why, instead of marking other people as "rude" whose solutions
> you do not appreciate at all, don't you just pick up the pratical proposals
> of other persons, even if you do not like them for some reasons, and at
> least try to raise them up to a far more better level?
> > Thus you definitely could avoid a lots of flaming, misunderstanding, and
> other counterproductive things to happen...
> > And this would conform to practising the synergetic principle, wouldn't
> it?
> >
> > Just one hint to help you: I remember a mail from Johannes in which he
> told me that you started up this whole development thing from a zero level
> some two or three years ago. And Johannes not forgot to state that in the
> beginning you were nothing but nerving... (now add a smiley behind this,
> please, I'd deeply appreciate you to do).
> >
> > Above that:
> > 1. Taking part in testing the mm-tree and eliminating horrible bugs in it
> I never experienced but positive and warm compromise solutions in the end.
> Experiencing this is highly enlarging one's own personality.
> > 2. If you start up at zero (like you did once too - see above and ask
> Johannes if you do not remember at all) it is no good start at all if your
> humble effort is being thrown off after the first or second reject. That's
> highly discouraging, and if it happens very often the bad experience remains
> in one's own subjective perception filter.
>
>
> i did really start very small during those early stages. Johannes did
> help me a lot in many areas, he gave me a lot of valuable information,
> for which i am thankful to him. The same goes to Ralph Metzler and many
> others who gave me a big hand to bootup. Can't forget Andrew, Marcel et
> all in this regard (I did try to pass on such information to some
> people, they thought i was trying to sabotage their project etc.
Instead of describing what the matter was why don't you just try to
get forward now without playing the rebellian here, we sorted out a
way and accept it now.
Afterwards let's discuss what you want to change to get your changes in.
I really have the impression that you try to limit to give away useful
information, and afterwards you wonder why people don't understand
what you mean.
You should also describe the impact on other things (eg. your upcoming
work), don't expect that anyone on any mailinglist here knows what
code you host somewhere on your private servers at home.
> I stopped responding publicly as you might have seen. At one point i did
> throw away all DVB development, i did write the same on the #linuxtv IRC
> channel, did send a mail to Johannes too on that) It was just one user
> who got me back again on it, a North American DVB user
>
> In many cases it would be very nerving to work on hardware that is
> extremely undocumented. Sometimes you will have to wait for weeks for a
> certain person (persons who worked on the chips etc. On top of this
> people who worked on the devices will move away to newer organizations.
> Currently facing the same with another chip) to be free to provide an
> answer for the question. In short requires a lot of patience. On top of
> this when someone flames you in the little time one has.. well, many a
> times i lost my temper, yes.
>
> Sorry, if i was real bad.
>
> > 3. When I wrote patches since then I never gave up until there weren't any
> > a. fuzz factors
> > b. rejections
> > anymore. Instead I highly tried to put Andrew's "The perfect
> patch"-guidelines into practice. Although this kind of perfection reduces
> maintainers to gatekeepers in some cases - the borders of what is what and
> who is who are highly mutual...
> >
> > So the basic thing is just:
> > 1. To understand that everyone develops, independent from the knowledge
> and understanding level.
> > 2. To understand that everyone has good ideas at least sometimes,
> independent from knowledge and understanding level.
> >
> > And, even if you do not want to understand it out of whatever reason, it
> is no fun for any person to sound or act "abusive".
> > We're all just trying to search and find solutions, that's all.
> >
> > Above that I want to thank you for the theoretical introduction that you
> gave.
> > And I hope it helps after all.
> > But I am still very sad that the cx878 project died the way it died, so
> very close before its maturity to be implied into Mercurial tree. I did my
> best to help, but in the end I nothing but wasted time - and after all, I do
> not remember where the repository resides, after thaddatil.net has been down
> for months now... What a pity!
>
> No, the cx878 project never died. thadathil.net was hosted at my office.
> When the office moved a bit and some other complications, thadathil.net
> went offline. on top of that, at work i was given additional
> responsibilities for which i was struggling real hard. work with regards
> to DVB i just do it in my spare time, but i try to steal away some time
> from office work as well.
>
> Christoph usually used to review all my code as well as some others.
> With the upcoming KDE4, he was working more with kaffeine and had little
> time, himself.
>
> And as you might be aware i was working with a new delivery system
> DVB-S2. When one works with a new delivery system, the existing API
> proved too restrictive. Then working on which i trampled onto many
> issues (not even referring to the new delivery system, or the issues
> with the demodulator, mind you S2 is a bit complex and can really
> confuse people.) with DVB-CORE itself, which led to another API update
> other than multiproto, the Adapter API extensions. while on this again
> stumbled where advanced operations where performed at the in kernel
> demuxer, not forgetting an additional DSS demuxer is also needed in
> kernel for DSS support.
>
Is there any proposal available which describes these changes?
> With all these and struggling hard with 4 hours sleep, well i couldn't
> take all those flames (More than what you see on the ML's many people
> tend to send private mails for some reason or the other for help.
> Normally i don't reject anyone's request), you can say i was kind of
> worn out. Above all these some developers were very "unfriendly", some
> did mischief (politics) too, which led to a larger rift.
>
Try to get all parties satisfied here, if you don't want dvb_attach
for the DST/BT878 to be used here explain why so that everyone
understands it, I don't see that anything gets locked out because the
current code uses a very similar method at the moment (yes I know that
it's no frontend, but it's not even implemented as something really
special)
If you have future plans about it write about them, and write why they
will hurt your work.
Markus
> So i chose to remain silent. That's all.
>
> During this period, Julian was kind enough to provide me hosting for my
> requirements. I will try to get thadathil.net up soon (many people used
> to have firmware downloads from there, also some people had access there
> for hosting test repo's and so on)
>
> Well, that was a long rant
>
>
> _______________________________________________
> linux-dvb mailing list
> [email protected]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>
--
Markus Rechberger
-------- Original-Nachricht --------
Datum: Wed, 02 May 2007 20:45:58 +0400
Von: Manu Abraham <[email protected]>
An: Uwe Bugla <[email protected]>
CC: [email protected], [email protected]
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
> Uwe Bugla wrote:
> > -------- Original-Nachricht --------
> > Datum: Wed, 02 May 2007 17:30:32 +0400
> > Von: Manu Abraham <[email protected]>
> > An: Trent Piepho <[email protected]>
> > CC: Simon Arlott <[email protected]>, Linux Kernel Mailing list
> <[email protected]>, [email protected], Jan Engelhardt
> <[email protected]>, [email protected],
> [email protected], Linux DVB <[email protected]>
> > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was:
> Critical points about ...)
> >
> >> Trent Piepho wrote:
> >>> On Tue, 1 May 2007, Simon Arlott wrote:
> >>>> On 30/04/07 22:17, Markus Rechberger wrote:
> >>>>> From my side I do not see any problem with that patch, if someone
> else
> >>>>> has a problem with it please state out the reason.
> >>>> I have no problem with the patch since it has nothing to do with my
> DVB
> >>>> card but you're only encouraging Uwe to be abusive since it seems to
> >>>> help get him what he wants:
> >>> I've been aware of the problem with dst not fully using the dvb
> >> customization
> >>> systems(*) for a long time. It came up when dvb_attach() et al were
> >> first
> >>> being integrated, well before any rejected patches or strongly worded
> >> emails
> >>> or whatever from certain people that I'm aware of.
> >>>
> >> Well, your understanding of the device is quite limited and hence your
> >> comments and patches.
> >>
> >> The DST as it refers to is an embedded system a x86 Compatible RISC
> core
> >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's
> own
> >> IO and 2 DMA channels. What we have is a PQFP device
> >>
> >> This is the case in most cases. On some cheaper cards the embedded
> >> system is replaced by an 8 bit host microcontroller, to cut down costs
> >> where all the features are not required for a specific model
> >>
> >> Additionally this embedded system has a fast shovelling engine for the
> >> MPEG2 TS routing in between the
> >> This embedded system is connected to an actual
> >> (1) DVB frontend [2]
> >> (2) DVB CA interface [3]
> >> (3) Analog tuner
> >> (4) Audio interfaces
> >>
> >> These features are not the characteristics of a DVB Frontend. Here
> there
> >> is a DVB frontend like the normal ones which is hidden behind another
> >> pseudo bridge (So you don't have *any* access to the frontend at large)
> >>
> >> It is not necessary that *all* the dst cards (there are around ~15
> >> different variants of the same) do have the very same feature set.
> >>
> >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
> >> fact it is a combo driver supporting the entire devices using a common
> >> command set
> >>
> >> In such a case it has more characteristics of the PCI bridge and in
> fact
> >> heavily tied to it and has it's own advantages.
> >>
> >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton,
> and
> >> since
> >>> I already know about the issues here, I felt I should post a patch for
> >> them
> >>> any other reasonable developers who might spend time on this.
> >>>
> >> I would think that it would be *extremely* rude for a person to send in
> >> patches for a device that which you don't understand at all, when it is
> >> for limiting the capability of the said device
> >
> > Hi Manu,
> > now if this is your evalution about it all, then let me tell you that I
> feel deeply sorry about it.
> >
> > Fact is:
> > Noone ever intended to send in patches limiting the capability of the
> said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and
> others never did...
> >
> > Instead of this we all have very different knowledge and understanding
> levels, with you obviously being the one with the most elaborate and
> sophisticated level.
> >
> > So please why, instead of marking other people as "rude" whose solutions
> you do not appreciate at all, don't you just pick up the pratical
> proposals of other persons, even if you do not like them for some reasons, and at
> least try to raise them up to a far more better level?
> > Thus you definitely could avoid a lots of flaming, misunderstanding, and
> other counterproductive things to happen...
> > And this would conform to practising the synergetic principle, wouldn't
> it?
> >
> > Just one hint to help you: I remember a mail from Johannes in which he
> told me that you started up this whole development thing from a zero level
> some two or three years ago. And Johannes not forgot to state that in the
> beginning you were nothing but nerving... (now add a smiley behind this,
> please, I'd deeply appreciate you to do).
> >
> > Above that:
> > 1. Taking part in testing the mm-tree and eliminating horrible bugs in
> it I never experienced but positive and warm compromise solutions in the
> end. Experiencing this is highly enlarging one's own personality.
> > 2. If you start up at zero (like you did once too - see above and ask
> Johannes if you do not remember at all) it is no good start at all if your
> humble effort is being thrown off after the first or second reject. That's
> highly discouraging, and if it happens very often the bad experience remains
> in one's own subjective perception filter.
>
>
> i did really start very small during those early stages. Johannes did
> help me a lot in many areas, he gave me a lot of valuable information,
> for which i am thankful to him. The same goes to Ralph Metzler and many
> others who gave me a big hand to bootup. Can't forget Andrew, Marcel et
> all in this regard (I did try to pass on such information to some
> people, they thought i was trying to sabotage their project etc.
Hi Manu,
I think noone ever thought you were trying to sabotage any project.
Perhaps you simply missed to „sell“ your ideas a little bit better on the eloquence level.
Example: During this horrible bt8xx breakdown period (kernels 2.6.13 up to 2.6.17-rc1) it was Edgar who definitely did not have the technically better approach, but „sold“ his thoughts far more transparent, reading more logical.
But in the end it was your approach that ensured the best possible solution in the end, not anybody else's.
I
> stopped responding publicly as you might have seen. At one point i did
> throw away all DVB development, i did write the same on the #linuxtv IRC
> channel, did send a mail to Johannes too on that) It was just one user
> who got me back again on it, a North American DVB user
I would like to be the second one to encourage you to get back on it, as it is a great pity if such a great profound knowledge just disappears from the surface.
>
> In many cases it would be very nerving to work on hardware that is
> extremely undocumented.
I know, as I had Email contact to Peter Hettkamp, the author of the cx24110 frontend. He told me about the hindrance policy executed by the companies:
a. Pinnacle never offered free cards for linux driver development
b. Connexant only offers info if you sign a very restrictive paper
Plus, on the other hand, the drivers that are written and published for Windoze are a catastrophe like the whole system itself is a catastrophe.
Sometimes you will have to wait for weeks for a
> certain person (persons who worked on the chips etc. On top of this
> people who worked on the devices will move away to newer organizations.
> Currently facing the same with another chip) to be free to provide an
> answer for the question. In short requires a lot of patience. On top of
> this when someone flames you in the little time one has.. well, many a
> times i lost my temper, yes.
>
> Sorry, if i was real bad.
I can accept that as it reads very truthful. But in fact the biggest shame is on me because I started to flame you. So please forgive me for having done this.
When I first saw this cx878 project I had the impression that you were trying to get it done on people's backs without ensuring the continuity of a working driver (speak: a bttv dependent one). This may sound quite absurd, but it's my personally view why this immensely long breakdown period ever happened at all.
IMHO there should be exactly two plans:
a. Trying to improve the existing working concept by making dst, dst_ca, and dvb-pll deselectable in a way that does not cause any Oopses or regressions anyway: There is not much work to be done. Just merge my work on makefile and Kconfig with Trent Piepho's work on the rest.
And if you are not satisfied with that for whatever reason I'd deeply appreciate you to settle down in it and add the necessary code that you personally are missing. Should not be much effort, should it?
b. Trying to finish the bt878 project, which is very close to being real mature (Christoph responded that he does not have any time for it so he personally sees no future for it, which is a pity, but should never be a hindrance not to finish it as it follows the right path).
On the technical layer I noticed that I heard some Pinnacle relais click during testing, but there were some i2c_bus symbols missing during compilation. So I guess those missing symbols are responsible for getting neither picture nor sound.
I do not think that the traditional bttv dependencies are such a high and hopeless hindrance reason that cannot be overcome at all.
We're gonna make it if we stick together.
BUT:
It would be utmost terrible to merge both plans with two different priorities into one. For the moment, plan a is highest priority.
But plan b should not be forgotten anyway.
I can offer testing and documentary work for both plans.
>
> > 3. When I wrote patches since then I never gave up until there weren't
> any
> > a. fuzz factors
> > b. rejections
> > anymore. Instead I highly tried to put Andrew's "The perfect
> patch"-guidelines into practice. Although this kind of perfection reduces maintainers
> to gatekeepers in some cases - the borders of what is what and who is who
> are highly mutual...
> >
> > So the basic thing is just:
> > 1. To understand that everyone develops, independent from the knowledge
> and understanding level.
> > 2. To understand that everyone has good ideas at least sometimes,
> independent from knowledge and understanding level.
> >
> > And, even if you do not want to understand it out of whatever reason, it
> is no fun for any person to sound or act "abusive".
> > We're all just trying to search and find solutions, that's all.
> >
> > Above that I want to thank you for the theoretical introduction that you
> gave.
> > And I hope it helps after all.
> > But I am still very sad that the cx878 project died the way it died, so
> very close before its maturity to be implied into Mercurial tree. I did my
> best to help, but in the end I nothing but wasted time - and after all, I
> do not remember where the repository resides, after thaddatil.net has been
> down for months now... What a pity!
>
> No, the cx878 project never died. thadathil.net was hosted at my office.
> When the office moved a bit and some other complications, thadathil.net
> went offline. on top of that, at work i was given additional
> responsibilities for which i was struggling real hard. work with regards
> to DVB i just do it in my spare time, but i try to steal away some time
> >from office work as well.
>
> Christoph usually used to review all my code as well as some others.
> With the upcoming KDE4, he was working more with kaffeine and had little
> time, himself.
>
> And as you might be aware i was working with a new delivery system
> DVB-S2. When one works with a new delivery system, the existing API
> proved too restrictive. Then working on which i trampled onto many
> issues (not even referring to the new delivery system, or the issues
> with the demodulator, mind you S2 is a bit complex and can really
> confuse people.) with DVB-CORE itself, which led to another API update
> other than multiproto, the Adapter API extensions. while on this again
> stumbled where advanced operations where performed at the in kernel
> demuxer, not forgetting an additional DSS demuxer is also needed in
> kernel for DSS support.
>
> With all these and struggling hard with 4 hours sleep, well i couldn't
> take all those flames (More than what you see on the ML's many people
> tend to send private mails for some reason or the other for help.
> Normally i don't reject anyone's request), you can say i was kind of
> worn out. Above all these some developers were very "unfriendly", some
> did mischief (politics) too, which led to a larger rift.
Sounds horrible. I once again deeply regret what I started in the past, but I hope I gave enough hints how we all can learn out of it, including me.
If there is no team chief stepping in between to settle down attacks and ellbow egoisms then I think there is a big gap in the personnel structure of the linuxtv.org developpers team.
>
> So i chose to remain silent. That's all.
>
> During this period, Julian was kind enough to provide me hosting for my
> requirements. I will try to get thadathil.net up soon (many people used
> to have firmware downloads from there, also some people had access there
> for hosting test repo's and so on)
That sounds fantastic. So can we continue to put plan b into practice too??
>
> Well, that was a long rant
I hate the word „rant“ for its negative taste at least in the german translation.
I would rather say it was necessary to state all this.
And I also hat terminologies like „The perfect patch.“
Nothing is perfect. But the stepping forward idea is simply to put some puzzle parts together in an appropriate manner.
I guess the only reason why I flamed Mike Krufky was his rejection of unsigned patches. That was my fault too and I regret what I said about him. So please Mike, if you read this please forgive me.
IMHO a missing signature should not be treated like a fetish.
Also unsigned patches can contain good ideas, can't they?
Sometimes it is just necessary to merge the appropriate puzzle parts.
But, on the other hand I remember having asked Edgar at least five times for what reason he remained so stubborn in the signature question.
I never got back at least one reply on that, for whatever reason....
See, the conflict culture here very often conforms to something like a kindergarden, and I deeply regret that...
Above all I still am very hopeful that we can get back to the technical points to be resolved concerning plan a (optimize the bttv dependent concept for now).
Perhaps we should start another thread on this if everybody can agree.
And if you or anybody else feel that you run out of temper or lose control of whatever reason, just move one step backwards, sleep over it one or two nights, and take a new start then with a cool and calm mind...
Do I expect too much? Hope I do not!
Yours sincerely
Uwe
P. S.:
A. If you are really interested I can send you my basic puzzle parts in short, opening a new thread on this issue. Just give me a short response if you are interested.
B. If you want to continue the cx878 project please drop me a short note where I can download it to test and enlarge it with my own ideas as good as I can.
Must not be immediately (no sweat please), but I am looking forward to receive a response from you.
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Uwe Bugla wrote:
> On the technical layer I noticed that I heard some Pinnacle relais click during testing, but there were some i2c_bus symbols missing during compilation. So I guess those missing symbols are responsible for getting neither picture nor sound.
Can you send your compile warnings ? I couldn't find the same in my
mailbox any report on the same. Maybe my mail filter did something.
> A. If you are really interested I can send you my basic puzzle parts in short, opening a new thread on this issue. Just give me a short response if you are interested.
>
> B. If you want to continue the cx878 project please drop me a short note where I can download it to test and enlarge it with my own ideas as good as I can.
>
> Must not be immediately (no sweat please), but I am looking forward to receive a response from you.
>
What i would like to do is like this: Have the current state frozen as
it is, such that there is a fallback case (The dst is quite fragile and
change at some place would break another. ie, what looks good for one
DST variant is bad for the other). Work on a new tree (CX878) and
migrate stuff to it. Remove the old one, once things are done.
I wouldn't want to mess up the current working situation and hence.
-------- Original-Nachricht --------
Datum: Thu, 03 May 2007 18:44:36 +0400
Von: Manu Abraham <[email protected]>
An: Uwe Bugla <[email protected]>
CC: [email protected], [email protected]
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
> Uwe Bugla wrote:
>
> > On the technical layer I noticed that I heard some Pinnacle relais click
> during testing, but there were some i2c_bus symbols missing during
> compilation. So I guess those missing symbols are responsible for getting neither
> picture nor sound.
>
> Can you send your compile warnings ? I couldn't find the same in my
> mailbox any report on the same. Maybe my mail filter did something.
I can certainly send compile warnings and dmesg and whatever you need.
But at first I need another link WHERE I can download the actual cx878 code.
Is it thaddathil.net or where the hell has it gone?
Just send me one link please, otherwise I do not have any chance to help you, OK?
>
> > A. If you are really interested I can send you my basic puzzle parts in
> short, opening a new thread on this issue. Just give me a short response if
> you are interested.
> >
> > B. If you want to continue the cx878 project please drop me a short note
> where I can download it to test and enlarge it with my own ideas as good
> as I can.
> >
> > Must not be immediately (no sweat please), but I am looking forward to
> receive a response from you.
> >
>
> What i would like to do is like this: Have the current state frozen as
> it is, such that there is a fallback case (The dst is quite fragile and
> change at some place would break another. ie, what looks good for one
> DST variant is bad for the other). Work on a new tree (CX878) and
> migrate stuff to it. Remove the old one, once things are done.
>
> I wouldn't want to mess up the current working situation and hence.
Hi Manu,
But it would be an acceptable compromise FOR NOW, wouldn't it?
So please don't turn your back on it, even if it may be incomplete for your needs.
Just add your SOB and then focus on cx878 with full power, OK?
Anything else would be terrible in pschological terms, you know?
Just think about Trent, Markus, me, so many others, you know.
Do I expect too much? Hope I do not!
Plus:
If I should help you it would be a pleasure for me if you could offer an acceptable time window that fulfills the following aims:
a. not to exhaust or threaten or bug you or nerve you (noone wants that, you know)
b. give me and others a feeling for when things of whatever issue are done and resolved, you know.
So at least for me it's very hard to continue if the whole thing looks like a never ending story, you know? So please give us a chance. And please do better this time.
Just learn and develop, you know.
And be more transparent and eloquent this time, but do not crawl back into a snail house, OK?
Waiting for your link meanwhile to download that hopeful project...
CCing some other persons who are perhaps interested in this....
Yours sincerely
Uwe
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Uwe Bugla wrote:
> Hi Manu,
>
> But it would be an acceptable compromise FOR NOW, wouldn't it?
The reason is i do not wish to make changes to it, till i can fix it. It
is indeed hard to fix things that support a lot of devices, with
different issues. There are enough of issues in there.
You can look at all those frontend not found issues on the DVB ML.
The people who make all these noise, do nothing but just play politics.
Just do a search on the linux-dvb ML at gmane.org. You can easily find them.
> Waiting for your link meanwhile to download that hopeful project...
http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2
On 5/3/07, Manu Abraham <[email protected]> wrote:
> Uwe Bugla wrote:
>
> > Hi Manu,
> >
> > But it would be an acceptable compromise FOR NOW, wouldn't it?
>
>
> The reason is i do not wish to make changes to it, till i can fix it. It
> is indeed hard to fix things that support a lot of devices, with
> different issues. There are enough of issues in there.
>
> You can look at all those frontend not found issues on the DVB ML.
>
> The people who make all these noise, do nothing but just play politics.
> Just do a search on the linux-dvb ML at gmane.org. You can easily find them.
>
Manu,
to me it looks like your attitude is not acceptable here, I sent
several mails already which you just use to ignore.
If you don't change that attitude immediatelly I'd really wish to get
you banned of this community until you're open for discussions.
http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html
there's a bugreport and you fully ignore it, and you blame it on the
"politicians" here, telling me that there are mails out there
somewhere shows that you're not interested in getting forward.
I'm waiting for your response here.
Markus
> > Waiting for your link meanwhile to download that hopeful project...
>
> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2
>
--
Markus Rechberger
-------- Original-Nachricht --------
Datum: Thu, 03 May 2007 19:48:50 +0400
Von: Manu Abraham <[email protected]>
An: Uwe Bugla <[email protected]>
CC: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
> Uwe Bugla wrote:
>
> > Hi Manu,
> >
> > But it would be an acceptable compromise FOR NOW, wouldn't it?
>
>
> The reason is i do not wish to make changes to it, till i can fix it. It
> is indeed hard to fix things that support a lot of devices, with
> different issues. There are enough of issues in there.
>
> You can look at all those frontend not found issues on the DVB ML.
>
> The people who make all these noise, do nothing but just play politics.
> Just do a search on the linux-dvb ML at gmane.org. You can easily find
> them.
>
> > Waiting for your link meanwhile to download that hopeful project...
>
> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2
Sorry Manu,
incorrect link!
Why?
If you download the thing as tar.bz2 you get a zero file down.
However, if you download the thing as tar.gz you will succeed in getting it.
I'll sit down this evening, try to make changes to imply it into the actual mercurial tree, produce necessary patches and give you a bug report as far as the compilation errors are concerned.
I am really looking forward to see this fantastic thing finished....
It's worth it for a thousands of very good reasons, not only RAM optimization, but also stability and many many others...
So gimme some time, and perhaps please supply a tar.bz2 version if you can, or fix the download error (zero file) if there is any other reason that I cannot see.
OKIDOK so far?
Uwe
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Uwe Bugla wrote:
> -------- Original-Nachricht --------
> Datum: Thu, 03 May 2007 19:48:50 +0400
> Von: Manu Abraham <[email protected]>
> An: Uwe Bugla <[email protected]>
> CC: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
> Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
>
>> Uwe Bugla wrote:
>>
>>> Hi Manu,
>>>
>>> But it would be an acceptable compromise FOR NOW, wouldn't it?
>>
>> The reason is i do not wish to make changes to it, till i can fix it. It
>> is indeed hard to fix things that support a lot of devices, with
>> different issues. There are enough of issues in there.
>>
>> You can look at all those frontend not found issues on the DVB ML.
>>
>> The people who make all these noise, do nothing but just play politics.
>> Just do a search on the linux-dvb ML at gmane.org. You can easily find
>> them.
>>
>>> Waiting for your link meanwhile to download that hopeful project...
>> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2
>
> Sorry Manu,
>
> incorrect link!
> Why?
>
> If you download the thing as tar.bz2 you get a zero file down.
I think could be a bug in hgweb probably.
>
> However, if you download the thing as tar.gz you will succeed in getting it.
>
Ok. The gzip archive should be as good as the bzip archive, just that it
is slightly larger.
> I'll sit down this evening, try to make changes to imply it into the actual mercurial tree, produce necessary patches and give you a bug report as far as the compilation errors are concerned.
>
> I am really looking forward to see this fantastic thing finished....
> It's worth it for a thousands of very good reasons, not only RAM optimization, but also stability and many many others...
>
> So gimme some time, and perhaps please supply a tar.bz2 version if you can, or fix the download error (zero file) if there is any other reason that I cannot see.
>
Let me see why hgweb gives a zero length archive
Markus Rechberger wrote:
> Manu,
>
> to me it looks like your attitude is not acceptable here, I sent
> several mails already which you just use to ignore.
You very well know the reason why i am ignoring your mails. You just
tend to flame people for nothing. I tend to ignore the flamers.
> If you don't change that attitude immediatelly I'd really wish to get
> you banned of this community until you're open for discussions.
>
> http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html
>
> there's a bugreport and you fully ignore it, and you blame it on the
> "politicians" here, telling me that there are mails out there
> somewhere shows that you're not interested in getting forward.
>
That bug report very well proves my point.
> I'm waiting for your response here.
>
> Markus
>
>> > Waiting for your link meanwhile to download that hopeful project...
>>
>> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2
>>
>>
>
>
-------- Original-Nachricht --------
Datum: Thu, 3 May 2007 17:59:18 +0200
Von: "Markus Rechberger" <[email protected]>
An: "Manu Abraham" <[email protected]>
CC: "Uwe Bugla" <[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected]
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
> On 5/3/07, Manu Abraham <[email protected]> wrote:
> > Uwe Bugla wrote:
> >
> > > Hi Manu,
> > >
> > > But it would be an acceptable compromise FOR NOW, wouldn't it?
> >
> >
> > The reason is i do not wish to make changes to it, till i can fix it. It
> > is indeed hard to fix things that support a lot of devices, with
> > different issues. There are enough of issues in there.
> >
> > You can look at all those frontend not found issues on the DVB ML.
> >
> > The people who make all these noise, do nothing but just play politics.
> > Just do a search on the linux-dvb ML at gmane.org. You can easily find
> them.
> >
>
> Manu,
>
> to me it looks like your attitude is not acceptable here, I sent
> several mails already which you just use to ignore.
> If you don't change that attitude immediatelly I'd really wish to get
> you banned of this community until you're open for discussions.
>
> http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html
>
> there's a bugreport and you fully ignore it, and you blame it on the
> "politicians" here, telling me that there are mails out there
> somewhere shows that you're not interested in getting forward.
>
> I'm waiting for your response here.
>
> Markus
Hey Markus, fine chap: Please cool down! I just downloaded this cx878 thing which will beat a couple of flies with one attack once it is finished.
It will be more stable than every preceding driver, it will revolutionize RAM usage extraordinarily, and it will solve all outstanding technical problems involved in the current DST driver concept, if I did understand Manu right, which is different sometimes, but, as it seems, not impossible.
So he just changed his priorities, and if this thing is finished we all will be winning a lot in the end I guess...
So please at least try to get yourself involved into that project, even if there are outstanding human drawbacks - its hard with him, I know, but it is not impossible at all.
And the cx878 project is worth to engage oneself in for a thousands of very good reasons - just believe me, as I have already done a lot of testing work on it.
It's fine, and it will revolutionize the whole bt8xx driver concept.
So if there are many many people helping to finish it, that will be the best thing ever seen...
And as far Manu is concerned: he is a primadonna, as I am.
Primadonnas are real extraordinary people, you know.
So please do not beat him or treat him like this.
Yours sincerely
Uwe
Peace, brother!
>
> > > Waiting for your link meanwhile to download that hopeful project...
> >
> >
> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2
> >
>
>
> --
> Markus Rechberger
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Manu Abraham wrote:
> Uwe Bugla wrote:
>
>> If you download the thing as tar.bz2 you get a zero file down.
>>
>
> I think could be a bug in hgweb probably.
[snip]
> Let me see why hgweb gives a zero length archive
>
Manu,
We reported this bug to the selenic guys quite a long time ago... You
should inherit the fix if you upgrade mercurial on your server.
Regards,
Mike
Michael Krufky wrote:
> Manu Abraham wrote:
>> Uwe Bugla wrote:
>>
>>> If you download the thing as tar.bz2 you get a zero file down.
>>>
>> I think could be a bug in hgweb probably.
> [snip]
>> Let me see why hgweb gives a zero length archive
>>
> Manu,
>
> We reported this bug to the selenic guys quite a long time ago... You
> should inherit the fix if you upgrade mercurial on your server.
>
Cool. Thanks.
I think it is a newer version ..
[manu@bh ~]$ hg --version
Mercurial Distributed SCM (version 0.9)
Copyright (C) 2005 Matt Mackall <[email protected]>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
You have an account on that machine. Would you like to take a look ?
On 5/3/07, Manu Abraham <[email protected]> wrote:
> Markus Rechberger wrote:
>
> > Manu,
> >
> > to me it looks like your attitude is not acceptable here, I sent
> > several mails already which you just use to ignore.
>
> You very well know the reason why i am ignoring your mails. You just
> tend to flame people for nothing. I tend to ignore the flamers.
>
You should stop to rely on the history, since such a flame needs at
least 2 parties and back then you were also involved. There's nothing
else to say about that.
> > If you don't change that attitude immediatelly I'd really wish to get
> > you banned of this community until you're open for discussions.
> >
> > http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html
> >
> > there's a bugreport and you fully ignore it, and you blame it on the
> > "politicians" here, telling me that there are mails out there
> > somewhere shows that you're not interested in getting forward.
> >
>
> That bug report very well proves my point.
Well it would be nice if you could answer the question in that mail
then, I don't see any reason why you shouldn't answer it.
It's just a guess, but it seems like that you had a problem with other
developers at that part and it seems like it didn't get to an end
(probably because both parties didn't agree with each other)
Markus
On Wed, 2 May 2007, Manu Abraham wrote:
> > I've been aware of the problem with dst not fully using the dvb customization
> > systems(*) for a long time. It came up when dvb_attach() et al were first
> > being integrated, well before any rejected patches or strongly worded emails
> > or whatever from certain people that I'm aware of.
> >
>
> Well, your understanding of the device is quite limited and hence your
> comments and patches.
Manu, have you actually looked at the patch? It seems like you are just
rejecting everything that has anything to do with dst out of hand.
Can you point to any line of code there, and say what it breaks or what it
will make impossible?
> These features are not the characteristics of a DVB Frontend. Here there
> is a DVB frontend like the normal ones which is hidden behind another
> pseudo bridge (So you don't have *any* access to the frontend at large)
Again, did you actually look at the patch? I never so much as used the
word frontend to describe the dst. I didn't change the operation of the
dst in any way. I didn't move it to a new place in the framework.
The bt8xx driver talks to the dst module via the dvb_frontend object, my
patch has nothing to do with this. It is a simple patch for simple
programming issues and nothing to do with these larger issues you bring up.
> I would think that it would be *extremely* rude for a person to send in
> patches for a device that which you don't understand at all, when it is
> for limiting the capability of the said device
Is the problem that there is a bug in my patch? Or is your problem that I
was rude in submitting any patch at all that had anything to do with your
code? Do you feel that this part of the Linux kernel is owned by you, and
that no one else should be permitted to have anything to do with it?
> > (*) There are two customization/dependency control systems in DVB. One is
> > dvb_attach(), the other is DVB_FE_CUSTOMISE. They are not two entirely
> > separate systems, but overlap in their design a great deal.
>
> Here we have the attach method attaching different objects, but
> basically it can be handled for the frontend devices only (and that too
> that share a very common trait, in this case, frontends are coupled
> using the i2c bus) and not for other devices. Situation changes when you
> use another interface such as SPI, where the interface is not well defined.
This is not correct. The dvb_attach() system has no assumption that it will
be used for a front-end device. There are already users which are not
front-ends, such as tuners or lnb supply control chips, and yes, dst, which
will all know very well is not a frontend.
It also has nothing do with the i2c. The attached device could be connected
in any way. I plan to add dvb_attach() support for the cx88 secondary i2c bus
driver (aka vp3054), and that isn't even a different chip.
> > This design means the actual hard link between different drivers is limited to
> > each driver's single attach function (**). By breaking this one link, we can
> > control which drivers must be loaded or linked to only those necessary or
> > wanted. dvb_attach() and DVB_FE_CUSTOMISE are two different ways of
> > controlling these links.
>
> dvb_attach will have to go away for the DST. It doesn't work for the
> mentioned reasons that it is just pushing the device to a corner as a
> DVB frontend whereas it is not a DVB Frontend at all.
The dst is already using dvb_attach()! I'm not changing that at all.
> being the author and maintainer of dst/dst_ca and maintainer of
> dvb-bt8xx, i NACK this change
Can one become a maintainer just be declaring ones self to be so? Or is there
an expectation that a maintainer will in fact, maintain. That is to say,
address concerns in a timely fashion, review patches and work in good faith to
resolve problems with said patches.
> What i would like to do is like this: Have the current state frozen as
> it is,
So as maintainer you are declaring that no changes of any kind are permitted?
That is to say, the code should become frozen, un-fixed and un-updated, in
other words, _unmaintained_.
How can you have it both ways, that you are the maintainer and that it should
be unmaintained?
Trent Piepho wrote:
> This is not correct. The dvb_attach() system has no assumption that it will
> be used for a front-end device. There are already users which are not
> front-ends, such as tuners or lnb supply control chips,
SEC (aka Satellite Equipment Control) is a part of the frontend.
>
> So as maintainer you are declaring that no changes of any kind are permitted?
Please do take a look at the changesets whether it is as you say.