[PATCH] ov772x: add edge contrl support
Signed-off-by: Kuninori Morimoto
---
This patch is 1st step for extra settings
drivers/media/video/ov772x.c | 34 ++
include/media/ov772x.h | 25 +
2 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 34c9819..a951327 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -358,6 +358,15 @@
#define VOSZ_VGA0xF0
#define VOSZ_QVGA 0x78
+/* EDGE CTRL
+ * see alse
+ *ov772x.h :: for Edge ctrl
+ */
+#define EDGE0CTRL(param) (((param) >> 24) & 0x1F)
+#define EDGE1CTRL(param) (((param) >> 16) & 0x0F)
+#define EDGE2CTRL(param) (((param) >> 8) & 0xFF)
+#define EDGE3CTRL(param) (((param) >> 0) & 0xFF)
+
/*
* ID
*/
@@ -816,6 +825,31 @@ static int ov772x_set_params(struct ov772x_priv *priv, u32
width, u32 height,
ov772x_reset(priv->client);
/*
+* set Edge Ctrl if platform has edgectrl
+*/
+ if (priv->info->edgectrl & OV772X_EDGECTRL_ENABLE) {
+ ret = ov772x_mask_set(priv->client,
+ EDGE0, 0x1F, EDGE0CTRL(priv->info->edgectrl));
+ if (ret < 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv->client,
+ EDGE1, 0x0F, EDGE1CTRL(priv->info->edgectrl));
+ if (ret < 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv->client,
+ EDGE2, 0xFF, EDGE2CTRL(priv->info->edgectrl));
+ if (ret < 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv->client,
+ EDGE3, 0xFF, EDGE3CTRL(priv->info->edgectrl));
+ if (ret < 0)
+ goto ov772x_set_fmt_error;
+ }
+
+ /*
* set size format
*/
ret = ov772x_write_array(priv->client, priv->win->regs);
diff --git a/include/media/ov772x.h b/include/media/ov772x.h
index 57db48d..5b083dc 100644
--- a/include/media/ov772x.h
+++ b/include/media/ov772x.h
@@ -17,9 +17,34 @@
#define OV772X_FLAG_VFLIP 0x0001 /* Vertical flip image */
#define OV772X_FLAG_HFLIP 0x0002 /* Horizontal flip image */
+/*
+ * for Edge ctrl
+ *
+ * strength : (for EDGE0) Edge enhancement strength control
+ * threshold : (for EDGE1) Edge enhancement threshold control
+ * low : (for EDGE2) Edge enhancement strength Low point control
+ * high : (for EDGE3) Edge enhancement strength High point control
+ *
+ * Meaning of edgectrl bit
+ *
+ * Exx0
+ *
+ * E: use edgectrl or not (OV772X_EDGECTRL_ENABLE)
+ * 0: for Edge0 ctrl
+ * 1: for Edge1 ctrl
+ * 2: for Edge2 ctrl
+ * 3: for Edge3 ctrl
+ */
+#define OV772X_EDGECTRL_ENABLE 0x8000
+#define OV772X_EDGECTRL(strength, threshold, low, high) \
+ (OV772X_EDGECTRL_ENABLE | \
+(strength & 0x1F) << 24 | (threshold & 0x0F) << 16 | \
+(low & 0xFF) << 8 | (high & 0xFF) << 0)
+
struct ov772x_camera_info {
unsigned long buswidth;
unsigned long flags;
+ unsigned long edgectrl;
struct soc_camera_link link;
};
--
1.5.6.3
--
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
[PULL] http://linuxtv.org/hg/~dheitmueller/misc_fixes
Hello Mauro, Please pull from http://linuxtv.org/hg/~dheitmueller/misc_fixes/ for the following fixes: em28xx: add remote control definition for HVR-900 (both versions) usbvision: fix oops on ARM platform when allocating transfer buffers em28xx: fix oops on ARM platform when allocating transfer buffers au0828: fix oops on ARM platform when allocating transfer buffers Thanks, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Sat, Mar 21, 2009 at 10:45 PM, Andy Walls wrote:
> There are lots of interesting ideas here. From the implementation Manu
> has presented to explain his ideas, let me separate out the problem
> statement, concept, content, and form from each other and comment on
> those separately.
>
>
>
> 1. Problem (re-)statement:
>
> My understanding of what Manu is saying is, that there is a larger
> problem of getting useful statistics out of the drivers to userspace in
> a form applications can *understand in general* and then present to the
> user in their preferred format.
>
> This restatement raises the problem up a level from the original
> discussion threads.
>
> I think Manu's restatement of the problem, as I understand it, is a
> better way to look at the problem, and hence for solutions.
>
>
>
> 2. Concept:
>
> The essential elements of Manu's concept, as I understand it, are to
> provide to userspace
>
> a) Measurement values in their "native form" from the hardware, without
> manipulation into another form.
>
> b) Meta-data about the various measurement values (including as to
> whether or not they are supported at all), so that the application can
> know exaclty how to process the measurement values that are provided in
> "native form" from the hardware.
>
>
> I'm OK with this concept. It is easy to understand from the kernel side
> of things. It provides flexibility to do more in userspace, which may
> come with some complexity to applications unfortunately.
>
> What seemed most interesting about this concept is, per the examples
> Manu discussed and Trent provided, the ability to perform userspace
> control/tracking loops using a) the values directly in an automated
> process or b) the values converted into human readable form in a manual
> process.
>
>
>
> 3. Content:
>
> In the presented implmentation, I saw the following data items
> identified as going from kernel space to userspace:
>
> a) Measurement values
> "raw" signal level
> quality (SNR, CNR, Eb/No, etc.)
> strength (dB, dBuV, etc.)
> error rate (BER, PER)
> uncorrectable blocks
>
> b) Meta-data about the measurment values
> Signedness (signed or unsigned)
> Width (8, 16, 24, or 32 bits)
> Units (SNR_dB, CNR_dB, PER, MER, relative/dimensionless, etc.)
> Exponent (base 10, scales the measurement value for the unit.)
>
>
> The types of measurment values in the above, I'm assuming, come from
> Manu's fairly complete survey or knowledge of what's currently available
> in devices. They look OK to me.
>
> For the meta-data, I'll make the following suggestions:
>
> a) It may be possible to just cast everything to a 32 bit width on the
> way out of the kernel and thus dispense with the "width" meta-data.
>
> b) It may be useful for the driver to provide as meta-data the possible
> bottom of scale and top of scale values for the measurement values.
>
>
>
> 4. Form:
>
> The form of the solution presented in the small implementation has 3 new
> ioctls, 2 new data structures, and 4 new enumerations. I think that
> this small implementation was excellent for presenting the concept and
> communicating the ideas.
>
> I'm not so sure it the best final form for such an interface. Possible
> drawbacks are:
>
> a. Meta-data information is combined, creating larger enumerations
> (case:s in a switch() statement) that applications have to deal with.
> Signedness is combined with Width; that's not so bad. Units is combined
> with Exponent, making 'enum fecap_errors' rather large. This is likely
> fixable with modification to the presented implementation.
>
> b. A new type of measurment in a new hardware device means a change in
> the message structure. In the presented implementation, I'm not sure
> there's a good way to fix this. (I'm not sure how much of a drawback
> this is in reality, my crystal ball is broken...)
>
> c. It makes 3 allocations from the space of possible ioctl values. I am
> under the impression using new ioctls is to be avoided. I don't know if
> that impression is justified. For perspective, currently about 93 of
> the 256 type 'o' ioctl numbers are in use by dvb and 73 of the 256 type
> 'V' ioctl numbers are in use by v4l.
>
>
>
> As an alternative form for the interface between the kernel and
> userspace, I can suggest
>
> a. using the FE_GET_PROPERTY ioctl
>
> b. new defines to use for getting the measurment values and metadata
> with FE_GET_PROPERTY. For example, for the quality measurment and
> meta-data:
>
> #define DTV_QUALITY_SIGNEDNESS 41
> #define DTV_QUALITY_WIDTH 42 (or DTV_QUALITY_SIGN_WIDTH with values like -32
> meaning 32 bit signed)
> #define DTV_QUALITY_UNIT 43
> #define DTV_QUALITY_EXPONENT 44
> #define DTV_QUALITY_TOP_OF_SCALE 45
> #define DTV_QUALITY_BOTTOM_OF_SCALE 46
>
> #define DTV_QUALITY 47
>
>
> c. Variaitons of the enums Manu presented for the meta-data. For
> example for quality:
>
> enum fe_quality_unit {
> FE_QUALITY_UNKOW
Bug in mxl5005s driver
In line 3992:
if (fe->ops.info.type == FE_ATSC) {
switch (params->u.vsb.modulation) {
case VSB_8:
req_mode = MXL_ATSC; break;
default:
case QAM_64:
case QAM_256:
case QAM_AUTO:
req_mode = MXL_QAM; break;
}
} else
req_mode = MXL_DVBT;
req_mode is filled with MXL_ATSC, MXL_QAM, or MXL_DVBT
and in line 4007 req_mode is used like params->u.vsb.modulation
switch (req_mode) {
case VSB_8:
case QAM_64:
case QAM_256:
case QAM_AUTO:
req_bw = MXL5005S_BANDWIDTH_6MHZ;
break;
default:
/* Assume DVB-T */
switch (params->u.ofdm.bandwidth) {
case BANDWIDTH_6_MHZ:
req_bw = MXL5005S_BANDWIDTH_6MHZ;
break;
case BANDWIDTH_7_MHZ:
req_bw = MXL5005S_BANDWIDTH_7MHZ;
break;
case BANDWIDTH_AUTO:
case BANDWIDTH_8_MHZ:
Jose Alberto Reguero
--
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] dvb_shutdown_timeout
Hi Goga, Am Sonntag, den 22.03.2009, 20:02 +0300 schrieb Goga777: > Hi > > does the option dvb_shutdown_timeout =0 work correctly on current v4l-dvb ? > Seems to me it was broken early > > Goga > on the saa7134 driver it works correctly with the exception of that one Medion Quad md8800 DVB-S frontend which is always at 18Volts until the driver is unloaded. Timeout = 0 should be the default currently and all other settings like echo 8 > /sys/module/dvb_core/parameters/dvb_shutdown_timeout come through. The hg v4l-dvb is a few weeks old on that machine, but I also can test on latest if you see it there. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new frequency table for Strasbourg, France
2009/3/14, Benjamin Zores : > Hi, > > Attached patch updates the current dvb-t/fr-Strasbourg file with > relevant transponders frequency values. I've removed the 167k offset, added channel 69 and committed the file. > Please commit, > > Ben Thanks, Christoph -- 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Mar 22 19:00:06 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11135:91098251ab91 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc8-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29-rc8-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: ERRORS linux-2.6.29-rc8-armv5-omap2: ERRORS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc8-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc8-m32r: OK linux-2.6.22.19-mips: WARNINGS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29-rc8-mips: ERRORS linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29-rc8-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-rc8-x86_64: OK fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc8): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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
dvb_shutdown_timeout =0
Hi does the option dvb_shutdown_timeout =0 work correctly on current v4l-dvb ? Seems to me it was broken early 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
Re: Problems with Hauppauge HVR 1600 and cx18 driver
On Wed, Mar 18, 2009 at 9:12 PM, Andy Walls wrote: > 2. Try modifying the enc_ts_bufsize module parameter from it's default > of 32 k, down to 4 k or up to 128 k. With a smaller size, the loss of > any one buffer from the encoder will not have such a devastating effect > on the MPEG TS, but interrupts will happen more frequently. With a > larger size, you're less likely to see the timeout errors in your logs, > and the interrupt rate will be lower. > > Make sure you use enc_ts_bufs=64 when you set the buffer size small. > Andy, I am noticing an improvement in pixelation by setting the bufsize to 64k. I will monitor over the next week and report back. I am running 3 HVR-1600s and the IRQs are coming up shared with the USB which also supports my HD PVR capture device. Monday nights are usually one of the busier nights for recording so I will know how well this holds up. Thanks for the tip! Brandon -- 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 1/1 re-submit 1] sdio: add low level i/o functions for workarounds
-Original Message- From: Pierre Ossman [mailto:drz...@drzeus.cx] Sent: Sunday, March 22, 2009 4:36 PM To: Mauro Carvalho Chehab Cc: Uri Shkolnik; Linux Media Mailing List Subject: Re: [PATCH 1/1 re-submit 1] sdio: add low level i/o functions for workarounds On Sat, 14 Mar 2009 07:42:01 -0300 Mauro Carvalho Chehab wrote: > Hi Pierre, > > Uri sent me this patchset, as part of the changes for supporting some devices > from Siano. > > The changeset looks fine, although I have no experiences with MMC. Are you > applying it on your tree, or do you prefer if I apply here? > > If you're applying on yours, this is my ack: > Acked-by: Mauro Carvalho Chehab > This should probably go in your tree with the patch for the Siano SDIO driver. The problem is that that driver isn't ready yet. I was going to do a final cleanup once the USB separations patches were done, but those never materialised. Rgds -- -- Pierre Ossman - Hi Pierre, The USB separation patches are ready, and will be committed for review shortly (SDIO stack workaround + Siano SDIO driver were the first to be re-re-re-committed, SPI will be next, and after them the "core" which includes the 'separation' code). You can view one (of many) older commit operations @ http://patchwork.kernel.org/project/linux-media/list/?submitter=Uri&stat e=* Please note that due the commit requirements I re-patch (re-generate) the code patches you email me back at mid-2008 against kernel 2.6.29 (your code remain unchanged !). Thanks, Uri -- 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 1/1 re-submit 1] sdio: add low level i/o functions for workarounds
On Sat, 14 Mar 2009 07:42:01 -0300 Mauro Carvalho Chehab wrote: > Hi Pierre, > > Uri sent me this patchset, as part of the changes for supporting some devices > from Siano. > > The changeset looks fine, although I have no experiences with MMC. Are you > applying it on your tree, or do you prefer if I apply here? > > If you're applying on yours, this is my ack: > Acked-by: Mauro Carvalho Chehab > This should probably go in your tree with the patch for the Siano SDIO driver. The problem is that that driver isn't ready yet. I was going to do a final cleanup once the USB separations patches were done, but those never materialised. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: [linux-dvb] DVBT USB DONGLE - EC168 - MXL5003S
Alessandra Santi wrote: [ 4922.573293] dvb-usb: This USB2.0 device cannot be run on a USB1.1 port. (it lacks a hardware PID filter) I think this error message is rather clear. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Andy Walls wrote:
> On Fri, 2009-03-20 at 10:55 +0400, Manu Abraham wrote:
>> Manu Abraham wrote:
>
>>> I have been going through this thread with much interest to see
>>> where it was going.
>>>
>>> In fact, what i found after reading the emails in this thread:
>>>
>>> People would like to see standardized Signal stats in whatever apps
>>> they like.
>>>
>>> * Some users prefer a dB scale
>>> * Some users prefer a percent scale
>>> * Some prefer a relative scale.
>>>
>>> Some need a signal monitor to do specific activity.
>>>
>>> All this needs one to require the existing format into one common
>>> format as required, which needs all drivers to be converted.
>>>
>>> The Pros:
>>>
>>> * Application can just read the value from the IOCTL and be happy
>>> dispalying the value.
>>>
>>> The Cons:
>>>
>>> * Converting all drivers is no joke. Many drivers are Reverse
>>> Engineered, Some are written from specs, Some are written from
>>> sample code.
>>>
>>> * Assuming that everything is alright, many do think that statistics
>>> can be just used in a 1:1 proportion depending on some sample code.
>>> But it has to be borne in mind that it is for a very specific
>>> reference platform that it is. Lot of things do affect it directly.
>>> Eventually what you consider statistics from a demod driver, from
>>> where you get statistics, depends on other frontend components.
>>>
>>> * Now assume that it is correct for the reference platform too..
>>> Just think how many users are really conversant with all those units
>>> and how to interpret it .. ? I would say hardly few ...
>>>
>>> * Doing format/protocol conversions in kernel is not something
>>> that's appreciated.
>>>
>>> * Different types of conversions would be needed. All the conersions
>>> need to be foolproof, else you shoot your foot, with some odd values
>>> as well..
>>>
>>> * This concept provides a single format with little or no flexibility.
>>>
>>>
>>> I had been thinking a bit on this in the large view. My idea was
>>> that it would be better not not to modify any driver as it is, but
>>> get that value out to userspace with that exact representation.
>>>
>>> The current existing API does the statistics correctly, but all it
>>> needs is that the user/application needs to be told what units it
>>> expects the statistics in.
>>>
>>> That said, i did a small implementation, with almost all parctical
>>> possible combinations.
>>>
>>> The Pros:
>>>
>>> * Application can choose whether it wants to display the statistics
>>> in a specific way the application would like
>>>
>>> * Application can also choose what format the driver provides too..
>>>
>>> * Format conversions are simple at userspace
>>>
>>> * The driver just mentions what format it is using and sends out the
>>> values are being read and calculated for the hardware requirements.
>>> No conversions are done in the driver.
>>>
>>>
>>> The Cons:
>>>
>>> * The application has to do the format conversion. ie the driver
>>> does not force the application to use a specific format. In other
>>> words, it is more flexibility to the application.
>>>
>>> That said, my thoughts follow thus. I guess it hardly needs any
>>> explanation. But if any queries, i am here around.
>>>
>>>
>>>
>>> /* Frontend General Statistics
>>> * General parameters
>>> * FE_*_UNKNOWN:
>>> * Parameter is unknown to the frontend and doesn't really
>>> * make any sense for an application.
>>> *
>>> * FE_*_RELATIVE:
>>> * Parameter is relative on the basis of a ceil - floor basis
>>> * Format is based on empirical test to determine
>>> * the floor and ceiling values. This format is exactly the
>>> * same format as the existing statistics implementation.
>>> *
>>> * FE_*_PAD:
>>> * Parameter is used as a Pad variable, not of any use to the
>>> * userspace world.
>>> */
>>>
>>> /* Statistics format
>>> * FE_FORMAT_S32:Signed 32 bits
>>> * FE_FORMAT_U32:Unsigned 32 bits
>>> * FE_FORMAT_U24:Unsigned 24 bits
>>> * FE_FORMAT_S24:Signed 24 bits
>>> * FE_FORMAT_S16:Signed 16 bits
>>> * FE_FORMAT_U16:Unsigned 16 bits
>>> * FE_FORMAT_S08:Signed 8 bits
>>> * FE_FORMAT_U08:Unsigned 8 bits
>>> */
>>> enum fecap_format {
>>> FE_FORMAT_UNKNOWN = 0,
>>> FE_FORMAT_S32,
>>> FE_FORMAT_S24,
>>> FE_FORMAT_S16,
>>> FE_FORMAT_S08,
>>> FE_FORMAT_U32,
>>> FE_FORMAT_U24,
>>> FE_FORMAT_U16,
>>> FE_FORMAT_U08,
>>>
>>> FE_FORMAT_PAD = 0x
>>> };
>>>
>>> /* Quality format
>>> * FE_QUALITY_SNR_dB_100:SNR in dB/100
>>> * FE_QUALITY_SNR_dB_10 :SNR in dB/10
>>> * FE_QUALITY_SNR_dB:SNR in dB
>>> * FE_QUALITY_CNR_dB_100:CNR in dB/100
>>> * FE_QUALITY_CNR_dB_10 :CNR in dB/10
>>> * FE_QUALITY_CNR_dB:CNR in dB
>>> * FE_QUALITY_EsNo :Es/No
>>> * FE_QUALITY_EbNo :Eb/No
>>> */
>>> enum fecap_qual
dual tuner dvb-c card
Hello All, I'm looking for a good dual tuner dvb-c card for a PVR system with a single PCI slot. Can anyone recommend one that works well under Linux at the moment? (Do they exist at all?) Regards, Bert Haverkamp P.S This mail is a dub from the one I sent to a few days ago. I got a "This list is depreciated" message, so I´m not sure if list is still read. My appologies in advance for the duplication otherwise. - There is always a but, but not this time. -- - There is always a but, but not this time. -- 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: qv4l2 (was [PATCH] LED control)
On Tue, 17 Mar 2009 09:45:40 +0100 (CET) "Hans Verkuil" wrote: [snip] > > Actually, there are a few programs that can handle the webcam > > parameters. In fact I know only 'v4l2-ctl': I did not succeeded to > > compile qv4l2 > > What compile errors do you get? > > If you do not have qt3 installed, then it will be interesting to see > if you can compile the qv4l2 in my ~hverkuil/v4l-dvb-qv4l2 tree which > is qt4. It still needs more cleanup and tweaking before I can merge > that in the v4l-dvb tree, though. Hello Hans, Yes, I have qt4. I got your tree and the qv4l2 generation is OK. I could change the controls of my webcam (but, indeed, the JPEG parameters). Little problem: if I directly do 'start capture', the program loops displaying the single word: 'dqbuf'. Otherwise, streaming works fine, but the CPU load is heavy: 85% (vm: 40Mb) versus 60% with gtk+ (vm: 15Mb) and 8% with vlc (vm: 137Mb). Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: TT 3650
Op zondag 08-03-2009 om 16:27 uur [tijdzone +0100], schreef Andreas Kurz: > Hi... > > Still having some problems getting this card to work for me (Suse 11.1, KDE > 4.1). > I have successfully installed the suggested non-main-repo, szap-s2 and > dvbstream. > Unter Yast/TV-card I used the Experts button to tell the system to use a > unknown tv-card with v4l2. Unfotunately dvbstream -o 8192 | vlc leaves me > with > > sc...@notebookmmc:~> dvbstream -o 8192 | vlc > VLC media player 0.9.8a Grishenko > [0001] main libvlc debug: VLC media player - version 0.9.8a Grishenko - > (c) 1996-2008 the VideoLAN team > [0001] main libvlc debug: libvlc was configured with ./configure > '--host=i686-suse-linux-gnu' '--build=i686-suse-linux-gnu' > '--target=i586-suse-linux' '--program-prefix=' '--prefix=/usr' > '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' > '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' > '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' > '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' > '--infodir=/usr/share/info' '--disable-dependency-tracking' > '--enable-gnomevfs' '--enable-ncurses' '--enable-wxwidgets' '--disable-pda' > '--disable-macosx' '--disable-qnx' '--enable-xosd' '--enable-gnutls' > '--enable-visual' '--disable-goom' '--enable-slp' '--enable-lirc' > '--disable-joystick' '--disable-corba' '--enable-dvdread' '--enable-dvdnav' > '--disable-dshow' '--enable-v4l' '--enable-v4l2' '--enable-pvr' > '--enable-vcd' '--enable-satellite' '--enable-ogg' '--enable-mkv' > '--enable-mod' '--enable-libcdio' '--enable-vcdx' '--enable-cddax' > '--enable-libcddb' '--enable-x11' '--enable-xvideo' '--enable-glx' > '--enable-fb' '--enable-mga' '--enable-freetype' '--enable-fribidi' > '--disable-svg' '--disable-directx' '--disable-wingdi' '--disable-glide' > '--enable-aa' '--enable-caca' '--enable-oss' '--disable-esd' '--enable-arts' > '--enable-waveout' '--disable-coreaudio' '--disable-hd1000a' > '--disable-hd1000v' '--enable-mad' '--enable-ffmpeg' '--enable-faad' > '--enable-a52' '--enable-dca' '--enable-flac' '--enable-libmpeg2' > '--enable-vorbis' '--enable-tremor' '--enable-speex' '--disable-tarkin' > '--enable-theora' '--enable-cmml' '--enable-utf8' '--enable-pth' > '--disable-st' '--disable-gprof' '--disable-cprof' '--disable-testsuite' > '--enable-optimizations' '--disable-altivec' '--disable-debug' > '--enable-release' '--enable-sout' '--with-ffmpeg-faac' '--disable-galaktos' > '--enable-httpd' '--enable-jack' '--enable-mozilla' '--enable-alsa' > '--enable-real' '--enable-realrtsp' '--enable-live555' > '--with-live555-tree=/usr/lib/live' '--enable-fast-install' '--enable-dvbpsi' > '--enable-dvb' '--enable-lua' '--enable-pulse' '--enable-asademux' > '--enable-libproxy' '--enable-libass' '--enable-kate' '--enable-smb' > '--enable-taglib' 'build_alias=i686-suse-linux-gnu' > 'host_alias=i686-suse-linux-gnu' 'target_alias=i586-suse-linux' > 'CFLAGS=-march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall > -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables > -fasynchronous-unwind-tables' 'CXXFLAGS=-march=i586 -mtune=i686 > -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector > -funwind-tables -fasynchronous-unwind-tables' > [0001] main libvlc debug: translation test: code is "de" > dvbstream v0.6 - (C) Dave Chapman 2001-2004 > Released under the GPL. > Latest version available from http://www.linuxstb.org/ > dvbstream will stop after -1 seconds (71582788 minutes) > FD 0: DEMUX DEVICE: : No such file or directory > [0001] main libvlc: vlc wird mit dem Standard-Interface ausgeführt. > Benutzen Sie 'cvlc', um vlc ohne Interface zu verwenden. > > > With the most important part: > > FD 0: DEMUX DEVICE: : No such file or directory > > > lsusb gives me: > Bus 004 Device 003: ID 0b48:300d TechnoTrend AG TT-connect CT-3650 CI Forgive me for asking, but does this card really work with the s2api driver? If I'm not mistaken, the S2-3650 and the CT-3650 are different beasts, one is DVB-S, the other is DVB-C/T and uses totally different chipset, see: http://www.linuxtv.org/pipermail/linux-dvb/2008-May/026288.html Kind regards, Alain -- 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
Can't tune to Astra 2D (because of Symbol Rate 220000?)
Hi all, Essentially I'm a Linux DVB newbie, and am struggling with this. Basically I want to just record BBC HD, and watch it elsewhere via UPnP server (Mediatomb). I have three tuners. A Hauppauge WinTV DVB-S USB tuner. This works fine. It can tune to the required transponder (Astra 2D, 10847, Vertical, Symbol Rate 22), but it seems to have a bandwidth limit of about 6Mbps (I suspect its because its USB 1.1) and so it can handle SD based video streams, but not HD. So I have two other cards from Ebay. Both PCI this time. A Technisat Skystar 2 and more recently (due to this one's failure) a Hauppauge WinTV DVB-S rev 1.3. I deliberately chose the Hauppauge as it was revision 1.3 (and apparently well supported), and a different chipset to the Skystar 2. It's obvious they're different as I had to download and install firmware for the 1.3, which I didn't have to for the Skystar 2. They both work, recognised by the kernel and appear in /dev/dvb, and can tune to stuff (typically with a symbol rate of 275000) but both completely fail to Freesat channels (basically Astra 2D) because (I think) the symbol rate is 22. Very weird! I'm using Fedora 9 essentially out of the box, nothing peculiar done to change it. So, is this a known problem? Has anybody else seen this? Is there a DVB-S card that will tune to this fairly standard scenario? I've seen a Compro VideoMate S300 do it in Windows, but that card isn't supported in Linux. Or, is it a LinuxTV/Kernel version problem (I'm sorry, I'm not sure which version of the Kernel I'm using definitely 2.6.x, I'm aware from the box at the moment so can't tell just now.) Help! Cheers, Phil -- 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
