Re: [PATCH] v4l: mt9v032: Fix Bayer pattern
Hi Guennadi, On Saturday 16 July 2011 01:11:28 Guennadi Liakhovetski wrote: On Fri, 15 Jul 2011, Laurent Pinchart wrote: Compute crop rectangle boundaries to ensure a GRBG Bayer pattern. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/mt9v032.c | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) If there's no comment I'll send a pull request for this patch in a couple of days. Hm, I might have a comment: why?... Isn't it natural to accept the fact, that different sensors put a different Bayer pixel at their sensor matrix origin? Isn't that why we have all possible Bayer formats? Maybe you just have to choose a different output format? That's the other solution. The driver currently claims the device outputs SGRBG, but configures it to output SGBGR. This is clearly a bug. Is it better to modify the format than the crop rectangle location ? The OMAP3 ISP supports all Bayer formats, but the driver configures itself for SGRBG by default. Using another pattern currently requires userspace software to change several hardware-dependent parameters (including matrices and tables). This should eventually be fixed in the OMAP3 ISP driver, but for the time being application developers will have an easier life if the sensor outputs SGRBG instead of SGBRG. -- Regards, Laurent Pinchart -- 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
[PATCH] improve recection with limits frecuenies and tda827x
On Miércoles, 13 de Julio de 2011 14:41:30 Mauro Carvalho Chehab escribió:
Em 06-07-2011 19:57, Jose Alberto Reguero escreveu:
This patch add suport for the dvb-t part of CT-3650.
Jose Alberto
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
patches/lmml_951522_add_support_for_the_dvb_t_part_of_ct_3650_v2.patch
Content-Type: text/plain; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: add support for the dvb-t part of CT-3650 v2
Date: Wed, 06 Jul 2011 22:57:04 -
From: Jose Alberto Reguero jaregu...@telefonica.net
X-Patchwork-Id: 951522
Message-Id: 201107070057.06317.jaregu...@telefonica.net
To: linux-media@vger.kernel.org
This patch add suport for the dvb-t part of CT-3650.
Jose Alberto
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
diff -ur linux/drivers/media/common/tuners/tda827x.c
linux.new/drivers/media/common/tuners/tda827x.c ---
linux/drivers/media/common/tuners/tda827x.c 2010-07-03
23:22:08.0 +0200 +++
linux.new/drivers/media/common/tuners/tda827x.c 2011-07-04
12:00:29.931561053 +0200 @@ -135,14 +135,29 @@
static int tuner_transfer(struct dvb_frontend *fe,
struct i2c_msg *msg,
- const int size)
+ int size)
{
int rc;
struct tda827x_priv *priv = fe-tuner_priv;
+ struct i2c_msg msgr[2];
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
- rc = i2c_transfer(priv-i2c_adap, msg, size);
+ if (priv-cfg-i2cr (msg-flags == I2C_M_RD)) {
+ msgr[0].addr = msg-addr;
+ msgr[0].flags = 0;
+ msgr[0].len = msg-len - 1;
+ msgr[0].buf = msg-buf;
+ msgr[1].addr = msg-addr;
+ msgr[1].flags = I2C_M_RD;
+ msgr[1].len = 1;
+ msgr[1].buf = msg-buf;
+ size = 2;
+ rc = i2c_transfer(priv-i2c_adap, msgr, size);
+ msg-buf[msg-len - 1] = msgr[1].buf[0];
+ } else {
+ rc = i2c_transfer(priv-i2c_adap, msg, size);
+ }
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
No. You should be applying such fix at the I2C adapter instead. This is the
code at the ttusb2 driver:
static int ttusb2_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg
msg[],int num) {
struct dvb_usb_device *d = i2c_get_adapdata(adap);
static u8 obuf[60], ibuf[60];
int i,read;
if (mutex_lock_interruptible(d-i2c_mutex) 0)
return -EAGAIN;
if (num 2)
warn(more than 2 i2c messages at a time is not handled yet.
TODO.);
for (i = 0; i num; i++) {
read = i+1 num (msg[i+1].flags I2C_M_RD);
obuf[0] = (msg[i].addr 1) | read;
obuf[1] = msg[i].len;
/* read request */
if (read)
obuf[2] = msg[i+1].len;
else
obuf[2] = 0;
memcpy(obuf[3],msg[i].buf,msg[i].len);
if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf,
obuf[2] +
3)
0) { err(i2c transfer failed.);
break;
}
if (read) {
memcpy(msg[i+1].buf,ibuf[3],msg[i+1].len);
i++;
}
}
mutex_unlock(d-i2c_mutex);
return i;
}
Clearly, this routine has issues, as it assumes that all transfers with
reads will be broken into just two msgs, where the first one is a write,
and a second one is a read, and that no transfers will be bigger than 2
messages.
It shouldn't be hard to adapt it to handle transfers on either way, and to
remove the limit of 2 transfers.
@@ -540,7 +555,7 @@
if_freq = 500;
break;
}
- tuner_freq = params-frequency + if_freq;
+ tuner_freq = params-frequency;
if (fe-ops.info.type == FE_QAM) {
dprintk(%s select tda827xa_dvbc\n, __func__);
@@ -554,6 +569,8 @@
i++;
}
+ tuner_freq += if_freq;
+
N = ((tuner_freq + 31250) / 62500) frequency_map[i].spd;
buf[0] = 0;// subaddress
buf[1] = N 8;
This seems to be a bug fix, but you're touching only at the DVB-C. If the
table lookup should not consider if_freq, the same fix is needed on the
other similar logics at the driver.
Also, please send such patch in separate.
Only tested with tda827xa and DVB-T and two limit frecuencies.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -ur linux/drivers/media/common/tuners/tda827x.h
linux.new/drivers/media/common/tuners/tda827x.h ---
linux/drivers/media/common/tuners/tda827x.h 2010-07-03
23:22:08.0 +0200 +++
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not integrated to same silicon. If you add such FE delsys switch mechanism it needs some more glue to bind two physical FEs to one virtual FE. I see much easier to keep all FEs as own - just register those under the same adapter if FEs are shared. In this case, the driver should just create two frontends, as currently. There's a difference when there are two physical FE's and just one FE: with 2 FE's, the userspace application can just keep both opened at the same time. Some applications (like vdr) assumes that all multi-fe are like that. When there's just a single FE, but the driver needs to fork it in two due to the API troubles, the driver needs to prevent the usage of both fe's, either at open or at the ioctl level. So, applications like vdr will only use the first frontend. 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
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not integrated to same silicon. If you add such FE delsys switch mechanism it needs some more glue to bind two physical FEs to one virtual FE. I see much easier to keep all FEs as own - just register those under the same adapter if FEs are shared. In this case, the driver should just create two frontends, as currently. There's a difference when there are two physical FE's and just one FE: with 2 FE's, the userspace application can just keep both opened at the same time. Some applications (like vdr) assumes that all multi-fe are like that. Does this mean demod is not sleeping (.init() called)? When there's just a single FE, but the driver needs to fork it in two due to the API troubles, the driver needs to prevent the usage of both fe's, either at open or at the ioctl level. So, applications like vdr will only use the first frontend. Lets take example. There is shared MFE having DVB-S, DVB-T and DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S have own. Currently it will shown as: * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T) ** frontend2 (DVB-C) Your new ideal solution will be: * adapter0 ** frontend0 (DVB-S/T/C) What really happens (mixed old and new): * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T/C) It does not look very good to offer this kind of mixed solution, since it is possible to offer only one solution for userspace, new or old, but not mixing. 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: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Em 16-07-2011 11:16, Antti Palosaari escreveu: On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not integrated to same silicon. If you add such FE delsys switch mechanism it needs some more glue to bind two physical FEs to one virtual FE. I see much easier to keep all FEs as own - just register those under the same adapter if FEs are shared. In this case, the driver should just create two frontends, as currently. There's a difference when there are two physical FE's and just one FE: with 2 FE's, the userspace application can just keep both opened at the same time. Some applications (like vdr) assumes that all multi-fe are like that. Does this mean demod is not sleeping (.init() called)? When there's just a single FE, but the driver needs to fork it in two due to the API troubles, the driver needs to prevent the usage of both fe's, either at open or at the ioctl level. So, applications like vdr will only use the first frontend. Lets take example. There is shared MFE having DVB-S, DVB-T and DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S have own. Currently it will shown as: Let me name the approaches: Approach 1) * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T) ** frontend2 (DVB-C) Approach 2) Your new ideal solution will be: * adapter0 ** frontend0 (DVB-S/T/C) Approach 3) What really happens (mixed old and new): * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T/C) What I've said before is that approach 3 is the ideal solution. It does not look very good to offer this kind of mixed solution, since it is possible to offer only one solution for userspace, new or old, but not mixing. Good point. There's an additional aspect to handle: if a driver that uses approach 1, a conversion to either approach 2 or 3 would break existing applications that can't handle with the new approach. There's a 4th posibility: always offering fe0 with MFE capabilities, and creating additional fe's for old applications that can't cope with the new mode. For example, on a device that supports DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T, it will be shown as: Approach 4) fe0 is a frontend superset *adapter0 *frontend0 (DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T) - aka: FE superset *frontend1 (DVB-S/DVB-S2) *frontend2 (DVB-T/DVB-T2) *frontend3 (DVB-C) *frontend4 (ISDB-T) fe0 will need some special logic to allow redirecting a FE call to the right fe, if there are more than one physical frontend bound into the FE API. I'm starting to think that (4) is the better
Re: Updates to French scan files
2011/7/2 mossroy moss...@free.fr: The following patch deletes the 19 remaining fr-* files, as most of them are outdated. Committed, thanks. Christoph I tested auto-Default and it worked for me (I tested on tvheadend. See https://www.lonelycoder.com/redmine/issues/570 ). Could the other French users test auto-Default (and auto-With167kHzOffsets if necessary) to confirm we don't need more frequencies? snip -- 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] update the dvb-t channels for de-Berlin
2011/7/12 Alexander Futász ald...@cs.tu-berlin.de: Hi, attched is a patch which reflects the recent changes in the DVB-T channel offering for Berlin, Germany. See http://www.mabb.de/digitale-welt/dvb-t/programme.html Cheers Updated, 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
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
On 16.07.2011 16:54, Mauro Carvalho Chehab wrote: Em 16-07-2011 11:16, Antti Palosaari escreveu: On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not integrated to same silicon. If you add such FE delsys switch mechanism it needs some more glue to bind two physical FEs to one virtual FE. I see much easier to keep all FEs as own - just register those under the same adapter if FEs are shared. In this case, the driver should just create two frontends, as currently. There's a difference when there are two physical FE's and just one FE: with 2 FE's, the userspace application can just keep both opened at the same time. Some applications (like vdr) assumes that all multi-fe are like that. Does this mean demod is not sleeping (.init() called)? When there's just a single FE, but the driver needs to fork it in two due to the API troubles, the driver needs to prevent the usage of both fe's, either at open or at the ioctl level. So, applications like vdr will only use the first frontend. Lets take example. There is shared MFE having DVB-S, DVB-T and DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S have own. Currently it will shown as: Let me name the approaches: Approach 1) * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T) ** frontend2 (DVB-C) Approach 2) Your new ideal solution will be: * adapter0 ** frontend0 (DVB-S/T/C) Approach 3) What really happens (mixed old and new): * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T/C) What I've said before is that approach 3 is the ideal solution. It does not look very good to offer this kind of mixed solution, since it is possible to offer only one solution for userspace, new or old, but not mixing. Good point. There's an additional aspect to handle: if a driver that uses approach 1, a conversion to either approach 2 or 3 would break existing applications that can't handle with the new approach. There's a 4th posibility: always offering fe0 with MFE capabilities, and creating additional fe's for old applications that can't cope with the new mode. For example, on a device that supports DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T, it will be shown as: Approach 4) fe0 is a frontend superset *adapter0 *frontend0 (DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T) - aka: FE superset *frontend1 (DVB-S/DVB-S2) *frontend2 (DVB-T/DVB-T2) *frontend3 (DVB-C) *frontend4 (ISDB-T) fe0 will need some special logic to allow redirecting a FE call to the right fe, if there are more than one
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
On Saturday 16 July 2011 16:54:50 Mauro Carvalho Chehab wrote: Em 16-07-2011 11:16, Antti Palosaari escreveu: On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not integrated to same silicon. If you add such FE delsys switch mechanism it needs some more glue to bind two physical FEs to one virtual FE. I see much easier to keep all FEs as own - just register those under the same adapter if FEs are shared. In this case, the driver should just create two frontends, as currently. There's a difference when there are two physical FE's and just one FE: with 2 FE's, the userspace application can just keep both opened at the same time. Some applications (like vdr) assumes that all multi-fe are like that. Does this mean demod is not sleeping (.init() called)? When there's just a single FE, but the driver needs to fork it in two due to the API troubles, the driver needs to prevent the usage of both fe's, either at open or at the ioctl level. So, applications like vdr will only use the first frontend. Lets take example. There is shared MFE having DVB-S, DVB-T and DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S have own. Currently it will shown as: Let me name the approaches: Approach 1) * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T) ** frontend2 (DVB-C) Approach 2) Your new ideal solution will be: * adapter0 ** frontend0 (DVB-S/T/C) Approach 3) What really happens (mixed old and new): Why does this happen? * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T/C) What I've said before is that approach 3 is the ideal solution. No, sorry. It does not look very good to offer this kind of mixed solution, since it is possible to offer only one solution for userspace, new or old, but not mixing. Good point. There's an additional aspect to handle: if a driver that uses approach 1, a conversion to either approach 2 or 3 would break existing applications that can't handle with the new approach. There's a 4th posibility: always offering fe0 with MFE capabilities, and creating additional fe's for old applications that can't cope with the new mode. For example, on a device that supports DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T, it will be shown as: Approach 4) fe0 is a frontend superset *adapter0 *frontend0 (DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T) - aka: FE superset *frontend1 (DVB-S/DVB-S2) *frontend2 (DVB-T/DVB-T2) *frontend3
[GIT PULL for 3.0] master
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus For a couple of regression fixes for 3.0. Thanks! Mauro The following changes since commit ddc6ff31cc22720c46c1547a5310ea260a968ae9: [media] msp3400: fill in v4l2_tuner based on vt-type field (2011-07-07 17:28:30 -0300) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Devin Heitmueller (1): [media] dvb_frontend: fix race condition in stopping/starting frontend Jarod Wilson (2): [media] Revert V4L/DVB: cx23885: Enable Message Signaled Interrupts(MSI) [media] nuvoton-cir: make idle timeout more sane Mauro Carvalho Chehab (1): [media] tuner-core: fix a 2.6.39 regression with mt20xx Rafi Rubin (2): [media] mceusb: Timeout unit corrections [media] mceusb: increase default timeout to 100ms Ralf Baechle (1): [media] MEDIA: Fix non-ISA_DMA_API link failure of sound code Randy Dunlap (1): [media] media: fix radio-sf16fmr2 build when SND is not enabled drivers/media/dvb/dvb-core/dvb_frontend.c |8 drivers/media/radio/Kconfig|4 ++-- drivers/media/rc/mceusb.c |9 + drivers/media/rc/nuvoton-cir.c |2 +- drivers/media/video/cx23885/cx23885-core.c |9 ++--- drivers/media/video/tuner-core.c | 16 6 files changed, 30 insertions(+), 18 deletions(-) -- 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 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
On 07/16/2011 06:40 PM, Andreas Oberritter wrote: On 16.07.2011 16:54, Mauro Carvalho Chehab wrote: Em 16-07-2011 11:16, Antti Palosaari escreveu: On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not integrated to same silicon. If you add such FE delsys switch mechanism it needs some more glue to bind two physical FEs to one virtual FE. I see much easier to keep all FEs as own - just register those under the same adapter if FEs are shared. In this case, the driver should just create two frontends, as currently. There's a difference when there are two physical FE's and just one FE: with 2 FE's, the userspace application can just keep both opened at the same time. Some applications (like vdr) assumes that all multi-fe are like that. Does this mean demod is not sleeping (.init() called)? When there's just a single FE, but the driver needs to fork it in two due to the API troubles, the driver needs to prevent the usage of both fe's, either at open or at the ioctl level. So, applications like vdr will only use the first frontend. Lets take example. There is shared MFE having DVB-S, DVB-T and DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S have own. Currently it will shown as: Let me name the approaches: Approach 1) * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T) ** frontend2 (DVB-C) Approach 2) Your new ideal solution will be: * adapter0 ** frontend0 (DVB-S/T/C) Approach 3) What really happens (mixed old and new): * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T/C) What I've said before is that approach 3 is the ideal solution. It does not look very good to offer this kind of mixed solution, since it is possible to offer only one solution for userspace, new or old, but not mixing. Good point. There's an additional aspect to handle: if a driver that uses approach 1, a conversion to either approach 2 or 3 would break existing applications that can't handle with the new approach. There's a 4th posibility: always offering fe0 with MFE capabilities, and creating additional fe's for old applications that can't cope with the new mode. For example, on a device that supports DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T, it will be shown as: Approach 4) fe0 is a frontend superset *adapter0 *frontend0 (DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T) - aka: FE superset *frontend1 (DVB-S/DVB-S2) *frontend2 (DVB-T/DVB-T2) *frontend3 (DVB-C) *frontend4 (ISDB-T) fe0 will need some special logic to allow redirecting a FE call to the right fe, if there are more than one physical frontend bound into the FE API.
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
On 16.07.2011 17:44, Antti Palosaari wrote: On 07/16/2011 06:40 PM, Andreas Oberritter wrote: On 16.07.2011 16:54, Mauro Carvalho Chehab wrote: Em 16-07-2011 11:16, Antti Palosaari escreveu: On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not integrated to same silicon. If you add such FE delsys switch mechanism it needs some more glue to bind two physical FEs to one virtual FE. I see much easier to keep all FEs as own - just register those under the same adapter if FEs are shared. In this case, the driver should just create two frontends, as currently. There's a difference when there are two physical FE's and just one FE: with 2 FE's, the userspace application can just keep both opened at the same time. Some applications (like vdr) assumes that all multi-fe are like that. Does this mean demod is not sleeping (.init() called)? When there's just a single FE, but the driver needs to fork it in two due to the API troubles, the driver needs to prevent the usage of both fe's, either at open or at the ioctl level. So, applications like vdr will only use the first frontend. Lets take example. There is shared MFE having DVB-S, DVB-T and DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S have own. One remark: In my previous mail I assumed that in your example DVB-S and either DVB-C or DVB-T can be tuned simultaneously, i.e. there are two antenna connectors and two tuners in addition to the two demod chips. If this assumtion was wrong, then of course approach 2 is the sane one, not approach 3. Currently it will shown as: Let me name the approaches: Approach 1) * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T) ** frontend2 (DVB-C) Approach 2) Your new ideal solution will be: * adapter0 ** frontend0 (DVB-S/T/C) Approach 3) What really happens (mixed old and new): * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T/C) What I've said before is that approach 3 is the ideal solution. It does not look very good to offer this kind of mixed solution, since it is possible to offer only one solution for userspace, new or old, but not mixing. Good point. There's an additional aspect to handle: if a driver that uses approach 1, a conversion to either approach 2 or 3 would break existing applications that can't handle with the new approach. There's a 4th posibility: always offering fe0 with MFE capabilities, and creating additional fe's for old applications that can't cope with the new mode. For example, on a device that supports
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
On 07/16/2011 06:53 PM, Andreas Oberritter wrote: On 16.07.2011 17:44, Antti Palosaari wrote: On 07/16/2011 06:40 PM, Andreas Oberritter wrote: On 16.07.2011 16:54, Mauro Carvalho Chehab wrote: Em 16-07-2011 11:16, Antti Palosaari escreveu: On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not integrated to same silicon. If you add such FE delsys switch mechanism it needs some more glue to bind two physical FEs to one virtual FE. I see much easier to keep all FEs as own - just register those under the same adapter if FEs are shared. In this case, the driver should just create two frontends, as currently. There's a difference when there are two physical FE's and just one FE: with 2 FE's, the userspace application can just keep both opened at the same time. Some applications (like vdr) assumes that all multi-fe are like that. Does this mean demod is not sleeping (.init() called)? When there's just a single FE, but the driver needs to fork it in two due to the API troubles, the driver needs to prevent the usage of both fe's, either at open or at the ioctl level. So, applications like vdr will only use the first frontend. Lets take example. There is shared MFE having DVB-S, DVB-T and DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S have own. One remark: In my previous mail I assumed that in your example DVB-S and either DVB-C or DVB-T can be tuned simultaneously, i.e. there are two antenna connectors and two tuners in addition to the two demod chips. If this assumtion was wrong, then of course approach 2 is the sane one, not approach 3. My assumption was that frontends are using shared HW resources for reason or the other and thus only one FE can be used at the time. When there is no shared resources it should be implemented as multiple adapters. Currently it will shown as: Let me name the approaches: Approach 1) * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T) ** frontend2 (DVB-C) Approach 2) Your new ideal solution will be: * adapter0 ** frontend0 (DVB-S/T/C) Approach 3) What really happens (mixed old and new): * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T/C) What I've said before is that approach 3 is the ideal solution. It does not look very good to offer this kind of mixed solution, since it is possible to offer only one solution for userspace, new or old, but not mixing. Good point. There's an additional aspect to handle: if a driver that uses approach 1, a conversion to either approach 2 or 3 would break existing applications that can't handle with the new approach.
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Le samedi 16 juillet 2011 18:53:16 Andreas Oberritter, vous avez écrit : You are wrong, actually you can. At least here in Finland some cable networks offers DVB-T too. I know that there are cable operators which use DVB-T, but they don't use DVB-C simultaneously. This wouldn't make sense, unless they didn't want their customers to receive their signals. They do offer both simultaneously. DNA (formerly Welho) in Helsinki provides both DVB-T and DVB-C on the same cable, obviously on different frequencies. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: 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:Sat Jul 16 19:00:36 CEST 2011 git hash:bec969c908bb22931fd5ab8ecdf99de8702a6a31 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
usbvision: disable scaling for Nogatech MicroCam
Scaling causes bad artifacts (horizontal lines) with compression at least
with Nogatech MicroCam so disable it (for this HW).
This also fixes messed up image with some programs (Cheese with 160x120,
Adobe Flash). HW seems to support only image widths that are multiple of 64
but the driver does not account that in vidioc_try_fmt_vid_cap(). Cheese
calls try_fmt with 160x120, succeeds and then assumes that it really gets
data in that resolution - but it gets 128x120 instead. Don't know if this
affects other usbvision devices, it would be great if someone could test it.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
diff -urp linux-2.6.39-rc2-/drivers/media/video/usbvision//usbvision-video.c
linux-2.6.39-rc2/drivers/media/video/usbvision/usbvision-video.c
--- linux-2.6.39-rc2-/drivers/media/video/usbvision//usbvision-video.c
2011-07-16 16:42:35.0 +0200
+++ linux-2.6.39-rc2/drivers/media/video/usbvision/usbvision-video.c
2011-07-16 16:36:43.0 +0200
@@ -924,6 +924,11 @@ static int vidioc_try_fmt_vid_cap(struct
RESTRICT_TO_RANGE(vf-fmt.pix.width, MIN_FRAME_WIDTH, MAX_FRAME_WIDTH);
RESTRICT_TO_RANGE(vf-fmt.pix.height, MIN_FRAME_HEIGHT,
MAX_FRAME_HEIGHT);
+ if (usbvision_device_data[usbvision-dev_model].codec == CODEC_WEBCAM) {
+ vf-fmt.pix.width = MAX_FRAME_WIDTH;
+ vf-fmt.pix.height = MAX_FRAME_HEIGHT;
+ }
+
vf-fmt.pix.bytesperline = vf-fmt.pix.width*
usbvision-palette.bytes_per_pixel;
vf-fmt.pix.sizeimage = vf-fmt.pix.bytesperline*vf-fmt.pix.height;
@@ -952,6 +957,11 @@ static int vidioc_s_fmt_vid_cap(struct f
usbvision-cur_frame = NULL;
+ if (usbvision_device_data[usbvision-dev_model].codec == CODEC_WEBCAM) {
+ vf-fmt.pix.width = MAX_FRAME_WIDTH;
+ vf-fmt.pix.height = MAX_FRAME_HEIGHT;
+ }
+
/* by now we are committed to the new data... */
usbvision_set_output(usbvision, vf-fmt.pix.width, vf-fmt.pix.height);
--
Ondrej Zary
--
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] v4l: mt9v032: Fix Bayer pattern
On Sat, 16 Jul 2011, Laurent Pinchart wrote: Hi Guennadi, On Saturday 16 July 2011 01:11:28 Guennadi Liakhovetski wrote: On Fri, 15 Jul 2011, Laurent Pinchart wrote: Compute crop rectangle boundaries to ensure a GRBG Bayer pattern. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/mt9v032.c | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) If there's no comment I'll send a pull request for this patch in a couple of days. Hm, I might have a comment: why?... Isn't it natural to accept the fact, that different sensors put a different Bayer pixel at their sensor matrix origin? Isn't that why we have all possible Bayer formats? Maybe you just have to choose a different output format? That's the other solution. The driver currently claims the device outputs SGRBG, but configures it to output SGBGR. This is clearly a bug. Is it better to modify the format than the crop rectangle location ? Actually, it is interesting. I just looked (again) in the mt9v032 and some other Aptina Bayer sensor datasheets, and they actually have _odd_ numbers of rows and columns. So, mt9v032 actually has 753x481 active pixels. And that extra pixel is explicitly provided to adjust the origin colour. Ok, they write, it is for uniformity with the mirrored image, but who believes them?;-) So, maybe you should adjust your max values to the above ones, then taking one pixel out of your image will not reduce your useful image size. Thanks Guennadi The OMAP3 ISP supports all Bayer formats, but the driver configures itself for SGRBG by default. Using another pattern currently requires userspace software to change several hardware-dependent parameters (including matrices and tables). This should eventually be fixed in the OMAP3 ISP driver, but for the time being application developers will have an easier life if the sensor outputs SGRBG instead of SGBRG. -- Regards, Laurent Pinchart --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: Imon module Oops and kernel hang
On Thu, 2011-07-14 at 12:41 +1000, Chris W wrote: On 14/07/11 08:11, Jarod Wilson wrote: On Jul 13, 2011, at 1:42 AM, Chris W wrote: Just noticed your report is for 2.6.39.x and 2.6.38.x only, but I'm not aware of any relevant imon changes between 2.6.39 and 3.0. I just tried 3.0.0-rc7 with the same result (used defaults for new config items. I manually loaded both keymaps before imon. I looks like the mystery T889 has become a T886... compiler generated temporary name perhaps? Looks like I'll probably have to give that a spin, since I'm not seeing the problem here (I can also switch to an 0xffdc device, which is actually handled a bit differently by the driver). I understand that the 0xffdc device covers a multitude of physical variants. Is there any information from the device itself that drives the selected keymap? If so, how do I extract it? Regards, Chris This is an obviously repeatable NULL pointer dereference in rc_g_keycode_from_table(). The faulting line of code in both cases disasembles to: 1e: 8b 80 dc 00 00 00 mov0xdc(%eax),%eax %eax obviously holds the value 0 (NULL). But I'm having a hard time telling to where exactly that line of assembly corresponds in rc_g_keycode_from_table(). And I can't tell from the source which data structure has something at offset 0xdc that gets derefernced early: struct rc_dev or struct rc_map. Could you provide the output of $ locate rc-core.ko $ objdump -d -l /blah/blah/drivers/media/rc/rc-core.ko for the rc_g_keycode_from_table() function? Regards, Andy Jul 14 11:19:38 kepler BUG: unable to handle kernel Jul 14 11:19:38 kepler NULL pointer dereference Jul 14 11:19:38 kepler at 00dc Jul 14 11:19:38 kepler IP: Jul 14 11:19:38 kepler [f8f1949e] rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 14 11:19:38 kepler *pde = Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Oops: [#1] Jul 14 11:19:38 kepler PREEMPT Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Modules linked in: Jul 14 11:19:38 kepler imon(+) Jul 14 11:19:38 kepler rc_imon_pad Jul 14 11:19:38 kepler rc_imon_mce Jul 14 11:19:38 kepler netconsole Jul 14 11:19:38 kepler asb100 Jul 14 11:19:38 kepler hwmon_vid Jul 14 11:19:38 kepler cx22702 Jul 14 11:19:38 kepler dvb_pll Jul 14 11:19:38 kepler mt352 Jul 14 11:19:38 kepler cx88_dvb Jul 14 11:19:38 kepler cx88_vp3054_i2c Jul 14 11:19:38 kepler videobuf_dvb Jul 14 11:19:38 kepler snd_via82xx Jul 14 11:19:38 kepler snd_ac97_codec Jul 14 11:19:38 kepler cx8800 Jul 14 11:19:38 kepler cx8802 Jul 14 11:19:38 kepler cx88xx Jul 14 11:19:38 kepler ac97_bus Jul 14 11:19:38 kepler snd_mpu401_uart Jul 14 11:19:38 kepler snd_rawmidi Jul 14 11:19:38 kepler b44 Jul 14 11:19:38 kepler ssb Jul 14 11:19:38 kepler rc_core Jul 14 11:19:38 kepler i2c_algo_bit Jul 14 11:19:38 kepler mii Jul 14 11:19:38 kepler tveeprom Jul 14 11:19:38 kepler btcx_risc Jul 14 11:19:38 kepler i2c_viapro Jul 14 11:19:38 kepler videobuf_dma_sg Jul 14 11:19:38 kepler videobuf_core Jul 14 11:19:38 kepler [last unloaded: ir_nec_decoder] Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Pid: 2885, comm: modprobe Not tainted 3.0.0-rc7 #1 Jul 14 11:19:38 kepler System Manufacturer System Name Jul 14 11:19:38 kepler /A7V8X Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler EIP: 0060:[f8f1949e] EFLAGS: 00010002 CPU: 0 Jul 14 11:19:38 kepler EIP is at rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 14 11:19:38 kepler EAX: EBX: f5610800 ECX: 0008 EDX: Jul 14 11:19:38 kepler ESI: EDI: EBP: f7009e48 ESP: f7009e18 Jul 14 11:19:38 kepler DS: 007b ES: 007b FS: GS: 0033 SS: 0068 Jul 14 11:19:38 kepler Process modprobe (pid: 2885, ti=f7008000 task=f708ada0 task.ti=f5706000) Jul 14 11:19:38 kepler Stack: Jul 14 11:19:38 kepler f71cc8c0 Jul 14 11:19:38 kepler 0082 Jul 14 11:19:38 kepler 0002 Jul 14 11:19:38 kepler f7009e2c Jul 14 11:19:38 kepler c101eabb Jul 14 11:19:38 kepler f71cc8c0 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler 0086 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler 0086 Jul 14 11:19:38 kepler f5610800 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler f7009e58 Jul 14 11:19:38 kepler f87be59c Jul 14 11:19:38 kepler f5610800 Jul 14 11:19:38 kepler f5610841 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler f7009edc Jul 14 11:19:38 kepler f87be6dc Jul 14 11:19:38 kepler f68c00a4 Jul 14 11:19:38 kepler f7009e6c Jul 14 11:19:38 kepler f68c5760 Jul 14 11:19:38 kepler f7009e74 Jul 14 11:19:38 kepler f68c00a4 Jul 14 11:19:38 kepler f7009e98 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Call Trace: Jul 14 11:19:38 kepler [c101eabb] ? T.886+0x1b/0x30 Jul 14 11:19:38 kepler [f87be59c] imon_remote_key_lookup+0x1c/0x70 [imon] Jul 14 11:19:38 kepler [f87be6dc] imon_incoming_packet+0x5c/0xe20 [imon] Jul 14 11:19:38 kepler [c1259cc8] ?
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Em 16-07-2011 12:53, Andreas Oberritter escreveu: On 16.07.2011 17:44, Antti Palosaari wrote: On 07/16/2011 06:40 PM, Andreas Oberritter wrote: On 16.07.2011 16:54, Mauro Carvalho Chehab wrote: Em 16-07-2011 11:16, Antti Palosaari escreveu: On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not integrated to same silicon. If you add such FE delsys switch mechanism it needs some more glue to bind two physical FEs to one virtual FE. I see much easier to keep all FEs as own - just register those under the same adapter if FEs are shared. In this case, the driver should just create two frontends, as currently. There's a difference when there are two physical FE's and just one FE: with 2 FE's, the userspace application can just keep both opened at the same time. Some applications (like vdr) assumes that all multi-fe are like that. Does this mean demod is not sleeping (.init() called)? When there's just a single FE, but the driver needs to fork it in two due to the API troubles, the driver needs to prevent the usage of both fe's, either at open or at the ioctl level. So, applications like vdr will only use the first frontend. Lets take example. There is shared MFE having DVB-S, DVB-T and DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S have own. One remark: In my previous mail I assumed that in your example DVB-S and either DVB-C or DVB-T can be tuned simultaneously, i.e. there are two antenna connectors and two tuners in addition to the two demod chips. If this assumtion was wrong, then of course approach 2 is the sane one, not approach 3. Currently it will shown as: Let me name the approaches: Approach 1) * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T) ** frontend2 (DVB-C) Approach 2) Your new ideal solution will be: * adapter0 ** frontend0 (DVB-S/T/C) Approach 3) What really happens (mixed old and new): * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T/C) What I've said before is that approach 3 is the ideal solution. It does not look very good to offer this kind of mixed solution, since it is possible to offer only one solution for userspace, new or old, but not mixing. Good point. There's an additional aspect to handle: if a driver that uses approach 1, a conversion to either approach 2 or 3 would break existing applications that can't handle with the new approach. There's a 4th posibility: always offering fe0 with MFE capabilities, and creating additional fe's for old applications that can't cope
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Em 16-07-2011 12:44, Antti Palosaari escreveu: On 07/16/2011 06:40 PM, Andreas Oberritter wrote: On 16.07.2011 16:54, Mauro Carvalho Chehab wrote: Em 16-07-2011 11:16, Antti Palosaari escreveu: Approach 4) fe0 is a frontend superset *adapter0 *frontend0 (DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T) - aka: FE superset *frontend1 (DVB-S/DVB-S2) *frontend2 (DVB-T/DVB-T2) *frontend3 (DVB-C) *frontend4 (ISDB-T) fe0 will need some special logic to allow redirecting a FE call to the right fe, if there are more than one physical frontend bound into the FE API. I'm starting to think that (4) is the better approach, as it won't break legacy applications, and it will provide an easier way for new applications to control the frontend with just one frontend. Approach 4 would break existing applications, because suddenly they'd have to cope with an additional device. It would be impossible for an existing application to tell whether frontend0 (from your example) was a real device or not. (not sure who commented this... somehow, I didn't receive the original email - well, I'll just reply on Antti's answer) Yes, an existing application will not know how to handle such fe, but, as the other fe's are still provided, they can swill switch the delivery system by replacing the frontend they're using. There are some alternatives for this approach, like: Approach 5) fe0 is a frontend superset, initialized to handle the first registered delivery system *adapter0 *frontend0 (DVB-S/DVB-S2), but allows changing to DVB-T/DVB-T2/DVB-C/ISDB-T *frontend1 (DVB-T/DVB-T2) *frontend2 (DVB-C) *frontend3 (ISDB-T) (so, it is something between approach 1 and 4) Being frankly, I think that this would be messy. In any case, I think that, if we decide for something like approach 4 or 5, we should deprecate the support for the extra frontends, after kernel + 2 versions, so, falling back into approach 2 (e. g. just one frontend for all delivery systems). I also think that we should get a decision about that for 3.1, and port DRX-K to the agreed approach before the release of 3.1, as it will be one less driver that we'll need to concern about migrating. 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
Re: Imon module Oops and kernel hang
On 17/07/11 10:43, Andy Walls wrote: This is an obviously repeatable NULL pointer dereference in rc_g_keycode_from_table(). The faulting line of code in both cases disasembles to: 1e: 8b 80 dc 00 00 00 mov0xdc(%eax),%eax %eax obviously holds the value 0 (NULL). But I'm having a hard time telling to where exactly that line of assembly corresponds in rc_g_keycode_from_table(). And I can't tell from the source which data structure has something at offset 0xdc that gets derefernced early: struct rc_dev or struct rc_map. Could you provide the output of $ locate rc-core.ko $ objdump -d -l /blah/blah/drivers/media/rc/rc-core.ko for the rc_g_keycode_from_table() function? I have a few copies lying about now. kepler ~ # locate rc-core.ko /lib/modules/2.6.38-gentoo-r6/kernel/drivers/media/rc/rc-core.ko /lib/modules/2.6.39.3/kernel/drivers/media/rc/rc-core.ko /lib/modules/3.0.0-rc7/kernel/drivers/media/rc/rc-core.ko /usr/src/linux-2.6.38-gentoo-r6/drivers/media/rc/.rc-core.ko.cmd /usr/src/linux-2.6.38-gentoo-r6/drivers/media/rc/rc-core.ko /usr/src/linux-2.6.39.3/drivers/media/rc/.rc-core.ko.cmd /usr/src/linux-2.6.39.3/drivers/media/rc/rc-core.ko /usr/src/linux-3.0-rc7/drivers/media/rc/.rc-core.ko.cmd /usr/src/linux-3.0-rc7/drivers/media/rc/rc-core.ko This is from my current running kernel /lib/modules/2.6.38-gentoo-r6/kernel/drivers/media/rc/rc-core.ko and the partial objdump and corresponding oops/crash output: 0450 rc_g_keycode_from_table: rc_g_keycode_from_table(): 450: 55 push %ebp 451: 89 e5 mov%esp,%ebp 453: 57 push %edi 454: 56 push %esi 455: 53 push %ebx 456: 83 ec 24sub$0x24,%esp 459: 89 45 e8mov%eax,-0x18(%ebp) 45c: 9c pushf 45d: 8f 45 ecpopl -0x14(%ebp) 460: fa cli 461: 89 e0 mov%esp,%eax 463: 25 00 e0 ff ff and$0xe000,%eax 468: ff 40 14incl 0x14(%eax) 46b: 8b 45 e8mov-0x18(%ebp),%eax 46e: 8b 80 d4 00 00 00 mov0xd4(%eax),%eax 474: 89 c3 mov%eax,%ebx 476: 89 45 f0mov%eax,-0x10(%ebp) 479: 4b dec%ebx 47a: 78 38 js 4b4 rc_g_keycode_from_table+0x64 47c: 8b 45 e8mov-0x18(%ebp),%eax 47f: 31 c9 xor%ecx,%ecx 481: 8b b0 cc 00 00 00 mov0xcc(%eax),%esi 487: eb 0e jmp497 rc_g_keycode_from_table+0x47 489: 8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi 490: 8d 48 01lea0x1(%eax),%ecx 493: 39 d9 cmp%ebx,%ecx 495: 7f 1d jg 4b4 rc_g_keycode_from_table+0x64 497: 8d 04 0blea(%ebx,%ecx,1),%eax 49a: 89 c7 mov%eax,%edi 49c: c1 ef 1fshr$0x1f,%edi 49f: 8d 04 07lea(%edi,%eax,1),%eax 4a2: d1 f8 sar%eax 4a4: 8d 3c c6lea(%esi,%eax,8),%edi 4a7: 3b 17 cmp(%edi),%edx 4a9: 77 e5 ja 490 rc_g_keycode_from_table+0x40 4ab: 73 3b jae4e8 rc_g_keycode_from_table+0x98 4ad: 8d 58 fflea-0x1(%eax),%ebx 4b0: 39 d9 cmp%ebx,%ecx 4b2: 7e e3 jle497 rc_g_keycode_from_table+0x47 4b4: 31 db xor%ebx,%ebx 4b6: ff 75 ecpushl -0x14(%ebp) 4b9: 9d popf 4ba: 89 e0 mov%esp,%eax 4bc: 25 00 e0 ff ff and$0xe000,%eax 4c1: ff 48 14decl 0x14(%eax) 4c4: 8b 40 08mov0x8(%eax),%eax 4c7: a8 08 test $0x8,%al 4c9: 75 52 jne51d rc_g_keycode_from_table+0xcd 4cb: 85 db test %ebx,%ebx 4cd: 74 0a je 4d9 rc_g_keycode_from_table+0x89 4cf: 8b 3d 00 00 00 00 mov0x0,%edi 4d5: 85 ff test %edi,%edi 4d7: 7f 19 jg 4f2 rc_g_keycode_from_table+0xa2 4d9: 83 c4 24add$0x24,%esp 4dc: 89 d8 mov%ebx,%eax 4de: 5b pop%ebx 4df:
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
On 16.07.2011 18:37, Rémi Denis-Courmont wrote: Le samedi 16 juillet 2011 18:53:16 Andreas Oberritter, vous avez écrit : You are wrong, actually you can. At least here in Finland some cable networks offers DVB-T too. I know that there are cable operators which use DVB-T, but they don't use DVB-C simultaneously. This wouldn't make sense, unless they didn't want their customers to receive their signals. They do offer both simultaneously. DNA (formerly Welho) in Helsinki provides both DVB-T and DVB-C on the same cable, obviously on different frequencies. Is there any channel available on DVB-T which isn't available on DVB-C in this cable network? -- 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 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
On 17.07.2011 02:56, Mauro Carvalho Chehab wrote: Em 16-07-2011 12:53, Andreas Oberritter escreveu: On 16.07.2011 17:44, Antti Palosaari wrote: On 07/16/2011 06:40 PM, Andreas Oberritter wrote: On 16.07.2011 16:54, Mauro Carvalho Chehab wrote: Em 16-07-2011 11:16, Antti Palosaari escreveu: On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not integrated to same silicon. If you add such FE delsys switch mechanism it needs some more glue to bind two physical FEs to one virtual FE. I see much easier to keep all FEs as own - just register those under the same adapter if FEs are shared. In this case, the driver should just create two frontends, as currently. There's a difference when there are two physical FE's and just one FE: with 2 FE's, the userspace application can just keep both opened at the same time. Some applications (like vdr) assumes that all multi-fe are like that. Does this mean demod is not sleeping (.init() called)? When there's just a single FE, but the driver needs to fork it in two due to the API troubles, the driver needs to prevent the usage of both fe's, either at open or at the ioctl level. So, applications like vdr will only use the first frontend. Lets take example. There is shared MFE having DVB-S, DVB-T and DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S have own. One remark: In my previous mail I assumed that in your example DVB-S and either DVB-C or DVB-T can be tuned simultaneously, i.e. there are two antenna connectors and two tuners in addition to the two demod chips. If this assumtion was wrong, then of course approach 2 is the sane one, not approach 3. Currently it will shown as: Let me name the approaches: Approach 1) * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T) ** frontend2 (DVB-C) Approach 2) Your new ideal solution will be: * adapter0 ** frontend0 (DVB-S/T/C) Approach 3) What really happens (mixed old and new): * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T/C) What I've said before is that approach 3 is the ideal solution. It does not look very good to offer this kind of mixed solution, since it is possible to offer only one solution for userspace, new or old, but not mixing. Good point. There's an additional aspect to handle: if a driver that uses approach 1, a conversion to either approach 2 or 3 would break existing applications that can't handle with the new approach. There's a 4th posibility: always offering fe0 with MFE capabilities, and creating
[GIT pull for 3.0] media regression fixes: Was: Re: [GIT PULL for 3.0] master
Em 16-07-2011 12:42, Mauro Carvalho Chehab escreveu: Linus, In time: Email subject got wrong... Note to myself: I should avoid rush sending emails just before a weekend travel... The patches at the tree are correct, and I double-checked it on my notebook. Thanks! Mauro Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus For a couple of regression fixes for 3.0. Thanks! Mauro The following changes since commit ddc6ff31cc22720c46c1547a5310ea260a968ae9: [media] msp3400: fill in v4l2_tuner based on vt-type field (2011-07-07 17:28:30 -0300) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Devin Heitmueller (1): [media] dvb_frontend: fix race condition in stopping/starting frontend Jarod Wilson (2): [media] Revert V4L/DVB: cx23885: Enable Message Signaled Interrupts(MSI) [media] nuvoton-cir: make idle timeout more sane Mauro Carvalho Chehab (1): [media] tuner-core: fix a 2.6.39 regression with mt20xx Rafi Rubin (2): [media] mceusb: Timeout unit corrections [media] mceusb: increase default timeout to 100ms Ralf Baechle (1): [media] MEDIA: Fix non-ISA_DMA_API link failure of sound code Randy Dunlap (1): [media] media: fix radio-sf16fmr2 build when SND is not enabled drivers/media/dvb/dvb-core/dvb_frontend.c |8 drivers/media/radio/Kconfig|4 ++-- drivers/media/rc/mceusb.c |9 + drivers/media/rc/nuvoton-cir.c |2 +- drivers/media/video/cx23885/cx23885-core.c |9 ++--- drivers/media/video/tuner-core.c | 16 6 files changed, 30 insertions(+), 18 deletions(-) -- 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 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Em 17-07-2011 00:02, Andreas Oberritter escreveu: Approach 2 limits the usage of two simultaneous fe, when they're not mutually exclusive. Not sure if this is actually a problem. This would be a problem, of course. If they're not mutually exclusive, then I'd expect the possibility to use them simultaneously. From userspace perspective, the possibility of using them simultaneously may not actually be useful, provided that they both share the same demux interface. However, I agree that adding an artificial limit there doesn't seem right. 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
