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
> 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 sho
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
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 fee
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 th
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 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 a
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 line
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 d
> 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 pla
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 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 me
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 regressi
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.
AF
> 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
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 y
> 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)
Con
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 y
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 whethe
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
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
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:5
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 fa
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 thing
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
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 y
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 accept
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 g
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'
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 s
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 anythin
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 overr
> > * 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 remai
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 an
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
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 Li
>>> 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
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
>
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 avai
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 t
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 availabl
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?
T
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 use
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 i2
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 mt
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
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. Lo
Well, I'd like to see Linus' opinion about this, because while
programmers keep discussing this, users are waiting forever... so if
Markus has a concrete and better solution, why don't use it?
And as far as I know, Markus is the programmer who is most
interested in this code. I did
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:
> > Markus,
> >
> > Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu:
> > > Following patch adds the possibility to implement tuner drive
59 matches
Mail list logo