Re: rtl2832u support
Could the tree from http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2 which is really just an older version of the same code, go into staging than as well ? For that one, I have the signoff by RealTek already. Mauro Carvalho Chehab wrote: Em 20-11-2010 20:37, Maxim Levitsky escreveu: 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). Yes, if people is interested on later fixing the issues. As Antti said he already broke the driver into more consistent parts, maybe his tree may be an start. I would like to volunteer to clean up the driver for eventual merge. At least I can start right away with low handing fruit. Ok, Seems fine for me. 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. The better would be to try to sync with Realtek to be sure that they'll continue to develop the upstream driver, after having it merged. Otherwise, someone will need to do the manual sync, and this can be very painful. 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). Just send the patches. The better is to submit them via linux-media, and say, at a TODO file, that patches for it should be submitted to linux-me...@vger.kernel.org. Something similar to drivers/staging/tm6000/TODO. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
On Mon, 2010-12-06 at 16:45 +0100, Jan Hoogenraad wrote: Could the tree from http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2 which is really just an older version of the same code, go into staging than as well ? Yes, but the problem is that due to shaddy license status of the 'windows' driver, I am afraid to look seriously at it. Up till now, I only experimented with IR code. Jan, since you have contacts with Realtek, maybe it would be possible to get datasheet for their hardware? And the above code is guaraneed not to work on my card because even their 'windows' driver v1.4 doesn't work here. Only 2.0 driver works. And you said that you couldn't seperate demod from bridge? Is that nessesary? I have seen few drivers that don't separate it in v4l source. Tuners are of course another story. Best regards, Maxim Levitsky For that one, I have the signoff by RealTek already. Mauro Carvalho Chehab wrote: Em 20-11-2010 20:37, Maxim Levitsky escreveu: 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). Yes, if people is interested on later fixing the issues. As Antti said he already broke the driver into more consistent parts, maybe his tree may be an start. I would like to volunteer to clean up the driver for eventual merge. At least I can start right away with low handing fruit. Ok, Seems fine for me. 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. The better would be to try to sync with Realtek to be sure that they'll continue to develop the upstream driver, after having it merged. Otherwise, someone will need to do the manual sync, and this can be very painful. 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). Just send the patches. The better is to submit them via linux-media, and say, at a TODO file, that patches for it should be submitted to linux-me...@vger.kernel.org. Something similar to drivers/staging/tm6000/TODO. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
I haven't seen any data sheets. At the other hand, Antti was able to create a separated (tuner vs demod) driver, except for IR. http://linuxtv.org/hg/~anttip/rtl2831u/ http://linuxtv.org/hg/~anttip/qt1010/ I haven't seen a data sheet, but I doubt if it would be of more use than using this example code. My mail contacts (latest in may 2008) focused on getting the code to work and on signing off the code. I'll give my mail contact a try, especially if you have questions that cannot be found in the current code base. Maxim Levitsky wrote: On Mon, 2010-12-06 at 16:45 +0100, Jan Hoogenraad wrote: Could the tree from http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2 which is really just an older version of the same code, go into staging than as well ? Yes, but the problem is that due to shaddy license status of the 'windows' driver, I am afraid to look seriously at it. Up till now, I only experimented with IR code. Jan, since you have contacts with Realtek, maybe it would be possible to get datasheet for their hardware? And the above code is guaraneed not to work on my card because even their 'windows' driver v1.4 doesn't work here. Only 2.0 driver works. And you said that you couldn't seperate demod from bridge? Is that nessesary? I have seen few drivers that don't separate it in v4l source. Tuners are of course another story. Best regards, Maxim Levitsky For that one, I have the signoff by RealTek already. Mauro Carvalho Chehab wrote: Em 20-11-2010 20:37, Maxim Levitsky escreveu: 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). Yes, if people is interested on later fixing the issues. As Antti said he already broke the driver into more consistent parts, maybe his tree may be an start. I would like to volunteer to clean up the driver for eventual merge. At least I can start right away with low handing fruit. Ok, Seems fine for me. 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. The better would be to try to sync with Realtek to be sure that they'll continue to develop the upstream driver, after having it merged. Otherwise, someone will need to do the manual sync, and this can be very painful. 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). Just send the patches. The better is to submit them via linux-media, and say, at a TODO file, that patches for it should be submitted to linux-me...@vger.kernel.org. Something similar to drivers/staging/tm6000/TODO. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
On Mon, Dec 6, 2010 at 4:29 PM, Jan Hoogenraad jan-conceptro...@hoogenraad.net wrote: I haven't seen any data sheets. At the other hand, Antti was able to create a separated (tuner vs demod) driver, except for IR. http://linuxtv.org/hg/~anttip/rtl2831u/ http://linuxtv.org/hg/~anttip/qt1010/ I haven't seen a data sheet, but I doubt if it would be of more use than using this example code. My mail contacts (latest in may 2008) focused on getting the code to work and on signing off the code. I'll give my mail contact a try, especially if you have questions that cannot be found in the current code base. FWIW, in my experience, working code is preferable to datasheets if you have to pick. Often times datasheets are produced pre-silicon and aren't always updated properly with the final changes. Alex Maxim Levitsky wrote: On Mon, 2010-12-06 at 16:45 +0100, Jan Hoogenraad wrote: Could the tree from http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2 which is really just an older version of the same code, go into staging than as well ? Yes, but the problem is that due to shaddy license status of the 'windows' driver, I am afraid to look seriously at it. Up till now, I only experimented with IR code. Jan, since you have contacts with Realtek, maybe it would be possible to get datasheet for their hardware? And the above code is guaraneed not to work on my card because even their 'windows' driver v1.4 doesn't work here. Only 2.0 driver works. And you said that you couldn't seperate demod from bridge? Is that nessesary? I have seen few drivers that don't separate it in v4l source. Tuners are of course another story. Best regards, Maxim Levitsky For that one, I have the signoff by RealTek already. Mauro Carvalho Chehab wrote: Em 20-11-2010 20:37, Maxim Levitsky escreveu: 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). Yes, if people is interested on later fixing the issues. As Antti said he already broke the driver into more consistent parts, maybe his tree may be an start. I would like to volunteer to clean up the driver for eventual merge. At least I can start right away with low handing fruit. Ok, Seems fine for me. 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. The better would be to try to sync with Realtek to be sure that they'll continue to develop the upstream driver, after having it merged. Otherwise, someone will need to do the manual sync, and this can be very painful. 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). Just send the patches. The better is to submit them via linux-media, and say, at a TODO file, that patches for it should be submitted to linux-me...@vger.kernel.org. Something similar to drivers/staging/tm6000/TODO. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
On Mon, 2010-12-06 at 16:43 -0500, Alex Deucher wrote: On Mon, Dec 6, 2010 at 4:29 PM, Jan Hoogenraad jan-conceptro...@hoogenraad.net wrote: I haven't seen any data sheets. At the other hand, Antti was able to create a separated (tuner vs demod) driver, except for IR. http://linuxtv.org/hg/~anttip/rtl2831u/ http://linuxtv.org/hg/~anttip/qt1010/ I haven't seen a data sheet, but I doubt if it would be of more use than using this example code. My mail contacts (latest in may 2008) focused on getting the code to work and on signing off the code. I'll give my mail contact a try, especially if you have questions that cannot be found in the current code base. FWIW, in my experience, working code is preferable to datasheets if you have to pick. Often times datasheets are produced pre-silicon and aren't always updated properly with the final changes. I completely agree with that. however I miss few things in IR code (it works with protocols the driver in-house decoding supports but fails for others.) And few other things. Sure like I said, I can manage without them. But if I had datasheets in addition to working code, it would be better. Best regards, Maxim Levitsky Alex Maxim Levitsky wrote: On Mon, 2010-12-06 at 16:45 +0100, Jan Hoogenraad wrote: Could the tree from http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2 which is really just an older version of the same code, go into staging than as well ? Yes, but the problem is that due to shaddy license status of the 'windows' driver, I am afraid to look seriously at it. Up till now, I only experimented with IR code. Jan, since you have contacts with Realtek, maybe it would be possible to get datasheet for their hardware? And the above code is guaraneed not to work on my card because even their 'windows' driver v1.4 doesn't work here. Only 2.0 driver works. And you said that you couldn't seperate demod from bridge? Is that nessesary? I have seen few drivers that don't separate it in v4l source. Tuners are of course another story. Best regards, Maxim Levitsky For that one, I have the signoff by RealTek already. Mauro Carvalho Chehab wrote: Em 20-11-2010 20:37, Maxim Levitsky escreveu: 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). Yes, if people is interested on later fixing the issues. As Antti said he already broke the driver into more consistent parts, maybe his tree may be an start. I would like to volunteer to clean up the driver for eventual merge. At least I can start right away with low handing fruit. Ok, Seems fine for me. 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. The better would be to try to sync with Realtek to be sure that they'll continue to develop the upstream driver, after having it merged. Otherwise, someone will need to do the manual sync, and this can be very painful. 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). Just send the patches. The better is to submit them via linux-media, and say, at a TODO file, that patches for it should be submitted to linux-me...@vger.kernel.org. Something similar to drivers/staging/tm6000/TODO. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
On Sun, 2010-11-21 at 00:37 +0200, Maxim Levitsky wrote: 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.mar...@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 Anybody? Best regards Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
Em 20-11-2010 20:37, Maxim Levitsky escreveu: 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). Yes, if people is interested on later fixing the issues. As Antti said he already broke the driver into more consistent parts, maybe his tree may be an start. I would like to volunteer to clean up the driver for eventual merge. At least I can start right away with low handing fruit. Ok, Seems fine for me. 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. The better would be to try to sync with Realtek to be sure that they'll continue to develop the upstream driver, after having it merged. Otherwise, someone will need to do the manual sync, and this can be very painful. 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). Just send the patches. The better is to submit them via linux-media, and say, at a TODO file, that patches for it should be submitted to linux-me...@vger.kernel.org. Something similar to drivers/staging/tm6000/TODO. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
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.mar...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
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.mar...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
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.mar...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
On Tuesday, October 19, 2010 23:28:49 Devin Heitmueller wrote: On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil hverk...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
rtl2832u support
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-- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
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? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
On Tuesday, October 19, 2010 21:26:13 Devin Heitmueller wrote: On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion damjan.mar...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil hverk...@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.mar...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil hverk...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
