subject:"\[linux\-dvb\] \[PATCH\] Userspace tuner"


Em Sáb, 2007-09-15 às 16:33 +0200, Markus Rechberger escreveu:
> I'm off for the weekend now so have a nice one :-)

Enjoy your weekend. I really hope that you have some time to reflect and
review your positions during the weekend.

-- 
Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/15/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > Everyone knows that there are some issues even some internal
> > ones which I'm not part of.
>
> With respect to your kernel-userspace API for xc3028, you made something
> that seemed to be a dream: there's a consensus: not a single developer
> believed that this is the better way; nobody seems that this is the
> better approach.
>

Not a single developer out of 3-5 people? Seems fine with me, because
people didn't agree with anything else before either and tried to point
me to wrong solutions.
http://threebit.net/mail-archive/video4linux/msg07548.html

> So, or you are the only media developer with good sense in the face of
> the Earth, or you're incapable of understand the obvious: you're wrong
> with this approach. IMO, the answer is quite obvious.
>

that for you don't have to use it.
http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages

I'm off for the weekend now so have a nice one :-)
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

> Everyone knows that there are some issues even some internal
> ones which I'm not part of.

With respect to your kernel-userspace API for xc3028, you made something
that seemed to be a dream: there's a consensus: not a single developer
believed that this is the better way; nobody seems that this is the
better approach.

So, or you are the only media developer with good sense in the face of
the Earth, or you're incapable of understand the obvious: you're wrong
with this approach. IMO, the answer is quite obvious.

-- 
Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/15/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 15, 2007, Markus Rechberger wrote:
> >
> > it gets me thinking. Some core developers who I met during
> > the last few weeks (kernel summit, suse conference in czech)
> > told me to go on with it actually because the final plan isn't that
> > bad..
>
> I was referring to your code you posted for merging on linux-dvb,
> and which got rejected. Anyway, it's easy to agree with you if one
> has just heard _your_ version -- the purpose of this thread is to
> give people an alternate version of the story to complement
> yours, which would allow the people you talked to to think it over
> and change their mind. See if you can get of those people you
> talked to to post here to support you.
>

Everyone knows that there are some issues even some internal
ones which I'm not part of.
Not sure if you met some other kernel developers recently, all you
can hear is "those crazy media guys" (which just includes everyone
who works with media related drivers)

> > Beside that I'm just curious how much did you contribute
> > during the last 2 years to the lkml/linux kernel, and how much
> > do you want to contribute in future? (also from my side
> > talk is cheap (even for me) but getting something done costs
> > quite some time and feedback from other people)
>
> IOW you say if I don't write code I should shut up?
> Is that also what you tell users on your em28xx list
> when they dare to disagree with you?
>
> Nice...
>

This is a free world you can write whatever you want,
but if you want me to change my code you need to
convince me that I should acknowlidge your ideas.
And by not acknowlidging my requirements don't expect
that I will go back to the start and try to reinvent the
wheel. After almost 2 years I'm quite into those things
and I know what I want for my project and what I'll try
to achieve with what I'm doing.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Sat, Sep 15, 2007, Markus Rechberger wrote:
> The main discussion in this thread was about drivers in userspace
> are bad because the API will allow binary drivers. The guy
> who works for Hauppauge (again I also have good contacts
> at Hauppauge Europe) writes it's bad - for no technical reason.

It sends a shiver down my spine that seem to imply that you
use your Hauppauge Europe contact to lobby against the
efforts of Hauppauge USA employees to promote support for
Open Source kernel drivers within their company.

> If someone points out that it is bad (after reading the whole thread)
> why don't we put X.org, bash, well everything into the kernel?
> GPL is the saviour seems to be the saviour for some people in this
> world, but in the end it's still if people want to go that way.
> Much work has been done by other people before, my work
> is also just an additional contribution and I (again) don't intend to
> release binary drivers. (also keep in mind that ubuntu takes
> everything which makes things work - this matters to the enduser)
> 
> Hey I can also write I can help you to get things right with some other
> people, and I can financially support people by giving away
> hardware and even specs for free in some cases. Who is able
> to do that from the old crufted v4l/dvb guys?
> 
> Manu throws his drivers over the wall to the OSS community, although
> I don't mind.
> Mauro is copying the logic of my code and writes I told him I'm ok with
> taking my code without just adding a single line of how his driver
> got developed. (I still wonder why he skipped some significant parts
> of the driver .. because he used the existing one as logic template)
> 
> http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c
> (not looking at the specific changeset but he copied the firmware
> loading instructions without taking care about the copyright?)

After you dismissed all arguments except your own as invalid, you've
now moved on to the "post bullshit and personal accusations" stage.
I hope this means we're now done with this "discussion".

> > Now, doesn't _that_ get you thinking?
> 
> oh yes.

Yeah, right.


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

Re: [linux-dvb] [PATCH] Userspace tuner

On Sat, Sep 15, 2007, Markus Rechberger wrote:
> 
> it gets me thinking. Some core developers who I met during
> the last few weeks (kernel summit, suse conference in czech)
> told me to go on with it actually because the final plan isn't that
> bad..

I was referring to your code you posted for merging on linux-dvb,
and which got rejected. Anyway, it's easy to agree with you if one
has just heard _your_ version -- the purpose of this thread is to
give people an alternate version of the story to complement
yours, which would allow the people you talked to to think it over
and change their mind. See if you can get of those people you
talked to to post here to support you.

> Beside that I'm just curious how much did you contribute
> during the last 2 years to the lkml/linux kernel, and how much
> do you want to contribute in future? (also from my side
> talk is cheap (even for me) but getting something done costs
> quite some time and feedback from other people)

IOW you say if I don't write code I should shut up?
Is that also what you tell users on your em28xx list
when they dare to disagree with you?

Nice...

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/15/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > 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

> > 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.

> > 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.

> 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.

> 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/tuner-xc2028.c
>
> 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.

> 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.

>
> >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.

> 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.

> 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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-15 Thread Manu Abraham

Hello Markus,

Markus Rechberger wrote:

> The main discussion in this thread was about drivers in userspace
> are bad because the API will allow binary drivers. The guy
> who works for Hauppauge (again I also have good contacts
> at Hauppauge Europe) writes it's bad - for no technical reason.

AFAICS, Steven raised the same thoughts what i had.

> If someone points out that it is bad (after reading the whole thread)
> why don't we put X.org, bash, well everything into the kernel?

I am not saying that userspace is bad. In fact i am all for userspace,
_if_ there is much of a complication. For example we have had largely
complex devices. You might like to read this thread a while back.

This was the reason why we started up libdvbapi/mti (For those who don't
know what it is, libdvbapi/mti is a userspace approach for having device
support in userspace with complicated tuning algorithms with a lot of
calculations)

http://search.gmane.org/?query=Re%3A+%5BRFC%5D+Userspace+extensions%2C+was+Re%3A+%5Blinux-dvb%5D+%5Bpatch%5D+Add+support+for+different+tuning+algorithms==linux.drivers.dvb=relevance=and=

For that demodulator and a successor for the same, i had finally moved
the same to in kernel with a lot of trouble. Maybe it is not as precise
as it should have been.

But what i mean is that we should use such approaches if there needs to
be a heavy valid reason and if there are many more devices going that
way, we should definitely move to userspace. Maybe the userspace idea is
a bit still immature.

That said, i don't see any such complexities with the XC3028

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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-15 Thread Manu Abraham

Hello Markus,

Markus Rechberger wrote:

The main discussion in this thread was about drivers in userspace
are bad because the API will allow binary drivers. The guy
who works for Hauppauge (again I also have good contacts
at Hauppauge Europe) writes it's bad - for no technical reason.

AFAICS, Steven raised the same thoughts what i had.

If someone points out that it is bad (after reading the whole thread)
why don't we put X.org, bash, well everything into the kernel?

I am not saying that userspace is bad. In fact i am all for userspace,
_if_ there is much of a complication. For example we have had largely
complex devices. You might like to read this thread a while back.

This was the reason why we started up libdvbapi/mti (For those who don't
know what it is, libdvbapi/mti is a userspace approach for having device
support in userspace with complicated tuning algorithms with a lot of
calculations)

http://search.gmane.org/?query=Re%3A+%5BRFC%5D+Userspace+extensions%2C+was+Re%3A+%5Blinux-dvb%5D+%5Bpatch%5D+Add+support+for+different+tuning+algorithmsauthor=group=linux.drivers.dvbsort=relevanceDEFAULTOP=andquery=

For that demodulator and a successor for the same, i had finally moved
the same to in kernel with a lot of trouble. Maybe it is not as precise
as it should have been.

But what i mean is that we should use such approaches if there needs to
be a heavy valid reason and if there are many more devices going that
way, we should definitely move to userspace. Maybe the userspace idea is
a bit still immature.

That said, i don't see any such complexities with the XC3028

Manu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
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

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.

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.

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.

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/tuner-xc2028.c

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.

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.

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.

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.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Sat, Sep 15, 2007, Markus Rechberger wrote:
 
 it gets me thinking. Some core developers who I met during
 the last few weeks (kernel summit, suse conference in czech)
 told me to go on with it actually because the final plan isn't that
 bad..

I was referring to your code you posted for merging on linux-dvb,
and which got rejected. Anyway, it's easy to agree with you if one
has just heard _your_ version -- the purpose of this thread is to
give people an alternate version of the story to complement
yours, which would allow the people you talked to to think it over
and change their mind. See if you can get of those people you
talked to to post here to support you.

 Beside that I'm just curious how much did you contribute
 during the last 2 years to the lkml/linux kernel, and how much
 do you want to contribute in future? (also from my side
 talk is cheap (even for me) but getting something done costs
 quite some time and feedback from other people)

IOW you say if I don't write code I should shut up?
Is that also what you tell users on your em28xx list
when they dare to disagree with you?

Nice...


Johannes
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

On Sat, Sep 15, 2007, Markus Rechberger wrote:
The main discussion in this thread was about drivers in userspace
are bad because the API will allow binary drivers. The guy
who works for Hauppauge (again I also have good contacts
at Hauppauge Europe) writes it's bad - for no technical reason.

It sends a shiver down my spine that seem to imply that you
use your Hauppauge Europe contact to lobby against the
efforts of Hauppauge USA employees to promote support for
Open Source kernel drivers within their company.

If someone points out that it is bad (after reading the whole thread)
why don't we put X.org, bash, well everything into the kernel?
GPL is the saviour seems to be the saviour for some people in this
world, but in the end it's still if people want to go that way.
Much work has been done by other people before, my work
is also just an additional contribution and I (again) don't intend to
release binary drivers. (also keep in mind that ubuntu takes
everything which makes things work - this matters to the enduser)

Hey I can also write I can help you to get things right with some other
people, and I can financially support people by giving away
hardware and even specs for free in some cases. Who is able
to do that from the old crufted v4l/dvb guys?

Manu throws his drivers over the wall to the OSS community, although
I don't mind.
Mauro is copying the logic of my code and writes I told him I'm ok with
taking my code without just adding a single line of how his driver
got developed. (I still wonder why he skipped some significant parts
of the driver .. because he used the existing one as logic template)

http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c
(not looking at the specific changeset but he copied the firmware
loading instructions without taking care about the copyright?)

After you dismissed all arguments except your own as invalid, you've
now moved on to the post bullshit and personal accusations stage.
I hope this means we're now done with this discussion.

Now, doesn't _that_ get you thinking?

oh yes.

Yeah, right.

Johannes
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/15/07, Johannes Stezenbach [EMAIL PROTECTED] wrote:
 On Sat, Sep 15, 2007, Markus Rechberger wrote:
 
  it gets me thinking. Some core developers who I met during
  the last few weeks (kernel summit, suse conference in czech)
  told me to go on with it actually because the final plan isn't that
  bad..

 I was referring to your code you posted for merging on linux-dvb,
 and which got rejected. Anyway, it's easy to agree with you if one
 has just heard _your_ version -- the purpose of this thread is to
 give people an alternate version of the story to complement
 yours, which would allow the people you talked to to think it over
 and change their mind. See if you can get of those people you
 talked to to post here to support you.


Everyone knows that there are some issues even some internal
ones which I'm not part of.
Not sure if you met some other kernel developers recently, all you
can hear is those crazy media guys (which just includes everyone
who works with media related drivers)

  Beside that I'm just curious how much did you contribute
  during the last 2 years to the lkml/linux kernel, and how much
  do you want to contribute in future? (also from my side
  talk is cheap (even for me) but getting something done costs
  quite some time and feedback from other people)

 IOW you say if I don't write code I should shut up?
 Is that also what you tell users on your em28xx list
 when they dare to disagree with you?

 Nice...


This is a free world you can write whatever you want,
but if you want me to change my code you need to
convince me that I should acknowlidge your ideas.
And by not acknowlidging my requirements don't expect
that I will go back to the start and try to reinvent the
wheel. After almost 2 years I'm quite into those things
and I know what I want for my project and what I'll try
to achieve with what I'm doing.

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

Re: [linux-dvb] [PATCH] Userspace tuner

 Everyone knows that there are some issues even some internal
 ones which I'm not part of.

With respect to your kernel-userspace API for xc3028, you made something
that seemed to be a dream: there's a consensus: not a single developer
believed that this is the better way; nobody seems that this is the
better approach.

So, or you are the only media developer with good sense in the face of
the Earth, or you're incapable of understand the obvious: you're wrong
with this approach. IMO, the answer is quite obvious.

-- 
Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
  Everyone knows that there are some issues even some internal
  ones which I'm not part of.

 With respect to your kernel-userspace API for xc3028, you made something
 that seemed to be a dream: there's a consensus: not a single developer
 believed that this is the better way; nobody seems that this is the
 better approach.


Not a single developer out of 3-5 people? Seems fine with me, because
people didn't agree with anything else before either and tried to point
me to wrong solutions.
http://threebit.net/mail-archive/video4linux/msg07548.html

 So, or you are the only media developer with good sense in the face of
 the Earth, or you're incapable of understand the obvious: you're wrong
 with this approach. IMO, the answer is quite obvious.


that for you don't have to use it.
http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages

I'm off for the weekend now so have a nice one :-)
Markus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner


Em Sáb, 2007-09-15 às 16:33 +0200, Markus Rechberger escreveu:
 I'm off for the weekend now so have a nice one :-)

Enjoy your weekend. I really hope that you have some time to reflect and
review your positions during the weekend.

-- 
Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-15 Thread Steven Toth


Johannes Stezenbach wrote:

On Sat, Sep 15, 2007, Markus Rechberger wrote:
  

The main discussion in this thread was about drivers in userspace
are bad because the API will allow binary drivers. The guy
who works for Hauppauge (again I also have good contacts
at Hauppauge Europe) writes it's bad - for no technical reason.



  


lol, oh man, how to make friends and influence people.


It sends a shiver down my spine that seem to imply that you
use your Hauppauge Europe contact to lobby against the
efforts of Hauppauge USA employees to promote support for
Open Source kernel drivers within their company.

  


Ack.



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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-15 Thread Bernard Jungen

On Sat, Sep 15, 2007 at 11:04:42AM -0300, Mauro Carvalho Chehab wrote:
 With respect to your kernel-userspace API for xc3028, you made something
 that seemed to be a dream: there's a consensus: not a single developer
 believed that this is the better way; nobody seems that this is the
 better approach.
 
 So, or you are the only media developer with good sense in the face of
 the Earth, or you're incapable of understand the obvious: you're wrong
 with this approach. IMO, the answer is quite obvious.

Yes, as a newbie observer on the v4l list, the answer is obvious to me,
at last, and the reason is not entirely technical. I can't read so many
bogus arguments on so few lines without reacting.

Rephrasing Mauro:

Not a single developer out of a few SEEMS to believe that it is the BETTER
approach, so since the FEW represent ALL media developers in the world, and
since there is only ONE RIGHT way to do things, and since the GROUP is
always RIGHT and always knows better than the individual, then YOU're WRONG
and I'm right. Conform to the group and do as the group says, whatever the
consequences!

Geeks are decidedly as prone as others to blindly accept travelling on the
slippery road of herd mentality and obvious conclusions based on
appearances. Is this OPEN source development or a dictatorship or what?

So in the end Mauro will be right. And Markus will continue to develop and
defend his stuff as HE sees fit. He knows his own work better than anyone
else. It will be HIS way or nothing with his own stuff, it's his inalienable
right.

And don't be naive, if there's no solution more viable than Markus' one,
then the latter will eventually be widely adopted somehow, sometime,
whatever the amount of grumbling from the establishment. No
dictatorship/forced consensus can decide future's direction, nor improve
its already low own viability.

Cheers,

Bernard.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

> 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.

> 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.

> 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 used to
state on your website that your intention were to release binary-only
xc5000 drivers. 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/tuner-xc2028.c

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.

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.

---

>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.

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.

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.
 
Cheers,
Mauro


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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2007, Markus Rechberger wrote:
> >
> > people do contribute to the em28xx project.
> ...
> > there's also an active and even problem solving oriented ML available:
> > http://mcentral.de/pipermail/em28xx/
> >
> > Also if you look at the mercurial code you'll see several people
> > contributing to that project.
>
> Of course, people who own such a device and want to use
> it with Linux have no choice but to work with you.
> And you do a good job for your users, you support them
> well and in return they contribute info and patches
> to support new devices.
>
> But the thing is that at mcentral.de you're the man at the top,

why is it mcentral.de at the moment? I started several discussions about
the whole topic. The thing which is in v4l-dvb on linuxtv does not satisfy
any requirements, also further additions will be hard to achieve with it.

> and your users will hardly disagree with you on core
> technical questions. (Well, admittedly I'm speculating
> here as I don't read your em28xx list.)
>

they can disagree, I even pointed out to design flaws lately when
some users posted bugreports.

> On for drivers/media/ OTOH you are just one developer among others,
> and some of them choose to disagree with you. Even worse,
> IIRC there wasn't even _a single_ other developer willing
> to ACK your offending patch.
>

the current patch isn't offending anymore, see it as a chance I'm
giving you the chance to acknowlidge what has been done now from
my side.
The main discussion in this thread was about drivers in userspace
are bad because the API will allow binary drivers. The guy
who works for Hauppauge (again I also have good contacts
at Hauppauge Europe) writes it's bad - for no technical reason.

If someone points out that it is bad (after reading the whole thread)
why don't we put X.org, bash, well everything into the kernel?
GPL is the saviour seems to be the saviour for some people in this
world, but in the end it's still if people want to go that way.
Much work has been done by other people before, my work
is also just an additional contribution and I (again) don't intend to
release binary drivers. (also keep in mind that ubuntu takes
everything which makes things work - this matters to the enduser)

Hey I can also write I can help you to get things right with some other
people, and I can financially support people by giving away
hardware and even specs for free in some cases. Who is able
to do that from the old crufted v4l/dvb guys?

Manu throws his drivers over the wall to the OSS community, although
I don't mind.
Mauro is copying the logic of my code and writes I told him I'm ok with
taking my code without just adding a single line of how his driver
got developed. (I still wonder why he skipped some significant parts
of the driver .. because he used the existing one as logic template)

http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c
(not looking at the specific changeset but he copied the firmware
loading instructions without taking care about the copyright?)

> Now, doesn't _that_ get you thinking?
>

oh yes.

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

Re: [linux-dvb] [PATCH] Userspace tuner

> Beside that I'm just curious how much did you contribute
> during the last 2 years to the lkml/linux kernel, and how much
> do you want to contribute in future? (also from my side
> talk is cheap (even for me) but getting something done costs
> quite some time and feedback from other people)

Contributing doesn't necessarily means submitting patches. There are
several good guys at the community offering very valuable contributions,
like patchset reviews, good comments, userspace experiences, etc.

Johannes does a very impressive work of maintaining, almost alone,
LinuxTV website, upgrading the system, monitoring disk spaces, taking
backups, etc. Also, he is always available to discuss the most important
changes at APIs and to defend the Open Source community, providing his
very clear point of view.

Thank you, Johannes for all your good work!

-- 
Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2007, Markus Rechberger wrote:
> >
> > people do contribute to the em28xx project.
> ...
> > there's also an active and even problem solving oriented ML available:
> > http://mcentral.de/pipermail/em28xx/
> >
> > Also if you look at the mercurial code you'll see several people
> > contributing to that project.
>
> Of course, people who own such a device and want to use
> it with Linux have no choice but to work with you.
> And you do a good job for your users, you support them
> well and in return they contribute info and patches
> to support new devices.
>
> But the thing is that at mcentral.de you're the man at the top,
> and your users will hardly disagree with you on core
> technical questions. (Well, admittedly I'm speculating
> here as I don't read your em28xx list.)
>

they can. Put technical issues infront of everything also see the
whole picture that userspace tv applications have to support
all the codecs which are available.

> On for drivers/media/ OTOH you are just one developer among others,
> and some of them choose to disagree with you. Even worse,
> IIRC there wasn't even _a single_ other developer willing
> to ACK your offending patch.
>

there was not a single developer of the old crufted developers who
didn't bring the project forward during the last 2 years.
yes you're right.

> Now, doesn't _that_ get you thinking?
>

it gets me thinking. Some core developers who I met during
the last few weeks (kernel summit, suse conference in czech)
told me to go on with it actually because the final plan isn't that
bad.. I don't expect anyone of the old crufted v4l/dvb (well many
of them already left the party) will join the game...
(I'll leave that open here) spend some time read the whole history
of this thread and it will show up what this all is targeting at.
I'll answer your questions with technical reasons why I'm doing
all that stuff that way if you'll just ask.
Someone told me during the last 2 weeks
 "but v4l2 was about to solve all those problems" it didn't. (point)
and I think I explained good enough why all that crap still goes
on as it is.

Beside that I'm just curious how much did you contribute
during the last 2 years to the lkml/linux kernel, and how much
do you want to contribute in future? (also from my side
talk is cheap (even for me) but getting something done costs
quite some time and feedback from other people)

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

Re: [linux-dvb] [PATCH] Userspace tuner

Aidan Thornton wrote:

> 
> I think this will require a rethink of either how the em2880-dvb
> driver works or how frontend drivers work. The current API expects
> users to initialise their frontend and then bind a tuner to it.
> em2880-dvb is a sort of subdriver that attaches to the main driver,
> and doesn't have any control over when or how it initialises its
> tuner, so it can't delay tuner initialisation until the frontend has
> been initialised. (I don't think it's the only hybrid driver that
> works this way either). Of course, I could be missing something.

The em28xx/xc3028 is in fact not too complex. Just for sake of
demonstration, some time back i had posted a dummy driver how it can be
done in a nice and clean way as an example.

The patch assumes some additional standards, you can ignore them. But
you get the general idea from in there.
http://marc.info/?l=linux-video=117613833119350=2


> 
>> There is no reason why the Xceive driver cannot be merged into the
>> current development tree using the hybrid tuner framework as it stands
>> today.
> 
> I'm not convinced this is entirely true. In order to avoid unnecessary
> reinitialisation of the device, the driver needs to know whether the
> device is in analog or digital mode, and I can't see a way of doing it
> with the current API. (I think existing drivers, such as the xc2028
> driver in one branch, use the older analog API and make the digital
> driver a wrapper around it.) Again, I may be missing something.

You can read this post also for some additional information.
http://marc.info/?l=linux-video=117922735929375=2

Use the ideas as you deem fit. ;-)

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

Re: [linux-dvb] [PATCH] Userspace tuner


> > There is no reason why the Xceive driver cannot be merged into the
> > current development tree using the hybrid tuner framework as it stands
> > today.
> 
> I'm not convinced this is entirely true. In order to avoid unnecessary
> reinitialisation of the device, the driver needs to know whether the
> device is in analog or digital mode, and I can't see a way of doing it
> with the current API. (I think existing drivers, such as the xc2028
> driver in one branch, use the older analog API and make the digital
> driver a wrapper around it.) Again, I may be missing something.

For sure there are some ways. One dirty way would be to add an static
lock at xc3028 driver. You can rise the lock when firmware is being
uploaded, removing it at the end. This would prevent the troubles you've
mentioned.

A cleaner way would be to create a tasklet for firmware upload. This
will also prevent the driver for a long load time, due to firmware
initialization (a similar change were recently added at ivtv driver).

For sure there are other ways of doing this.
 
Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-14 Thread Aidan Thornton

Hi,

On 9/14/07, Michael Krufky <[EMAIL PROTECTED]> wrote:
> On 9/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > > > - The hybrid tuner support, that where your requirement, when all those
> > > > discussions started, were already added to the subsystem. So now, an
> > > > hybrid tuner can be accessed by both DVB and V4L devices;
> > > >
> > >
> > > It's far more complex as the thing which is implemented there.
> > > The only thing that has been implemented is that one moduleformat
> > > can be loaded by the v4l and by the dvb framework nothing else at the
> > > moment. I told you at the kernel summit about that and I think you
> > > knew about that before.
> > >
> > > Just to quote some text:
> > > "Right now, a separate instance of the driver is used for analog /
> > > digital tuning.  In order to use a single instance, we will have to
> > > store a pointer to the dvb_frontend structure on the bridge level, but
> > > there are various other prerequisites that must be dealt with before we
> > > get to that point.
> > >
> > > We _will_ get there though, eventually."
> >
> > Maybe it is still not perfect. Feel free to improve it. Several people
> > from the community, including me, already offered you help to add your
> > driver, reworking on the 5% of the stuff that aren't compatible with the
> > V4L/DVB core API design.
>
> For clarification, Markus is quoting me, above.
>
> The idea is to eventually store a pointer to the dvb_frontend
> structure on the bridge level to be used as a single entry point
> between the analog and digital subsystems.  However, we are not yet
> ready for this, as the refactoring process has a lot more to be done
> beforehand.

I think this will require a rethink of either how the em2880-dvb
driver works or how frontend drivers work. The current API expects
users to initialise their frontend and then bind a tuner to it.
em2880-dvb is a sort of subdriver that attaches to the main driver,
and doesn't have any control over when or how it initialises its
tuner, so it can't delay tuner initialisation until the frontend has
been initialised. (I don't think it's the only hybrid driver that
works this way either). Of course, I could be missing something.

> There is no reason why the Xceive driver cannot be merged into the
> current development tree using the hybrid tuner framework as it stands
> today.

I'm not convinced this is entirely true. In order to avoid unnecessary
reinitialisation of the device, the driver needs to know whether the
device is in analog or digital mode, and I can't see a way of doing it
with the current API. (I think existing drivers, such as the xc2028
driver in one branch, use the older analog API and make the digital
driver a wrapper around it.) Again, I may be missing something.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007, Markus Rechberger wrote:
> 
> people do contribute to the em28xx project.
...
> there's also an active and even problem solving oriented ML available:
> http://mcentral.de/pipermail/em28xx/
> 
> Also if you look at the mercurial code you'll see several people
> contributing to that project.

Of course, people who own such a device and want to use
it with Linux have no choice but to work with you.
And you do a good job for your users, you support them
well and in return they contribute info and patches
to support new devices.

But the thing is that at mcentral.de you're the man at the top,
and your users will hardly disagree with you on core
technical questions. (Well, admittedly I'm speculating
here as I don't read your em28xx list.)

On for drivers/media/ OTOH you are just one developer among others,
and some of them choose to disagree with you. Even worse,
IIRC there wasn't even _a single_ other developer willing
to ACK your offending patch.

Now, doesn't _that_ get you thinking?

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> On 9/14/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
> > On 9/14/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > > On 9/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> > > > Joerg Roedel wrote:
> > > > > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
> > > > > What do you think about IOMMU?
> > > > >
> > > > >
> > > >  Just because AMD or INTEL want to invent some whizzy new technology
> > it
> > > >  doesn't say anything about the TV card development and retail
> > business.
> > > >  Intel and AMD have teams of Linux engineers helping operating
> > system
> > > >  developers bring their ideas and technologies to new platforms.
> > That's
> > > > a
> > > >  million miles away from any of the TV board vendors I know of, who
> > have
> > > >  little or NO fulltime linux developers and consider the < 5% market
> > > >  fringe at best.
> > > > 
> > > > >>> it helps to virtualize devices and introduces newer features for
> > that.
> > > > >>> Some interesting projects could be derrived out of that, there are
> > > > >>> quite a few interesting papers floating around how drivers could be
> > > > >>> handled in future.
> > > > >>>
> > > > >> IOMMU can be considered similar to the AGP GART, which is similar,
> > > > >> remapping the Addresses, as far as i understand.
> > > > >
> > > > > Common new IOMMUs have only very few in common with the AGP GART. In
> > > > > fact, with current modern IOMMU hardware it will be possible to
> > > > > implement secure userspace device drivers that are even able to do
> > DMA.
> > > > > This is not possible with the GART.
> > > > >
> > > > >> Though you get a physical to virtual translation, what about
> > interrupts,
> > > > >
> > > > > Modern IOMMUs are able to remap interrupts. This will solve the
> > problem
> > > > > with PCI interrupt sharing.
> > > >
> > > > What CPU's are we talking about ?
> > > >
> > >
> > > upcoming x86-64 processors from the AMD side. I'm not into what Intel
> > > is doing in that area at the moment.
> >
> > All AMD64 chips have an IOMMU.  Only Intel's most recent chips do.
> >
>
> It's not available yet, you can read more about it in the following article:
>
> http://developer.amd.com/articlex.jsp?id=101
>
> If you're interested in it I can put together some more information about
> it.

It (the IOMMU) is available on all AMD64 chips.  The newer
virtualization stuff is only on the newer chips.

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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-14 Thread Michael Krufky

On 9/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > > - The hybrid tuner support, that where your requirement, when all those
> > > discussions started, were already added to the subsystem. So now, an
> > > hybrid tuner can be accessed by both DVB and V4L devices;
> > >
> >
> > It's far more complex as the thing which is implemented there.
> > The only thing that has been implemented is that one moduleformat
> > can be loaded by the v4l and by the dvb framework nothing else at the
> > moment. I told you at the kernel summit about that and I think you
> > knew about that before.
> >
> > Just to quote some text:
> > "Right now, a separate instance of the driver is used for analog /
> > digital tuning.  In order to use a single instance, we will have to
> > store a pointer to the dvb_frontend structure on the bridge level, but
> > there are various other prerequisites that must be dealt with before we
> > get to that point.
> >
> > We _will_ get there though, eventually."
>
> Maybe it is still not perfect. Feel free to improve it. Several people
> from the community, including me, already offered you help to add your
> driver, reworking on the 5% of the stuff that aren't compatible with the
> V4L/DVB core API design.

For clarification, Markus is quoting me, above.

The idea is to eventually store a pointer to the dvb_frontend
structure on the bridge level to be used as a single entry point
between the analog and digital subsystems.  However, we are not yet
ready for this, as the refactoring process has a lot more to be done
beforehand.

Phase 1 of the refactoring was to implement the core changes required
for a single module to be used by both v4l and dvb, and to convert the
existing tuner modules to the new internal API.

Phase 2, a work in progress, involves the removal of duplicated code.
For example, the current code in the master branch still has tda8275 /
tda8275a analog code inside of tda8290.c, where the digital tuning
code is in tda827x.c ...  This was resolved in this changeset:

Move all tda8275/8275a tuning code from tda8290 module into tda827x module
http://linuxtv.org/hg/~mkrufky/philipsNXP/rev/09c2e16a8cdd

This code is working fine, and I have it pushed to linuxtv.org for the
sake of testing.  I have not requested merge to master because I still
have some cleanups to do, and I do not want this to go to 2.6.24.

(side note: basic support for TDA8295 + TDA18271 has been added to my
philipsNXP tree, as well)

Tuner-simple and dvb-pll will have to undergo a similar treatment, and
it's not going to happen overnight.  But I *am* working on it.

I've outlined a basic roadmap to the refactoring plans in my original RFC:
http://linuxtv.org/pipermail/linux-dvb/2007-August/019950.html

What I didn't mention in that RFC, however, is the method in which I
plan to remove the multiple instantiations of the tuner code for a
single piece of hardware, by moving the dvb_frontend pointer to the
bridge level.  Since this change depends on the other refactoring to
be completed first, I found it unnecessary to explain this in detail
at this point.

When the time comes, a new RFC will be sent out to deal with that matter.

There is no reason why the Xceive driver cannot be merged into the
current development tree using the hybrid tuner framework as it stands
today.

Regards,

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
> On 9/14/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > On 9/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> > > Joerg Roedel wrote:
> > > > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
> > > > What do you think about IOMMU?
> > > >
> > > >
> > >  Just because AMD or INTEL want to invent some whizzy new technology
> it
> > >  doesn't say anything about the TV card development and retail
> business.
> > >  Intel and AMD have teams of Linux engineers helping operating
> system
> > >  developers bring their ideas and technologies to new platforms.
> That's
> > > a
> > >  million miles away from any of the TV board vendors I know of, who
> have
> > >  little or NO fulltime linux developers and consider the < 5% market
> > >  fringe at best.
> > > 
> > > >>> it helps to virtualize devices and introduces newer features for
> that.
> > > >>> Some interesting projects could be derrived out of that, there are
> > > >>> quite a few interesting papers floating around how drivers could be
> > > >>> handled in future.
> > > >>>
> > > >> IOMMU can be considered similar to the AGP GART, which is similar,
> > > >> remapping the Addresses, as far as i understand.
> > > >
> > > > Common new IOMMUs have only very few in common with the AGP GART. In
> > > > fact, with current modern IOMMU hardware it will be possible to
> > > > implement secure userspace device drivers that are even able to do
> DMA.
> > > > This is not possible with the GART.
> > > >
> > > >> Though you get a physical to virtual translation, what about
> interrupts,
> > > >
> > > > Modern IOMMUs are able to remap interrupts. This will solve the
> problem
> > > > with PCI interrupt sharing.
> > >
> > > What CPU's are we talking about ?
> > >
> >
> > upcoming x86-64 processors from the AMD side. I'm not into what Intel
> > is doing in that area at the moment.
>
> All AMD64 chips have an IOMMU.  Only Intel's most recent chips do.
>

It's not available yet, you can read more about it in the following article:

http://developer.amd.com/articlex.jsp?id=101

If you're interested in it I can put together some more information about
it.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> On 9/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> > Joerg Roedel wrote:
> > > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
> > > What do you think about IOMMU?
> > >
> > >
> >  Just because AMD or INTEL want to invent some whizzy new technology it
> >  doesn't say anything about the TV card development and retail business.
> >  Intel and AMD have teams of Linux engineers helping operating system
> >  developers bring their ideas and technologies to new platforms. That's
> > a
> >  million miles away from any of the TV board vendors I know of, who have
> >  little or NO fulltime linux developers and consider the < 5% market
> >  fringe at best.
> > 
> > >>> it helps to virtualize devices and introduces newer features for that.
> > >>> Some interesting projects could be derrived out of that, there are
> > >>> quite a few interesting papers floating around how drivers could be
> > >>> handled in future.
> > >>>
> > >> IOMMU can be considered similar to the AGP GART, which is similar,
> > >> remapping the Addresses, as far as i understand.
> > >
> > > Common new IOMMUs have only very few in common with the AGP GART. In
> > > fact, with current modern IOMMU hardware it will be possible to
> > > implement secure userspace device drivers that are even able to do DMA.
> > > This is not possible with the GART.
> > >
> > >> Though you get a physical to virtual translation, what about interrupts,
> > >
> > > Modern IOMMUs are able to remap interrupts. This will solve the problem
> > > with PCI interrupt sharing.
> >
> > What CPU's are we talking about ?
> >
>
> upcoming x86-64 processors from the AMD side. I'm not into what Intel
> is doing in that area at the moment.

All AMD64 chips have an IOMMU.  Only Intel's most recent chips do.

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

Re: [linux-dvb] [PATCH] Userspace tuner

> > - The hybrid tuner support, that where your requirement, when all those
> > discussions started, were already added to the subsystem. So now, an
> > hybrid tuner can be accessed by both DVB and V4L devices;
> >
> 
> It's far more complex as the thing which is implemented there.
> The only thing that has been implemented is that one moduleformat
> can be loaded by the v4l and by the dvb framework nothing else at the
> moment. I told you at the kernel summit about that and I think you
> knew about that before.
> 
> Just to quote some text:
> "Right now, a separate instance of the driver is used for analog /
> digital tuning.  In order to use a single instance, we will have to
> store a pointer to the dvb_frontend structure on the bridge level, but
> there are various other prerequisites that must be dealt with before we
> get to that point.
> 
> We _will_ get there though, eventually."

Maybe it is still not perfect. Feel free to improve it. Several people
from the community, including me, already offered you help to add your
driver, reworking on the 5% of the stuff that aren't compatible with the
V4L/DVB core API design.

> > - Audio standard selection is already possible via S_STD (it is already
> > working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more
> > standards should be needed, but hey, we still have 34 bits available at
> > std mask.
> >
> 
> Let me quote some text where you've been in CC and which didn't get
> far enough to get a solution implemented.
> 
> (Michael Schimek)
> 
> "> xc3028_BG_PAL_A2_A.i2c FW_78 > B/G PAL A2
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "A"
> > xc3028_BG_PAL_A2_A_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON
> > xc3028_BG_PAL_A2_B.i2c FW_78 B/G PAL A2
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "B"
> > xc3028_BG_PAL_A2_B_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON
> 
> > xc3028_BG_PAL_NICAM_A.i2c FW_78 B/G PAL NICAM
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "A"
> > xc3028_BG_PAL_NICAM_A_MTS.i2c FW_78_MTS B/G PAL FM
> > xc3028_BG_PAL_NICAM_B.i2c FW_78 B/G PAL NICAM
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "B"
> > xc3028_BG_PAL_NICAM_B_MTS.i2c FW_78_MTS B/G PAL FM
> 
> We cannot add new standards for each of these files because only six
> bits are unassigned in the lower half of v4l2_std_id. It seems
> unecessary too, please correct me if I'm wrong.
We can use the full 64 bits of v4l2_std_id. We just need to take some
care. 

Due to the lack of __ucmpdi2 on ppc32 architecture, with some gcc
versions, a hack were added at v4l2-common.c, that truncates it to 32
bits, at the function v4l2_norm_to_name():

http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commit;h=412297d31d439ba56cd4faeb3a49a6f569f40702

So, using more than 32 bits is possible, providing that we change the
implementation of v4l2_norm_to_name() or find a way for it to work with
ppc32.

Instead of just adding a standard for each possible combination, we may
just add bits for the supported audio formats. For example, we can use
the bitmask as:

#define V4L2_STD_AUDIO_NICAM_A  ((v4l2_std_id)0x0400)
#define V4L2_STD_AUDIO_A2_A ((v4l2_std_id)0x0800)

Since for all other chipsets but xc3028, all audio standards are
supported, maybe we can, instead, use a negate bitmap logic for the
non-supported audio standards. Something like:

#define V4L2_STD_AUDIO_NOT_NICAM_A  ((v4l2_std_id)0x0400)
#define V4L2_STD_AUDIO_NOT_A2_A ((v4l2_std_id)0x0800)

And define some macros for the specific standards you need. For example:

#define V4L2_STD_AUDIO_NOT_ALL  V4L2_STD_AUDIO_NOT_A2_A | 
V4L2_STD_AUDIO_NOT_NICAM_A

#define V4L2_STD_PAL_BG_A2  V4L2_STD_PAL_BG | (V4L2_STD_AUDIO_NOT_ALL & 
!V4L2_STD_AUDIO_NOT_A2_A)

This way, V4L2_STD_PAL_BG will mean that this PAL/BG accepts all
possible audio standards (being binary compatible), while
V4L2_STD_PAL_BG_A2_A will mean that only A2 response 'A' audio format is
supported for PAL/BG.

-- 
Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> Markus,
>
> > >
> > > Maybe you still don't realize how tiresome it is to talk to you.
> > > What you present as "linuxtv people block my contributions" is
> > > IMHO "linuxtv people got fed up talking to you". Because when
> > > people disagree with you, you keep rambling on and on instead
> > > of just accepting it. See, working with an Open source community
> > > requires that you don't piss everyone off, but instead find
> > > ways to _motivate_ them to help you fix the problems which
> > > prevent your code from being merged. When people are doing
> > > software development _for fun_, then it should be a _pleasure_
> > > for them to work with you, and not a pain in the ass.
> > >
> >
> > Johannes,
> >
> > people do contribute to the em28xx project.
> > If noone keeps finding solutions for requirements I will of course
> > go on to find my own way.
> > Although upcoming and even the current requirements are not met
> > by the existing API.
> > It's worth nothing to merge what's available now since I'm not even
> > ok with how several issues are solved with the driver itself at the
> > moment.
> > I'm going forward step by step with it now.
> >
> > there's also an active and even problem solving oriented ML available:
> > http://mcentral.de/pipermail/em28xx/
> >
> > Also if you look at the mercurial code you'll see several people
> > contributing to that project.
>
> Solutions for your requirements can be reachable via a kernelspace
> solution:
>
> - The hybrid tuner support, that where your requirement, when all those
> discussions started, were already added to the subsystem. So now, an
> hybrid tuner can be accessed by both DVB and V4L devices;
>

It's far more complex as the thing which is implemented there.
The only thing that has been implemented is that one moduleformat
can be loaded by the v4l and by the dvb framework nothing else at the
moment. I told you at the kernel summit about that and I think you
knew about that before.

Just to quote some text:
"Right now, a separate instance of the driver is used for analog /
digital tuning.  In order to use a single instance, we will have to
store a pointer to the dvb_frontend structure on the bridge level, but
there are various other prerequisites that must be dealt with before we
get to that point.

We _will_ get there though, eventually."

> - Audio standard selection is already possible via S_STD (it is already
> working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more
> standards should be needed, but hey, we still have 34 bits available at
> std mask.
>

Let me quote some text where you've been in CC and which didn't get
far enough to get a solution implemented.

(Michael Schimek)

"> xc3028_BG_PAL_A2_A.i2c FW_78 > B/G PAL A2
>   Group delay: See RecITU-R BT.470-6 p.21 Response "A"
> xc3028_BG_PAL_A2_A_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON
> xc3028_BG_PAL_A2_B.i2c FW_78 B/G PAL A2
>   Group delay: See RecITU-R BT.470-6 p.21 Response "B"
> xc3028_BG_PAL_A2_B_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON

> xc3028_BG_PAL_NICAM_A.i2c FW_78 B/G PAL NICAM
>   Group delay: See RecITU-R BT.470-6 p.21 Response "A"
> xc3028_BG_PAL_NICAM_A_MTS.i2c FW_78_MTS B/G PAL FM
> xc3028_BG_PAL_NICAM_B.i2c FW_78 B/G PAL NICAM
>   Group delay: See RecITU-R BT.470-6 p.21 Response "B"
> xc3028_BG_PAL_NICAM_B_MTS.i2c FW_78_MTS B/G PAL FM

We cannot add new standards for each of these files because only six
bits are unassigned in the lower half of v4l2_std_id. It seems
unecessary too, please correct me if I'm wrong.

(Well the driver could define its own video standards for each of the
firmwares and put them into the upper 32 bits of v4l2_std_id, which were
set aside for this purpose. But adding standards to the API also has its
advantages. Maybe it's time to reserve bits 40-55 for future expansion.)

I suppose you choose firmwares with IF or baseband sound output
depending on the design of the card?"



> The point is: there's no technical need for userspace. This will just
> add userless complexity.
>
> However, you insist with your selfish idea that every other solution,
> except the one you're proposing are bogus. This is not the way Open
> Source development works. You should listen to people.
>

I pointed out a few requirements which didn't get commented at all, and
I explained why things where done in a particular way.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007 at 08:56:40PM +0400, Manu Abraham wrote:
> 
> I do understand that (an earlier reply from Grant Grundler on the same
> [1], while working on something else), but that wasn't exactly what i
> was getting at. The bridges are in fact tied up with a certain CPU class.
> 
> Though your argument holds true: "secure userpsace device drivers can be
> implemented with modern hardware" There is a large flaw in it. (From an
> academic POV, you are correct)
> 
> Now, if all the drivers were to depend on that certain feature, what
> happens to all other CPU class users ? Looking at a pile of CPU's being
> used, also not to forget that devices such as STB's use even very small
> embedded CPU's such as the PPC405 Vulcan based [2] to mobile devices
> such as mobile phones using ARM, Xtensa [3], OMAP CPU's/platforms, which
> do not in any way use the bridges nor the CPU class which you however
> mention.

This is true. These platforms do not (and afaik will not) have an
IOMMU and thus its impossible to implement a secure userspace driver
interface that supports DMA. In general, IOMMUs are only expected on
platforms which implement virtualization, have a processor address space
larger than the io address space or both.

> So .. we are looking at a small segment, ie. a subset of the PC users
> even, even if the larger segments like STB's can be ignored. This would
> mean that only a small subset of users using a certain CPU class can use
> those drivers (eventhough the devices themselves don't have that
> limitation, the limitation being the implementation of the driver
> alone), which is absurd.

This is also true. But looking at the current development of
virtualization in hardware on the PC market (and also the increasing
amount of main memory) makes me sure that in a few years every new sold
_PC_ will haven an IOMMU inside. But the problems with the other
platforms or older hardware will certainly remain.

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

Re: [linux-dvb] [PATCH] Userspace tuner

Markus,

> >
> > Maybe you still don't realize how tiresome it is to talk to you.
> > What you present as "linuxtv people block my contributions" is
> > IMHO "linuxtv people got fed up talking to you". Because when
> > people disagree with you, you keep rambling on and on instead
> > of just accepting it. See, working with an Open source community
> > requires that you don't piss everyone off, but instead find
> > ways to _motivate_ them to help you fix the problems which
> > prevent your code from being merged. When people are doing
> > software development _for fun_, then it should be a _pleasure_
> > for them to work with you, and not a pain in the ass.
> >
> 
> Johannes,
> 
> people do contribute to the em28xx project.
> If noone keeps finding solutions for requirements I will of course
> go on to find my own way.
> Although upcoming and even the current requirements are not met
> by the existing API.
> It's worth nothing to merge what's available now since I'm not even
> ok with how several issues are solved with the driver itself at the
> moment.
> I'm going forward step by step with it now.
> 
> there's also an active and even problem solving oriented ML available:
> http://mcentral.de/pipermail/em28xx/
> 
> Also if you look at the mercurial code you'll see several people
> contributing to that project.

Solutions for your requirements can be reachable via a kernelspace
solution:

- The hybrid tuner support, that where your requirement, when all those
discussions started, were already added to the subsystem. So now, an
hybrid tuner can be accessed by both DVB and V4L devices;

- Audio standard selection is already possible via S_STD (it is already
working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more
standards should be needed, but hey, we still have 34 bits available at
std mask.

The point is: there's no technical need for userspace. This will just
add userless complexity.

However, you insist with your selfish idea that every other solution,
except the one you're proposing are bogus. This is not the way Open
Source development works. You should listen to people.


Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

Joerg Roedel wrote:

>>> Common new IOMMUs have only very few in common with the AGP GART. In
>>> fact, with current modern IOMMU hardware it will be possible to
>>> implement secure userspace device drivers that are even able to do DMA.
>>> This is not possible with the GART.
>>>
 Though you get a physical to virtual translation, what about interrupts,
>>> Modern IOMMUs are able to remap interrupts. This will solve the problem
>>> with PCI interrupt sharing.
>> What CPU's are we talking about ?
> 
> IOMMUs are not necessarily a CPU feature. These IOMMUS will be found in
> the South/North Bridge or even on PCI devices itself (uncommon). The
> Calgary IOMMU is such an example of an IOMMU not implemented on the CPU
> itself.
> 

I do understand that (an earlier reply from Grant Grundler on the same
[1], while working on something else), but that wasn't exactly what i
was getting at. The bridges are in fact tied up with a certain CPU class.

Though your argument holds true: "secure userpsace device drivers can be
implemented with modern hardware" There is a large flaw in it. (From an
academic POV, you are correct)

Now, if all the drivers were to depend on that certain feature, what
happens to all other CPU class users ? Looking at a pile of CPU's being
used, also not to forget that devices such as STB's use even very small
embedded CPU's such as the PPC405 Vulcan based [2] to mobile devices
such as mobile phones using ARM, Xtensa [3], OMAP CPU's/platforms, which
do not in any way use the bridges nor the CPU class which you however
mention.

So .. we are looking at a small segment, ie. a subset of the PC users
even, even if the larger segments like STB's can be ignored. This would
mean that only a small subset of users using a certain CPU class can use
those drivers (eventhough the devices themselves don't have that
limitation, the limitation being the implementation of the driver
alone), which is absurd.

Manu

[1] http://lkml.org/lkml/2007/5/26/217
[2] http://abraham.manu.googlepages.com/p3160033.jpg
[3] http://tensilica.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2007, Markus Rechberger wrote:
> > On 9/14/07, Steven Toth <[EMAIL PROTECTED]> wrote:
> > >
> > > If you care about LinuxTV you'll work with the core subsystem developers
> > > to bring your em28xx tree inline. If you don't care then why are you
> here?
> >
> > It doesn't really work out to work with those 3-5 "core" people who are
> active
> > there.
> > It starts at the point where RFCs are submitted and not answered,
> > discussions are avoided and finally some people start to complain.
> > In case of pointing people to wrong or bad solutions, one "Maintainer"
> > pointed out it would be like manipulating others work ... this exactly
> > happened with the em28xx project. It's not only about the current
> > implementation, as from my side I also take upcoming products into
> > account and how long it would take to get something which isn't
> > supported by the API fixed.. it's just something that is too hard and
> > I don't want to debate about things where I know that the outcome
> > is that I have to wait till someone of those 3-5 "core" people come up
> > with an own idea.
>
> Maybe you still don't realize how tiresome it is to talk to you.
> What you present as "linuxtv people block my contributions" is
> IMHO "linuxtv people got fed up talking to you". Because when
> people disagree with you, you keep rambling on and on instead
> of just accepting it. See, working with an Open source community
> requires that you don't piss everyone off, but instead find
> ways to _motivate_ them to help you fix the problems which
> prevent your code from being merged. When people are doing
> software development _for fun_, then it should be a _pleasure_
> for them to work with you, and not a pain in the ass.
>

Johannes,

people do contribute to the em28xx project.
If noone keeps finding solutions for requirements I will of course
go on to find my own way.
Although upcoming and even the current requirements are not met
by the existing API.
It's worth nothing to merge what's available now since I'm not even
ok with how several issues are solved with the driver itself at the
moment.
I'm going forward step by step with it now.

there's also an active and even problem solving oriented ML available:
http://mcentral.de/pipermail/em28xx/

Also if you look at the mercurial code you'll see several people
contributing to that project.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote:
> > what stops vendors of using the current existing code to achieve that
> > goal. They could provide binary drivers with the existing API.
>
> If you feel lucky about the GPL
>
> > What stops companies to intercept the ioctl calls and overriding some
> > I2C commands?
>
> The GPL - derivative work is the boundary not code linkage. Possibly a
> userspace
> tuner hack would probably fit this too. Especially if a specific vendor is
> producing both bits together and trying to claim they are independant.
>
> > How about proprietary video formats, would you also place the decoding
> > algorithms in kernel  just to force companies to release their code
> > for it?
>
> No, I would assume they'd provide a proprietary conversion library that
> no nobody would use (just like their hw). We keep format conversion firmly
> seperated from hardware I/O processing.
>

In general there are known formats available, the drawback is that every TV
application deals with it in a non-unified way at the moment, meaning alot
code duplication in userspace since there's no library available at the moment
which does the videoconversion from one to another format. Such a library is
beeing developed at the moment which gets plugged infront of accessing
the devicenodes.

Although in the long run I'm looking forward to reuse the userspace tuners with
such a library infront of everything by using i2c-dev.
This would also make it easy to reuse the sample code of several companies,
without having to cut out several features of the drivers and to rewrite them
to an inkernel format.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007 at 04:00:30PM +0400, Manu Abraham wrote:
> Joerg Roedel wrote:
> > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
> > What do you think about IOMMU?
> >
> >
>  Just because AMD or INTEL want to invent some whizzy new technology it
>  doesn't say anything about the TV card development and retail business.
>  Intel and AMD have teams of Linux engineers helping operating system
>  developers bring their ideas and technologies to new platforms. That's a
>  million miles away from any of the TV board vendors I know of, who have
>  little or NO fulltime linux developers and consider the < 5% market
>  fringe at best.
> 
> >>> it helps to virtualize devices and introduces newer features for that.
> >>> Some interesting projects could be derrived out of that, there are
> >>> quite a few interesting papers floating around how drivers could be
> >>> handled in future.
> >>>
> >> IOMMU can be considered similar to the AGP GART, which is similar,
> >> remapping the Addresses, as far as i understand.
> > 
> > Common new IOMMUs have only very few in common with the AGP GART. In
> > fact, with current modern IOMMU hardware it will be possible to
> > implement secure userspace device drivers that are even able to do DMA.
> > This is not possible with the GART.
> > 
> >> Though you get a physical to virtual translation, what about interrupts,
> > 
> > Modern IOMMUs are able to remap interrupts. This will solve the problem
> > with PCI interrupt sharing.
> 
> What CPU's are we talking about ?

IOMMUs are not necessarily a CPU feature. These IOMMUS will be found in
the South/North Bridge or even on PCI devices itself (uncommon). The
Calgary IOMMU is such an example of an IOMMU not implemented on the CPU
itself.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Joerg Roedel wrote:
> > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
> > What do you think about IOMMU?
> >
> >
>  Just because AMD or INTEL want to invent some whizzy new technology it
>  doesn't say anything about the TV card development and retail business.
>  Intel and AMD have teams of Linux engineers helping operating system
>  developers bring their ideas and technologies to new platforms. That's
> a
>  million miles away from any of the TV board vendors I know of, who have
>  little or NO fulltime linux developers and consider the < 5% market
>  fringe at best.
> 
> >>> it helps to virtualize devices and introduces newer features for that.
> >>> Some interesting projects could be derrived out of that, there are
> >>> quite a few interesting papers floating around how drivers could be
> >>> handled in future.
> >>>
> >> IOMMU can be considered similar to the AGP GART, which is similar,
> >> remapping the Addresses, as far as i understand.
> >
> > Common new IOMMUs have only very few in common with the AGP GART. In
> > fact, with current modern IOMMU hardware it will be possible to
> > implement secure userspace device drivers that are even able to do DMA.
> > This is not possible with the GART.
> >
> >> Though you get a physical to virtual translation, what about interrupts,
> >
> > Modern IOMMUs are able to remap interrupts. This will solve the problem
> > with PCI interrupt sharing.
>
> What CPU's are we talking about ?
>

upcoming x86-64 processors from the AMD side. I'm not into what Intel
is doing in that area at the moment.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote:
> what stops vendors of using the current existing code to achieve that
> goal. They could provide binary drivers with the existing API.

If you feel lucky about the GPL

> What stops companies to intercept the ioctl calls and overriding some
> I2C commands?

The GPL - derivative work is the boundary not code linkage. Possibly a userspace
tuner hack would probably fit this too. Especially if a specific vendor is
producing both bits together and trying to claim they are independant.

> How about proprietary video formats, would you also place the decoding
> algorithms in kernel  just to force companies to release their code
> for it?

No, I would assume they'd provide a proprietary conversion library that
no nobody would use (just like their hw). We keep format conversion firmly
seperated from hardware I/O processing. 

Alan

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

Re: [linux-dvb] [PATCH] Userspace tuner

> > * Why did someone duallicense videodev2 with BSD/GPL?

Originally the BSD people wanted to share the interface for user space
compatibility.

The kernel however is GPL so the BSD licence on some bits of the code
isn't really relevant as the combination of bits you depend upon is GPL,
will remain GPL and the only way to do a binary module would be to show
it is not in any way a derivative work in law.

> I know for certain that adding a userland API tuner/demod interface to 
> the kernel, allowing non-caring opportunistic silicon or board vendors 
> to developer closed source proprietary drivers, will have a negative 
> effect on the community and we'd set back linuxtv 3-5 years.

Agreed entirely

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

Re: [linux-dvb] [PATCH] Userspace tuner

Joerg Roedel wrote:
> On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
> What do you think about IOMMU?
>
>
 Just because AMD or INTEL want to invent some whizzy new technology it
 doesn't say anything about the TV card development and retail business.
 Intel and AMD have teams of Linux engineers helping operating system
 developers bring their ideas and technologies to new platforms. That's a
 million miles away from any of the TV board vendors I know of, who have
 little or NO fulltime linux developers and consider the < 5% market
 fringe at best.

>>> it helps to virtualize devices and introduces newer features for that.
>>> Some interesting projects could be derrived out of that, there are
>>> quite a few interesting papers floating around how drivers could be
>>> handled in future.
>>>
>> IOMMU can be considered similar to the AGP GART, which is similar,
>> remapping the Addresses, as far as i understand.
> 
> Common new IOMMUs have only very few in common with the AGP GART. In
> fact, with current modern IOMMU hardware it will be possible to
> implement secure userspace device drivers that are even able to do DMA.
> This is not possible with the GART.
> 
>> Though you get a physical to virtual translation, what about interrupts,
> 
> Modern IOMMUs are able to remap interrupts. This will solve the problem
> with PCI interrupt sharing.

What CPU's are we talking about ?

Thanks for the explanation.

Manu

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007, Markus Rechberger wrote:
> On 9/14/07, Steven Toth <[EMAIL PROTECTED]> wrote:
> >
> > If you care about LinuxTV you'll work with the core subsystem developers
> > to bring your em28xx tree inline. If you don't care then why are you here?
> 
> It doesn't really work out to work with those 3-5 "core" people who are active
> there.
> It starts at the point where RFCs are submitted and not answered,
> discussions are avoided and finally some people start to complain.
> In case of pointing people to wrong or bad solutions, one "Maintainer"
> pointed out it would be like manipulating others work ... this exactly
> happened with the em28xx project. It's not only about the current
> implementation, as from my side I also take upcoming products into
> account and how long it would take to get something which isn't
> supported by the API fixed.. it's just something that is too hard and
> I don't want to debate about things where I know that the outcome
> is that I have to wait till someone of those 3-5 "core" people come up
> with an own idea.

Maybe you still don't realize how tiresome it is to talk to you.
What you present as "linuxtv people block my contributions" is
IMHO "linuxtv people got fed up talking to you". Because when
people disagree with you, you keep rambling on and on instead
of just accepting it. See, working with an Open source community
requires that you don't piss everyone off, but instead find
ways to _motivate_ them to help you fix the problems which
prevent your code from being merged. When people are doing
software development _for fun_, then it should be a _pleasure_
for them to work with you, and not a pain in the ass.

You code and your arguments in this discussion may be
different than before, but the thread follows a familiar
pattern and will likely go nowhere, just like the many
discussions before.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
> >>> What do you think about IOMMU?
> >>>
> >>>
> >> Just because AMD or INTEL want to invent some whizzy new technology it
> >> doesn't say anything about the TV card development and retail business.
> >> Intel and AMD have teams of Linux engineers helping operating system
> >> developers bring their ideas and technologies to new platforms. That's a
> >> million miles away from any of the TV board vendors I know of, who have
> >> little or NO fulltime linux developers and consider the < 5% market
> >> fringe at best.
> >>
> > 
> > it helps to virtualize devices and introduces newer features for that.
> > Some interesting projects could be derrived out of that, there are
> > quite a few interesting papers floating around how drivers could be
> > handled in future.
> > 
> 
> IOMMU can be considered similar to the AGP GART, which is similar,
> remapping the Addresses, as far as i understand.

Common new IOMMUs have only very few in common with the AGP GART. In
fact, with current modern IOMMU hardware it will be possible to
implement secure userspace device drivers that are even able to do DMA.
This is not possible with the GART.

> Though you get a physical to virtual translation, what about interrupts,

Modern IOMMUs are able to remap interrupts. This will solve the problem
with PCI interrupt sharing.

Joerg

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

Re: [linux-dvb] [PATCH] Userspace tuner

>>> What do you think about IOMMU?
>>>
>>>
>> Just because AMD or INTEL want to invent some whizzy new technology it
>> doesn't say anything about the TV card development and retail business.
>> Intel and AMD have teams of Linux engineers helping operating system
>> developers bring their ideas and technologies to new platforms. That's a
>> million miles away from any of the TV board vendors I know of, who have
>> little or NO fulltime linux developers and consider the < 5% market
>> fringe at best.
>>
> 
> it helps to virtualize devices and introduces newer features for that.
> Some interesting projects could be derrived out of that, there are
> quite a few interesting papers floating around how drivers could be
> handled in future.
> 

IOMMU can be considered similar to the AGP GART, which is similar,
remapping the Addresses, as far as i understand.

Though you get a physical to virtual translation, what about interrupts,
yet to be seen with how to do it with multipath scenarios.

Something that i happened to read
https://www.gelato.unsw.edu.au/archives/comp-arch/2007-March/007370.html
Even Documentation/Intel-IOMMU.txt, doesn't seem to paint a very rosy
picture

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Steven Toth <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/13/07, Steven Toth <[EMAIL PROTECTED]> wrote:
> >
>  Also there is to consider a non technical aspect, whether vendors will
>  misuse this interface for binary only, undermining the efforts put in
>  for OSS drivers.
> 
> 
> 
> >>> What holds companies for using the current available code putting it
> >>> into an rpm or deb package and releasing such code now?
> >>>
> >>> The Avermedia example I pointed out to is a good example already.
> >>> As from my side I won't release binary drivers.
> >>> Although on the other side:
> >>> * are drivers from vendors which work through several kernel versions
> >>> that bad?
> >>> * Why did someone duallicense videodev2 with BSD/GPL?
> >>>
> >>> I would appreciate if someone else on the list could also comment
> >>> the reason that drivers should all be included in the linuxkernel just
> >>> because forcing the companies to release binary drivers because
> >>> of that. My opinion about that is if a company wants to go opensource
> >>> they will do so, if not they will either not release a driver or release
> >>> nothing.
> >>>
> >>>
> >>>
> >> I know for certain that adding a userland API tuner/demod interface to
> >> the kernel, allowing non-caring opportunistic silicon or board vendors
> >> to developer closed source proprietary drivers, will have a negative
> >> effect on the community and we'd set back linuxtv 3-5 years.
> >>
> >> I know for certain that it would happen. Trust me.
> >>
> >> I've told you this countless times and you're not hearing me.
> >>
> >> Hauppauge have some leverage with Conexant and NXP to release public
> >> datasheets. If they just have to release a demod.so (or similar)
> >> loadable, they'll defer to the board vendors and we'll see the certain
> >> board vendors 'locking other board vendors' out of their drivers. We'll
> >> see embedded firmware, not shared between drivers.
> >>
> >> Except, it won't stop at demod.so. It will extend into unfixable bugs
> >> for VendorB's board, because VendorA doesn't want to release a new
> >> demod.so, and VendorB has no linux resources. What happens next? For
> >> financial reasons - demod.so will begin to include checks to see if
> >> specific PCI or USB devices are present in the system, and will fail to
> >> work properly (if at all) when they're not being used with the preferred
> >> products.
> >>
> >>
> > Steven,
> >
> > what stops vendors of using the current existing code to achieve that
> > goal. They could provide binary drivers with the existing API.
> >
> >
>
> Because the good people in this mailing list are keeping them honest.
> Give any board or silicon company the ability to protect their IP, even
> in the smallest way and they'll do it, and for no good technical reason.
> It's a cut throat market and it's not clear that everyone understands
> just how thin sales margins really are.
>
> That means Hauppauge potentially releasing a binary driver, because it's
> much easier than seeking silicon vendor permission for a public diver.
> The net result of that would mean I'd have to leave the company and find
> another company that practices the one thing I truly care about 
> open source and open development groups.
>

well you could already release binary drivers if you would be
concerned about it, so again all that seems to be no reason for me.
What stops Hauppauge in implementing drivers another way?
For example the USB drivers completly in userspace.

> I'm keeping Hauppauge honest with their Linux involvement and I'm not
> alone. Other devs in other linux subsystems in other companies are doing
> the same thing.
>

For example the UIO thing, accessing MMIO through userspace, also
accessing usb control messages from userspace. Because of that reason
since it is already possible to provide binary drivers your reason is
again not valid.
The code which the userspace tuners are connected to is GPL so what.
Beside that Hauppauge is not the only company out there although I also
have contacts there at Hauppauge Europe.

> Binary drivers (or binary components) leads Linux back in time.
>
> I can't believe your so passionate about protecting secrets.
>

Please point me to the part where I am passionated about protecting
any of my opensource code which is currently available.
I have other arguments why to put that part into userspace.

> > What stops companies to intercept the ioctl calls and overriding some
> > I2C commands?
> >
> >
>
> Why would a company want to do that? Companies don't do that, hackers do
> that.
>

just to achieve what you're trying to argue with that companies could
use some odd constructs which could be used to publish their drivers as
binary only. I don't see the problem there if they want to do so.

> > Since you know about windows drivers (at least I think that you know
> > about it) you might know about the limitations of the v4l/dvb API
> > in

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Steven Toth [EMAIL PROTECTED] wrote:
 Markus Rechberger wrote:
  On 9/13/07, Steven Toth [EMAIL PROTECTED] wrote:
 
  Also there is to consider a non technical aspect, whether vendors will
  misuse this interface for binary only, undermining the efforts put in
  for OSS drivers.
 
 
 
  What holds companies for using the current available code putting it
  into an rpm or deb package and releasing such code now?
 
  The Avermedia example I pointed out to is a good example already.
  As from my side I won't release binary drivers.
  Although on the other side:
  * are drivers from vendors which work through several kernel versions
  that bad?
  * Why did someone duallicense videodev2 with BSD/GPL?
 
  I would appreciate if someone else on the list could also comment
  the reason that drivers should all be included in the linuxkernel just
  because forcing the companies to release binary drivers because
  of that. My opinion about that is if a company wants to go opensource
  they will do so, if not they will either not release a driver or release
  nothing.
 
 
 
  I know for certain that adding a userland API tuner/demod interface to
  the kernel, allowing non-caring opportunistic silicon or board vendors
  to developer closed source proprietary drivers, will have a negative
  effect on the community and we'd set back linuxtv 3-5 years.
 
  I know for certain that it would happen. Trust me.
 
  I've told you this countless times and you're not hearing me.
 
  Hauppauge have some leverage with Conexant and NXP to release public
  datasheets. If they just have to release a demod.so (or similar)
  loadable, they'll defer to the board vendors and we'll see the certain
  board vendors 'locking other board vendors' out of their drivers. We'll
  see embedded firmware, not shared between drivers.
 
  Except, it won't stop at demod.so. It will extend into unfixable bugs
  for VendorB's board, because VendorA doesn't want to release a new
  demod.so, and VendorB has no linux resources. What happens next? For
  financial reasons - demod.so will begin to include checks to see if
  specific PCI or USB devices are present in the system, and will fail to
  work properly (if at all) when they're not being used with the preferred
  products.
 
 
  Steven,
 
  what stops vendors of using the current existing code to achieve that
  goal. They could provide binary drivers with the existing API.
 
 

 Because the good people in this mailing list are keeping them honest.
 Give any board or silicon company the ability to protect their IP, even
 in the smallest way and they'll do it, and for no good technical reason.
 It's a cut throat market and it's not clear that everyone understands
 just how thin sales margins really are.

 That means Hauppauge potentially releasing a binary driver, because it's
 much easier than seeking silicon vendor permission for a public diver.
 The net result of that would mean I'd have to leave the company and find
 another company that practices the one thing I truly care about 
 open source and open development groups.


well you could already release binary drivers if you would be
concerned about it, so again all that seems to be no reason for me.
What stops Hauppauge in implementing drivers another way?
For example the USB drivers completly in userspace.

 I'm keeping Hauppauge honest with their Linux involvement and I'm not
 alone. Other devs in other linux subsystems in other companies are doing
 the same thing.


For example the UIO thing, accessing MMIO through userspace, also
accessing usb control messages from userspace. Because of that reason
since it is already possible to provide binary drivers your reason is
again not valid.
The code which the userspace tuners are connected to is GPL so what.
Beside that Hauppauge is not the only company out there although I also
have contacts there at Hauppauge Europe.

 Binary drivers (or binary components) leads Linux back in time.

 I can't believe your so passionate about protecting secrets.


Please point me to the part where I am passionated about protecting
any of my opensource code which is currently available.
I have other arguments why to put that part into userspace.

  What stops companies to intercept the ioctl calls and overriding some
  I2C commands?
 
 

 Why would a company want to do that? Companies don't do that, hackers do
 that.


just to achieve what you're trying to argue with that companies could
use some odd constructs which could be used to publish their drivers as
binary only. I don't see the problem there if they want to do so.

  Since you know about windows drivers (at least I think that you know
  about it) you might know about the limitations of the v4l/dvb API
  in general the reason just put as much code as possible into the
  kernel just for forcing companies to release code under GPL doesn't
  seem to be valid.
 

 It seems perfectly valid to me.

  How about proprietary video formats, would you also

Re: [linux-dvb] [PATCH] Userspace tuner

 What do you think about IOMMU?


 Just because AMD or INTEL want to invent some whizzy new technology it
 doesn't say anything about the TV card development and retail business.
 Intel and AMD have teams of Linux engineers helping operating system
 developers bring their ideas and technologies to new platforms. That's a
 million miles away from any of the TV board vendors I know of, who have
 little or NO fulltime linux developers and consider the  5% market
 fringe at best.

 
 it helps to virtualize devices and introduces newer features for that.
 Some interesting projects could be derrived out of that, there are
 quite a few interesting papers floating around how drivers could be
 handled in future.
 

IOMMU can be considered similar to the AGP GART, which is similar,
remapping the Addresses, as far as i understand.

Though you get a physical to virtual translation, what about interrupts,
yet to be seen with how to do it with multipath scenarios.

Something that i happened to read
https://www.gelato.unsw.edu.au/archives/comp-arch/2007-March/007370.html
Even Documentation/Intel-IOMMU.txt, doesn't seem to paint a very rosy
picture

Manu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
  What do you think about IOMMU?
 
 
  Just because AMD or INTEL want to invent some whizzy new technology it
  doesn't say anything about the TV card development and retail business.
  Intel and AMD have teams of Linux engineers helping operating system
  developers bring their ideas and technologies to new platforms. That's a
  million miles away from any of the TV board vendors I know of, who have
  little or NO fulltime linux developers and consider the  5% market
  fringe at best.
 
  
  it helps to virtualize devices and introduces newer features for that.
  Some interesting projects could be derrived out of that, there are
  quite a few interesting papers floating around how drivers could be
  handled in future.
  
 
 IOMMU can be considered similar to the AGP GART, which is similar,
 remapping the Addresses, as far as i understand.

Common new IOMMUs have only very few in common with the AGP GART. In
fact, with current modern IOMMU hardware it will be possible to
implement secure userspace device drivers that are even able to do DMA.
This is not possible with the GART.

 Though you get a physical to virtual translation, what about interrupts,

Modern IOMMUs are able to remap interrupts. This will solve the problem
with PCI interrupt sharing.

Joerg

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007, Markus Rechberger wrote:
 On 9/14/07, Steven Toth [EMAIL PROTECTED] wrote:
 
  If you care about LinuxTV you'll work with the core subsystem developers
  to bring your em28xx tree inline. If you don't care then why are you here?
 
 It doesn't really work out to work with those 3-5 core people who are active
 there.
 It starts at the point where RFCs are submitted and not answered,
 discussions are avoided and finally some people start to complain.
 In case of pointing people to wrong or bad solutions, one Maintainer
 pointed out it would be like manipulating others work ... this exactly
 happened with the em28xx project. It's not only about the current
 implementation, as from my side I also take upcoming products into
 account and how long it would take to get something which isn't
 supported by the API fixed.. it's just something that is too hard and
 I don't want to debate about things where I know that the outcome
 is that I have to wait till someone of those 3-5 core people come up
 with an own idea.

Maybe you still don't realize how tiresome it is to talk to you.
What you present as linuxtv people block my contributions is
IMHO linuxtv people got fed up talking to you. Because when
people disagree with you, you keep rambling on and on instead
of just accepting it. See, working with an Open source community
requires that you don't piss everyone off, but instead find
ways to _motivate_ them to help you fix the problems which
prevent your code from being merged. When people are doing
software development _for fun_, then it should be a _pleasure_
for them to work with you, and not a pain in the ass.

You code and your arguments in this discussion may be
different than before, but the thread follows a familiar
pattern and will likely go nowhere, just like the many
discussions before.


Johannes
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

Joerg Roedel wrote:
 On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
 What do you think about IOMMU?


 Just because AMD or INTEL want to invent some whizzy new technology it
 doesn't say anything about the TV card development and retail business.
 Intel and AMD have teams of Linux engineers helping operating system
 developers bring their ideas and technologies to new platforms. That's a
 million miles away from any of the TV board vendors I know of, who have
 little or NO fulltime linux developers and consider the  5% market
 fringe at best.

 it helps to virtualize devices and introduces newer features for that.
 Some interesting projects could be derrived out of that, there are
 quite a few interesting papers floating around how drivers could be
 handled in future.

 IOMMU can be considered similar to the AGP GART, which is similar,
 remapping the Addresses, as far as i understand.
 
 Common new IOMMUs have only very few in common with the AGP GART. In
 fact, with current modern IOMMU hardware it will be possible to
 implement secure userspace device drivers that are even able to do DMA.
 This is not possible with the GART.
 
 Though you get a physical to virtual translation, what about interrupts,
 
 Modern IOMMUs are able to remap interrupts. This will solve the problem
 with PCI interrupt sharing.

What CPU's are we talking about ?

Thanks for the explanation.

Manu

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

Re: [linux-dvb] [PATCH] Userspace tuner

  * Why did someone duallicense videodev2 with BSD/GPL?

Originally the BSD people wanted to share the interface for user space
compatibility.

The kernel however is GPL so the BSD licence on some bits of the code
isn't really relevant as the combination of bits you depend upon is GPL,
will remain GPL and the only way to do a binary module would be to show
it is not in any way a derivative work in law.

 I know for certain that adding a userland API tuner/demod interface to 
 the kernel, allowing non-caring opportunistic silicon or board vendors 
 to developer closed source proprietary drivers, will have a negative 
 effect on the community and we'd set back linuxtv 3-5 years.

Agreed entirely

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote:
 what stops vendors of using the current existing code to achieve that
 goal. They could provide binary drivers with the existing API.

If you feel lucky about the GPL

 What stops companies to intercept the ioctl calls and overriding some
 I2C commands?

The GPL - derivative work is the boundary not code linkage. Possibly a userspace
tuner hack would probably fit this too. Especially if a specific vendor is
producing both bits together and trying to claim they are independant.

 How about proprietary video formats, would you also place the decoding
 algorithms in kernel  just to force companies to release their code
 for it?

No, I would assume they'd provide a proprietary conversion library that
no nobody would use (just like their hw). We keep format conversion firmly
seperated from hardware I/O processing. 

Alan

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Manu Abraham [EMAIL PROTECTED] wrote:
 Joerg Roedel wrote:
  On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
  What do you think about IOMMU?
 
 
  Just because AMD or INTEL want to invent some whizzy new technology it
  doesn't say anything about the TV card development and retail business.
  Intel and AMD have teams of Linux engineers helping operating system
  developers bring their ideas and technologies to new platforms. That's
 a
  million miles away from any of the TV board vendors I know of, who have
  little or NO fulltime linux developers and consider the  5% market
  fringe at best.
 
  it helps to virtualize devices and introduces newer features for that.
  Some interesting projects could be derrived out of that, there are
  quite a few interesting papers floating around how drivers could be
  handled in future.
 
  IOMMU can be considered similar to the AGP GART, which is similar,
  remapping the Addresses, as far as i understand.
 
  Common new IOMMUs have only very few in common with the AGP GART. In
  fact, with current modern IOMMU hardware it will be possible to
  implement secure userspace device drivers that are even able to do DMA.
  This is not possible with the GART.
 
  Though you get a physical to virtual translation, what about interrupts,
 
  Modern IOMMUs are able to remap interrupts. This will solve the problem
  with PCI interrupt sharing.

 What CPU's are we talking about ?


upcoming x86-64 processors from the AMD side. I'm not into what Intel
is doing in that area at the moment.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007 at 04:00:30PM +0400, Manu Abraham wrote:
 Joerg Roedel wrote:
  On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
  What do you think about IOMMU?
 
 
  Just because AMD or INTEL want to invent some whizzy new technology it
  doesn't say anything about the TV card development and retail business.
  Intel and AMD have teams of Linux engineers helping operating system
  developers bring their ideas and technologies to new platforms. That's a
  million miles away from any of the TV board vendors I know of, who have
  little or NO fulltime linux developers and consider the  5% market
  fringe at best.
 
  it helps to virtualize devices and introduces newer features for that.
  Some interesting projects could be derrived out of that, there are
  quite a few interesting papers floating around how drivers could be
  handled in future.
 
  IOMMU can be considered similar to the AGP GART, which is similar,
  remapping the Addresses, as far as i understand.
  
  Common new IOMMUs have only very few in common with the AGP GART. In
  fact, with current modern IOMMU hardware it will be possible to
  implement secure userspace device drivers that are even able to do DMA.
  This is not possible with the GART.
  
  Though you get a physical to virtual translation, what about interrupts,
  
  Modern IOMMUs are able to remap interrupts. This will solve the problem
  with PCI interrupt sharing.
 
 What CPU's are we talking about ?

IOMMUs are not necessarily a CPU feature. These IOMMUS will be found in
the South/North Bridge or even on PCI devices itself (uncommon). The
Calgary IOMMU is such an example of an IOMMU not implemented on the CPU
itself.

Joerg
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Alan Cox [EMAIL PROTECTED] wrote:
 On Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote:
  what stops vendors of using the current existing code to achieve that
  goal. They could provide binary drivers with the existing API.

 If you feel lucky about the GPL

  What stops companies to intercept the ioctl calls and overriding some
  I2C commands?

 The GPL - derivative work is the boundary not code linkage. Possibly a
 userspace
 tuner hack would probably fit this too. Especially if a specific vendor is
 producing both bits together and trying to claim they are independant.

  How about proprietary video formats, would you also place the decoding
  algorithms in kernel  just to force companies to release their code
  for it?

 No, I would assume they'd provide a proprietary conversion library that
 no nobody would use (just like their hw). We keep format conversion firmly
 seperated from hardware I/O processing.


In general there are known formats available, the drawback is that every TV
application deals with it in a non-unified way at the moment, meaning alot
code duplication in userspace since there's no library available at the moment
which does the videoconversion from one to another format. Such a library is
beeing developed at the moment which gets plugged infront of accessing
the devicenodes.

Although in the long run I'm looking forward to reuse the userspace tuners with
such a library infront of everything by using i2c-dev.
This would also make it easy to reuse the sample code of several companies,
without having to cut out several features of the drivers and to rewrite them
to an inkernel format.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Johannes Stezenbach [EMAIL PROTECTED] wrote:
 On Fri, Sep 14, 2007, Markus Rechberger wrote:
  On 9/14/07, Steven Toth [EMAIL PROTECTED] wrote:
  
   If you care about LinuxTV you'll work with the core subsystem developers
   to bring your em28xx tree inline. If you don't care then why are you
 here?
 
  It doesn't really work out to work with those 3-5 core people who are
 active
  there.
  It starts at the point where RFCs are submitted and not answered,
  discussions are avoided and finally some people start to complain.
  In case of pointing people to wrong or bad solutions, one Maintainer
  pointed out it would be like manipulating others work ... this exactly
  happened with the em28xx project. It's not only about the current
  implementation, as from my side I also take upcoming products into
  account and how long it would take to get something which isn't
  supported by the API fixed.. it's just something that is too hard and
  I don't want to debate about things where I know that the outcome
  is that I have to wait till someone of those 3-5 core people come up
  with an own idea.

 Maybe you still don't realize how tiresome it is to talk to you.
 What you present as linuxtv people block my contributions is
 IMHO linuxtv people got fed up talking to you. Because when
 people disagree with you, you keep rambling on and on instead
 of just accepting it. See, working with an Open source community
 requires that you don't piss everyone off, but instead find
 ways to _motivate_ them to help you fix the problems which
 prevent your code from being merged. When people are doing
 software development _for fun_, then it should be a _pleasure_
 for them to work with you, and not a pain in the ass.


Johannes,

people do contribute to the em28xx project.
If noone keeps finding solutions for requirements I will of course
go on to find my own way.
Although upcoming and even the current requirements are not met
by the existing API.
It's worth nothing to merge what's available now since I'm not even
ok with how several issues are solved with the driver itself at the
moment.
I'm going forward step by step with it now.

there's also an active and even problem solving oriented ML available:
http://mcentral.de/pipermail/em28xx/

Also if you look at the mercurial code you'll see several people
contributing to that project.

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

Re: [linux-dvb] [PATCH] Userspace tuner

Joerg Roedel wrote:

 Common new IOMMUs have only very few in common with the AGP GART. In
 fact, with current modern IOMMU hardware it will be possible to
 implement secure userspace device drivers that are even able to do DMA.
 This is not possible with the GART.

 Though you get a physical to virtual translation, what about interrupts,
 Modern IOMMUs are able to remap interrupts. This will solve the problem
 with PCI interrupt sharing.
 What CPU's are we talking about ?
 
 IOMMUs are not necessarily a CPU feature. These IOMMUS will be found in
 the South/North Bridge or even on PCI devices itself (uncommon). The
 Calgary IOMMU is such an example of an IOMMU not implemented on the CPU
 itself.
 


I do understand that (an earlier reply from Grant Grundler on the same
[1], while working on something else), but that wasn't exactly what i
was getting at. The bridges are in fact tied up with a certain CPU class.

Though your argument holds true: secure userpsace device drivers can be
implemented with modern hardware There is a large flaw in it. (From an
academic POV, you are correct)

Now, if all the drivers were to depend on that certain feature, what
happens to all other CPU class users ? Looking at a pile of CPU's being
used, also not to forget that devices such as STB's use even very small
embedded CPU's such as the PPC405 Vulcan based [2] to mobile devices
such as mobile phones using ARM, Xtensa [3], OMAP CPU's/platforms, which
do not in any way use the bridges nor the CPU class which you however
mention.

So .. we are looking at a small segment, ie. a subset of the PC users
even, even if the larger segments like STB's can be ignored. This would
mean that only a small subset of users using a certain CPU class can use
those drivers (eventhough the devices themselves don't have that
limitation, the limitation being the implementation of the driver
alone), which is absurd.


Manu

[1] http://lkml.org/lkml/2007/5/26/217
[2] http://abraham.manu.googlepages.com/p3160033.jpg
[3] http://tensilica.com/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

Markus,

 
  Maybe you still don't realize how tiresome it is to talk to you.
  What you present as linuxtv people block my contributions is
  IMHO linuxtv people got fed up talking to you. Because when
  people disagree with you, you keep rambling on and on instead
  of just accepting it. See, working with an Open source community
  requires that you don't piss everyone off, but instead find
  ways to _motivate_ them to help you fix the problems which
  prevent your code from being merged. When people are doing
  software development _for fun_, then it should be a _pleasure_
  for them to work with you, and not a pain in the ass.
 
 
 Johannes,
 
 people do contribute to the em28xx project.
 If noone keeps finding solutions for requirements I will of course
 go on to find my own way.
 Although upcoming and even the current requirements are not met
 by the existing API.
 It's worth nothing to merge what's available now since I'm not even
 ok with how several issues are solved with the driver itself at the
 moment.
 I'm going forward step by step with it now.
 
 there's also an active and even problem solving oriented ML available:
 http://mcentral.de/pipermail/em28xx/
 
 Also if you look at the mercurial code you'll see several people
 contributing to that project.

Solutions for your requirements can be reachable via a kernelspace
solution:

- The hybrid tuner support, that where your requirement, when all those
discussions started, were already added to the subsystem. So now, an
hybrid tuner can be accessed by both DVB and V4L devices;

- Audio standard selection is already possible via S_STD (it is already
working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more
standards should be needed, but hey, we still have 34 bits available at
std mask.

The point is: there's no technical need for userspace. This will just
add userless complexity.

However, you insist with your selfish idea that every other solution,
except the one you're proposing are bogus. This is not the way Open
Source development works. You should listen to people.


Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007 at 08:56:40PM +0400, Manu Abraham wrote:
 
 I do understand that (an earlier reply from Grant Grundler on the same
 [1], while working on something else), but that wasn't exactly what i
 was getting at. The bridges are in fact tied up with a certain CPU class.
 
 Though your argument holds true: secure userpsace device drivers can be
 implemented with modern hardware There is a large flaw in it. (From an
 academic POV, you are correct)
 
 Now, if all the drivers were to depend on that certain feature, what
 happens to all other CPU class users ? Looking at a pile of CPU's being
 used, also not to forget that devices such as STB's use even very small
 embedded CPU's such as the PPC405 Vulcan based [2] to mobile devices
 such as mobile phones using ARM, Xtensa [3], OMAP CPU's/platforms, which
 do not in any way use the bridges nor the CPU class which you however
 mention.

This is true. These platforms do not (and afaik will not) have an
IOMMU and thus its impossible to implement a secure userspace driver
interface that supports DMA. In general, IOMMUs are only expected on
platforms which implement virtualization, have a processor address space
larger than the io address space or both.

 So .. we are looking at a small segment, ie. a subset of the PC users
 even, even if the larger segments like STB's can be ignored. This would
 mean that only a small subset of users using a certain CPU class can use
 those drivers (eventhough the devices themselves don't have that
 limitation, the limitation being the implementation of the driver
 alone), which is absurd.

This is also true. But looking at the current development of
virtualization in hardware on the PC market (and also the increasing
amount of main memory) makes me sure that in a few years every new sold
_PC_ will haven an IOMMU inside. But the problems with the other
platforms or older hardware will certainly remain.

Joerg
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
 Markus,

  
   Maybe you still don't realize how tiresome it is to talk to you.
   What you present as linuxtv people block my contributions is
   IMHO linuxtv people got fed up talking to you. Because when
   people disagree with you, you keep rambling on and on instead
   of just accepting it. See, working with an Open source community
   requires that you don't piss everyone off, but instead find
   ways to _motivate_ them to help you fix the problems which
   prevent your code from being merged. When people are doing
   software development _for fun_, then it should be a _pleasure_
   for them to work with you, and not a pain in the ass.
  
 
  Johannes,
 
  people do contribute to the em28xx project.
  If noone keeps finding solutions for requirements I will of course
  go on to find my own way.
  Although upcoming and even the current requirements are not met
  by the existing API.
  It's worth nothing to merge what's available now since I'm not even
  ok with how several issues are solved with the driver itself at the
  moment.
  I'm going forward step by step with it now.
 
  there's also an active and even problem solving oriented ML available:
  http://mcentral.de/pipermail/em28xx/
 
  Also if you look at the mercurial code you'll see several people
  contributing to that project.

 Solutions for your requirements can be reachable via a kernelspace
 solution:

 - The hybrid tuner support, that where your requirement, when all those
 discussions started, were already added to the subsystem. So now, an
 hybrid tuner can be accessed by both DVB and V4L devices;


It's far more complex as the thing which is implemented there.
The only thing that has been implemented is that one moduleformat
can be loaded by the v4l and by the dvb framework nothing else at the
moment. I told you at the kernel summit about that and I think you
knew about that before.

Just to quote some text:
Right now, a separate instance of the driver is used for analog /
digital tuning.  In order to use a single instance, we will have to
store a pointer to the dvb_frontend structure on the bridge level, but
there are various other prerequisites that must be dealt with before we
get to that point.

We _will_ get there though, eventually.

 - Audio standard selection is already possible via S_STD (it is already
 working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more
 standards should be needed, but hey, we still have 34 bits available at
 std mask.


Let me quote some text where you've been in CC and which didn't get
far enough to get a solution implemented.

(Michael Schimek)

 xc3028_BG_PAL_A2_A.i2c FW_78  B/G PAL A2
   Group delay: See RecITU-R BT.470-6 p.21 Response A
 xc3028_BG_PAL_A2_A_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON
 xc3028_BG_PAL_A2_B.i2c FW_78 B/G PAL A2
   Group delay: See RecITU-R BT.470-6 p.21 Response B
 xc3028_BG_PAL_A2_B_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON

 xc3028_BG_PAL_NICAM_A.i2c FW_78 B/G PAL NICAM
   Group delay: See RecITU-R BT.470-6 p.21 Response A
 xc3028_BG_PAL_NICAM_A_MTS.i2c FW_78_MTS B/G PAL FM
 xc3028_BG_PAL_NICAM_B.i2c FW_78 B/G PAL NICAM
   Group delay: See RecITU-R BT.470-6 p.21 Response B
 xc3028_BG_PAL_NICAM_B_MTS.i2c FW_78_MTS B/G PAL FM

We cannot add new standards for each of these files because only six
bits are unassigned in the lower half of v4l2_std_id. It seems
unecessary too, please correct me if I'm wrong.

(Well the driver could define its own video standards for each of the
firmwares and put them into the upper 32 bits of v4l2_std_id, which were
set aside for this purpose. But adding standards to the API also has its
advantages. Maybe it's time to reserve bits 40-55 for future expansion.)

I suppose you choose firmwares with IF or baseband sound output
depending on the design of the card?



 The point is: there's no technical need for userspace. This will just
 add userless complexity.

 However, you insist with your selfish idea that every other solution,
 except the one you're proposing are bogus. This is not the way Open
 Source development works. You should listen to people.


I pointed out a few requirements which didn't get commented at all, and
I explained why things where done in a particular way.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Markus Rechberger [EMAIL PROTECTED] wrote:
 On 9/14/07, Manu Abraham [EMAIL PROTECTED] wrote:
  Joerg Roedel wrote:
   On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
   What do you think about IOMMU?
  
  
   Just because AMD or INTEL want to invent some whizzy new technology it
   doesn't say anything about the TV card development and retail business.
   Intel and AMD have teams of Linux engineers helping operating system
   developers bring their ideas and technologies to new platforms. That's
  a
   million miles away from any of the TV board vendors I know of, who have
   little or NO fulltime linux developers and consider the  5% market
   fringe at best.
  
   it helps to virtualize devices and introduces newer features for that.
   Some interesting projects could be derrived out of that, there are
   quite a few interesting papers floating around how drivers could be
   handled in future.
  
   IOMMU can be considered similar to the AGP GART, which is similar,
   remapping the Addresses, as far as i understand.
  
   Common new IOMMUs have only very few in common with the AGP GART. In
   fact, with current modern IOMMU hardware it will be possible to
   implement secure userspace device drivers that are even able to do DMA.
   This is not possible with the GART.
  
   Though you get a physical to virtual translation, what about interrupts,
  
   Modern IOMMUs are able to remap interrupts. This will solve the problem
   with PCI interrupt sharing.
 
  What CPU's are we talking about ?
 

 upcoming x86-64 processors from the AMD side. I'm not into what Intel
 is doing in that area at the moment.

All AMD64 chips have an IOMMU.  Only Intel's most recent chips do.

Alex
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

- The hybrid tuner support, that where your requirement, when all those
discussions started, were already added to the subsystem. So now, an
hybrid tuner can be accessed by both DVB and V4L devices;

It's far more complex as the thing which is implemented there.
The only thing that has been implemented is that one moduleformat
can be loaded by the v4l and by the dvb framework nothing else at the
moment. I told you at the kernel summit about that and I think you
knew about that before.

Just to quote some text:
Right now, a separate instance of the driver is used for analog /
digital tuning. In order to use a single instance, we will have to
store a pointer to the dvb_frontend structure on the bridge level, but
there are various other prerequisites that must be dealt with before we
get to that point.

We _will_ get there though, eventually.

Maybe it is still not perfect. Feel free to improve it. Several people
from the community, including me, already offered you help to add your
driver, reworking on the 5% of the stuff that aren't compatible with the
V4L/DVB core API design.

- Audio standard selection is already possible via S_STD (it is already
working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more
standards should be needed, but hey, we still have 34 bits available at
std mask.

Let me quote some text where you've been in CC and which didn't get
far enough to get a solution implemented.

(Michael Schimek)

xc3028_BG_PAL_A2_A.i2c FW_78 B/G PAL A2
Group delay: See RecITU-R BT.470-6 p.21 Response A
xc3028_BG_PAL_A2_A_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON
xc3028_BG_PAL_A2_B.i2c FW_78 B/G PAL A2
Group delay: See RecITU-R BT.470-6 p.21 Response B
xc3028_BG_PAL_A2_B_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON

xc3028_BG_PAL_NICAM_A.i2c FW_78 B/G PAL NICAM
Group delay: See RecITU-R BT.470-6 p.21 Response A
xc3028_BG_PAL_NICAM_A_MTS.i2c FW_78_MTS B/G PAL FM
xc3028_BG_PAL_NICAM_B.i2c FW_78 B/G PAL NICAM
Group delay: See RecITU-R BT.470-6 p.21 Response B
xc3028_BG_PAL_NICAM_B_MTS.i2c FW_78_MTS B/G PAL FM

We cannot add new standards for each of these files because only six
bits are unassigned in the lower half of v4l2_std_id. It seems
unecessary too, please correct me if I'm wrong.
We can use the full 64 bits of v4l2_std_id. We just need to take some
care.

Due to the lack of __ucmpdi2 on ppc32 architecture, with some gcc
versions, a hack were added at v4l2-common.c, that truncates it to 32
bits, at the function v4l2_norm_to_name():

http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commit;h=412297d31d439ba56cd4faeb3a49a6f569f40702

So, using more than 32 bits is possible, providing that we change the
implementation of v4l2_norm_to_name() or find a way for it to work with
ppc32.

Instead of just adding a standard for each possible combination, we may
just add bits for the supported audio formats. For example, we can use
the bitmask as:

#define V4L2_STD_AUDIO_NICAM_A ((v4l2_std_id)0x0400)
#define V4L2_STD_AUDIO_A2_A ((v4l2_std_id)0x0800)

Since for all other chipsets but xc3028, all audio standards are
supported, maybe we can, instead, use a negate bitmap logic for the
non-supported audio standards. Something like:

#define V4L2_STD_AUDIO_NOT_NICAM_A ((v4l2_std_id)0x0400)
#define V4L2_STD_AUDIO_NOT_A2_A ((v4l2_std_id)0x0800)

And define some macros for the specific standards you need. For example:

#define V4L2_STD_AUDIO_NOT_ALL V4L2_STD_AUDIO_NOT_A2_A |
V4L2_STD_AUDIO_NOT_NICAM_A

#define V4L2_STD_PAL_BG_A2 V4L2_STD_PAL_BG | (V4L2_STD_AUDIO_NOT_ALL
!V4L2_STD_AUDIO_NOT_A2_A)

This way, V4L2_STD_PAL_BG will mean that this PAL/BG accepts all
possible audio standards (being binary compatible), while
V4L2_STD_PAL_BG_A2_A will mean that only A2 response 'A' audio format is
supported for PAL/BG.

--
Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Alex Deucher [EMAIL PROTECTED] wrote:
 On 9/14/07, Markus Rechberger [EMAIL PROTECTED] wrote:
  On 9/14/07, Manu Abraham [EMAIL PROTECTED] wrote:
   Joerg Roedel wrote:
On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
What do you think about IOMMU?
   
   
Just because AMD or INTEL want to invent some whizzy new technology
 it
doesn't say anything about the TV card development and retail
 business.
Intel and AMD have teams of Linux engineers helping operating
 system
developers bring their ideas and technologies to new platforms.
 That's
   a
million miles away from any of the TV board vendors I know of, who
 have
little or NO fulltime linux developers and consider the  5% market
fringe at best.
   
it helps to virtualize devices and introduces newer features for
 that.
Some interesting projects could be derrived out of that, there are
quite a few interesting papers floating around how drivers could be
handled in future.
   
IOMMU can be considered similar to the AGP GART, which is similar,
remapping the Addresses, as far as i understand.
   
Common new IOMMUs have only very few in common with the AGP GART. In
fact, with current modern IOMMU hardware it will be possible to
implement secure userspace device drivers that are even able to do
 DMA.
This is not possible with the GART.
   
Though you get a physical to virtual translation, what about
 interrupts,
   
Modern IOMMUs are able to remap interrupts. This will solve the
 problem
with PCI interrupt sharing.
  
   What CPU's are we talking about ?
  
 
  upcoming x86-64 processors from the AMD side. I'm not into what Intel
  is doing in that area at the moment.

 All AMD64 chips have an IOMMU.  Only Intel's most recent chips do.


It's not available yet, you can read more about it in the following article:

http://developer.amd.com/articlex.jsp?id=101

If you're interested in it I can put together some more information about
it.

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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-14 Thread Michael Krufky

On 9/14/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
   - The hybrid tuner support, that where your requirement, when all those
   discussions started, were already added to the subsystem. So now, an
   hybrid tuner can be accessed by both DVB and V4L devices;
  
 
  It's far more complex as the thing which is implemented there.
  The only thing that has been implemented is that one moduleformat
  can be loaded by the v4l and by the dvb framework nothing else at the
  moment. I told you at the kernel summit about that and I think you
  knew about that before.
 
  Just to quote some text:
  Right now, a separate instance of the driver is used for analog /
  digital tuning.  In order to use a single instance, we will have to
  store a pointer to the dvb_frontend structure on the bridge level, but
  there are various other prerequisites that must be dealt with before we
  get to that point.
 
  We _will_ get there though, eventually.

 Maybe it is still not perfect. Feel free to improve it. Several people
 from the community, including me, already offered you help to add your
 driver, reworking on the 5% of the stuff that aren't compatible with the
 V4L/DVB core API design.

For clarification, Markus is quoting me, above.

The idea is to eventually store a pointer to the dvb_frontend
structure on the bridge level to be used as a single entry point
between the analog and digital subsystems.  However, we are not yet
ready for this, as the refactoring process has a lot more to be done
beforehand.

Phase 1 of the refactoring was to implement the core changes required
for a single module to be used by both v4l and dvb, and to convert the
existing tuner modules to the new internal API.

Phase 2, a work in progress, involves the removal of duplicated code.
For example, the current code in the master branch still has tda8275 /
tda8275a analog code inside of tda8290.c, where the digital tuning
code is in tda827x.c ...  This was resolved in this changeset:

Move all tda8275/8275a tuning code from tda8290 module into tda827x module
http://linuxtv.org/hg/~mkrufky/philipsNXP/rev/09c2e16a8cdd

This code is working fine, and I have it pushed to linuxtv.org for the
sake of testing.  I have not requested merge to master because I still
have some cleanups to do, and I do not want this to go to 2.6.24.

(side note: basic support for TDA8295 + TDA18271 has been added to my
philipsNXP tree, as well)

Tuner-simple and dvb-pll will have to undergo a similar treatment, and
it's not going to happen overnight.  But I *am* working on it.

I've outlined a basic roadmap to the refactoring plans in my original RFC:
http://linuxtv.org/pipermail/linux-dvb/2007-August/019950.html

What I didn't mention in that RFC, however, is the method in which I
plan to remove the multiple instantiations of the tuner code for a
single piece of hardware, by moving the dvb_frontend pointer to the
bridge level.  Since this change depends on the other refactoring to
be completed first, I found it unnecessary to explain this in detail
at this point.

When the time comes, a new RFC will be sent out to deal with that matter.

There is no reason why the Xceive driver cannot be merged into the
current development tree using the hybrid tuner framework as it stands
today.

Regards,

Mike
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Markus Rechberger [EMAIL PROTECTED] wrote:
 On 9/14/07, Alex Deucher [EMAIL PROTECTED] wrote:
  On 9/14/07, Markus Rechberger [EMAIL PROTECTED] wrote:
   On 9/14/07, Manu Abraham [EMAIL PROTECTED] wrote:
Joerg Roedel wrote:
 On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
 What do you think about IOMMU?


 Just because AMD or INTEL want to invent some whizzy new technology
  it
 doesn't say anything about the TV card development and retail
  business.
 Intel and AMD have teams of Linux engineers helping operating
  system
 developers bring their ideas and technologies to new platforms.
  That's
a
 million miles away from any of the TV board vendors I know of, who
  have
 little or NO fulltime linux developers and consider the  5% market
 fringe at best.

 it helps to virtualize devices and introduces newer features for
  that.
 Some interesting projects could be derrived out of that, there are
 quite a few interesting papers floating around how drivers could be
 handled in future.

 IOMMU can be considered similar to the AGP GART, which is similar,
 remapping the Addresses, as far as i understand.

 Common new IOMMUs have only very few in common with the AGP GART. In
 fact, with current modern IOMMU hardware it will be possible to
 implement secure userspace device drivers that are even able to do
  DMA.
 This is not possible with the GART.

 Though you get a physical to virtual translation, what about
  interrupts,

 Modern IOMMUs are able to remap interrupts. This will solve the
  problem
 with PCI interrupt sharing.
   
What CPU's are we talking about ?
   
  
   upcoming x86-64 processors from the AMD side. I'm not into what Intel
   is doing in that area at the moment.
 
  All AMD64 chips have an IOMMU.  Only Intel's most recent chips do.
 

 It's not available yet, you can read more about it in the following article:

 http://developer.amd.com/articlex.jsp?id=101

 If you're interested in it I can put together some more information about
 it.

It (the IOMMU) is available on all AMD64 chips.  The newer
virtualization stuff is only on the newer chips.

Alex
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

On Fri, Sep 14, 2007, Markus Rechberger wrote:
 
 people do contribute to the em28xx project.
...
 there's also an active and even problem solving oriented ML available:
 http://mcentral.de/pipermail/em28xx/
 
 Also if you look at the mercurial code you'll see several people
 contributing to that project.

Of course, people who own such a device and want to use
it with Linux have no choice but to work with you.
And you do a good job for your users, you support them
well and in return they contribute info and patches
to support new devices.

But the thing is that at mcentral.de you're the man at the top,
and your users will hardly disagree with you on core
technical questions. (Well, admittedly I'm speculating
here as I don't read your em28xx list.)

On for drivers/media/ OTOH you are just one developer among others,
and some of them choose to disagree with you. Even worse,
IIRC there wasn't even _a single_ other developer willing
to ACK your offending patch.

Now, doesn't _that_ get you thinking?


Johannes
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-14 Thread Aidan Thornton

Hi,

On 9/14/07, Michael Krufky [EMAIL PROTECTED] wrote:
 On 9/14/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
- The hybrid tuner support, that where your requirement, when all those
discussions started, were already added to the subsystem. So now, an
hybrid tuner can be accessed by both DVB and V4L devices;
   
  
   It's far more complex as the thing which is implemented there.
   The only thing that has been implemented is that one moduleformat
   can be loaded by the v4l and by the dvb framework nothing else at the
   moment. I told you at the kernel summit about that and I think you
   knew about that before.
  
   Just to quote some text:
   Right now, a separate instance of the driver is used for analog /
   digital tuning.  In order to use a single instance, we will have to
   store a pointer to the dvb_frontend structure on the bridge level, but
   there are various other prerequisites that must be dealt with before we
   get to that point.
  
   We _will_ get there though, eventually.
 
  Maybe it is still not perfect. Feel free to improve it. Several people
  from the community, including me, already offered you help to add your
  driver, reworking on the 5% of the stuff that aren't compatible with the
  V4L/DVB core API design.

 For clarification, Markus is quoting me, above.

 The idea is to eventually store a pointer to the dvb_frontend
 structure on the bridge level to be used as a single entry point
 between the analog and digital subsystems.  However, we are not yet
 ready for this, as the refactoring process has a lot more to be done
 beforehand.

I think this will require a rethink of either how the em2880-dvb
driver works or how frontend drivers work. The current API expects
users to initialise their frontend and then bind a tuner to it.
em2880-dvb is a sort of subdriver that attaches to the main driver,
and doesn't have any control over when or how it initialises its
tuner, so it can't delay tuner initialisation until the frontend has
been initialised. (I don't think it's the only hybrid driver that
works this way either). Of course, I could be missing something.

 There is no reason why the Xceive driver cannot be merged into the
 current development tree using the hybrid tuner framework as it stands
 today.

I'm not convinced this is entirely true. In order to avoid unnecessary
reinitialisation of the device, the driver needs to know whether the
device is in analog or digital mode, and I can't see a way of doing it
with the current API. (I think existing drivers, such as the xc2028
driver in one branch, use the older analog API and make the digital
driver a wrapper around it.) Again, I may be missing something.

Aidan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner


  There is no reason why the Xceive driver cannot be merged into the
  current development tree using the hybrid tuner framework as it stands
  today.
 
 I'm not convinced this is entirely true. In order to avoid unnecessary
 reinitialisation of the device, the driver needs to know whether the
 device is in analog or digital mode, and I can't see a way of doing it
 with the current API. (I think existing drivers, such as the xc2028
 driver in one branch, use the older analog API and make the digital
 driver a wrapper around it.) Again, I may be missing something.

For sure there are some ways. One dirty way would be to add an static
lock at xc3028 driver. You can rise the lock when firmware is being
uploaded, removing it at the end. This would prevent the troubles you've
mentioned.

A cleaner way would be to create a tasklet for firmware upload. This
will also prevent the driver for a long load time, due to firmware
initialization (a similar change were recently added at ivtv driver).

For sure there are other ways of doing this.
 
Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

Aidan Thornton wrote:

 
 I think this will require a rethink of either how the em2880-dvb
 driver works or how frontend drivers work. The current API expects
 users to initialise their frontend and then bind a tuner to it.
 em2880-dvb is a sort of subdriver that attaches to the main driver,
 and doesn't have any control over when or how it initialises its
 tuner, so it can't delay tuner initialisation until the frontend has
 been initialised. (I don't think it's the only hybrid driver that
 works this way either). Of course, I could be missing something.

The em28xx/xc3028 is in fact not too complex. Just for sake of
demonstration, some time back i had posted a dummy driver how it can be
done in a nice and clean way as an example.

The patch assumes some additional standards, you can ignore them. But
you get the general idea from in there.
http://marc.info/?l=linux-videom=117613833119350w=2


 
 There is no reason why the Xceive driver cannot be merged into the
 current development tree using the hybrid tuner framework as it stands
 today.
 
 I'm not convinced this is entirely true. In order to avoid unnecessary
 reinitialisation of the device, the driver needs to know whether the
 device is in analog or digital mode, and I can't see a way of doing it
 with the current API. (I think existing drivers, such as the xc2028
 driver in one branch, use the older analog API and make the digital
 driver a wrapper around it.) Again, I may be missing something.

You can read this post also for some additional information.
http://marc.info/?l=linux-videom=117922735929375w=2

Use the ideas as you deem fit. ;-)

Manu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Johannes Stezenbach [EMAIL PROTECTED] wrote:
 On Fri, Sep 14, 2007, Markus Rechberger wrote:
 
  people do contribute to the em28xx project.
 ...
  there's also an active and even problem solving oriented ML available:
  http://mcentral.de/pipermail/em28xx/
 
  Also if you look at the mercurial code you'll see several people
  contributing to that project.

 Of course, people who own such a device and want to use
 it with Linux have no choice but to work with you.
 And you do a good job for your users, you support them
 well and in return they contribute info and patches
 to support new devices.

 But the thing is that at mcentral.de you're the man at the top,
 and your users will hardly disagree with you on core
 technical questions. (Well, admittedly I'm speculating
 here as I don't read your em28xx list.)


they can. Put technical issues infront of everything also see the
whole picture that userspace tv applications have to support
all the codecs which are available.

 On for drivers/media/ OTOH you are just one developer among others,
 and some of them choose to disagree with you. Even worse,
 IIRC there wasn't even _a single_ other developer willing
 to ACK your offending patch.


there was not a single developer of the old crufted developers who
didn't bring the project forward during the last 2 years.
yes you're right.

 Now, doesn't _that_ get you thinking?


it gets me thinking. Some core developers who I met during
the last few weeks (kernel summit, suse conference in czech)
told me to go on with it actually because the final plan isn't that
bad.. I don't expect anyone of the old crufted v4l/dvb (well many
of them already left the party) will join the game...
(I'll leave that open here) spend some time read the whole history
of this thread and it will show up what this all is targeting at.
I'll answer your questions with technical reasons why I'm doing
all that stuff that way if you'll just ask.
Someone told me during the last 2 weeks
 but v4l2 was about to solve all those problems it didn't. (point)
and I think I explained good enough why all that crap still goes
on as it is.

Beside that I'm just curious how much did you contribute
during the last 2 years to the lkml/linux kernel, and how much
do you want to contribute in future? (also from my side
talk is cheap (even for me) but getting something done costs
quite some time and feedback from other people)

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

Re: [linux-dvb] [PATCH] Userspace tuner

 Beside that I'm just curious how much did you contribute
 during the last 2 years to the lkml/linux kernel, and how much
 do you want to contribute in future? (also from my side
 talk is cheap (even for me) but getting something done costs
 quite some time and feedback from other people)

Contributing doesn't necessarily means submitting patches. There are
several good guys at the community offering very valuable contributions,
like patchset reviews, good comments, userspace experiences, etc.

Johannes does a very impressive work of maintaining, almost alone,
LinuxTV website, upgrading the system, monitoring disk spaces, taking
backups, etc. Also, he is always available to discuss the most important
changes at APIs and to defend the Open Source community, providing his
very clear point of view.

Thank you, Johannes for all your good work!

-- 
Cheers,
Mauro

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Johannes Stezenbach [EMAIL PROTECTED] wrote:
On Fri, Sep 14, 2007, Markus Rechberger wrote:

people do contribute to the em28xx project.
...
there's also an active and even problem solving oriented ML available:
http://mcentral.de/pipermail/em28xx/

Also if you look at the mercurial code you'll see several people
contributing to that project.

Of course, people who own such a device and want to use
it with Linux have no choice but to work with you.
And you do a good job for your users, you support them
well and in return they contribute info and patches
to support new devices.

But the thing is that at mcentral.de you're the man at the top,

why is it mcentral.de at the moment? I started several discussions about
the whole topic. The thing which is in v4l-dvb on linuxtv does not satisfy
any requirements, also further additions will be hard to achieve with it.

and your users will hardly disagree with you on core
technical questions. (Well, admittedly I'm speculating
here as I don't read your em28xx list.)

they can disagree, I even pointed out to design flaws lately when
some users posted bugreports.

On for drivers/media/ OTOH you are just one developer among others,
and some of them choose to disagree with you. Even worse,
IIRC there wasn't even _a single_ other developer willing
to ACK your offending patch.

the current patch isn't offending anymore, see it as a chance I'm
giving you the chance to acknowlidge what has been done now from
my side.
The main discussion in this thread was about drivers in userspace
are bad because the API will allow binary drivers. The guy
who works for Hauppauge (again I also have good contacts
at Hauppauge Europe) writes it's bad - for no technical reason.

Now, doesn't _that_ get you thinking?

oh yes.

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

Re: [linux-dvb] [PATCH] Userspace tuner

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.

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.

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 used to
state on your website that your intention were to release binary-only
xc5000 drivers. So, please stop with childish and assume what you've
said.

http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c

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.

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:

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.

---

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.

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.

Cheers,
Mauro

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-13 Thread Steven Toth


Markus Rechberger wrote:

On 9/13/07, Steven Toth <[EMAIL PROTECTED]> wrote:
  

Also there is to consider a non technical aspect, whether vendors will
misuse this interface for binary only, undermining the efforts put in
for OSS drivers.




What holds companies for using the current available code putting it
into an rpm or deb package and releasing such code now?

The Avermedia example I pointed out to is a good example already.
As from my side I won't release binary drivers.
Although on the other side:
* are drivers from vendors which work through several kernel versions
that bad?
* Why did someone duallicense videodev2 with BSD/GPL?

I would appreciate if someone else on the list could also comment
the reason that drivers should all be included in the linuxkernel just
because forcing the companies to release binary drivers because
of that. My opinion about that is if a company wants to go opensource
they will do so, if not they will either not release a driver or release
nothing.


  

I know for certain that adding a userland API tuner/demod interface to
the kernel, allowing non-caring opportunistic silicon or board vendors
to developer closed source proprietary drivers, will have a negative
effect on the community and we'd set back linuxtv 3-5 years.

I know for certain that it would happen. Trust me.

I've told you this countless times and you're not hearing me.

Hauppauge have some leverage with Conexant and NXP to release public
datasheets. If they just have to release a demod.so (or similar)
loadable, they'll defer to the board vendors and we'll see the certain
board vendors 'locking other board vendors' out of their drivers. We'll
see embedded firmware, not shared between drivers.

Except, it won't stop at demod.so. It will extend into unfixable bugs
for VendorB's board, because VendorA doesn't want to release a new
demod.so, and VendorB has no linux resources. What happens next? For
financial reasons - demod.so will begin to include checks to see if
specific PCI or USB devices are present in the system, and will fail to
work properly (if at all) when they're not being used with the preferred
products.



Steven,

what stops vendors of using the current existing code to achieve that
goal. They could provide binary drivers with the existing API.

  


Because the good people in this mailing list are keeping them honest. 
Give any board or silicon company the ability to protect their IP, even 
in the smallest way and they'll do it, and for no good technical reason. 
It's a cut throat market and it's not clear that everyone understands 
just how thin sales margins really are.


That means Hauppauge potentially releasing a binary driver, because it's 
much easier than seeking silicon vendor permission for a public diver. 
The net result of that would mean I'd have to leave the company and find 
another company that practices the one thing I truly care about  
open source and open development groups.


I'm keeping Hauppauge honest with their Linux involvement and I'm not 
alone. Other devs in other linux subsystems in other companies are doing 
the same thing.


Binary drivers (or binary components) leads Linux back in time.

I can't believe your so passionate about protecting secrets.


What stops companies to intercept the ioctl calls and overriding some
I2C commands?

  


Why would a company want to do that? Companies don't do that, hackers do 
that.



Since you know about windows drivers (at least I think that you know
about it) you might know about the limitations of the v4l/dvb API
in general the reason just put as much code as possible into the
kernel just for forcing companies to release code under GPL doesn't
seem to be valid.
  


It seems perfectly valid to me.


How about proprietary video formats, would you also place the decoding
algorithms in kernel  just to force companies to release their code
for it?
  


The kernel has no good API for those, each new type of video device and 
suggested API is judged on it's own merits and discussed on the mailing 
lists.



What do you think about the existing usbfs implementation, which
allows to implement usb drivers completly in userspace?
  


Those are not my problem and I don't use them, you should raise that 
with the relevant usb-dev mailing lists. I'm here because I care about 
linuxtv. Please stay on topic.



What do you think about IOMMU?

  
Just because AMD or INTEL want to invent some whizzy new technology it 
doesn't say anything about the TV card development and retail business. 
Intel and AMD have teams of Linux engineers helping operating system 
developers bring their ideas and technologies to new platforms. That's a 
million miles away from any of the TV board vendors I know of, who have 
little or NO fulltime linux developers and consider the < 5% market 
fringe at best.


Markus, senior devs in the LinuxTV group are telling you, based on their 
commercial experience, that userspace access is

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-13 Thread hermann pitton

Am Donnerstag, den 13.09.2007, 16:36 -0400 schrieb Steven Toth:
> >   
> >> Also there is to consider a non technical aspect, whether vendors will
> >> misuse this interface for binary only, undermining the efforts put in
> >> for OSS drivers.
> >>
> >> 
> >
> > What holds companies for using the current available code putting it
> > into an rpm or deb package and releasing such code now?
> >
> > The Avermedia example I pointed out to is a good example already.
> > As from my side I won't release binary drivers.
> > Although on the other side:
> > * are drivers from vendors which work through several kernel versions
> > that bad?
> > * Why did someone duallicense videodev2 with BSD/GPL?
> >
> > I would appreciate if someone else on the list could also comment
> > the reason that drivers should all be included in the linuxkernel just
> > because forcing the companies to release binary drivers because
> > of that. My opinion about that is if a company wants to go opensource
> > they will do so, if not they will either not release a driver or release
> > nothing.
> >
> >   
> 
> 
> I know for certain that adding a userland API tuner/demod interface to 
> the kernel, allowing non-caring opportunistic silicon or board vendors 
> to developer closed source proprietary drivers, will have a negative 
> effect on the community and we'd set back linuxtv 3-5 years.
> 
> I know for certain that it would happen. Trust me.
> 
> I've told you this countless times and you're not hearing me.
> 
> Hauppauge have some leverage with Conexant and NXP to release public 
> datasheets. If they just have to release a demod.so (or similar) 
> loadable, they'll defer to the board vendors and we'll see the certain 
> board vendors 'locking other board vendors' out of their drivers. We'll 
> see embedded firmware, not shared between drivers.
> 
> Except, it won't stop at demod.so. It will extend into unfixable bugs 
> for VendorB's board, because VendorA doesn't want to release a new 
> demod.so, and VendorB has no linux resources. What happens next? For 
> financial reasons - demod.so will begin to include checks to see if 
> specific PCI or USB devices are present in the system, and will fail to 
> work properly (if at all) when they're not being used with the preferred 
> products.
> 
> Read my lips: For commercial reasons, this enables driver components 
> that only work if specific boards are present.
> 
> - Steve
> 

I do confirn that I have all this, Steve mentions, really have seen
already!

Markus, sorry, they did abuse it and will do it again.

Hermann


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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/13/07, Steven Toth <[EMAIL PROTECTED]> wrote:
>
> >
> >> Also there is to consider a non technical aspect, whether vendors will
> >> misuse this interface for binary only, undermining the efforts put in
> >> for OSS drivers.
> >>
> >>
> >
> > What holds companies for using the current available code putting it
> > into an rpm or deb package and releasing such code now?
> >
> > The Avermedia example I pointed out to is a good example already.
> > As from my side I won't release binary drivers.
> > Although on the other side:
> > * are drivers from vendors which work through several kernel versions
> > that bad?
> > * Why did someone duallicense videodev2 with BSD/GPL?
> >
> > I would appreciate if someone else on the list could also comment
> > the reason that drivers should all be included in the linuxkernel just
> > because forcing the companies to release binary drivers because
> > of that. My opinion about that is if a company wants to go opensource
> > they will do so, if not they will either not release a driver or release
> > nothing.
> >
> >
>
>
> I know for certain that adding a userland API tuner/demod interface to
> the kernel, allowing non-caring opportunistic silicon or board vendors
> to developer closed source proprietary drivers, will have a negative
> effect on the community and we'd set back linuxtv 3-5 years.
>
> I know for certain that it would happen. Trust me.
>
> I've told you this countless times and you're not hearing me.
>
> Hauppauge have some leverage with Conexant and NXP to release public
> datasheets. If they just have to release a demod.so (or similar)
> loadable, they'll defer to the board vendors and we'll see the certain
> board vendors 'locking other board vendors' out of their drivers. We'll
> see embedded firmware, not shared between drivers.
>
> Except, it won't stop at demod.so. It will extend into unfixable bugs
> for VendorB's board, because VendorA doesn't want to release a new
> demod.so, and VendorB has no linux resources. What happens next? For
> financial reasons - demod.so will begin to include checks to see if
> specific PCI or USB devices are present in the system, and will fail to
> work properly (if at all) when they're not being used with the preferred
> products.
>
Steven,

what stops vendors of using the current existing code to achieve that
goal. They could provide binary drivers with the existing API.

What stops companies to intercept the ioctl calls and overriding some
I2C commands?

Since you know about windows drivers (at least I think that you know
about it) you might know about the limitations of the v4l/dvb API
in general the reason just put as much code as possible into the
kernel just for forcing companies to release code under GPL doesn't
seem to be valid.
How about proprietary video formats, would you also place the decoding
algorithms in kernel  just to force companies to release their code
for it?
What do you think about the existing usbfs implementation, which
allows to implement usb drivers completly in userspace?
What do you think about IOMMU?

please answer those questions.

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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-13 Thread Steven Toth



  

Also there is to consider a non technical aspect, whether vendors will
misuse this interface for binary only, undermining the efforts put in
for OSS drivers.




What holds companies for using the current available code putting it
into an rpm or deb package and releasing such code now?

The Avermedia example I pointed out to is a good example already.
As from my side I won't release binary drivers.
Although on the other side:
* are drivers from vendors which work through several kernel versions
that bad?
* Why did someone duallicense videodev2 with BSD/GPL?

I would appreciate if someone else on the list could also comment
the reason that drivers should all be included in the linuxkernel just
because forcing the companies to release binary drivers because
of that. My opinion about that is if a company wants to go opensource
they will do so, if not they will either not release a driver or release
nothing.

  



I know for certain that adding a userland API tuner/demod interface to 
the kernel, allowing non-caring opportunistic silicon or board vendors 
to developer closed source proprietary drivers, will have a negative 
effect on the community and we'd set back linuxtv 3-5 years.


I know for certain that it would happen. Trust me.

I've told you this countless times and you're not hearing me.

Hauppauge have some leverage with Conexant and NXP to release public 
datasheets. If they just have to release a demod.so (or similar) 
loadable, they'll defer to the board vendors and we'll see the certain 
board vendors 'locking other board vendors' out of their drivers. We'll 
see embedded firmware, not shared between drivers.


Except, it won't stop at demod.so. It will extend into unfixable bugs 
for VendorB's board, because VendorA doesn't want to release a new 
demod.so, and VendorB has no linux resources. What happens next? For 
financial reasons - demod.so will begin to include checks to see if 
specific PCI or USB devices are present in the system, and will fail to 
work properly (if at all) when they're not being used with the preferred 
products.


Read my lips: For commercial reasons, this enables driver components 
that only work if specific boards are present.


- Steve








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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-13 Thread Manu Abraham

Markus Rechberger wrote:
> On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Markus Rechberger wrote:
>>> On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> It's only a step in development, I do not intend to keep the kernel
> stub in the end, but I do intend to keep and use the userspace drivers
> with i2c-dev in the long run, this requires a v4l/dvb library at the
>> front
> of everything.
 Well, this was what adq and myself did with libdvbapi and mti, (much
 before UIO was announced at LK.) It is not tied to I2C either.

>>> I2C is the main communication path for it, although there are callback
>>> mechanisms available which add the possibility for different configuration
>>> paths.
>> Sorry, i must say that what you said is wrong.
>>
>> The example implementation in libdvbapi/mti is I2C only with a STV0299
>> on the TTPCI, if that was what you meant.
>> But if you need examples for every possible interface, then probably you
>> are out of luck.
>>
> 
> I didn't comment the libdvbapi/mti driver.
> I'm quite confident that non I2C protocols can be handled by a callback
> function. In the end it's either a usb control command or pci mmio writes

There's also DTL in some cases. It's not USB msgs and or PCI MMIO alone.
The actual DTL spec is unfortunately not open.

Manu

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> >>> It's only a step in development, I do not intend to keep the kernel
> >>> stub in the end, but I do intend to keep and use the userspace drivers
> >>> with i2c-dev in the long run, this requires a v4l/dvb library at the
> front
> >>> of everything.
> >> Well, this was what adq and myself did with libdvbapi and mti, (much
> >> before UIO was announced at LK.) It is not tied to I2C either.
> >>
> >
> > I2C is the main communication path for it, although there are callback
> > mechanisms available which add the possibility for different configuration
> > paths.
>
> Sorry, i must say that what you said is wrong.
>
> The example implementation in libdvbapi/mti is I2C only with a STV0299
> on the TTPCI, if that was what you meant.
> But if you need examples for every possible interface, then probably you
> are out of luck.
>

I didn't comment the libdvbapi/mti driver.
I'm quite confident that non I2C protocols can be handled by a callback
function. In the end it's either a usb control command or pci mmio writes
in the current usual cases and such calls could be handled behind a
callback function which is implemented in the driver.

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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-13 Thread Manu Abraham

Markus Rechberger wrote:
> On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>>> It's only a step in development, I do not intend to keep the kernel
>>> stub in the end, but I do intend to keep and use the userspace drivers
>>> with i2c-dev in the long run, this requires a v4l/dvb library at the front
>>> of everything.
>> Well, this was what adq and myself did with libdvbapi and mti, (much
>> before UIO was announced at LK.) It is not tied to I2C either.
>>
> 
> I2C is the main communication path for it, although there are callback
> mechanisms available which add the possibility for different configuration
> paths.

Sorry, i must say that what you said is wrong.

The example implementation in libdvbapi/mti is I2C only with a STV0299
on the TTPCI, if that was what you meant.
But if you need examples for every possible interface, then probably you
are out of luck.

Manu

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>
> > It's only a step in development, I do not intend to keep the kernel
> > stub in the end, but I do intend to keep and use the userspace drivers
> > with i2c-dev in the long run, this requires a v4l/dvb library at the front
> > of everything.
>
> Well, this was what adq and myself did with libdvbapi and mti, (much
> before UIO was announced at LK.) It is not tied to I2C either.
>

I2C is the main communication path for it, although there are callback
mechanisms available which add the possibility for different configuration
paths.

> But, according to your statements (with regards to i2c-dev) you can
> handle only some I2C based devices, which is in fact a subset of a
> subset. Also not to forget that hardly a few I2C devices are in fact
> "truly" I2C compatible. In fact many variables to be considered.
>

The analogue tuner core is also only for i2c only devices which most
devices rely on.

> Also there is to consider a non technical aspect, whether vendors will
> misuse this interface for binary only, undermining the efforts put in
> for OSS drivers.
>

What holds companies for using the current available code putting it
into an rpm or deb package and releasing such code now?

The Avermedia example I pointed out to is a good example already.
As from my side I won't release binary drivers.
Although on the other side:
* are drivers from vendors which work through several kernel versions
that bad?
* Why did someone duallicense videodev2 with BSD/GPL?

I would appreciate if someone else on the list could also comment
the reason that drivers should all be included in the linuxkernel just
because forcing the companies to release binary drivers because
of that. My opinion about that is if a company wants to go opensource
they will do so, if not they will either not release a driver or release
nothing.

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

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-13 Thread Manu Abraham


> It's only a step in development, I do not intend to keep the kernel
> stub in the end, but I do intend to keep and use the userspace drivers
> with i2c-dev in the long run, this requires a v4l/dvb library at the front
> of everything.

Well, this was what adq and myself did with libdvbapi and mti, (much
before UIO was announced at LK.) It is not tied to I2C either.

But, according to your statements (with regards to i2c-dev) you can
handle only some I2C based devices, which is in fact a subset of a
subset. Also not to forget that hardly a few I2C devices are in fact
"truly" I2C compatible. In fact many variables to be considered.

Also there is to consider a non technical aspect, whether vendors will
misuse this interface for binary only, undermining the efforts put in
for OSS drivers.

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

Re: [linux-dvb] [PATCH] Userspace tuner

On 9/13/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 13, 2007, Markus Rechberger wrote:
> > Let's add the LKML to this.
> > 
> > On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > > > I don't see any technical reason why tuner drivers should be moved to
> > > > userspace. Looking at xc3028 device, the driver is very simple and
> > > > doesn't require any special treatment that it isn't possible to be
> done
> > > > at kernel. There are already some implementations on kernelspace that
> > > > works fine.
> > >
> > > As from my side to support the xceive driver properly it needs a
> > > rewrite and a proper API description. Since it's not possible to
> > > discuss any API changes
> 
> Not possible? We're doing it all the time...
> 

Then ask Mauro about the audio standard discussion which I had with him.

> However, your ideas were rejected in this discussion,
> and you can't seem to get over it.
> 

As for future projects I see other people having the same problems if
they want to join the project. If deeper requirements and/or ideas will
come up some particular people will try to run their own game.
If I'm doing something wrong technically then state it out show me
the bugs that I can understand what I did wrong or what I am doing
wrong. As for design changes if someone thinks he has to deny 
something he has to state out _why_ and not only some overall
nontechnical statements which do not help anyone.

> > > don't get me wrong but the existing community is rather small and
> > > kicking off people who are interested in changing things.
> 
> IMHO there is a lack of openness caused by people being burned
> in past flamewars. This makes it a bit difficult to see through
> what happens and why, and to participate.  However, I think it
> is completely wrong to say that the community is "kicking off people".
> 

You identified it already the right way in one mail much earlier. It's a
messup caused by many people and not only by one single person.
And that's also how I see it.

> > > I'm against how the project works out at the moment and how it worked
> > > out in history. Exactly this way will kick off companies to be
> > > interested in future like Avermedia. A driver can easily be written
> > > within a few weeks and I've been struggling with it for 2 years(!!!)
> > > now just for nothing finally telling me that some guys want to steal
> > > my code and move it to kernelspace although it would raise more
> > > complications with upcoming and current devices which have even more
> > > requirements.
> 
> Oh dear, there we go again... more flame bait...
> 
> I reality, 95% of your driver code could have been merged
> without problems, but you refused to take the small, objectionable
> part out of the picture.
> 

the driver itself still evolves, so the main point is in getting those 
incomplete
APIs to support further requirements. Instead of acknowlidging and seriously
discussing the solutions of others all that's beeing done now is to redo things
hundred times and splitting development one side beeing more open (which
is the userspace work) and the other part beeing more closed to a few people 
only (the inkernel work).
It's not my task to convince myself to rewrite the base of something which
I don't think that it would be valueable. The one who wants me that I 
spend days in changing my code should try to convince me to change
my mind on that, unless he can provide patches which demonstrate
that his changes are definitelly an advantage over what has been done 
from my side. 
I will for sure acknowlidge everything that will seriously improve the work 
which has been done.

> (For those interested:
> http://mcentral.de/~mrec/patches/v4l-dvb/hg_v4l-dvb-experimental_01.patch
> The patch changed the internal tuner API and required changes
> to all tuner drivers.)
> 

The main problem is moreover that the RFC didn't get discussed properly, 
afterwards people wondered what happened, even though the sources
were also available all the time in a public repository.

> Your all-or-nothing approach didn't work out.
> 

well we got far enough that I end up to step away and preparing the sources
to be able to get submitted beside linuxtv since I don't/didn't get any useful
technical feedback there.
Convince me that my work is welcome then I might start to submit smaller
patches, I already spent days for exporting patches in history and it all
end up nowhere but in unfriendly discussions - which also turned me to be
unfriendly to some people (which I've been told that I should ignore them 
recently and also not continue to to argue on a nontechnical level .. althought 
as mentioned I'm not the only one who made mistakes :-)

> Out of curiosity: How does your userspace approach solve
> the hybrid (analog/digital TV) tuner problem which was the
> only objectionable part of your work? And why are the kernel
> parts of your new

Re: [linux-dvb] [PATCH] Userspace tuner

2007-09-13 Thread Johannes Stezenbach

On Thu, Sep 13, 2007, Markus Rechberger wrote:
> 
> We currently have an implementation that works, although
> it works by downloading several firmwares for several devices 
> or even several countries. This is not what I want to have in 
> future since it's not needed and it's also hard to manage for
> distributors. All those differences could be adjusted by 
> software even without module parameter hacks.

This argument doesn't hold water. The unpleasant point
for users and distributors isn't the "binary-only"
thing, it's the "no right to distribute" problem.
And that's the same for firmware blobs or binary-only
userspace blobs.

IOW, if you can get the right to redistribute a binary-only
userspace blob which incudes the firmware inside, why
shouldn't you be able to get the right to redistribute
just the firmware?

Or the other way round: Do you think your binary-only software
will be important enough so distributors will go through
all the trouble of trying to get a license to include it in
their distribution? If so, why wouldn't they do the same
for the plain firmware blobs for in-kernel drivers?

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

Re: [linux-dvb] [PATCH] Userspace tuner