> 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
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
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) wri
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
_
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, 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
> > - 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
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
>>> 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 comp
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
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
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
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, Dâniel Fraga <[EMAIL PROTECTED]> wrote:
> 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, Mark
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
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 drivers in
> > userspace.
>
> As you asked me about userspace driver, at Linux Conf Europe, let me
>
Markus,
Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu:
> Following patch adds the possibility to implement tuner drivers in
> userspace.
As you asked me about userspace driver, at Linux Conf Europe, let me
give you my feedback about it.
On Linux, userspace-to-kernelspace APIs ar
Markus Rechberger wrote:
> anyway it's history; we shouldn't waste more time on discussing what
> happened
Indeed.
However, you have continued to do so, and in an inflammatory fashion --
and that is just not going to escape attention. As I've indicated to
you earlier -- if the issue is truly at
Dont bother xc2028-fe is
STILL A PATCH.
Getting the dual4 working for .au still requires PATCHES
What time is it?
I'm not complaining. Since it works.
But Please consider ( or dont)
Even if certain developers did not exist in this dimension.
You would still be stuck where you are now. Only with le
Hi,
Dâniel Fraga schrieb:
> Well... if I was a developer, I would knew why I'm doing this.
> And I would accept the challenge ("Man who plays golf in rain get wet
> balls"). So, developing drivers isn't just write code, but to interact
> with users and see what's their problems. We, the user
On Fri, 17 Aug 2007 11:15:21 -0400
CityK <[EMAIL PROTECTED]> wrote:
> While supporting most devices is an admirable goal (and one which I
> certainly subscribe to) , what makes you think that pushing something
> through just for the sake of supporting it is the right course of
> action? Does "Lin
On Fri, 17 Aug 2007 13:29:41 +0200
Henk <[EMAIL PROTECTED]> wrote:
> There's also some responsibility by the users:
>
> Users should THINK before they buy unsupported devices. If possible
> buy devices that are supported by mainline.
>
> This is the only way we can convince manufactures to contr
anyway it's history; we shouldn't waste more time on discussing what
happened .. we could fill weeks by doing that.
So to clear up some things:
* regarding binary userspace drivers, if someone wants to write binary
drivers he can do that already if he has enough knowledge and time,
even without th
On 8/17/07, CityK <[EMAIL PROTECTED]> wrote:
> Dâniel Fraga wrote:
> > I've been exchanging e-mails with Markus for months and he
> > supported very well my board (cx88 chip with xc2028 tuner).
> >
>
> Yes, Markus is very good (exceptionally good in fact) with helping users.
>
> > But at th
Dâniel Fraga wrote:
> I've been exchanging e-mails with Markus for months and he
> supported very well my board (cx88 chip with xc2028 tuner).
>
Yes, Markus is very good (exceptionally good in fact) with helping users.
> But at the same time, I noticed that there's a disagreement
>
Dâniel Fraga wrote:
>
> While the developers discuss these things, the users are waiting forever.
You make it sound as if its a case of bureaucrats discussing policy
before opening the bread line.
> And i think that if Linux really wants
> to support well most of the devices, something should be
> Binary releases? Not from myself or Hauppauge. Period. Mark my words,
> you will not see Hauppauge push binary junk at people just because we
> want Linux support. That's the kind of thing marketing people like to do
> and it has no respect within the community.
Acked.
> Besides, who needs a
>> If it was not by Markus' effort, I couldn't use my Xceive based
>> board, so I support his initiative. And as far as I know, he's the only
>> programmer working on this specific tuner.
>>
>> To sum up: there's no time to waste. Linux needs more code and
>> less discussion.
>>
>>
>
> The reason is that the linuxtv project depends on people who have
> their own ideas and do not care about other solutions or temporary
> solutions to get things done, pulling the drivers to userspace adds
> more flexibility for upcoming devices. Also it's possible to provide
> one tuner binary
On 8/17/07, Henk <[EMAIL PROTECTED]> wrote:
> There's also some responsibility by the users:
>
> Users should THINK before they buy unsupported devices. If possible
> buy devices that are supported by mainline.
>
> This is the only way we can convince manufactures to contribute to the
> Linux commu
There's also some responsibility by the users:
Users should THINK before they buy unsupported devices. If possible
buy devices that are supported by mainline.
This is the only way we can convince manufactures to contribute to the
Linux community.
On Fri, Aug 17, 2007 at 01:09:19AM -0300, Daniel
On Thu, 16 Aug 2007 21:46:14 +0100
Simon Kenyon <[EMAIL PROTECTED]> wrote:
> i have not seen anything which would suggest that this is going into
> the kernel anytime soon. i don't know who is "right" but there appear
> to be serious differences of opinion between the developers as to how
> to pro
On 8/16/07, Simon Kenyon <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-16 at 12:39 -0300, Dâniel Fraga wrote:
> > I think this is a wonderful idea and I can't wait to see it
> > merged in the official kernel.
> >
> i have not seen anything which would suggest that this is going into the
> kernel
On Thu, 2007-08-16 at 12:39 -0300, Dâniel Fraga wrote:
> I think this is a wonderful idea and I can't wait to see it
> merged in the official kernel.
>
i have not seen anything which would suggest that this is going into the kernel
anytime soon.
i don't know who is "right" but there appear
On Tue, 14 Aug 2007 16:31:33 +0200
"Markus Rechberger" <[EMAIL PROTECTED]> wrote:
> Following patch adds the possibility to implement tuner drivers in
> userspace.
(...)
> This work can immediatelly be reused with ivtv [2], saa7134, cx88,
> em28xx [3] and cxusb drivers and add support
Hi Andreas,
On 8/14/07, Andreas Oberritter <[EMAIL PROTECTED]> wrote:
> Hello Markus,
>
> Markus Rechberger wrote:
> > +static int tuner_open(struct inode *inode, struct file *file)
> > +{
> > +struct tuner_info *info = kzalloc(sizeof(struct tuner_info),
> > GFP_KERNEL);
>
> you should retu
Hello Markus,
Markus Rechberger wrote:
> +static int tuner_open(struct inode *inode, struct file *file)
> +{
> +struct tuner_info *info = kzalloc(sizeof(struct tuner_info),
> GFP_KERNEL);
you should return -ENOMEM in case kzalloc fails.
> +init_waitqueue_head(&info->waitqueue);
> +m
Following patch adds the possibility to implement tuner drivers in
userspace.
The tuner drivers themself are implemented as shared libraries and will
get loaded dynamically by a userspace daemon.
Every kernelspace driver loads one instance of a userspace driver, which
will communicate with the k
75 matches
Mail list logo
