Re: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly
On Sunday 07 June 2009 00:20:26 Jon Smirl wrote:
On Sat, Jun 6, 2009 at 9:00 AM, Hans Verkuilhverk...@xs4all.nl wrote:
Hi all,
For video4linux we sometimes need to probe for a single i2c address.
Normally you would do it like this:
Why does video4linux need to probe to find i2c devices? Can't the
address be determined by knowing the PCI ID of the board?
There are two reasons we need to probe: it is either because when the board
was added no one bothered to record which chip was on what address (this
happened in particular with old drivers like bttv) or because there is
simply no other way to determine the presence or absence of an i2c device.
E.g. there are three versions of one card: without upd64083 (Y/C separation
device) and upd64031a (ghost reduction device), with only the upd64031a and
one with both. Since they all have the same PCI ID the only way to
determine the model is to probe.
Regards,
Hans
static const unsigned short addrs[] = {
addr, I2C_CLIENT_END
};
client = i2c_new_probed_device(adapter, info, addrs);
This is a bit awkward and I came up with this macro:
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
This can construct a list of one or more i2c addresses on the fly. But
this is something that really belongs in i2c.h, renamed to I2C_ADDRS.
With this macro we can just do:
client = i2c_new_probed_device(adapter, info, I2C_ADDRS(addr));
Comments?
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: [PATCHv5 1 of 8] v4l2_subdev i2c: Add v4l2_i2c_new_subdev_board i2c helper function
On Saturday 06 June 2009 22:40:21 Eduardo Valentin wrote:
Hi Hans,
On Sat, Jun 6, 2009 at 8:09 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Saturday 06 June 2009 14:49:46 Hans Verkuil wrote:
On Saturday 06 June 2009 13:59:19 Hans Verkuil wrote:
On Friday 29 May 2009 09:33:21 Eduardo Valentin wrote:
# HG changeset patch
# User Eduardo Valentin eduardo.valen...@nokia.com
# Date 1243414605 -10800
# Branch export
# Node ID 4fb354645426f8b187c2c90cd8528b2518461005
# Parent 142fd6020df3b4d543068155e49a2618140efa49
Device drivers of v4l2_subdev devices may want to have
board specific data. This patch adds an helper function
to allow bridge drivers to pass board specific data to
v4l2_subdev drivers.
For those drivers which need to support kernel versions
bellow 2.6.26, a .s_config callback was added. The
idea of this callback is to pass board configuration
as well. In that case, subdev driver should set .s_config
properly, because v4l2_i2c_new_subdev_board will call
the .s_config directly. Of course, if we are = 2.6.26,
the same data will be passed through i2c board info as well.
Hi Eduardo,
I finally had some time to look at this. After some thought I
realized that the main problem is really that the API is becoming
quite messy. Basically there are 9 different ways of loading and
initializing a subdev:
First there are three basic initialization calls: no
initialization, passing irq and platform_data, and passing the
i2c_board_info struct directly (preferred for drivers that don't
need pre-2.6.26 compatibility).
And for each flavor you would like to see three different versions
as well: one with a fixed known i2c address, one where you probe
for a list of addresses, and one where you can probe for a single
i2c address.
I propose to change the API as follows:
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device
*v4l2_dev, struct i2c_adapter *adapter,
const char *module_name, const char *client_type,
u8 addr, const unsigned short *addrs);
struct v4l2_subdev *v4l2_i2c_new_subdev_cfg(struct v4l2_device
*v4l2_dev, struct i2c_adapter *adapter,
const char *module_name, const char *client_type,
int irq, void *platform_data,
u8 addr, const unsigned short *addrs);
/* Only available for kernels = 2.6.26 */
struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device
*v4l2_dev, struct i2c_adapter *adapter, const char *module_name,
struct i2c_board_info *info, const unsigned short *addrs);
If you use a fixed address, then only set addr (or info.addr) and
set addrs to NULL. If you want to probe for a list of addrs, then
set addrs to the list of addrs. If you want to probe for a single
addr, then use V4L2_I2C_ADDRS(addr) as the addrs argument. This
constructs an array with just two entries. Actually, this macro can
also create arrays with more entries.
Note that v4l2_i2c_new_subdev will be an inline that calls
v4l2_i2c_new_subdev_cfg with 0, NULL for the irq and platform_data.
And for kernels = 2.6.26 v4l2_i2c_new_subdev_cfg can be an inline
calling v4l2_i2c_new_subdev_board.
This approach reduces the number of functions to just one (not
counting the inlines) and simplifies things all around. It does
mean that all sources need to be changed, but if we go this route,
then now is the time before the 2.6.31 window is closed. And I
would also like to remove the '_new' from these function names. I
never thought it added anything useful.
Comments? If we decide to go this way, then I need to know soon so
that I can make the changes before the 2.6.31 window closes.
BTW, if the new s_config subdev call is present, then it should
always be called. That way the subdev driver can safely do all of
its initialization in s_config, no matter how it was initialized.
Sorry about the long delay in replying to this: it's been very
hectic lately at the expense of my v4l-dvb work.
I've done the initial conversion to the new API (no _cfg or _board
version yet) in my ~hverkuil/v4l-dvb-subdev tree. It really
simplifies things and if nobody objects then I'd like to get this in
before 2.6.31.
I've added the new _cfg and _board fucntions as well in this tree. It
needs a bit of a cleanup before I can do a pull request (the last two
patches should be merged to one), but otherwise this is the code as I
think it should be:
/* Construct an I2C_CLIENT_END-terminated array of i2c addresses on the
fly */
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned
Hauppauge WinTV NOVA-S and DiseqC problem
Hello, It is not new problem, but because it is not fixed after 2.5 year, I must try to make focus to bugfix again. Problem on isl6421 driver is two types of LNB current limitation. Default type of current limitation is not possible use in combination wit DiseqC. Detail and patch for bug fix is here: http://www.linuxtv.org/pipermail/linux-dvb/2006-November/014567.html This patch is over 2.5year old, but still not integrated to sources. Problem is real, in DVBN forum exist many threads with this problem and when I try make google query for isl6421 dcl linux, it will return pages where this patch is known (over 1300 pages). Pages without solution for this problem is little bit more. Coul me somebody tell how to add this patch to official sources? Jiri -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly
On Sun, Jun 7, 2009 at 2:35 AM, Hans Verkuilhverk...@xs4all.nl wrote:
On Sunday 07 June 2009 00:20:26 Jon Smirl wrote:
On Sat, Jun 6, 2009 at 9:00 AM, Hans Verkuilhverk...@xs4all.nl wrote:
Hi all,
For video4linux we sometimes need to probe for a single i2c address.
Normally you would do it like this:
Why does video4linux need to probe to find i2c devices? Can't the
address be determined by knowing the PCI ID of the board?
There are two reasons we need to probe: it is either because when the board
was added no one bothered to record which chip was on what address (this
happened in particular with old drivers like bttv) or because there is
simply no other way to determine the presence or absence of an i2c device.
Unrecorded boards could be handled by adding a printk at driver init
time asking people to email you the needed information. Then remove
the printks as soon as you get the answer.
E.g. there are three versions of one card: without upd64083 (Y/C separation
device) and upd64031a (ghost reduction device), with only the upd64031a and
one with both. Since they all have the same PCI ID the only way to
determine the model is to probe.
Did they happen to change the subsystem device_id? There are two pairs
of PCI IDs on each card. Most of the time the subsystem vendor/device
isn't set.
Getting rid of the probes altogether is the most reliable solution.
There is probably a way to identify these boards more specifically
that you haven't discovered yet. PCI subsystem device ID is worth
checking.
Regards,
Hans
static const unsigned short addrs[] = {
addr, I2C_CLIENT_END
};
client = i2c_new_probed_device(adapter, info, addrs);
This is a bit awkward and I came up with this macro:
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
This can construct a list of one or more i2c addresses on the fly. But
this is something that really belongs in i2c.h, renamed to I2C_ADDRS.
With this macro we can just do:
client = i2c_new_probed_device(adapter, info, I2C_ADDRS(addr));
Comments?
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly
On Sun, Jun 7, 2009 at 9:25 AM, Jon Smirljonsm...@gmail.com wrote:
On Sun, Jun 7, 2009 at 2:35 AM, Hans Verkuilhverk...@xs4all.nl wrote:
On Sunday 07 June 2009 00:20:26 Jon Smirl wrote:
On Sat, Jun 6, 2009 at 9:00 AM, Hans Verkuilhverk...@xs4all.nl wrote:
Hi all,
For video4linux we sometimes need to probe for a single i2c address.
Normally you would do it like this:
Why does video4linux need to probe to find i2c devices? Can't the
address be determined by knowing the PCI ID of the board?
There are two reasons we need to probe: it is either because when the board
was added no one bothered to record which chip was on what address (this
happened in particular with old drivers like bttv) or because there is
simply no other way to determine the presence or absence of an i2c device.
Unrecorded boards could be handled by adding a printk at driver init
time asking people to email you the needed information. Then remove
the printks as soon as you get the answer.
E.g. there are three versions of one card: without upd64083 (Y/C separation
device) and upd64031a (ghost reduction device), with only the upd64031a and
one with both. Since they all have the same PCI ID the only way to
determine the model is to probe.
Did they happen to change the subsystem device_id? There are two pairs
of PCI IDs on each card. Most of the time the subsystem vendor/device
isn't set.
Example using lspci -vvv -nn
This is an Intel ICH8 but Dell as set in a subsystem id if 1028:01db
to indicate their custom use of the generic part.
00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus
Controller [8086:283e] (rev 02)
Subsystem: Dell Device [1028:01db]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Interrupt: pin C routed to IRQ 10
Region 0: Memory at dffdab00 (32-bit, non-prefetchable) [size=256]
Region 4: I/O ports at ece0 [size=32]
Kernel modules: i2c-i801
Getting rid of the probes altogether is the most reliable solution.
There is probably a way to identify these boards more specifically
that you haven't discovered yet. PCI subsystem device ID is worth
checking.
Regards,
Hans
static const unsigned short addrs[] = {
addr, I2C_CLIENT_END
};
client = i2c_new_probed_device(adapter, info, addrs);
This is a bit awkward and I came up with this macro:
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
This can construct a list of one or more i2c addresses on the fly. But
this is something that really belongs in i2c.h, renamed to I2C_ADDRS.
With this macro we can just do:
client = i2c_new_probed_device(adapter, info, I2C_ADDRS(addr));
Comments?
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
Jon Smirl
jonsm...@gmail.com
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly
On Sunday 07 June 2009 15:30:50 Jon Smirl wrote:
On Sun, Jun 7, 2009 at 9:25 AM, Jon Smirljonsm...@gmail.com wrote:
On Sun, Jun 7, 2009 at 2:35 AM, Hans Verkuilhverk...@xs4all.nl wrote:
On Sunday 07 June 2009 00:20:26 Jon Smirl wrote:
On Sat, Jun 6, 2009 at 9:00 AM, Hans Verkuilhverk...@xs4all.nl
wrote:
Hi all,
For video4linux we sometimes need to probe for a single i2c
address. Normally you would do it like this:
Why does video4linux need to probe to find i2c devices? Can't the
address be determined by knowing the PCI ID of the board?
There are two reasons we need to probe: it is either because when the
board was added no one bothered to record which chip was on what
address (this happened in particular with old drivers like bttv) or
because there is simply no other way to determine the presence or
absence of an i2c device.
Unrecorded boards could be handled by adding a printk at driver init
time asking people to email you the needed information. Then remove
the printks as soon as you get the answer.
It's rather unfeasible when you are dealing with dozens and dozens of cards.
We also know that there are variants of these cards out there where they
changed audio chips or tuner chips without changing anything. It's not a
big deal, that's why we have the i2c probing to solve these cases. Newer
drivers try to avoid probing wherever possible, of course.
E.g. there are three versions of one card: without upd64083 (Y/C
separation device) and upd64031a (ghost reduction device), with only
the upd64031a and one with both. Since they all have the same PCI ID
the only way to determine the model is to probe.
Did they happen to change the subsystem device_id? There are two pairs
of PCI IDs on each card. Most of the time the subsystem vendor/device
isn't set.
No, it's all the same. This is very common for the cheaper cards. They take
a reference design, modify it and never bother to change the IDs.
Regards,
Hans
Example using lspci -vvv -nn
This is an Intel ICH8 but Dell as set in a subsystem id if 1028:01db
to indicate their custom use of the generic part.
00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus
Controller [8086:283e] (rev 02)
Subsystem: Dell Device [1028:01db]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Interrupt: pin C routed to IRQ 10
Region 0: Memory at dffdab00 (32-bit, non-prefetchable) [size=256]
Region 4: I/O ports at ece0 [size=32]
Kernel modules: i2c-i801
Getting rid of the probes altogether is the most reliable solution.
There is probably a way to identify these boards more specifically
that you haven't discovered yet. PCI subsystem device ID is worth
checking.
Regards,
Hans
static const unsigned short addrs[] = {
addr, I2C_CLIENT_END
};
client = i2c_new_probed_device(adapter, info, addrs);
This is a bit awkward and I came up with this macro:
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END
})
This can construct a list of one or more i2c addresses on the fly.
But this is something that really belongs in i2c.h, renamed to
I2C_ADDRS.
With this macro we can just do:
client = i2c_new_probed_device(adapter, info, I2C_ADDRS(addr));
Comments?
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
Telecom --
To unsubscribe from this list: send the line unsubscribe
linux-i2c in the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
Jon Smirl
jonsm...@gmail.com
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: Probably strange bug with usb radio-mr800
Hello, On Sun, Jun 7, 2009 at 1:07 AM, Oliver Neukumoli...@neukum.org wrote: Am Freitag, 5. Juni 2009 00:43:04 schrieb Alexey Klimov: Is there any ideas about different behaviour of device on 32- and 64-bit platforms with the same usb bulk messages? Any input is welcome. Are you running a 32 bit userland? If so, ioctls could be critical. Two different machines. The answer is no. If not, the driver may not be 64bit clean. Which driver is affected? media/radio/radio-mr800.c Please, also take a look in my first letter to usb and v4l mail lists from May 27. -- Best regards, Klimov Alexey -- 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/pwc - use usb_interface as parent, not usb_device
Looks good, we recently fixed the same issue in the gspca driver to, Acked-by: Hans de Goede hdego...@redhat.com On 06/04/2009 09:18 PM, Lennart Poettering wrote: The current code creates a sysfs device path where the video4linux device is child of the usb device itself instead of the interface it belongs to. That is evil and confuses udev. This patch does basically the same thing as Kay's similar patch for the ov511 driver: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ce96d0a44a4f8d1bb3dc12b5e98cb688c1bc730d (Resent 2nd time, due to missing Signed-off-by) Lennart Signed-off-by: Lennart Poetteringmzxre...@0pointer.de --- drivers/media/video/pwc/pwc-if.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c index 7c542ca..92d4177 100644 --- a/drivers/media/video/pwc/pwc-if.c +++ b/drivers/media/video/pwc/pwc-if.c @@ -1783,7 +1783,7 @@ static int usb_pwc_probe(struct usb_interface *intf, const struct usb_device_id return -ENOMEM; } memcpy(pdev-vdev,pwc_template, sizeof(pwc_template)); - pdev-vdev-parent =(udev-dev); + pdev-vdev-parent =intf-dev; strcpy(pdev-vdev-name, name); video_set_drvdata(pdev-vdev, pdev); -- 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: webcam drivers and V4L2_MEMORY_USERPTR support
On 06/05/2009 09:43 AM, Stefan Kost wrote: Hans de Goede schrieb: On 06/01/2009 09:58 AM, Trent Piepho wrote: On Mon, 1 Jun 2009, Stefan Kost wrote: I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers v4l2src [1]. This allows to request shared memory buffers from xvideo, capture into those and therefore save a memcpy. This works great with the v4l2 driver on our embedded device. When I was testing this on my desktop, I noticed that almost no driver seems to support it. I tested zc0301 and uvcvideo, but also grepped the kernel driver sources. It seems that gspca might support it, but I ave not confirmed it. Is there a technical reason for it, or is it simply not implemented? userptr support is relatively new and so it has less support, especially with driver that pre-date it. Maybe USB cams use a compressed format and so userptr with xvideo would not work anyway since xv won't support the camera's native format. It certainly could be done for bt8xx, cx88, saa7134, etc. Even in the webcam with custom compressed format case, userptr support could be useful to safe a memcpy, as libv4l currently fakes mmap buffers, so what happens is: camdirect transfer mmap bufferlibv4l format conversion fake mmap buffer application-memcpy dest buffer So if libv4l would support userptr's (which it currently does not do) we could still safe a memcpy here. Do you mean that if a driver supports userptr and one uses libv4l instead of the direct ioctl, there is a regression and the app iuppo getting told only mmap works? Yes, this was done this way for simplicity's sake (libv4l2 is complex enough at is). At the time this decision was made it was an easy one to make as userptr support mostly was (and I believe still is) a paper excercise. Iow no applications and almost no drivers support it. If more applications start supporting it, support can and should be added to libv4l2. But this will be tricky. For higher pixels counts extra memcpy's are scary, especially if they are no visible. Sorry for the naive question, but what is libv4l role regarding buffer allocations? In ourcase we don't need any extra format conversion from libv4l. I am fine if it works without extra memcpy in that case and I understand that it would be tricky to support inplace formats conversions for some formats and extra memcpy for the rest. I would be willing to take *clean, non invasive* patches to libv4l to add userptr support, but I'm not sure if this can be done in a clean way (haven't tried). Where are the libv4l sources hosted. I found your blog and the freshmeat page only so far. The sources are part of the v4l-dvb mercurial tree. But the latest version is in my personal tree, please use that to base patches on: http://linuxtv.org/hg/~hgoede/libv4l 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
Fw: Broken link in get_dvb_firmware for nxt2004 (A180)
Jan,
Instead of v4l-dvb-maintainer and V4L ML, please send patches to
linux-media@vger.kernel.org, otherwise, patchwork won't catch it.
Forwarded message:
Date: Sun, 07 Jun 2009 14:42:15 +0200
From: Jan Ceuleers jan.ceule...@computer.org
To: mche...@infradead.org, v4l-dvb-maintai...@linuxtv.org,
video4linux-l...@redhat.com
Subject: Re: Broken link in get_dvb_firmware for nxt2004 (A180)
Errr... The patch was produced the wrong way around. Sorry about that.
Trying again.
Cheers,
Mauro
--- linux-2.6.29/Documentation/dvb/get_dvb_firmware.orig2009-06-07
14:38:20.0 +0200
+++ linux-2.6.29/Documentation/dvb/get_dvb_firmware 2009-06-07
14:38:55.0 +0200
@@ -317,7 +317,7 @@
sub nxt2004 {
my $sourcefile = AVerTVHD_MCE_A180_Drv_v1.2.2.16.zip;
-my $url = http://www.aver.com/support/Drivers/$sourcefile;;
+my $url = http://www.avermedia-usa.com/support/Drivers/$sourcefile;;
my $hash = 111cb885b1e009188346d72acfed024c;
my $outfile = dvb-fe-nxt2004.fw;
my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
[PATCH] saa7134: add support for AVerMedia M103 (f736)
Add 1461:f736 to the list of identifiers corresponding to the
SAA7134_BOARD_AVERMEDIA_M103 board. This patch adds support for
a variant of the AVerMedia M103 MiniPCI DVB-T Hybrid card.
Signed-off-by: Barry Kitson b.kit...@gmail.com
---
Documentation/video4linux/CARDLIST.saa7134 |2 +-
drivers/media/video/saa7134/saa7134-cards.c |6 ++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/video4linux/CARDLIST.saa7134
b/Documentation/video4linux/CARDLIST.saa7134
index b8d4705..fa16e6c 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -143,7 +143,7 @@
142 - Beholder BeholdTV H6 [5ace:6290]
143 - Beholder BeholdTV M63[5ace:6191]
144 - Beholder BeholdTV M6 Extra [5ace:6193]
-145 - AVerMedia MiniPCI DVB-T Hybrid M103 [1461:f636]
+145 - AVerMedia MiniPCI DVB-T Hybrid M103 [1461:f636,1461:f736]
146 - ASUSTeK P7131 Analog
147 - Asus Tiger 3in1 [1043:4878]
148 - Encore ENLTV-FM v5.3 [1a7f:2008]
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index e2febcd..0863c3e 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -5723,6 +5723,12 @@ struct pci_device_id saa7134_pci_tbl[] = {
}, {
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1461, /* Avermedia Technologies Inc */
+ .subdevice= 0xf736,
+ .driver_data = SAA7134_BOARD_AVERMEDIA_M103,
+ }, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
.subvendor= 0x1043,
.subdevice= 0x4878, /* REV:1.02G */
.driver_data = SAA7134_BOARD_ASUSTeK_TIGER_3IN1,
--
1.6.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Leadtek Winfast DTV-1000S
Dear Mike, Have not heard from you in quite some time, has there been any progress on getting this card up and running? As I said to you in a previous email it is extremely close using the settings for card #156, however it fails to detect any DVB-T channels, although the signal strength meter works while its scanning for them. I have not tried the FM component of the card. Here is lspci -vvv -nn output, 00:0e.0 Multimedia controller [0480]: Philips Semiconductors SAA7130 Video Broadcast Decoder [1131:7130] (rev 01) Subsystem: LeadTek Research Inc. Device [107d:6655] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (21000ns min, 8000ns max) Interrupt: pin A routed to IRQ 12 Region 0: Memory at eb001000 (32-bit, non-prefetchable) [size=1K] Capabilities: access denied For anyone else reading this card is a DVB-T and FM receiver using the SAA7130, TDA10048 and TDA18271. Please let me know if theres anything I can do to be of further assistance. Thanks, Brad Allen -- 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
Broken link in get_dvb_firmware for nxt2004 (A180)
Hi!
I read the following on the mythtv-users mailing list, and I'd just like to
make sure that you guys are aware of it as well.
The script get_dvb_firmware no longer works for obtaining the nxt2004 firmware
because AVer have reorganised their websites. The wanted file is now available
from the following URL:
http://www.avermedia-usa.com/support/Drivers/AVerTVHD_MCE_A180_Drv_v1.2.2.16.zip
The patch is therefore as follows (this is against 2.6.29; inlined and
attached).
Note that I don't subscribe to the mailing list.
Cheers, Jan
--- linux-2.6.29/Documentation/dvb/get_dvb_firmware.orig2009-06-07
14:38:20.0 +0200
+++ linux-2.6.29/Documentation/dvb/get_dvb_firmware 2009-06-07
14:38:55.0 +0200
@@ -317,7 +317,7 @@
sub nxt2004 {
my $sourcefile = AVerTVHD_MCE_A180_Drv_v1.2.2.16.zip;
-my $url = http://www.aver.com/support/Drivers/$sourcefile;;
+my $url = http://www.avermedia-usa.com/support/Drivers/$sourcefile;;
my $hash = 111cb885b1e009188346d72acfed024c;
my $outfile = dvb-fe-nxt2004.fw;
my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
--- linux-2.6.29/Documentation/dvb/get_dvb_firmware.orig2009-06-07
14:38:20.0 +0200
+++ linux-2.6.29/Documentation/dvb/get_dvb_firmware 2009-06-07
14:38:55.0 +0200
@@ -317,7 +317,7 @@
sub nxt2004 {
my $sourcefile = AVerTVHD_MCE_A180_Drv_v1.2.2.16.zip;
-my $url = http://www.aver.com/support/Drivers/$sourcefile;;
+my $url = http://www.avermedia-usa.com/support/Drivers/$sourcefile;;
my $hash = 111cb885b1e009188346d72acfed024c;
my $outfile = dvb-fe-nxt2004.fw;
my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Jun 7 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11929:5ed2a853b692 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-rc7-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc7-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc7-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc7-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc7-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc7-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc7-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-rc7-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc7): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Leadtek Winfast DTV-1000S
Hi, Am Sonntag, den 07.06.2009, 08:47 -0700 schrieb Brad Allen: Dear Mike, Have not heard from you in quite some time, has there been any progress on getting this card up and running? As I said to you in a previous email it is extremely close using the settings for card #156, however it fails to detect any DVB-T channels, although the signal strength meter works while its scanning for them. I have not tried the FM component of the card. Here is lspci -vvv -nn output, 00:0e.0 Multimedia controller [0480]: Philips Semiconductors SAA7130 Video Broadcast Decoder [1131:7130] (rev 01) Subsystem: LeadTek Research Inc. Device [107d:6655] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (21000ns min, 8000ns max) Interrupt: pin A routed to IRQ 12 Region 0: Memory at eb001000 (32-bit, non-prefetchable) [size=1K] Capabilities: access denied For anyone else reading this card is a DVB-T and FM receiver using the SAA7130, TDA10048 and TDA18271. Please let me know if theres anything I can do to be of further assistance. Thanks, Brad Allen for your information and for all others interested. Henry Wu did send modified saa7134 files with support for this card on Tuesday off list. Mike replied, that he will set up a test repository as soon he gets some time for doing so. The most noticeable difference to the Hauppauge card is, that it works in TS parallel mode. Please wait a little until Mike is done with his review and announces the card for testing here on the list. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly
On Sun, 2009-06-07 at 09:25 -0400, Jon Smirl wrote:
On Sun, Jun 7, 2009 at 2:35 AM, Hans Verkuilhverk...@xs4all.nl wrote:
On Sunday 07 June 2009 00:20:26 Jon Smirl wrote:
On Sat, Jun 6, 2009 at 9:00 AM, Hans Verkuilhverk...@xs4all.nl wrote:
Hi all,
For video4linux we sometimes need to probe for a single i2c address.
Normally you would do it like this:
Why does video4linux need to probe to find i2c devices? Can't the
address be determined by knowing the PCI ID of the board?
There are two reasons we need to probe: it is either because when the board
was added no one bothered to record which chip was on what address (this
happened in particular with old drivers like bttv) or because there is
simply no other way to determine the presence or absence of an i2c device.
Unrecorded boards could be handled by adding a printk at driver init
time asking people to email you the needed information. Then remove
the printks as soon as you get the answer.
E.g. there are three versions of one card: without upd64083 (Y/C separation
device) and upd64031a (ghost reduction device), with only the upd64031a and
one with both. Since they all have the same PCI ID the only way to
determine the model is to probe.
Did they happen to change the subsystem device_id? There are two pairs
of PCI IDs on each card. Most of the time the subsystem vendor/device
isn't set.
Getting rid of the probes altogether is the most reliable solution.
There is probably a way to identify these boards more specifically
that you haven't discovered yet. PCI subsystem device ID is worth
checking.
Jon,
This really is a well beaten topic for v4l-dvb devices.
1. Device IDs are used to identify the bridge chip.
2. Subsystem IDs are used to identify the specfic card.
3. Vendor provided serial EEPROMs (sitting at 8-bit I2C address 0xA0)
can provide some amplifying information about the board layout.
There is variation in the I2C peripherals used on a video card PCB per
any Subsystem ID. It's not a granular enough descriptor.
The data from serial EEPROMs, if the vendor was nice enough to even
include one, may not have a known decoding.
I agree that I2C probing is bad/undesirable. But for some video boards,
there is no other way than probing without each end user having expert
knowledge of the PCB layout.
Not probing, for cases where there is no other automated means to divine
the I2C devices used, would likely require an annoying or unsutainable
level of end user support be provided from a volunteer community.
Regards,
Andy
Regards,
Hans
static const unsigned short addrs[] = {
addr, I2C_CLIENT_END
};
client = i2c_new_probed_device(adapter, info, addrs);
This is a bit awkward and I came up with this macro:
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
This can construct a list of one or more i2c addresses on the fly. But
this is something that really belongs in i2c.h, renamed to I2C_ADDRS.
With this macro we can just do:
client = i2c_new_probed_device(adapter, info, I2C_ADDRS(addr));
Comments?
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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] bt8xx: Add support for the Conexant Fusion 878a / Twinhan VP 1025 DVB-S
Add fefe:0001 to the list of identifiers for the bt8xx driver. The chip is
named Conexant Fusion 878a, the card is a Twinhan VP 1025 DVB-S PCI.
Please commit the attached patch.
Thanks and best regards,
Michael
--- bt878.orig.c 2009-06-07 22:23:33.0 +0200
+++ bt878.c 2009-06-07 22:23:27.0 +0200
@@ -405,6 +405,7 @@
BROOKTREE_878_DEVICE(0x18ac, 0xd500, DViCO FusionHDTV 5 Lite),
BROOKTREE_878_DEVICE(0x7063, 0x2000, pcHDTV HD-2000 TV),
BROOKTREE_878_DEVICE(0x1822, 0x0026, DNTV Live! Mini),
+ BROOKTREE_878_DEVICE(0xfefe, 0x0001, Conexant Fusion / Twinhan VP 1025 DVB-S),
{ }
};
signature.asc
Description: Digital signature
Re: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly
Hi,
Am Sonntag, den 07.06.2009, 16:00 -0400 schrieb Andy Walls:
On Sun, 2009-06-07 at 09:25 -0400, Jon Smirl wrote:
On Sun, Jun 7, 2009 at 2:35 AM, Hans Verkuilhverk...@xs4all.nl wrote:
On Sunday 07 June 2009 00:20:26 Jon Smirl wrote:
On Sat, Jun 6, 2009 at 9:00 AM, Hans Verkuilhverk...@xs4all.nl wrote:
Hi all,
For video4linux we sometimes need to probe for a single i2c address.
Normally you would do it like this:
Why does video4linux need to probe to find i2c devices? Can't the
address be determined by knowing the PCI ID of the board?
There are two reasons we need to probe: it is either because when the
board
was added no one bothered to record which chip was on what address (this
happened in particular with old drivers like bttv) or because there is
simply no other way to determine the presence or absence of an i2c device.
Unrecorded boards could be handled by adding a printk at driver init
time asking people to email you the needed information. Then remove
the printks as soon as you get the answer.
E.g. there are three versions of one card: without upd64083 (Y/C
separation
device) and upd64031a (ghost reduction device), with only the upd64031a
and
one with both. Since they all have the same PCI ID the only way to
determine the model is to probe.
Did they happen to change the subsystem device_id? There are two pairs
of PCI IDs on each card. Most of the time the subsystem vendor/device
isn't set.
Getting rid of the probes altogether is the most reliable solution.
There is probably a way to identify these boards more specifically
that you haven't discovered yet. PCI subsystem device ID is worth
checking.
Jon,
This really is a well beaten topic for v4l-dvb devices.
1. Device IDs are used to identify the bridge chip.
2. Subsystem IDs are used to identify the specfic card.
3. Vendor provided serial EEPROMs (sitting at 8-bit I2C address 0xA0)
can provide some amplifying information about the board layout.
There is variation in the I2C peripherals used on a video card PCB per
any Subsystem ID. It's not a granular enough descriptor.
The data from serial EEPROMs, if the vendor was nice enough to even
include one, may not have a known decoding.
I agree that I2C probing is bad/undesirable. But for some video boards,
there is no other way than probing without each end user having expert
knowledge of the PCB layout.
Not probing, for cases where there is no other automated means to divine
the I2C devices used, would likely require an annoying or unsutainable
level of end user support be provided from a volunteer community.
Regards,
Andy
about detecting and identifying i2c devices on a TV card it is really a
long story ...
Everybody talking about such should have at least a look at the bttv
driver before announcing RFC stuff.
It should make wonder, what all is used to come around.
(resistors on unused gpios for example)
On later drivers, like the saa7134, there were really high hopes to get
out of that previous total misery, highest respect to all sorting it
however possible and did it well then, by reliable PCI subsystem stuff.
But to give one more example, Asus, by far not the worst, did force the
users to uninstall all other TV card drivers on their m$ systems in
2005, if the tda8275a hybrid should be in use. (don't work anymore ...)
On that we have always been much better!
Jon's suggestions are on the level of 2002 and he is not in any details.
Cheers,
Hermann
Regards,
Hans
static const unsigned short addrs[] = {
addr, I2C_CLIENT_END
};
client = i2c_new_probed_device(adapter, info, addrs);
This is a bit awkward and I came up with this macro:
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
This can construct a list of one or more i2c addresses on the fly. But
this is something that really belongs in i2c.h, renamed to I2C_ADDRS.
With this macro we can just do:
client = i2c_new_probed_device(adapter, info, I2C_ADDRS(addr));
Comments?
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: Leadtek Winfast DTV-1000S
That is fantastic news. Not only will it be coming soon, but I don't have to do it myself!! How will we know when the test repository is created - will it be announced on this list? Thanks, Paul Henry Wu did send modified saa7134 files with support for this card on Tuesday off list. Mike replied, that he will set up a test repository as soon he gets some time for doing so. -- 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: Leadtek Winfast DTV-1000S
Am Montag, den 08.06.2009, 07:59 +1000 schrieb pau...@planar.id.au: That is fantastic news. Not only will it be coming soon, but I don't have to do it myself!! How will we know when the test repository is created - will it be announced on this list? Thanks, Paul Henry Wu did send modified saa7134 files with support for this card on Tuesday off list. Mike replied, that he will set up a test repository as soon he gets some time for doing so. Paul, give Mike some time for it. There are much more variables in question, that can be different on devices now seen in the wild for the first time and a proper framework must be employed. If you can't wait, ask Mike do send you the files, seems they are recent enough for current v4l-dvb, but better is to wait and start with some unified testing base. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bt8xx: Add support for the Conexant Fusion 878a / Twinhan VP 1025 DVB-S
On Sun, 7 Jun 2009, Michael Stapelberg wrote: Add fefe:0001 to the list of identifiers for the bt8xx driver. The chip is named Conexant Fusion 878a, the card is a Twinhan VP 1025 DVB-S PCI. Please commit the attached patch. You can remove Conexant Fusion from the board name. All the boards for that driver use that same chip. Just use Twinhan VP 1025 DVB-S. Don't you need to add it to the list in bttv-cards.c in order to use the card? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for the following 3 changesets: 01/03: lnbp21: Add missing newline http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=9fb907f46b2a 02/03: ivtv: Add missing newline http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=0b3fde8fc202 03/03: tuner-simple, tveeprom: Add Philips FQ1216LME MK3 analog tuner http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=7fba03a020fd You'll probably have to cherry pick these. The first 2 were from an earlier pull request that I had though you had pulled already, so I performed an update. I couldn't check in the 3rd change until I checked in a make commit autogenerated change to CARDLIST.cx88 - there was no good way to have make commit not do it. :( 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
funny colors from XC5000 on big endian systems
Is it possible that the XC5000 driver does not work properly on big endian systems? I am using Linux/PowerPC 2.6.29.4. I have tried to view an analog NTSC video stream from a Hauppauge 950Q using various applications (including GStreamer v4lsrc and XawTV). The video is always present, but in purple and green hues. Mike -- 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: funny colors from XC5000 on big endian systems
On Sun, 2009-06-07 at 20:22 -0400, W. Michael Petullo wrote: Is it possible that the XC5000 driver does not work properly on big endian systems? I am using Linux/PowerPC 2.6.29.4. I have tried to view an analog NTSC video stream from a Hauppauge 950Q using various applications (including GStreamer v4lsrc and XawTV). The video is always present, but in purple and green hues. Sounds more like a problem with the analog video decoder/digitizer than the tuner. Regards, Andy Mike -- 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: funny colors from XC5000 on big endian systems
On Sun, 2009-06-07 at 21:12 -0400, Devin Heitmueller wrote: On Sun, Jun 7, 2009 at 8:22 PM, W. Michael Petullom...@flyn.org wrote: Is it possible that the XC5000 driver does not work properly on big endian systems? I am using Linux/PowerPC 2.6.29.4. I have tried to view an analog NTSC video stream from a Hauppauge 950Q using various applications (including GStreamer v4lsrc and XawTV). The video is always present, but in purple and green hues. Mike -- 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 Hello Mike, Yes, there was an issue that resulted in purple/green colors, but I thought I had it fixed. Perhaps the fix I made was endian specific (I will have to check the code). Note that this is entirely an issue with the au8522 decoder driver, not the xc5000 tuner driver. Admittedly, I have done all my testing with x86, so it wouldn't surprise me if an endianness bug snuck in there (although I try to be conscious of these sorts of issues). Two questions: Do you see the issue using tvtime? This will help isolate whether it's an application compatibility issue or whether it's related to endianness (and I do almost all my testing with tvtime). You indicated that you had reason to believe it's a PowerPC issue. Is there any reason that you came to that conclusion other than that you're running on ppc? I'm not discounting the possibility, but it would be good to know if you have other information that supports your theory. You may also want to check if CVBS or S-Video also shows the problem. A simple test that will conclusively eliminate the XC5000. Regards, Andy Regards, Devin -- 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: funny colors from XC5000 on big endian systems
On Sun, Jun 7, 2009 at 9:20 PM, Andy Wallsawa...@radix.net wrote: You may also want to check if CVBS or S-Video also shows the problem. A simple test that will conclusively eliminate the XC5000. Regards, Andy Well, it won't really be conclusive in this case - it's an intermittent bug in the hardware, and is much more likely to occur with the xc5000 because it happens when the signal needs to resync (the 16-bit YUYV byte pair sometimes is read on the wrong boundary). Hence it tends to occur more often with the xc5000 because of changing channels (but can occur on the CVBS or S-Video inputs as well). The au0828 driver has code to detect this condition but there might be an issue with the check. Once I know the answer to the questions posed to Mike, I can work with him to debug the issue. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Em Thu, 4 Jun 2009 14:39:52 +0200 Laurent Pinchart laurent.pinch...@skynet.be escreveu: Mauro, Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/ for the following 3 changesets: uvcvideo: Add generic control blacklist. uvcvideo: Don't accept to change the format when buffers are allocated. uvcvideo: Implement VIDIOC_[GS]_JPEGCOMP I have a few comments about the code of the last patch: + jpeg-quality = video-streaming-ctrl.wCompQuality / 100; Wouldn't be better to round it to the closest value instead of just truncating? + memcpy(probe, video-streaming-ctrl, sizeof probe); Please use sizeof(probe) instead. ERROR: do not use assignment in if condition #64: FILE: linux/drivers/media/video/uvc/uvc_v4l2.c:376: + if ((ret = uvc_probe_video(video, probe)) 0) ERROR: do not use assignment in if condition #80: FILE: linux/drivers/media/video/uvc/uvc_v4l2.c:872: + if ((ret = uvc_acquire_privileges(handle)) 0) total: 2 errors, 0 warnings, 81 lines checked Please, one statement per line. - Also, I have a few comments, from API POV. It doesn't seem that those ioctls are properly implemented. There are some things there that sounded obfuscated for me, and it you aren't implementing. Probably because it is not clear enough. Also, we used to have a similar set of ioctls for MPEG, that were removed, in favor of the usage of extended controls, with a cleaner interface. That's said, instead of adding more support for this obfuscated API, maybe we could deprecate those in favor of some controls that could make more sense, and let vidio_ioctl2 provide backward compat for it by calling the proper controls, just to preserve binary compatibility with legacy applications. 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
About the VIDIOC_DQBUF
Dear all ~~
I have met a issue when I used the mmap method for previewing . I just
used the standard code as spec to get the image data :
status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
{
LOG_FUNCTION_NAME
int rt ;
unsigned int i ;
fd_set fds ;
struct timeval tv ;
struct v4l2_buffer buf ;
for(;;){
FD_ZERO(fds) ;
FD_SET(v4l2Fd, fds) ;
//now the time is long ,just for debug
tv.tv_sec = 2 ;
tv.tv_usec = 0 ;
rt = select(v4l2Fd + 1, fds, NULL, NULL, tv) ;
LOGD(The value of select return : %d\n, rt) ;
/** for debug
if(V4L2_NOERROR != v4l2ReadFrame()){
LOGE(READ ERROR) ;
}
***/
if(-1 == rt){
LOGE(there is something wrong in select
function(select)) ;
//no defined error manage
return V4L2_IOCTL_ERROR ;
}
if(0 == rt){
LOGE(wait for data timeout in select) ;
return V4L2_TIMEOUT ;
}
memset(buf, 0, sizeof(buf)) ;
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE ;
buf.memory = V4L2_MEMORY_MMAP ;
if(-1 == ioctl(v4l2Fd, VIDIOC_DQBUF, buf)){
LOGE(there is something wrong in dequeue
buffer(VIDIOC_DQBUF)) ;
return V4L2_IOCTL_ERROR ;
}
assert(i n_buf) ;
LOGE(buf.index 0buf.length = %d %d \n, buf.index ,
buf.length) ;
memcpy((mCameraProwave-getPreviewHeap())-base(),
v4l2Buffer[buf.index].start, buf.length) ;
if(-1 == ioctl(v4l2Fd, VIDIOC_QBUF, buf)){
LOGE(there is something wrong in enqueue
buffer(VIDIOC_QBUF)) ;
return V4L2_IOCTL_ERROR ;
}
//break ; //i don't know whether the break is needed ;
}
return V4L2_NOERROR ;
}
when executed the VIDIOC_DQBUF IOCTL,the return value was right, but the
value of buf.length would always be zero. Then I used the read()
function to read raw data in the file handle for debug, and I can get
the raw data. Anybody have met this issue before ? Who can give me some
advices or tell me what is wrong , thanks a lot ~
--
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: funny colors from XC5000 on big endian systems
Is it possible that the XC5000 driver does not work properly on big endian systems? I am using Linux/PowerPC 2.6.29.4. I have tried to view an analog NTSC video stream from a Hauppauge 950Q using various applications (including GStreamer v4lsrc and XawTV). The video is always present, but in purple and green hues. Do you see the issue using tvtime? This will help isolate whether it's an application compatibility issue or whether it's related to endianness (and I do almost all my testing with tvtime). Tvtime works like a charm. The colors look fine. This is the first I've seen tvtime and it seems great. Now we may be getting off the topic, but does anyone know why xawtv, streamer and GStreamer's v4l2src would muck up the colors? You indicated that you had reason to believe it's a PowerPC issue. Is there any reason that you came to that conclusion other than that you're running on ppc? I'm not discounting the possibility, but it would be good to know if you have other information that supports your theory. It was a hypothesis, but based on experience in seeing endian bugs in video code and hearing endian bugs in audio code. After using PowerPC long enough, you learn to jump to the endian conclusion pretty quickly. I was wrong! Thanks. Mike -- 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: funny colors from XC5000 on big endian systems
On Sun, Jun 7, 2009 at 10:12 PM, W. Michael Petullom...@flyn.org wrote: Do you see the issue using tvtime? This will help isolate whether it's an application compatibility issue or whether it's related to endianness (and I do almost all my testing with tvtime). Tvtime works like a charm. The colors look fine. This is the first I've seen tvtime and it seems great. Now we may be getting off the topic, but does anyone know why xawtv, streamer and GStreamer's v4l2src would muck up the colors? Ok, that's good to know. Perhaps it's some difference in the way the v4l stream is read and the frames are dequeued (mmap versus read(), etc). You indicated that you had reason to believe it's a PowerPC issue. Is there any reason that you came to that conclusion other than that you're running on ppc? I'm not discounting the possibility, but it would be good to know if you have other information that supports your theory. It was a hypothesis, but based on experience in seeing endian bugs in video code and hearing endian bugs in audio code. After using PowerPC long enough, you learn to jump to the endian conclusion pretty quickly. I was wrong! Ok, well that's good to know. I did look at the code and couldn't see how it could possibly be an endianness bug. Bear in mind that the analog support for the 950q is still relatively new, and its entirely possible there are some application specific bugs to be worked out as there is more testing. Could you please describe in more detail the *exact* configuration you are attempting, including the versions of the applications you are using and command line arguments you are passing. If I can reproduce the issue here then I can probably debug it much faster. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Em Sun, 07 Jun 2009 20:49:25 -0400 Andy Walls awa...@radix.net escreveu: Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for the following 3 changesets: 01/03: lnbp21: Add missing newline http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=9fb907f46b2a 02/03: ivtv: Add missing newline http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=0b3fde8fc202 03/03: tuner-simple, tveeprom: Add Philips FQ1216LME MK3 analog tuner http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=7fba03a020fd You'll probably have to cherry pick these. Ok, I've cherry-picked. The first 2 were from an earlier pull request that I had though you had pulled already, so I performed an update. I couldn't check in the 3rd change until I checked in a make commit autogenerated change to CARDLIST.cx88 - there was no good way to have make commit not do it. :( The issue is caused, in fact, by a mistake from my side: I've accidentally committed an unfinished changeset for cx88 together with another patch. This were reverted, but you probably did your changes over my tree before the revert patch. Please re-clone your tree from master to avoid having those patches to appear again. 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
