Re: [linux-dvb] device file ordering w/multiple cards
Andy Zivkovic wrote: > Joseph Shraibman wrote: > I have two dvb cards in my system. Is there any way to change the order > of the device files? It might also be possible to use udev for this kind of ordering. Maybe just like the persistent-[net|storage] scripts in /etc/udev/rules.d Regards, Jaap Crezee -- 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
How can I fix errors and warnings in nvidia module for Tesla C1060
Hello, I am trying to install driver of nvidia Tesla C1060 on x86 based compute node of Rockcluster 5.1 But I am following errors and warnings: make -f /usr/src/kernels/2.6.18-92.1.13.el5-i686/scripts/Makefile.build obj= /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/nv cc -Wp,-MD,/tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/nv/.nv.o.d -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/4.1.2/include -D__KERNEL_ _ -Iinclude -Iinclude2 -I/usr/src/kernels/2.6.18-92.1.13.el5-i686/include -i nclude include/linux/autoconf.h -I/tmp/selfgz3379/NVIDIA-Linux-x86-177.72- pkg1/usr/src/nv -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict -aliasing -fno-common -Wstrict-prototypes -Wundef -Werror-implicit-function- declaration -Os -pipe -msoft-float -fno-builtin-sprintf -fno-builtin-log2 -f no-builtin-puts -mpreferred-stack-boundary=2 -march=i686 -mtune=generic -mtu ne=generic -mregparm=3 -ffreestanding -I/usr/src/kernels/2.6.18-92.1.13.el5- i686/include/asm-i386/mach-generic -Iinclude/asm-i386/mach-generic -I/usr/sr c/kernels/2.6.18-92.1.13.el5-i686/include/asm-i386/mach-default -Iinclude/as m-i386/mach-default -fomit-frame-pointer -g -fno-stack-protector -Wdeclarati on-after-statement -Wno-pointer-sign -I/tmp/self gz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/nv -Wall -Wimplicit -Wreturn-typ e -Wswitch -Wformat -Wchar-subscripts -Wparentheses -Wpointer-arith -Wno-mul tichar -Werror -MD -Wsign-compare -Wno-cast-qual -Wno-error -D__KERNEL__ -DM ODULE -DNVRM -DNV_VERSION_STRING=\"177.72\" -UDEBUG -U_DEBUG -DNDEBUG -DMODU LE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(nv)" -D"KBUILD_MODNAM E=KBUILD_STR(nvidia)" -c -o /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr /src/nv/.tmp_nv.o /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/nv/nv .c In file included from include/linux/list.h:8, from include/linux/lockdep.h:13, from include/linux/spinlock_types.h:18, from include/linux/spinlock.h:78, from include/linux/capability.h:45, from include/linux/sched.h:44, from include/linux/module.h:9, from /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/n v/nv-linux.h:59, from /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/n v/nv.c:14: include/linux/prefetch.h: In function 'prefetch_range': include/linux/prefetch.h:62: warning: pointer of type 'void *' used in arith metic In file included from include/linux/dmapool.h:14, from include/linux/pci.h:616, from /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/n v/nv-linux.h:86, from /tmp/selfgz3379/NVIDIA-Linux-x86-177.72-pkg1/usr/src/n v/nv.c:14: include/asm/io.h: In function 'check_signature': include/asm/io.h:245: warning: wrong type argument to increment ... -> Kernel module compilation complete. ERROR: Unable to load the kernel module 'nvidia.ko'. This happens most frequently when this kernel module was built against the wrong or improperly configured kernel sources, with a version of gcc that differs from the one used to build the target kernel, or if a driver such as rivafb/nvidiafb is present and prevents the NVIDIA kernel module from obtaining ownership of the NVIDIA graphics device(s). Please see the log entries 'Kernel module load error' and 'Kernel messages' at the end of the file '/var/log/nvidia-installer.log' for more information. -> Kernel module load error: insmod: error inserting './usr/src/nv/nvidia.ko': -1 No such device I am attaching complete log file for your reference. I cannot see any source code for these modules. How can I fix these error and warnings. Thanks, -- JSR nvidia-installer log file '/var/log/nvidia-installer.log' creation time: Sat Jan 24 10:26:32 2009 installer version: 1.0.7 option status: license pre-accepted: false update : false force update: false expert : false uninstall : false driver info : false precompiled interfaces : true no ncurses color: false query latest version: false OpenGL header files : true no questions: false silent : false no recursion: false no backup : false kernel module only : false sanity : false add this kernel : false no runlevel check : false no network : false no ABI note : false no RPMs : false no kernel module: false force SELinux : default no X server check : false no cc version check : false force tls : (not specified) X install prefix: (not specified) X l
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-pull
Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2-pull for the following: - pvrusb2: Use usb_make_path() to determine device bus location pvrusb2-hdw.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) This is the usb_make_path() change that's been talked about. Hopefully you'll see this as a real live actual pull request in spite of the subject line having been thoroughly spoiled / thrashed over the past week due to all the subsequent discussion from the last pull request :-) Note also that the pull location is slightly different than what I usually use. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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] sh_mobile_ceu_camera: NV12/21/16/61 are added only once.
On Fri, Jan 23, 2009 at 9:28 AM, Kuninori Morimoto wrote: > NV12/21/16/61 had been added every time > UYVY/VYUY/YUYV/YVYU appears on get_formats. > This patch modify this problem. That's one way to do it. Every similar driver has to do the same thing. Yuck. Or we could have a better translation framework that does OR for us, using for instance bitmaps. / magnus -- 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] sh_mobile_ceu_camera: NV12/21/16/61 are added only once.
NV12/21/16/61 had been added every time
UYVY/VYUY/YUYV/YVYU appears on get_formats.
This patch modify this problem.
Signed-off-by: Kuninori Morimoto
---
[before]
Format NV12 (12 bits, NV12): Planar NV12
Format NV21 (12 bits, NV21): Planar NV21
Format unknown (0x3631564e) ( 0 bits, NV16): Unknown 0x3631564e
Format unknown (0x3136564e) ( 0 bits, NV61): Unknown 0x3136564e
Format YUYV (16 bits, YUYV): Packed YUY2
Format NV12 (12 bits, NV12): Planar NV12
Format NV21 (12 bits, NV21): Planar NV21
Format unknown (0x3631564e) ( 0 bits, NV16): Unknown 0x3631564e
Format unknown (0x3136564e) ( 0 bits, NV61): Unknown 0x3136564e
Format unknown (0x55595659) ( 0 bits, YVYU): Packed YVYU
Format NV12 (12 bits, NV12): Planar NV12
Format NV21 (12 bits, NV21): Planar NV21
Format unknown (0x3631564e) ( 0 bits, NV16): Unknown 0x3631564e
Format unknown (0x3136564e) ( 0 bits, NV61): Unknown 0x3136564e
Format UYVY (16 bits, UYVY): Packed UYVY
Format RGB555 (16 bits, RGB555): BGR 15-bit
Format RGB555X (16 bits, RGB555X): Unknown 0x51424752
Format RGB565 (16 bits, RGB565): BGR 16-bit
Format RGB565X (16 bits, RGB565X): Unknown 0x52424752
[after]
Format NV12 (12 bits, NV12): Planar NV12
Format NV21 (12 bits, NV21): Planar NV21
Format unknown (0x3631564e) ( 0 bits, NV16): Unknown 0x3631564e
Format unknown (0x3136564e) ( 0 bits, NV61): Unknown 0x3136564e
Format YUYV (16 bits, YUYV): Packed YUY2
Format unknown (0x55595659) ( 0 bits, YVYU): Packed YVYU
Format UYVY (16 bits, UYVY): Packed UYVY
Format RGB555 (16 bits, RGB555): BGR 15-bit
Format RGB555X (16 bits, RGB555X): Unknown 0x51424752
Format RGB565 (16 bits, RGB565): BGR 16-bit
Format RGB565X (16 bits, RGB565X): Unknown 0x52424752
drivers/media/video/sh_mobile_ceu_camera.c | 64
1 files changed, 36 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 9a2586b..9cde91a 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -555,42 +555,50 @@ static int sh_mobile_ceu_get_formats(struct
soc_camera_device *icd, int idx,
struct soc_camera_format_xlate *xlate)
{
struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
- int ret, k, n;
+ int ret, i, k, n;
int formats = 0;
ret = sh_mobile_ceu_try_bus_param(icd);
if (ret < 0)
return 0;
- switch (icd->formats[idx].fourcc) {
- case V4L2_PIX_FMT_UYVY:
- case V4L2_PIX_FMT_VYUY:
- case V4L2_PIX_FMT_YUYV:
- case V4L2_PIX_FMT_YVYU:
- n = ARRAY_SIZE(sh_mobile_ceu_formats);
- formats += n;
- for (k = 0; xlate && k < n; k++) {
- xlate->host_fmt = &sh_mobile_ceu_formats[k];
- xlate->cam_fmt = icd->formats + idx;
- xlate->buswidth = icd->formats[idx].depth;
- xlate++;
- dev_dbg(&ici->dev, "Providing format %s using %s\n",
- sh_mobile_ceu_formats[k].name,
- icd->formats[idx].name);
- }
- default:
- /* Generic pass-through */
- formats++;
- if (xlate) {
- xlate->host_fmt = icd->formats + idx;
- xlate->cam_fmt = icd->formats + idx;
- xlate->buswidth = icd->formats[idx].depth;
- xlate++;
- dev_dbg(&ici->dev,
- "Providing format %s in pass-through mode\n",
- icd->formats[idx].name);
+ /* yuv color format check when idx == 0 */
+ if (idx)
+ goto yuv_check_done;
+
+ for (i = 0 ; i < icd->num_formats ; i++) {
+ switch (icd->formats[i].fourcc) {
+ case V4L2_PIX_FMT_UYVY:
+ case V4L2_PIX_FMT_VYUY:
+ case V4L2_PIX_FMT_YUYV:
+ case V4L2_PIX_FMT_YVYU:
+ n = ARRAY_SIZE(sh_mobile_ceu_formats);
+ formats += n;
+ for (k = 0; xlate && k < n; k++) {
+ xlate->host_fmt = &sh_mobile_ceu_formats[k];
+ xlate->cam_fmt = icd->formats + i;
+ xlate->buswidth = icd->formats[i].depth;
+ xlate++;
+ dev_dbg(&ici->dev,
+ "Providing format %s using %s\n",
+ sh_mobile_ceu_formats[k].name,
+ icd->formats[i].name);
+ }
+ goto yuv_check_done;
}
}
+yuv_check_done:
+
+ formats++;
+ if (xlate) {
+ xlate->host_
[PATCH] ov772x: add support S_CROP operation.
ov772x_set_fmt had returned NULL when pixfmt is 0,
although it mean only geometry change.
This patch modify this problem.
Signed-off-by: Kuninori Morimoto
---
drivers/media/video/ov772x.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 681a11b..30eb80e 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -792,12 +792,15 @@ static int ov772x_set_fmt(struct soc_camera_device *icd,
/*
* select format
+* when pixfmt is 0, only geometry change
*/
- priv->fmt = NULL;
- for (i = 0; i < ARRAY_SIZE(ov772x_cfmts); i++) {
- if (pixfmt == ov772x_cfmts[i].fourcc) {
- priv->fmt = ov772x_cfmts + i;
- break;
+ if (pixfmt) {
+ priv->fmt = NULL;
+ for (i = 0; i < ARRAY_SIZE(ov772x_cfmts); i++) {
+ if (pixfmt == ov772x_cfmts[i].fourcc) {
+ priv->fmt = ov772x_cfmts + i;
+ break;
+ }
}
}
if (!priv->fmt)
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tuning a pvrusb2 device. Every attempt has failed.
Still trying to get the OnAir Creator to work. It is properly recognized by the pvrusb2 driver, but I can't seem to get any further. I'm now trying to scan the digital channels. What I have already tried: o Channel scan with mythtv completes, but when trying to view any of the supposedly found channels, I get a blank screen. Mythtv says it can't get a signal lock. o Channel scan withh kaffeine: as it progresses, I see the occasional green light, most often with a relatively low number (15-25% or so) of signal strength and an even lower number (1-3% or so) of SNR. When the progress bar reaches about 80% the scan suddenly ends and there is nothing in the right column, where the found channels are supposed to go (right?). Usually the next operation I try crashes kaffeine. I'm still trying to find gdb on this new lenny install. Until I do I won't be able to get a trace-back. o Scan with 'scan' from dvb-tools. I used the us-ATSC-center-frequencies-8VSB file from kaffeine. I get this: scanning /tmp/us-ATSC-center-frequencies-8VSB using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' >>> tune to: 57028615:8VSB WARNING: >>> tuning failed!!! >>> tune to: 57028615:8VSB (tuning failed) WARNING: >>> tuning failed!!! ... [ exactly the same output for most channels but then I get a few channels like this ] >>> tune to: 497028615:8VSB WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x1ffb ... dumping lists (0 services) Done. o If I try to tune it (to one of the frequencies that gives a filter timeout, with dvbtune from dvb-tools) I get this: > dvbtune -f 533028615 Using DVB card "LG Electronics LGDT3303 VSB/QAM Frontend" Unknown FE type. Aborting o scantv is for analog only, and it doesn't have NTSC norm, but in any case, it seems to put the device into analog mode (it has an analog tuner) and turns the red led off. From observation, it seems that when the device is accessed in analog mode (via /dev/video0) the led goes off, when accessed through the /dev/dvb/adapter0, it comes back on. o change-channel.sh that comes with the pvrusb2 driver. The above frequency list (from kaffeine) is apparently the wrong format for this script. I'll have to look further into the proper format. Of course it would be quicker if someone can point me to a list of us channels in the proper format. The procedure described in the script to obtain the frequencies depends on frequency lists in /usr/share/doc/xawtv, but there is no file for us frequencies. o femon returns this, which makes sense since the card is not tuned to anything: FE: LG Electronics LGDT3303 VSB/QAM Frontend (ATSC) status | signal | snr | ber | unc fbdf | Can anyone suggest other tools I might have missed? Explain why I'm getting the results above? Since both mythtv and kaffeine find some channels in the scan, shouldn't I be able to watch them? To narrow down the problem, I was going to tune the card to one of the channels and then use mplayer to read directly from the device, but I can't even change the channel. Any suggestions would be welcome. Thanks. A. -- 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
TinyTwin (af9015) Results and questions
I've pulled the latest v4l-dvb trunk and installed it, can confirm that both tuners of the DigitalNow TinyTwin work beautifully. I do have a few questions though. - I still have to specify: options dvb-usb-af9015 dual_mode=1 to enable the second tuner. I thought that would be on by default now the 2nd tuner bugs have been worked out. - Is there a official place to download the firmware from? Currently I'm getting it from: http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware_files/4.95.0/dvb-usb-af9015.fw - Is it possible to estimate when this will make its way into the linux kernel? How will I know? I ask because I'd like to write up a howto for myth and/or ubuntu users, and want to cover all bases. Thanks - Lindsay Lindsay Mathieson http://members.optusnet.com.au/~blackpaw1/album Lindsay Mathieson http://members.optusnet.com.au/~blackpaw1/album -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] getting started with msi tv card
Hi Daniel, I'm combining the replies to several messages
into one response. This includes private mail for which
there is no on-list content, but I hope that for the sake
of other list-victims, I have included sufficient context...
On Thu, 22 Jan 2009, Daniel Dalton wrote:
> >>> tune to:
> >>> 22650:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
> >>> tuning status == 0x04
> >>> tuning status == 0x06
> >>> tuning status == 0x06
> >>> tuning status == 0x06
> >>> tuning status == 0x00
> >>> tuning status == 0x06
> >>> tuning status == 0x06
> >>> tuning status == 0x06
> >>> tuning status == 0x00
> >>> tuning status == 0x06
> WARNING: >>> tuning failed!!!
As I noted earlier (privately), the `tuning status' value gives an
indication of what sort of signal your USB stick is seeing.
I've cut most of the following frequencies, because they
mirror the above values -- you either see 0x0, 0x4, or 0x6.
Except...
> >>> tuning status == 0x1e
> WARNING: filter timeout pid 0x0011
> WARNING: filter timeout pid 0x
> WARNING: filter timeout pid 0x0010
On this particular (UHF) frequency, you actually were able
to lock onto a signal. Sadly, this was not enough to get
any information from it...
> So I assume there is no signal? I'm plugging into a co-axle plug in my
> house, which we plug our tv into.
> So do you think my problem is with the card?
A status value of 0x0 means no signal whatsoever. The
values, if you are interested, can be seen in the source
file /usr/local/src/linux-2.6.27-rc4/include/linux/dvb/frontend.h
(adjust to match your path to the source -- if you are
interested, and it is fine if you are not...)
typedef enum fe_status {
FE_HAS_SIGNAL = 0x01, /* found something above the noise level */
FE_HAS_CARRIER = 0x02, /* found a DVB signal */
FE_HAS_VITERBI = 0x04, /* FEC is stable */
FE_HAS_SYNC = 0x08, /* found sync bytes */
FE_HAS_LOCK = 0x10, /* everything's working... */
The value 0x6 is obtained by ORing the above CARRIER and
VITERBI values. Normally one first gets signal, from which
carrier, viterbi, sync, and finally lock follow in quick
succession.
Basically, this all means that your tuner sees something,
but it can't quite lock onto it.
> Am I better getting a new card? I got this a couple of years ago when I
> was on windows, and never used it, so yeh I don't have the original
> aerial that came with it or the original disks...
As Antti has suggested, you may have better luck with a
new different card.
As an offside, supposedly the linux-dvb mailing list has
been abandoned by every developer, and only a few DVB-freak
luddites remain, and in theory, by posting this to the
linux-media list I should magically reach thousands of
developers who can fix the support for your card. Rght.
For these developers, seeing this for the first time, the
history behind this thread, including details about the
card being discussed, are safely archived on the linux-dvb
mailing list over the past three-or-so days.
Personally, I don't expect support for your card to
magically materialise, though I'd love to be proved
wrong. Generally it's due to lack of adequate documentation
provided by the device or chipset manufacturers. I am far
removed from this, sad to say.
> I'm chopping out the script, just to cut the size of this reply
> down. But, thanks very much for sending the script, it looks good, and
> yep, I think I'll find that very useful once I get tv going on my box.
As I always say, my script itself is probably useless,
while the ideas which went into it have value. The
general idea is that you use the Unix-type way of thinking
of using basic building-block tools stacked together to
come up with the desired result.
This requires one to think at the building-block level,
which may not yet be at your level -- but once you reach
it, if you do, then you have an understanding which almost
brings you to the level of `master of the known universe'.
I'll go over this quickly...
First of all, from the transmitter to your tuner is
something which I will just say is a black box for now,
and you don't need to know more about it, because that
won't help you under Linux -- though it would if you
were to be an engineer or hardware developer, and you
need to know details of modulation and the like.
Where Linux comes into play is the payload carried by
the broadcast. This is in the form of a (partial)
Transport Stream, which you will be able to obtain from
your device.
There are many different ways to get at this stream,
for example, `tzap' and `cat' from the DVB device, or
using `dvbstream' in my example. Generally, they are
all similar, in that the end result is the Partial
Transport Stream.
Which leads me to mention that the particular script
I provided has the custom flag `-T' not present in
normal `dvbstream' which simply causes it to Terminate
i
Re: [linux-dvb] device file ordering w/multiple cards
Joseph Shraibman wrote: I have two dvb cards in my system. Is there any way to change the order of the device files? If the different cards use different drivers, you can pass the adapter_nr parameter to the module. In my /etc/modprobe.conf I have: options dvb_usb_dib0700 adapter_nr=0,1,2,3 options mantis adapter_nr=4 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: [linux-dvb] device file ordering w/multiple cards
Joseph Shraibman schrieb:
> I have two dvb cards in my system. Is there any way to change the order
> of the device files?
Usually, the device files (/dev/dvb/adapter?/..) are create by a udev-rule. If
you modify
the rule, you can assign every dvb card to a specific number. In my case, I'm
using Suse,
which comes withe following udev rule in
/etc/udev/rules.d/50-udev-default.rules:
# DVB video
SUBSYSTEM=="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter%%i/%%s
$${K.*} $${K#*.}'", NAME="%c"
I've two DVB cards, one FF and one budget. The FF should be always the adapter
#0. I've
disabled the default DVB rule and add my one rule, which assigns the numbers
depend on the
pci vendor/device numbers:
# DVB video
#SUBSYSTEM=="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter%%i/%%s
$${K.*} $${K#*.}'", NAME="%c"
SUBSYSTEM=="dvb", SYSFS{subsystem_device}=="0x1156",
SYSFS{subsystem_vendor}=="0x153b",
PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter%%i/%%s 1 $${K#*.}'",
NAME="%c
SUBSYSTEM=="dvb", SYSFS{subsystem_device}=="0x000a",
SYSFS{subsystem_vendor}=="0x13c2",
PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter%%i/%%s 0 $${K#*.}'",
NAME="%c
If you use two identical cards, you can use the pci slot number:
# DVB video
#SUBSYSTEM=="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter%%i/%%s
$${K.*} $${K#*.}'", NAME="%c"
SUBSYSTEM=="dvb", SUBSYSTEMS=="pci", KERNELS==":04:07.0", PROGRAM="/bin/sh
-c 'K=%k;
K=$${K#dvb}; printf dvb/adapter%%i/%%s 1 $${K#*.}'", NAME="%c"
SUBSYSTEM=="dvb", SUBSYSTEMS=="pci", KERNELS==":04:06.0", PROGRAM="/bin/sh
-c 'K=%k;
K=$${K#dvb}; printf dvb/adapter%%i/%%s 0 $${K#*.}'", NAME="%c"
Regards,
Hartmut
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Fusion HDTV 7 Dual Express
On Thu, Jan 22, 2009 at 02:13:02PM -0800, Tu-Tu Yu wrote: > Then that means you're getting good signal== 012c (Hex) equal to > 300(Dec) then that means your snr value is 300/10 = 30 dB > I just got one of these cards and I was noticing the snr values (generally 300 or 295) as compared to those from my HD5500 (which reports large numbers that have to be shifted and scaled). The card works great but I was wondering: Does every driver report SNR in its own unique way? Is there a standard way to interpret the numbers other than reading the driver code? Just curious, not flaming... Also, perhaps OT, the remote is detected: input: i2c IR (FusionHDTV) as /devices/virtual/input/input6 ir-kbd-i2c: i2c IR (FusionHDTV) detected at i2c-3/3-006b/ir0 [cx23885[0]] I noticed the other thread about keytables and was wondering if there is any testing I could do that might be useful. -- Mark -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Fusion HDTV 7 Dual Express
On Thu, Jan 22, 2009 at 5:07 PM, Joseph Shraibman wrote: > Ignore my previous email. The card wasn't tuned to anything. I tuned to a > known good station and get this: > > FE: Samsung S5H1411 QAM/8VSB Frontend (ATSC) > status SCVYL | signal 012c | snr 012c | ber | unc | Great, that's much more like it (you're getting an SNR of 29.5dB). I should look at doing a patch so that the signal and SNR are zero when there is no lock so that users don't get confused by the garbage output. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Fusion HDTV 7 Dual Express
Then that means you're getting good signal== 012c (Hex) equal to 300(Dec) then that means your snr value is 300/10 = 30 dB On Thu, Jan 22, 2009 at 2:07 PM, Joseph Shraibman wrote: > Ignore my previous email. The card wasn't tuned to anything. I tuned to > a known good station and get this: > > FE: Samsung S5H1411 QAM/8VSB Frontend (ATSC) > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 0127 | snr 0127 | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 0127 | snr 0127 | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 0127 | snr 0127 | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 0127 | snr 0127 | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 0127 | snr 0127 | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 0127 | snr 0127 | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > status SCVYL | signal 012c | snr 012c | ber | unc | > FE_HAS_LOCK > > > On Thu, 22 Jan 2009, Devin Heitmueller wrote: > >> On Thu, Jan 22, 2009 at 4:37 PM, Joseph Shraibman >> wrote: On some demods, the strength and SNR indicators are only valid if you have a lock. >>> >>> But why don't I get a lock? I was getting signals with my pcHDTV3000 so I >>> know it isn't an antenna problem. >> >> I just looked back at your dmesg output, and I am somewhat confused. >> Do you have multiple cards installed in the host at the same time? >> Isn't the Oren OR51132 the other card? I would assume that you would >> need to be looking at the output of the s5h1411 frontend with femon if >> you're trying to capture on the Fusion HDTV 7 Dual Express. Or >> perhaps I am just missing something here. >> >> Devin >> >> -- >> Devin J. Heitmueller >> http://www.devinheitmueller.com >> AIM: devinheitmueller >> > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Fusion HDTV 7 Dual Express
Ignore my previous email. The card wasn't tuned to anything. I tuned to a known good station and get this: FE: Samsung S5H1411 QAM/8VSB Frontend (ATSC) status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 0127 | snr 0127 | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 0127 | snr 0127 | ber | unc | FE_HAS_LOCK status SCVYL | signal 0127 | snr 0127 | ber | unc | FE_HAS_LOCK status SCVYL | signal 0127 | snr 0127 | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 0127 | snr 0127 | ber | unc | FE_HAS_LOCK status SCVYL | signal 0127 | snr 0127 | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status SCVYL | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK On Thu, 22 Jan 2009, Devin Heitmueller wrote: On Thu, Jan 22, 2009 at 4:37 PM, Joseph Shraibman wrote: On some demods, the strength and SNR indicators are only valid if you have a lock. But why don't I get a lock? I was getting signals with my pcHDTV3000 so I know it isn't an antenna problem. I just looked back at your dmesg output, and I am somewhat confused. Do you have multiple cards installed in the host at the same time? Isn't the Oren OR51132 the other card? I would assume that you would need to be looking at the output of the s5h1411 frontend with femon if you're trying to capture on the Fusion HDTV 7 Dual Express. Or perhaps I am just missing something here. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Fusion HDTV 7 Dual Express
On Thu, 22 Jan 2009, Devin Heitmueller wrote: On Thu, Jan 22, 2009 at 4:37 PM, Joseph Shraibman wrote: On some demods, the strength and SNR indicators are only valid if you have a lock. But why don't I get a lock? I was getting signals with my pcHDTV3000 so I know it isn't an antenna problem. I just looked back at your dmesg output, and I am somewhat confused. Do you have multiple cards installed in the host at the same time? Isn't the Oren OR51132 the other card? I would assume that you would need to be looking at the output of the s5h1411 frontend with femon if you're trying to capture on the Fusion HDTV 7 Dual Express. Or perhaps I am just missing something here. Yes, I do, but * was pretty sure devices zero and one was the dual express. This is what happens when I pass -a 1 or -a 2 into femon FE: Samsung S5H1411 QAM/8VSB Frontend (ATSC) Problem retrieving frontend information: Invalid argument status S | signal 8f14 | snr 0804 | ber | unc | Problem retrieving frontend information: Invalid argument status S | signal 8f14 | snr 0804 | ber | unc | Problem retrieving frontend information: Invalid argument status S | signal 8f14 | snr 0804 | ber | unc | Problem retrieving frontend information: Invalid argument status S | signal 8f14 | snr 0804 | ber | unc | Problem retrieving frontend information: Invalid argument status S | signal 8f14 | snr 0804 | ber | unc | Problem retrieving frontend information: Invalid argument status S | signal 8f14 | snr 0804 | ber | unc | Problem retrieving frontend information: Invalid argument status S | signal 8f14 | snr 0804 | ber | unc | -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Fusion HDTV 7 Dual Express
On Thu, Jan 22, 2009 at 4:37 PM, Joseph Shraibman wrote: >> On some demods, the strength and SNR indicators are only valid if you >> have a lock. > > But why don't I get a lock? I was getting signals with my pcHDTV3000 so I > know it isn't an antenna problem. I just looked back at your dmesg output, and I am somewhat confused. Do you have multiple cards installed in the host at the same time? Isn't the Oren OR51132 the other card? I would assume that you would need to be looking at the output of the s5h1411 frontend with femon if you're trying to capture on the Fusion HDTV 7 Dual Express. Or perhaps I am just missing something here. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Fusion HDTV 7 Dual Express
On Thu, 22 Jan 2009, Devin Heitmueller wrote: On Thu, Jan 22, 2009 at 3:45 PM, Joseph Shraibman wrote: On Thu, 22 Jan 2009, Devin Heitmueller wrote: Are you sure you have zero signal strength, or just really low signal strength? I am pretty sure on the s5h1411, the signal strength field is populated with the the SNR, which could be construed as very low signal strength if you were expecting a percentage scaled from 0 to 65535. Have you run femon to confirm that the strength field really is zero? FE: Oren OR51132 VSB/QAM Frontend (ATSC) status | signal 3506 | snr 073f | ber | unc | status | signal 3506 | snr 073f | ber | unc | status | signal 3506 | snr 073f | ber | unc | status | signal 3506 | snr 073f | ber | unc | status | signal 3506 | snr 073f | ber | unc | status | signal 3506 | snr 073f | ber | unc | On some demods, the strength and SNR indicators are only valid if you have a lock. But why don't I get a lock? I was getting signals with my pcHDTV3000 so I know it isn't an antenna problem. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Fusion HDTV 7 Dual Express
On Thu, Jan 22, 2009 at 3:45 PM, Joseph Shraibman wrote: > > > On Thu, 22 Jan 2009, Devin Heitmueller wrote: > >> Are you sure you have zero signal strength, or just really low signal >> strength? I am pretty sure on the s5h1411, the signal strength field >> is populated with the the SNR, which could be construed as very low >> signal strength if you were expecting a percentage scaled from 0 to >> 65535. >> >> Have you run femon to confirm that the strength field really is zero? >> > > FE: Oren OR51132 VSB/QAM Frontend (ATSC) > status | signal 3506 | snr 073f | ber | unc | > status | signal 3506 | snr 073f | ber | unc | > status | signal 3506 | snr 073f | ber | unc | > status | signal 3506 | snr 073f | ber | unc | > status | signal 3506 | snr 073f | ber | unc | > status | signal 3506 | snr 073f | ber | unc | On some demods, the strength and SNR indicators are only valid if you have a lock. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Fusion HDTV 7 Dual Express
On Thu, 22 Jan 2009, Devin Heitmueller wrote: Are you sure you have zero signal strength, or just really low signal strength? I am pretty sure on the s5h1411, the signal strength field is populated with the the SNR, which could be construed as very low signal strength if you were expecting a percentage scaled from 0 to 65535. Have you run femon to confirm that the strength field really is zero? FE: Oren OR51132 VSB/QAM Frontend (ATSC) status | signal 3506 | snr 073f | ber | unc | status | signal 3506 | snr 073f | ber | unc | status | signal 3506 | snr 073f | ber | unc | status | signal 3506 | snr 073f | ber | unc | status | signal 3506 | snr 073f | ber | unc | status | signal 3506 | snr 073f | ber | unc | I find it more than a little suspicious that femon reports the same thing over and over. -- 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/tvp514x: make the module aware of rich people
Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath -Original Message- From: Sebastian Andrzej Siewior [mailto:bige...@linutronix.de] Sent: Monday, January 12, 2009 11:55 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab; video4linux- l...@redhat.com Subject: [PATCH] v4l/tvp514x: make the module aware of rich people because they might design two of those chips on a single board. You never know. [Hiremath, Vaibhav] Thanks, it was in my todo list. I will verify this patch tomorrow and let you know. ping Sebastian -- 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: Hauppauge TD-500
Brilliant, glad its in.
On Thu, Jan 22, 2009 at 8:59 PM, Devin Heitmueller
wrote:
> On Thu, Jan 22, 2009 at 3:55 PM, Glen Ford wrote:
>> Hi,
>>
>>
>> I am assuming this is the right list to post to.
>>
>> I recently setup MythBuntu on my system with Hauppauge TD-500 - the
>> system worked except for the IR Remote Control - I tried using the
>> latest v4l-dvb from the Hg repo to no avail.
>>
>> I had to make the following changes to dib0700_devices.c in order for
>> the remote to be recognised and appear as an event device (other
>> changes needed for MythBuntu itself can be found on my ubuntuforum
>> post here: http://ubuntuforums.org/showthread.php?p=6509202#post6509202)
>>
>> r...@pvr:~/dvb/v4l-dvb# hg diff
>> diff -r f4d7d0b84940 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
>> --- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Sun Jan 18
>> 10:55:38 2009 +
>> +++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Wed Jan 21
>> 19:41:36 2009 +
>> @@ -1683,7 +1683,13 @@
>>{ &dib0700_usb_id_table[43], NULL },
>>{ NULL },
>>}
>> - }
>> + },
>> +
>> + .rc_interval = DEFAULT_RC_INTERVAL,
>> + .rc_key_map = dib0700_rc_keys,
>> + .rc_key_map_size = ARRAY_SIZE(dib0700_rc_keys),
>> + .rc_query = dib0700_rc_query
>> +
>>}, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
>>
>>.num_adapters = 1
>>
>> Regards,
>>
>>
>> Glen
>
> Hello Glen,
>
> This exact patch has already been merged into my tree (contributed by
> Arne Luehrs), and a PULL request was sent to Mauro on Tuesday for it
> to go into the mainline v4l-dvb.
>
> http://linuxtv.org/hg/~dheitmueller/dib0700-pbfixes/rev/cf6003290b09
>
> Devin
>
> --
> Devin J. Heitmueller
> http://www.devinheitmueller.com
> AIM: devinheitmueller
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Laurent Pinchart a écrit : > On Thursday 22 January 2009, Carsten Meier wrote: >> Am Thu, 22 Jan 2009 00:20:00 +0100 >> >> schrieb Laurent Pinchart : >>> Hi Carsten, >>> >>> On Wednesday 21 January 2009, Carsten Meier wrote: now I want to translate bus_info into a sysfs-path to obtain device-info like serial numbers. Given a device reports "usb-:00:1d.2-2" as bus_info, then the device-info is located under "/sys/bus/usb/devices/2-2", which is a symlink to the appropriate /sys/devices/ directory, right? >>> I'm afraid not. In the above bus_info value, :00:1d.2 is the PCI >>> bus path of your USB controller, and the last digit after the dash is >>> the USB device path. >>> All I have to do is to compare the first 4 chars of bus_info against "usb-", get the chars after "." and append it to "/sys/bus/usb/devices/" to obatin a sysfs-path, right? Is there a more elegant solution or already a function for this? Can the "." appear more than once before the last one? >>> Probably not before, but definitely after. >>> >>> Root hubs get a USB device path set to '0'. Every other device is >>> numbered according to the hub port number it is connected to. If you >>> have an external hub connected on port 2 of your root hub, and have a >>> webcam connected to port 3 of the external hub, usb_make_path() will >>> return "usb-:00:1d.2-2.3". >>> >>> Cheers, >>> >>> Laurent Pinchart >> Hi, >> >> On my machine, my pvrusb2 (connected directly to my mini-pc) shows up >> under "/sys/bus/usb/devices/7-2/" which is a symbolic link to >> "../../../devices/pci:00/:00:1d.7/usb7/7-2" > > You're just lucky that USB bus 7 (usb7/7) is connected to the 7th function of > your USB host controller (1d.7). > > Here's an example of what I get on my computer: > > /sys/bus/usb/devices/4-2 -> ../../../devices/pci:00/:00:1d.2/usb4/4-2 > >> I can't test for the new bus_info-string, because it's not fixed yet in >> the driver. But if I got it correctly it should be >> "usb-:00:1d.7-7.2" ? > > I think you will get usb-:00:1d.7-2 > >> Then I've to simply take the string after the last dash, replace "." by "-" >> and append it to "/sys/bus/usb/devices/" for a sysfs-path? > > Unfortunately the mapping is not that direct. The part before the last dash > identifies the USB host controller. The part after the last dash identifies > the device path related to the controller, expressed as a combination of port > numbers. > > The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus number (in > this case 7) that is not present in usb_make_path()'s output. > > To find the sysfs path of your USB peripheral, you will have to find out > which > bus number the bus name (:00:1d.7) corresponds to. You might be able to > find that by checking each usb[0-9]+ links in /sys/bus/usb/devices and > comparing the link's target with the bus name. > To ease this processing, using libsysfs can be a good idea... On my system, the documentation of libsysfs is here: /usr/doc/sysfsutils-2.1.0/libsysfs.txt Knowing the bus-id, it won't be hard to look at it in data structures. Just my 2 cents. Regard, Thierry -- 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: Hauppauge TD-500
On Thu, Jan 22, 2009 at 3:55 PM, Glen Ford wrote:
> Hi,
>
>
> I am assuming this is the right list to post to.
>
> I recently setup MythBuntu on my system with Hauppauge TD-500 - the
> system worked except for the IR Remote Control - I tried using the
> latest v4l-dvb from the Hg repo to no avail.
>
> I had to make the following changes to dib0700_devices.c in order for
> the remote to be recognised and appear as an event device (other
> changes needed for MythBuntu itself can be found on my ubuntuforum
> post here: http://ubuntuforums.org/showthread.php?p=6509202#post6509202)
>
> r...@pvr:~/dvb/v4l-dvb# hg diff
> diff -r f4d7d0b84940 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
> --- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Sun Jan 18
> 10:55:38 2009 +
> +++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Wed Jan 21
> 19:41:36 2009 +
> @@ -1683,7 +1683,13 @@
>{ &dib0700_usb_id_table[43], NULL },
>{ NULL },
>}
> - }
> + },
> +
> + .rc_interval = DEFAULT_RC_INTERVAL,
> + .rc_key_map = dib0700_rc_keys,
> + .rc_key_map_size = ARRAY_SIZE(dib0700_rc_keys),
> + .rc_query = dib0700_rc_query
> +
>}, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
>
>.num_adapters = 1
>
> Regards,
>
>
> Glen
Hello Glen,
This exact patch has already been merged into my tree (contributed by
Arne Luehrs), and a PULL request was sent to Mauro on Tuesday for it
to go into the mainline v4l-dvb.
http://linuxtv.org/hg/~dheitmueller/dib0700-pbfixes/rev/cf6003290b09
Devin
--
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hauppauge TD-500
Hi,
I am assuming this is the right list to post to.
I recently setup MythBuntu on my system with Hauppauge TD-500 - the
system worked except for the IR Remote Control - I tried using the
latest v4l-dvb from the Hg repo to no avail.
I had to make the following changes to dib0700_devices.c in order for
the remote to be recognised and appear as an event device (other
changes needed for MythBuntu itself can be found on my ubuntuforum
post here: http://ubuntuforums.org/showthread.php?p=6509202#post6509202)
r...@pvr:~/dvb/v4l-dvb# hg diff
diff -r f4d7d0b84940 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Sun Jan 18
10:55:38 2009 +
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Wed Jan 21
19:41:36 2009 +
@@ -1683,7 +1683,13 @@
{ &dib0700_usb_id_table[43], NULL },
{ NULL },
}
- }
+ },
+
+ .rc_interval = DEFAULT_RC_INTERVAL,
+ .rc_key_map = dib0700_rc_keys,
+ .rc_key_map_size = ARRAY_SIZE(dib0700_rc_keys),
+ .rc_query = dib0700_rc_query
+
}, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
.num_adapters = 1
Regards,
Glen
--
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: Request for new pixel format (JPEG2000)
On Thursday 22 January 2009 21:37:00 Mauro Carvalho Chehab wrote:
> On Thu, 22 Jan 2009 12:03:48 +0200
>
> Vladimir Davydov wrote:
> > On Thursday 22 January 2009 09:19:54 Hans Verkuil wrote:
> > > On Thursday 22 January 2009 06:09:02 Alexey Klimov wrote:
> > > > (added linux-media mail-list)
> > > >
> > > > Hello, Vladimir
> > > >
> > > > On Wed, 2009-01-21 at 21:46 +0200, Vladimir Davydov wrote:
> > > > > Hi,
> > > > > Is it possible to add new pixel format to videodev2.h file?
> > > > >
> > > > > #define V4L2_PIX_FMT_MJ2C v4l2_fourcc('M','J','2','C') /* Morgan
> > > > > JPEG 2000*/
> > > > >
> > > > > I have developed a V4L2 driver for the board with hardware JPEG2000
> > > > > codec (ADV202 chip). This driver uses that pixel format.
> > > > > I think JPEG 2000 is very perspective codec and it will be good if
> > > > > V4L2 will support it.
> > > > >
> > > > > Short description of the device is here:
> > > > > http://www.promwad.com/markets/linux-video-jpeg2000-blackfin.html
> > >
> > > Vladimir,
> > >
> > > It shouldn't be a problem adding this, but we prefer to only add such
> > > things when the driver code is also added at the same time. Are you
> > > going to submit the driver code as well to the list?
> > >
> > > Thanks,
> > >
> > > Hans
> >
> > Hans,
> > I can sibmit the driver code. But this driver is only for the blackfin
> > processor and will not work on other platforms. Does it make sense to
> > include the driver to the kernel source?
> > Maybe it will be better to include this driver to the blackfin.uclinux
> > kernel tree. How do you think?
>
> Please submit the driver to linux-media. The proper place for those drivers
> are under drivers/media. We have also other drivers there that are
> architecture specific (like omap drivers, OLPC, etc).
>
Good, I will prepare the source and submit to linux-media.
> Cheers,
> Mauro.
--
Vladimir Davydov
Senior Developer
Promwad Innovation Company
Web: www.promwad.com
22, Olshevskogo St.,
220073, Minsk,
BELARUS
Phone/Fax: +375 (17) 312–1246
E-mail: vladimir.davy...@promwad.com
Skype: v_davydov
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Fusion HDTV 7 Dual Express
Hi ~ Did you try to do >rmmod cx23885 >modprobe s5h1411 >modprobe xc5000 >modprobe cx23885 everytime you reboot the computer.?! Audrey On Thu, Jan 22, 2009 at 11:42 AM, Joseph Shraibman wrote: > I too am having 0 signal strength with a Fusion HDTV 7 Dual Express. scan > (from dvb-apps) does find channels, but my application won't work because > it is seeing no signal. I tried rebuilding the drivers from repository > tip but it doesn't help. The kernel I'm using is 2.6.27.9-73.fc9.i686. > lspci -v shows: > > 02:00.0 Multimedia video controller: Conexant Unknown device 8852 (rev 04) > Subsystem: DViCO Corporation Unknown device d618 > Flags: bus master, fast devsel, latency 0, IRQ 17 > Memory at fbc0 (64-bit, non-prefetchable) [size=2M] > Capabilities: [40] Express Endpoint, MSI 00 > Capabilities: [80] Power Management version 2 > Capabilities: [90] Vital Product Data > Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/0 Enable- > Capabilities: [100] Advanced Error Reporting > Capabilities: [200] Virtual Channel > Kernel driver in use: cx23885 > Kernel modules: cx23885 > > after "make load" in the v4l-dvb directory dmesg shows: > > cx23885_dvb_register() allocating 1 frontend(s) > cx23885[0]: cx23885 based dvb card > xc5000 1-0064: creating new instance > xc5000: Successfully identified at address 0x64 > xc5000: Firmware has not been loaded previously > DVB: registering new adapter (cx23885[0]) > DVB: registering adapter 1 frontend 0 (Samsung S5H1411 QAM/8VSB > Frontend)... > cx23885_dvb_register() allocating 1 frontend(s) > cx23885[0]: cx23885 based dvb card > xc5000 2-0064: creating new instance > xc5000: Successfully identified at address 0x64 > xc5000: Firmware has not been loaded previously > DVB: registering new adapter (cx23885[0]) > DVB: registering adapter 2 frontend 0 (Samsung S5H1411 QAM/8VSB > Frontend)... > cx23885_dev_checkrevision() New hardware revision found 0x0 > cx23885_dev_checkrevision() Hardware revision unknown 0x0 > cx23885[0]/0: found at :02:00.0, rev: 4, irq: 17, latency: 0, mmio: > 0xfbc0 > cx23885 :02:00.0: setting latency timer to 64 > ivtvfb: no cards found > or51132: Waiting for firmware upload(dvb-fe-or51132-vsb.fw)... > firmware: requesting dvb-fe-or51132-vsb.fw > or51132: Version: 10001134-1943 (113-4-194-3) > or51132: Firmware upload complete. > > > On Thu, 16 Oct 2008, Jonathan Johnson wrote: > >> Hello linux-dvb members, >> >> I know another person posted a message similar to mine, but offered no >> diagnostic info, so I am. >> >> DViCO device d618 using driver cx23885 >> Conexant Device 8852 (rev 02) >> Base OS: SuSE 11.0 >> kernel manually upgraded to 2.6.27 >> checked dmesg, and all firmware(s) load. >> >> I have a FusionHDTV Dual 7 tuner, and it gets no signal at all, and some >> times no channels appear >> when I scan from with in mythtv, and sometimes some of the channels appear. >> >> 1. First I tried hooking a ATI 650 to Vista and got 100% strength all the >> time, so it wasn't the antenna. >> 2. I then hooked up the FusionHDTV card to Vista and it also reported 100% >> signal strength. >> Therefore the card is not broken. >> 3. I have 2 ATI HDTV Wonder that have always worked perfectly, so signal >> strength is good. >> >> >> When trying to record w/ MythTV I get >> - >> This occurs a couple times. >> DVBSM(/dev/dvb/adapter1/frontend0), Warning can not measuer S/N >> The following occurs many times: >> DVBChan(3:/dev/dvb/adapter1/frontend0) Error: Tune(): Setting Frontend >> using tuning parameters failed. >> "eno: Invalid argument (22)" >> --- >> >> Spent 1/2 hour looking thru google results. >> I decided despite how horrible luck I have with compiling certain things, I >> would give it a go anyway. >> The kernel always compiles for me at least. I went to linuxtv.org and >> followed the instructions. >> I did the make and make install and got the invalid symbols mentioned on the >> website, and it said >> reboot. So I did, and I recompiled again, for the heck of it, and still >> have invalid symbols. Read the >> INSTALL text file, and tried a bunch of options.I tried make >> kernel-(something), and recompile the >> kernel(completely), and reboot,and still no go. I tried re-compiling >> v4l-dvb and still nothing. >> I eventually tried "make all" and the compile failed with errors. Could not >> get it to compile, and now >> v4l-dvb was un-usable. >> >> I then installed and did a full compile of kernel 2.6.27.1 (released last >> night), and at least everything >> now works. >> >> I would like to try the development version to see if that fixes things, but >> I am not skilled enough to >> resolved the unresolved symbol problem. insmod and modprobe failed with the >> same error. >> >> >> Later, >> Jonathan >> >> >> --- >> >>
Re: [linux-dvb] Fusion HDTV 7 Dual Express
On Thu, Jan 22, 2009 at 2:42 PM, Joseph Shraibman wrote: > I too am having 0 signal strength with a Fusion HDTV 7 Dual Express. scan > (from dvb-apps) does find channels, but my application won't work because > it is seeing no signal. I tried rebuilding the drivers from repository > tip but it doesn't help. The kernel I'm using is 2.6.27.9-73.fc9.i686. > lspci -v shows: > > 02:00.0 Multimedia video controller: Conexant Unknown device 8852 (rev 04) > Subsystem: DViCO Corporation Unknown device d618 > Flags: bus master, fast devsel, latency 0, IRQ 17 > Memory at fbc0 (64-bit, non-prefetchable) [size=2M] > Capabilities: [40] Express Endpoint, MSI 00 > Capabilities: [80] Power Management version 2 > Capabilities: [90] Vital Product Data > Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/0 Enable- > Capabilities: [100] Advanced Error Reporting > Capabilities: [200] Virtual Channel > Kernel driver in use: cx23885 > Kernel modules: cx23885 > > after "make load" in the v4l-dvb directory dmesg shows: > > cx23885_dvb_register() allocating 1 frontend(s) > cx23885[0]: cx23885 based dvb card > xc5000 1-0064: creating new instance > xc5000: Successfully identified at address 0x64 > xc5000: Firmware has not been loaded previously > DVB: registering new adapter (cx23885[0]) > DVB: registering adapter 1 frontend 0 (Samsung S5H1411 QAM/8VSB > Frontend)... > cx23885_dvb_register() allocating 1 frontend(s) > cx23885[0]: cx23885 based dvb card > xc5000 2-0064: creating new instance > xc5000: Successfully identified at address 0x64 > xc5000: Firmware has not been loaded previously > DVB: registering new adapter (cx23885[0]) > DVB: registering adapter 2 frontend 0 (Samsung S5H1411 QAM/8VSB > Frontend)... > cx23885_dev_checkrevision() New hardware revision found 0x0 > cx23885_dev_checkrevision() Hardware revision unknown 0x0 > cx23885[0]/0: found at :02:00.0, rev: 4, irq: 17, latency: 0, mmio: > 0xfbc0 > cx23885 :02:00.0: setting latency timer to 64 > ivtvfb: no cards found > or51132: Waiting for firmware upload(dvb-fe-or51132-vsb.fw)... > firmware: requesting dvb-fe-or51132-vsb.fw > or51132: Version: 10001134-1943 (113-4-194-3) > or51132: Firmware upload complete. > > > On Thu, 16 Oct 2008, Jonathan Johnson wrote: > >> Hello linux-dvb members, >> >> I know another person posted a message similar to mine, but offered no >> diagnostic info, so I am. >> >> DViCO device d618 using driver cx23885 >> Conexant Device 8852 (rev 02) >> Base OS: SuSE 11.0 >> kernel manually upgraded to 2.6.27 >> checked dmesg, and all firmware(s) load. >> >> I have a FusionHDTV Dual 7 tuner, and it gets no signal at all, and some >> times no channels appear >> when I scan from with in mythtv, and sometimes some of the channels appear. >> >> 1. First I tried hooking a ATI 650 to Vista and got 100% strength all the >> time, so it wasn't the antenna. >> 2. I then hooked up the FusionHDTV card to Vista and it also reported 100% >> signal strength. >> Therefore the card is not broken. >> 3. I have 2 ATI HDTV Wonder that have always worked perfectly, so signal >> strength is good. >> >> >> When trying to record w/ MythTV I get >> - >> This occurs a couple times. >> DVBSM(/dev/dvb/adapter1/frontend0), Warning can not measuer S/N >> The following occurs many times: >> DVBChan(3:/dev/dvb/adapter1/frontend0) Error: Tune(): Setting Frontend >> using tuning parameters failed. >> "eno: Invalid argument (22)" >> --- >> >> Spent 1/2 hour looking thru google results. >> I decided despite how horrible luck I have with compiling certain things, I >> would give it a go anyway. >> The kernel always compiles for me at least. I went to linuxtv.org and >> followed the instructions. >> I did the make and make install and got the invalid symbols mentioned on the >> website, and it said >> reboot. So I did, and I recompiled again, for the heck of it, and still >> have invalid symbols. Read the >> INSTALL text file, and tried a bunch of options.I tried make >> kernel-(something), and recompile the >> kernel(completely), and reboot,and still no go. I tried re-compiling >> v4l-dvb and still nothing. >> I eventually tried "make all" and the compile failed with errors. Could not >> get it to compile, and now >> v4l-dvb was un-usable. >> >> I then installed and did a full compile of kernel 2.6.27.1 (released last >> night), and at least everything >> now works. >> >> I would like to try the development version to see if that fixes things, but >> I am not skilled enough to >> resolved the unresolved symbol problem. insmod and modprobe failed with the >> same error. >> >> >> Later, >> Jonathan >> >> >> --- >> >> ___ >> linux-dvb mailing list >> linux-...@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb >
Re: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo
On Mon, 19 Jan 2009 10:38:45 +0100
Laurent Pinchart wrote:
> On Monday 19 January 2009, Mauro Carvalho Chehab wrote:
> > On Sun, 18 Jan 2009 21:49:13 +0100
> >
> > Laurent Pinchart wrote:
> > > Mauro,
> > >
> > > Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/
> > >
> > > for the following 3 changesets:
> > >
> > > uvcvideo: replace strn{cpy,cat} with strl{cpy,cat}.
> >
> > Hmm... instead of this:
> >
> > + phys = kasprintf(GFP_KERNEL, "usb-%s-%s", udev->bus->bus_name,
> > +udev->devpath);
> >
> > You should use, instead:
> >
> > usb_make_path(udev, phys, sizeof(phys));
> >
> > This is easier to read and it should become a standard to fill bus_name on
> > usb drivers, since it produces a canonical name.
>
> input->name isn't a fixed-size buffer but a dynamically allocated one, so I
> can't use usb_make_path as-is. Reading the code, the phys buffer is currently
> leaked, so I'll have to fix it anyway.
>
> Switching to a fixed-size buffer is possible and 64 bytes seems to be a
> sensible value. Most USB input devices seem to set phys to usb_make_path()
> + "/input0". Is there an authoritative source of information regarding how
> the phys field should be formatted ?
No. I've seen some drivers adding /input0 as well. I guess we should discuss
this issue with linux event guys.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request for new pixel format (JPEG2000)
On Thu, 22 Jan 2009 12:03:48 +0200
Vladimir Davydov wrote:
> On Thursday 22 January 2009 09:19:54 Hans Verkuil wrote:
> > On Thursday 22 January 2009 06:09:02 Alexey Klimov wrote:
> > > (added linux-media mail-list)
> > >
> > > Hello, Vladimir
> > >
> > > On Wed, 2009-01-21 at 21:46 +0200, Vladimir Davydov wrote:
> > > > Hi,
> > > > Is it possible to add new pixel format to videodev2.h file?
> > > >
> > > > #define V4L2_PIX_FMT_MJ2C v4l2_fourcc('M','J','2','C') /* Morgan JPEG
> > > > 2000*/
> > > >
> > > > I have developed a V4L2 driver for the board with hardware JPEG2000
> > > > codec (ADV202 chip). This driver uses that pixel format.
> > > > I think JPEG 2000 is very perspective codec and it will be good if V4L2
> > > > will support it.
> > > >
> > > > Short description of the device is here:
> > > > http://www.promwad.com/markets/linux-video-jpeg2000-blackfin.html
> >
> > Vladimir,
> >
> > It shouldn't be a problem adding this, but we prefer to only add such
> > things when the driver code is also added at the same time. Are you going
> > to submit the driver code as well to the list?
> >
> > Thanks,
> >
> > Hans
>
> Hans,
> I can sibmit the driver code. But this driver is only for the blackfin
> processor and will not work on other platforms. Does it make sense to include
> the driver to the kernel source?
> Maybe it will be better to include this driver to the blackfin.uclinux kernel
> tree. How do you think?
Please submit the driver to linux-media. The proper place for those drivers are
under drivers/media. We have also other drivers there that are architecture
specific (like omap drivers, OLPC, etc).
Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Am Thu, 22 Jan 2009 16:57:36 +0100 schrieb Laurent Pinchart : > On Thursday 22 January 2009, Carsten Meier wrote: > > Am Thu, 22 Jan 2009 00:20:00 +0100 > > > > schrieb Laurent Pinchart : > > > Hi Carsten, > > > > > > On Wednesday 21 January 2009, Carsten Meier wrote: > > > > now I want to translate bus_info into a sysfs-path to obtain > > > > device-info like serial numbers. Given a device reports > > > > "usb-:00:1d.2-2" as bus_info, then the device-info is > > > > located under "/sys/bus/usb/devices/2-2", which is a symlink to > > > > the appropriate /sys/devices/ directory, right? > > > > > > I'm afraid not. In the above bus_info value, :00:1d.2 is the > > > PCI bus path of your USB controller, and the last digit after the > > > dash is the USB device path. > > > > > > > All I have to do is to compare the first 4 chars of bus_info > > > > against "usb-", get the chars after "." and append it to > > > > "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > > > > > > > > Is there a more elegant solution or already a function for > > > > this? Can the "." appear more than once before the last one? > > > > > > Probably not before, but definitely after. > > > > > > Root hubs get a USB device path set to '0'. Every other device is > > > numbered according to the hub port number it is connected to. If > > > you have an external hub connected on port 2 of your root hub, > > > and have a webcam connected to port 3 of the external hub, > > > usb_make_path() will return "usb-:00:1d.2-2.3". > > > > > > Cheers, > > > > > > Laurent Pinchart > > > > Hi, > > > > On my machine, my pvrusb2 (connected directly to my mini-pc) shows > > up under "/sys/bus/usb/devices/7-2/" which is a symbolic link to > > "../../../devices/pci:00/:00:1d.7/usb7/7-2" > > You're just lucky that USB bus 7 (usb7/7) is connected to the 7th > function of your USB host controller (1d.7). > > Here's an example of what I get on my computer: > > /sys/bus/usb/devices/4-2 > -> ../../../devices/pci:00/:00:1d.2/usb4/4-2 > > > I can't test for the new bus_info-string, because it's not fixed > > yet in the driver. But if I got it correctly it should be > > "usb-:00:1d.7-7.2" ? > > I think you will get usb-:00:1d.7-2 > > > Then I've to simply take the string after the last dash, replace > > "." by "-" and append it to "/sys/bus/usb/devices/" for a > > sysfs-path? > > Unfortunately the mapping is not that direct. The part before the > last dash identifies the USB host controller. The part after the last > dash identifies the device path related to the controller, expressed > as a combination of port numbers. > > The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus > number (in this case 7) that is not present in usb_make_path()'s > output. > > To find the sysfs path of your USB peripheral, you will have to find > out which bus number the bus name (:00:1d.7) corresponds to. You > might be able to find that by checking each usb[0-9]+ links > in /sys/bus/usb/devices and comparing the link's target with the bus > name. > > Best regards, > > Laurent Pinchart Hi Laurent, could you please post what your video-device reports for bus_info together with the /sys/bus/usb-path where it shows up and the location where the symlink points to? This thing makes me going nuts... :( Thanks, Carsten -- 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] WARNINGS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Thu Jan 22 19:00:06 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10265:f4d7d0b84940 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK 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-rc2-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc2-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc2-armv5-omap2: OK linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc2-i686: OK linux-2.6.16.61-m32r: OK linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc2-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc2-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc2-powerpc64: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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-rc2-x86_64: OK fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc2): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 -- 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
gspca_spca505
Ooops! ;) I'm having some visual problems so you'll have to bear with me for the next few months. OK, I copy and pasted your debug level of 63, yes 63, into the echo command and outputted the result of svv -rg from dmesg into the file, kernel.txt. I did NOT detach and reattach the camera in this latter case. For the time being, I'm leaving my e-mail address alone. I will change it in time. You can reach me at t,p,r'e'i,t.z,e'l AT hotmail.com. Naturally, omit the punctuation in my id. Your listed echo command should output to .../module/... not .../modules/... Also, my system doesn't have a kern.log so I used dmesg | grep spca instead and outputted the result to kernel.txt Furthermore, I noticed after my last correspondence that the camera works perfectly when I powered the system off for approximately 10 seconds and rebooted. The FIRST attempt to run svv worked flawlessly. After exiting svv and trying again, the video was garbled from that point onward so it might be an initialization problem. I have NOT tried to recompile spca505.c with the change yet. I'll wait until I hear from you again via my address at hotmail.com Also, I clearly remember when M. Xhaard revamped the spca5xx driver a few years ago. When he did, the internal capture card stopped working. I even e-mailed M. about the problem, but nothing positive resulted from it. gspca: packet [4] o:4092 l:1023 gspca: packet [5] o:5115 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:2 o:3 gspca: add t:1 l:1013 gspca: packet [6] o:6138 l:1023 gspca: packet [7] o:7161 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:3 o:3 gspca: add t:1 l:1013 gspca: poll gspca: dqbuf gspca: frame wait q:3 i:3 o:0 gspca: dqbuf 3 gspca: qbuf 3 gspca: qbuf q:0 i:3 o:0 gspca: poll gspca: dqbuf gspca: frame wait q:0 i:3 o:1 gspca: dqbuf 0 gspca: qbuf 0 gspca: qbuf q:1 i:3 o:1 gspca: poll gspca: dqbuf gspca: frame wait q:1 i:3 o:2 gspca: dqbuf 1 gspca: qbuf 1 gspca: qbuf q:2 i:3 o:2 gspca: poll gspca: dqbuf gspca: frame wait q:2 i:3 o:3 gspca: dqbuf 2 gspca: qbuf 2 gspca: qbuf q:3 i:3 o:3 gspca: poll gspca: isoc irq gspca: packet [0] o:0 l:1023 gspca: packet [1] o:1023 l:1023 gspca: add t:3 l:0 gspca: add t:1 l:1013 gspca: packet [2] o:2046 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:0 o:3 gspca: add t:1 l:1013 gspca: packet [3] o:3069 l:1023 gspca: packet [4] o:4092 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:1 o:3 gspca: add t:1 l:1013 gspca: packet [5] o:5115 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:2 o:3 gspca: add t:1 l:1013 gspca: packet [6] o:6138 l:1023 gspca: packet [7] o:7161 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:3 o:3 gspca: add t:1 l:1013 gspca: poll gspca: dqbuf gspca: frame wait q:3 i:3 o:0 gspca: dqbuf 3 gspca: qbuf 3 gspca: qbuf q:0 i:3 o:0 gspca: poll gspca: dqbuf gspca: frame wait q:0 i:3 o:1 gspca: dqbuf 0 gspca: qbuf 0 gspca: qbuf q:1 i:3 o:1 gspca: poll gspca: dqbuf gspca: frame wait q:1 i:3 o:2 gspca: dqbuf 1 gspca: qbuf 1 gspca: qbuf q:2 i:3 o:2 gspca: poll gspca: dqbuf gspca: frame wait q:2 i:3 o:3 gspca: dqbuf 2 gspca: qbuf 2 gspca: qbuf q:3 i:3 o:3 gspca: poll gspca: isoc irq gspca: packet [0] o:0 l:1023 gspca: add t:3 l:0 gspca: add t:1 l:1013 gspca: packet [1] o:1023 l:1023 gspca: packet [2] o:2046 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:0 o:3 gspca: add t:1 l:1013 gspca: packet [3] o:3069 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:1 o:3 gspca: add t:1 l:1013 gspca: packet [4] o:4092 l:1023 gspca: packet [5] o:5115 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:2 o:3 gspca: add t:1 l:1013 gspca: packet [6] o:6138 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:3 o:3 gspca: add t:1 l:1013 gspca: poll gspca: dqbuf gspca: frame wait q:3 i:3 o:0 gspca: dqbuf 3 gspca: qbuf 3 gspca: qbuf q:0 i:3 o:0 gspca: poll gspca: dqbuf gspca: frame wait q:0 i:3 o:1 gspca: dqbuf 0 gspca: qbuf 0 gspca: qbuf q:1 i:3 o:1 gspca: poll gspca: dqbuf gspca: frame wait q:1 i:3 o:2 gspca: dqbuf 1 gspca: qbuf 1 gspca: qbuf q:2 i:3 o:2 gspca: poll gspca: dqbuf gspca: frame wait q:2 i:3 o:3 gspca: dqbuf 2 gspca: qbuf 2 gspca: qbuf q:3 i:3 o:3 gspca: poll gspca: isoc irq gspca: packet [0] o:0 l:1023 gspca: add t:3 l:0 gspca: add t:1 l:1013 gspca: packet [1] o:1023 l:1023 gspca: packet [2] o:2046 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:0 o:3 gspca: add t:1 l:1013 gspca: packet [3] o:3069 l:1023 gspca: packet [4] o:4092 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:1 o:3 gspca: add t:1 l:1013 gspca: packet [5] o:5115 l:1023 gspca: packet [6] o:6138 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:2 o:3 gspca: add t:1 l:1013 gspca: packet [7] o:7161 l:1023 gspca: add t:3 l:0 gspca: frame complete len:1013 q:3 i:3 o:3 gspca: add t:1 l:1013 gspca: poll gspca: dqbuf gspca: frame wait q:3 i:3 o:0 gspca: dqbuf 3 gspca: qb
Re: [linux-dvb] HVR-1800 Support
On Wed, Jan 21, 2009 at 12:08 AM, Killero SS wrote: > i'm using ubuntu 8.10 2.6.27-9-generic > and tried compiling latest modules with hg-clone but my analog capture got > broken, firmware error... > so i got back to original kernel modules > however, some people claim they get audio with analog on /dev/video1 > this has never be my case, im using svideo signal so wondering if that may be > it. > i get analog video on video0 and video1, but some colors look pretty weird, > red for example. > > another thing this card has fm radio, anyone knows how to set it up? i've > been unable to find any info regarding this > > I never got Svideo in working on my 1800. I ended up selling it and getting a 1600. -Mark -- 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/~pinchartl/uvcvideo
Mauro,
Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/
for the following 4 changesets:
uvcvideo: replace strn{cpy,cat} with strl{cpy,cat}.
uvcvideo: Add support for the Alcor Micro AU3820 chipset.
uvcvideo: Retry URB buffers allocation when the system is low on memory.
uvcvideo: Fix memory leak in input device handling
uvc_ctrl.c |2 -
uvc_driver.c | 27 +---
uvc_status.c | 16 ++-
uvc_v4l2.c | 12
uvc_video.c | 79 +++
uvcvideo.h |7 ++---
6 files changed, 74 insertions(+), 69 deletions(-)
Thanks,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Thursday 22 January 2009, Carsten Meier wrote: > Am Thu, 22 Jan 2009 00:20:00 +0100 > > schrieb Laurent Pinchart : > > Hi Carsten, > > > > On Wednesday 21 January 2009, Carsten Meier wrote: > > > now I want to translate bus_info into a sysfs-path to obtain > > > device-info like serial numbers. Given a device reports > > > "usb-:00:1d.2-2" as bus_info, then the device-info is located > > > under "/sys/bus/usb/devices/2-2", which is a symlink to the > > > appropriate /sys/devices/ directory, right? > > > > I'm afraid not. In the above bus_info value, :00:1d.2 is the PCI > > bus path of your USB controller, and the last digit after the dash is > > the USB device path. > > > > > All I have to do is to compare the first 4 chars of bus_info against > > > "usb-", get the chars after "." and append it to > > > "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > > > > > > Is there a more elegant solution or already a function for this? Can > > > the "." appear more than once before the last one? > > > > Probably not before, but definitely after. > > > > Root hubs get a USB device path set to '0'. Every other device is > > numbered according to the hub port number it is connected to. If you > > have an external hub connected on port 2 of your root hub, and have a > > webcam connected to port 3 of the external hub, usb_make_path() will > > return "usb-:00:1d.2-2.3". > > > > Cheers, > > > > Laurent Pinchart > > Hi, > > On my machine, my pvrusb2 (connected directly to my mini-pc) shows up > under "/sys/bus/usb/devices/7-2/" which is a symbolic link to > "../../../devices/pci:00/:00:1d.7/usb7/7-2" You're just lucky that USB bus 7 (usb7/7) is connected to the 7th function of your USB host controller (1d.7). Here's an example of what I get on my computer: /sys/bus/usb/devices/4-2 -> ../../../devices/pci:00/:00:1d.2/usb4/4-2 > I can't test for the new bus_info-string, because it's not fixed yet in > the driver. But if I got it correctly it should be > "usb-:00:1d.7-7.2" ? I think you will get usb-:00:1d.7-2 > Then I've to simply take the string after the last dash, replace "." by "-" > and append it to "/sys/bus/usb/devices/" for a sysfs-path? Unfortunately the mapping is not that direct. The part before the last dash identifies the USB host controller. The part after the last dash identifies the device path related to the controller, expressed as a combination of port numbers. The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus number (in this case 7) that is not present in usb_make_path()'s output. To find the sysfs path of your USB peripheral, you will have to find out which bus number the bus name (:00:1d.7) corresponds to. You might be able to find that by checking each usb[0-9]+ links in /sys/bus/usb/devices and comparing the link's target with the bus name. Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L/DVB: fix v4l2_device_call_all/v4l2_device_call_until_err macro
> When these macros aren't called with 'grp_id' this will result in a > build failure. Hi Roel, Thanks, however it is fixed already in the v4l-dvb repo so it should appear upstream as soon as Mauro prepares the next pull request. Regards, Hans > > Signed-off-by: Roel Kluin > --- > diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h > index 9bf4ccc..ad86caa 100644 > --- a/include/media/v4l2-device.h > +++ b/include/media/v4l2-device.h > @@ -94,16 +94,16 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev > *sd); > /* Call the specified callback for all subdevs matching grp_id (if 0, > then > match them all). Ignore any errors. Note that you cannot add or delete > a subdev while walking the subdevs list. */ > -#define v4l2_device_call_all(dev, grp_id, o, f, args...) \ > +#define v4l2_device_call_all(dev, _grp_id, o, f, args...)\ > __v4l2_device_call_subdevs(dev, \ > - !(grp_id) || sd->grp_id == (grp_id), o, f , ##args) > + !(_grp_id) || sd->grp_id == (_grp_id), o, f , ##args) > > /* Call the specified callback for all subdevs matching grp_id (if 0, > then > match them all). If the callback returns an error other than 0 or > -ENOIOCTLCMD, then return with that error code. Note that you cannot > add or delete a subdev while walking the subdevs list. */ > -#define v4l2_device_call_until_err(dev, grp_id, o, f, args...) > \ > +#define v4l2_device_call_until_err(dev, _grp_id, o, f, args...) > \ > __v4l2_device_call_subdevs_until_err(dev, \ > -!(grp_id) || sd->grp_id == (grp_id), o, f , ##args) > +!(_grp_id) || sd->grp_id == (_grp_id), o, f , ##args) > > #endif > > -- > 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 > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] V4L/DVB: fix v4l2_device_call_all/v4l2_device_call_until_err macro
When these macros aren't called with 'grp_id' this will result in a build failure. Signed-off-by: Roel Kluin --- diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h index 9bf4ccc..ad86caa 100644 --- a/include/media/v4l2-device.h +++ b/include/media/v4l2-device.h @@ -94,16 +94,16 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev *sd); /* Call the specified callback for all subdevs matching grp_id (if 0, then match them all). Ignore any errors. Note that you cannot add or delete a subdev while walking the subdevs list. */ -#define v4l2_device_call_all(dev, grp_id, o, f, args...) \ +#define v4l2_device_call_all(dev, _grp_id, o, f, args...) \ __v4l2_device_call_subdevs(dev, \ - !(grp_id) || sd->grp_id == (grp_id), o, f , ##args) + !(_grp_id) || sd->grp_id == (_grp_id), o, f , ##args) /* Call the specified callback for all subdevs matching grp_id (if 0, then match them all). If the callback returns an error other than 0 or -ENOIOCTLCMD, then return with that error code. Note that you cannot add or delete a subdev while walking the subdevs list. */ -#define v4l2_device_call_until_err(dev, grp_id, o, f, args...) \ +#define v4l2_device_call_until_err(dev, _grp_id, o, f, args...) \ __v4l2_device_call_subdevs_until_err(dev, \ - !(grp_id) || sd->grp_id == (grp_id), o, f , ##args) + !(_grp_id) || sd->grp_id == (_grp_id), o, f , ##args) #endif -- 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
saa7134-alsa.ko and alsa-driver-1.0.19
Hi everybody Has anyone of you got the saa7134-alsa module running with alsa-driver-1.0.19 ? r...@mythtv:~# modprobe -v saa7134-alsa insmod /lib/modules/2.6.27.8/kernel/drivers/media/video/saa7134/saa7134-alsa.ko FATAL: Error inserting saa7134_alsa (/lib/modules/2.6.27.8/kernel/drivers/media/video/saa7134/saa7134-alsa.ko): Unknown symbol in module, or unknown parameter (see dmesg) r...@mythtv:~# dmesg |less [ 7543.401381] Linux video capture interface: v2.00 [ 7543.412129] saa7130/34: v4l2 driver version 0.2.14 loaded [ 7543.412157] saa7133[0]: found at :04:00.0, rev: 209, irq: 16, latency: 64, mmio: 0xfebff800 [ 7543.412162] saa7133[0]: subsystem: 1043:4845, board: ASUSTeK P7131 Analog [card=146,insmod option] [ 7543.412170] saa7133[0]: board init: gpio is 0 [ 7543.412210] input: saa7134 IR (ASUSTeK P7131 Analo as /devices/pci:00/:00:1e.0/:04:00.0/input/input9 [ 7543.558005] saa7133[0]: i2c eeprom 00: 43 10 45 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [ 7543.558022] saa7133[0]: i2c eeprom 10: 00 ff e2 0f ff 20 ff ff ff ff ff ff ff ff ff ff [ 7543.558038] saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 88 ff ff ff ff [ 7543.558054] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558071] saa7133[0]: i2c eeprom 40: ff 22 00 c2 96 ff 02 30 15 ff ff ff ff ff ff ff [ 7543.558086] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558102] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558118] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558136] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558152] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558168] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558184] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558195] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558206] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558216] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.558227] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 7543.578071] tuner 1-004b: chip found @ 0x96 (saa7133[0]) [ 7543.613005] tda829x 1-004b: setting tuner address to 61 [ 7543.649006] tda829x 1-004b: type set to tda8290+75a [ 7546.226225] saa7133[0]: registered device video0 [v4l2] [ 7546.226270] saa7133[0]: registered device vbi0 [ 7546.226312] saa7133[0]: registered device radio0 [ 7546.258185] saa7134_alsa: Unknown symbol snd_card_new i needed to upgrade the alsa driver in order to get the 00:1b.0 Audio device: Intel Corporation ICH10 HD Audio Controller soundcard propperly running, so using the alsa out of the kernel source (using 2.6.27.8 right now) is not an option do you have any ideas? i have read somthing about editing the #ifdef-s in compat.h but i have to admit that i don-t understand what to do there. Thanks a lot in advance! Ben -- 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: gspca_spca505
On Wed, 21 Jan 2009 15:07:30 -0700
"T.P. Reitzel" <4066724...@vzwmail.net> wrote:
> OK, I've raised the level of debug to 15 as you requested.
I found no interesting information in your traces: the debug level is
too low and there is only the probe sequence. Please, may you do,
as root:
echo 0x3f > /sys/modules/gspca_main/parameters/debug
then, as user, run:
svv -rg
then, as root again, do:
grep spca /var/log/kern.log > spca.log
and send me the file 'spca.log'? Thank you.
I may have found a problem. May you try to change the line 399 of
linux/drivers/media/gspca/spca505.c from:
#define initial_brightness 0x7f /* 0x0(white)-0xff(black) */
to:
#define initial_brightness 0 /* 0x0(white)-0xff(black) */
BTW, your email address ("T.P. Reitzel" <4066724...@vzwmail.net>) is not
correct. Please, may you fix it before posting again?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request for new pixel format (JPEG2000)
On Thursday 22 January 2009 09:19:54 Hans Verkuil wrote:
> On Thursday 22 January 2009 06:09:02 Alexey Klimov wrote:
> > (added linux-media mail-list)
> >
> > Hello, Vladimir
> >
> > On Wed, 2009-01-21 at 21:46 +0200, Vladimir Davydov wrote:
> > > Hi,
> > > Is it possible to add new pixel format to videodev2.h file?
> > >
> > > #define V4L2_PIX_FMT_MJ2C v4l2_fourcc('M','J','2','C') /* Morgan JPEG
> > > 2000*/
> > >
> > > I have developed a V4L2 driver for the board with hardware JPEG2000
> > > codec (ADV202 chip). This driver uses that pixel format.
> > > I think JPEG 2000 is very perspective codec and it will be good if V4L2
> > > will support it.
> > >
> > > Short description of the device is here:
> > > http://www.promwad.com/markets/linux-video-jpeg2000-blackfin.html
>
> Vladimir,
>
> It shouldn't be a problem adding this, but we prefer to only add such
> things when the driver code is also added at the same time. Are you going
> to submit the driver code as well to the list?
>
> Thanks,
>
> Hans
Hans,
I can sibmit the driver code. But this driver is only for the blackfin
processor and will not work on other platforms. Does it make sense to include
the driver to the kernel source?
Maybe it will be better to include this driver to the blackfin.uclinux kernel
tree. How do you think?
With best regards,
Vladimir
>
> > > Thanks,
> > > Vladimir.
> >
> > Please, send patches and other e-mails related to drivers development to
> > linux-media@vger.kernel.org
> > Such tool like patchwork.kernel.org will cares about patches, so they
> > don't lost.
> >
> > I think you already check this page
> > http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
> > if not, please check.
--
Vladimir Davydov
Senior Developer
Promwad Innovation Company
Web: www.promwad.com
22, Olshevskogo St.,
220073, Minsk,
BELARUS
Phone/Fax: +375 (17) 312–1246
E-mail: vladimir.davy...@promwad.com
Skype: v_davydov
--
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: [REVIEW PATCH 01/14] V4L: Int if: Dummy slave
Mauro Carvalho Chehab wrote:
On Mon, 12 Jan 2009 20:03:08 -0600
"Aguirre Rodriguez, Sergio Alberto" wrote:
+static struct v4l2_int_slave dummy_slave = {
+ /* Dummy pointer to avoid underflow in find_ioctl. */
+ .ioctls = (void *)0x8000,
Why are you using here a magic number?
Not really a reason. It could be or actually perhaps anything equal to
or bigger than sizeof(struct v4l2_int_ioctl_desc) so that last doesn't
underflow:
const struct v4l2_int_ioctl_desc *first = slave->ioctls;
const struct v4l2_int_ioctl_desc *last =
first + slave->num_ioctls - 1;
num_ioctls is zero. See find_ioctl in drivers/media/video/v4l2-int-device.c.
I guess that should be changed to sizeof(struct v4l2_int_ioctl_desc).
--
Sakari Ailus
sakari.ai...@nokia.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
