On 9/15/07, Mauro Carvalho Chehab <mchehab@infradead.org> wrote:
quoted text
> > The main discussion in this thread was about drivers in userspace
> > are bad because the API will allow binary drivers.
>
> No. The focus is that userspace API is not needed at all, and the
> community believe that this is a regression from all efforts that are
> being done by the community to have good quality OSS software.
>

please have a look at:
http://mcentral.de/wiki/index.php/Bugtracker


quoted text
> > The guy
> > who works for Hauppauge (again I also have good contacts
> > at Hauppauge Europe) writes it's bad - for no technical reason.
>
> Please stop with personal attacks.
>

This is no personal attack.

quoted text
> > I (again) don't intend to
> > release binary drivers. (also keep in mind that ubuntu takes
> > everything which makes things work - this matters to the enduser)
>
> Markus, you are thinking that all the community are fool?

You're using the word "community" in a quite abstract way here.
Please document how the linuxtv community behaves behind the
lines, and I would even like that those people who discussed several
things would start to write about their other personal issues with
that project which I'm not part of.

quoted text
> You used to
> state on your website that your intention were to release binary-only
> xc5000 drivers.

people talk alot, in the end only the result counts. So if you've seen
any binary driver from my side point out to it. To be honest
I think if I would have gone the same way as Avermedia from the
beginning on to release binary drivers it would have saved months
of development and the main distros could already have _full_
support for all the features.
The driver as it is now is not perfect either it requires quite some
more work to get all features work flawlessly around the globe for
all the users.

quoted text
> So, please stop with childish and assume what you've said.
>
> > Mauro is copying the logic of my code and writes I told him I'm ok with
> > taking my code without just adding a single line of how his driver
> > got developed. (I still wonder why he skipped some significant parts
> > of the driver .. because he used the existing one as logic template)
> >
> >
> http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/t...
>
> The basis for tuner-xc2028 driver is tea5767. The xc2028/xc3028 drivers
> is very simple:
>
> a) load the proper firmware;
> b) send one 32 bits command to select frequency + the frequency divider.
>

well people see if they compare the code what you took from the existing
driver.

quoted text
> All the rest is the common logic of a tuner driver.
>
> If you take a look at my driver, you will see that the implementation is
> different, providing also those functionalities:
>
> - provides a sync during frequency setting, needed by tm6000;
> - has the logic to retrieve signal status;
> - part of the firmware need to be reload every time you change a freq
> (tm6000 driver needs it);
> - supports just the firmwares I've identified as being used by tm6000
> driver;
>
> The only thing I used is your usbreplay.pl, as properly stated at
> README.first (properly pointing to your site).
>
> Again, please stop with personal attacks. This leads to nowhere.
>

If you look at my current implementation and even the implementation
which I had a year ago many problems are solved there.
I don't mind if you don't want to use the userspace tuner API, it's not
a replacement for the inkernel version, it makes it just easy to
implement it.
The current and upcoming em28xx devices will use it, just to avoid
that I have to redo all the work hundret times for no real reason.

quoted text
>
> >From my side, I've nacked your userspace tuner.
>
> However, I keep open to accept your kernelspace em28xx/xc3028 drivers,
> providing that they fits at the current V4L/DVB core.
>

I don't even want to use that existing driver in future (as I wrote earlier
already). The newer module will be a dropin userspace replacement for
what's available. I got around 70 devices work with it at the moment,
although I don't even want to reinvent the wheel so I'll take what I've
received from some companies. That way all I have to do is to use
the provided API of those silicon sample drivers.

quoted text
> Changes at common APIs, and especially at Kernel to userspace API should
> be discussed with the community. If you accept this fact, you may also
> propose improvements at the APIs.
>

That for I wrote the RFCs which didn't get discussed properly and where
2 people of that "community" told me to use something which won't work
out at all.
And hey, why didn't those guys do what they told me to do in the end?
Because they wanted to do it by themself only. Although it's the base
of the driver without a proper base it just screams for more work in the
end.

quoted text
> If, after all that were discussed, you're willing to do a serious work,
> please send us the patches for em28xx/xc3028 kernelspace drivers.
> Otherwise, I'll kindly ask you to take your own way and stop with those
> flamewars.
>

You don't have to use it if you don't like it, and I get around those
restrictions and I'm able to fix up and extend the features for the
upcoming devices without interfering your work.

Markus
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/