Message-ID: <d9def9db0709141046h3b2dee40l398f5ed1bbc19322@mail.gmail.com>
Date:	Fri, 14 Sep 2007 19:46:55 +0200
From:	"Markus Rechberger" <mrechberger@...il.com>
To:	"Mauro Carvalho Chehab" <mchehab@...radead.org>
Cc:	"Johannes Stezenbach" <js@...uxtv.org>,
	"video4linux-list@...hat.com" <video4linux-list@...hat.com>,
	"Manu Abraham" <abraham.manu@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-dvb@...uxtv.org" <linux-dvb@...uxtv.org>, mschimek@....at
Subject: Re: [linux-dvb] [PATCH] Userspace tuner

On 9/14/07, Mauro Carvalho Chehab <mchehab@...radead.org> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists