[linux-dvb] [PATCH] Userspace tuner

Markus Rechberger mrechberger at gmail.com
Thu Sep 13 00:46:31 CEST 2007

On 9/12/07, Mauro Carvalho Chehab <mchehab at infradead.org> 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
> give you my feedback about it.
> On Linux, userspace-to-kernelspace APIs are meant to be forever. This
> means that, once a newer API is created, this should remain supported
> for all future versions. So, such APIs should be carefully analyzed and
> accepted by the community, before going to mainstream.

The V4L and DVB API is stable at the moment because it's at a stage
which is sufficient for older devices but not sufficient for newer
devices anymore.
To support newer device it needs a change.

> I don't see any technical reason why tuner drivers should be moved to
> userspace. Looking at xc3028 device, the driver is very simple and
> doesn't require any special treatment that it isn't possible to be done
> at kernel. There are already some implementations on kernelspace that
> works fine.

As from my side to support the xceive driver properly it needs a
rewrite and a proper API description. Since it's not possible to
discuss any API changes I will work around at least for those devices
which I can support for.

> On the other hand, a TV driver without a tuner is a broken driver. With
> parts of the driver being at userspace, this means to add undesired
> complexity at the drivers architecture, while not bringing any benefit.
> If you look at V4L history, the first drivers started at userspace,
> being migrated to kernelspace, where we have the proper scenario for
> managing those devices.
> Another aspect that should be analyzed is what is desired by the
> community:

don't get me wrong but the existing community is rather small and
kicking off people who are interested in changing things.
I recently had a talk with someone and I've been told that I'm kicking
off people.
Guess why I kick off people? -> because they do not contribute in a
productive way which also means submitting patches. Optical useless
changes don't make any difference at the functionality in the end. And
my requirements are ignored constantly here.

> kernelspace tuners or userspace tuners. Keeping support for
> both at long term doesn't seem reasonable. The Linux community should
> decide what is the better way. Currently, only you are pushing for
> userspace tuners, mainly due to non-technical reasons.

read the project site and you will see the reasons.
Another advantage is that I have cygwin based code here which I can
easily reuse with all that work I'm not going to reinvent the wheel
even for newer devices which I work on.

> Almost all the
> other developers are comfortable with kernelspace tuners. So, creating
> an userspace interface just to make you happy is not the way we should
> go.

I'm afraid of giving the people which are against what I submitted the
responsibility over the project. Initially there was an RFC which
didn't get commented either (well there was one useless comment, I
tried to discuss it on IRC before with the same guy) after I
implemented exactly what I proposed there I got the first non
technical comments - also keep in mind that working on something costs
alot of time and talking about something unknown is rather cheap.

> A final aspect is that having an userspace driver for tuner will mean
> that the kernel driver will depend on an userspace counterpart in order
> to work. This will allow a vendor with bad intentions to release a
> partially broken userspace driver, with limited capabilities, and a
> closed source driver for full support. This model is likely to occur, if
> you take a look at the past. For example: ATI and Nvidia closed source
> drivers, several soft modem drivers, some network drivers, ...

Please go forward and discuss the UIO driver with Greg Kroah Hartmann
and the fuse driver with the other people. If companies want to
release binary drivers they can easily use the existing code put it
into an RPM or DEB package and Ubuntu will pick it up.

> With all those issues, I'm against to add an userspace interface for
> tuners.

I'm against how the project works out at the moment and how it worked
out in history. Exactly this way will kick off companies to be
interested in future like Avermedia. A driver can easily be written
within a few weeks and I've been struggling with it for 2 years(!!!)
now just for nothing finally telling me that some guys want to steal
my code and move it to kernelspace although it would raise more
complications with upcoming and current devices which have even more
I spent more time in rewriting and discussing everything than to get
any of those requirements done.
Look at the dvb hotplug patch which came from my side, also look at
device node locking where the Hauppauge guy submitted a patch which
doesn't work properly because of the spinning thread in the end. I
would take my considerations and requirements a bit more serious.


More information about the linux-dvb mailing list