[linux-dvb] hvr-1800 status?
I just picked up this card and I'm looking forward to trying it. I run Fedora 7 x86_64 2.6.23-1.10. I guess I'll try the steps as described at http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers and see how it goes. How close are we to getting NTSC to work? Do I need firmware for this card? Advice and pointers welcome. John ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-usb-vp702x-02.fw
The starbox 1 is quite limited in regards to data streaming: It has only 8 PID-filter-entries (Where in my tests I only could use 6). That makes the card quite uncomfortable to use for end-user-software like vdr or mythtv. This is mainly the reason why I skipped adding support for it. Patrick. On Fri, 2 Nov 2007, Greg Suarez wrote: Brandon, Considering that Patrick is one of the developers of the vp702x driver and he says that Starbox I isn't supported so not we can do. Patrick, Are there any plans to add support for the Starbox I? Can we help in anyway? Thanks, Greg On Nov 2, 2007 2:32 PM, Brandon Nolte [EMAIL PROTECTED] wrote: Greg, I have the 2.6.22-14 kernel under Gusty. I have tried fedora slackware knoppmyth and a gentoo derivation. I am unsure if i have the starbox or the starbox 2 I have had some progress. The firmware I had downloaded was messed up. I have tried the one of the german site that was linked to before. I am now able to get the unit to register and create a /dev/dvb/adapter. I seem to be getting the same error as you involving the -110. Any eta on support for the starbox. I am more than willing to help out in any way. Bus 001 Device 005: ID 13d3:3207 IMC Networks Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x13d3 IMC Networks idProduct 0x3207 bcdDevice2.09 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 100 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Device Status: 0x0002 (Bus Powered) Remote Wakeup Enabled [628036.456000] usb 1-3: new high speed USB device using ehci_hcd and address 5 [628036.588000] usb 1-3: configuration #1 chosen from 1 choice [628036.588000] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in cold state, will try to load a firmware [628036.60] dvb-usb: downloading firmware from file 'dvb-usb- vp702x-02.fw' [628036.62] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in warm state. [628036.62] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [628036.62] DVB: registering new adapter (TwinhanDTV StarBox DVB- S USB2.0 (VP7021)) [628036.624000] dvb-usb: MAC address: 00:08:ca:15:26:48 [628036.644000] vp702x: system string: USB702X: [628036.644000] DVB: registering frontend 0 (Twinhan DST-like frontend (VP7021/VP7020) DVB-S)... [628036.648000] input: IR-receiver inside an USB DVB receiver as / class/input/input7 [628036.648000] dvb-usb: schedule remote query interval to 400 msecs. [628036.648000] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully initialized and connected. [628501.80] vp702x: usb in operation failed. (-110) [EMAIL PROTECTED]:/dev/dvb/adapter0# ls -latr total 0 crw-rw 1 root video 212, 7 2007-11-02 17:05 net0 crw-rw 1 root video 212, 3 2007-11-02 17:05 frontend0 crw-rw 1 root video 212, 5 2007-11-02 17:05 dvr0 crw-rw 1 root video 212, 4 2007-11-02 17:05 demux0 drwxr-xr-x 3 root root 60 2007-11-02 17:05 .. drwxr-xr-x 2 root root 120 2007-11-02 17:05 . [EMAIL PROTECTED]:/dev/dvb/adapter0# scan ~/61.5w scanning /root/61.5w using
Re: [linux-dvb] dvb_usb_vp7045 usb control message out went wrong. Solution!
Hi,
Back in May in this mailing list there were few messages describing a problem
with Twinhan Alpha USB2 DVB-T (the old device, not the new one with the same
brand name which doesn't work at all in Linux, yet) device. Couple people
reported (including me) that this device had problems in Linux VDR application.
DVB-T TV picture works great with the device, for a while. Every now and then
the device starts to throw usb in went wrong and/or usb out went wrong
error messages in dmesg log. After the the whole system started to crawl and
didn't recover until the device was disconnected and re-connected in USB port
(well, that breaks VDR app so it had to be restarted also).
The problem could be related to VIA EPIA mini-itx boards (I have Epia M1
board) because on www.vdr-portal.de (in LinVDR forum section) some other people
were reporting the same problem and at least one of them had EPIA board also.
Finally I have found a solution in my hardware setup. It required small
modification in drivers/media/dvb/dvb-usb/vp7045.c Kernel module (Twinhan
alpha2 uses dvb-usb-vp7045 module). If some of you have the same problem then
maybe attached diff patch works for you too.
I don't know too much about Linux DVB API and dvb arhitechture there so the
diff is just a hack. There could be easier or better solution available also.
The attached diff is probably useful only for in those scenarios where this
issue is giving show stopper problems.
Here is copy-paste of the post I did in
http://www.vdr-portal.de/board/thread.php?threadid=61812page=2 forum post.
- Mike N
--
Hello,This is an old topic but just wanted to share experiences and findings. I
had this same issue usb out went wrong with Epia M1 board and Twinhan
Alpha USB2 DVB-T tuner.Mozard seems to have Epia board also and having the same
kind of errors, so could be that something is non-standard in Epia USB
ports.Mr. Google didn't have an answer to this problem, only few hits to
pages describing the same problem. I have built Epia based VDR and eventually I
got frustrated enough to look more closely into this problem.The good news is
that at least in my hardware combination I have found a solution. Maybe it
helps in your situation also.I tracked down the problem into Kernel
dvb-usb-vp7045 module and hack fix modification in the corresponding vp7045.c
source file did the trick in my system (requires kernel module
re-compilation).The problem was the usb-in error came always first and after
that it started to throw usb out went wrong errors. I hardly ever recovered
from that error until Twinhan device was disconnected and re-connected in USB
port. The exact error code from failed usb command was always ETIMEDOUT (110),
so the command didn't complete properly in USB device.I have Linux 2.6.21.1
kernel but I think the module I modifed is pretty much the same in more recent
kernels too (and few steps older also).I modified
linux-2.6.21.1/drivers/media/dvb/dvb-usb/vp7045.c source file in a following
way:- From line 22 begins int vp7045_usb_op function- Few lines below in this
function there are two usb_control_msg function calls (the first one is out and
second one in usb command).- I added simple FOR loop to re-try the USB-IN
command few times if the error code was timeout error (and increasing timeout
value each time just in case until command succeeds).This re-send the command
fix does the magic in my Epia. Jihuuu! I still get usb in went wrong every
now and then but the driver automatically recovers from it within few secs so I
don't even notice it if I don't look at dmesg log outputs.If you have problems
with usb OUT went wrong situations in a way where IN command never failed at
first then maybe similar re-try and timeout increase fixes that too. But, in
my case I noticed that the first error message was always usb in went wrong
and only after that it started to throw usb out went wrong.Please see the
attached diff path file for a more detailed code lines. This is hack fix so
defintely backup the original vp7045.c file before appyling the patch.Hopefully
this hack fix works for you also. For me it works great.- Mike
_
Connect to the next generation of MSN Messenger
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtaglinediff -Naur old/vp7045.c new/vp7045.c
--- old/vp7045.c2007-11-04 22:19:39.0 +0200
+++ new/vp7045.c2007-11-04 22:20:40.0 +0200
@@ -21,6 +21,7 @@
int vp7045_usb_op(struct dvb_usb_device *d, u8 cmd, u8 *out, int outlen, u8
*in, int inlen, int msec)
{
+ int usbResult, idx; /* Hack fix to usb went wrong */
int ret = 0;
u8 inbuf[12] = { 0 }, outbuf[20] = { 0 };
@@ -52,10 +53,28 @@
msleep(msec);
+/* Hack fix: Removed code below and replaced with re-try looping
if (usb_control_msg(d-udev,
Re: [linux-dvb] Still no VHF support in mt2266 ?
In my hg repository the patch is committed. Due to time limitations I could not prepare it for 2.6.24 ... sorry. Patrick. On Sat, 3 Nov 2007, Michael Baudinne wrote: Namaste, I have a Nova-TD usb stick on Debian Etch with the latest hg v4l-dvb tree compiled against the backports kernel 2.6.22 and Firmware dvb-usb-dib0700-1.10.fw .. so far it's running smoothly :-) But I'm not getting any channels on transponders below 470MHz, because the kernel tells me, while tuning to these channels: kernel: DVB: frontend 1 frequency 19150 out of range (47000..86000) Unfortunately, in Berlin there are 8 TV channels, which are on 177.5MHz and 191.5MHz. After doing some research i figured that this is due to the mt2266 module, which obviously currently does not support VHF: http://www.linuxtv.org/pipermail/linux-dvb/2007-October/020937.html After that date I wasn't able to find any further progress in word or patch on removing this limitation. Manually setting .frequency_min to 17400 in mt2266.c removes the warning while tuning, but it seems, the tuner still does not know how to tune correctly. Since I'm not a programmer, can I do some patch testing ? Regards Michael ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hvr-1800 status?
[EMAIL PROTECTED] wrote: I just picked up this card and I'm looking forward to trying it. I run Fedora 7 x86_64 2.6.23-1.10. I guess I'll try the steps as described at http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers and see how it goes. How close are we to getting NTSC to work? Do I need firmware for this card? Advice and pointers welcome. Funny that you should ask about analog mode NTSC just a week or two after we've confirmed that QAM works. (ATSC has always worked, QAM needed a small patch to fix). The NTSC tuner is already supported, but the cx23885 bridge driver does not yet support analog mode. I don't know how long that will take, but it shouldn't be too far off. You don't need any firmware for the hvr1800. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hvr-1800 status?
Michael Krufky wrote: [EMAIL PROTECTED] wrote: I just picked up this card and I'm looking forward to trying it. I run Fedora 7 x86_64 2.6.23-1.10. I guess I'll try the steps as described at http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers and see how it goes. How close are we to getting NTSC to work? Do I need firmware for this card? Advice and pointers welcome. Funny that you should ask about analog mode NTSC just a week or two after we've confirmed that QAM works. (ATSC has always worked, QAM needed a small patch to fix). The NTSC tuner is already supported, but the cx23885 bridge driver does not yet support analog mode. I don't know how long that will take, but it shouldn't be too far off. You don't need any firmware for the hvr1800. Regards, Mike The cx23885 has a modified version of the cx25840 a/v decoder inside it. It uses different firmware than the normal cx25840 driver already present in Linux. As such, to support analog, I also have to push some patches into that driver for the differing registers (and firmware). Analog preview and analog encoder running well in lab conditions and they are pretty stable, but I need to spend quality time cherry picking pieces from multiple development trees to build something acceptable to the linuxtv community. Soon, think weeks not days. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] GDI Black Gold [14c7:0108]
Hi, Have a GDI Black Gold card with subsystem 14c7:0108 and I cannot make it work. Does anyone on the list have a working config for this card and/or know how to make this card work? I'm getting so far as video1 and vbi1 is created, but I don't have any entries in /dev/dvb/. cat /dev/video1 test.mpg produces a video typical of a tv picture without signal (ant-war)... :) config /etc/modprobe.conf: alias char-major-81-1 cx88-dvb options cx88xx card=2 i2c_scan=1 lspci -v: 02:09.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) Subsystem: Modular Technology Holdings Ltd GDI Black Gold Flags: bus master, medium devsel, latency 64, IRQ 23 Memory at f500 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 02:09.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) Subsystem: Modular Technology Holdings Ltd Unknown device 0108 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at f600 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 dmesg: CORE cx88[0]: subsystem: 14c7:0108, board: GDI Black Gold [card=2,insmod option] TV tuner -1 at 0x1fe, Radio tuner -1 at 0x1fe cx88[0]: Test OK cx88[0]: i2c scan: found device @ 0x10 [???] cx88[0]: i2c scan: found device @ 0xa0 [eeprom] cx88[0]: GDI: tuner=unknown cx88[0]/2: cx2388x 8802 Driver Manager ACPI: PCI Interrupt :02:09.0[A] - GSI 21 (level, low) - IRQ 23 CORE cx88[0]: subsystem: 14c7:0108, board: GDI Black Gold [card=2,insmod option] TV tuner -1 at 0x1fe, Radio tuner -1 at 0x1fe cx88[0]: Test OK cx88[0]: i2c scan: found device @ 0x10 [???] cx88[0]: i2c scan: found device @ 0xa0 [eeprom] cx88[0]: GDI: tuner=unknown cx88[0]/0: found at :02:09.0, rev: 5, irq: 23, latency: 64, mmio: 0xf500 cx88[0]/0: registered device video1 [v4l2] cx88[0]/0: registered device vbi1 Thanks, //riru ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Johannes Stezenbach wrote:
On Fri, Nov 02, 2007, Steven Toth wrote:
The design goals for me are:
1) We stop trying to predict what the API will need in 5 years, and focus
on building a very simplistic ioctl API for getting and setting generic
frontend properties, it should be basic enough to deal with any new
modulation type (or advanced tuner) that we know of today.
good one
2) We change the tuning mechanism from being (mostly) atomic (SET_FRONTEND)
to a looser command/sequence definition. (Thereby stepping away from fixed
structs that define the ABI). With two new ioctls
(get_property/set_property) and a simple property struct which specifies
how generic types are passed to/from the kernel.
no so good
3) A userland library _may_ offer a number of helper functions to simplify
in terms of applications development, turning this:
many people seem to hate ALSA, there's a lesson to be learned here
command.id = BEGIN_TRANSACTION
ioctl(SET_PROPERTY, command);
command.id = SET_MODULATION
command.arg = 8VSB
ioctl(SET_PROPERTY, command);
command.id = SET_FREQUENCY
command.arg = 59125
ioctl(SET_PROPERTY, command);
command.id = VALIDATE_TRANSACTION
ioctl(SET_PROPERTY, command);
command.id = END_TRANSACTION
ioctl(SET_PROPERTY, command);
Into a more human readable form like this:
int tune_8vsb(frequency);
It's a basic approach, we trade off multiple ioctls (at a very low rate)
entering the kernel, for a very flexible tuning approach to frontend
control.
Once you have those tag/value pairs, you could batch them
together in an array and pass them down in one ioctl. This
avoids the ugly transaction stuff and keeps it atomic.
And I think it wouldn't look too ugly in user code, e.g.:
struct dvb_tuning_param p[3] = {
{ .id = MODULATION, .val = MOD_8VSB },
{ .id = FREQUENCY, .val = 59125 },
{ .id = 0 }
};
ioctl(fd, DVB_TUNE, p);
You can't reliably pass in variably length arrays into the kernel, or
none of the other kernel wide drivers do, they need to be fixed length
for sanity reasons. That being said, I have a newly defined type which
represents an array enabling 16 messages to be passed in a single
transaction.
IE. It's no limited by array size. ioctls can be chained together to
form atomic tuning operations and are not bound by length, should any
future hardware require radically different parameters/operations.
Here's the message set I've using with QAM for example:
tv_properties_t _qam_cmdseq = {
{ .cmd = TV_SEQ_START },
{ .cmd = TV_SET_FREQUENCY, .u.data = 56100 },
{ .cmd = TV_SET_MODULATION, .u.data = QAM_AUTO },
{ .cmd = TV_SET_INVERSION, .u.data = INVERSION_AUTO },
{ .cmd = TV_SET_BANDWIDTH, .u.data = BANDWIDTH_AUTO },
{ .cmd = TV_SEQ_COMPLETE },
{ .cmd = 0 },
};
... and here's the ioctl structure in question from frontend.h
typedef struct {
__u32 cmd;
union {
__u32 data;
struct {
__u8 data[32];
__u32 len;
} buffer;
} u;
} tv_property_t;
/* No more than 16 properties during any given ioctl */
typedef tv_property_t tv_properties_t[16];
#define FE_SET_PROPERTY_IOW('o', 82, tv_properties_t)
I have other changes to frontend.h that I'll describe below, in answer
to your other points.
Unrelated: It's important to note that the new API allows messages to be
atomic individually, or grouped into transactions for a single atomic
operation. One example is a single message to control DiSEqC, which in
the current published API occurs immediately. The current API is
completely atomic, and offers nothing for future hardware which may need
a finer grain of control. (Think analog)
Hence, this API supports both mechanisms.
But there's more work to do:
- need for .val being variable lenght or a union of different types?
See the current union. It supports a generic u32 for passing enums or
other values, and also a generic byte buffer (which can be chained with
multiple messages and multiple ioctls via transactions grouping). This
generic buffer is large enough to store the current DiSEqC message
mechanisms, but scalable to be able to support any number of future
messages with any message lengths, literally into multi megabytes if
that's what is required.
- extend existing enums or define new ones for MODULATION etc?
A mixture of both.
Where appropriate the current enums have been extended to support new
modulation types, FECs etc. In more cases than not, this is the case.
Where appropriate new enums/type have been defined to support new user
facing attributes (rolloff/pilot) being a classic case (although both
current drivers detect Pilot automatically). This doesn't impact the
ABI, but mechanisms like this (for future devices) show how
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
Markus Rechberger wrote:
On 11/5/07, Steven Toth [EMAIL PROTECTED] wrote:
Johannes Stezenbach wrote:
On Fri, Nov 02, 2007, Steven Toth wrote:
The design goals for me are:
1) We stop trying to predict what the API will need in 5 years, and focus
on building a very simplistic ioctl API for getting and setting generic
frontend properties, it should be basic enough to deal with any new
modulation type (or advanced tuner) that we know of today.
good one
2) We change the tuning mechanism from being (mostly) atomic
(SET_FRONTEND)
to a looser command/sequence definition. (Thereby stepping away from
fixed
structs that define the ABI). With two new ioctls
(get_property/set_property) and a simple property struct which specifies
how generic types are passed to/from the kernel.
no so good
3) A userland library _may_ offer a number of helper functions to
simplify
in terms of applications development, turning this:
many people seem to hate ALSA, there's a lesson to be learned here
command.id = BEGIN_TRANSACTION
ioctl(SET_PROPERTY, command);
command.id = SET_MODULATION
command.arg = 8VSB
ioctl(SET_PROPERTY, command);
command.id = SET_FREQUENCY
command.arg = 59125
ioctl(SET_PROPERTY, command);
command.id = VALIDATE_TRANSACTION
ioctl(SET_PROPERTY, command);
command.id = END_TRANSACTION
ioctl(SET_PROPERTY, command);
Into a more human readable form like this:
int tune_8vsb(frequency);
It's a basic approach, we trade off multiple ioctls (at a very low rate)
entering the kernel, for a very flexible tuning approach to frontend
control.
Once you have those tag/value pairs, you could batch them
together in an array and pass them down in one ioctl. This
avoids the ugly transaction stuff and keeps it atomic.
And I think it wouldn't look too ugly in user code, e.g.:
struct dvb_tuning_param p[3] = {
{ .id = MODULATION, .val = MOD_8VSB },
{ .id = FREQUENCY, .val = 59125 },
{ .id = 0 }
};
ioctl(fd, DVB_TUNE, p);
You can't reliably pass in variably length arrays into the kernel, or
none of the other kernel wide drivers do, they need to be fixed length
for sanity reasons. That being said, I have a newly defined type which
represents an array enabling 16 messages to be passed in a single
transaction.
Hi Steven,
just have a look at the i2c-dev driver it passes a variable length to
the kernel.
Hey Markus,
Good. I looked at about 40 different drivers, then ran some kernel wide
greps before giving up. I can see it now, this is a much nicer approach.
Thanks,
- Steve
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Mon, Nov 05, 2007, Steven Toth wrote:
Johannes Stezenbach wrote:
struct dvb_tuning_param p[3] = {
{ .id = MODULATION, .val = MOD_8VSB },
{ .id = FREQUENCY, .val = 59125 },
{ .id = 0 }
};
ioctl(fd, DVB_TUNE, p);
You can't reliably pass in variably length arrays into the kernel, or none
of the other kernel wide drivers do, they need to be fixed length for
sanity reasons.
Of course you can have variable length args to ioctl(). It's
just that you can't let dvb_usercopy() do the work anymore but
have to call copy_from_user() yourself, but I would favor a simple,
generic API anytime over one with unnecessary, arbitrary
limits, so IMHO it's worth the little extra effort.
#define DVB_TUNE _IOC(_IOC_WRITE,'o',82,0)
plus
diff -r 1acfe4149714 linux/drivers/media/dvb/dvb-core/dvbdev.c
--- a/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 10:30:39 2007 -0200
+++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 18:23:41 2007 +0100
@@ -362,9 +362,11 @@ int dvb_usercopy(struct inode *inode, st
case _IOC_READ: /* some v4l ioctls are marked wrong ... */
case _IOC_WRITE:
case (_IOC_WRITE | _IOC_READ):
- if (_IOC_SIZE(cmd) = sizeof(sbuf)) {
+ if (_IOC_SIZE(cmd) == 0)
+ parg = arg;
+ else if (_IOC_SIZE(cmd) = sizeof(sbuf))
parg = sbuf;
- } else {
+ else {
/* too big to allocate from stack */
mbuf = kmalloc(_IOC_SIZE(cmd),GFP_KERNEL);
if (NULL == mbuf)
(untested)
(BTW, the majority of ioctls don't encode the argument size, this
feature was invented just a few years ago; see man ioctl_list)
Or you could encode the lenght seperately like e.g.
I2C_RDWR does with its struct i2c_rdwr_ioctl_data argument.
It's a matter of taste, not sanity or security.
1) I've made minor changes to dvb_core to interpret these messages and
handle the ioctl. No changes have been made to the frontend drivers.
2) Adding support for s2 _inside_ the kernel will mean adding a single
method to dvb_frontend_ops which allows the dvb_core to notify a new S2
driver. The goal here is to minimize these changes also. I haven't
demonstrated that code here, becuse I felt it was more important to show
the impact to the userland API/ABI, knowing that DVB-S2 and other advanced
types (including analog) would naturally fit well within this model.
3) This applies to all devs. I welcome all feedback, for sure the sytax
might need some cleanup, but please don't shoot the idea down when it's
only had 6-8 hours work of engineering behind it. It's proof of concept. It
doesn't contain any of Manu's code so I don't feel bound politically or
technically. I think given another 4-5 hours I could show the HVR4000
working, and demonstrate many of the userland signal/statistic API's.
At this stage I'm looking for a Yes, in principle we like the idea, but
show me how you do feature XYZ from other devs. At which point I'll flush
out more code this would probably lead to an RFC for your approval.
Seems like no one is interested.
BTW, since every DVB-S2 demod is also a DVB-S demod, why does
no one split the DVB-S parts of their driver for merging
first? It would make the users happy as it would change the
state from card not supported to card works for 95% of existing
transponders. (Dunno how this fits into this thread but...)
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Mon, Nov 05, 2007, Johannes Stezenbach wrote:
Of course you can have variable length args to ioctl(). It's
just that you can't let dvb_usercopy() do the work anymore but
have to call copy_from_user() yourself, but I would favor a simple,
generic API anytime over one with unnecessary, arbitrary
limits, so IMHO it's worth the little extra effort.
#define DVB_TUNE _IOC(_IOC_WRITE,'o',82,0)
plus
Here's a better patch, still untested but without
obvious bugs, I hope ;-) :
diff -r 1acfe4149714 linux/drivers/media/dvb/dvb-core/dvbdev.c
--- a/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 10:30:39 2007 -0200
+++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 18:41:43 2007 +0100
@@ -362,9 +362,11 @@ int dvb_usercopy(struct inode *inode, st
case _IOC_READ: /* some v4l ioctls are marked wrong ... */
case _IOC_WRITE:
case (_IOC_WRITE | _IOC_READ):
- if (_IOC_SIZE(cmd) = sizeof(sbuf)) {
+ if (_IOC_SIZE(cmd) == 0)
+ parg = arg;
+ else if (_IOC_SIZE(cmd) = sizeof(sbuf))
parg = sbuf;
- } else {
+ else {
/* too big to allocate from stack */
mbuf = kmalloc(_IOC_SIZE(cmd),GFP_KERNEL);
if (NULL == mbuf)
@@ -373,7 +375,7 @@ int dvb_usercopy(struct inode *inode, st
}
err = -EFAULT;
- if (copy_from_user(parg, (void __user *)arg, _IOC_SIZE(cmd)))
+ if (_IOC_SIZE(cmd) copy_from_user(parg, (void __user *)arg,
_IOC_SIZE(cmd)))
goto out;
break;
}
@@ -390,7 +392,7 @@ int dvb_usercopy(struct inode *inode, st
{
case _IOC_READ:
case (_IOC_WRITE | _IOC_READ):
- if (copy_to_user((void __user *)arg, parg, _IOC_SIZE(cmd)))
+ if (_IOC_SIZE(cmd) copy_to_user((void __user *)arg, parg,
_IOC_SIZE(cmd)))
err = -EFAULT;
break;
}
Johannes
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On 05/11/2007, Johannes Stezenbach [EMAIL PROTECTED] wrote: Seems like no one is interested. BTW, since every DVB-S2 demod is also a DVB-S demod, why does no one split the DVB-S parts of their driver for merging first? It would make the users happy as it would change the state from card not supported to card works for 95% of existing transponders. (Dunno how this fits into this thread but...) I'm fascinated just to see the development process. Like the idea of splitting the demods, I'd be happy with S working fine and adding S2 as that evolves. Just so u know at least someone is watching! ;) Bon ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Monday 05 November 2007, Johannes Stezenbach wrote:
On Mon, Nov 05, 2007, Steven Toth wrote:
Johannes Stezenbach wrote:
struct dvb_tuning_param p[3] = {
{ .id = MODULATION, .val = MOD_8VSB },
{ .id = FREQUENCY, .val = 59125 },
{ .id = 0 }
};
ioctl(fd, DVB_TUNE, p);
You can't reliably pass in variably length arrays into the kernel, or none
of the other kernel wide drivers do, they need to be fixed length for
sanity reasons.
Of course you can have variable length args to ioctl(). It's
just that you can't let dvb_usercopy() do the work anymore but
have to call copy_from_user() yourself, but I would favor a simple,
generic API anytime over one with unnecessary, arbitrary
limits, so IMHO it's worth the little extra effort.
#define DVB_TUNE _IOC(_IOC_WRITE,'o',82,0)
plus
diff -r 1acfe4149714 linux/drivers/media/dvb/dvb-core/dvbdev.c
--- a/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 10:30:39
2007 -0200
+++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 18:23:41
2007 +0100
@@ -362,9 +362,11 @@ int dvb_usercopy(struct inode *inode, st
case _IOC_READ: /* some v4l ioctls are marked wrong ... */
case _IOC_WRITE:
case (_IOC_WRITE | _IOC_READ):
- if (_IOC_SIZE(cmd) = sizeof(sbuf)) {
+ if (_IOC_SIZE(cmd) == 0)
+ parg = arg;
+ else if (_IOC_SIZE(cmd) = sizeof(sbuf))
parg = sbuf;
- } else {
+ else {
/* too big to allocate from stack */
mbuf = kmalloc(_IOC_SIZE(cmd),GFP_KERNEL);
if (NULL == mbuf)
(untested)
(BTW, the majority of ioctls don't encode the argument size, this
feature was invented just a few years ago; see man ioctl_list)
Or you could encode the lenght seperately like e.g.
I2C_RDWR does with its struct i2c_rdwr_ioctl_data argument.
It's a matter of taste, not sanity or security.
1) I've made minor changes to dvb_core to interpret these messages and
handle the ioctl. No changes have been made to the frontend drivers.
2) Adding support for s2 _inside_ the kernel will mean adding a single
method to dvb_frontend_ops which allows the dvb_core to notify a new S2
driver. The goal here is to minimize these changes also. I haven't
demonstrated that code here, becuse I felt it was more important to show
the impact to the userland API/ABI, knowing that DVB-S2 and other advanced
types (including analog) would naturally fit well within this model.
3) This applies to all devs. I welcome all feedback, for sure the sytax
might need some cleanup, but please don't shoot the idea down when it's
only had 6-8 hours work of engineering behind it. It's proof of concept. It
doesn't contain any of Manu's code so I don't feel bound politically or
technically. I think given another 4-5 hours I could show the HVR4000
working, and demonstrate many of the userland signal/statistic API's.
At this stage I'm looking for a Yes, in principle we like the idea, but
show me how you do feature XYZ from other devs. At which point I'll flush
out more code this would probably lead to an RFC for your approval.
Seems like no one is interested.
BTW, since every DVB-S2 demod is also a DVB-S demod, why does
no one split the DVB-S parts of their driver for merging
first? It would make the users happy as it would change the
state from card not supported to card works for 95% of existing
transponders. (Dunno how this fits into this thread but...)
hi everybody,
what are we doing now?
imho we are discussing a new change to the dvb-s2 api again.
although i do like this ioctl approach for further enhancements of the api,
i must admit that things that are already done have to be done again.
iirc, there is a multiproto version of szap, vdr, ...
although, existing drivers e.g. stb0899 must be rewritten/patched to handle the
new iotcl.
at least i do not know what this will mean to the rework and test scenario,
on both sides. this means if we take multiproto from manu - what has steven got
to do,
and, if we take stevens approach, whats on manus side.
i would really appreciate to get a working compromise instead of starting this
api extension
all over again for the X time since Nov. 2005 when - iirc felix domke and me -
started the discussion.
Yes, in principle I like the idea but someday we must get an end to the
implementation and
merge it.
best regards
marcel
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
At this stage I'm looking for a Yes, in principle we like the idea, but show me how you do feature XYZ from other devs. At which point I'll flush out more code this would probably lead to an RFC for your approval. Seems like no one is interested. yeah, apparently. (unrelated: thanks for the ioctl patch - mrec also pointed me in the right direction). BTW, since every DVB-S2 demod is also a DVB-S demod, why does no one split the DVB-S parts of their driver for merging first? It would make the users happy as it would change the state from card not supported to card works for 95% of existing transponders. (Dunno how this fits into this thread but...) It doesn't fit into the thread, but you're welcome to raise it. DVB-S only, I did that during late 2005, prior to adopting multiproto. Quickly it was clear that the community was behind Manu's project so I dropped it and started modifications for multiproto. Since then I've pushed back on the idea (in hindsight for way too long) because multiproto was close to completion for so long. In reality, that was a year ago and maybe it's time to revisit DVB-S support for the HVR4000. Given the current political climate I think I like that idea. I'll rework the driver and present a patch later this week. I can't speak for Manu's STB0899 driver. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-usb-vp702x-02.fw
Patrick, I'd like to contribute to the project, so maybe this will be a good place for me to start. Although the starbox 1 is limited by it's capabilities, at least I can contribute to the completeness of device support of the project. If you have the time and patience maybe you could help me get started with what is required to get the starbox working? Thanks, Greg On Nov 5, 2007 1:31 AM, Patrick Boettcher [EMAIL PROTECTED] wrote: The starbox 1 is quite limited in regards to data streaming: It has only 8 PID-filter-entries (Where in my tests I only could use 6). That makes the card quite uncomfortable to use for end-user-software like vdr or mythtv. This is mainly the reason why I skipped adding support for it. Patrick. On Fri, 2 Nov 2007, Greg Suarez wrote: Brandon, Considering that Patrick is one of the developers of the vp702x driver and he says that Starbox I isn't supported so not we can do. Patrick, Are there any plans to add support for the Starbox I? Can we help in anyway? Thanks, Greg On Nov 2, 2007 2:32 PM, Brandon Nolte [EMAIL PROTECTED] wrote: Greg, I have the 2.6.22-14 kernel under Gusty. I have tried fedora slackware knoppmyth and a gentoo derivation. I am unsure if i have the starbox or the starbox 2 I have had some progress. The firmware I had downloaded was messed up. I have tried the one of the german site that was linked to before. I am now able to get the unit to register and create a /dev/dvb/adapter. I seem to be getting the same error as you involving the -110. Any eta on support for the starbox. I am more than willing to help out in any way. Bus 001 Device 005: ID 13d3:3207 IMC Networks Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x13d3 IMC Networks idProduct 0x3207 bcdDevice2.09 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 100 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Device Status: 0x0002 (Bus Powered) Remote Wakeup Enabled [628036.456000] usb 1-3: new high speed USB device using ehci_hcd and address 5 [628036.588000] usb 1-3: configuration #1 chosen from 1 choice [628036.588000] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in cold state, will try to load a firmware [628036.60] dvb-usb: downloading firmware from file 'dvb-usb- vp702x-02.fw' [628036.62] dvb-usb: found a 'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)' in warm state. [628036.62] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [628036.62] DVB: registering new adapter (TwinhanDTV StarBox DVB- S USB2.0 (VP7021)) [628036.624000] dvb-usb: MAC address: 00:08:ca:15:26:48 [628036.644000] vp702x: system string: USB702X: [628036.644000] DVB: registering frontend 0 (Twinhan DST-like frontend (VP7021/VP7020) DVB-S)... [628036.648000] input: IR-receiver inside an USB DVB receiver as / class/input/input7 [628036.648000] dvb-usb: schedule remote query interval to 400 msecs. [628036.648000] dvb-usb: TwinhanDTV StarBox DVB-S USB2.0 (VP7021) successfully initialized and
Re: [linux-dvb] hvr-1800 status?
On Monday 05 November 2007 07:02:27 am Steven Toth wrote: Michael Krufky wrote: [EMAIL PROTECTED] wrote: I just picked up this card and I'm looking forward to trying it. I run Fedora 7 x86_64 2.6.23-1.10. I guess I'll try the steps as described at http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers and see how it goes. How close are we to getting NTSC to work? Do I need firmware for this card? Advice and pointers welcome. Funny that you should ask about analog mode NTSC just a week or two after we've confirmed that QAM works. (ATSC has always worked, QAM needed a small patch to fix). The NTSC tuner is already supported, but the cx23885 bridge driver does not yet support analog mode. I don't know how long that will take, but it shouldn't be too far off. Excellent, thank you Mike. I'm using an older pvr150 in my shiny new PCI-Express motherboard and I'm looking forward to replacing it with this PCI-Express card. If I can figure out how to split the cable I'll be able to run both tuners until I can remove the pvr150. You don't need any firmware for the hvr1800. Regards, Mike The cx23885 has a modified version of the cx25840 a/v decoder inside it. It uses different firmware than the normal cx25840 driver already present in Linux. As such, to support analog, I also have to push some patches into that driver for the differing registers (and firmware). Are you saying that I will need firmware to view analog tv? Analog preview and analog encoder running well in lab conditions and they are pretty stable, but I need to spend quality time cherry picking pieces from multiple development trees to build something acceptable to the linuxtv community. Soon, think weeks not days. Judging by my schedule, I might not be able to test this out tonight after all. Perhaps tomorrow night. Are you saying that the http://linuxtv.org/hg/v4l-dvb stuff will not have any of your good stuff checked in? - Steve Thanks for your help. As you can see, I'm a newb here. Advice on how to proceed is always welcome. John ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hvr-1800 status?
[EMAIL PROTECTED] wrote: On Monday 05 November 2007 07:02:27 am Steven Toth wrote: Michael Krufky wrote: [EMAIL PROTECTED] wrote: I just picked up this card and I'm looking forward to trying it. I run Fedora 7 x86_64 2.6.23-1.10. I guess I'll try the steps as described at http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers and see how it goes. How close are we to getting NTSC to work? Do I need firmware for this card? Advice and pointers welcome. Funny that you should ask about analog mode NTSC just a week or two after we've confirmed that QAM works. (ATSC has always worked, QAM needed a small patch to fix). The NTSC tuner is already supported, but the cx23885 bridge driver does not yet support analog mode. I don't know how long that will take, but it shouldn't be too far off. Excellent, thank you Mike. I'm using an older pvr150 in my shiny new PCI-Express motherboard and I'm looking forward to replacing it with this PCI-Express card. If I can figure out how to split the cable I'll be able to run both tuners until I can remove the pvr150. You don't need any firmware for the hvr1800. Regards, Mike The cx23885 has a modified version of the cx25840 a/v decoder inside it. It uses different firmware than the normal cx25840 driver already present in Linux. As such, to support analog, I also have to push some patches into that driver for the differing registers (and firmware). Are you saying that I will need firmware to view analog tv? Yes. Analog preview and analog encoder running well in lab conditions and they are pretty stable, but I need to spend quality time cherry picking pieces from multiple development trees to build something acceptable to the linuxtv community. Soon, think weeks not days. Judging by my schedule, I might not be able to test this out tonight after all. Perhaps tomorrow night. Are you saying that the http://linuxtv.org/hg/v4l-dvb stuff will not have any of your good stuff checked in? Yes. - Steve Thanks for your help. As you can see, I'm a newb here. Advice on how to proceed is always welcome. You're welcome. Once analog video is running, an patchset/announcement will be made here. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hvr-1800 status?
Hi guys, Would this apply to the hvr-1600 also? I've got both the hvr-1800 and 1600 in two different HP media boxes running Vista. Thanks - Original Message From: Steven Toth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: linux-dvb@linuxtv.org; Michael Krufky [EMAIL PROTECTED] Sent: Monday, November 5, 2007 9:02:27 AM Subject: Re: [linux-dvb] hvr-1800 status? Michael Krufky wrote: [EMAIL PROTECTED] wrote: I just picked up this card and I'm looking forward to trying it. I run Fedora 7 x86_64 2.6.23-1.10. I guess I'll try the steps as described at http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers and see how it goes. How close are we to getting NTSC to work? Do I need firmware for this card? Advice and pointers welcome. Funny that you should ask about analog mode NTSC just a week or two after we've confirmed that QAM works. (ATSC has always worked, QAM needed a small patch to fix). The NTSC tuner is already supported, but the cx23885 bridge driver does not yet support analog mode. I don't know how long that will take, but it shouldn't be too far off. You don't need any firmware for the hvr1800. Regards, Mike The cx23885 has a modified version of the cx25840 a/v decoder inside it. It uses different firmware than the normal cx25840 driver already present in Linux. As such, to support analog, I also have to push some patches into that driver for the differing registers (and firmware). Analog preview and analog encoder running well in lab conditions and they are pretty stable, but I need to spend quality time cherry picking pieces from multiple development trees to build something acceptable to the linuxtv community. Soon, think weeks not days. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hvr-1800 status?
Randall Stewart wrote: Hi guys, Would this apply to the hvr-1600 also? I've got both the hvr-1800 and 1600 in two different HP media boxes running Vista. Hi, No. Please comment/reply in the correct place, either at the end of the email or inline if you're referencing someone's comment. Thanks - Original Message From: Steven Toth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: linux-dvb@linuxtv.org; Michael Krufky [EMAIL PROTECTED] Sent: Monday, November 5, 2007 9:02:27 AM Subject: Re: [linux-dvb] hvr-1800 status? Michael Krufky wrote: [EMAIL PROTECTED] wrote: I just picked up this card and I'm looking forward to trying it. I run Fedora 7 x86_64 2.6.23-1.10. I guess I'll try the steps as described at http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers and see how it goes. How close are we to getting NTSC to work? Do I need firmware for this card? Advice and pointers welcome. Funny that you should ask about analog mode NTSC just a week or two after we've confirmed that QAM works. (ATSC has always worked, QAM needed a small patch to fix). The NTSC tuner is already supported, but the cx23885 bridge driver does not yet support analog mode. I don't know how long that will take, but it shouldn't be too far off. You don't need any firmware for the hvr1800. Regards, Mike The cx23885 has a modified version of the cx25840 a/v decoder inside it. It uses different firmware than the normal cx25840 driver already present in Linux. As such, to support analog, I also have to push some patches into that driver for the differing registers (and firmware). Analog preview and analog encoder running well in lab conditions and they are pretty stable, but I need to spend quality time cherry picking pieces from multiple development trees to build something acceptable to the linuxtv community. Soon, think weeks not days. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hvr-1800 status?
Randall Stewart wrote: - Original Message From: Steven Toth [EMAIL PROTECTED] To: Randall Stewart [EMAIL PROTECTED] Cc: linux-dvb@linuxtv.org Sent: Monday, November 5, 2007 1:37:05 PM Subject: Re: [linux-dvb] hvr-1800 status? Randall Stewart wrote: Hi guys, Would this apply to the hvr-1600 also? I've got both the hvr-1800 and 1600 in two different HP media boxes running Vista. Hi, No. Please comment/reply in the correct place, either at the end of the email or inline if you're referencing someone's comment. Thanks - Original Message From: Steven Toth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: linux-dvb@linuxtv.org; Michael Krufky [EMAIL PROTECTED] Sent: Monday, November 5, 2007 9:02:27 AM Subject: Re: [linux-dvb] hvr-1800 status? Michael Krufky wrote: [EMAIL PROTECTED] wrote: I just picked up this card and I'm looking forward to trying it. I run Fedora 7 x86_64 2.6.23-1.10. I guess I'll try the steps as described at http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers and see how it goes. How close are we to getting NTSC to work? Do I need firmware for this card? Advice and pointers welcome. Funny that you should ask about analog mode NTSC just a week or two after we've confirmed that QAM works. (ATSC has always worked, QAM needed a small patch to fix). The NTSC tuner is already supported, but the cx23885 bridge driver does not yet support analog mode. I don't know how long that will take, but it shouldn't be too far off. You don't need any firmware for the hvr1800. Regards, Mike The cx23885 has a modified version of the cx25840 a/v decoder inside it. It uses different firmware than the normal cx25840 driver already present in Linux. As such, to support analog, I also have to push some patches into that driver for the differing registers (and firmware). Analog preview and analog encoder running well in lab conditions and they are pretty stable, but I need to spend quality time cherry picking pieces from multiple development trees to build something acceptable to the linuxtv community. Soon, think weeks not days. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Sorry for the reply in the wrong place. I don't usually post to news lists. Is there an eta on the HVR-1600 support or project schedule etc that I could monitor? No problem, understood. A schedule, not yet although a driver is being developed. Any announcement would be made here. Thanks for the help. Anytime. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Geniatech SatBox
All, Does anyone gotten the SatBox from Geniatech to work? Can anyone recommend a supported USB-2 DVB-S device that can be acquired in the US? Thank you, Greg Suarez ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] (no subject)
Hi, DVB-T has just arrived in our town. I made a frequency file, that you can find in attachment. It works perfectly. Hoping this is the right place to post... Best Regards Olivier /home/garet/fr-Nancy Description: Binary data ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
