Re: [PATCH 01/13] V4L: Extend V4L2_CID_COLORFX with more image effects
Hi, On 04/27/2012 09:02 PM, Hans Verkuil wrote: On Friday, April 27, 2012 19:54:50 Sylwester Nawrocki wrote: On 04/27/2012 12:12 PM, Hans Verkuil wrote: On Friday, April 27, 2012 11:52:54 Sylwester Nawrocki wrote: This patch adds definition of additional color effects: - V4L2_COLORFX_AQUA, - V4L2_COLORFX_ART_FREEZE, - V4L2_COLORFX_SILHOUETTE, - V4L2_COLORFX_SOLARIZATION, - V4L2_COLORFX_ANTIQUE, - V4L2_COLORFX_ARBITRARY_CBCR. BTW, reading this again I think ARBITRARY_CBCR is a confusing name. Perhaps REPLACE_CBCR or SET_CBCR is better? This is how it was named in the datasheets ;-) I like V4L2_COLORFX_REPLACE_CBCR better. What about V4L2_COLORFX_CONSTANT_CBCR, V4L2_COLORFX_PATTERN_CBCR or V4L2_COLORFX_FILL_IN_CBCR ? ... Maybe it would be better to add a V4L2_COLORFX_COLOR menu entry and V4L2_CID_COLORFX_CB, V4L2_CID_COLORFX_CR controls ? That would work, yes. Although I am not convinced splitting it up is worthwhile. The colorspace can change on the fly, so you would have to handle out-of-range values anyway. Personally I would stick with CID_COLORFX_CBCR (and clearly document in which byte the CB and the CR go). That's going to be sufficient I guess. Applications will most likely be just pre-configured with some fixed CB/CR values, mapped to some meaningful names. It should be fine, as far as those coefficient registers are accessible from user space. That's just my opinion, though. Regards, Hans PS: I'll review the camera control enhancements patch series in the next few days. Great, thanks a lot! I was thinking about a guide on which control groups should be used for each devices, to make the driver and application writers' life easier, but its not an easy task in light of high diversity of camera devices... -- Regards, Sylwester -- 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
Demod hardware pid filter implement
Hello Antti,
As we known that AF9013 has the hardware pid filter capability.
How to implement the hardware pid filter, which the demodulator has this
capability?
For usb, i find
struct dvb_usb_adapter_fe_properties {
int (*pid_filter_ctrl) (struct dvb_usb_adapter *, int);
int (*pid_filter) (struct dvb_usb_adapter *, int, u16, int);
...
It can implement the hardware filter if the demodulator has.
But on the other interface, i do not find similar solution.
For example, we have a hardware of AF9013 and CX23885 pcie chip and want to use
the hardware pid filter in AF9013.
i find some codes to hook the dvb.demux to do that pid filtering.
I think it is demod property, but the current dvb_frontend_ops has no
definition for this.
It is better that adding a function pointer of pid filtering in
dvb_frontend_ops to do in general way.
What is your idea?
BR,
Max
--
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: Demod hardware pid filter implement
On 28.04.2012 12:17, nibble.max wrote:
Hello Antti,
As we known that AF9013 has the hardware pid filter capability.
How to implement the hardware pid filter, which the demodulator has this
capability?
For usb, i find
struct dvb_usb_adapter_fe_properties {
int (*pid_filter_ctrl) (struct dvb_usb_adapter *, int);
int (*pid_filter) (struct dvb_usb_adapter *, int, u16, int);
...
It can implement the hardware filter if the demodulator has.
But on the other interface, i do not find similar solution.
For example, we have a hardware of AF9013 and CX23885 pcie chip and want to use
the hardware pid filter in AF9013.
i find some codes to hook the dvb.demux to do that pid filtering.
I think it is demod property, but the current dvb_frontend_ops has no
definition for this.
It is better that adding a function pointer of pid filtering in
dvb_frontend_ops to do in general way.
What is your idea?
It is not supported currently - only DVB USB supports it.
In order to PID filter for the demodulator you will need to change DVB
fronted code. Copy some PID -filtering stuff from the DVB USB to the
frondend handling.
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: [GIT PULL FOR v3.5] An ivtv fix and support suspend/resume in radio-keene
Hi Mauro, One other fix was added: radio-isa: fix memory leak drivers/media/radio/radio-isa.c|8 +++- v4l2_ctrl_handler_free wasn't called if there was a problem creating controls. Regards, Hans On Friday, April 27, 2012 13:56:37 Hans Verkuil wrote: Hi Mauro, One small trivial ivtv fix and a patch that adds support for suspend/resume to the radio-keene driver. Regards, Hans The following changes since commit bcb2cf6e0bf033d79821c89e5ccb328bfbd44907: [media] ngene: remove an unneeded condition (2012-04-26 15:29:23 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git fixes for you to fetch changes up to 71ea18d3e92d834926751f8460cf6893424b3852: radio-keene: support suspend/resume. (2012-04-27 09:57:02 +0200) Hans Verkuil (2): ivtv: set max/step to 0 for PTS and FRAME controls. radio-keene: support suspend/resume. drivers/media/radio/radio-keene.c | 20 drivers/media/video/ivtv/ivtv-driver.c |4 ++-- 2 files changed, 22 insertions(+), 2 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 v3] [media] s5p-g2d: Add support for FIMG2D v4.1 H/W logic
Hi Sachin,
On 04/24/2012 12:38 PM, Sachin Kamat wrote:
From: Ajay Kumarajaykumar...@samsung.com
Modify the G2D driver(which initially supported only FIMG2D v3 style H/W)
to support FIMG2D v4.1 style hardware present on Exynos4x12 and Exynos52x0
SOC.
-- Set the SRC and DST type to 'memory' instead of using reset values.
-- FIMG2D v4.1 H/W uses different logic for stretching(scaling).
-- Use CACHECTL_REG only with FIMG2D v3.
Signed-off-by: Ajay Kumarajaykumar...@samsung.com
Signed-off-by: Sachin Kamatsachin.ka...@linaro.org
---
drivers/media/video/s5p-g2d/g2d-hw.c | 17 +
drivers/media/video/s5p-g2d/g2d-regs.h |6 ++
drivers/media/video/s5p-g2d/g2d.c | 23 +--
drivers/media/video/s5p-g2d/g2d.h |9 -
4 files changed, 48 insertions(+), 7 deletions(-)
...
@@ -783,6 +788,8 @@ static int g2d_probe(struct platform_device *pdev)
def_frame.stride = (def_frame.width * def_frame.fmt-depth) 3;
+ dev-device_type = platform_get_device_id(pdev)-driver_data;
+
return 0;
unreg_video_dev:
@@ -832,9 +839,21 @@ static int g2d_remove(struct platform_device *pdev)
return 0;
}
+static struct platform_device_id g2d_driver_ids[] = {
+ {
+ .name = s5p-g2d,
+ .driver_data= TYPE_G2D_3X,
IMHO it would be better to define a separate data structure describing
the quirks. For an example please see http://patchwork.linuxtv.org/patch/10869
and the code using struct flite_variant. There was some lengthy
discussion recently on linux-i2c mailing list, where someone tried
to add more quirks to the i2c-s3c2440 driver which uses 'driver_data'
like it is done in this patch. To avoid wasting time in future,
I would suggest to make 'driver_data' right away holding a pointer
to a data structure, rather than simple integer.
We could start, for example, with something like:
struct g2d_variant {
unsigned short hw_rev;
};
+ }, {
+ .name = s5p-g2d41x,
+ .driver_data= TYPE_G2D_41X,
+ }, { },
How about marking the last empty entry e.g.
{ /* sentinel */ }
? Or just putting it in new line ?
+};
+MODULE_DEVICE_TABLE(platform, s3c24xx_driver_ids);
Hmm, should be g2d_driver_ids. This isn't going to fly when you
compile this driver as a module. You would get an error like:
error: ‘__mod_platform_device_table’ aliased to undefined symbol
‘s3c24xx_driver_ids’
Regards,
Sylwester
--
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 v2] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG
Hi, On 04/25/2012 06:09 PM, Jean-Francois Moine wrote: Hi Hans, snip BTW, I don't think the exposure and gain controls use the right registers as they are coded in the actual gspca pac7302 subdriver. The ms-windows driver uses the registers (3-80 / 3-03), (3-05 / 3-04), 3-03, 3-04 and 3-05 are already known and they all influence framerate / exposure in some way. I've also ran some tests with 3-80, again it influences framerate in some way (*). We already have a well tested and working, fine-grained way to control exposure so I think it is best to leave things as is exposure wise. (3-12) 3-12 is interesting, it is a new gain control. The pull request I've just send (with you in the CC) contains a patch to improve gain control using both 3-10 and 3-12 together. and (1-80) 1-80 is compression balance, since our decompression code for higher compression settings (markers 68) still is not perfect this is best left untouched. *) Note I've documented all registers I've ran tests with as part of the patchset for which I've just send a pull request. Regards, Hans -- 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: video capture driver interlacing question (easycap)
On Thu, Apr 26, 2012 at 5:33 PM, Ezequiel García elezegar...@gmail.com wrote: Hi everyone, As you may know I'm re-writing from scratch the staging/easycap driver. Finally, after digging through the labyrinthic staging/easycap code, I've reached a point where I'm able to understand isoc packets. Despite not having any documentation (I asked several times) from chip vendor, I can separate packets in odd and even. So, instead of receiving frames the device is sending me fields, right? My doubt now is this: * Do I have to *merge* this pair of fields for each frame, or can I give it to v4l? If affirmative: how should I *merge* them? * Is this related to multiplanar buffers (should I use vb2_plane_addr)? Currently, staging/easycap does some strange and complex conversion, from the pair of fields buffers, to get a frame buffer (!) but I'm not sure if it's the correct way to do it? I guess I can keep staring at em28xx (together with vivi/uvc/pwc) driver, but if someone cares to give me a small hint or point me at a small portion of code I'll be grateful. Thanks, Ezequiel. Anyone? -- 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
[GIT PULL FOR 3.5] gspca_pac73XX improvements + misc fixes
Hi Mauro et al, Please pull from my tree for a bunch of gspca_pac73XX improvements and 1 other webcam driver fix. The following changes since commit bcb2cf6e0bf033d79821c89e5ccb328bfbd44907: [media] ngene: remove an unneeded condition (2012-04-26 15:29:23 -0300) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.5 for you to fetch changes up to c9b5378afdfc2fa3eecae2cf8d2e20c40e60496c: gspca_pac7302: Improve the gain control (2012-04-28 15:37:59 +0200) Hans de Goede (12): stk-webcam: Don't flip the image by default gspca/autogain_functions.h: Allow users to declare what they want gspca_pac73xx: Remove comments from before the 7302 / 7311 separation gspca_pac7311: Make sure exposure changes get applied immediately gspca_pac7311: Adjust control scales to match registers gspca_pac7311: Switch to new gspca control mechanism gspca_pac7311: Switch to coarse expo autogain algorithm gspca_pac7311: Convert multi-line comments to standard kernel style gspca_pac7311: Properly set the compression balance gspca_pac7302: Convert multi-line comments to standard kernel style gspca_pac7302: Document some more registers gspca_pac7302: Improve the gain control drivers/media/video/gspca/autogain_functions.h |6 +- drivers/media/video/gspca/nw80x.c |2 + drivers/media/video/gspca/pac7302.c| 184 +++- drivers/media/video/gspca/pac7311.c| 380 +++- drivers/media/video/gspca/sonixb.c |2 + drivers/media/video/gspca/sonixj.c |5 +- drivers/media/video/gspca/topro.c |6 +- drivers/media/video/stk-webcam.c |8 +- 8 files changed, 239 insertions(+), 354 deletions(-) Thanks Regards, Hans -- 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] em28xx: Make card_setup() and pre_card_setup() static
From: Ezequiel Garcia elezegar...@gmail.com
This cleans namespace a bit by making em28xx_card_setup()
em28xx_pre_card_setup() static functions.
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
drivers/media/video/em28xx/em28xx-cards.c |6 --
drivers/media/video/em28xx/em28xx.h |2 --
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 9fd8cc7..5c0fd9f 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -69,6 +69,8 @@ struct em28xx_hash_table {
unsigned int tuner;
};
+static void em28xx_pre_card_setup(struct em28xx *dev);
+
/*
* Reset sequences for analog/digital modes
*/
@@ -2361,7 +2363,7 @@ static int em28xx_hint_sensor(struct em28xx *dev)
/* Since em28xx_pre_card_setup() requires a proper dev-model,
* this won't work for boards with generic PCI IDs
*/
-void em28xx_pre_card_setup(struct em28xx *dev)
+static void em28xx_pre_card_setup(struct em28xx *dev)
{
/* Set the initial XCLK and I2C clock values based on the board
definition */
@@ -2709,7 +2711,7 @@ void em28xx_register_i2c_ir(struct em28xx *dev)
i2c_new_probed_device(dev-i2c_adap, info, addr_list, NULL);
}
-void em28xx_card_setup(struct em28xx *dev)
+static void em28xx_card_setup(struct em28xx *dev)
{
/*
* If the device can be a webcam, seek for a sensor.
diff --git a/drivers/media/video/em28xx/em28xx.h
b/drivers/media/video/em28xx/em28xx.h
index 2868b19..100d1e8 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -710,8 +710,6 @@ void em28xx_release_analog_resources(struct em28xx *dev);
/* Provided by em28xx-cards.c */
extern int em2800_variant_detect(struct usb_device *udev, int model);
-extern void em28xx_pre_card_setup(struct em28xx *dev);
-extern void em28xx_card_setup(struct em28xx *dev);
extern struct em28xx_board em28xx_boards[];
extern struct usb_device_id em28xx_id_table[];
extern const unsigned int em28xx_bcount;
--
1.7.3.4
--
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] em28xx: Remove unused list_head struct for queued buffers
From: Ezequiel Garcia elezegar...@gmail.com
The list_head struct usage was fully removed by commit
d7aa80207babe694b316a48200b096cf0336ecb3.
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
drivers/media/video/em28xx/em28xx-cards.c |2 --
drivers/media/video/em28xx/em28xx.h |1 -
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 5c0fd9f..eea90b0 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -3142,9 +3142,7 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
/* init video dma queues */
INIT_LIST_HEAD(dev-vidq.active);
- INIT_LIST_HEAD(dev-vidq.queued);
INIT_LIST_HEAD(dev-vbiq.active);
- INIT_LIST_HEAD(dev-vbiq.queued);
if (dev-board.has_msp34xx) {
/* Send a reset to other chips via gpio */
diff --git a/drivers/media/video/em28xx/em28xx.h
b/drivers/media/video/em28xx/em28xx.h
index 100d1e8..87766f1 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -269,7 +269,6 @@ struct em28xx_buffer {
struct em28xx_dmaqueue {
struct list_head active;
- struct list_head queued;
wait_queue_head_t wq;
--
1.7.3.4
--
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
[GIT PULL FOR 3.5] gspca_pac73XX improvements + misc fixes
Hi Mauro et al, Please pull from my tree for a bunch of gspca_pac73XX improvements and 1 other webcam driver fix. The following changes since commit bcb2cf6e0bf033d79821c89e5ccb328bfbd44907: [media] ngene: remove an unneeded condition (2012-04-26 15:29:23 -0300) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.5 for you to fetch changes up to c9b5378afdfc2fa3eecae2cf8d2e20c40e60496c: gspca_pac7302: Improve the gain control (2012-04-28 15:37:59 +0200) Hans de Goede (12): stk-webcam: Don't flip the image by default gspca/autogain_functions.h: Allow users to declare what they want gspca_pac73xx: Remove comments from before the 7302 / 7311 separation gspca_pac7311: Make sure exposure changes get applied immediately gspca_pac7311: Adjust control scales to match registers gspca_pac7311: Switch to new gspca control mechanism gspca_pac7311: Switch to coarse expo autogain algorithm gspca_pac7311: Convert multi-line comments to standard kernel style gspca_pac7311: Properly set the compression balance gspca_pac7302: Convert multi-line comments to standard kernel style gspca_pac7302: Document some more registers gspca_pac7302: Improve the gain control drivers/media/video/gspca/autogain_functions.h |6 +- drivers/media/video/gspca/nw80x.c |2 + drivers/media/video/gspca/pac7302.c| 184 +++- drivers/media/video/gspca/pac7311.c| 380 +++- drivers/media/video/gspca/sonixb.c |2 + drivers/media/video/gspca/sonixj.c |5 +- drivers/media/video/gspca/topro.c |6 +- drivers/media/video/stk-webcam.c |8 +- 8 files changed, 239 insertions(+), 354 deletions(-) Thanks Regards, Hans -- 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] [media] ngene: remove an unneeded condition
Am 20.04.2012 15:15, schrieb Dan Carpenter: stat is always zero here. The condition used to be needed, but we shifted stuff around in 0f0b270f90 [media] ngene: CXD2099AR Common Interface driver. This doesn't change how the code works, it's just a bit tidier. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/media/dvb/ngene/ngene-core.c b/drivers/media/dvb/ngene/ngene-core.c index f129a93..3985738 100644 --- a/drivers/media/dvb/ngene/ngene-core.c +++ b/drivers/media/dvb/ngene/ngene-core.c @@ -1409,10 +1409,8 @@ static int ngene_start(struct ngene *dev) if (stat 0) goto fail; - if (!stat) - return stat; + return 0; - /* otherwise error: fall through */ fail: ngwritel(0, NGENE_INT_ENABLE); free_irq(dev-pci_dev-irq, dev); it seems more logical to use the positive exit in this case like: if (stat =0) return 0; instead of jumping over return 0: just my 2 cents, re, wh -- 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: HVR-1600 QAM recordings with slight glitches in them
On Tue, 2012-04-24 at 23:07 -0400, Brian J. Murrell wrote: On 12-04-24 06:42 PM, Andy Walls wrote: Run 'femon' on the cx18's dvb frontend when you have a live QAM capture ongoing. OK. Ran it all evening during the evening capture window. Started it at 20:30, sharp to coincide with the evening's recording from that card also starting at 20:30 sharp. Here's where it found anomalies: $ nl /var/tmp/femon.out | grep -v | ber | unc | grepping out the 0 lines doesn't let one see the trends in Signal to Noise Ratio (SNR) before and after the uncorrectable (unc) block counts. So you can see, since femon prints an output line each second, the number on the left is the seconds since 20:30 and we are looking for any line showing a ber or unc that is non-zero: Cool. First. note the following about the s5h1409 driver for the CX24227 (aka S5H109) QAM/8VSB demodulator: a. the Bit Eror Rate (BER) as returned by the driver is bogus; ignore it. It is just a copy of the uncorrectable block count. b. The signal level is a software computed value based on the SNR value. Ignore signal as redundant information. c. The Signal to Noise Ratio (SNR) should be a hexadecimal value with units of 1/10th of a deciBel (0.1 dB) (centiBels?). E.g. 0x13a = 314 = 31.4 dB I believe Steven calibrated this value to SNR at the RF input of the HVR-1600. (Steven or Devin, correct me if I am wrong.) 1FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC) 67status SCVYL | signal 013a | snr 013a | ber 0198 | unc 0198 | FE_HAS_LOCK 313status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 457status SCVYL | signal 013a | snr 013a | ber 026e | unc 026e | FE_HAS_LOCK 802status SCVYL | signal 013c | snr 013c | ber 0265 | unc 0265 | FE_HAS_LOCK 1093status SCVYL | signal 013a | snr 013a | ber 014b | unc 014b | FE_HAS_LOCK 1184status SCVYL | signal 013a | snr 013a | ber 01ca | unc 01ca | FE_HAS_LOCK 1192status SCVYL | signal 013a | snr 013a | ber 0267 | unc 0267 | FE_HAS_LOCK 1385status SCVYL | signal 013c | snr 013c | ber 025d | unc 025d | FE_HAS_LOCK 1435status SCVYL | signal 013c | snr 013c | ber 0268 | unc 0268 | FE_HAS_LOCK 1511status SCVYL | signal 013c | snr 013c | ber 026c | unc 026c | FE_HAS_LOCK 1657status SCVYL | signal 013a | snr 013a | ber 026a | unc 026a | FE_HAS_LOCK 1693status SCVYL | signal 013a | snr 013c | ber 026f | unc 026f | FE_HAS_LOCK 1749status SCVYL | signal 013c | snr 013c | ber 0184 | unc 0184 | FE_HAS_LOCK 1796status SCVYL | signal 013a | snr 013a | ber 1a8b | unc 1a8b | FE_HAS_LOCK 1814status SCVYL | signal 013c | snr 013c | ber 026d | unc 026d | FE_HAS_LOCK 2028status SCVYL | signal 013c | snr 013c | ber 0275 | unc 0275 | FE_HAS_LOCK 2081status SCVYL | signal 013c | snr 013c | ber 023a | unc 023a | FE_HAS_LOCK 2261status SCVYL | signal 013c | snr 013c | ber 0264 | unc 0264 | FE_HAS_LOCK 2307status SCVYL | signal 013c | snr 013c | ber 0279 | unc 0279 | FE_HAS_LOCK 2318status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 2474status SCVYL | signal 013a | snr 013a | ber 026f | unc 026f | FE_HAS_LOCK 2533status SCVYL | signal 013c | snr 013c | ber 0098 | unc 0098 | FE_HAS_LOCK 2612status SCVYL | signal 013a | snr 013a | ber 026a | unc 026a | FE_HAS_LOCK 2627status SCVYL | signal 013c | snr 013c | ber 0108 | unc 0108 | FE_HAS_LOCK 2671status SCVYL | signal 013c | snr 013c | ber 0196 | unc 0196 | FE_HAS_LOCK 2870status SCVYL | signal 013c | snr 013c | ber 0264 | unc 0264 | FE_HAS_LOCK 3084status SCVYL | signal 013c | snr 013c | ber 0274 | unc 0274 | FE_HAS_LOCK 3220status SCVYL | signal 013c | snr 013c | ber 0275 | unc 0275 | FE_HAS_LOCK 3323status SCVYL | signal 013c | snr 013c | ber 026b | unc 026b | FE_HAS_LOCK 3406status SCVYL | signal 013c | snr 013c | ber 024f | unc 024f | FE_HAS_LOCK 3433status SCVYL | signal 013c | snr 013a | ber 022a | unc 022a | FE_HAS_LOCK 3946status SCVYL | signal 013c | snr 013c | ber 0270 | unc 0270 | FE_HAS_LOCK 4129status SCVYL | signal 013c | snr 013c | ber 026d | unc 026d | FE_HAS_LOCK 4275status SCVYL | signal 013c | snr 013c | ber 0273 | unc 0273 | FE_HAS_LOCK 4284status SCVYL | signal 013c | snr 013c | ber 0267 | unc 0267 | FE_HAS_LOCK 4411status SCVYL | signal 013c | snr
Re: [media-ctl PATCH] Compare entity name length aswell
Hi Laurent
On Wed, Apr 25, 2012 at 8:57 AM, Sergio Aguirre saagui...@ti.com wrote:
Otherwise, some false positives might arise when
having 2 subdevices with similar names, like:
OMAP4 ISS ISP IPIPEIF
OMAP4 ISS ISP IPIPE
Before this patch, trying to find OMAP4 ISS ISP IPIPE, resulted
in a false entity match, retrieving OMAP4 ISS ISP IPIPEIF
information instead.
Checking length should ensure such cases are handled well.
Any feedback about this?
Regards,
Sergio
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
src/mediactl.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mediactl.c b/src/mediactl.c
index 5b8c587..451a386 100644
--- a/src/mediactl.c
+++ b/src/mediactl.c
@@ -66,7 +66,8 @@ struct media_entity *media_get_entity_by_name(struct
media_device *media,
for (i = 0; i media-entities_count; ++i) {
struct media_entity *entity = media-entities[i];
- if (strncmp(entity-info.name, name, length) == 0)
+ if ((strncmp(entity-info.name, name, length) == 0)
+ (strlen(entity-info.name) == length))
return entity;
}
--
1.7.5.4
--
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] em28xx: Remove unused field from em28xx_buffer struct
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
drivers/media/video/em28xx/em28xx.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx.h
b/drivers/media/video/em28xx/em28xx.h
index 87766f1..b004dd8 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -264,7 +264,6 @@ struct em28xx_buffer {
struct list_head frame;
int top_field;
- int receiving;
};
struct em28xx_dmaqueue {
--
1.7.3.4
--
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] em28xx: Remove unused enum em28xx_io_method
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
drivers/media/video/em28xx/em28xx.h |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx.h
b/drivers/media/video/em28xx/em28xx.h
index b004dd8..b5bac9c 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -275,13 +275,6 @@ struct em28xx_dmaqueue {
intpos;
};
-/* io methods */
-enum em28xx_io_method {
- IO_NONE,
- IO_READ,
- IO_MMAP,
-};
-
/* inputs */
#define MAX_EM28XX_INPUT 4
@@ -575,7 +568,6 @@ struct em28xx {
/* states */
enum em28xx_dev_state state;
- enum em28xx_io_method io;
/* vbi related state tracking */
int capture_type;
--
1.7.3.4
--
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
[RFCv1 PATCH 0/7] gspca: allow use of control framework and other fixes
Hi all, Here is a patch series that makes it possible to use the control framework in gspca. The gspca core changes are very minor but as a bonus give you priority support as well. The hard work is in updating the subdrivers. I've done two, and I intend to do the stv06xx driver as well, but that's the last of my gspca webcams that I can test. Looking through the subdrivers I think that 50-70% are in the category 'easy to convert', the others will take a bit more time (autogain/gain type of constructs are always more complex than just a simple brightness control). After applying this patch series the two converted drivers pass the v4l2-compliance test as it stands today. Comments? Questions? Regards. Hans -- 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
[RFCv1 PATCH 1/7] gspca: allow subdrivers to use the control framework.
From: Hans Verkuil hans.verk...@cisco.com
Make the necessary changes to allow subdrivers to use the control framework.
This does not add control event support, that needs more work.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/gspca/gspca.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index ca5a2b1..56dff10 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -38,6 +38,7 @@
#include linux/uaccess.h
#include linux/ktime.h
#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
#include gspca.h
@@ -1006,6 +1007,8 @@ static void gspca_set_default_mode(struct gspca_dev
*gspca_dev)
/* set the current control values to their default values
* which may have changed in sd_init() */
+ /* does nothing if ctrl_handler == NULL */
+ v4l2_ctrl_handler_setup(gspca_dev-vdev.ctrl_handler);
ctrl = gspca_dev-cam.ctrls;
if (ctrl != NULL) {
for (i = 0;
@@ -1323,6 +1326,7 @@ static void gspca_release(struct video_device *vfd)
PDEBUG(D_PROBE, %s released,
video_device_node_name(gspca_dev-vdev));
+ v4l2_ctrl_handler_free(gspca_dev-vdev.ctrl_handler);
kfree(gspca_dev-usb_buf);
kfree(gspca_dev);
}
@@ -2347,6 +2351,10 @@ int gspca_dev_probe2(struct usb_interface *intf,
gspca_dev-sd_desc = sd_desc;
gspca_dev-nbufread = 2;
gspca_dev-empty_packet = -1; /* don't check the empty packets */
+ gspca_dev-vdev = gspca_template;
+ gspca_dev-vdev.parent = intf-dev;
+ gspca_dev-module = module;
+ gspca_dev-present = 1;
/* configure the subdriver and initialize the USB device */
ret = sd_desc-config(gspca_dev, id);
@@ -2368,10 +2376,6 @@ int gspca_dev_probe2(struct usb_interface *intf,
init_waitqueue_head(gspca_dev-wq);
/* init video stuff */
- memcpy(gspca_dev-vdev, gspca_template, sizeof gspca_template);
- gspca_dev-vdev.parent = intf-dev;
- gspca_dev-module = module;
- gspca_dev-present = 1;
ret = video_register_device(gspca_dev-vdev,
VFL_TYPE_GRABBER,
-1);
@@ -2391,6 +2395,7 @@ out:
if (gspca_dev-input_dev)
input_unregister_device(gspca_dev-input_dev);
#endif
+ v4l2_ctrl_handler_free(gspca_dev-vdev.ctrl_handler);
kfree(gspca_dev-usb_buf);
kfree(gspca_dev);
return ret;
--
1.7.10
--
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
[RFCv1 PATCH 2/7] zc3xx: convert to the control framework.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/gspca/zc3xx.c | 451 +++--
1 file changed, 182 insertions(+), 269 deletions(-)
diff --git a/drivers/media/video/gspca/zc3xx.c
b/drivers/media/video/gspca/zc3xx.c
index 7d9a4f1..e7b7599 100644
--- a/drivers/media/video/gspca/zc3xx.c
+++ b/drivers/media/video/gspca/zc3xx.c
@@ -22,6 +22,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME : fmt
#include linux/input.h
+#include media/v4l2-ctrls.h
#include gspca.h
#include jpeg.h
@@ -35,26 +36,23 @@ static int force_sensor = -1;
#define REG08_DEF 3/* default JPEG compression (70%) */
#include zc3xx-reg.h
-/* controls */
-enum e_ctrl {
- BRIGHTNESS,
- CONTRAST,
- EXPOSURE,
- GAMMA,
- AUTOGAIN,
- LIGHTFREQ,
- SHARPNESS,
- QUALITY,
- NCTRLS /* number of controls */
-};
-
-#define AUTOGAIN_DEF 1
-
/* specific webcam descriptor */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
- struct gspca_ctrl ctrls[NCTRLS];
+ struct v4l2_ctrl_handler ctrl_handler;
+ struct { /* gamma/brightness/contrast control cluster */
+ struct v4l2_ctrl *gamma;
+ struct v4l2_ctrl *brightness;
+ struct v4l2_ctrl *contrast;
+ };
+ struct { /* autogain/exposure control cluster */
+ struct v4l2_ctrl *autogain;
+ struct v4l2_ctrl *exposure;
+ };
+ struct v4l2_ctrl *plfreq;
+ struct v4l2_ctrl *sharpness;
+ struct v4l2_ctrl *jpegqual;
struct work_struct work;
struct workqueue_struct *work_thread;
@@ -95,112 +93,6 @@ enum sensors {
};
/* V4L2 controls supported by the driver */
-static void setcontrast(struct gspca_dev *gspca_dev);
-static void setexposure(struct gspca_dev *gspca_dev);
-static int sd_setautogain(struct gspca_dev *gspca_dev, __s32 val);
-static void setlightfreq(struct gspca_dev *gspca_dev);
-static void setsharpness(struct gspca_dev *gspca_dev);
-static int sd_setquality(struct gspca_dev *gspca_dev, __s32 val);
-
-static const struct ctrl sd_ctrls[NCTRLS] = {
-[BRIGHTNESS] = {
- {
- .id = V4L2_CID_BRIGHTNESS,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Brightness,
- .minimum = 0,
- .maximum = 255,
- .step= 1,
- .default_value = 128,
- },
- .set_control = setcontrast
- },
-[CONTRAST] = {
- {
- .id = V4L2_CID_CONTRAST,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Contrast,
- .minimum = 0,
- .maximum = 255,
- .step= 1,
- .default_value = 128,
- },
- .set_control = setcontrast
- },
-[EXPOSURE] = {
- {
- .id = V4L2_CID_EXPOSURE,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Exposure,
- .minimum = 0x30d,
- .maximum= 0x493e,
- .step = 1,
- .default_value = 0x927
- },
- .set_control = setexposure
- },
-[GAMMA] = {
- {
- .id = V4L2_CID_GAMMA,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Gamma,
- .minimum = 1,
- .maximum = 6,
- .step= 1,
- .default_value = 4,
- },
- .set_control = setcontrast
- },
-[AUTOGAIN] = {
- {
- .id = V4L2_CID_AUTOGAIN,
- .type= V4L2_CTRL_TYPE_BOOLEAN,
- .name= Auto Gain,
- .minimum = 0,
- .maximum = 1,
- .step= 1,
- .default_value = AUTOGAIN_DEF,
- .flags = V4L2_CTRL_FLAG_UPDATE
- },
- .set = sd_setautogain
- },
-[LIGHTFREQ] = {
- {
- .id = V4L2_CID_POWER_LINE_FREQUENCY,
- .type= V4L2_CTRL_TYPE_MENU,
- .name= Light frequency filter,
- .minimum = 0,
- .maximum = 2, /* 0: 0, 1: 50Hz, 2:60Hz */
- .step= 1,
- .default_value = 0,
- },
- .set_control = setlightfreq
- },
-[SHARPNESS] = {
- {
- .id = V4L2_CID_SHARPNESS,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Sharpness,
- .minimum = 0,
- .maximum = 3,
- .step= 1,
- .default_value = 2,
- },
- .set_control = setsharpness
- },
-[QUALITY] = {
- {
- .id = V4L2_CID_JPEG_COMPRESSION_QUALITY,
- .type=
[RFCv1 PATCH 7/7] gspca: fix querycap and incorrect return codes.
From: Hans Verkuil hans.verk...@cisco.com Add V4L2_CAP_DEVICE_CAPS support to querycap and replace -EINVAL by -ENOTTY whenever an ioctl is not supported. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/gspca/gspca.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/media/video/gspca/gspca.c b/drivers/media/video/gspca/gspca.c index 7b03f36..734eacd 100644 --- a/drivers/media/video/gspca/gspca.c +++ b/drivers/media/video/gspca/gspca.c @@ -1066,10 +1066,10 @@ static int vidioc_g_register(struct file *file, void *priv, struct gspca_dev *gspca_dev = video_drvdata(file); if (!gspca_dev-sd_desc-get_chip_ident) - return -EINVAL; + return -ENOTTY; if (!gspca_dev-sd_desc-get_register) - return -EINVAL; + return -ENOTTY; if (mutex_lock_interruptible(gspca_dev-usb_lock)) return -ERESTARTSYS; @@ -1090,10 +1090,10 @@ static int vidioc_s_register(struct file *file, void *priv, struct gspca_dev *gspca_dev = video_drvdata(file); if (!gspca_dev-sd_desc-get_chip_ident) - return -EINVAL; + return -ENOTTY; if (!gspca_dev-sd_desc-set_register) - return -EINVAL; + return -ENOTTY; if (mutex_lock_interruptible(gspca_dev-usb_lock)) return -ERESTARTSYS; @@ -1115,7 +1115,7 @@ static int vidioc_g_chip_ident(struct file *file, void *priv, struct gspca_dev *gspca_dev = video_drvdata(file); if (!gspca_dev-sd_desc-get_chip_ident) - return -EINVAL; + return -ENOTTY; if (mutex_lock_interruptible(gspca_dev-usb_lock)) return -ERESTARTSYS; @@ -1410,9 +1410,10 @@ static int vidioc_querycap(struct file *file, void *priv, } usb_make_path(gspca_dev-dev, (char *) cap-bus_info, sizeof(cap-bus_info)); - cap-capabilities = V4L2_CAP_VIDEO_CAPTURE + cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | V4L2_CAP_READWRITE; + cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS; ret = 0; out: mutex_unlock(gspca_dev-usb_lock); @@ -1565,7 +1566,7 @@ static int vidioc_querymenu(struct file *file, void *priv, struct gspca_dev *gspca_dev = video_drvdata(file); if (!gspca_dev-sd_desc-querymenu) - return -EINVAL; + return -ENOTTY; return gspca_dev-sd_desc-querymenu(gspca_dev, qmenu); } @@ -1774,7 +1775,7 @@ static int vidioc_g_jpegcomp(struct file *file, void *priv, int ret; if (!gspca_dev-sd_desc-get_jcomp) - return -EINVAL; + return -ENOTTY; if (mutex_lock_interruptible(gspca_dev-usb_lock)) return -ERESTARTSYS; gspca_dev-usb_err = 0; @@ -1793,7 +1794,7 @@ static int vidioc_s_jpegcomp(struct file *file, void *priv, int ret; if (!gspca_dev-sd_desc-set_jcomp) - return -EINVAL; + return -ENOTTY; if (mutex_lock_interruptible(gspca_dev-usb_lock)) return -ERESTARTSYS; gspca_dev-usb_err = 0; -- 1.7.10 -- 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
[RFCv1 PATCH 3/7] sn9c20x: convert to the control framework.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/gspca/sn9c20x.c | 481 ++-
1 file changed, 198 insertions(+), 283 deletions(-)
diff --git a/drivers/media/video/gspca/sn9c20x.c
b/drivers/media/video/gspca/sn9c20x.c
index 7e71aa2..ed51556 100644
--- a/drivers/media/video/gspca/sn9c20x.c
+++ b/drivers/media/video/gspca/sn9c20x.c
@@ -28,6 +28,7 @@
#include jpeg.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include linux/dmi.h
MODULE_AUTHOR(Brian Johnson brij...@gmail.com,
@@ -66,28 +67,32 @@ MODULE_LICENSE(GPL);
#define LED_REVERSE0x2 /* some cameras unset gpio to turn on leds */
#define FLIP_DETECT0x4
-enum e_ctrl {
- BRIGHTNESS,
- CONTRAST,
- SATURATION,
- HUE,
- GAMMA,
- BLUE,
- RED,
- VFLIP,
- HFLIP,
- EXPOSURE,
- GAIN,
- AUTOGAIN,
- QUALITY,
- NCTRLS /* number of controls */
-};
-
/* specific webcam descriptor */
struct sd {
struct gspca_dev gspca_dev;
- struct gspca_ctrl ctrls[NCTRLS];
+ struct v4l2_ctrl_handler ctrl_handler;
+ struct { /* color control cluster */
+ struct v4l2_ctrl *brightness;
+ struct v4l2_ctrl *contrast;
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
+ struct { /* blue/red balance control cluster */
+ struct v4l2_ctrl *blue;
+ struct v4l2_ctrl *red;
+ };
+ struct { /* h/vflip control cluster */
+ struct v4l2_ctrl *hflip;
+ struct v4l2_ctrl *vflip;
+ };
+ struct v4l2_ctrl *gamma;
+ struct { /* autogain and exposure or gain control cluster */
+ struct v4l2_ctrl *autogain;
+ struct v4l2_ctrl *exposure;
+ struct v4l2_ctrl *gain;
+ };
+ struct v4l2_ctrl *jpegqual;
struct work_struct work;
struct workqueue_struct *work_thread;
@@ -166,175 +171,6 @@ static const struct dmi_system_id flip_dmi_table[] = {
{}
};
-static void set_cmatrix(struct gspca_dev *gspca_dev);
-static void set_gamma(struct gspca_dev *gspca_dev);
-static void set_redblue(struct gspca_dev *gspca_dev);
-static void set_hvflip(struct gspca_dev *gspca_dev);
-static void set_exposure(struct gspca_dev *gspca_dev);
-static void set_gain(struct gspca_dev *gspca_dev);
-static void set_quality(struct gspca_dev *gspca_dev);
-
-static const struct ctrl sd_ctrls[NCTRLS] = {
-[BRIGHTNESS] = {
- {
- .id = V4L2_CID_BRIGHTNESS,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Brightness,
- .minimum = 0,
- .maximum = 0xff,
- .step= 1,
- .default_value = 0x7f
- },
- .set_control = set_cmatrix
- },
-[CONTRAST] = {
- {
- .id = V4L2_CID_CONTRAST,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Contrast,
- .minimum = 0,
- .maximum = 0xff,
- .step= 1,
- .default_value = 0x7f
- },
- .set_control = set_cmatrix
- },
-[SATURATION] = {
- {
- .id = V4L2_CID_SATURATION,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Saturation,
- .minimum = 0,
- .maximum = 0xff,
- .step= 1,
- .default_value = 0x7f
- },
- .set_control = set_cmatrix
- },
-[HUE] = {
- {
- .id = V4L2_CID_HUE,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Hue,
- .minimum = -180,
- .maximum = 180,
- .step= 1,
- .default_value = 0
- },
- .set_control = set_cmatrix
- },
-[GAMMA] = {
- {
- .id = V4L2_CID_GAMMA,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Gamma,
- .minimum = 0,
- .maximum = 0xff,
- .step= 1,
- .default_value = 0x10
- },
- .set_control = set_gamma
- },
-[BLUE] = {
- {
- .id = V4L2_CID_BLUE_BALANCE,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Blue Balance,
- .minimum = 0,
- .maximum = 0x7f,
- .step= 1,
- .default_value = 0x28
- },
- .set_control = set_redblue
- },
-[RED] = {
- {
- .id = V4L2_CID_RED_BALANCE,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Red Balance,
- .minimum = 0,
- .maximum = 0x7f,
-
[RFCv1 PATCH 4/7] gspca: use video_drvdata(file) instead of file-private_data.
From: Hans Verkuil hans.verk...@cisco.com
Prepare for control events: free up file-private_data by using
video_drvdata(file) to get to the gspca_dev struct.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/gspca/gspca.c | 64 ++---
1 file changed, 31 insertions(+), 33 deletions(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 56dff10..5c1b53e 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1061,7 +1061,7 @@ static int vidioc_g_register(struct file *file, void
*priv,
struct v4l2_dbg_register *reg)
{
int ret;
- struct gspca_dev *gspca_dev = priv;
+ struct gspca_dev *gspca_dev = video_drvdata(file);
if (!gspca_dev-sd_desc-get_chip_ident)
return -EINVAL;
@@ -1085,7 +1085,7 @@ static int vidioc_s_register(struct file *file, void
*priv,
struct v4l2_dbg_register *reg)
{
int ret;
- struct gspca_dev *gspca_dev = priv;
+ struct gspca_dev *gspca_dev = video_drvdata(file);
if (!gspca_dev-sd_desc-get_chip_ident)
return -EINVAL;
@@ -1110,7 +1110,7 @@ static int vidioc_g_chip_ident(struct file *file, void
*priv,
struct v4l2_dbg_chip_ident *chip)
{
int ret;
- struct gspca_dev *gspca_dev = priv;
+ struct gspca_dev *gspca_dev = video_drvdata(file);
if (!gspca_dev-sd_desc-get_chip_ident)
return -EINVAL;
@@ -1130,7 +1130,7 @@ static int vidioc_g_chip_ident(struct file *file, void
*priv,
static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_fmtdesc *fmtdesc)
{
- struct gspca_dev *gspca_dev = priv;
+ struct gspca_dev *gspca_dev = video_drvdata(file);
int i, j, index;
__u32 fmt_tb[8];
@@ -1172,7 +1172,7 @@ static int vidioc_enum_fmt_vid_cap(struct file *file,
void *priv,
static int vidioc_g_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *fmt)
{
- struct gspca_dev *gspca_dev = priv;
+ struct gspca_dev *gspca_dev = video_drvdata(file);
int mode;
mode = gspca_dev-curr_mode;
@@ -1217,7 +1217,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file,
void *priv,
struct v4l2_format *fmt)
{
- struct gspca_dev *gspca_dev = priv;
+ struct gspca_dev *gspca_dev = video_drvdata(file);
int ret;
ret = try_fmt_vid_cap(gspca_dev, fmt);
@@ -1229,7 +1229,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file,
static int vidioc_s_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *fmt)
{
- struct gspca_dev *gspca_dev = priv;
+ struct gspca_dev *gspca_dev = video_drvdata(file);
int ret;
if (mutex_lock_interruptible(gspca_dev-queue_lock))
@@ -1268,7 +1268,7 @@ out:
static int vidioc_enum_framesizes(struct file *file, void *priv,
struct v4l2_frmsizeenum *fsize)
{
- struct gspca_dev *gspca_dev = priv;
+ struct gspca_dev *gspca_dev = video_drvdata(file);
int i;
__u32 index = 0;
@@ -1294,7 +1294,7 @@ static int vidioc_enum_framesizes(struct file *file, void
*priv,
static int vidioc_enum_frameintervals(struct file *filp, void *priv,
struct v4l2_frmivalenum *fival)
{
- struct gspca_dev *gspca_dev = priv;
+ struct gspca_dev *gspca_dev = video_drvdata(filp);
int mode = wxh_to_mode(gspca_dev, fival-width, fival-height);
__u32 i;
@@ -1333,10 +1333,9 @@ static void gspca_release(struct video_device *vfd)
static int dev_open(struct file *file)
{
- struct gspca_dev *gspca_dev;
+ struct gspca_dev *gspca_dev = video_drvdata(file);
PDEBUG(D_STREAM, [%s] open, current-comm);
- gspca_dev = (struct gspca_dev *) video_devdata(file);
if (!gspca_dev-present)
return -ENODEV;
@@ -1344,7 +1343,6 @@ static int dev_open(struct file *file)
if (!try_module_get(gspca_dev-module))
return -ENODEV;
- file-private_data = gspca_dev;
#ifdef GSPCA_DEBUG
/* activate the v4l2 debug */
if (gspca_debug D_V4L2)
@@ -1359,7 +1357,7 @@ static int dev_open(struct file *file)
static int dev_close(struct file *file)
{
- struct gspca_dev *gspca_dev = file-private_data;
+ struct gspca_dev *gspca_dev = video_drvdata(file);
PDEBUG(D_STREAM, [%s] close, current-comm);
if (mutex_lock_interruptible(gspca_dev-queue_lock))
@@ -1375,7 +1373,6 @@ static int dev_close(struct file *file)
}
frame_free(gspca_dev);
}
- file-private_data = NULL;
module_put(gspca_dev-module);
[RFCv1 PATCH 6/7] gspca: add support for control events.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/gspca/gspca.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 3d3b780..7b03f36 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -40,6 +40,7 @@
#include media/v4l2-ioctl.h
#include media/v4l2-ctrls.h
#include media/v4l2-fh.h
+#include media/v4l2-event.h
#include gspca.h
@@ -2158,6 +2159,7 @@ static unsigned int dev_poll(struct file *file,
poll_table *wait)
ret = POLLIN | POLLRDNORM; /* yes */
else
ret = 0;
+ ret |= v4l2_ctrl_poll(file, wait);
mutex_unlock(gspca_dev-queue_lock);
if (!gspca_dev-present)
return POLLHUP;
@@ -2269,6 +2271,8 @@ static const struct v4l2_ioctl_ops dev_ioctl_ops = {
.vidioc_s_register = vidioc_s_register,
#endif
.vidioc_g_chip_ident= vidioc_g_chip_ident,
+ .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
static const struct video_device gspca_template = {
--
1.7.10
--
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
[RFCv1 PATCH 5/7] gscpa: use v4l2_fh and add G/S_PRIORITY support.
From: Hans Verkuil hans.verk...@cisco.com
In order to support control event gspca has to use struct v4l2_fh.
As a bonus feature this also gives priority handling for free.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/gspca/gspca.c | 13 ++---
drivers/media/video/gspca/gspca.h |2 ++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 5c1b53e..3d3b780 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -39,6 +39,7 @@
#include linux/ktime.h
#include media/v4l2-ioctl.h
#include media/v4l2-ctrls.h
+#include media/v4l2-fh.h
#include gspca.h
@@ -1327,6 +1328,7 @@ static void gspca_release(struct video_device *vfd)
video_device_node_name(gspca_dev-vdev));
v4l2_ctrl_handler_free(gspca_dev-vdev.ctrl_handler);
+ v4l2_device_unregister(gspca_dev-v4l2_dev);
kfree(gspca_dev-usb_buf);
kfree(gspca_dev);
}
@@ -1352,7 +1354,7 @@ static int dev_open(struct file *file)
gspca_dev-vdev.debug = ~(V4L2_DEBUG_IOCTL
| V4L2_DEBUG_IOCTL_ARG);
#endif
- return 0;
+ return v4l2_fh_open(file);
}
static int dev_close(struct file *file)
@@ -1378,7 +1380,7 @@ static int dev_close(struct file *file)
PDEBUG(D_STREAM, close done);
- return 0;
+ return v4l2_fh_release(file);
}
static int vidioc_querycap(struct file *file, void *priv,
@@ -2345,12 +2347,16 @@ int gspca_dev_probe2(struct usb_interface *intf,
}
}
+ ret = v4l2_device_register(intf-dev, gspca_dev-v4l2_dev);
+ if (ret)
+ goto out;
gspca_dev-sd_desc = sd_desc;
gspca_dev-nbufread = 2;
gspca_dev-empty_packet = -1; /* don't check the empty packets */
gspca_dev-vdev = gspca_template;
- gspca_dev-vdev.parent = intf-dev;
+ gspca_dev-vdev.v4l2_dev = gspca_dev-v4l2_dev;
video_set_drvdata(gspca_dev-vdev, gspca_dev);
+ set_bit(V4L2_FL_USE_FH_PRIO, gspca_dev-vdev.flags);
gspca_dev-module = module;
gspca_dev-present = 1;
@@ -2458,6 +2464,7 @@ void gspca_disconnect(struct usb_interface *intf)
/* the device is freed at exit of this function */
gspca_dev-dev = NULL;
+ v4l2_device_disconnect(gspca_dev-v4l2_dev);
mutex_unlock(gspca_dev-usb_lock);
usb_set_intfdata(intf, NULL);
diff --git a/drivers/media/video/gspca/gspca.h
b/drivers/media/video/gspca/gspca.h
index 589009f..2aacfa3 100644
--- a/drivers/media/video/gspca/gspca.h
+++ b/drivers/media/video/gspca/gspca.h
@@ -6,6 +6,7 @@
#include linux/usb.h
#include linux/videodev2.h
#include media/v4l2-common.h
+#include media/v4l2-device.h
#include linux/mutex.h
/* compilation option */
@@ -158,6 +159,7 @@ struct gspca_frame {
struct gspca_dev {
struct video_device vdev; /* !! must be the first item */
struct module *module; /* subdriver handling the device */
+ struct v4l2_device v4l2_dev;
struct usb_device *dev;
struct file *capt_file; /* file doing video capture */
#if defined(CONFIG_INPUT) || defined(CONFIG_INPUT_MODULE)
--
1.7.10
--
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] [media] ngene: remove an unneeded condition
On Sat, Apr 28, 2012 at 04:57:35PM +0200, walter harms wrote: Am 20.04.2012 15:15, schrieb Dan Carpenter: stat is always zero here. The condition used to be needed, but we shifted stuff around in 0f0b270f90 [media] ngene: CXD2099AR Common Interface driver. This doesn't change how the code works, it's just a bit tidier. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/media/dvb/ngene/ngene-core.c b/drivers/media/dvb/ngene/ngene-core.c index f129a93..3985738 100644 --- a/drivers/media/dvb/ngene/ngene-core.c +++ b/drivers/media/dvb/ngene/ngene-core.c @@ -1409,10 +1409,8 @@ static int ngene_start(struct ngene *dev) if (stat 0) goto fail; - if (!stat) - return stat; + return 0; - /* otherwise error: fall through */ fail: ngwritel(0, NGENE_INT_ENABLE); free_irq(dev-pci_dev-irq, dev); it seems more logical to use the positive exit in this case like: if (stat =0) return 0; instead of jumping over return 0: I would say it's more readable to handle the error condition as a special case instead of handling the normal success case as special. It's better to be consistent instead of changing back and forth: if (error condition) return ret; if (error condition) return ret; if (success conditi) return ret; if (error condition) return ret; regards, dan carpenter -- 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: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Apr 28 19:00:19 CEST 2012 git hash:bcb2cf6e0bf033d79821c89e5ccb328bfbd44907 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS 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-3.0-i686: OK linux-3.1-i686: OK linux-3.2.1-i686: OK linux-3.3-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS 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 linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS 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
Re: HVR-1600 QAM recordings with slight glitches in them
On 12-04-28 10:56 AM, Andy Walls wrote: grepping out the 0 lines doesn't let one see the trends in Signal to Noise Ratio (SNR) before and after the uncorrectable (unc) block counts. OK. I have completely reworked the way I use femon. I now start/stop femon along with recordings so I should have a separate femon output for each recording (using Mythtv system events and a couple of recording start/stop scripts, fwiw). So I see SNR values from 0x138 to 0x13c ( 31.2 dB to 31.6 dB ) when you have problems. For 256-QAM cable signals, I think that is considered marginal. OK. Good to know. (Can someone else with 256-QAM North American cable please confirm? I only have OTA) Would be great if somebody can. Thanks in advance. When you have no errors, what is the SNR? I'm guessing there are no large swings. From what I recall of the data, no, the SNR was pretty much the same throughout good and bad periods of the recordings. But with my configuration here, we will know for sure soon enough. Hard to tell, given that one of the other digital sub-channels may have been effected and not visible on the channel you were recording. Ahhh. I see. I normally watch DTV live with mplayer, and also have femon open in another window, when performing this sort of test. That's effectively what I am doing with my recordings. When a recording starts, an femon starts and logs. When the recording is done I use mplayer (-nosound -vo null -benchmark, just to make it run as fast as possible) and prune out the per frame counters so that what I am left with is the bits that mplayer complains about in the stream along with the frame count it happened at. The femon output is also included for cross reference. A video or audio glitch, 1 or 2 seconds after a non-zero uncorrectable block count, is usually a good indicator of correlation. That's what I will look for. Well, not the best performer from what I hear. Indeed. I don't have any of these problems with my HVR-950Q. This HVR-1600 was a really good deal though, so I can't totally complain. :-) Speaking of the HVR-950Q, does femon not work with it? I seem to always get zero values across the board trying. But certainly works just fine for many people in many contexts. Yes, and indeed, it works here for the most part even with small glitches some of the time. But some other times, the glitching is bad enough to make a recording more or less useless. OK. There are two ways to go here: 1. We assume your signal is marginal. Take a look here for things to check and fix if needed: http://ivtvdriver.org/index.php/Howto:Improve_signal_quality I will see what I can do with those. As a test, you you might also want to temporarily change your coax wiring setup to reduce the number of splits and connectors before the signal goes into the HVR-1600, and see if things are better. Indeed. That was at the top of my list also, so isolate the rest of the cable plant in here. Every 2-way splitter will drop 3-5 dB of signal. OK. So about splitters. Given that I'm in a house with 4 cable television runs to different rooms, plus a cable modem, plus 4 PVR tuner inputs (so yeah, 9 consumers), what is my best splitter plan/options. Probably ideally I want to split the incoming signal into two, one for the cable modem and one to feed the television consumers. Once I have the feed off to the televisions though, am I best trying to split that into 8, (i.e. equally with an 8-way splitter -- if that's even possible) or would I be better served with some more smaller splits in somewhat of a tree formation? I'm also assuming that all splitters are not of the same quality and that the dollar store ones are likely of inferior quality. But dollar store aside, even amongst reasonable retailers, how can I tell (without having to get all electronics geeky with an oscilliscope and whatnot) what's good and what's bad? Also, splitting 8 ways, am I into amplification/boosting territory or am I likely to just boost noise along with the signal? 2. We assume your signal is too strong, and that it is overdriving the MXL5005s digital tuner of the HVR-1600, causing problems for the CX24227 demodulator. Heh. I wonder if that could be possible given my description above. :-) Your corrective action here would be to attenuate the incoming RF signal with either an inline attenuator, or with additional, properly terminated, splitters. Indeed. Thanks so much for all of the input here. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: HVR-1600 QAM recordings with slight glitches in them
One more question... On 12-04-28 10:56 AM, Andy Walls wrote: So I see SNR values from 0x138 to 0x13c ( 31.2 dB to 31.6 dB ) when you have problems. For 256-QAM cable signals, I think that is considered marginal. I've never gotten my mind around SNRs and dBs, etc. Generally speaking, am I looking for these snr values to go up or down (i.e. closer to 0 or further away) to make my signal better? Cheers, b. signature.asc Description: OpenPGP digital signature
[ 3960.758784] 1 lock held by motion/7776: [ 3960.758788] #0: (queue-mutex){......}, at: [ffffffff815c62d2] uvc_queue_enable+0x32/0xc0
Hi,
I'm using a webcam (logitech) supported by the uvcvideo module to capture video.
Previously once in a while I would get the uvcvideo: Failed to resubmit video
URB (-27)., but the grabbing continued without a problem.
Now the video grabbing program (motion) seems to lock due to some nested lock
if i interpret it right.
Additional problem is that i don't really know what kernel version was still
OK, so can't help with that info.
This is on a vanilla 3.4 RC kernel latest commit:
c629eaf8392b676b4f83c3dc344e66402bfeec92
--
Sander
[ 3696.753490] ehci_hcd :09:00.1: request 880016091400 would overflow
(3923+31 = 3936)
[ 3696.753494] uvcvideo: Failed to resubmit video URB (-27).
[ 3696.753563] ehci_hcd :09:00.1: request 880016091800 would overflow
(3922+31 = 3936)
[ 3696.753566] uvcvideo: Failed to resubmit video URB (-27).
[ 3696.753609] ehci_hcd :09:00.1: request 880016090800 would overflow
(3922+31 = 3936)
[ 3696.753611] uvcvideo: Failed to resubmit video URB (-27).
[ 3696.753645] ehci_hcd :09:00.1: request 880016090c00 would overflow
(3922+31 = 3936)
[ 3696.753647] uvcvideo: Failed to resubmit video URB (-27).
[ 3696.753656] ehci_hcd :09:00.1: request 880016091000 would overflow
(3922+31 = 3936)
[ 3696.753657] uvcvideo: Failed to resubmit video URB (-27).
[ 3960.758154] INFO: task motion:7776 blocked for more than 120 seconds.
[ 3960.758168] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this
message.
[ 3960.758174] motion D 0201 0 7776 1 0x
[ 3960.758183] 8800239d9b68 0216 eaa50018
810a451b
[ 3960.758192] 88002392cf60 00012600 8800239d9fd8
8800239d8010
[ 3960.758200] 00012600 00012600 8800239d9fd8
00012600
[ 3960.758209] Call Trace:
[ 3960.758219] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 3960.758226] [814e0048] ? hub_suspend+0xf8/0x130
[ 3960.758232] [814f0024] ? usbdev_do_ioctl+0x194/0x1000
[ 3960.758238] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 3960.758244] [8108ba01] ? get_parent_ip+0x11/0x50
[ 3960.758250] [8108d6cd] ? sub_preempt_count+0x9d/0xd0
[ 3960.758257] [815c02d2] ? hdpvr_probe+0x6c2/0xa30
[ 3960.758264] [817f8e84] schedule+0x24/0x70
[ 3960.758269] [817f9363] schedule_preempt_disabled+0x13/0x20
[ 3960.758275] [817f77c7] mutex_lock_nested+0x1a7/0x420
[ 3960.758281] [815c62d2] ? uvc_queue_enable+0x32/0xc0
[ 3960.758287] [815c62d2] uvc_queue_enable+0x32/0xc0
[ 3960.758292] [815c941f] uvc_video_enable+0x12f/0x180
[ 3960.758298] [815c7b55] uvc_v4l2_do_ioctl+0x555/0x1190
[ 3960.758304] [816c5668] ? sock_update_classid+0xa8/0x120
[ 3960.758310] [816c1d7e] ? sock_sendmsg+0xee/0x120
[ 3960.758316] [81561996] video_usercopy+0x186/0x4c0
[ 3960.758322] [815c7600] ? uvc_v4l2_set_streamparm+0x190/0x190
[ 3960.758327] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 3960.758333] [810a559f] ? lock_release+0xff/0x210
[ 3960.758338] [8108ba01] ? get_parent_ip+0x11/0x50
[ 3960.758344] [815c6bc4] uvc_v4l2_ioctl+0x24/0x70
[ 3960.758349] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 3960.758740] [8116e474] ? fsnotify+0x84/0x360
[ 3960.758745] [81560850] v4l2_ioctl+0xb0/0x180
[ 3960.758751] [81145213] do_vfs_ioctl+0x93/0x500
[ 3960.758756] [810a559f] ? lock_release+0xff/0x210
[ 3960.758762] [81134ba7] ? fget_light+0xd7/0x140
[ 3960.758768] [81134b0b] ? fget_light+0x3b/0x140
[ 3960.758773] [811456ca] sys_ioctl+0x4a/0x80
[ 3960.758778] [817fb0f9] system_call_fastpath+0x16/0x1b
[ 3960.758784] 1 lock held by motion/7776:
[ 3960.758788] #0: (queue-mutex){..}, at: [815c62d2]
uvc_queue_enable+0x32/0xc0
[ 4080.758504] INFO: task motion:7776 blocked for more than 120 seconds.
[ 4080.758518] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this
message.
[ 4080.758524] motion D 0201 0 7776 1 0x
[ 4080.758532] 8800239d9b68 0216 eaa50018
810a451b
[ 4080.758540] 88002392cf60 00012600 8800239d9fd8
8800239d8010
[ 4080.758547] 00012600 00012600 8800239d9fd8
00012600
[ 4080.758555] Call Trace:
[ 4080.758564] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 4080.758570] [814e0048] ? hub_suspend+0xf8/0x130
[ 4080.758576] [814f0024] ? usbdev_do_ioctl+0x194/0x1000
[ 4080.758581] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 4080.758587] [8108ba01] ? get_parent_ip+0x11/0x50
[ 4080.758592] [8108d6cd] ? sub_preempt_count+0x9d/0xd0
[ 4080.758597] [815c02d2] ? hdpvr_probe+0x6c2/0xa30
[ 4080.758603] [817f8e84] schedule+0x24/0x70
[ 4080.758608] [817f9363]
Re: HVR-1600 QAM recordings with slight glitches in them
On 12-04-28 02:36 PM, Brian J. Murrell wrote: One more question... And to answer my own question, and provide some more data... I've never gotten my mind around SNRs and dBs, etc. Generally speaking, am I looking for these snr values to go up or down (i.e. closer to 0 or further away) to make my signal better? Clearly, bigger numbers are better. When I hook my HVR-1600 directly up to the cable connection coming into the house with a 25 foot cable and a barrel connector the SNR goes up to 148 (32.8 dB) so that's my ceiling. I can't leave it hooked up like this for anything more than a few minutes so I can't be sure that's a high enough SNR for me to get perfect recordings every time. If I add one two way splitter to the incoming cable with one feed going off to my cable modem and one to the HVR-1600, the SNR drops to 145 (32.5 dB). But again, I can't really leave it like that for too long. so splitting that leg of the 2-way split 3 more times through a 3 way splitter reduces the SNR at the HVR-1600 to between 142 and 145 (32.2 - 32.5 dB). I typically have one more splitter downstream from that 3 way splitter which is a 4 way splitter to feed all of the tuners on my Mythtv box and introducing that splitter reduces the SNR at the HVR-1600 to between 13c and 13e (31.6 - 31.8 dB). I have no idea where in these range of values acceptable is though. Given that the HVR-1600 seems to be more sensitive to signal quality that just about anything else in here, I suppose I could feed it more directly from a split closer to the source signal. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: video capture driver interlacing question (easycap)
Hi Ezequiel On Sat, 28 Apr 2012, Ezequiel García wrote: On Thu, Apr 26, 2012 at 5:33 PM, Ezequiel García elezegar...@gmail.com wrote: Hi everyone, As you may know I'm re-writing from scratch the staging/easycap driver. Finally, after digging through the labyrinthic staging/easycap code, I've reached a point where I'm able to understand isoc packets. Despite not having any documentation (I asked several times) from chip vendor, I can separate packets in odd and even. So, instead of receiving frames the device is sending me fields, right? My doubt now is this: * Do I have to *merge* this pair of fields for each frame, or can I give it to v4l? If affirmative: how should I *merge* them? * Is this related to multiplanar buffers (should I use vb2_plane_addr)? Currently, staging/easycap does some strange and complex conversion, from the pair of fields buffers, to get a frame buffer (!) but I'm not sure if it's the correct way to do it? I guess I can keep staring at em28xx (together with vivi/uvc/pwc) driver, but if someone cares to give me a small hint or point me at a small portion of code I'll be grateful. Thanks, Ezequiel. Anyone? This might help: http://linuxtv.org/downloads/v4l-dvb-apis/field-order.html i.e., no, you should not merge fields in the driver, IIRC, you just hand them over to the user in separate buffers. Thanks Guennadi --- 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: HVR-1600 QAM recordings with slight glitches in them
On Sat, 2012-04-28 at 14:08 -0400, Brian J. Murrell wrote: On 12-04-28 10:56 AM, Andy Walls wrote: OK. There are two ways to go here: 1. We assume your signal is marginal. Take a look here for things to check and fix if needed: http://ivtvdriver.org/index.php/Howto:Improve_signal_quality I will see what I can do with those. As a test, you you might also want to temporarily change your coax wiring setup to reduce the number of splits and connectors before the signal goes into the HVR-1600, and see if things are better. Indeed. That was at the top of my list also, so isolate the rest of the cable plant in here. Every 2-way splitter will drop 3-5 dB of signal. OK. So about splitters. Given that I'm in a house with 4 cable television runs to different rooms, plus a cable modem, plus 4 PVR tuner inputs (so yeah, 9 consumers), what is my best splitter plan/options. Probably ideally I want to split the incoming signal into two, one for the cable modem and one to feed the television consumers. Assuming ideal splitters: a 2 way split is a 3 dB signal loss for each leg a 4 way split is a 6 dB signal loss for each leg an 8 way split is a 9 dB signal loss for each leg Signal losses in dB are additive. So for example, a device downstream from a 2-way split and then 4 way split, experiences a minimum of 9 dB of signal loss. Once I have the feed off to the televisions though, am I best trying to split that into 8, (i.e. equally with an 8-way splitter -- if that's even possible) or would I be better served with some more smaller splits in somewhat of a tree formation? With ideal splitters and perfect cable connections, it wouldn't matter. With real-life splitters and cable connectors, the fewer the devices and cable connections you use, the better. I'm also assuming that all splitters are not of the same quality and that the dollar store ones are likely of inferior quality. But dollar store aside, even amongst reasonable retailers, how can I tell (without having to get all electronics geeky with an oscilliscope and whatnot) what's good and what's bad? When looking for splitters as a consumer, you need to ensure frequency range of the splitter covers your needed range. Splitters for terrestrial OTA broadcasts only need to pass signals to about 900 MHz. Splitters for satellite TV need to pass signals to around 2300 MHz (2.3 GHz) or so. For cable you will need to pass signals up to about 1000 MHz (1.0 GHz). You shouldn't woory about splitter performance variabtions on the order of 1 or 2 dB. You can compensate for that with a distribution amplifier and better quality cable and connectors. BTW, I have in the past purchased a brand name, somewhat expensive, 4 way splitter from a Lowes hardware store, only to find one of the outputs didn't pass any signal - it was broken. :( Also, splitting 8 ways, am I into amplification/boosting territory or am I likely to just boost noise along with the signal? Yes you will be amplifying the incoming noise. But you've got to do something to preserve SNR against cable plant losses, which degrade signal but don't reduce noise. Put any distribution amplifier you purchase, as close to where the signal comes into your home as possible. Make sure it is a low noise amplifier. Variable gain is a nice feature, to avoid overdriving your components. BTW, the noise figure of a receiving system (your cable plant and tuners) is dominated by the Noise Figure of it's first amplification stage: http://en.wikipedia.org/wiki/Friis_formulas_for_noise A good, low noise, distribution amplifier can go a long way to helping eliminate other problems. Don't skimp; pay the money for a decent one. Also, you must take steps to reduce other losses and stop signal reflections: good cable, good cable connections, and properly terminate every split/leg. One missing or bad termination results in signal reflections (i.e. additional noise) in your entire cable plant. 2. We assume your signal is too strong, and that it is overdriving the MXL5005s digital tuner of the HVR-1600, causing problems for the CX24227 demodulator. Heh. I wonder if that could be possible given my description above. :-) Probably not. :) Your corrective action here would be to attenuate the incoming RF signal with either an inline attenuator, or with additional, properly terminated, splitters. Indeed. Thanks so much for all of the input here. No problem. Regards, Andy -- 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: HVR-1600 QAM recordings with slight glitches in them
On Sat, 2012-04-28 at 14:36 -0400, Brian J. Murrell wrote: One more question... On 12-04-28 10:56 AM, Andy Walls wrote: So I see SNR values from 0x138 to 0x13c ( 31.2 dB to 31.6 dB ) when you have problems. For 256-QAM cable signals, I think that is considered marginal. I've never gotten my mind around SNRs and dBs, etc. Generally speaking, am I looking for these snr values to go up or down (i.e. closer to 0 or further away) to make my signal better? Higher SNR is better: Higher SNR = lower probability of bit errors Lower SNR = higher probability of bit errors SNR in dB = 10 log (S/N) S : Received signal power in Watts N : Noise power at measurement point in Watts A logarithmic scale (dB) is used to express the quantities in values that are easier for people to comprehend and deal with. Gains and losses in dB are additive. -3 dB corresponds to a drop by a factor of 1/2: 10 * log(1/2) = -3.01 +3 dB corresponds to a gain by a factor of 2:10 * log(2) = 3.01 Regards, Andy Cheers, b. -- 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: HVR-1600 QAM recordings with slight glitches in them
On 12-04-28 04:39 PM, Brian J. Murrell wrote: I typically have one more splitter downstream from that 3 way splitter which is a 4 way splitter to feed all of the tuners on my Mythtv box and introducing that splitter reduces the SNR at the HVR-1600 to between 13c and 13e (31.6 - 31.8 dB). Interestingly enough, I moved the Myth backend to it's usual home, in the basement, right next to the incoming cable signal and replaced that 25' run that I had going to where it was temporarily with a smaller, say 10' run (of RG-59 so still room for improvement) and my SNR at the HVR-1600, even after all of the splitters is now 015c or 34.8 dB. I'm still going to go replacing all of that RG-59 with shorter, custom made lengths of RG6 cables. I can't go too short when making those can I or would even a 6-12 inch cable be perfectly fine? I'm thinking of the runs between that last 4 way splitter and the tuners in the Myth backend. b. signature.asc Description: OpenPGP digital signature
