User-space tuner misconception: it doesn't have anything to do withbinary blobs

[Dâniel Fraga]

	I read today on kerneltrap the following:

http://kerneltrap.org/Linux/Avoiding_Blobs

	and I notice that people have a misconception about how the
user space tuner proposed by Markus Rechberger works.

	I've been using Markus' code for a long time and he's the only
one that made my device works (a Powercolor Real Angel 330 capture
board = cx88 chipset with Xceive firmware dependent tuner).

	In the beginning, I used Markus' xc3028-tuner kernel module,
but it was always a fight between V4L developers and I, as a user, have
to wait many months... Ok, I tried to help Markus as most as I can and
I'd like to clarify what's really the user space tuner proposal:

1) the only difference between using a xc3028-tuner kernel module and a
user space tuner is obvious: we use a daemon that do the job that the
module made before.

2) there isn't any binary blobs. It doesn't matter if we use the kernel
module or the user space tuner, I *have* to use the provided firmware,
which is a separate thing.

	To sum up: if it was not Markus, I never could use my device.
So I hope Linus reconsiders his position, because otherwise who knows
when I can use my device? As far as i know, Markus is the only
programmer working on this.

	It doesn't make sense to reject a code that surely works very
well and leave users waiting forever... because companies won't help...

	And it must be made clear: all Markus' code is completely open
source, GPL etc:

http://mcentral.de/wiki/index.php/Userspace_tuner

	The V4l project is very slow. When i bought my device maybe a
year ago, I read about the cx88 support... and it's the same way... it
didn't evolve at all... it seems that nobody cares... so when someone
really does the job, why it's rejected? It's non sense. Linux supports
few devices and I don't think valuable code should be rejected this way.

-- 
Linux 2.6.23: Arr Matey! A Hairy Bilge Rat!
http://www.lastfm.pt/user/danielfraga
http://u-br.net

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