Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
On Tue, Aug 18, 2009 at 10:07:04AM -0400, Devin Heitmueller wrote: The risk of trusting some random Linux developer's driver work is a reason why some vendors don't want to support Linux. If I were a vendor, and I endorsed a Linux driver written by someone without the appropriate knowledge of the hardware, I could end up with large number of product returns, and I would incur the cost of those losses. This is an interesting statement. Let me rephrase it: If I were a vendor selling ill-designed hardware which can be permanently damaged by buggy software, I'd make sure as hell that I get the information about how to avoid the damage out to every Open Source developer. Otherwise I would have to live with the risk of seeing an increased rate of product returns. BTW, there is a big difference of after I plugged the device in under Linux it was dead and it runs hot under Linux, that might shorten the life span. I hope there is no hardware of the first kind. For the second kind you can fairly safely experiment until you solved the problem. Thanks, Johannes -- 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: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
Am Dienstag, den 18.08.2009, 10:07 -0400 schrieb Devin Heitmueller: On Tue, Aug 18, 2009 at 7:00 AM, Johannes Stezenbachj...@linuxtv.org wrote: I would be interested to know if someone _actually_ managed to break their hardware by using buggy drivers. The short answer is *absolutely*. /me takes off driver developer hat and puts on hardware developer hat In a world of flash, eeproms, and software programmable clocks, there are all sorts of ways where a driver bug can damage the hardware. Looking for some simple examples? 1. Think of the overclocking community and what happens when they reconfigure a GPU's software controlled clock to perform beyond its maximum expected rating without extra cooling. 2. Think of all the reports of corrupted eeproms you read about on the mailing list. Sure, in many cases a good developer can hack a way to reprogram the eeprom in software, but in many cases the board won't even come up, so you end up with an RMA. It's not damaged in the more traditional sense, but the net effect is the same - the board is rendered inoperable and has to be sent back to the manufacturer. 3. Try loading the xc3028 tuner firmware onto the low power version of the chip (xc3028l). It took me a minute before I realized the smell of burning plastic was coming from my tuner. Don't get me wrong, in many cases things can be designed into the hardware to mitigate the effects of software bugs. In any hardware design, your goal is to minimize the return rate, so you build failsafes for the most likely to occur problems. However, in many cases this adds additional cost to the BOM, and you make educated decisions about the probability of certain classes of failure and instead build the reliability into the driver instead (making sure that the Windows driver can *never* put the hardware into a state). A random open source developer doesn't know what these sorts of decisions were, and would not be able to replicate the corresponding checks in a Linux driver. 4. Ever see a user complaint of how a tuner runs hot under Linux compared to the same device running under Windows? Almost certainly an improperly GPIO configuration which resulted in a condition such as having the digital demod powered on at the same time as the analog decoder. Sure, it will work for a while but you're running the device outside of the expected thermal profile and shortening the life of the hardware. The above are just a few *simple* examples. The nastier ones are often too difficult to explain in less than fifty words. IANAL but I think that consumer electronics hardware which can be damaged by software is broken by design. A vendor selling such hardware is stupid because people would return the broken hardware and get a replacement. I don't see how a vendor could proof that the device was not damaged by an obscure bug in the Windows driver to get around their responsibility to replace broken hardware within the warranty period. Yeah, you're right. Usually they cannot tell right away and will perform an RMA. And the board will end up on a lab bench with a hardware engineering isolating which component failed, and then working with the driver developer trying to figure out how the hell their Windows driver put the board in such a state. The risk of trusting some random Linux developer's driver work is a reason why some vendors don't want to support Linux. If I were a vendor, and I endorsed a Linux driver written by someone without the appropriate knowledge of the hardware, I could end up with large number of product returns, and I would incur the cost of those losses. Also, in many cases the board doesn't burn out immediately. But because of crappy drivers it takes three or four months to burn out, and the result is a board that is designed to run without problems for tens of thousands of hours dies in a significantly shorter time. Good device driver developers realize and accept this risk whenever they attempt to write a reverse engineered driver. I certainly don't want to discourage people from learning how to write Linux drivers for tuners, but caveat emptor - you can end up permanently damaging your hardware. Devin Hi, again, both can be right. I don't deny the smell you had, what a crap on the other hand. But Johannes is right too. I did not manage to burn a single Philips device during the last seven years. And i did all the worst every single day ;) So, there might be still a slight difference ... Cheers, Hermann -- 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: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
On Mon, Aug 17, 2009 at 04:59:42PM -0400, Michael Krufky wrote: variations, nobody has ever verified that the GPIO programming is safe to use, and there is no way to prevent the potentially harmful code from running on the wrong device. I, personally, do not want the responsibility of explaining to users that their usb sticks may be damaged because of code that got merged I would be interested to know if someone _actually_ managed to break their hardware by using buggy drivers. IANAL but I think that consumer electronics hardware which can be damaged by software is broken by design. A vendor selling such hardware is stupid because people would return the broken hardware and get a replacement. I don't see how a vendor could proof that the device was not damaged by an obscure bug in the Windows driver to get around their responsibility to replace broken hardware within the warranty period. Johannes -- 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: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
On Tue, Aug 18, 2009 at 7:00 AM, Johannes Stezenbachj...@linuxtv.org wrote: I would be interested to know if someone _actually_ managed to break their hardware by using buggy drivers. The short answer is *absolutely*. /me takes off driver developer hat and puts on hardware developer hat In a world of flash, eeproms, and software programmable clocks, there are all sorts of ways where a driver bug can damage the hardware. Looking for some simple examples? 1. Think of the overclocking community and what happens when they reconfigure a GPU's software controlled clock to perform beyond its maximum expected rating without extra cooling. 2. Think of all the reports of corrupted eeproms you read about on the mailing list. Sure, in many cases a good developer can hack a way to reprogram the eeprom in software, but in many cases the board won't even come up, so you end up with an RMA. It's not damaged in the more traditional sense, but the net effect is the same - the board is rendered inoperable and has to be sent back to the manufacturer. 3. Try loading the xc3028 tuner firmware onto the low power version of the chip (xc3028l). It took me a minute before I realized the smell of burning plastic was coming from my tuner. Don't get me wrong, in many cases things can be designed into the hardware to mitigate the effects of software bugs. In any hardware design, your goal is to minimize the return rate, so you build failsafes for the most likely to occur problems. However, in many cases this adds additional cost to the BOM, and you make educated decisions about the probability of certain classes of failure and instead build the reliability into the driver instead (making sure that the Windows driver can *never* put the hardware into a state). A random open source developer doesn't know what these sorts of decisions were, and would not be able to replicate the corresponding checks in a Linux driver. 4. Ever see a user complaint of how a tuner runs hot under Linux compared to the same device running under Windows? Almost certainly an improperly GPIO configuration which resulted in a condition such as having the digital demod powered on at the same time as the analog decoder. Sure, it will work for a while but you're running the device outside of the expected thermal profile and shortening the life of the hardware. The above are just a few *simple* examples. The nastier ones are often too difficult to explain in less than fifty words. IANAL but I think that consumer electronics hardware which can be damaged by software is broken by design. A vendor selling such hardware is stupid because people would return the broken hardware and get a replacement. I don't see how a vendor could proof that the device was not damaged by an obscure bug in the Windows driver to get around their responsibility to replace broken hardware within the warranty period. Yeah, you're right. Usually they cannot tell right away and will perform an RMA. And the board will end up on a lab bench with a hardware engineering isolating which component failed, and then working with the driver developer trying to figure out how the hell their Windows driver put the board in such a state. The risk of trusting some random Linux developer's driver work is a reason why some vendors don't want to support Linux. If I were a vendor, and I endorsed a Linux driver written by someone without the appropriate knowledge of the hardware, I could end up with large number of product returns, and I would incur the cost of those losses. Also, in many cases the board doesn't burn out immediately. But because of crappy drivers it takes three or four months to burn out, and the result is a board that is designed to run without problems for tens of thousands of hours dies in a significantly shorter time. Good device driver developers realize and accept this risk whenever they attempt to write a reverse engineered driver. I certainly don't want to discourage people from learning how to write Linux drivers for tuners, but caveat emptor - you can end up permanently damaging your hardware. 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
Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
On Mon, Aug 17, 2009 at 4:25 PM, Malcolm Lewiscoyoteu...@gmail.com wrote:
Hi
I've been using the patches from
http://linuxtv.org/hg/~mkrufky/teledongle/rev/676e2f4475ed
on a Sabrent device in openSuSE and SLED, during testing with the
milestone 5 release of
11.2 and kernel version 2.6.31-rc5-git3-2-desktop there needs to be
some changes to the
au0828-cards.c patch to enable building a kmp module;
--- au0828-cards.c 2009-08-12 18:16:39.435886920 -0500
+++ au0828-cards.c.orig 2009-08-12 18:28:22.176126368 -0500
@@ -116,6 +116,12 @@
.tuner_addr = ADDR_UNSET,
.i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
},
+ [AU0828_BOARD_SYNTEK_TELEDONGLE] = {
+ .name = Syntek Teledongle [EXPERIMENTAL],
+ .tuner_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
+ },
};
/* Tuner callback function for au0828 boards. Currently only needed
@@ -248,6 +254,7 @@
case AU0828_BOARD_HAUPPAUGE_HVR950Q:
case AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL:
case AU0828_BOARD_HAUPPAUGE_WOODBURY:
+ case AU0828_BOARD_SYNTEK_TELEDONGLE: /* FIXME */
/* GPIO's
* 4 - CS5340
* 5 - AU8522 Demodulator
@@ -325,6 +332,8 @@
.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
{ USB_DEVICE(0x2040, 0x8200),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
+ { USB_DEVICE(0x05e1, 0x0400),
+ .driver_info = AU0828_BOARD_SYNTEK_TELEDONGLE },
{ },
};
There are two versions I'm building and src for both can be found here;
http://download.opensuse.org/repositories/home:/malcolmlewis/
Malcolm,
I would strongly advise against distributing packages based on these
patches... This code was never merged into the master branch because
it has potential to break devices at the hardware level, and it will
create a support nightmare, based on the fact that there are multiple
UNLIKE devices that use the same USB ID but actually contain different
hardware components. As the patch may enable support for ONE of the
variations, nobody has ever verified that the GPIO programming is safe
to use, and there is no way to prevent the potentially harmful code
from running on the wrong device.
I, personally, do not want the responsibility of explaining to users
that their usb sticks may be damaged because of code that got merged
into the kernel -- that's why the code is in a separate repository
until the issues can be dealt with. In general, users know that if
they have to manually apply patches themselves, that they are doing so
at their own risk.
If you succeed in getting your device to work, please let me know -- I
will be very interested to hear about it.
Good Luck,
Mike
--
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: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
On Mon, Aug 17, 2009 at 3:59 PM, Michael Krufkymkru...@kernellabs.com wrote:
On Mon, Aug 17, 2009 at 4:25 PM, Malcolm Lewiscoyoteu...@gmail.com wrote:
Hi
I've been using the patches from
http://linuxtv.org/hg/~mkrufky/teledongle/rev/676e2f4475ed
on a Sabrent device in openSuSE and SLED, during testing with the
milestone 5 release of
11.2 and kernel version 2.6.31-rc5-git3-2-desktop there needs to be
some changes to the
au0828-cards.c patch to enable building a kmp module;
--- au0828-cards.c 2009-08-12 18:16:39.435886920 -0500
+++ au0828-cards.c.orig 2009-08-12 18:28:22.176126368 -0500
@@ -116,6 +116,12 @@
.tuner_addr = ADDR_UNSET,
.i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
},
+ [AU0828_BOARD_SYNTEK_TELEDONGLE] = {
+ .name = Syntek Teledongle [EXPERIMENTAL],
+ .tuner_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
+ },
};
/* Tuner callback function for au0828 boards. Currently only needed
@@ -248,6 +254,7 @@
case AU0828_BOARD_HAUPPAUGE_HVR950Q:
case AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL:
case AU0828_BOARD_HAUPPAUGE_WOODBURY:
+ case AU0828_BOARD_SYNTEK_TELEDONGLE: /* FIXME */
/* GPIO's
* 4 - CS5340
* 5 - AU8522 Demodulator
@@ -325,6 +332,8 @@
.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
{ USB_DEVICE(0x2040, 0x8200),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
+ { USB_DEVICE(0x05e1, 0x0400),
+ .driver_info = AU0828_BOARD_SYNTEK_TELEDONGLE },
{ },
};
There are two versions I'm building and src for both can be found here;
http://download.opensuse.org/repositories/home:/malcolmlewis/
Malcolm,
I would strongly advise against distributing packages based on these
patches... This code was never merged into the master branch because
it has potential to break devices at the hardware level, and it will
create a support nightmare, based on the fact that there are multiple
UNLIKE devices that use the same USB ID but actually contain different
hardware components. As the patch may enable support for ONE of the
variations, nobody has ever verified that the GPIO programming is safe
to use, and there is no way to prevent the potentially harmful code
from running on the wrong device.
I, personally, do not want the responsibility of explaining to users
that their usb sticks may be damaged because of code that got merged
into the kernel -- that's why the code is in a separate repository
until the issues can be dealt with. In general, users know that if
they have to manually apply patches themselves, that they are doing so
at their own risk.
If you succeed in getting your device to work, please let me know -- I
will be very interested to hear about it.
Good Luck,
Mike
___
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-...@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Hi Mike
Ahh, OK :) I can confirm I've had no issues using it with smplayer on
openSuSE 11.0, openSuSE 11.1 and openSuSE 11.2 M5 i586 (ViA Artigo and
ASUS 1000HE) and SLED 11 x86_64 (home build AMD 4400 X2 system).
System tunes into FTA HDTV great, have scan in different areas and all
scanned channels found have worked. (I'm in Mississippi)
I'm happy to do further testing if you can advise on what is required.
--
Cheers
Malcolm
--
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
