rtl2832u support

rtl2832u support

[Damjan Marion]

Hi,

Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb?

Realtek published source code under GPL:

MODULE_AUTHOR("Realtek");
MODULE_DESCRIPTION("Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device");
MODULE_VERSION("1.4.2");
MODULE_LICENSE("GPL");

Thanks,

Damjan

Re: rtl2832u support

[Antti Palosaari]

On 10/19/2010 08:42 PM, Damjan Marion wrote:
> Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb?

It is due to lack of developer making driver suitable for Kernel. I have 
done some work and have knowledge what is needed, but no time nor 
interest enough currently. It should be implement as one USB-interface 
driver and two demod drivers (RTL2830, RTL2832) to support for both 
RTL2831U and RTL2832U.

Antti
-- 
http://palosaari.fi/

Re: rtl2832u support

[Damjan Marion]

On Oct 19, 2010, at 9:10 PM, Antti Palosaari wrote:
> On 10/19/2010 08:42 PM, Damjan Marion wrote:
>> Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb?
> 
> It is due to lack of developer making driver suitable for Kernel. I have done some work and have knowledge what is needed, but no time nor interest enough currently. It should be implement as one USB-interface driver and two demod drivers (RTL2830, RTL2832) to support for both RTL2831U and RTL2832U.

Can you share what you done so far?

Re: rtl2832u support

[Antti Palosaari]

On 10/19/2010 10:33 PM, Damjan Marion wrote:
>
> On Oct 19, 2010, at 9:10 PM, Antti Palosaari wrote:
>> On 10/19/2010 08:42 PM, Damjan Marion wrote:
>>> Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb?
>>
>> It is due to lack of developer making driver suitable for Kernel. I have done some work and have knowledge what is needed, but no time nor interest enough currently. It should be implement as one USB-interface driver and two demod drivers (RTL2830, RTL2832) to support for both RTL2831U and RTL2832U.
>
> Can you share what you done so far?

Look LinuxTV.org HG trees. There is Jan and my trees, both for RTL2831U. 
I split driver logically correct parts. Also I have some RTL2832U hacks 
here in my computer, I can give those for the person really continuing 
development.

Antti

-- 
http://palosaari.fi/

Re: rtl2832u support

[poma]

Antti Palosaari wrote:
> On 10/19/2010 10:33 PM, Damjan Marion wrote:
>>
>> On Oct 19, 2010, at 9:10 PM, Antti Palosaari wrote:
>>> On 10/19/2010 08:42 PM, Damjan Marion wrote:
>>>> Is there any special reason why driver for rtl2832u DVB-T receiver 
>>>> chipset is not included into v4l-dvb?
>>>
>>> It is due to lack of developer making driver suitable for Kernel. I 
>>> have done some work and have knowledge what is needed, but no time 
>>> nor interest enough currently. It should be implement as one 
>>> USB-interface driver and two demod drivers (RTL2830, RTL2832) to 
>>> support for both RTL2831U and RTL2832U.
>>
>> Can you share what you done so far?
> 
> Look LinuxTV.org HG trees. There is Jan and my trees, both for RTL2831U. 
> I split driver logically correct parts. Also I have some RTL2832U hacks 
> here in my computer, I can give those for the person really continuing 
> development.
> 
> Antti
> 

Hi there,

Jack, is Realtek Interested?

Kind regards,
poma

Re: rtl2832u support

[Devin Heitmueller]

On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion <damjan.marion@gmail.com> wrote:
>
> Hi,
>
> Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb?
>
> Realtek published source code under GPL:
>
> MODULE_AUTHOR("Realtek");
> MODULE_DESCRIPTION("Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device");
> MODULE_VERSION("1.4.2");
> MODULE_LICENSE("GPL");

Unfortunately, in most cases much more is "required" than having a
working driver under the GPL in order for it to be accepted upstream.
In some cases it can mean a developer spending a few hours cleaning up
whitespace and indentation, and in other cases it means significant
work to the driver is required.

The position the LinuxTV team has taken is that they would rather have
no upstream driver at all than to have a driver which doesn't have the
right indentation or other aesthetic problems which has no bearing on
how well the driver actually works.

This is one of the big reasons KernelLabs has tens of thousands of
lines of code adding support for a variety of devices with many happy
users (who are willing to go through the trouble to compile from
source), but the code cannot be accepted upstream.  I just cannot find
the time to do the "idiot work".

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: rtl2832u support

[Hans Verkuil]

On Tuesday, October 19, 2010 21:26:13 Devin Heitmueller wrote:
> On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion <damjan.marion@gmail.com> wrote:
> >
> > Hi,
> >
> > Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb?
> >
> > Realtek published source code under GPL:
> >
> > MODULE_AUTHOR("Realtek");
> > MODULE_DESCRIPTION("Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device");
> > MODULE_VERSION("1.4.2");
> > MODULE_LICENSE("GPL");
> 
> Unfortunately, in most cases much more is "required" than having a
> working driver under the GPL in order for it to be accepted upstream.
> In some cases it can mean a developer spending a few hours cleaning up
> whitespace and indentation, and in other cases it means significant
> work to the driver is required.
> 
> The position the LinuxTV team has taken is that they would rather have
> no upstream driver at all than to have a driver which doesn't have the
> right indentation or other aesthetic problems which has no bearing on
> how well the driver actually works.
> 
> This is one of the big reasons KernelLabs has tens of thousands of
> lines of code adding support for a variety of devices with many happy
> users (who are willing to go through the trouble to compile from
> source), but the code cannot be accepted upstream.  I just cannot find
> the time to do the "idiot work".

Bullshit. First of all these rules are those of the kernel community
as a whole and *not* linuxtv as such, and secondly you can upstream such
drivers in the staging tree. If you want to move it out of staging, then
it will take indeed more work since the quality requirements are higher
there.

Them's the rules for kernel development.

I've done my share of coding style cleanups. I never understand why people
dislike doing that. In my experience it always greatly improves the code
(i.e. I can actually understand it) and it tends to highlight the remaining
problematic areas in the driver.

Of course, I can also rant for several paragraphs about companies throwing
code over the wall without bothering to actually do the remaining work to
get it mainlined. The very least they can do is to sponsor someone to do the
work for them.

But I'll spare you that :-)

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

Re: rtl2832u support

[Alex Deucher]

On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On Tuesday, October 19, 2010 21:26:13 Devin Heitmueller wrote:
>> On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion <damjan.marion@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb?
>> >
>> > Realtek published source code under GPL:
>> >
>> > MODULE_AUTHOR("Realtek");
>> > MODULE_DESCRIPTION("Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device");
>> > MODULE_VERSION("1.4.2");
>> > MODULE_LICENSE("GPL");
>>
>> Unfortunately, in most cases much more is "required" than having a
>> working driver under the GPL in order for it to be accepted upstream.
>> In some cases it can mean a developer spending a few hours cleaning up
>> whitespace and indentation, and in other cases it means significant
>> work to the driver is required.
>>
>> The position the LinuxTV team has taken is that they would rather have
>> no upstream driver at all than to have a driver which doesn't have the
>> right indentation or other aesthetic problems which has no bearing on
>> how well the driver actually works.
>>
>> This is one of the big reasons KernelLabs has tens of thousands of
>> lines of code adding support for a variety of devices with many happy
>> users (who are willing to go through the trouble to compile from
>> source), but the code cannot be accepted upstream.  I just cannot find
>> the time to do the "idiot work".
>
> Bullshit. First of all these rules are those of the kernel community
> as a whole and *not* linuxtv as such, and secondly you can upstream such
> drivers in the staging tree. If you want to move it out of staging, then
> it will take indeed more work since the quality requirements are higher
> there.
>
> Them's the rules for kernel development.
>
> I've done my share of coding style cleanups. I never understand why people
> dislike doing that. In my experience it always greatly improves the code
> (i.e. I can actually understand it) and it tends to highlight the remaining
> problematic areas in the driver.
>
> Of course, I can also rant for several paragraphs about companies throwing
> code over the wall without bothering to actually do the remaining work to
> get it mainlined. The very least they can do is to sponsor someone to do the
> work for them.

To start, I appreciate the kernel coding style requirements.  I think
it makes the code much easier to read and more consistent across the
kernel tree.  But, just to play devil's advocate, it's a fair amount
of work to write a driver especially if the hw is complex.  It's much
easier to share a common codebase between different OSs because to
reduces the maintenance burden and makes it easier to support new asic
variants.  This is especially true if you are a small company with
limited resources.  It annoys me somewhat when IHVs put in the effort
to actually produce a GPLed Linux driver and the community shits on
them for not writing it from scratch to match the kernel style
requirements.  Lets face it, there are a lot of hw specs out there
with no driver.  A working driver with source is vastly more useful.
It would be nice if every company out there had the resources to
develop a nice clean native Linux driver, but right now that's not
always the case.

Alex

Re: rtl2832u support

[Devin Heitmueller]

On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Bullshit.

Not exactly the level of mutual respect for your peers that I would
expect of you, Hans.

> First of all these rules are those of the kernel community
> as a whole and *not* linuxtv as such, and secondly you can upstream such
> drivers in the staging tree. If you want to move it out of staging, then
> it will take indeed more work since the quality requirements are higher
> there.

You are correct - while I indeed say it was the position of the
LinuxTV developers, I didn't intend to single them out from the rest
of the Linux kernel community.  The problem I described is systemic to
working with the Linux kernel community in general.

> Them's the rules for kernel development.
>
> I've done my share of coding style cleanups. I never understand why people
> dislike doing that. In my experience it always greatly improves the code
> (i.e. I can actually understand it) and it tends to highlight the remaining
> problematic areas in the driver.

Because it's additional work.  I agree that *sometimes* it can be
useful.  And yet many times it's a bunch of changes that provide
little actual value and only make it harder to keep the Linux driver
in sync with the upstream source (in many cases, the GPL driver is
derived from some Windows driver or other source).

Alex makes a point that I think it's worth expanding on a bit:

The Linux kernel developers' goals are different than those of the
product/chipset vendor.  The product/chipset vendor typically wants
consistency across operating systems.  This usually involves some sort
of OS portability layer to abstract out the OS specific parts (which
is usually done as a combination of OS specific header files and C
macros).  This reduces the maintenance cost for the author as it makes
it easier to be confident that changes to the core will basically
"just work" on other operating systems.

The Linux kernel developer wants consistency across Linux drivers
regardless of who wrote them.  This makes sense for the Linux kernel
community in that it makes it easier to work on drivers that you
didn't necessarily write.  However it also means that all of the
portability code and macros are seen as "crap which has to be stripped
out".  The net effect is a driver that looks little like the original
platform independent driver, making it easier for the Linux kernel
community to maintain but harder for the original author to provide
updates to.

I can appreciate why the Linux development community chose this route,
but let's not pretend that it doesn't come at a significant cost.
Kind of like how the Git move has resulted in developers who want to
build drivers on a known-stable kernel (as opposed to the bleeding
edge) being treated as second class citizens.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: rtl2832u support

[Hans Verkuil]

On Tuesday, October 19, 2010 23:28:49 Devin Heitmueller wrote:
> On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > Bullshit.
> 
> Not exactly the level of mutual respect for your peers that I would
> expect of you, Hans.

You I right, that could have been phrased more diplomatically. So I'm human
after all :-)

> > First of all these rules are those of the kernel community
> > as a whole and *not* linuxtv as such, and secondly you can upstream such
> > drivers in the staging tree. If you want to move it out of staging, then
> > it will take indeed more work since the quality requirements are higher
> > there.
> 
> You are correct - while I indeed say it was the position of the
> LinuxTV developers, I didn't intend to single them out from the rest
> of the Linux kernel community.  The problem I described is systemic to
> working with the Linux kernel community in general.
> 
> > Them's the rules for kernel development.
> >
> > I've done my share of coding style cleanups. I never understand why people
> > dislike doing that. In my experience it always greatly improves the code
> > (i.e. I can actually understand it) and it tends to highlight the remaining
> > problematic areas in the driver.
> 
> Because it's additional work.  I agree that *sometimes* it can be
> useful.  And yet many times it's a bunch of changes that provide
> little actual value and only make it harder to keep the Linux driver
> in sync with the upstream source (in many cases, the GPL driver is
> derived from some Windows driver or other source).

Yes, it is additional work, but there is a big payout at the end: once the
driver is merged in the mainline, then your maintenance level falls down
to just bug fixing. That is a *huge* cost saving.

I also have to say that in my experience most driver code made this way
(i.e. OS independent) tends to be truly awful code.
 
> Alex makes a point that I think it's worth expanding on a bit:
> 
> The Linux kernel developers' goals are different than those of the
> product/chipset vendor.  The product/chipset vendor typically wants
> consistency across operating systems.  This usually involves some sort
> of OS portability layer to abstract out the OS specific parts (which
> is usually done as a combination of OS specific header files and C
> macros).  This reduces the maintenance cost for the author as it makes
> it easier to be confident that changes to the core will basically
> "just work" on other operating systems.

Been there, done that.
 
> The Linux kernel developer wants consistency across Linux drivers
> regardless of who wrote them.  This makes sense for the Linux kernel
> community in that it makes it easier to work on drivers that you
> didn't necessarily write.  However it also means that all of the
> portability code and macros are seen as "crap which has to be stripped
> out".  The net effect is a driver that looks little like the original
> platform independent driver, making it easier for the Linux kernel
> community to maintain but harder for the original author to provide
> updates to.

Ah, and there is the crucial phrase: "making it easier for the Linux kernel
community to maintain". That's the pay-off: once it is in you no longer have
to care about maintaining it besides bug fixes. The maintenance level of
out-of-tree drivers seems quite low in the beginning but over time it can
skyrocket. Particularly in a subsystem like v4l which is undergoing a lot
of change.

> I can appreciate why the Linux development community chose this route,
> but let's not pretend that it doesn't come at a significant cost.

It's the difference between 'high initial cost, low or no cost afterwards'
and 'low initial cost, ever increasing cost afterwards'. In my experience,
the first option has always a (much) lower total cost compared to the
second option. Not to mention a much higher code quality. But it can be
very hard to convince companies of that, particularly when they just start
out doing linux work.

A special case is when the hardware needs to support a new feature for which
a new public API is needed. There the initial cost can be very high indeed.

For small companies that can be prohibitive. I have no real solution for this
at the moment. But it does make me appreciate companies like TI, Samsung and
Nokia who are willing to take the long road, hopefully with a big payout at
the end.

> Kind of like how the Git move has resulted in developers who want to
> build drivers on a known-stable kernel (as opposed to the bleeding
> edge) being treated as second class citizens.

That's a typical example of having limited resources. I also would like to
see better support for building against stable kernels (and I have to test
Mauro's new approach one of these days), but there is only so much time
(and money) available.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

Re: rtl2832u support

[Damjan Marion]

On Oct 19, 2010, at 10:27 PM, Hans Verkuil wrote:
> On Tuesday, October 19, 2010 21:26:13 Devin Heitmueller wrote:
>> On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion <damjan.marion@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb?
>>> 
>>> Realtek published source code under GPL:
>>> 
>>> MODULE_AUTHOR("Realtek");
>>> MODULE_DESCRIPTION("Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device");
>>> MODULE_VERSION("1.4.2");
>>> MODULE_LICENSE("GPL");
>> 
>> Unfortunately, in most cases much more is "required" than having a
>> working driver under the GPL in order for it to be accepted upstream.
>> In some cases it can mean a developer spending a few hours cleaning up
>> whitespace and indentation, and in other cases it means significant
>> work to the driver is required.
>> 
>> The position the LinuxTV team has taken is that they would rather have
>> no upstream driver at all than to have a driver which doesn't have the
>> right indentation or other aesthetic problems which has no bearing on
>> how well the driver actually works.
>> 
>> This is one of the big reasons KernelLabs has tens of thousands of
>> lines of code adding support for a variety of devices with many happy
>> users (who are willing to go through the trouble to compile from
>> source), but the code cannot be accepted upstream.  I just cannot find
>> the time to do the "idiot work".
> 
> Bullshit. First of all these rules are those of the kernel community
> as a whole and *not* linuxtv as such, and secondly you can upstream such
> drivers in the staging tree. If you want to move it out of staging, then
> it will take indeed more work since the quality requirements are higher
> there.


Do we have a common agreement that this driver can go to staging as-is?

If yes, I have patch ready, just need to know where to send it (It is around 1 MB).

Regards,

Damjan

Re: rtl2832u support

[Maxim Levitsky]

On Wed, 2010-11-17 at 12:15 +0100, Damjan Marion wrote:
> On Oct 19, 2010, at 10:27 PM, Hans Verkuil wrote:
> > On Tuesday, October 19, 2010 21:26:13 Devin Heitmueller wrote:
> >> On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion <damjan.marion@gmail.com> wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb?
> >>> 
> >>> Realtek published source code under GPL:
> >>> 
> >>> MODULE_AUTHOR("Realtek");
> >>> MODULE_DESCRIPTION("Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device");
> >>> MODULE_VERSION("1.4.2");
> >>> MODULE_LICENSE("GPL");
> >> 
> >> Unfortunately, in most cases much more is "required" than having a
> >> working driver under the GPL in order for it to be accepted upstream.
> >> In some cases it can mean a developer spending a few hours cleaning up
> >> whitespace and indentation, and in other cases it means significant
> >> work to the driver is required.
> >> 
> >> The position the LinuxTV team has taken is that they would rather have
> >> no upstream driver at all than to have a driver which doesn't have the
> >> right indentation or other aesthetic problems which has no bearing on
> >> how well the driver actually works.
> >> 
> >> This is one of the big reasons KernelLabs has tens of thousands of
> >> lines of code adding support for a variety of devices with many happy
> >> users (who are willing to go through the trouble to compile from
> >> source), but the code cannot be accepted upstream.  I just cannot find
> >> the time to do the "idiot work".
> > 
> > Bullshit. First of all these rules are those of the kernel community
> > as a whole and *not* linuxtv as such, and secondly you can upstream such
> > drivers in the staging tree. If you want to move it out of staging, then
> > it will take indeed more work since the quality requirements are higher
> > there.
> 
> 
> Do we have a common agreement that this driver can go to staging as-is?
> 
> If yes, I have patch ready, just need to know where to send it (It is around 1 MB).

I also bought that device few days ago.
Needless to say it works perfectly (better that in windows) with this
driver.

Best regards,
	Maxim Levitsky

Re: rtl2832u support

[Maxim Levitsky]

On Fri, 2010-11-19 at 09:36 +0200, Maxim Levitsky wrote:
> On Wed, 2010-11-17 at 12:15 +0100, Damjan Marion wrote:
> > On Oct 19, 2010, at 10:27 PM, Hans Verkuil wrote:
> > > On Tuesday, October 19, 2010 21:26:13 Devin Heitmueller wrote:
> > >> On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion <damjan.marion@gmail.com> wrote:
> > >>> 
> > >>> Hi,
> > >>> 
> > >>> Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb?
> > >>> 
> > >>> Realtek published source code under GPL:
> > >>> 
> > >>> MODULE_AUTHOR("Realtek");
> > >>> MODULE_DESCRIPTION("Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device");
> > >>> MODULE_VERSION("1.4.2");
> > >>> MODULE_LICENSE("GPL");
> > >> 
> > >> Unfortunately, in most cases much more is "required" than having a
> > >> working driver under the GPL in order for it to be accepted upstream.
> > >> In some cases it can mean a developer spending a few hours cleaning up
> > >> whitespace and indentation, and in other cases it means significant
> > >> work to the driver is required.
> > >> 
> > >> The position the LinuxTV team has taken is that they would rather have
> > >> no upstream driver at all than to have a driver which doesn't have the
> > >> right indentation or other aesthetic problems which has no bearing on
> > >> how well the driver actually works.
> > >> 
> > >> This is one of the big reasons KernelLabs has tens of thousands of
> > >> lines of code adding support for a variety of devices with many happy
> > >> users (who are willing to go through the trouble to compile from
> > >> source), but the code cannot be accepted upstream.  I just cannot find
> > >> the time to do the "idiot work".
> > > 
> > > Bullshit. First of all these rules are those of the kernel community
> > > as a whole and *not* linuxtv as such, and secondly you can upstream such
> > > drivers in the staging tree. If you want to move it out of staging, then
> > > it will take indeed more work since the quality requirements are higher
> > > there.
> > 
> > 
> > Do we have a common agreement that this driver can go to staging as-is?
> > 
> > If yes, I have patch ready, just need to know where to send it (It is around 1 MB).

I would like to volunteer to clean up the driver for eventual merge.
At least I can start right away with low handing fruit.

I have took the driver from

http://www.turnovfree.net/~stybla/linux/v4l-dvb/lv5tdlx/20101102_RTL2832_2836_2840_LINUX+RC-Dongle.rar


And it looks very recent, so that means that Realtek actually continues
to develop it.

Greg KH, maybe you know how to contact Realteck to figure out the best
strategy in handling this code.

Meanwhile, lets put that into staging.
(The above driver doesn't compile due to changes in RC code, but it can
be removed (that what I did for now) or ported to new rc-core which what
I will do very soon).

Best regards,
	Maxim Levitsky