On Tue, Sep 18, 2007 at 07:56:05PM -0300, Mauro Carvalho Chehab wrote:
> proprietary format. This way, an userspace app may use the userspace
> library as a "fallback method" for unknown FOURCC formats. The result
> will be probably far away from an optimal result on some cases (since it
>
> The reason why there is no single 'format conversion library' that
> everybody uses is because of the large differences between requirements
> for such a thing. The line between 'format conversion' and things such
> as a video codec, or image processing is very vague.
Agreed. What I think it
On 9/18/07, Jelle Foks <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > 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
Markus Rechberger wrote:
> 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
Markus Rechberger wrote:
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
On 9/18/07, Jelle Foks [EMAIL PROTECTED] wrote:
Markus Rechberger wrote:
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
The reason why there is no single 'format conversion library' that
everybody uses is because of the large differences between requirements
for such a thing. The line between 'format conversion' and things such
as a video codec, or image processing is very vague.
Agreed. What I think it should
On Tue, Sep 18, 2007 at 07:56:05PM -0300, Mauro Carvalho Chehab wrote:
proprietary format. This way, an userspace app may use the userspace
library as a fallback method for unknown FOURCC formats. The result
will be probably far away from an optimal result on some cases (since it
probably mean
On 9/15/07, Bernard Jungen <[EMAIL PROTECTED]> wrote:
> 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
On 9/15/07, Bernard Jungen [EMAIL PROTECTED] wrote:
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
On Saturday 15 September 2007 18:58:34 Bernard Jungen wrote:
> 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
On Saturday 15 September 2007 18:58:34 Bernard Jungen wrote:
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
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
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
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
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
> 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
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
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
On Sat, Sep 15, 2007, Markus Rechberger wrote:
>
> it gets me thinking. Some core developers who I met during
> the last few weeks (kernel summit, suse conference in czech)
> told me to go on with it actually because the final plan isn't that
> bad..
I was referring to your code you posted for
On 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
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.
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.
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
On Sat, Sep 15, 2007, Markus Rechberger wrote:
it gets me thinking. Some core developers who I met during
the last few weeks (kernel summit, suse conference in czech)
told me to go on with it actually because the final plan isn't that
bad..
I was referring to your code you posted for
On Sat, Sep 15, 2007, Markus Rechberger wrote:
The main discussion in this thread was about drivers in userspace
are bad because the API will allow binary drivers. The guy
who works for Hauppauge (again I also have good contacts
at Hauppauge Europe) writes it's bad - for no technical reason.
On 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
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
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
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
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
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
> 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
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
> 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)
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
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,
> > 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
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
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
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
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
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
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
> > - 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
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
> > >
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
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
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
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
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
>
>
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
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
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
> > * 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
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
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
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
>>> 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
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
>
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 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
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
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
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
* 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
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
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
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
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
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
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
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,
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
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,
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
- 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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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?
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
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
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
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.
> 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
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
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
Hi,
On 9/13/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> 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
1 - 100 of 118 matches
Mail list logo
