Re: [PATCH] [media] em28xx: support for Sundtek MediaTV Digital Home

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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 Stilmant
 wrote:
> 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

[Markus Rechberger]

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

[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.
 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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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)

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

 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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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?

[Markus Rechberger]

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.

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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?

[Markus Rechberger]

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?

[Markus Rechberger]

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?

[Markus Rechberger]

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?

[Markus Rechberger]

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]

[Markus Rechberger]

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]

[Markus Rechberger]

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]

[Markus Rechberger]

 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

[Markus Rechberger]

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?

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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?

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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?

[Markus Rechberger]

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...

[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

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...

[Markus Rechberger]

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...

[Markus Rechberger]

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...

[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
--
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...

[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
--
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...

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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?

[Markus Rechberger]

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?

[Markus Rechberger]

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

[Markus Rechberger]

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?

[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
--
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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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

[Markus Rechberger]

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