Re: [PATCH] [media] em28xx: support for Sundtek MediaTV Digital Home
On Sat, May 6, 2017 at 3:50 AM, Thomas Hollstegge <thomas.hollste...@gmail.com> wrote: > Hi Markus, > > Markus Rechberger <mrechber...@gmail.com> schrieb am Sat, 06. May 00:33: >> We had different HW designs based on Empia until 2012 using this USB >> ID it will not work with many units out there, also with different >> standby behaviours, chipsets etc. > > Well, after this patch there's one more device that works with an > open-source driver, which I consider a good thing. What about > open-sourcing support for the other devices you're talking about? > As mentioned you can use the sysfs approach for you. Don't buy a device which you intend to use with unintended software afterwards. Your device is from 2010 as far as I see, you can ship the unit back for changing the USB ID for it so you can mess around with it and break it completely. The USB ID in question is used for all kind of devices, even analog or radio only units which are very far from being supported by this crappy opensource driver which is able to crash the entire kernel. Our work is pretty much isolated. You might match your unit also based on your serialnumber if you want to apply such a patch to the crappy opensource driver. >> If you want to get a device with kernel support I recommend buying a >> different one and let that one go back to our community (since our >> tuners and support are still quite popular). > > Thanks, but I'd rather stick with the device I have than spending more > money to have a device that only works with a closed-source driver. > then sell it get a good price and buy another unit or ship it back for getting another USB ID (the EEPROM needs to be removed for rewriting it). > Anyway, I just saw that the patch doesn't apply cleanly against > linux-media master. I'll submit a new version of the patch in a > minute. > > Cheers > Thomas
Re: [PATCH] [media] em28xx: support for Sundtek MediaTV Digital Home
On Fri, May 5, 2017 at 11:44 PM, Thomas Hollstegge <thomas.hollste...@gmail.com> wrote: > Hi Markus, > > Markus Rechberger <mrechber...@gmail.com> schrieb am Fri, 05. May 08:06: >> On Fri, May 5, 2017 at 6:21 AM, Thomas Hollstegge >> <thomas.hollste...@gmail.com> wrote: >> > Sundtek MediaTV Digital Home is a rebranded MaxMedia UB425-TC with the >> > following components: >> > >> > USB bridge: Empia EM2874B >> > Demodulator: Micronas DRX 3913KA2 >> > Tuner: NXP TDA18271HDC2 >> > >> >> Not that it matters a lot anymore for those units however the USB ID >> is allocated for multiple different units, this patch will break some >> of them. > > I searched the kernel sources for USB IDs but didn't find any mention. > So what exactly will break with this commit? Is there a better way to > detect different devices besides USB IDs? > We had different HW designs based on Empia until 2012 using this USB ID it will not work with many units out there, also with different standby behaviours, chipsets etc. If you want to get a device with kernel support I recommend buying a different one and let that one go back to our community (since our tuners and support are still quite popular). >> If you want to use that use the unit with this driver you're on your >> own and have to assign it via sysfs and usb/bind. > > I did, and it works fine. However, it would be nice if the driver > supported the devices directly. > >> It was a joint project many years ago before we also started to design >> and manufacture our own units. > > Interesting, thanks for sharing this insight! > > Cheers > Thomas
Re: [PATCH] [media] em28xx: support for Sundtek MediaTV Digital Home
On Fri, May 5, 2017 at 6:21 AM, Thomas Hollstegge <thomas.hollste...@gmail.com> wrote: > Sundtek MediaTV Digital Home is a rebranded MaxMedia UB425-TC with the > following components: > > USB bridge: Empia EM2874B > Demodulator: Micronas DRX 3913KA2 > Tuner: NXP TDA18271HDC2 > Not that it matters a lot anymore for those units however the USB ID is allocated for multiple different units, this patch will break some of them. If you want to use that use the unit with this driver you're on your own and have to assign it via sysfs and usb/bind. It was a joint project many years ago before we also started to design and manufacture our own units. Best Regards, Markus Rechberger > Signed-off-by: Thomas Hollstegge <thomas.hollste...@gmail.com> > --- > drivers/media/usb/em28xx/em28xx-cards.c | 15 +++ > drivers/media/usb/em28xx/em28xx-dvb.c | 1 + > drivers/media/usb/em28xx/em28xx.h | 1 + > 3 files changed, 17 insertions(+) > > diff --git a/drivers/media/usb/em28xx/em28xx-cards.c > b/drivers/media/usb/em28xx/em28xx-cards.c > index 5f90d08..4effbda 100644 > --- a/drivers/media/usb/em28xx/em28xx-cards.c > +++ b/drivers/media/usb/em28xx/em28xx-cards.c > @@ -415,6 +415,7 @@ static struct em28xx_reg_seq hauppauge_930c_digital[] = { > > /* 1b80:e425 MaxMedia UB425-TC > * 1b80:e1cc Delock 61959 > + * eb1a:51b2 Sundtek MediaTV Digital Home > * GPIO_6 - demod reset, 0=active > * GPIO_7 - LED, 0=active > */ > @@ -2405,6 +2406,18 @@ struct em28xx_board em28xx_boards[] = { > .ir_codes = RC_MAP_HAUPPAUGE, > .leds = hauppauge_dualhd_leds, > }, > + /* eb1a:51b2 Sundtek MediaTV Digital Home > +* Empia EM2874B + Micronas DRX 3913KA2 + NXP TDA18271HDC2 */ > + [EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME] = { > + .name = "Sundtek MediaTV Digital Home", > + .tuner_type= TUNER_ABSENT, > + .tuner_gpio= maxmedia_ub425_tc, > + .has_dvb = 1, > + .ir_codes = RC_MAP_REDDO, > + .def_i2c_bus = 1, > + .i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE | > + EM28XX_I2C_FREQ_400_KHZ, > + }, > }; > EXPORT_SYMBOL_GPL(em28xx_boards); > > @@ -2600,6 +2613,8 @@ struct usb_device_id em28xx_id_table[] = { > .driver_info = EM28178_BOARD_TERRATEC_T2_STICK_HD }, > { USB_DEVICE(0x3275, 0x0085), > .driver_info = EM28178_BOARD_PLEX_PX_BCUD }, > + { USB_DEVICE(0xeb1a, 0x51b2), > + .driver_info = > EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME }, > { }, > }; > MODULE_DEVICE_TABLE(usb, em28xx_id_table); > diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c > b/drivers/media/usb/em28xx/em28xx-dvb.c > index 82edd37..e7fa25d 100644 > --- a/drivers/media/usb/em28xx/em28xx-dvb.c > +++ b/drivers/media/usb/em28xx/em28xx-dvb.c > @@ -1482,6 +1482,7 @@ static int em28xx_dvb_init(struct em28xx *dev) > break; > } > case EM2874_BOARD_DELOCK_61959: > + case EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME: > case EM2874_BOARD_MAXMEDIA_UB425_TC: > /* attach demodulator */ > dvb->fe[0] = dvb_attach(drxk_attach, _ub425_tc_drxk, > diff --git a/drivers/media/usb/em28xx/em28xx.h > b/drivers/media/usb/em28xx/em28xx.h > index e9f3799..72f1468 100644 > --- a/drivers/media/usb/em28xx/em28xx.h > +++ b/drivers/media/usb/em28xx/em28xx.h > @@ -148,6 +148,7 @@ > #define EM28178_BOARD_PLEX_PX_BCUD98 > #define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB 99 > #define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 100 > +#define EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME 101 > > /* Limits minimum and default number of buffers */ > #define EM28XX_MIN_BUF 4 > -- > 2.7.4 >
Re: [xawtv3] Request: Support for FM RDS
Hi, On Wed, Feb 15, 2017 at 5:28 PM, Devin Heitmueller <dheitmuel...@kernellabs.com> wrote: > Hi George, > > The big problem is that almost none of the hardware tuners out there > which support FM have support for RDS. You generally need an extra > chip, and very few devices have it (IIRC, none of the ones that are > supported in Linux have been available in retail for a number of > years). > Sundtek MediaTV Pro has support for RDS and we also manufacture dedicated radio units from time to time. Best Regards, Markus Rechberger > Don't get me wrong - I would like to see RDS supported as well - but I > couldn't find a single tuner product shipping in retail that supports > it. > > In short, it's a hardware limitation, not a problem with the > linux-media driver stack. > > Devin > > On Wed, Feb 15, 2017 at 11:07 AM, George Pojar <geoubu...@gmail.com> wrote: >> FM RDS would be a great feature in radio console application. It would >> be nice to see what the name of the song is that is playing (that is, >> if the station supports RDS). > > > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com
Re: Brazilian television capture device
The new Sundtek devices support DVB-C, DVB-T, ISDB-T, AnalogTV and FM Radio. The old ones only supported ISDB-T/AnalogTV and FM Radio. Power consumption is very low too. On Tue, Oct 20, 2015 at 11:01 AM, Michael Stilmantwrote: > Hi, David > > I'm in the same process that you are. I'm also on remote (Europe) but > I have some laptop in Brazil where I can do some test using remote > shell. I don't talk Brazilian/Portuguese so it is also hard to find > Local Linux groups certainly discussing about it > > I have also that reference. > http://www.isdb-t.com/usb-isdb-t-full-seg-digital-usb-tv-stick-use-for-pc-philippines-japan-chile-vcan1012/ > I don't know neither if this could be working. Not yet purchased > > My contact purchased > http://www.netserv19.com/ecommerce_site/produto_103630_1598_Visus-Tv-Radicale-Receptor-Tv-Digital-Fullhd-Alta-Definicao-FULL-SEG > I will need to test it coming days > but dvbsnoop -s feinfo allready return: > > Device: /dev/dvb/adapter0/frontend0 > > Basic capabilities: > Name: "DiBcom 8000 ISDB-T" > Frontend-type: OFDM (DVB-T) > Frequency (min): 45000.000 kHz > Frequency (max): 86.000 kHz > Frequency stepsiz: 62.500 kHz > Frequency tolerance: 0.000 kHz > > > Which is not a bad sign. > > Please share you finding, it would be appreciated. > > Regards, > > Michael > > > > > On Tue, Oct 20, 2015 at 1:04 AM, David Liontooth wrote: >> >> Does anyone know of a tv capture device for Brazil (ISDB-T) that is >> supported in Linux and available for sale? >> >> I'm having a hard time finding any of the devices listed under >> http://www.linuxtv.org/wiki/index.php/ISDB-T_USB_Devices or ISDB-T PCIe >> devices -- >> >> * Pixelview SBTVD >> (http://www.kabum.com.br/produto/6784/receptor-de-tv-digital-pixelview-playtv-usb-2-0-sbtvd-full-seg-pv-d231urn-f) >> is out of stock >> * Geniatech/MyGica X8507 PCI-Express Hybrid Card >> (http://www.linuxtv.org/wiki/index.php/Geniatech/MyGica_X8507_PCI-Express_Hybrid_Card) >> >> I see the Aver3d Hybrid Volar Xpro (H869 -- >> http://avertv.avermedia.com/avertv/Upload/ProductImages/DS_H869_EN_140415.pdf) >> at americanas.com >> (http://www.americanas.com.br/produto/9869979/placa-captura-de-tv-aver3d-hybrid-volar-xpro) >> -- is it supported? >> >> I'm advising friends remotely, so I can't just purchase it and try it out. >> >> Cheers, >> Dave >> >> -- >> 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 -- 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: Sundtek Media Pro III Europe switching off
On Fri, Feb 6, 2015 at 3:08 PM, steigerungs faktor steigerungsfak...@web.de wrote: Am 01.02.2015 um 14:26 schrieb Markus Rechberger: You'd need to show us some logfiles. echo loglevel=min /etc/sundtek.conf (and reboot) or /opt/bin/mediaclient --loglevel=min (this will turn on the logfile immediately). Is the tuner attached to a USB 3.0 port? What does tvheadend say? The tuner and drivers are 100% stable and proven with tvheadend, so in case tvheadend is blocked something else must be wrong. Best Regards, Markus On Sun, Feb 1, 2015 at 11:12 AM, steigerungs faktor steigerungsfak...@web.de wrote: Hi. Sry for the delay, testet quite a bit during nights. And switched from TVHeadend to VDR. Better used to. Obviously I have a USB problem, allthough not using 3.0 Will contact Fedora and Sundtek. Thanks for the trouble Gunter If interested, here is the story: Yesterday, after boot, Sundtek Media Pro was on. Driver loaded. TV possible, Rec possible. (By the way, not KODI but XBMC Gotham is running on this Fedora 20.) Hardware is Gigabyte GA-870A-USB3 Mainboard, Dualcore 3,4 GHz AMD. 4GB RAM, NVIDIA 9500. NVIDIA driver in use. SSD (reboot is nice). Setting Timer (1) worked with live TV running; at programmed time, vdr switched channel and recorded. Interesting: I had live TV on Eurosport, Timer on Tele 5, and could record Tele5 with Eurosport continuing to show football Probably same transponder, and the tuner can split the signals ??? Anyways, Eurosport kept going after Timer end. Tuner had no chance for pausing (?). Next Timer (2): Some time later, DasErste. Eurosport live ended, DasErste was recorded. Next timer(3) : DasErsteHD, immediately following Timer 2. Was recorded correctly; obviously again Tuner had no chance for pausing (?). Yet after rec, live TV was off. Next Timer (4): hours later. Rec startet, but no data recorded. This morning no chance of getting xbmc to show tv. No data from backend. Reboot, device plugged in. mediasrv.log: 2015-02-06 09:06:10 [1050] restarting logging 2015-02-06 09:06:10 [1050] sending command failed with status (Unknown error -1) 2015-02-06 09:06:10 [1050] read status failure 1041 2015-02-06 09:06:10 [1050] The device just got disconnected from the system 2015-02-06 09:06:10 [1050] Shutting down this device instance 2015-02-06 09:06:10 [1050] USB Transfer problem, shutting down driver instance (-1 - 19) 2015-02-06 09:06:10 [1050] Stopping Remote Control support 2015-02-06 09:06:10 [1050] Enabling Standby 2015-02-06 09:06:10 [1050] sending command failed with status (Unknown error -1) 2015-02-06 09:06:10 [1050] sending command failed with status (Unknown error -1) 2015-02-06 09:06:10 [1050] sending command failed with status (Unknown error -1) 2015-02-06 09:06:10 [1050] Tuner response error (660) 2015-02-06 09:06:10 [1050] sending command failed with status (Unknown error -1) 2015-02-06 09:06:10 [1050] sending command failed with status (Unknown error -1) 2015-02-06 09:06:10 [1050] send vendor cmd failed with status --1 2015-02-06 09:06:10 [1050] send vendor cmd failed with status --1 2015-02-06 09:06:10 [1050] sending command failed with status (Unknown error -1) 2015-02-06 09:06:10 [4953] RC: detached remote control 2015-02-06 09:06:10 [1050] clearing id: 0 2015-02-06 09:06:17 [1050] Shutting down driver now 2015-02-06 09:06:17 [1050] Waiting for service thread to complete 2015-02-06 09:07:05 [1086] RC: IR Event /dev/input/event12 2015-02-06 09:07:05 [1095] RC: IR Event /dev/input/event12 2015-02-06 09:11:40 [1048] The device just got disconnected from the system 2015-02-06 09:11:40 [1048] Shutting down this device instance 2015-02-06 09:11:40 [1048] USB Transfer problem, shutting down driver instance (-1 - 19) 2015-02-06 09:11:40 [1048] Stopping Remote Control support 2015-02-06 09:11:40 [1911] RC: detached remote control 2015-02-06 09:11:40 [1048] clearing id: 0 -- Aha. USB problem. Unplugged device, plugged back in without reboot. mediasrv.log: all kinds of errors like: 2015-02-06 09:11:41 [1048] sending command failed with status (Unknown error -1) 2015-02-06 09:11:41 [1048] send vendor cmd failed with status --1 2015-02-06 09:11:41 [1048] sending command failed with status fffc (Unknown error -4) 2015-02-06 09:11:41 [1048] sending command failed with status fffe (Unknown error -2) 2015-02-06 09:11:41 [1048] sending command failed with status fffd (Unknown error -3) 2015-02-06 09:11:41 [1048] Tuner communcication error (573) 2015-02-06 09:11:41 [1048] Tuner response error (660) 2015-02-06 09:11:41 [1048] Tuner acknowledge message timed out (527) 2015-02-06 09:11:41 [1048] Tuner response error (660) 2015-02-06 09:11:41 [1048] xouton fail 2015-02-06 09:11:41 [1048] Error loading firmware for demodulator (400) 2015-02-06
Re: Sundtek Media Pro III Europe switching off
You'd need to show us some logfiles. echo loglevel=min /etc/sundtek.conf (and reboot) or /opt/bin/mediaclient --loglevel=min (this will turn on the logfile immediately). Is the tuner attached to a USB 3.0 port? What does tvheadend say? The tuner and drivers are 100% stable and proven with tvheadend, so in case tvheadend is blocked something else must be wrong. Best Regards, Markus On Sun, Feb 1, 2015 at 11:12 AM, steigerungs faktor steigerungsfak...@web.de wrote: Hi. New to the list, so maybe topic Sundtek Media Pro III has been treatet allready. If so, please just send archives. If not: Setup is the the above Stick, newest driver, Linux (Fedora 20), Kodi with TVHeadend. All fine when initially starting. Shows TV and records shows. Then Timer is set, and stick 'stops working'. I.e.: the timed show is not recorded. Instead Kodi tells me that connection to tvheadend is lost. To gain stick back, reboot is necessary. Any ideas? Gunter -- 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: [tvtime] ignores WSS signals
It probably won't help you but with Sundtek devices you can register a WSS callback at the driver which automatically triggers tvtime-command in the background for adjusting the 4:3 / 16:9 On Sun, Feb 1, 2015 at 5:22 PM, Buda Servantes budaservan...@gmail.com wrote: I would like to see the following in TVTime: Detection of WSS (Letterbox) Stretch 4:3 content in 16:9 format automatically based on WSS signal -- 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: sound dropouts with DVB
Hi, On Thu, Mar 6, 2014 at 10:48 PM, pinguin74 pingui...@gmx.com wrote: Hello, I use a Sundtek DVB-C stick with openSUSE 13.1 Linux. Most of the time, TV is just fine. But sometimes the sound just drops out, the sound disappears totally for up to 20 or 30 seconds. Usually sound returns. When sound drops out, there is no error message. Generally sound is fine, I use pulseaudio with KDE. The sound drop out happens only when watching TV. Is this a know issue with DVB? What could be the reason for the dropouts? The DVB-C signal is strong, usually 100%. If you use mplayer, mplayer will show you if there's some stream corruption. Other than that it could only be a codec issue. Markus Would be nice to get a hint. -- 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: sound dropouts with DVB
On Fri, Mar 7, 2014 at 12:19 AM, pinguin74 pingui...@gmx.com wrote: Most of the time, TV is just fine. But sometimes the sound just drops out, the sound disappears totally for up to 20 or 30 seconds. Usually sound returns. When sound drops out, there is no error message. If you use mplayer, mplayer will show you if there's some stream corruption. Other than that it could only be a codec issue. I will try with mplayer later. What does codec issue mean? I think the audio stream in DVB-C is a digital stream that does not need to be changed or encoded in any way? I thought DVB playback simply is a kind of pass thru the digital streamt to the media player The mediaplayer is using a codec for decoding/unpacking the compressed digital stream. Markus -- 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: [PATCH v4 RFC 1/2] [media] em28xx: retry I2C write ops if failed by timeout
Did you trace the i2c messages on the bus? This seems like papering the actual bug. USB 3.0 is a disaster with Linux, maybe your hardware or your controller driver is not okay? There are other bugreports out there which are USB 3.0 related, some of our customers reported that since 3.6.0 is okay while 3.7.10 give them a complete system lock up also with the driver in question here. On Sat, Jan 4, 2014 at 12:09 PM, Mauro Carvalho Chehab m.che...@samsung.com wrote: At least on HVR-950, sometimes an I2C operation fails. This seems to be more frequent when the device is connected into an USB 3.0 port. Instead of report an error, try to repeat it, for up to 20 ms. That makes the code more reliable. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- drivers/media/usb/em28xx/em28xx-i2c.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c b/drivers/media/usb/em28xx/em28xx-i2c.c index 6cd3d909bb3a..35d6808aa9ff 100644 --- a/drivers/media/usb/em28xx/em28xx-i2c.c +++ b/drivers/media/usb/em28xx/em28xx-i2c.c @@ -189,6 +189,7 @@ static int em28xx_i2c_send_bytes(struct em28xx *dev, u16 addr, u8 *buf, * Zero length reads always succeed, even if no device is connected */ +retry: /* Write to i2c device */ ret = dev-em28xx_write_regs_req(dev, stop ? 2 : 3, addr, buf, len); if (ret != len) { @@ -208,26 +209,24 @@ static int em28xx_i2c_send_bytes(struct em28xx *dev, u16 addr, u8 *buf, ret = dev-em28xx_read_reg(dev, 0x05); if (ret == 0) /* success */ return len; - if (ret == 0x10) { - em28xx_warn(I2C transfer timeout on writing to addr 0x%02x, - addr); - return -EREMOTEIO; - } + if (ret == 0x10) + goto retry; if (ret 0) { em28xx_warn(failed to get i2c transfer status from bridge register (error=%i)\n, ret); return ret; } msleep(5); - /* -* NOTE: do we really have to wait for success ? -* Never seen anything else than 0x00 or 0x10 -* (even with high payload) ... -*/ } - if (i2c_debug) - em28xx_warn(write to i2c device at 0x%x timed out\n, addr); + if (ret == 0x10) { + if (i2c_debug) + em28xx_warn(I2C transfer timeout on writing to addr 0x%02x, + addr); + } else { + em28xx_warn(write to i2c device at 0x%x timed out (ret=0x%02x)\n, + addr, ret); + } return -EREMOTEIO; } -- 1.8.3.1 -- 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: [RFCv1] DVB-USB improvements
On Tue, May 8, 2012 at 3:12 PM, Antti Palosaari cr...@iki.fi wrote: Factors behind the changes are mostly coming from the fact current struct dvb_usb_device_properties contains so many static configuration options. You cannot change single dvb_usb_device_properties easily (safely) at runtime since it is usually driver global struct and thus shared between all the DVB USB driver instances. That fits just fine for the traditional devices where all configuration is same for the devices having single USB ID. Nowadays we have more and more devices that are based of chipset vendor reference designs - even using just single USB ID chipset vendor have given for that chipset. These reference designs still varies much about used chips and configurations. Configuring different base chips, USB-bridge, demod, tuner, and also peripheral properties like dual tuners, remotes and CI is needed to do runtime because of single USB ID is used for that all. My personal innovator behind all these is problems I met when developing AF9015 and AF9035 drivers. Also RTL2831U and RTL2832U are kinda similar and have given some more motivation. Here is small list what I am planning to do. It is surely so much work that everything is not possible, but lets try to select most important and easiest as a higher priority. resume / suspend support --- * very important feature * crashes currently when DVB USB tries to download firmware when resuming from suspend read_config1 --- * new callback to do initial tweaks * very first callback * is that really needed? read_mac_address = read_config2 --- * rename it read_config2 or read_config if read_config1 is not implemented at all * rename old callback and extend it usage as a more general * only 8 devices use currently * when returned mac != 0 = print mac address as earlier, otherwise work as a general callback new callback init() --- * called after tuner attach to initialize rest of device * good place to do some general settings - configure endpoints - configure remote controller - configure + attach CI change DVB-USB to dynamic debug --- * use Kernel new dynamic debugs instead of own proprietary system download_firmware --- * struct usb_device = struct dvb_usb_device * we need access for the DVB USB driver state in every callback identify_state --- * struct usb_device = struct dvb_usb_device * we need access for the DVB USB driver state in every callback attach all given adapter frontends as once --- * for the MFE devices attach all frontends as once * deregister all frontends if error returned * small effect only for MFE attach all given adapter tuners as once --- * deregister all frontends if error returned * small effect only for MFE make remote dynamically configurable --- * default keytable mapped same level with USB-ID device name etc. * there is generally 3 things that could be mapped to USB ID - USB IDs (cold + warm) - device name - remote controller keytable - all the others could be resolved configured dynamically * it is not only keytable but whole remote should be changed dynamically configurable make stream dynamically configurable --- * we need change stream parameters in certain situations - there is multiple endpoints but shared MFE - need to set params according to stream bandwidth (USB1.1, DVB-T, DVB-C2 in same device) - leave old static configrations as those are but add callbacks to get new values at runtime dynamically growing device list in dvb_usb_device_properties --- * currently number of devices are limited statically * there is devices having ~50 or more IDs which means multiple dvb_usb_device_properties are needed dynamic USB ID support --- * currently not supported by DVB USB analog support for the DVB USB --- * currently not supported by DVB USB * I have no experience * em28xx can be converted? You might also work on a dvb library, just like libv4l has right now, that might satisfy the streaming requests which have been made on this mailinglist :-) BR, Markus -- 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 -- 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: [PATCH] Support for Sundtek SkyTV Ultimate (USB DVB-S/S2)
On Mon, Nov 28, 2011 at 3:53 AM, Alessandro Miceli angelofsky1...@gmail.com wrote: Here is the patch to support the Sundtek SkyTV Ultimate device. It's a USB DVB-S/S2 device based on Empia chipset 28174 + NXP TDA 10071. Device tested with success on Intel Core i5, Ubuntu 11.10, Kernel 3.0.0, Kaffeine and latest media_build env. The hardware profile of Sundtek device seems a clone of PCTV 460e already supported by LinuxTV. Signed-off-by: Alessandro Miceli angelofsky1...@gmail.com diff -uprN orig/drivers/media/video/em28xx//em28xx-cards.c linux/drivers/media/video/em28xx//em28xx-cards.c --- orig/drivers/media/video/em28xx//em28xx-cards.c 2011-11-25 05:45:29.0 +0100 +++ linux/drivers/media/video/em28xx//em28xx-cards.c 2011-11-27 20:36:24.626783803 +0100 @@ -1888,6 +1888,14 @@ struct em28xx_board em28xx_boards[] = { .has_dvb = 1, .ir_codes = RC_MAP_PINNACLE_PCTV_HD, }, + [EM2884_BOARD_SUNDTEK_DVBS2] = { + .i2c_speed = EM2874_I2C_SECONDARY_BUS_SELECT | + EM28XX_I2C_CLK_WAIT_ENABLE | EM28XX_I2C_FREQ_400_KHZ, + .name = Sundtek SkyTV Ultimate, + .tuner_type = TUNER_ABSENT, + .tuner_gpio = pctv_460e, + .has_dvb = 1, + }, }; const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards); @@ -2027,6 +2035,8 @@ struct usb_device_id em28xx_id_table[] = .driver_info = EM28174_BOARD_PCTV_460E }, { USB_DEVICE(0x2040, 0x1605), .driver_info = EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C }, + { USB_DEVICE(0xeb1a, 0x51be), + .driver_info = EM2884_BOARD_SUNDTEK_DVBS2 }, { }, }; MODULE_DEVICE_TABLE(usb, em28xx_id_table); diff -uprN orig/drivers/media/video/em28xx//em28xx-dvb.c linux/drivers/media/video/em28xx//em28xx-dvb.c --- orig/drivers/media/video/em28xx//em28xx-dvb.c 2011-11-25 05:45:29.0 +0100 +++ linux/drivers/media/video/em28xx//em28xx-dvb.c 2011-11-27 20:45:08.738805535 +0100 @@ -936,6 +936,11 @@ static int em28xx_dvb_init(struct em28xx sizeof(dvb-fe[0]-ops.tuner_ops)); break; + case EM2884_BOARD_SUNDTEK_DVBS2: + /* attach demod */ + dvb-fe[0] = dvb_attach(tda10071_attach, + em28xx_tda10071_config, dev-i2c_adap); + break; case EM28174_BOARD_PCTV_460E: /* attach demod */ dvb-fe[0] = dvb_attach(tda10071_attach, diff -uprN orig/drivers/media/video/em28xx//em28xx.h linux/drivers/media/video/em28xx//em28xx.h --- orig/drivers/media/video/em28xx//em28xx.h 2011-11-25 05:45:29.0 +0100 +++ linux/drivers/media/video/em28xx//em28xx.h 2011-11-27 20:35:34.286781718 +0100 @@ -124,6 +124,7 @@ #define EM28174_BOARD_PCTV_460E 80 #define EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C 81 #define EM2884_BOARD_CINERGY_HTC_STICK 82 +#define EM2884_BOARD_SUNDTEK_DVBS2 84 /* Limits minimum and default number of buffers */ #define EM28XX_MIN_BUF 4 This might only work with Rev 1 of the device Rev 2 - 4 definitely won't work with that. Revision 5 uses a completely different demodulator and will only cause errors with this. And by far it's no clone of the other device the circuits are totally different. If you insist on supporting our devices don't load it as default only people who have the first rev. with bad sensitivity should use it. Not accepted because of that. Best Regards, Markus -- 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: FM RDS receiver
On Tue, Jun 28, 2011 at 12:02 AM, Helmut Auer v...@helmutauer.de wrote: Hello List, Can you recommend any FM receiver card or usb stick currently available in Germany with RDS support ? We do have some FM Receiver/Transmitters which support RDS, however they are still only available upon request at this time. Audio is represented by ALSA (snd-usb-audio), radio can be controlled via v4l1/v4l2 from userspace. Alternatively Sundtek MediaTV Pro also supports RDS and is available on the market right now (decoders can be requested), audio is represented as OSS, although Alsa shouldn't be too difficult using the new userspace Alsa interface. Markus -- 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: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 10:44, Devin Heitmueller escreveu: Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. I was a little faster to answer to my previous emails. I'm not feeling well today due to a strong pain on my backbone. So, let me explain what would be ok, from my POV: A kernelspace driver that will follow DVBv5 API and talk with wit another device via the Kernel network stack, in order to access a remote Kernel board, or a kernel board at the physical machine, for virtual machines. That means that the dvb stack won't be proxied to an userspace application. Something like: Userspace app (like kaffeine, dvr, etc) - DVB net_tunnel driver - Kernel Network stack Kernel Network stack - DVB net_tunnel driver - DVB hardware for such a design a developer should be fired ^^ Everything back to ring 0, however I guess that particular developer who designed this does not know about that security concept, otherwise he wouldn't propose to put such things into kernelspace. and from the kernel network stack you go via TCP and connect to whoever you want (particular userspace daemon with all the implementation). Aside of the security issue which it introduces you won't even protect what you try to protect because you cannot control the connection. It would be interesting if someone would implement it that way now, so Mauro disqualified himself with this proposal. Although please continue I'll keep watching, either result (supporting or not supporting it) is fine with me. Markus In other words, the DVB net_tunnel driver will take care of using the network stack, implement Kernel namespaces, etc, in order to allow virtualizing a remote hardware, without needing any userspace driver for doing that (well, except, of course, for the standard network userspace applications for DNS solving, configuring IP routes, etc). 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: [RFC] vtunerc - virtual DVB device driver
My very little opinion is that waving GPL is way to the hell. Nobody told me why similar technologies, in different kernel parts are acceptable, but not here. since a customer was trying to use this module the only feedback I can give right now is that there are still some fundamental bugs in that work. Just running it with some intuitive parameters (without having a dvb device connected) caused it to hang. ./vtunerc.i686 -c 1 vtunerc: [5210 ../../vtunerc.c:349] debug: added frontend mode DVB-C as mode 0, searching for tuner types 2 vtunerc: [5210 ../../vtunerc.c:346] error: unknown tuner mode specified: 1 allow values are: -s -S -s2 -S2 -c -t it just never returned. DMESG: vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer vtunerc: [5207 ../../vtunerc.c:606] info: msg: 4096 completed vtunerc: [5207 ../../vtunerc.c:506] info: vtuner message! vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer ps fax | grep vtunerc: 5194 pts/4S 0:00 | \_ bash 5210 pts/4S+ 0:00 | \_ [vtunerc.i686] that way it's not good enough for inclusion yet anyway. Markus -- 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: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On Mon, Jun 20, 2011 at 9:29 PM, Rune Evjen rune.ev...@gmail.com wrote: 2011/6/12 Antti Palosaari cr...@iki.fi: On 06/12/2011 11:23 AM, Rune Evjen wrote: I just tested a PCTV 290e device using the latest media_build drivers in MythTV as a DVB-C device, and ran into some problems. The adapter is recognized by the em28xx-dvb driver [1] and dmesg output seems to be correct [2]. I can successfully scan for channels using the scan utility in dvb-apps but when I try to scan for channels in mythtv I get the following errors logged by mythtv-setup: 2011-06-12 00:57:20.971556 PIDInfo(/dev/dvb/adapter0/ frontend1): Failed to open demux device /dev/dvb/adapter0/demux1 for filter on pid 0x0 The demux1 does not exist, I only have the following nodes under /dev/dvb/adapter0: demux0 dvr0 frontend0 frontend1 net0 When searching the linx-media I came across this thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31839.html Is there any way to circumvent with the current driver that there is no corresponding demux1 for frontend1? Or can the DVB-T/T2 part be disabled somehow so that there is only one DVB-C frontend registered which corresponds to the demux0? There is no way to say driver to create demux1 for frontend1. After all it is not 100% clear even for me if that's correct or not, but most likely it is correct as far as I understood. Thank you for your response, Antti. Your help is much appreciated. I have tested the 290e as a DVB-C adapter with some success, to use it I created a new adapter directory under /dev/dvb, and symlinked the following: ln -s /dev/dvb/adapter0/frontend1 /dev/dvb/adapter1/frontend0 ln -s /dev/dvb/adapter0/demux0 /dev/dvb/adapter1/demux0 ln -s /dev/dvb/adapter0/dvr0 /dev/dvb/adapter1/dvr0 When testing I can scan using the scan utility and mythtv, and receive QAM-64 channels. QAM-256 channels have distorted audio and video. I tried to investigate the QAM-256 problem using the debug option on cxd2820r, but when this option is enabled I get no lock using mythtv or the scan utility. This also happened intermittently without the debug option, and when I get the no lock status, the only way to solve this is to shutdown and start the computer (i.e not rebooting) to make sure the 290e gets a power cycle (and it seems that the debug option also has to be off, at least this is my experience after 3-4 power cycles with and without this option). I have attached the syslog output with failed locks [1] generated by the debug option in case this may help with the driver development. Best regards, Rune [1]: syslog output when performing a scan using the scan utility: Jun 20 21:04:21 server kernel: [ 711.180370] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:21 server kernel: [ 711.180375] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380429] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380436] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.381308] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.581398] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.581403] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.582206] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.731275] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.731281] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732101] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.732108] cxd2820r: cxd2820r_set_frontend: delsys=1 Jun 20 21:04:22 server kernel: [ 711.732112] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732118] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:22 server kernel: [ 711.732123] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792010] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792017] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.792863] cxd2820r: cxd2820r_read_status_c: lock=04 52 Jun 20 21:04:22 server kernel: [ 711.992944] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.992949] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.993769] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 712.194200] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 712.194207] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 712.195052] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:23 server kernel: [ 712.291281] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:23 server kernel: [ 712.291285]
Re: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On Mon, Jun 20, 2011 at 10:55 PM, Rune Evjen rune.ev...@gmail.com wrote: 2011/6/20 Markus Rechberger mrechber...@gmail.com: On Mon, Jun 20, 2011 at 9:29 PM, Rune Evjen rune.ev...@gmail.com wrote: 2011/6/12 Antti Palosaari cr...@iki.fi: On 06/12/2011 11:23 AM, Rune Evjen wrote: I just tested a PCTV 290e device using the latest media_build drivers in MythTV as a DVB-C device, and ran into some problems. The adapter is recognized by the em28xx-dvb driver [1] and dmesg output seems to be correct [2]. I can successfully scan for channels using the scan utility in dvb-apps but when I try to scan for channels in mythtv I get the following errors logged by mythtv-setup: 2011-06-12 00:57:20.971556 PIDInfo(/dev/dvb/adapter0/ frontend1): Failed to open demux device /dev/dvb/adapter0/demux1 for filter on pid 0x0 The demux1 does not exist, I only have the following nodes under /dev/dvb/adapter0: demux0 dvr0 frontend0 frontend1 net0 When searching the linx-media I came across this thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31839.html Is there any way to circumvent with the current driver that there is no corresponding demux1 for frontend1? Or can the DVB-T/T2 part be disabled somehow so that there is only one DVB-C frontend registered which corresponds to the demux0? There is no way to say driver to create demux1 for frontend1. After all it is not 100% clear even for me if that's correct or not, but most likely it is correct as far as I understood. Thank you for your response, Antti. Your help is much appreciated. I have tested the 290e as a DVB-C adapter with some success, to use it I created a new adapter directory under /dev/dvb, and symlinked the following: ln -s /dev/dvb/adapter0/frontend1 /dev/dvb/adapter1/frontend0 ln -s /dev/dvb/adapter0/demux0 /dev/dvb/adapter1/demux0 ln -s /dev/dvb/adapter0/dvr0 /dev/dvb/adapter1/dvr0 When testing I can scan using the scan utility and mythtv, and receive QAM-64 channels. QAM-256 channels have distorted audio and video. I tried to investigate the QAM-256 problem using the debug option on cxd2820r, but when this option is enabled I get no lock using mythtv or the scan utility. This also happened intermittently without the debug option, and when I get the no lock status, the only way to solve this is to shutdown and start the computer (i.e not rebooting) to make sure the 290e gets a power cycle (and it seems that the debug option also has to be off, at least this is my experience after 3-4 power cycles with and without this option). I have attached the syslog output with failed locks [1] generated by the debug option in case this may help with the driver development. Best regards, Rune [1]: syslog output when performing a scan using the scan utility: Jun 20 21:04:21 server kernel: [ 711.180370] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:21 server kernel: [ 711.180375] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380429] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380436] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.381308] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.581398] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.581403] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.582206] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.731275] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.731281] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732101] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.732108] cxd2820r: cxd2820r_set_frontend: delsys=1 Jun 20 21:04:22 server kernel: [ 711.732112] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732118] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:22 server kernel: [ 711.732123] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792010] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792017] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.792863] cxd2820r: cxd2820r_read_status_c: lock=04 52 Jun 20 21:04:22 server kernel: [ 711.992944] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.992949] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.993769] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 712.194200] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 712.194207] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 712.195052] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:23
Re: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On Mon, Jun 20, 2011 at 11:02 PM, Antti Palosaari cr...@iki.fi wrote: On 06/20/2011 11:55 PM, Rune Evjen wrote: 2011/6/20 Markus Rechbergermrechber...@gmail.com: to tell the difference the amplifier is for DVB-T2, DVB-C is disabled in windows because it's not reliable. Technically the chip supports it but the LNA decreases the quality. There are already some other PCI boards out there with that chip which do not use that LNA which should have a better performance with that Sony chip. Is it possible to work around this by disabling the lna or is the quality decreased permanently as part of the hardware design, independently of whether the lna is enabled or not ? I searched the linux-media list and it seems that an lna option was discussed as a module parameter, but modinfo for the module I use [1] (using the media_build git repository) doesn't show a lna parameter. Can the lna be disabled in another way ? LNA is controlled by demod GPIO line. I don't remember if it is on or off for DVB-C currently. Look em28xx-dvb.c file, you can disable or enable it from there (needs re-compiling driver). I also saw BER counter running some muxes during development, but I think all channels I have are still working. And I didn't even have time to optimal parameters for tuner / demod. I will try to examine those later... sure things can be optimized forward and backward but unsupported features won't be better. DVB-C is disabled on purpose, the reason is not that it's not allowed in UK with some providers. In Germany some providers don't want alternative boxes either but no one can check that anyway. The LNA is for DVB-T2 not for DVB-C, PCTV sells it like that because they designed it for that purpose the rest is out of spec. Markus -- 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: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On Mon, Jun 20, 2011 at 11:10 PM, Antti Palosaari cr...@iki.fi wrote: On 06/21/2011 12:04 AM, Markus Rechberger wrote: On Mon, Jun 20, 2011 at 10:55 PM, Rune Evjenrune.ev...@gmail.com wrote: 2011/6/20 Markus Rechbergermrechber...@gmail.com: to tell the difference the amplifier is for DVB-T2, DVB-C is disabled in windows because it's not reliable. Technically the chip supports it but the LNA decreases the quality. There are already some other PCI boards out there with that chip which do not use that LNA which should have a better performance with that Sony chip. Is it possible to work around this by disabling the lna or is the quality decreased permanently as part of the hardware design, independently of whether the lna is enabled or not ? I searched the linux-media list and it seems that an lna option was discussed as a module parameter, but modinfo for the module I use [1] (using the media_build git repository) doesn't show a lna parameter. Can the lna be disabled in another way ? no, otherwise it would be sold as full hybrid device. DVB-T2 is weak that's why it was added. Failing DVB-C would increase the device return rate, that's why it is sold as DVB-T2 only. How the others have resolved that problem? Is that signal strength only issue when TDA18271 tuner is used? USB is expected to be mobile, so sensitivity is a more important issue. The T2 tuner in question is designed to be a little bit mobile (you can use it with your notebook without moving at least). If you use a PC card you can play around with the antenna and won't move it all the time. The sensitivity optimization is quite clear why it's there for T2. C is clearly not the focus of that design. We already switched away from the tda18271 for our current (and especially upcoming) designs as well. Markus -- 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: Well supported USB DVB-C device?
On Thu, Mar 10, 2011 at 5:02 PM, Guy Martin gms...@tuxicoman.be wrote: On Mon, 28 Feb 2011 02:28:37 +0200 Antti Palosaari cr...@iki.fi wrote: I am not sure which is status of TT CT-3650, it could be other one which is working. The CT-3650 works well. I belive everything works (CI, IR) but DVB-T is not yet implemented on that one. without AC Adapter Sundtek MediaTV Pro (DVB-C, DVB-T, AnalogTV, FM-Radio, Composite, S-Video) / Digital Home (DVB-C, DVB-T only), supported from Linux 2.6.15 - (any newer System). Full standby after 15 seconds inactivity. Also supported across many different Architectures. Driver installation should not take longer than 10 seconds on just about any system. Some multimedia distributions already ship direct support for it. BR, Markus -- 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: RFC: V4L2 driver for Qualcomm MSM camera.
On Tue, Jan 4, 2011 at 3:29 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 04-01-2011 08:40, Hans Verkuil escreveu: Hi Jeff, On Tuesday 04 January 2011 07:14:00 Haibo Zhong wrote: On 1/3/2011 6:37 PM, Shuzhen Wang wrote: On Tuesday, December 28, 2010 12:24 PM Laurent Pinchart wrote: I will strongly NAK any implementation that requires a daemon. We understand the motivation behind making the daemon optional. However there are restrictions from legal perspective, which we don't know how to get around. A simplest video streaming data flow with MSM ISP is like this: Sensor - ISP Hardware pipeline - videobuf The procedure to set up ISP pipeline is proprietary and cannot be open sourced. Without proper pipeline configuration, streaming won't work. And That's why we require the daemon. Laurent/Hans/Mauro, We are working on and will provide more design information on Qualcomm MSM ISP design and explain the legal concern of the daemon implementation. The underlined idea is to comply to V4L2 architecture with MSM solution. That's a good first step, but I'm afraid it's not enough. If you want your driver to be included in the mainline Linux kernel (and its derivative distribution kernels such as the MeeGo kernel for instance) all the code needed to access and use the hardware must be open-source. This of course doesn't preclude you from providing a closed-source userspace implementation of proprietary hardware-assisted image processing algorithms for instance (as a library or as a daemon). In the meantime, Laurent, can you share with your major concern about the Daemon? I have two concerns. - The daemon makes code required to use the hardware closed-source, making the driver closed-source (whether the kernel-side code is licensed under the GPL or not is irrelevant). I would have the exact same opinion if the required userspace proprietary code was provided as a library, so this concern is not specific to the implementation being in the form of a daemon. - The daemon makes the kernel-side driver architecture more complex for no reason. Assuming you can make all the driver open-source in the future and want to keep proprietary userspace image processing code closed-source, the driver architecture must not be designed solely to support that use case. The driver should be clean and lean, and the proprietary code must then come as a user of the driver, not the other way around. As a summary, having part of the driver closed-source is a no-go, and having part of the kernel driver API designed and used to support closed-source components only is a no-go as well. I don't entirely understand the whole discussion: in Helsinki this was discussed extensively with Jeff Zhong and I thought we all agreed on how to implement the driver: using a libv4l plugin which communicates to a daemon for your proprietary ISP code. I also had the same understanding from Helsinki's meeting. Also, the driver should work without any proprietary code (obviously with sub-optimal picture quality, but you should get something out of the hardware). The driver API should be well-documented when it comes to any custom ioctls/controls. This makes it possible for sufficiently motivated developers to write open source libv4l plugins. It was my understanding that the proprietary code was about determining the optimal ISP settings, not about getting the ISP hardware to work. Look: we don't mind if you have some daemon/library/userspace utils with some picture enhancement algorithm that you may have developed and have legal concerns to protect them. The best way for doing that is probably via libv4l, as other userspace apps will use it, but you can do whatever you want. However, the driver should be open source for being accepted upstream. In other words, all access to the hardware should be done via the open source driver, and using a public, well documented, kernel=userspace API. That means that any application should be able to use it, without requiring any daemon. So, it is OK if your driver have some well-documented ways to expose image statistics and some way to adjust the device parameters to enhance image quality, and have some proprietary, closed source daemon/library that will use those statistics to enhance the image. Of course, such driver, to be open, should allow someone to write a different code to do similar enhancements, as Hans pointed. That's said, I can't understand why you're afraid of doing that. Multiple reasons 1. They want to control their drivers and not have to take care about the kernel release cycles. 2. With a thin kernel layer (if needed) they can still modify the hardware and just need to update the userspace part of it. This will make their product better supported accross different kernelversions. 3. easier debugging of course 4. things are going userspace.. see PCI/e virtualization, drivers can be in Userspace
Re: Simple request : mini-pcie analog TV capture card
Hi, On Wed, Dec 15, 2010 at 1:25 AM, Fernando Laudares Camargos fernando.laudares.camar...@gmail.com wrote: Hello List, I'm after a somehow quite simple information: I'm looking for a mini-pcie TV tuner/capture card. I simply need to plug my cable TV decoder to such a card to watch TV on Linux. I've got success with a Hauppauge 950Q USB stick and TV time but this is not a one-time project and we would need to replicate it in a somehow large scale, so a mini-pcie card would fit the hardware best. Does anybody know any mini-pcie model analog card that are still available on the market and that is compatible with this need ? I've looked at linuxtv.org lists but couldn't find one. Habey has a new model, based on the ATI Theater 750 HD chip, which is not supported. AVerMedia has some models too, but none seems to have analog mode working on Linux. Any suggestions would be kindly appreciated. We have MiniPCIe AnalogTV devices which are very well supported. Basically those devices are using the USB Pins of the MiniPCIe Bus. All worldwide standards are supported, we have ATSC/clearQAM/analogTV(NTSC)/VBI/FM-Radio/composite and s-video are available through reserved pin routing. A European version is also available. Tested applications * http://tvtime.sourceforge.net tvtime * http://www.videolan.org/vlc/ VLC * http://www.mplayerhq.hu/design7/news.html Linux mplayer * http://www.mythtv.org/ MythTV * http://linux.bytesex.org/xawtv/ XawTV * http://zapping.sourceforge.net/Zapping/index.html Zapping * http://ekiga.org/ Ekiga VOIP (Channel 0: TV Channel 1: Composite Channel 2: S-Video) * http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome Motion detection Software http://support.sundtek.com/index.php/topic,4.0.html http://sundtek.com/images/vivi.png (some virtual driver emulation for testing) Setup shouldn't take longer than a few seconds Best Regards, Markus -- 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: Simple request : mini-pcie analog TV capture card
On Wed, Dec 15, 2010 at 6:33 AM, Markus Rechberger mrechber...@gmail.com wrote: Hi, On Wed, Dec 15, 2010 at 1:25 AM, Fernando Laudares Camargos fernando.laudares.camar...@gmail.com wrote: Hello List, I'm after a somehow quite simple information: I'm looking for a mini-pcie TV tuner/capture card. I simply need to plug my cable TV decoder to such a card to watch TV on Linux. I've got success with a Hauppauge 950Q USB stick and TV time but this is not a one-time project and we would need to replicate it in a somehow large scale, so a mini-pcie card would fit the hardware best. Does anybody know any mini-pcie model analog card that are still available on the market and that is compatible with this need ? I've looked at linuxtv.org lists but couldn't find one. Habey has a new model, based on the ATI Theater 750 HD chip, which is not supported. AVerMedia has some models too, but none seems to have analog mode working on Linux. Any suggestions would be kindly appreciated. We have MiniPCIe AnalogTV devices which are very well supported. Basically those devices are using the USB Pins of the MiniPCIe Bus. All worldwide standards are supported, we have ATSC/clearQAM/analogTV(NTSC)/VBI/FM-Radio/composite and s-video are available through reserved pin routing. A European version is also available. Tested applications * http://tvtime.sourceforge.net tvtime * http://www.videolan.org/vlc/ VLC * http://www.mplayerhq.hu/design7/news.html Linux mplayer * http://www.mythtv.org/ MythTV * http://linux.bytesex.org/xawtv/ XawTV * http://zapping.sourceforge.net/Zapping/index.html Zapping * http://ekiga.org/ Ekiga VOIP (Channel 0: TV Channel 1: Composite Channel 2: S-Video) * http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome Motion detection Software http://support.sundtek.com/index.php/topic,4.0.html Sent the wrong link, this one is for ATSC (the other one is the european version): http://support.sundtek.com/index.php/topic,87.0.html http://sundtek.com/images/vivi.png (some virtual driver emulation for testing) Setup shouldn't take longer than a few seconds Best Regards, Markus -- 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: Bounty for the first Open Source driver for Kinect
On Thu, Nov 11, 2010 at 12:08 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 11/10/2010 10:14 PM, Markus Rechberger wrote: On Wed, Nov 10, 2010 at 9:54 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: The bounty is already taken by that developer. But now, the Kinect thing is supported like a GPL userspace library. Maybe still need more work to be rewritten as a kernel module. This should better remain in userspace and interface libv4l/libv4l2 no need to make things more complicated than they have to be. As the author and maintainer of libv4l I say no, webcam drivers and the like belong in kernel space. libv4l is there to add things like format conversion (de-bayering in this case) which do not belong in userspace. Also there is no way to do 100% reliable isoc data handling from userspace. That's just your opinion we have 100% reliable isoc data handling in userspace, transferring 21 Mbyte/sec without any problem. And the driver works from 2.6.15 on - without recompiling. We're just about to release a new device in a few days, kernelsupport is absolutely not interesting since most distributions would not ship support for those devices at time of product release. Best Regards, Markus -- 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: Bounty for the first Open Source driver for Kinect
On Thu, Nov 11, 2010 at 1:13 AM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: On Thu, Nov 11, 2010 at 12:36 AM, Markus Rechberger mrechber...@gmail.com wrote: I've seen alot projects failing due not having enough users If it should mainly remain a hacker only project then a kernel module should be fine. sorry ? aside of that you can just debug userspace drivers with gdb, valgrind etc. if issues come up it will only affect your work not the entire system, kernel is seriously something critical. So you think that most of actual drivers which are inside the kernel are bad ? if it is inside the kernel it will be better maintained and fixed. External dependencies will break many things and add exceptions. You already got an answer for an issue similar to this from Linus Torvalds and Andrew Morton http://lkml.org/lkml/2007/10/10/244 As time goes on things evolve and change. Most of people want to download a kernel that just has all things inside. not search for other dependencies somewhere. If it is inside the kernel, many licensing problems will disappear. What if I want to develop something based on that userspace GPL library, should I search which license should I use (and there are many MIT/BSD/LGPL/...)? I'm not writing about open vs closed source just that userspace is more flexible for endusers (don't mix that up). Markus i -- 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: Bounty for the first Open Source driver for Kinect
On Wed, Nov 10, 2010 at 9:54 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: The bounty is already taken by that developer. But now, the Kinect thing is supported like a GPL userspace library. Maybe still need more work to be rewritten as a kernel module. This should better remain in userspace and interface libv4l/libv4l2 no need to make things more complicated than they have to be. Markus -- 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: Bounty for the first Open Source driver for Kinect
On Wed, Nov 10, 2010 at 10:24 PM, Antonio Ospite osp...@studenti.unina.it wrote: On Wed, 10 Nov 2010 22:14:36 +0100 Markus Rechberger mrechber...@gmail.com wrote: On Wed, Nov 10, 2010 at 9:54 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: The bounty is already taken by that developer. But now, the Kinect thing is supported like a GPL userspace library. Maybe still need more work to be rewritten as a kernel module. This should better remain in userspace and interface libv4l/libv4l2 no need to make things more complicated than they have to be. I can see at least two reasons for a kernel driver: 1. performance 2. out-of-the-box experience: the casual user who wants to just use kinect as a normal webcam doesn't have to care about installing some library out of the box experience libusb works everywhere, ARM/MIPS/PPC/etc. Kerneldrivers are usually not installed with those systems. Higher backward compatibility as well (shall go down to 2.6.15) with one compiled driver, relevant endusers do not want to compile believe me. Developers might want but that's another story. Markus If there are arguments against a kernel driver I can't see them yet. Ciao, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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: Bounty for the first Open Source driver for Kinect
On Thu, Nov 11, 2010 at 12:29 AM, Antonio Ospite osp...@studenti.unina.it wrote: On Thu, 11 Nov 2010 00:13:09 +0100 Markus Rechberger mrechber...@gmail.com wrote: On Wed, Nov 10, 2010 at 11:48 PM, Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: On Wed, Nov 10, 2010 at 10:24 PM, Antonio Ospite osp...@studenti.unina.it wrote: If there are arguments against a kernel driver I can't see them yet. [...] If I want to use this device, I will add many userspace code to create the skeleton model and that need much computation. Kernel Module adds performance to my other code. just some experience from our side, we do have fully working video4linux1/2 drivers in userspace, the only exception we have is a very thin layered kernelmodule in order to improve the datatransfer. Markus, can you point to some example so I can get a clearer picture? unfortunately we're closed source (and much more advanced) but you can have a look at other projects: * libv4l2 * freebsd has webcamd or something like that to emulate analog tv/webcams and dvb (they are even reusing linux kernel drivers with a userspace wrapper - so everything works in userspace for them). aside of that you can just debug userspace drivers with gdb, valgrind etc. if issues come up it will only affect your work not the entire system, kernel is seriously something critical. Markus Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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: dvb-c usb device
On Sun, Sep 19, 2010 at 1:33 AM, Antti Palosaari cr...@iki.fi wrote: On 09/18/2010 09:23 PM, Bert Haverkamp wrote: Every couple of months I scan this mailing list for the keywords usb and dvb-c, hoping that some new device has shown up that is supported Currently there is Anysee E30C Plus and Technotrend CT-3650. About Technotrend I am not 100% sure, but I have seen patch for adding DVB-C support for that device. There is many DRX-K devices, but no drivers yet. Also there is TDA10024 based Reddo available in Finland, but I haven't looked it. Thus only reliable one is Anysee. the biggest problem with Linux and DVB-C is getting HDTV work. 1. Nearly no distribution comes with codecs (and those who come are doing it in a not legal way - there are some) 2. Compiling fails for the masses (we've got exactly 3 opensource requests within 1 year). 3. graphiccard drivers are a mess (NVidia is doing the best job in getting their graphiccards work). We've been in contact with Trident for more than a year now they even visited our customers in order to help to improve the DVB-C quality of their solution. The main problem lies with earning revenue. If the chip manufacturer releases opensource drivers, all the product manufacturers will release the same which basically means there's no advantage for anyone anymore and this finally will lead to a pricefighting situation. The price will go down enough that it doesn't make any sense anymore to sell the product - definitely go down enough to not spend any money in RD for software. What can a product manufacturer do to improve this? nothing. And ultimately it will go back to the chip manufacturer because it's not worth for several companies to sell those products. We can just pick an example, Terratec. They used to offer Linux drivers. Finally they laid off all their software engineers. There's a company starting with P. which is now with a company which starts with H. offering 500 EUR/half year for Linux drivers. Since it's possible to drive those ICs from userspace the failure lies in the structure of this entire linux multimedia project, not being flexible enough for product manufacturers that's why we redeveloped everything and see it works. Those people who are into Linux use to scream loud but use to forget about the average people who are relevant for Manufacturers. I would recommend a situation where mainly the bridge datatransfer is in kernelspace configurable from userspace (we also have a kernel opensource bridge driver especially for embedded systems). The advantage of this is a. tuner configuration can be added in a flexible way from userspace at any time, providing backward compatibility to older kernels b. compiling drivers is no option for normal endusers. c. improved stability, since all the complex code is in userspace, the tuner/demod/etc configuration does not depend on speed either. d. bigger userbase, better testing since everyone at any time should be able to use the latest chipconfiguration package from userspace. e. manufacturers would have an easier possibility to provide support for their devices. sure this way is new but that's the way we went during the last 2 years and we pretty much succeeded in the linux area with that. After all it's only about providing good multimedia support to the enduser. Best Regards, Markus -- 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: Hauppauge PCTV DVB-S2 STICK 460E USB 2.0
On Tue, Aug 24, 2010 at 4:20 PM, Halim Sahin halim.sa...@t-online.de wrote: Hi, On Di, Aug 24, 2010 at 10:46:19 +0800, Markus Rechberger wrote: Although we are not working on that one, we are about to release another DVB-S/S2 USB Stick with full Linux support at around the end of september. What about usb ci? At least in germany a dvb-c stick without ci is useless. Do some research about Dream Multimedia / Dreambox (I'm not writing more about this topic, google can shed some more light on this). Best Regards, Markus -- 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: Hauppauge PCTV DVB-S2 STICK 460E USB 2.0
On Tue, Aug 24, 2010 at 9:42 PM, Goga777 goga...@bk.ru wrote: does somebody work under Linux drivers for this dvb-s2 stick ? Although we are not working on that one, we are about to release another DVB-S/S2 USB Stick with full Linux support at around the end of september. http://www.sundtek.de/images/kaffeine-dvbs2.png Including, MIPS (eg. Dreambox, Netgear WNDR3700, etc), ARM (various NAS and Linux Router systems), PPC, X86/32/64 support and network streaming capability plus official Linux support. which tuner and demodulator using ? have you any photos ? only, http://sundtek.de/images/sundtek-dvbs2.png Best Regards, Markus -- 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: Hauppauge PCTV DVB-S2 STICK 460E USB 2.0
On Tue, Aug 24, 2010 at 3:40 AM, Goga777 goga...@bk.ru wrote: hi does somebody work under Linux drivers for this dvb-s2 stick ? Although we are not working on that one, we are about to release another DVB-S/S2 USB Stick with full Linux support at around the end of september. http://www.sundtek.de/images/kaffeine-dvbs2.png Including, MIPS (eg. Dreambox, Netgear WNDR3700, etc), ARM (various NAS and Linux Router systems), PPC, X86/32/64 support and network streaming capability plus official Linux support. Best Regards, Markus Goga -- 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: [PULL] http://kernellabs.com/hg/~mkrufky/raw-payload
On Sat, Jun 19, 2010 at 8:09 PM, Michael Krufky mkru...@kernellabs.com wrote: Mauro, This adds the ability for drivers to send the received raw payload to the dvr device, in cases of newer delivery systems that do not deliver transport stream and do not require usage of the kernel demux. In these cases, the data can be fully decoded by a userspace application / library. For a driver to deliver the raw payload, simply use the function dvb_dmx_swfilter_raw instead of dvb_dmx_swfilter or RAW without an additional identifier doesn't make much sense, how should an application figure out what a RAW stream is? Is it network data? is /dev/urandom data? how should that be handle by an application. There should be another 'hint' somewhere about the fileformat. This somewhat influences the internal/external DVB API, without proper identification it shouldn't be added as it is. Markus dvb_dmx_swfilter_204, as shown in the dvb-usb patch. Please pull from: http://kernellabs.com/hg/~mkrufky/raw-payload for the following: - dvb-demux: add functionality to send raw payload to the dvr device - dvb-usb: add support for dvb-usb-adapters that deliver raw payload dvb-core/dvb_demux.c | 11 +++ dvb-core/dvb_demux.h | 2 ++ dvb-usb/dvb-usb-urb.c | 10 ++ dvb-usb/dvb-usb.h | 1 + 4 files changed, 24 insertions(+) Cheers, Mike Krufky -- 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: [PULL] http://kernellabs.com/hg/~mkrufky/raw-payload
On Sat, Jun 19, 2010 at 10:12 PM, Michael Krufky mkru...@kernellabs.com wrote: On Sat, Jun 19, 2010 at 4:00 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sat, Jun 19, 2010 at 8:09 PM, Michael Krufky mkru...@kernellabs.com wrote: Mauro, This adds the ability for drivers to send the received raw payload to the dvr device, in cases of newer delivery systems that do not deliver transport stream and do not require usage of the kernel demux. In these cases, the data can be fully decoded by a userspace application / library. For a driver to deliver the raw payload, simply use the function dvb_dmx_swfilter_raw instead of dvb_dmx_swfilter or RAW without an additional identifier doesn't make much sense, how should an application figure out what a RAW stream is? Is it network data? is /dev/urandom data? how should that be handle by an application. There should be another 'hint' somewhere about the fileformat. This somewhat influences the internal/external DVB API, without proper identification it shouldn't be added as it is. Markus, raw as in, untouched, directly received from the device. Another word can be used to describe it- pass-thru ... I think raw suffices, however. It's not specific to any format. then it should take a raw driver and not use the DVB API for this. Applications might not handle any kind of RAW if you don't tell them what format it is. Markus -- 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: [PULL] http://kernellabs.com/hg/~mkrufky/raw-payload
On Sat, Jun 19, 2010 at 10:17 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sat, Jun 19, 2010 at 10:12 PM, Michael Krufky mkru...@kernellabs.com wrote: On Sat, Jun 19, 2010 at 4:00 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sat, Jun 19, 2010 at 8:09 PM, Michael Krufky mkru...@kernellabs.com wrote: Mauro, This adds the ability for drivers to send the received raw payload to the dvr device, in cases of newer delivery systems that do not deliver transport stream and do not require usage of the kernel demux. In these cases, the data can be fully decoded by a userspace application / library. For a driver to deliver the raw payload, simply use the function dvb_dmx_swfilter_raw instead of dvb_dmx_swfilter or RAW without an additional identifier doesn't make much sense, how should an application figure out what a RAW stream is? Is it network data? is /dev/urandom data? how should that be handle by an application. There should be another 'hint' somewhere about the fileformat. This somewhat influences the internal/external DVB API, without proper identification it shouldn't be added as it is. Markus, raw as in, untouched, directly received from the device. Another word can be used to describe it- pass-thru ... I think raw suffices, however. It's not specific to any format. then it should take a raw driver and not use the DVB API for this. Applications might not handle any kind of RAW if you don't tell them what format it is. eg. what will happen when kaffeine requests some data? I hardly doubt that it will be able to handle a raw format. You just have to be more specific with your proposed API changes. RAW + identifier somewhere about what data it is might help the applications to get along with it. And if possible don't try to break existing applications. Markus -- 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: Is anybody working on TechniSat CableStar Combo HD CI USB device?
On Tue, Jun 8, 2010 at 10:03 AM, Jan-Pascal van Best janpas...@vanbest.org wrote: On Tue, June 8, 2010 08:26, Tobias Maier wrote: The Micronas DRX series seems to 'evil' in that there is only a closed-source driver and the manufacturer doesn't cooperate with open source developers. Have you asked them or are you simply asuming this because there is no open source driver? It is important to notice that the vendor (Trident) doesn't seem to want helping with open source development. Contacts with the vendor were tried during 2007 and 2008 in order to get their help by opening docs, via Linux Foundation NDA program, without success. The vendor also seems to be refusing so far to help the development of a driver for their demod DRX-K line that they acquired from Micronas (as pointed at http://linux.terratec.de/tv_en.html). (http://www.linuxtv.org/wiki/index.php/Trident_TM6000) We have been working on getting those chipsets work with our devices. http://sundtek.com/shop/Digital-TV-Sticks/Sundtek-MediaTV-Digital-Home-DVB-CT.html Trident is also still improving the quality of their driver and firmware, it very much makes sense that they handle their driver especially since those DRX drivers are very complex (basically too complex for being handled by the community, the drivers would just end up somewhere unmaintained). Best Regards, Markus -- 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: Is anybody working on TechniSat CableStar Combo HD CI USB device?
On Tue, Jun 8, 2010 at 12:14 PM, Bjørn Mork bj...@mork.no wrote: Markus Rechberger mrechber...@gmail.com writes: Trident is also still improving the quality of their driver and firmware, it very much makes sense that they handle their driver especially since those DRX drivers are very complex (basically too complex for being handled by the community, the drivers would just end up somewhere unmaintained). Ouch. That makes me wonder about the state of the Windows drivers for those devices... Better stay away from them, I guess. If you have issues with your Windows driver you should contact the manufacturer of your device. If they care about their product and/or some customer relation they will try to help you. Markus -- 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: What ever happened to standardizing signal level?
Hi, A little bit more ontopic, did anyone get around to read the signallevel of the tda18721? I wonder the register does not return any signallevel as indicated in the specifications. Markus -- 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: What ever happened to standardizing signal level?
On Sun, May 30, 2010 at 5:21 PM, Michael Krufky mkru...@linuxtv.org wrote: Markus Rechberger wrote: Hi, A little bit more ontopic, did anyone get around to read the signallevel of the tda18721? I wonder the register does not return any signallevel as indicated in the specifications. Markus There is a power level value that can be read from the tda18271 -- I had a patch that enabled reading of this value, for testing purposes, but it wasn't as useful as I had hoped, so I never bothered to merge it. If you'd like to play with it, I pushed up some code last year: http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29 Let me know how this works for you, or if you choose to change it. I If you find it valuable, we can merge it in somehow. hmm.. I somewhat tried the same but the register kept flipping back and the powerlevel register returned 0. Markus -- 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: ideal DVB-C PCI/e card? [linux-media]
On Wed, May 26, 2010 at 7:00 AM, Jed jedi.the...@gmail.com wrote: Ideally it'd be dual DVB-C, the only one I've found is more than dual DVB-C is far too expensive. If you need two receivers but can only spare up to one PCI or PCIe slot, why not use two USB or FireWire attached receivers? FireWire ones seem to be out of production now though and weren't exactly on the cheap side. OTOH one can drive up to 3 DVB FireWire receivers on a single FireWire bus; and for those who need even more there are dual link FireWire PCI and PCIe cards readily available. Thanks for offering your thoughts Stefan. Any specific recommendations? Ideally I want two or more dvb-c tuners in a pci/e form-factor. If there's FW or USB tuners that are mounted onto a PCI/e card, work well in Linux, are relatively cheap, then I'd love to know! I don't have an overview over USB tuners. We have USB DVB-C/T hybrid devices which are supported with Linux. http://support.sundtek.com/index.php/topic,4.0.html (the driver is mostly independent from Linux Kernels). Aside of that we just made it work on a Dreambox 800 (300 Mhz MIPS as well, and looking forward to support other platforms as well). http://sundtek.com/shop/Digital-TV-Sticks/Sundtek-MediaTV-Digital-Home-DVB-CT.html Best Regards, Markus Thanks but I'd prefer PCI/e form-factor... If there's something fw or usb-based x2, squeezed into that form-factor, I'm very interested! I may only have room for 1x pci/e dvb-c card (hopefully one that has two single fw tuners mounted). So I may still look at USB based tuners like yours... There are also MiniPCIe USB DVB-C/T solutions available, although we have only seen single PCIe - MiniPCIe solutions yet (and those required an additional internal USB connection for the USB part) Another option might be a PCI/PCIe USB Bridge + USB DVB-C, we tested 3x USB DVB-C devices with a notebook at the same time (maybe 4 are possible, our test PC only had 3x USB Slots back then). Markus -- 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: ideal DVB-C PCI/e card? [linux-media]
On Wed, May 26, 2010 at 9:01 AM, Jed jedi.the...@gmail.com wrote: Not sure what you mean, I don't suppose you could clarify? You mean I might be able to buy 2x mini-PCIe cards that can be mounted onto a PCIe - USB bridge then that card (bridge) will have two usb cables that need to be connected to 2 USB headers on the motherboard? If yes, that'd be fairly pricey wouldn't it? I'm only writing about the technical possibilities. Personally I prefer the USB Dongles, since they are flexible. Once you leave your home you can just unplug the DVB-C tuner connect it to a notebook/netbook and use it for FM, analog TV or DVB-T. Markus -- 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: ideal DVB-C PCI/e card? [linux-media]
I'm only writing about the technical possibilities. Personally I prefer the USB Dongles, since they are flexible. Once you leave your home you can just unplug the DVB-C tuner connect it to a notebook/netbook and use it for FM, analog TV or DVB-T. Markus Oh, so you're not aware of anything like that, which is purchasable? I am not aware of any dual dvb-c PCI/PCIe only device. Markus -- 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: Analog FM radio support for dib0700
On Mon, May 10, 2010 at 8:11 PM, Mirek Slugeň thunde...@email.cz wrote: Hi, I am working on project for monitoring analog FM radio stations in our Country and I need to find USB device which is supported under Linux including FM radio. I can't find such device for very long time (6 months), only AverTV Volar HX with binary drivers and very unstable linux drivers. So I am considering to pay for analog FM radio support for dib0700 devices. + I need this support in next 25 days, later is too late. + I can pay for adding FM radio maximum 1000 USD or 800 EUR (it depends on many factors such as accepting patches by linuxtv tree). If there is anyone intereseted please write me message. * FM Radio (including RDS) * Analog TV * Digital TV http://support.sundtek.com/index.php/topic,4.0.html Those devices are also used in the industrial field, depending on the volume we can also provide FM Radio USB dongles only (USB Audio Class based) That way you can get started quickly with your project. Best Regards, Markus Rechberger -- 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: ideal DVB-C PCI/e card?
On Mon, May 3, 2010 at 5:39 PM, Jed jedi.the...@gmail.com wrote: Excellent response, thank-you for so much detail! I apologise for my anaemic response, but it is very late here now, that's my excuse anyway! ;) Just curious, why did you pick VDR over MythTV? I would rather use the later + OSCam (maybe) if feasible. Thanks again for the excellent feedback, it's heartening to know there's other videoguard2 users out there! Good-night. On 3/05/10 5:49 PM, Bjørn Mork wrote: [answering this in private since any details about softcams etc usually is unwanted on mailinglists] Jedjedi.the...@gmail.com writes: I was wondering if someone could recommend a decent DVB-C tuner card? Ideally it would be a dual DVB-C card, but I'm not sure they exist?! I've been looking for the same, but not been able to find one. The closest is the foilware from Netup, but it is probably going to be too expensive when/if it is available anyway. Nor does there seem to be any DVB-C PCIe cards or USB sticks with Linux support. There are rumours about working external USB boxes. I haven't verified those, as I didn't really want any external box adding to the cable mess... There are a few DVB-C/T/(analogTV) USB devices, our USB Sticks are well supported and tested with Linux. http://support.sundtek.com/index.php/topic,7.0.html Aside of that we used to provide free USB Sticks to some opensource application developers as well (eg. easyVDR, tvheadend developers) Markus -- 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: RFC: exposing controls in sysfs
On Tue, Apr 6, 2010 at 1:27 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Andy, On Tuesday 06 April 2010 13:06:18 Andy Walls wrote: On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote: [snip] Again, I still don't know whether we should do this. It is dangerously seductive because it would be so trivial to implement. It's like watching ships run aground on a shallow sandbar that all the locals know about. The waters off of 'Point /sys' are full of usability shipwrecks. I don't know if it's some siren's song, the lack of a light house, or just strange currents that deceive even seasoned navigators Let the user run 'v4l2-ctl -d /dev/videoN -L' to learn about the control metatdata. It's not as easy as typing 'cat', but the user base using sysfs in an interactive shell or shell script should also know how to use v4l2-ctl. In embedded systems, the final system deployment should not need the control metadata available from sysfs in a command shell anyway. I fully agree with this. If we push the idea one step further, why do we need to expose controls in sysfs at all ? how about security permissions? while you can easily change the permission levels for nodes in /dev you can't do this so easily with sysfs entries. I don't really think this is needed at all some applications will start to use ioctl some other apps might go for sysfs.. this makes the API a little bit whacko Markus -- 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
V4L2 application compliance testing
Hi, we recently got around to test several video4linux2 applications and noticed that quite a few kernel drivers do not provide support properly testing applications for v4l2 compliance. http://sundtek.de/images/vivi.png we ported and modified the vivi to userspace, the testpackage is supposed to work with x86-64/x86-32/arm (eabi4/oabi)/mips and ppc(32/64), This virtual driver is also supposed to support all systems starting from Debian Potato (32bit) on. A quick shot for installing and testing: $ wget http://sundtek.de/media/sundtek_installer.sh $ chmod 777 sundtek_installer.sh $ ./sundtek_installer.sh adding a virtual driver (run this for each virtual interface you want to have): $ /opt/bin/mediaclient --tvdummy displaying the virtual device information: $ /opt/bin/mediaclient -e List of Media Hardware Devices device 1: [Virtual Video (vivi) Capture Board] ANALOG-TV [ANALOG-TV]: VIDEO0: /dev/video2 deleting the virtual device: $ /opt/bin/mediaclient --remove=[deviceid as indicated with mediaclient -e] to remove the package $ ./sundtek_installer -u So far we tested: * VLC (v4l1) * VLC (v4l2) * tvtime * mplayer * motion (v4l1) * ekiga * MythTV * xawtv * Zapping (poorly this application does not work with all distributions anymore since it's not maintained anymore). The virtual driver prints the frequency into the video when testing the tuner. If this driver works out with your application you can be sure that most legacy videodrivers will also work with your TV application. Aside of that we're also about to release the FreeBSD and Mac ports for the virtual driver (the package basically ports the V4L1/V4L2 interface to all other operating systems). Markus -- 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: RFC: Drop V4L1 support in V4L2 drivers
On Fri, Mar 19, 2010 at 9:46 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Friday 19 March 2010 08:59:08 Hans Verkuil wrote: Hi all, V4L1 support has been marked as scheduled for removal for a long time. The deadline for that in the feature-removal-schedule.txt file was July 2009. I think it is time that we remove the V4L1 compatibility support from V4L2 drivers for 2.6.35. Do you mean just removing V4L1-specific code from V4L2 drivers, or removing the V4L1 compatibility layer completely ? The compat layer as well. So the only V4L1 code left is that for V4L1-only drivers. I'm against this we have customers using the compat layer. Aside of that the compat layer doesn't hurt anyone, newer more serious applications are written with v4l2 only actually. This means that V4L2 drivers can only be used by V4L2-aware applications and can no longer be accessed by V4L1-only applications. It would help with the videobuf cleanup as well, but that's just a bonus. Do we still have V4L1-only drivers that use videobuf ? No V4L1-only drivers use videobuf, but videobuf has support for the V4L1 compat support in V4L2 drivers (the cgmbuf ioctl). So when we remove the compat support, then that videobuf code can be removed as well. that's just a bad implementation then and just should be fixed up the compat layer can handle this quite elegant. -Markus -- 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] Looking for Linux drivers for AVerMedia tuner or Leadtek tuner
On Sat, Feb 20, 2010 at 1:44 AM, Michael Angeli mang...@iconfitness.com wrote: Hello, Looking for Linux drivers for Avermedia Tuners per the following URLs http://www.avermedia.com/AVerTV/Product/ProductDetail.aspx?Id=378 http://www.avermedia.com/AVerTV/Product/ProductDetail.aspx?Id=482SI=true http://www.avermedia.com/avertv/Product/ProductDetail.aspx?Id=480SI=true Or a linux driver for the Leadtek Mini PCI TV tuner LR6648 with PCI express Bridge SAA7160ET Maybe this product might be interesting for you: http://sundtek.com/shop/Digital-TV-Sticks-oxid/Sundtek-MediaTV-MiniPCIe-DVB-CT-FM-AnalogTV.html * DVB-C / DVB-T (ATSC / ClearQAM is also available) * Analog TV * FM Radio * VBI * Standby support * MiniPCIe * Driver: ARM, MIPS, PPC, X86-32, X86-64 Best Regards, Markus -- 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: More details on Hauppauge 930C
On Mon, Jan 25, 2010 at 3:11 AM, Jakob Bohm saotowjokkoujux...@jbohm.dk wrote: So far all the posts I have been able to find about this device on wiki.linuxtv.org and in the archives of the linux-tv, linux-dvb and linux-media mailing lists have been unconfirmed guesswork of the form I think, Isn't that etc. I actually have this device (it was the first DVB-C device to hit the market in Denmark after our biggest cable TV provider offered unencrypted access to their basic packages in DVB-C format for anyone with a paid physical connection to their network). Ok, first the bad news: When looking inside the device I see two Micronas chips, thus *apparantly* confirming the rumors about this device being based on the Micronas chips for which Micronas lawyers blocked release of an already written FOSS driver back in 2008. But to be sure these are the banned chips, someone in the know should look closely at the photos I have taken of the actual chips in the 930C. Second bad news: When asking Hauppauge all the response I got was You need to post on the www.linuxtv.org site, that's where the devlopers are (and thats all the e-mail said, including the spelling mistake in devlopers). Now the observable facts: 1. Product name is Hauppauge 930C, model 16009 LF Rev B1F0, USB ID 2040:1605 . Retail package includes device, a short video cable adapter for the minisocket on the device, an IR remote, a small table-top retractable antenna and a CD with MS-Windows software and drivers. 2. Device is a combined DVB-C/DVB-T receiver with additional inputs for raw analog video as S-VHS or composite (either with separate analog stereo sound). I do not recall if the device has support for analog TV reception too. 3. Device is not yet listed in the device tables at linuxtv.org with any status (not even doesn't work). 4. Device is a large (= wide body) USB stick, with a standard size coaxial antenna input at the back, two indicator LEDs and an IR receiver on the right and a proprietary mini-socket for analog video/audio input on the left. The underside has a sticker with bar code, model number and MAC address. 4. I have taken close up photos of the device with and without the covers off. The inside of the device holds two circuit boards with some components hidden between them, I have taken photos or the outward facing sides of the two boards. I have posted the photos at these URLs: http://www.jbohm.org/930C/frontAndCable.jpg http://www.jbohm.org/930C/back.jpg http://www.jbohm.org/930C/boardFront.jpg http://www.jbohm.org/930C/boardBack.jpg (Please copy the photos to your own archives, these are temporary URLs). And finally something worth investigating: Some time has passed since Micronas Lawyers blocked the release of the FOSS driver for their chipset, maybe they have cooled down now and someone from the linuxtv project could approach Hauppauge or Pinacle (who seem FOSS-friendly) to put business pressure on their chipset supplier Micronas to reverse their decision and permit the release of the FOSS driver that was previously developped in cooperation between Pinacle, Micronas techs and Devin Heitmueller (one of the linuxtv developers). It hasn't been in Micronas hands for a long time anymore. Micronas had financial trouble and sold this devision to Trident. So far we (Sundtek) found an agreement to publish their propriertary work under closed source but with support for opensource applications in Linux in userspace not affecting the kernel. Best Regards, Markus -- 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: Drivers for Eyetv hybrid
On Thu, Jan 21, 2010 at 10:55 AM, Morten Friesgaard friesga...@gmail.com wrote: To bad. I bought this tuner because of the cross platform compability :-/ Well, it looks awfully alot like the TerraTec H5, would there be a driver this one? http://www.terratec.net/en/products/TerraTec_H5_83188.html just fyi. this Terratec device is not supported. We've been working on a device with equivalent features (DVB-T/C/AnalogTV/VBI/Composite/S-Video/FM-Radio/RDS/Remote Control) http://support.sundtek.com/index.php/topic,4.0.html We are also integrating additional flexible USB CI support for it. Best Regards, Markus Rechberger -- 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: Info
On Mon, Jan 18, 2010 at 5:17 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Jan 18, 2010 at 11:03 AM, Adriano Gigante adrig...@yahoo.it wrote: Hi Devin, The 0ccd:0043 is on my todo list of devices to work on (they sent me a sample board), although it's not the highest priority on my list given how old it is. Did they sent you also a 0ccd:0072 card (Terratec Cinergy Hybrid T USB XS FM)? Adri Terratec sent me two boards: 0ccd:0072 and 0ccd:0043. I've actually been working with a user on the #linuxtv irc channel who is in the process of getting the 0ccd:0072 board to work (username Prahal). He's making great progress, but if he gets stuck I will find some cycles to work through whatever problem he finds. Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm (cx25843 - xc5000): http://img91.imageshack.us/i/0004qf8.png/ http://img104.imageshack.us/i/0009cp4.png/ nothing that can be fixed with the driver. Markus -- 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: Info
On Mon, Jan 18, 2010 at 5:36 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hello Markus, On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger mrechber...@gmail.com wrote: Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm (cx25843 - xc5000): http://img91.imageshack.us/i/0004qf8.png/ http://img104.imageshack.us/i/0009cp4.png/ nothing that can be fixed with the driver. Interesting. If it cannot be fixed with the driver, how does the Windows driver work then? Is this some sort of premature hardware failure that occurs (after which point it is irreversible)? conexant cx25843 - xceive xc5000 failure (as what I've heard conexant laid off people in that area years ago while xceive (see their driver changelog if you have access to it) tried to fix it with their firmware but didn't succeed), it also happens with windows. Those screenshots are taken from a videoclip it was of course a big problem for business customers (almost all of them happily switched away from it) This is the same retail hardware as everyone else uses out there. XS FM is not being sold anymore. I only know one company in Ireland still sticking with it, also in terms of videoquality I'd avoid that combination. Markus Thanks for taking the time to point this out though, since I could totally imagine banging my head against the wall for quite a while once I saw this. 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: Info
On Mon, Jan 18, 2010 at 7:50 PM, fogna fogn...@gmail.com wrote: Il 01/18/2010 06:33 PM, Markus Rechberger ha scritto: On Mon, Jan 18, 2010 at 5:36 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hello Markus, On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger mrechber...@gmail.com wrote: Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm (cx25843 - xc5000): http://img91.imageshack.us/i/0004qf8.png/ http://img104.imageshack.us/i/0009cp4.png/ nothing that can be fixed with the driver. Interesting. If it cannot be fixed with the driver, how does the Windows driver work then? Is this some sort of premature hardware failure that occurs (after which point it is irreversible)? conexant cx25843 - xceive xc5000 failure (as what I've heard conexant laid off people in that area years ago while xceive (see their driver changelog if you have access to it) tried to fix it with their firmware but didn't succeed), it also happens with windows. Those screenshots are taken from a videoclip it was of course a big problem for business customers (almost all of them happily switched away from it) This is the same retail hardware as everyone else uses out there. XS FM is not being sold anymore. I only know one company in Ireland still sticking with it, also in terms of videoquality I'd avoid that combination. Markus Thanks for taking the time to point this out though, since I could totally imagine banging my head against the wall for quite a while once I saw this. 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 Hi Markus, thanks for the info, i didn't know of this hardware problem, i have this usb stick and at the moment all works normally, now i know when it will be time to replace it :) it happens sporadically sometimes 1 time/5 minutes sometimes 1 time/10 minutes. I think in windows it sometimes drops frames it also happens there and can be seen with VLC maybe some codecs also compensate it a little bit. There's no generic rule about this the xc5000 overdrives the videodecoder (it's not empia related issue actually moreover conexant/xceive) Markus -- 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: CI USB
On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- 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] SheevaBox as a media Server and a Fit-PC as a streaming client?
Hi, On Wed, Dec 16, 2009 at 4:12 PM, Lothar Behrens lothar.behr...@lollisoft.de wrote: Hi, I am new here and start with a setup question. The media or NAS server I think about: http://plugcomputer.org/ It has a high speed USB 2.0 port and a gigabit Lan. http://support.sundtek.com/index.php/topic,179.0.html (english) http://support.sundtek.com/index.php/topic,178.0.html (german) This might be interesting for you. Markus -- 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: Pinnacle PCTV Hybrid (2) dvb woes
On Mon, Dec 21, 2009 at 12:40 AM, Pedro Ribeiro ped...@gmail.com wrote: On Sun, Dec 20, 2009 at 6:32 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sun, Dec 20, 2009 at 12:07 PM, Pedro Ribeiro ped...@gmail.com wrote: Hello all, I'm having trouble setting up DVB for my Pinnacle PCTV Hybrid Stick (2), AKA 330e. You can check the linux-media archives for more info, but I can tell you that the 330e is not currently supported for DVB mode (analog only). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Damn, I suspected that. Anyway, I'm having trouble viewing analog TV. I can scan and watch channels fine, but there is no audio, and I don't know how to configure it. If you could help me, I would really appreciate it Should I use the em28xx soundcard for output or my own internal soundcard? tvtime only uses ALSA, but my internal soundcard as OSS mixer emulation (the em28xx has not). However, I cannot control the volume in tvtime Alsa says that the em28xx soundcard has no mixer controls. for some reason I would say to sell the card and buy another device (which one?) Pinnacle never wanted to pay developers, although they were interested in Linux drivers. Their max offer was 500 eur/half year for writing a linux driver for them. Devin is smart enough to work for them for free (smart dude!). Since I got that offer on the phone I denied to do any work for them anymore. Even though if it is opensource (with an obvious bad quality) it should not be free for them). But this also explains their previous quality of the windows software. Nowadays PCTV Systems is selling half working hardware in eastern Europe (wonder why they are not selling it in Germany, fear of getting sued by someone?)... Markus -- 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: Pinnacle PCTV Hybrid (2) dvb woes
On Mon, Dec 21, 2009 at 1:11 AM, Pedro Ribeiro ped...@gmail.com wrote: On Sun, Dec 20, 2009 at 11:57 PM, Markus Rechberger mrechber...@gmail.com wrote: On Mon, Dec 21, 2009 at 12:40 AM, Pedro Ribeiro ped...@gmail.com wrote: On Sun, Dec 20, 2009 at 6:32 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sun, Dec 20, 2009 at 12:07 PM, Pedro Ribeiro ped...@gmail.com wrote: Hello all, I'm having trouble setting up DVB for my Pinnacle PCTV Hybrid Stick (2), AKA 330e. You can check the linux-media archives for more info, but I can tell you that the 330e is not currently supported for DVB mode (analog only). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Damn, I suspected that. Anyway, I'm having trouble viewing analog TV. I can scan and watch channels fine, but there is no audio, and I don't know how to configure it. If you could help me, I would really appreciate it Should I use the em28xx soundcard for output or my own internal soundcard? tvtime only uses ALSA, but my internal soundcard as OSS mixer emulation (the em28xx has not). However, I cannot control the volume in tvtime Alsa says that the em28xx soundcard has no mixer controls. for some reason I would say to sell the card and buy another device (which one?) Pinnacle never wanted to pay developers, although they were interested in Linux drivers. Their max offer was 500 eur/half year for writing a linux driver for them. Devin is smart enough to work for them for free (smart dude!). Since I got that offer on the phone I denied to do any work for them anymore. Even though if it is opensource (with an obvious bad quality) it should not be free for them). But this also explains their previous quality of the windows software. Nowadays PCTV Systems is selling half working hardware in eastern Europe (wonder why they are not selling it in Germany, fear of getting sued by someone?)... Markus -- 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 500 euro for half a year? What an insult! Exactly what I thought, I know alot more stories nowadays actually... Well I thought of buying a new one, better supported in Linux. But they are very expensive, and someone offered me the 330e :( They are interested in Linux drivers, but yes it is absolutely insulting for every software engineer. The offer came from a manager who is rather hardware focused. Markus -- 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: [PATCH] gspca sunplus: propagate error for higher level
2009/11/30 Jean-Francois Moine moin...@free.fr: On Sun, 29 Nov 2009 13:15:37 +0100 Németh Márton nm...@freemail.hu wrote: I think that the return value of the usb_control_msg() is to be evaluated. If other drivers also not evaluating the usb_control_msg() *they* has to be fixed. The benefit would be that the userspace program can recognise error condition faster and react accordingly. For example the USB device can be unplugged any time. In this case there is no use to continue sending URBs. Otherwise the user program thinks that everything went on correctly and the user will be surprised how come that he or she unplugged a device and it is still working. I see 2 cases for getting errors in usb control messages: - there are permanent problems in the USB subsystem - device disconnection The first case is detected immediately at probe time and the device will not run (/dev/videon not created) On device disconnection, if streaming is active, it is be stopped and the device is marked for deletion. The only way to get errors in usb control message is to change some control value at the same time the device disconnects (i.e. disconnection while the ioctl runs in the subdriver). The probability for this to occur is surely less than 10**-9. Otherwise, once the disconnection is seen, no IO may be performed. If you want absolutely to propagate the errors at higher level, the simplest way is to have an 'error' variable in the gspca descriptor. You set it to 0 in gspca.c before calling the subdriver (i.e. just after getting the usb_lock), you check it before calling usb_control_msg (in the low level routines reg_r, reg_w..) , you set it if this last function returns an error, and you get its value before releasing the usb_lock. In this way, there are less changes and less code overhead. an example from one of my customers, there's one customer who uses a USB VOIP device, the device is actually bad designed and regulary hangs up and sometimes even resets the entire usb stack. That customer was previously using the em28xx kernel driver (which for some reason actually locked up the entire USB device/if it didn't cause some other corruptions...) Every check can just be appreciated, for sure alot usb kernel drivers do not handle errors properly at critical codeparts. Trent Piepho once suggested a macro for writing blocks of registers, this looked just fine actually. Markus -- 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: DVB support for MSI DigiVox A/D II and KWorld 320U
On Fri, Nov 13, 2009 at 4:37 PM, Lauri Laanmets lauri.laanm...@proekspert.ee wrote: Hello I have managed to attach the device without any error messages now but the tuning and playback of DVB still doesn't work. I get a lot of these error messages: [ 247.268152] em28xx #0: reading i2c device failed (error=-110) [ 247.268161] xc2028 1-0061: i2c input error: rc = -110 (should be 2) and [ 433.232124] xc2028 1-0061: Loading SCODE for type=DTV6 ATSC OREN538 SCODE HAS_IF_5580 (60110020), id . [ 433.256017] xc2028 1-0061: Incorrect readback of firmware version. [ 433.372019] xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3), id . [ 437.940029] xc2028 1-0061: Loading firmware for type=D2620 DTV78 (108), id . Do anybody have an idea what to do next? Or maybe somebody is willing to help me understanding the mcentral code because that one works fine. Due some fundamental problems we do not recommend to use the em28xx-new code, it can damage your device(!) We are now working together with several manufacturers since we accepted their restrictions we got indepth details about how to handle those devices correctly in order to prevent damaged devices. Even if it works fine for you it might break the device the next day. The only way to get it right is to cooperate with the chip design companies. Markus -- 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: Details about DVB frontend API
On Fri, Oct 23, 2009 at 9:02 PM, VDR User user@gmail.com wrote: On Thu, Oct 22, 2009 at 1:29 PM, Manu Abraham abraham.m...@gmail.com wrote: Sometime back, (some time in April) i proposed a patch which addressed the issue to scale even those devices which have a weird scale or none. Though based on an older tree of mine, here is the patch again. If it looks good enough, i can port the patch to accomodate other devices as well. Thanks for posting your patch. How about people get some discussion going about the pros/cons instead of ignoring it? The best method for the most devices needs to be the deciding factor here, not accepting/disregarding based on who your friends are. For once it would be nice if the childish politics could get throw out and what's best for v4l be the highest priority. And a thanks to anyone else that would like to submit a recommendation on how to deal with this. Hopefully there will be a few solid proposals to consider. it would be good to have a table what statistics can be returned, obviously the API implementation doesn't matter so much. Manu, Mike can you start a wiki site on linuxtv.org addressing this topic? Please work out a proper API definition first, afterwards think about the implementation. The correct implementation in the enduser applications is by far more important. Best Regards, Markus -- 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: Details about DVB frontend API
On Thu, Oct 22, 2009 at 10:29 PM, Manu Abraham abraham.m...@gmail.com wrote: On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Thu, 22 Oct 2009 21:13:30 +0200 Jean Delvare kh...@linux-fr.org escreveu: Hi folks, I am looking for details regarding the DVB frontend API. I've read linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS commands return, however it does not give any information about how the returned values should be interpreted (or, seen from the other end, how the frontend kernel drivers should encode these values.) If there documentation available that would explain this? For example, the signal strength. All I know so far is that this is a 16-bit value. But then what? Do greater values represent stronger signal or weaker signal? Are 0x and 0x special values? Is the returned value meaningful even when FE_HAS_SIGNAL is 0? When FE_HAS_LOCK is 0? Is the scale linear, or do some values have well-defined meanings, or is it arbitrary and each driver can have its own scale? What are the typical use cases by user-space application for this value? That's the kind of details I'd like to know, not only for the signal strength, but also for the SNR, BER and UB. Without this information, it seems a little difficult to have consistent frontend drivers. We all want to know about that ;) Seriously, the lack of a description of the meaning of the ranges for those read values were already widely discussed at LMML and at the legacy dvb ML. We should return this discussion again and decide what would be the better way to describe those values. My suggestion is that someone summarize the proposals we had and give some time for people vote. After that, we just commit the most voted one, and commit the patches for it. A pending question that should also be discussed is what we will do with those dvb devices where we simply don't know what scale it uses. There are several of them. Sometime back, (some time in April) i proposed a patch which addressed the issue to scale even those devices which have a weird scale or none. Though based on an older tree of mine, here is the patch again. If it looks good enough, i can port the patch to accomodate other devices as well. A few of our customers were requiring additional statistic information, so we added follwing command to our DVB API: FE_GET_SIGQUALITY struct media_sigquality { uint16_t MER; /** in steps of 0.1 dB */ uint32_t preViterbiBER ; /** in steps of 1/scaleFactorBER */ uint32_t postViterbiBER ; /** in steps of 1/scaleFactorBER */ uint32_t scaleFactorBER; /** scale factor for BER */ uint32_t packetError ; /** number of packet errors */ uint32_t postReedSolomonBER ; /** in steps of 1/scaleFactorBER */ uint32_t indicator;/** indicative signal quality low=0..100=high */ } It's a one shot request. it might be good to standardize this, although we can live with that additional command too. Best Regards, Markus -- 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: ISDB-T tuner
On Mon, Oct 19, 2009 at 9:29 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi Romont, Em Mon, 19 Oct 2009 12:16:30 + (GMT) Romont Sylvain psgma...@yahoo.fr escreveu: Hello! I actually live in Japan, I try to make working a tuner card ISDB-T with linux. I searched a lot in internet but I find nothing How can I make it working? My tuner card is a Pixela PIXDT090-PE0 in picture here: http://bbsimg01.kakaku.com/images/bbs/000/208/208340_m.jpg Thank you for your help!!! Unfortunately, only the Earthsoft PC1 board and the boards with dibcom 80xx USB boards are currently supported. In the case of Dibcom, it can support several different devices, but we may need to add the proper USB ID for the board at the driver. I'm in Japan during this week for the Kernel Summit and Japan Linux Symposium. One of objectives I'm expecting from this trip is to get more people involved on creating more drivers for ISDB and other Asian digital video standards. Here we can add that we also have fully working Hybrid/ISDB-T USB fullseg devices for Linux already, just in case someone is interested in it. Feel free to contact me to get some more information about it. The driver works from Linux 2.6.15 on (easy installation everywhere without compiling). Best Regards, Markus -- 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: Re : ISDB-T tuner
On Tue, Oct 20, 2009 at 5:07 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Mon, 19 Oct 2009 23:16:26 + (GMT) Romont Sylvain psgma...@yahoo.fr escreveu: Thank you for your answer! What do you mean by Hybrid? Just drop any answer from markus. He is just sending spam trying to sell his products with closed-source binary drivers. Apparently, his products don't work or don't have any market acceptance. So, he is trying to sell individual pieces by abusing this mailing list. Hybrid means Analog and Digital TV devices. Mauro this shows up a poor image of you as you neither know our situation nor anything else about our product. We have alot customers already. The devices are much easier to install than your kernel drivers you know that and fear to loose the importance of the kernel drivers now. Since you are or were supposed to teach students it will not draw a good light on you to write incorrect things about other companies or persons. Please think twice about what you do. If you would care about your subsystem you would have checked my API bugreports which I sent earlier already. By the way some ISDB-T implementations (Japan as far as I know) are tricky since they require encryption, the current official API model does not cover this either. Best Regards, Markus -- 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: ISDB-T tuner
On Tue, Oct 20, 2009 at 5:49 AM, Akihiro TSUKADA ts...@yahoo.co.jp wrote: My tuner card is a Pixela PIXDT090-PE0 Hi Romont, As you might know, all Japanese DTV programs are scrambled with BCAS. BCAS scrambling algorithm itself is opend in the standard, but in addition to that, PC devices have to encrypt received data locally in order to get authorized for BCAS. So most DTV devices sold in Japan cannot be used in Linux. Some self-started vendors have sold their devices without BCAS authentication (thus without local encryption). They don't/can't include a BCAS PC-card necessary for descrambling, and users must bring it from elsewhere, which is against the EULA with the exclusive and private card issuer organization, or just live with qcif-sized non scrambled 'one seg.' programs in TS. This is why so few ISDB-T/S devices are supported in Linux. And Pixela is one of the major vendors with BCAS authentication. So I'm afraid there is almost no possibility to be supported in Linux. And just for you information, in addition to EarthSoft PT1, there is a driver for 'Friio' ISDB-T USB receiver (which I wrote;) , and it is already included in the main repository. Dibcom is maybe for Brazil and may or may not work in Japan. (Some of the SKnet HDUS series USB receivers are known to be hack-able to avoid local encryption, but of course it's underground.) We are able to handle this legally already. The decryption is directly implemented into our driver. The driver runs entirely in Userspace and does not need any additional kernel modules, our current devices are based on Empia ICs. The installation is exactly the same as for our ATSC/DVB-T/DVB-C/ATV Hybrid devices http://support.sundtek.de/index.php/topic,4.0.html Another topic are Applications which can handle MPEG4/AAC properly, 1Seg also requires a dedicated player since none of the available players can handle it correctly. I'm just adding this so people can get an idea what's currently going on in the Linux area for ISDB-T. Everyone's free to make his own decision about buying devices in the end. Best Regards, Markus Rechberger -- 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: Hauppage WinTV-HVR-900H
On Sat, Oct 10, 2009 at 1:56 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Sat, 10 Oct 2009 00:24:57 +0200 Markus Rechberger mrechber...@gmail.com escreveu: On Fri, Oct 9, 2009 at 11:58 PM, Simon Kenyon si...@koala.ie wrote: Markus Rechberger wrote: Available from 20th Oct on so in 11 days. There are not many competitive devices (none) available for linux which deliver such support. On the other side it's not kernel based either, it's entirely in userspace. It's also entirely supported by all participating companies. this is a mailing list for the open source dvb drivers you are talking about a closed source solution what does your solution have to do with linuxtv.org? I see linux-media, you can find the sources of a patched tvtime version on the website. It shows an alternative way how to integrate usb chipsolutions in linux. Aside of that the official DVB(3/5)/V4L(1/2) API has been reviewed through our work and bugreports have been submitted to various places (linux media, some linux distributions). It integrates flawlessly and helps to improve the overall media support with linux. The posting was pointing out to Ali's email that he was looking for a working analog TV solution for France. He has bought this Pinnacle device 3 years ago, the vendor does not care about support for it. We provide solutions which work within a few seconds, nevermind what distribution. Your business is so bad that you can't even pay to an adds on some magazine, for you to spam the open source mailing lists as a desperate trial to sell a single unit of your product? As an information for you it's going very well. Just because you don't have any influence anymore in blocking our work as you had done in the past it's better for you to remain silent in the background. Best Regards, Markus -- 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: Hauppage WinTV-HVR-900H
On Fri, Oct 9, 2009 at 9:59 AM, Simon Kenyon si...@koala.ie wrote: Markus Rechberger wrote: Aside of that we also fully support Linux http://support.sundtek.de/index.php/topic,4.0.html http://support.sundtek.de/index.php/topic,7.0.html We also use to report bugs to Distributors in order to improve general Multimedia Support. Customers also get dedicated support as far as needed in order to get everything work properly (if needed). Best Regards, Markus binary driver for very expensive and unavailable hardware Available from 20th Oct on so in 11 days. There are not many competitive devices (none) available for linux which deliver such support. On the other side it's not kernel based either, it's entirely in userspace. It's also entirely supported by all participating companies. The driver is using the same components as the Windows driver. There's no way to crash the kernel with that driver, and it works from 2.6.15 kernelseries on without having to fiddle around. In any case it's up to the customer if he wants an easy installation or a complicated one, similar devices for Mac are available at a higher price. Even though when drivers are officially in the kernel still not all distributions are shipping all the kernel drivers especially the firmware isn't shipped with most distributions either. We do have customers who are not comfortable with having to compile kernelmodules and just want to have it work. Another positive side effect every system can use the same driver, updates are easily possible for everyone (unlike kernel drivers for such devices which have to be recompiled for every system). The installation of it usually takes below 10 seconds on any system we tested (Ubuntu, Redhat, Suse, Sidux, Gentoo, Acer One Netbook, Arch Linux) Best Regards, Markus -- 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: Hauppage WinTV-HVR-900H
On Fri, Oct 9, 2009 at 11:58 PM, Simon Kenyon si...@koala.ie wrote: Markus Rechberger wrote: Available from 20th Oct on so in 11 days. There are not many competitive devices (none) available for linux which deliver such support. On the other side it's not kernel based either, it's entirely in userspace. It's also entirely supported by all participating companies. this is a mailing list for the open source dvb drivers you are talking about a closed source solution what does your solution have to do with linuxtv.org? I see linux-media, you can find the sources of a patched tvtime version on the website. It shows an alternative way how to integrate usb chipsolutions in linux. Aside of that the official DVB(3/5)/V4L(1/2) API has been reviewed through our work and bugreports have been submitted to various places (linux media, some linux distributions). It integrates flawlessly and helps to improve the overall media support with linux. The posting was pointing out to Ali's email that he was looking for a working analog TV solution for France. He has bought this Pinnacle device 3 years ago, the vendor does not care about support for it. We provide solutions which work within a few seconds, nevermind what distribution. Although this was my last mail addressing your questions. Best Regards, Markus Rechberger -- 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: Hauppage WinTV-HVR-900H
On Thu, Oct 8, 2009 at 6:28 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Thu, Oct 8, 2009 at 2:20 PM, Ali Abdallah al...@xfce.org wrote: I have the card since alsmost 3 years, it never worked, but now i'm in urgent need of getting an analog usb stick to work with Linux. The PCTV hybrid: Bus 001 Device 004: ID eb1a:2881 eMPIA Technology, Inc. Thanks for you support, but i need an analog usb stick, well hopefully the wintv 900H will get supported soon. Well, I added support for that device last month, so I would suggest you install the latest v4l-dvb code from http://linuxtv.org/hg/v4l-dvb. Directions can be found here: http://linuxtv.org/repo Aside of that we also fully support Linux http://support.sundtek.de/index.php/topic,4.0.html http://support.sundtek.de/index.php/topic,7.0.html We also use to report bugs to Distributors in order to improve general Multimedia Support. Customers also get dedicated support as far as needed in order to get everything work properly (if needed). Best Regards, Markus -- 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: [Bulk] V4L-DVB Summit Day 3
On Fri, Oct 2, 2009 at 7:56 PM, CityK ci...@rogers.com wrote: Hans Verkuil wrote: I made the following list: - We created a new mc mailinglist: linux...@googlegroups.com This is a temporary mailinglist where we can post and review patches during prototyping of the mc API. We don't want to flood the linux-media list with those patches since that is already quite high-volume. The mailinglist should be active, although I couldn't find it yet from www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did something wrong. I'm scratching my head on this one. Seems the last thing that is needed is YET another mailing list. Further, it - fractures the development community. this is what I think too. I'm mainly interested in keeping up compatibility with that framework The traffic on this mailinglist is rather small and it should be ok to mix up developer mails with a few support mails (whereas people usually use to CC anyone who might be involved anyway). - persons unaware of the decision, and whom might be interested, would never find it . i.e. alienation if you try to send an email as adviced to that googlemail mailinglist you'll just get an email back that it doesn't work :-) nothing else to write about it I totally agree. One question I have though, what is the impact to the existing API, will they start to require that MC interface? TI hardware is rather specialized and most other devices will not need any of those changes, I don't see the benefit of bloating up the API for devices which already work fine, for simple devices it should better remain simple. (This question is mainly because we also maintain our own player which supports the v4l2/dvbV(3/5) API, but the driver should still support legacy applications in the future) Best Regards, Markus -- 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: status of google group created for working on Media controller?
Hi, On Thu, Oct 1, 2009 at 6:13 PM, Nagendra, Gururaj gururaj.nagen...@intel.com wrote: Murali, Please send a subscribe request to linux...@googlegroups.com Let's make progress from where we left off at Linux Plumbers Conf using MC mailing list. I would like to join this one too, what is needed for the subscription email? The last one I sent just returned. Best Regards, Markus -- 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: Bug in S2 API...
in dvb-frontend.c: if(cmd == FE_GET_PROPERTY) { tvps = (struct dtv_properties __user *)parg; dprintk(%s() properties.num = %d\n, __func__, tvps-num); dprintk(%s() properties.props = %p\n, __func__, tvps-props); ... if (copy_from_user(tvp, tvps-props, tvps-num * sizeof(struct dtv_property))) OK, thought I'll have never to care for it again. ENUM calls should never be W. Hit me for all I missed. Cheers, Hermann you are not seeing the point of it it seems Documentation/ioctl-number.txt If you are adding new ioctl's to the kernel, you should use the _IO macros defined in linux/ioctl.h: _IOan ioctl with no parameters _IOW an ioctl with write parameters (copy_from_user) _IOR an ioctl with read parameters (copy_to_user) _IOWR an ioctl with both write and read parameters. copy from user is required in order to copy the keys for the requested elements into the kernel. copy to user is finally used to play them back. Markus -- 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: Bug in S2 API...
On Tue, Sep 22, 2009 at 4:00 AM, hermann pitton hermann-pit...@arcor.de wrote: Hi Markus, Am Montag, den 21.09.2009, 12:02 +0200 schrieb Markus Rechberger: in dvb-frontend.c: if(cmd == FE_GET_PROPERTY) { tvps = (struct dtv_properties __user *)parg; dprintk(%s() properties.num = %d\n, __func__, tvps-num); dprintk(%s() properties.props = %p\n, __func__, tvps-props); ... if (copy_from_user(tvp, tvps-props, tvps-num * sizeof(struct dtv_property))) OK, thought I'll have never to care for it again. ENUM calls should never be W. Hit me for all I missed. Cheers, Hermann you are not seeing the point of it it seems you are right, I do not see your point at all, but I was wrong for the get calls. We had such discussions on v4l ioctls previously. The result was to keep them as is and not to change IOR to IOWR to keep compatibility. This is six years back. I think they all have got fixed up for v4l2 back then #ifdef __OLD_VIDIOC_ /* for compatibility, will go away some day */ #define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int) #define VIDIOC_S_PARM_OLD_IOW('V', 22, struct v4l2_streamparm) #define VIDIOC_S_CTRL_OLD_IOW('V', 28, struct v4l2_control) #define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct v4l2_audio) #define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct v4l2_audioout) #define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct v4l2_cropcap) #endif to eg: #define VIDIOC_OVERLAY _IOW('V', 14, int) #define VIDIOC_S_PARM _IOWR('V', 22, struct v4l2_streamparm) #define VIDIOC_S_CTRL _IOWR('V', 28, struct v4l2_control) #define VIDIOC_G_AUDIO _IOR('V', 33, struct v4l2_audio) #define VIDIOC_G_AUDOUT _IOR('V', 49, struct v4l2_audioout) #define VIDIOC_CROPCAP _IOWR('V', 58, struct v4l2_cropcap) so only the DVB-API remains bugged now. Markus -- 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: Bug in S2 API...
On Tue, Sep 22, 2009 at 7:08 AM, hermann pitton hermann-pit...@arcor.de wrote: All fine. But you do cut off parts of my messages. I would like to ask you to exercise a breakage, not only for stuff six years back, but on recent S2 API. at this time there are definitely no DVB applications available which check the flags of the encoded IOCTL values for the S2-API definitions, there are just very few applications available which use this API at all. if (IOCTL_WRITE(cmd)) copy data into buffer for ioctl -- from the driver side -- if (IOCTL_WRITE(cmd)) copy data from the other side process_ioctl() At least the API specification should be valid however the rest is implemented is another story. It works as it is but it's still wrong. Since the S2-API is rather new it might be better to fix it up. It would be a little bit weird too that coding style has a higher priority in Linux than correct code. it breaks the macros in asm-generic/ioctl.h #define IOC_INOUT ((_IOC_WRITE|_IOC_READ) _IOC_DIRSHIFT) #define IOC_IN (_IOC_WRITE _IOC_DIRSHIFT) #define IOC_OUT (_IOC_READ _IOC_DIRSHIFT) #define _IOC_DIR(nr)(((nr) _IOC_DIRSHIFT) _IOC_DIRMASK) Basically I don't mind too much since we already maintain our own version which also supports other unix systems and is not limited to linux only... Markus -- 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
Bug in S2 API...
while porting the S2api to userspace I came accross the S2-API definition itself #define FE_SET_PROPERTY_IOW('o', 82, struct dtv_properties) #define FE_GET_PROPERTY_IOR('o', 83, struct dtv_properties) while looking at this, FE_GET_PROPERTY should very likely be _IOWR in dvb-frontend.c: if(cmd == FE_GET_PROPERTY) { tvps = (struct dtv_properties __user *)parg; dprintk(%s() properties.num = %d\n, __func__, tvps-num); dprintk(%s() properties.props = %p\n, __func__, tvps-props); ... if (copy_from_user(tvp, tvps-props, tvps-num * sizeof(struct dtv_property))) Regards, Markus -- 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: Bug in S2 API...
On Mon, Sep 21, 2009 at 5:46 AM, hermann pitton hermann-pit...@arcor.de wrote: Am Montag, den 21.09.2009, 05:40 +0200 schrieb Markus Rechberger: while porting the S2api to userspace I came accross the S2-API definition itself #define FE_SET_PROPERTY _IOW('o', 82, struct dtv_properties) #define FE_GET_PROPERTY _IOR('o', 83, struct dtv_properties) while looking at this, FE_GET_PROPERTY should very likely be _IOWR in dvb-frontend.c: if(cmd == FE_GET_PROPERTY) { tvps = (struct dtv_properties __user *)parg; dprintk(%s() properties.num = %d\n, __func__, tvps-num); dprintk(%s() properties.props = %p\n, __func__, tvps-props); ... if (copy_from_user(tvp, tvps-props, tvps-num * sizeof(struct dtv_property))) Regards, Markus Seems to be a big issue. Why you ever want to write to a get property? to read out the API version for example. tvps-num is also used in order to check the boundaries of the property array. Markus -- 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: Bug in S2 API...
On Mon, Sep 21, 2009 at 6:10 AM, hermann pitton hermann-pit...@arcor.de wrote: Am Montag, den 21.09.2009, 06:09 +0200 schrieb Markus Rechberger: On Mon, Sep 21, 2009 at 5:46 AM, hermann pitton hermann-pit...@arcor.de wrote: Am Montag, den 21.09.2009, 05:40 +0200 schrieb Markus Rechberger: while porting the S2api to userspace I came accross the S2-API definition itself #define FE_SET_PROPERTY _IOW('o', 82, struct dtv_properties) #define FE_GET_PROPERTY _IOR('o', 83, struct dtv_properties) while looking at this, FE_GET_PROPERTY should very likely be _IOWR in dvb-frontend.c: if(cmd == FE_GET_PROPERTY) { tvps = (struct dtv_properties __user *)parg; dprintk(%s() properties.num = %d\n, __func__, tvps-num); dprintk(%s() properties.props = %p\n, __func__, tvps-props); ... if (copy_from_user(tvp, tvps-props, tvps-num * sizeof(struct dtv_property))) Regards, Markus Seems to be a big issue. Why you ever want to write to a get property? to read out the API version for example. tvps-num is also used in order to check the boundaries of the property array. Markus Their are no writes allowed to manipulate get properties. the writes are needed in order to submit tvps-num, although _IOR will work _IOWR is the correct one in that case, aside of that you can just compare it with other calls (eg. v4l2), the ENUM calls are all _IOWR. They submit the index and retrieve the rest. Markus -- 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: Initial media controller implementation
Hi, On Sat, Sep 12, 2009 at 12:57 PM, Hans Verkuil hverk...@xs4all.nl wrote: Rather than writing long mails on what a media controller is and what it can do, I thought that I could just as well implement it. So in 4 hours I implemented pretty much all of the media controller functionality. The main missing features are the ability to register non-v4l device nodes so that they can be enumerated and setting controls private to a sub-device. For that I should first finish the control handling framework. The datastructures and naming conventions needs to be cleaned up, and it needs some tweaking, but I'd say this is pretty much the way I want it. The code is available here: http://linuxtv.org/hg/~hverkuil/v4l-dvb-mc/ It includes a v4l2-mc utility in v4l2-apps/util that has the --show-topology option that enumerates all nodes and subdev. Currently any registered subdevs and v4l device nodes are already automatically added. Obviously, there are no links setup between them, that would require work in the drivers. Total diffstat: b/linux/include/media/v4l2-mc.h | 54 + b/v4l2-apps/util/v4l2-mc.cpp | 325 linux/drivers/media/video/v4l2-dev.c | 15 + linux/drivers/media/video/v4l2-device.c | 265 +- linux/include/linux/videodev2.h | 74 +++ linux/include/media/v4l2-dev.h | 6 linux/include/media/v4l2-device.h | 23 +- linux/include/media/v4l2-subdev.h | 11 - v4l2-apps/util/Makefile | 2 9 files changed, 762 insertions(+), 13 deletions(-) Ignoring the new utility that's just 435 lines of core code. Now try this with sysfs. Brrr. please even more important when doing this push out a proper documentation for it, The s2api is a mess seen from the documentation people need to hack existing code in order to figure out how to use it it seems. v4l2/(incomplete)linuxdvb v3 API are still the best references to start with right now. Markus -- 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: Invalid module format
On Wed, Sep 9, 2009 at 6:19 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Wed, Sep 9, 2009 at 12:14 PM, Edouard Marquezanimatri...@gmail.com wrote: Hello, I am using Gentoo with tuxonice-sources-2.6.3.0-r5 that is to say 2.6.30.5. The compilation of v4l-dvb works well (the kernel which is chosen is the right), but when I try to modprobe em28xx, I get this : WARNING: Error inserting videobuf_core (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videobuf-core.ko): Invalid module format WARNING: Error inserting videobuf_vmalloc (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videobuf-vmalloc.ko): Invalid module format WARNING: Error inserting v4l2_compat_ioctl32 (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/v4l2-compat-ioctl32.ko): Invalid module format WARNING: Error inserting v4l1_compat (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format WARNING: Error inserting videodev (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videodev.ko): Invalid module format WARNING: Error inserting v4l2_common (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/v4l2-common.ko): Invalid module format WARNING: Error inserting ir_common (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/common/ir-common.ko): Invalid module format FATAL: Error inserting em28xx (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/em28xx/em28xx.ko): Invalid module format I have this error in my dmesg : [ 3903.465920] tveeprom: disagrees about version of symbol module_layout I join my .config file. What do I need to do ? Thanks! Usually this occurs when people are using the mrechberger version of the em28xx driver, and the symbols are in conflict with the rest of the v4l-dvb tree. this is not true my old driver which is not available anymore did not ship any other modules aside the em28xx driver itself. This is a video4linux issue and has nothing to do with it. Best Regards, Markus -- 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: Invalid module format
On Wed, Sep 9, 2009 at 9:09 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Wed, Sep 9, 2009 at 3:02 PM, Markus Rechbergermrechber...@gmail.com wrote: this is not true my old driver which is not available anymore did not ship any other modules aside the em28xx driver itself. This is a video4linux issue and has nothing to do with it. Best Regards, Markus Hello Marks, While it is true that your driver did not include anything other than em28xx, I assume it is compiled against a certain set of v4l2 headers, and if those headers change (such as changes to data structures), then the em28xx modules you distributed would not work with that version of the v4l2 modules. I stopped the work at around Oct last year, 2.6.27 is the latest kernel which is supposed to be supported with it. Although since there are some bad bugs in it which I've been told by the manufacturer afterwards I do not recommend to use it either it shortens the lifetime of most devices... Best is to stick with windows unless the manufacturer and chipdesigners support a driver. WARNING: Error inserting videobuf_core (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videobuf-core.ko): Invalid module format this is something that cannot be caused by the em28xx work, it's any other messy issue with the v4l2 kernel API. Markus If he wants to use your driver, I would assume he would need to reinstall the stock kernel (overwriting whatever locally built version of v4l-dvb he previously installed). Cheers, 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] Anysee E30 C Plus + MPEG-4?
2009/8/18 Pásztor Szilárd d...@tricon.hu: Thanks for the comprehensive answer. Mr. Thommeret's hint about the missing video PID pushed me into the right direction so I'm a step further now. With scan -vv I could find the video PIDs for the HD channels and indeed they were missing in my channels.conf (values were 0) as scan detected them as OTHER, but with a type 0x1b addition with which I don't know what to do for the time being... After adding the correct PID values, mplayer still can't demux the incoming stream but the video is there, and with -dumpvideo a h264 elementary stream gets produced in the file that can be played back if I specify -demuxer h264es on the command line. What are beyond me now are: 1) how can mplayer not demux the stream if it can dump the video out (shouldn't a video dump involve a demux operation before all?) 2) is it a missing feature of mplayer that no metastream is processed that would carry the necessary information about the muxed streams? It would be adequate for me if I could specify a demuxer to use but it seems impossible in just one step - which I currently don't understand because an elementary stream is dumped as video. You might try: dvbstream -o 8192 | mplayer -cache 10240 - this forwards the entire stream to mplayer, you can switch the channels with [tab] Regards, Markus -- 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: USB devices supporting raw or sliced VBI for closed captioning?
On Sun, Aug 2, 2009 at 2:49 AM, hermann pittonhermann-pit...@arcor.de wrote: Am Samstag, den 01.08.2009, 03:45 +0200 schrieb Markus Rechberger: Hi, On Sat, Aug 1, 2009 at 1:20 AM, Steve Castellottis...@eyemagnet.com wrote: I was wondering if anyone could please point me at a list or similar resource for USB capture devices which support raw (or sliced) VBI access for producing a closed caption transcript through software such as zbvi-ntsc-cc or ccextractor? Specifically I'm wanting a device capable of S-Video, Composite, or even Component input, not just ATSC, as most USB devices seem focused around these days. I've managed to get this working with various ivtv and saa713x based PCI devices, but aren't aware of any USB implementations of chipsets which use those drivers. Searching online, I found this archived message: http://lists.zerezo.com/video4linux/msg16402.html which states: some em2840 and newer devices are able to capture raw vbi in linux (sliced vbi isn't possible yet) em2820, em2800, em2750 do not support vbi at all. Checking the em28xx driver homepage for recent models, I found this entry: http://mcentral.de/wiki/index.php5/Em2880 officially the em2880 is em2840 + DVB_T which implies that not only is the em2880 series a newer device, but it should in fact already contain the em2840 chip specifically mentioned. Later on that same page, in the list of devices: ATI/AMD TV Wonder 600 and on the manufacturer's page: http://ati.amd.com/products/tvwonder600/usb/index.html Under the list of Input Connectors: S-video input with adapter Picking up one of these devices, I attempted to tune into the S-Video feed and check the /dev/vbi0 device, but received the same error message as I do with all other em28xx devices encountered thus far: Cannot capture vbi data with v4l interface: /dev/vbi0 (AMD ATI TV Wonder HD 600) is not a raw vbi device. Can anyone please point me in the right direction? I would much prefer to be certain the next purchase is supported. Thanks! we do support Raw VBI for our devices, Sundtek MediaTV Pro for closed captioning. Alternatively we also have full support for ATSC-analogTV USB devices for the US market ([em288x]-[AVFB4910]-[Trident drx-J]-[tda18271]) the european product which we are selling is also capable of decoding NTSC closed caption. http://sundtek.de/shop/Digital-TV-Sticks-oxid/Sundtek-MediaTV-Pro.html (this is just the information about the European/DVB-T/DVB-C/analogTV(raw VBI) device, we do not have the US/ATSC/analogTV(rawVBI) product listed there, although we do offer it to business customers) We support it from Linux 2.6.15 on. Best Regards, Markus Rechberger Hi, anything new about how to deal with commercial advertising on lists, depending totally on our source? Please have a look. The question was about a device, and I doubt that you can get a device for free anywhere. If so there shouldn't be any other company names in drivers, or named on the mailinglist (to be fair) which do not support Linux. Best Regards, Markus -- 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: Cinergy T2 stopped working with kernel 2.6.30
On Fri, Jul 31, 2009 at 9:47 PM, emag...@magic.ms wrote: Apparently, usb_bulk_msg() cannot be used with data on the stack: http://www.linuxtv.org/pipermail/linux-dvb/2008-August/028150.html http://www.mail-archive.com/linux-usb-de...@lists.sourceforge.net/msg19158.html -- As far as I recall this has been documented for ages already... Although many people stumble over it... last but not least there's no reason to have USB drivers in the kernel anyway.. Markus -- 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: USB devices supporting raw or sliced VBI for closed captioning?
Hi, On Sat, Aug 1, 2009 at 1:20 AM, Steve Castellottis...@eyemagnet.com wrote: I was wondering if anyone could please point me at a list or similar resource for USB capture devices which support raw (or sliced) VBI access for producing a closed caption transcript through software such as zbvi-ntsc-cc or ccextractor? Specifically I'm wanting a device capable of S-Video, Composite, or even Component input, not just ATSC, as most USB devices seem focused around these days. I've managed to get this working with various ivtv and saa713x based PCI devices, but aren't aware of any USB implementations of chipsets which use those drivers. Searching online, I found this archived message: http://lists.zerezo.com/video4linux/msg16402.html which states: some em2840 and newer devices are able to capture raw vbi in linux (sliced vbi isn't possible yet) em2820, em2800, em2750 do not support vbi at all. Checking the em28xx driver homepage for recent models, I found this entry: http://mcentral.de/wiki/index.php5/Em2880 officially the em2880 is em2840 + DVB_T which implies that not only is the em2880 series a newer device, but it should in fact already contain the em2840 chip specifically mentioned. Later on that same page, in the list of devices: ATI/AMD TV Wonder 600 and on the manufacturer's page: http://ati.amd.com/products/tvwonder600/usb/index.html Under the list of Input Connectors: S-video input with adapter Picking up one of these devices, I attempted to tune into the S-Video feed and check the /dev/vbi0 device, but received the same error message as I do with all other em28xx devices encountered thus far: Cannot capture vbi data with v4l interface: /dev/vbi0 (AMD ATI TV Wonder HD 600) is not a raw vbi device. Can anyone please point me in the right direction? I would much prefer to be certain the next purchase is supported. Thanks! we do support Raw VBI for our devices, Sundtek MediaTV Pro for closed captioning. Alternatively we also have full support for ATSC-analogTV USB devices for the US market ([em288x]-[AVFB4910]-[Trident drx-J]-[tda18271]) the european product which we are selling is also capable of decoding NTSC closed caption. http://sundtek.de/shop/Digital-TV-Sticks-oxid/Sundtek-MediaTV-Pro.html (this is just the information about the European/DVB-T/DVB-C/analogTV(raw VBI) device, we do not have the US/ATSC/analogTV(rawVBI) product listed there, although we do offer it to business customers) We support it from Linux 2.6.15 on. Best Regards, Markus Rechberger -- 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: em28xx driver crashes device
On Thu, Jul 23, 2009 at 8:59 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Thu, 23 Jul 2009 16:29:02 +0200 Markus Rechberger mrechber...@gmail.com escreveu: On Thu, Jul 23, 2009 at 4:05 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechbergermrechber...@gmail.com wrote: There's a pretty good disclosed detection from Empia available, the linux kernel driver just doesn't support it and very likely will never support it. Instead of doing it the wrong way it's better to turn it off or explicitly ask the user if he wants to do something undefined with his device. The nvidia setup tools also provide an option to force it instead of letting the software just do whatever some developers don't know what it will cause... You don't know what will happen to the device when doing that detection. The initial device in question had to be replugged after we removed the driver from the system. You shouldn't invite people to do undefined things with their hardware so they might break them I think I will submit a few photos what physically can happen to the device with wrong settings. Well, if there is a known heuristic, I would be very happy to get rid of the autodetection logic. I haven't looked at the Empia code in months so I should probably do that. Since I used to design hardware for a living, I am quite familiar with what can happen with incorrect GPIOs so I do not believe you need to attempt to convince me with photos, which is why I am in favor of removing the logic in question. We just need to figure out how to do it without causing a regression in current device support. Interesting... I took a quick look at the code, and it seems like the USB errors occur before we change any GPIOs, and more interesting it appears that the em2861 itself is wedged (which I believe is the first time I've seen that). The code in the log above suggests that the autodetection concluded that the profile was not known, so it did not arbitrarily pick some incorrect device. I am a bit surprised that just reading the eeprom once and doing a scan of the i2c bus would wedge the chip. Is there any information you can give about the board in question in terms of what product it is or what components it contains? it was a simple TVP5150 based device... I do not mean my old code either it's also a failure as I got more information for the new driver after we dropped the old project. As you know the new driver is entirely in Userpace and supported by all involved chipcompanies, it comes with its own LinuxDVB and video4linux2 Stack. Also vendors have a very low interest in supporting those devices in Kernelspace as installing devices which should be sold now are not supported by any distributions. Devices which have been sold one year ago have a very low till no motivation anymore. Most people are simply not able to compile the drivers and/or prepare the kernel development environment just for installing and using a TV Card. PLEASE STOP WITH FUD. THIS FORUM IS FOR OPEN SOURCE DRIVER DISCUSSION. AS YOU DECIDED TO GO TO THE DARK SIDE, PLEASE STOP POSTING HERE OR AT THE OPEN SOURCE #IRC CHANNEL. someone has problems here? We also support available opensource players and will contribute some patches which can be used by all devices. Markus -- 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: em28xx driver crashes device
On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 24 Jul 2009 12:54:27 +0200 Markus Rechberger mrechber...@gmail.com escreveu: someone has problems here? We also support available opensource players and will contribute some patches which can be used by all devices. Ah well Mauro, This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the LinuxTV mailing lists were created for discussing open source development related to the kernel linux media drivers, the usability of those drivers and related open source themes. Anything related to binary only userspace stuff is completely out of topic and shouldn't be posted on the above places. Despiste what you're saying, your intention to drop support to open source is clear: you are playing against open source since 2007, when you firstly proposed a frontend hook at the kernel driver for userspace. This year, you dropped all open source trees you used to have. So, it is clear that you're out of open source business, and you won't be giving any open source support. So, please stop posting at the open source forums there's no reason to argue with you since you have your own ideas. We do give opensource support as well. So please find another target to struggle around with. Let's see who's able to deliver the better solution for endusers. Thanks, Markus -- 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: em28xx driver crashes device
On Fri, Jul 24, 2009 at 3:06 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 24 Jul 2009 14:15:16 +0200 Markus Rechberger mrechber...@gmail.com escreveu: On Fri, Jul 24, 2009 at 2:06 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 24 Jul 2009 12:54:27 +0200 Markus Rechberger mrechber...@gmail.com escreveu: someone has problems here? We also support available opensource players and will contribute some patches which can be used by all devices. Ah well Mauro, This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the LinuxTV mailing lists were created for discussing open source development related to the kernel linux media drivers, the usability of those drivers and related open source themes. Anything related to binary only userspace stuff is completely out of topic and shouldn't be posted on the above places. Despiste what you're saying, your intention to drop support to open source is clear: you are playing against open source since 2007, when you firstly proposed a frontend hook at the kernel driver for userspace. This year, you dropped all open source trees you used to have. So, it is clear that you're out of open source business, and you won't be giving any open source support. So, please stop posting at the open source forums there's no reason to argue with you since you have your own ideas. We do give opensource support as well. So please find another target to struggle around with. Let's see who's able to deliver the better solution for endusers. This is not a sort of game to see who has a better solution for end users. A company that has a serious commit to open source opens their datasheets to allow public development and contributions and submit patches regularly upstream, without any userspace hooks. If a kerneldriver would be required for our devices we now would definitely submit further patches to the kernel, but for USB drivers it is just not necessary at all since the entire driver can work without any complex dependencies in Userspace. Basically the historically grown v4l-dvb kernelapi is just not needed and just limits the customer base as initially pointed out that not everyone is able to compile those drivers. It is still valid for PCI devices probably until IOMMU is available. This has absolutely nothing to do with what you wrote, rather than the em28xx kerneldriver is basically not needed. If you want datasheets of various companies apply there and work for them, everyone's free to do so. regards, Markus -- 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] Terratec Cinergy HTC USB XS HD
On Thu, Jul 23, 2009 at 1:10 PM, ande...@gmx.de wrote: On Sat, Jul 18, 2009 at 12:46 PM, Mario Fetkamario.fe...@gmail.com wrote: On Saturday, 18. July 2009 04:06:13 Alain Kalker wrote: Op maandag 15-06-2009 om 22:36 uur [tijdzone +0200], schreef sacha: Hello Does anybody know if this devise will ever work with Linux? It was promised by one person last year the support will be available within months. One year has gone, nothing happens. Is there any alternatives to develop a driver for this devise aside from this person? Since there has been no answer to your question for some time, I think I will step in. From http://mcentral.de/wiki/index.php5/Terratec_HTC_XS , the future for a driver from Markus for this device does seem to look quite bleak. However, from looking in the mailinglist archive I gather that Steven Toth has offered to try getting it to work if someone is willing to provide him with a device. Maybe you two could get in contact. I myself am also interested in a driver for this device but I haven't got one yet. Kind regards, Alain as far as i know there already exists a driver but it could not be published as it is based on the micronas refernce driver i think the problem is related to http://www.linuxtv.org/pipermail/linux-dvb/2008-December/030738.html but this new situation with http://www.tridentmicro.com/Product_drx_39xyK.asp can maby change something about this chip and it would be possible to get the rights to publish the driver under gpl-2 This won't solve the issue that the AVFB4910 has been discontinued. This affects FM Radio, Analogue TV, Composite and S-Video, that IC didn't get bought by Trident. regards, Markus Did Devin Heitmueller comment on that? AFAIK he already finished a driver for the DRX-3933J and I would think he might have interest to get in contact with trident in order of being allowed to publish his work. Should be a rather small step compared to the work he has done so far. And Trident has some history in cooperating together with XFree developers, letting them develop graphics card drivers. What about this AVFB4910? Is it possible to get a working DVB-C/DVB-T solution without getting in contact with this chip? And once this would be done, there should still be the option of reverse engineering the protocol of that one. For those who are interested in such a solution: http://support.sundtek.de/index.php/topic,2.0.html http://sundtek.de/shop/Digital-TV-Sticks/Sundtek-MediaTV-Pro.html There's a fully supported solution available for Linux already, it also includes online Linux support. The installation of the drivers can't be easier. Best Regards, Markus Meanwhile, Terratec has dicontinued the Cinergy HTC USB XS HD, but what about the H5? Does anyone know about its internals already? AFAIK, these are still the only non-PCI DVB-C solutions on the market. Hmm, did micronas give up this full range of products? Sold the 'interesting' part to trident and ceased production of everything else? Maybe half a year ago, they didn't want to disturb ongoing selling negotiations by giving away their intellectual property for free in parallel, and now, after all is settled, maybe they don't mind anymore. So contacting those people again could be worth it, too. best regards, Raimund -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 -- 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: em28xx driver crashes device
On Thu, Jul 23, 2009 at 1:41 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Thu, Jul 23, 2009 at 5:40 AM, Markus Rechbergermrechber...@gmail.com wrote: Hey, [24004.018614] EEPROM ID= 0x9567eb1a, hash = 0x1067368a [24004.018618] Vendor/Product ID= eb1a:2861 [24004.018622] AC97 audio (5 sample rates) [24004.018626] 500mA max power [24004.018629] Table at 0x04, strings=0x206a, 0x, 0x [24004.049201] failed! [24004.049210] em28xx #0: reading from i2c device failed (error=-71) [24004.049444] failed! [24004.049451] em28xx #0: reading from i2c device failed (error=-71) [24004.049655] failed! [24004.049659] em28xx #0: reading from i2c device failed (error=-71) [24004.049891] failed! [24004.049895] em28xx #0: reading from i2c device failed (error=-71) [24004.050141] failed! [24004.050145] em28xx #0: reading from i2c device failed (error=-71) [24004.050393] failed! [24004.050396] em28xx #0: reading from i2c device failed (error=-71) [24004.050641] failed! [24004.050644] em28xx #0: reading from i2c device failed (error=-71) [24004.050890] failed! [24004.050894] em28xx #0: reading from i2c device failed (error=-71) [24004.051141] failed! [24004.051145] em28xx #0: reading from i2c device failed (error=-71) [24004.051392] failed! [24004.051395] em28xx #0: reading from i2c device failed (error=-71) [24004.051641] failed! [24004.051645] em28xx #0: reading from i2c device failed (error=-71) [24004.051892] failed! [24004.051895] em28xx #0: reading from i2c device failed (error=-71) [24004.052140] failed! [24004.052143] em28xx #0: reading from i2c device failed (error=-71) [24004.052393] failed! [24004.052396] em28xx #0: reading from i2c device failed (error=-71) [24004.052642] failed! [24004.052645] em28xx #0: reading from i2c device failed (error=-71) [24004.052892] failed! [24004.052895] em28xx #0: reading from i2c device failed (error=-71) [24004.057741] failed! [24004.057746] em28xx #0: reading from i2c device failed (error=-71) [24004.057880] failed! [24004.057884] em28xx #0: reading from i2c device failed (error=-71) [24004.058125] failed! [24004.058129] em28xx #0: reading from i2c device failed (error=-71) [24004.058379] failed! [24004.058383] em28xx #0: reading from i2c device failed (error=-71) [24004.058628] failed! [24004.058633] em28xx #0: reading from i2c device failed (error=-71) [24004.058880] failed! [24004.058883] em28xx #0: reading from i2c device failed (error=-71) [24004.059128] failed! [24004.059131] em28xx #0: reading from i2c device failed (error=-71) [24004.059380] failed! [24004.059383] em28xx #0: reading from i2c device failed (error=-71) [24004.059636] failed! [24004.059640] em28xx #0: reading from i2c device failed (error=-71) [24004.059914] failed! [24004.059917] em28xx #0: reading from i2c device failed (error=-71) [24004.060140] failed! [24004.060145] em28xx #0: reading from i2c device failed (error=-71) [24004.060388] failed! [24004.060392] em28xx #0: reading from i2c device failed (error=-71) [24004.060636] failed! [24004.060640] em28xx #0: reading from i2c device failed (error=-71) [24004.060884] failed! [24004.060887] em28xx #0: reading from i2c device failed (error=-71) [24004.061126] failed! [24004.061132] em28xx #0: reading from i2c device failed (error=-71) [24004.062214] failed! [24004.062219] em28xx #0: reading from i2c device failed (error=-71) [24004.062378] failed! [24004.062383] em28xx #0: reading from i2c device failed (error=-71) [24004.062632] failed! [24004.062636] em28xx #0: reading from i2c device failed (error=-71) [24004.062884] failed! [24004.062889] em28xx #0: reading from i2c device failed (error=-71) [24004.063126] failed! [24004.063131] em28xx #0: reading from i2c device failed (error=-71) [24004.063375] failed! [24004.063380] em28xx #0: reading from i2c device failed (error=-71) [24004.063626] failed! [24004.063631] em28xx #0: reading from i2c device failed (error=-71) [24004.063875] failed! [24004.063880] em28xx #0: reading from i2c device failed (error=-71) [24004.064127] failed! [24004.064132] em28xx #0: reading from i2c device failed (error=-71) [24004.064376] failed! [24004.064380] em28xx #0: reading from i2c device failed (error=-71) [24004.064625] failed! [24004.064630] em28xx #0: reading from i2c device failed (error=-71) [24004.064876] failed! [24004.064881] em28xx #0: reading from i2c device failed (error=-71) [24004.065126] failed! [24004.065130] em28xx #0: reading from i2c device failed (error=-71) [24004.065376] failed! [24004.065381] em28xx #0: reading from i2c device failed (error=-71) [24004.065626] failed! [24004.065632] em28xx #0: reading from i2c device failed (error=-71) [24004.065875] failed! [24004.065880] em28xx #0: reading from i2c device failed (error=-71) [24004.066126] failed! [24004.066131] em28xx #0: reading from i2c device failed (error=-71) [24004.066376] failed!
Re: [linux-dvb] Terratec Cinergy HTC USB XS HD
On Thu, Jul 23, 2009 at 1:51 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Thu, Jul 23, 2009 at 7:10 AM, ande...@gmx.de wrote: Did Devin Heitmueller comment on that? AFAIK he already finished a driver for the DRX-3933J and I would think he might have interest to get in contact with trident in order of being allowed to publish his work. I was aware of the Micronas sale. At this point I would continue to encourage users interested in Linux support for tuners to stay away from the products that include the drx-k or drx-j. we now do offer professional Linux support for DRX-K and DRX-J devices for customers. Best Regards, Markus -- 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: em28xx driver crashes device
On Thu, Jul 23, 2009 at 2:03 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Thu, Jul 23, 2009 at 7:46 AM, Markus Rechbergermrechber...@gmail.com wrote: one thing, you might remove that autodetecting part and taking a footprint of unknown devices this causes more problems than everything else with those devices. Maybe make this optional if someone wants to force autodetection over it it might be acceptable but doing that by default can also heat up devices. Also if it thinks it has detected something, after toggling some gpios the footprint might look different again after reloading it.. it's just a failed technique doing it that way... I agree that I'm not particularly happy with how the autodetection logic works today. The current logic though is based on the power-on-reset states of the GPIOs and GPOs though, so we are only changing the GPIOs if the board matches a known profile. That said, unless the hardware design was laid out such that the device would burn out if no driver were loaded at all, I think the risk is pretty minimal for a device that does not match a known profile. If Empia wants to describe a better heuristic for identifying their various hardware designs with the same USB ID but different board layouts and GPIO configs, that would be useful information and eliminate the need for autodetection code. Anyway, I'll take a look at the code and see if I can determine specifically where the errors are occurring in your case. The fun of dealing with hardware vendors that let their customers use default USB IDs for different hardware designs :-) There's a pretty good disclosed detection from Empia available, the linux kernel driver just doesn't support it and very likely will never support it. Instead of doing it the wrong way it's better to turn it off or explicitly ask the user if he wants to do something undefined with his device. The nvidia setup tools also provide an option to force it instead of letting the software just do whatever some developers don't know what it will cause... You don't know what will happen to the device when doing that detection. The initial device in question had to be replugged after we removed the driver from the system. You shouldn't invite people to do undefined things with their hardware so they might break them I think I will submit a few photos what physically can happen to the device with wrong settings. Markus -- 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: em28xx driver crashes device
On Thu, Jul 23, 2009 at 4:05 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechbergermrechber...@gmail.com wrote: There's a pretty good disclosed detection from Empia available, the linux kernel driver just doesn't support it and very likely will never support it. Instead of doing it the wrong way it's better to turn it off or explicitly ask the user if he wants to do something undefined with his device. The nvidia setup tools also provide an option to force it instead of letting the software just do whatever some developers don't know what it will cause... You don't know what will happen to the device when doing that detection. The initial device in question had to be replugged after we removed the driver from the system. You shouldn't invite people to do undefined things with their hardware so they might break them I think I will submit a few photos what physically can happen to the device with wrong settings. Well, if there is a known heuristic, I would be very happy to get rid of the autodetection logic. I haven't looked at the Empia code in months so I should probably do that. Since I used to design hardware for a living, I am quite familiar with what can happen with incorrect GPIOs so I do not believe you need to attempt to convince me with photos, which is why I am in favor of removing the logic in question. We just need to figure out how to do it without causing a regression in current device support. Interesting... I took a quick look at the code, and it seems like the USB errors occur before we change any GPIOs, and more interesting it appears that the em2861 itself is wedged (which I believe is the first time I've seen that). The code in the log above suggests that the autodetection concluded that the profile was not known, so it did not arbitrarily pick some incorrect device. I am a bit surprised that just reading the eeprom once and doing a scan of the i2c bus would wedge the chip. Is there any information you can give about the board in question in terms of what product it is or what components it contains? it was a simple TVP5150 based device... I do not mean my old code either it's also a failure as I got more information for the new driver after we dropped the old project. As you know the new driver is entirely in Userpace and supported by all involved chipcompanies, it comes with its own LinuxDVB and video4linux2 Stack. Also vendors have a very low interest in supporting those devices in Kernelspace as installing devices which should be sold now are not supported by any distributions. Devices which have been sold one year ago have a very low till no motivation anymore. Most people are simply not able to compile the drivers and/or prepare the kernel development environment just for installing and using a TV Card. Regards, Markus -- 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] Terratec Cinergy HTC USB XS HD
On Thu, Jul 23, 2009 at 4:39 PM, Benny Amorsenbenny+use...@amorsen.dk wrote: Markus Rechberger mrechber...@gmail.com writes: For those who are interested in such a solution: http://support.sundtek.de/index.php/topic,2.0.html http://sundtek.de/shop/Digital-TV-Sticks/Sundtek-MediaTV-Pro.html This doesn't appear to have any support for CA modules? DVB-C is not very useful around here without a CAM... We are currently discussing this with one of our partners as the situation changed with having everything in userspace the devices will usually have manufacturer support. There's a fully supported solution available for Linux already, it also includes online Linux support. The installation of the drivers can't be easier. I have to admit that it is cool that the driver is in user space. How about getting it included in the various Linux distributions? We do not aim to include the drivers in any distribution as we can keep control on driver updates any time. The driver can be downloaded on our site. It is tested with various Linuxversions between 2.6.15 and 2.6.30 (32 and 64bit). The entire system can coexist with already available Kerneldrivers (eg. linuxuvc driver), but it does not need any video4linux or dvb support in the kernel to be supported. It makes installing videodrivers a totally new experience, doable within a few seconds on most systems. Best Regards, Markus -- 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: offering bounty for GPL'd dual em28xx support
On Wed, Jul 22, 2009 at 4:48 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Wed, 22 Jul 2009 12:10:38 +0200 Jelle de Jong jelledej...@powercraft.nl escreveu: Devin Heitmueller wrote: snip The issue occurs with various different drivers. Basically the issue is the device attempts to reserve a certain amount of bandwidth on the USB bus for the isoc stream, and in the case of analog video at 640x480 this adds up to about 200Mbps. As a result, connecting multiple devices can result in exceeding the available bandwidth on the USB bus. Depending on your how many devices you are trying to connect, what your target capture resolution is, and whether you can put each device on its own USB bus will dictate what solution you can go with. Hi all, So I felt like doing a field test, with my dvb-t test system. Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900 Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc. Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex] Bus 001 Device 002: ID 15a4:9016 I have now three devices with dvb-t channels running with different channels and audio on an atom based cpu without problems. two: dvb-usb-dib0700 and one: dvb-usb-af9015 the dvb-usb-af9015 takes way more cpu interrupts because of the usb block size. prove: http://imagebin.ca/img/xM9Q7_A.jpg I will be demonstrating this at har2009 (see demonstration village) Devin could you login onto the dvb-t test system and see if you can get those em28xx device running with your new code? I will probably make an other test system with some more cpu power to see if even more usb devices are possible, or I may use my nice powerful multiseat quad core system for it. Best regards, Jelle de Jong Jelle, DVB-T is less consuming than analog, since the streams are mpeg compressed. The issue with em28xx is that, on analog mode, all data come uncompressed. So, the worse case is a NTSC stream with 16 bit YUY2 frame with using 720x480x30x2 Mbps (e. g. 207 Mbps) for the payload, plus some additional bandwidth for the transport headers. On HD, mpeg stream are up to 23 Mbps on DTV systems (ISDB full-seg is the worse case on DTV). 207Mbps?? 720*480*30 = 20736000 bytes == 19.78 Mbyte == 158.20 Mbit sure there's some overhead but your calculation is wrong. Markus -- 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
DMX_SET_FILTER
Hi, I recently went through the DVB API and found following structures for DMX_SET_FILTER typedef struct dmx_filter { uint8_t filter[DMX_FILTER_SIZE]; uint8_t mask[DMX_FILTER_SIZE]; uint8_t mode[DMX_FILTER_SIZE]; } dmx_filter_t; struct dmx_sct_filter_params { uint16_t pid; dmx_filter_t filter; uint32_t timeout; uint32_t flags; #define DMX_CHECK_CRC 1 #define DMX_ONESHOT 2 #define DMX_IMMEDIATE_START 4 #define DMX_KERNEL_CLIENT 0x8000 }; does anyone know the meaning of following fields? uint8_t filter[DMX_FILTER_SIZE]; // this is the table id uint8_t mask[DMX_FILTER_SIZE]; // ??? it sometimes is set to 0xff, but for PAT it is also 0x00 uint8_t mode[DMX_FILTER_SIZE]; // ??? I haven't found any reference for this in the DVB API Specs regards, Markus -- 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] Terratec Cinergy HTC USB XS HD
On Sat, Jul 18, 2009 at 12:46 PM, Mario Fetkamario.fe...@gmail.com wrote: On Saturday, 18. July 2009 04:06:13 Alain Kalker wrote: Op maandag 15-06-2009 om 22:36 uur [tijdzone +0200], schreef sacha: Hello Does anybody know if this devise will ever work with Linux? It was promised by one person last year the support will be available within months. One year has gone, nothing happens. Is there any alternatives to develop a driver for this devise aside from this person? Since there has been no answer to your question for some time, I think I will step in. From http://mcentral.de/wiki/index.php5/Terratec_HTC_XS , the future for a driver from Markus for this device does seem to look quite bleak. However, from looking in the mailinglist archive I gather that Steven Toth has offered to try getting it to work if someone is willing to provide him with a device. Maybe you two could get in contact. I myself am also interested in a driver for this device but I haven't got one yet. Kind regards, Alain as far as i know there already exists a driver but it could not be published as it is based on the micronas refernce driver i think the problem is related to http://www.linuxtv.org/pipermail/linux-dvb/2008-December/030738.html but this new situation with http://www.tridentmicro.com/Product_drx_39xyK.asp can maby change something about this chip and it would be possible to get the rights to publish the driver under gpl-2 This won't solve the issue that the AVFB4910 has been discontinued. This affects FM Radio, Analogue TV, Composite and S-Video, that IC didn't get bought by Trident. regards, Markus -- 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: [PULL] http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881
On Mon, Jul 13, 2009 at 5:23 AM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881 for the following: em28xx: set GPIO properly for Pinnacle Hybrid Pro analog support em28xx: make support work for the Pinnacle Hybrid Pro (eb1a:2881) You might add a message to dmesg, that this setting can burn other devices which use the eb1a:2881 vendor/productid. Especially Pinnacle they didn't add Svideo/Composite to their device and it works slightly different than the others. Best Regards, Markus -- 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: [PULL] http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881
On Mon, Jul 13, 2009 at 4:08 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Mon, Jul 13, 2009 at 9:51 AM, Markus Rechbergermrechber...@gmail.com wrote: On Mon, Jul 13, 2009 at 5:23 AM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881 for the following: em28xx: set GPIO properly for Pinnacle Hybrid Pro analog support em28xx: make support work for the Pinnacle Hybrid Pro (eb1a:2881) You might add a message to dmesg, that this setting can burn other devices which use the eb1a:2881 vendor/productid. Especially Pinnacle they didn't add Svideo/Composite to their device and it works slightly different than the others. Best Regards, Markus Hello Markus, Thank you for taking the time to review the patch and provide feedback. Two questions: 1. Are you suggesting that a warning be shown if someone manually uses card=52, or do you mean that we should show a warning if they actually have the Pinnacle Hybrid Pro 320e? I am using an eeprom checksum to ensure that not all devices with eb1a:2881 use the device profile, but rather only devices with the matching hash, so in theory the profile should only be associated with that one card. 2. Are there any additional details you can provide about the differences in the Pinnacle device you know of which is wired up differently than all the others? I am not entirely sure about which device you have, but there's one which does not support Svideo/Composite - there's no connector for it and internally it's not routed properly (although the hardware would be able to support it). I will check those devices this week. Personally, I would like to get rid of the card= modprobe option completely, as it presents a considerable risk of users who do not know any better damaging their hardware. I am obviously very concerned about any cases where devices could be damaged, and any additional information you could provide to help mitigate that risk is certainly welcome. I think there's no official way to solve this properly as this information is disclosed, so it will be up to the user if he burns his device or not when he uses a device with a generic ID. I still have those 2 Terratec devices which have a slightly melted case from the good old days where reverse engineered values have been used. Best Regards, Markus -- 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: Call for testers: Terratec Cinergy T XS USB support
Hi all, On Mon, Jun 29, 2009 at 4:00 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: Hello all, A few weeks ago, I did some work on support for the Terratec Cinergy T XS USB product. I successfully got the zl10353 version working and issued a PULL request last week (http://www.kernellabs.com/hg/~dheitmueller/em28xx-terratec-zl10353) There will be an alternative driver entirely in userspace available which works across all major kernelversions and distributions. It will support the old em28xx devices and handle audio routing for the most popular TV applications directly. This system makes compiling the drivers unnecessary across all available linux systems between 2.6.15 and ongoing. This package also allows commercial drivers from vendors, the API itself is almost the same as the video4linux/linuxdvb API. Installing a driver takes less than five seconds without having to take care about the kernel API or having to set up a development system. Aside of that it's operating system independent (working on Linux, MacOSX and FreeBSD). I think this is the way to go for the future since it adds more possibilities to the drivers, and it eases up and speeds up driver development dramatically. Best Regards, Markus However, the other version of the product, which contains a mt352 is not yet working. I am looking for people who own the device and would be willing to do testing of a tree to help debug the issue. Ideal candidates should have the experience using DVB devices under Linux in addition to some other known-working tuner product so we can be sure that certain frequencies are available and that the antenna/location work properly. If you are willing to provide remote SSH access for short periods of time if necessary, also indicate that in your email. Please email me if you are interested in helping out getting the device working. Thank you, 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 -- 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] Kworld DVB-T 323UR problems
On Sun, Jun 21, 2009 at 11:44 PM, Laszlo Kustanlkus...@gmail.com wrote: Hi everyone, I have a Kword DVB-T 323UR connected to a Linux Mint 7 Gloria (based on Ubuntu Jaunty), kernel 2.6.28. I successfully compiled em28xx, the firmware was obtained based on these steps: 1) Download the windows driver with something like: wget http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip 2) Extract the file hcw85bda.sys from the zip into the current dir: unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip Driver85/hcw85bda.sys 3) run the script: ./extract_xc3028.pl 4) copy the generated file: cp xc3028-v27.fw /lib/firmware My windows driver is called embda.sys, so I'm not sure whether the firmware is 100% good for my tuner or not. I have a couple of problems: 1. no analog audio, but I found out this works with workarounds I tried several tricks: a. sox -c 2 -r 32000 -t ossdsp /dev/dsp1 -t ossdsp /dev/dsp this works, but with a 4-5 second delay between audio and video b. arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | play -q -c 2 -r 32000 -t wav - I get an error: l...@laco-desktop ~ $ arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | play -q -c 2 -r 32000 -t wav - [1] 9084 l...@laco-desktop ~ $ Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 32000 Hz, Stereo Warning: rate is not accurate (requested = 32000Hz, got = 48000Hz) please, try the plug plugin arecord: pcm_read:1529: read error: Input/output error play wav: Premature EOF on .wav input file c. install modified tvtime from mcentral.de I get an error in this case too: Reading configuration from /usr/etc/tvtime/tvtime.xml Reading configuration from /home/laco/.tvtime/tvtime.xml HDA NVidia : AD198x Analog hw:0,0 Em28xx Audio : Empia 28xx Capture hw:1,0 opening: hw:1,0 Access type not available My arecord -l output is: l...@laco-desktop ~ $ arecord -l List of CAPTURE Hardware Devices card 0: NVidia [HDA NVidia], device 0: AD198x Analog [AD198x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Em28xx Audio [Em28xx Audio], device 0: Em28xx Audio [Empia 28xx Capture] Subdevices: 1/1 Subdevice #0: subdevice #0 2. my remote is not recognized. Here is the em28xx part from dmesg: l...@laco-desktop ~ $ dmesg | grep em28xx [11231.562817] em28xx v4l2 driver version 0.0.1 loaded [11231.564913] em28xx: new video device (eb1a:e323): interface 0, class 255 [11231.564920] em28xx: setting up device on a USB 1.1 bus [11231.564924] em28xx: your device won't work properly when [11231.564927] em28xx: not attached to a USB 2.0 highspeed bus [11231.564931] em28xx: more information: [11231.564933] em28xx: http://mcentral.de/wiki/index.php5/Talk:Em2880 please pay attention to that line... it probably will not work with usb 1.0. Markus [11231.564942] em28xx #0: Alternate settings: 8 [11231.564946] em28xx #0: Alternate setting 0, max size= 0 [11231.564950] em28xx #0: Alternate setting 1, max size= 512 [11231.564954] em28xx #0: Alternate setting 2, max size= 640 [11231.564958] em28xx #0: Alternate setting 3, max size= 768 [11231.564962] em28xx #0: Alternate setting 4, max size= 832 [11231.564966] em28xx #0: Alternate setting 5, max size= 896 [11231.564969] em28xx #0: Alternate setting 6, max size= 960 [11231.564973] em28xx #0: Alternate setting 7, max size= 1020 [11240.939178] em28xx #0: V4L2 VBI device registered as /dev/vbi0 [11240.998075] em28xx #0: V4L2 device registered as /dev/video0 [11240.998087] em28xx #0: Found KWorld E323 [11240.998153] usbcore: registered new interface driver em28xx [11241.064491] em28xx-audio.c: probing for em28x1 non standard usbaudio [11241.064497] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [11241.922736] em28xx-audio: device is currently in analog TV mode Nothing about input devices here and neither in /proc/bus/input/devices. 3. heat problems I noticed that when it is connected, it gets quite hot, even if no dvb software is running. In Windows it does not get so hot, even when watching tv. Sorry for this long mail. The first point would be the most important to solve, if you need more details to help me, no problem. Thanks, Laszlo ___ 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 -- 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