Markus,

quoted text
> >
> > 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

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