Re: [PATCH] Add support for RoverMedia TV Link Pro FM v3
Hello Hermann! > hm, because not printing tda9887 and tuner type set? I checked again. This is not observed now. It seems that repairs antenna at this time. Sorry for my mistake. I will try to accommodate all your wishes. I hope that I will make it. Thank you for your great help and advices! Best Regards, Eugene. -- 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] Add support for RoverMedia TV Link Pro FM
This patch add support for RoverMedia TV Link Pro FM (LR138 REV:I) card based
on saa7134.
Signed-off-by: Eugene Yudin
Best Regards,
Eugene
diff -r ad2f24d34b83 linux/Documentation/video4linux/CARDLIST.saa7134
--- a/linux/Documentation/video4linux/CARDLIST.saa7134 Fri Aug 28 04:12:06 2009 -0300
+++ b/linux/Documentation/video4linux/CARDLIST.saa7134 Sat Aug 29 15:53:10 2009 +0400
@@ -168,3 +168,4 @@
167 -> Beholder BeholdTV 609 RDS[5ace:6092]
168 -> Beholder BeholdTV 609 RDS[5ace:6093]
169 -> Compro VideoMate S350/S300 [185b:c900]
+170 -> RoverMedia TV Link Pro FM[19d1:0138]
diff -r ad2f24d34b83 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Aug 28 04:12:06 2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sat Aug 29 15:53:10 2009 +0400
@@ -5182,6 +5182,56 @@
.amux = LINE1
} },
},
+ [SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM] = {
+ /* RoverMedia TV Link Pro FM (LR138 REV:I) */
+ /* Eugene Yudin */
+ .name = "RoverMedia TV Link Pro FM",
+ .audio_clock = 0x0020,
+ .tuner_type = TUNER_PHILIPS_FM1216ME_MK3, /* TCL MFPE05 2 */
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT,
+ .gpiomask = 0xe000,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .gpio = 0x8000,
+ .tv = 1,
+ },{
+ .name = name_tv_mono,
+ .vmux = 1,
+ .amux = LINE2,
+ .gpio = 0x,
+ .tv = 1,
+ },{
+ .name = name_comp1,
+ .vmux = 0,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ },{
+ .name = name_comp2,
+ .vmux = 3,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ },{
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE2,
+ .gpio = 0x4000,
+ }},
+ .radio = {
+ .name = name_radio,
+ .amux = LINE2,
+ .gpio = 0x2000,
+ },
+ .mute = {
+ .name = name_mute,
+ .amux = TV,
+ .gpio = 0x8000,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -6296,6 +6346,12 @@
.subdevice= 0xc900,
.driver_data = SAA7134_BOARD_VIDEOMATE_S350,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7134,
+ .subvendor= 0x19d1, /* RoverMedia */
+ .subdevice= 0x0138, /* LifeView FlyTV Prime30 OEM */
+ .driver_data = SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
@@ -6656,6 +6712,7 @@
case SAA7134_BOARD_REAL_ANGEL_220:
case SAA7134_BOARD_KWORLD_PLUS_TV_ANALOG:
case SAA7134_BOARD_AVERMEDIA_GO_007_FM_PLUS:
+ case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
dev->has_remote = SAA7134_REMOTE_GPIO;
break;
case SAA7134_BOARD_FLYDVBS_LR300:
diff -r ad2f24d34b83 linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Fri Aug 28 04:12:06 2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Sat Aug 29 15:53:10 2009 +0400
@@ -456,6 +456,7 @@
case SAA7134_BOARD_FLYVIDEO3000:
case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
+ case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
ir_codes = ir_codes_flyvideo;
mask_keycode = 0xEC0;
mask_keydown = 0x004;
diff -r ad2f24d34b83 linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h Fri Aug 28 04:12:06 2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134.h Sat Aug 29 15:53:10 2009 +0400
@@ -294,6 +294,7 @@
#define SAA7134_BOARD_BEHOLD_609RDS_MK3 167
#define SAA7134_BOARD_BEHOLD_609RDS_MK5 168
#define SAA7134_BOARD_VIDEOMATE_S350169
+#define SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM 170
#define SAA7134_MAXBOARDS 32
#define SAA7134_INPUT_MAX 8
Re: [PATCH 1/6] Updated Support for TVP7002 in v4l2 definitions
On Saturday 29 August 2009 01:26:56 santiago.nu...@ridgerun.com wrote:
> From: Santiago Nunez-Corrales
>
> This patch provides required std and control definitions in TVP7002
> within v4l2. Removed HD definitions.
>
> Signed-off-by: Santiago Nunez-Corrales
> ---
> include/linux/videodev2.h | 25 +
> include/media/v4l2-chip-ident.h |3 +++
> 2 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 74f1687..685bc7e 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -1147,6 +1147,31 @@ enum v4l2_exposure_auto_type {
>
> #define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
>
> +
> +/* tvp7002 control IDs*/
> +#define V4L2_CID_TVP7002_BASEV4L2_CTRL_CLASS_DECODER
> +#define V4L2_CID_TVP7002_COARSE_GAIN_R (V4L2_CID_TVP7002_BASE
> + 1)
> +#define V4L2_CID_TVP7002_COARSE_GAIN_G (V4L2_CID_TVP7002_BASE
> + 2)
> +#define V4L2_CID_TVP7002_COARSE_GAIN_B (V4L2_CID_TVP7002_BASE
> + 3)
> +#define V4L2_CID_TVP7002_FINE_GAIN_R (V4L2_CID_TVP7002_BASE + 4)
> +#define V4L2_CID_TVP7002_FINE_GAIN_G (V4L2_CID_TVP7002_BASE + 5)
> +#define V4L2_CID_TVP7002_FINE_GAIN_B (V4L2_CID_TVP7002_BASE + 6)
> +#define V4L2_CID_TVP7002_B_CLAMP (V4L2_CID_TVP7002_BASE + 7)
> +#define V4L2_CID_TVP7002_G_CLAMP (V4L2_CID_TVP7002_BASE + 8)
> +#define V4L2_CID_TVP7002_R_CLAMP (V4L2_CID_TVP7002_BASE + 9)
> +#define V4L2_CID_TVP7002_CLAMP_OFF_EN(V4L2_CID_TVP7002_BASE
> + 10)
> +#define V4L2_CID_TVP7002_FCTCA (V4L2_CID_PRIVATE_BASE
> + 11)
> +#define V4L2_CID_TVP7002_F_CLAMP_GB (V4L2_CID_TVP7002_BASE + 12)
> +#define V4L2_CID_TVP7002_F_CLAMP_R (V4L2_CID_TVP7002_BASE + 13)
> +#define V4L2_CID_TVP7002_CLAMP_START (V4L2_CID_TVP7002_BASE + 14)
> +#define V4L2_CID_TVP7002_CLAMP_W (V4L2_CID_TVP7002_BASE + 15)
> +#define V4L2_CID_TVP7002_B_COARSE_OFF(V4L2_CID_TVP7002_BASE
> + 16)
> +#define V4L2_CID_TVP7002_G_COARSE_OFF(V4L2_CID_TVP7002_BASE
> + 17)
> +#define V4L2_CID_TVP7002_R_COARSE_OFF(V4L2_CID_TVP7002_BASE
> + 18)
> +#define V4L2_CID_TVP7002_B_FINE_OFF (V4L2_CID_TVP7002_BASE + 19)
> +#define V4L2_CID_TVP7002_G_FINE_OFF (V4L2_CID_TVP7002_BASE + 20)
> +#define V4L2_CID_TVP7002_R_FINE_OFF (V4L2_CID_TVP7002_BASE + 21)
Are there applications that actually need these controls? I do not
feel comfortable exposing such low-level controls to user-space in this way.
This is a recurring topic (if and how to expose low-level functionality) and
I have some ideas on how to solve this in the future. But for now I prefer it
if these are not exported yet.
BTW: only patch 1/6 is cross-posted to the linux-media list. I'm not sure if
that was intentional or an accident.
Regards,
Hans
> +
> /*
> * T U N I N G
> */
> diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
> index 56b31cb..14c83b5 100644
> --- a/include/media/v4l2-chip-ident.h
> +++ b/include/media/v4l2-chip-ident.h
> @@ -129,6 +129,9 @@ enum {
> V4L2_IDENT_SAA6752HS = 6752,
> V4L2_IDENT_SAA6752HS_AC3 = 6753,
>
> + /* module tvp7002: just ident 7002 */
> + V4L2_IDENT_TVP7002 = 7002,
> +
> /* module adv7170: just ident 7170 */
> V4L2_IDENT_ADV7170 = 7170,
>
--
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: Nova-TD-500 (84xxx) problems (was Re: dib0700 diversity support)
On 25/08/2009, at 1:31, "Nicolas Will" wrote: On Tue, 2009-08-25 at 00:36 +0930, Malcolm Caldwell wrote: Have you tried adding: dvb_usb_dib0700.force_lna_activation=1 to the modprobe options? The device I had wouldn't tune without this. I should have mentioned that I have tried this and buggy sfn workaround for the relavent modules. I have read that sometimes the problem is not a low signal, but too strong a signal. Have you tried placing an attenuator in front of the card? Ok, I have now tried an attenuator and it did not fix my problem, but made the reception worse. Nico -- 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
RFC: bus configuration setup for sub-devices
Hi all,
This is an updated RFC on how to setup the bus for sub-devices.
It is based on work from Guennadi and Muralidharan.
The problem is that both sub-devices and bridge devices have to configure
their bus correctly so that they can talk to one another. We need a
standard way of configuring such busses.
The soc-camera driver did this by auto-negotiation. For several reasons (see
the threads on bus parameters in the past) I thought that that was not a good
idea. After talking this over last week with Guennadi we agreed that we would
configure busses directly rather than negotiate the bus configuration. It was
a very pleasant meeting (Hans de Goede, Laurent Pinchart, Guennadi Liakhovetski
and myself) and something that we should repeat. Face-to-face meetings make
it so much faster to come to a decision on difficult problems.
My last proposal merged subdev and bridge parameters into one struct, thus
completely describing the bus setup. I realized that there is a problem with
that if you have to define the bus for sub-devices that are in the middle of
a chain: e.g. a sensor sends its video to a image processing subdev and from
there it goes to the bridge. You have to be able to specify both the source and
sink part of each bus for that image processing subdev.
It's much easier to do that by keeping the source and sink bus config
separate.
Here is my new proposal:
/*
* Some sub-devices are connected to the host/bridge device through a bus that
* carries the clock, vsync, hsync and data. Some interfaces such as BT.656
* carries the sync embedded in the data whereas others have separate lines
* carrying the sync signals.
*/
struct v4l2_bus_config {
/* embedded sync, set this when sync is embedded in the data stream */
unsigned embedded_sync:1;
/* master or slave */
unsigned is_master:1;
/* bus width */
unsigned width:8;
/* 0 - active low, 1 - active high */
unsigned pol_vsync:1;
/* 0 - active low, 1 - active high */
unsigned pol_hsync:1;
/* 0 - low to high, 1 - high to low */
unsigned pol_field:1;
/* 0 - sample at falling edge, 1 - sample at rising edge */
unsigned edge_pclock:1;
/* 0 - active low, 1 - active high */
unsigned pol_data:1;
};
It's all bitfields, so it is a very compact representation.
In video_ops we add two new functions:
int (*s_source_bus_config)(struct v4l2_subdev *sd, const struct
v4l2_bus_config *bus);
int (*s_sink_bus_config)(struct v4l2_subdev *sd, const struct
v4l2_bus_config *bus);
Actually, if there are no subdevs that can act as sinks then we should omit
s_sink_bus_config for now.
In addition, I think we need to require that at the start of the s_*_bus_config
implementation in the host or subdev there should be a standard comment
block describing the possible combinations supported by the hardware:
/* This hardware supports the following bus settings:
widths: 8/16
syncs: embedded or separate
bus master: slave
vsync polarity: 0/1
hsync polarity: 0/1
field polarity: not applicable
sampling edge pixelclock: 0/1
data polarity: 1
*/
This should make it easy for implementers to pick a valid set of bus
parameters.
Eagle-eyed observers will note that the bus type field has disappeared from
this proposal. The problem with that is that I have no clue what it is supposed
to do. Is there more than one bus that can be set up? In that case it is not a
bus type but a bus ID. Or does it determine that type of data that is being
transported over the bus? In that case it does not belong here, since that is
something for a s_fmt type API.
This particular API should just setup the physical bus. Nothing more, IMHO.
Please let me know if I am missing something here.
Guennadi, from our meeting I understood that you also want a way provide
an offset in case the data is actually only on some pins (e.g. the lower
or upper X pins are always 0). I don't think it is hard to provide support
for that in this API by adding an offset field or something like that.
Can you give me a pointer to the actual place where that is needed? Possibly
also with references to datasheets? I'd like to understand this better.
Sakari, this proposal is specific to parallel busses. I understood that Nokia
also has to deal with serial busses. Can you take a look at this proposal with
a serial bus in mind?
This bus config stuff has been in limbo for too long, so I'd like to come
to a conclusion and implementation in 1-2 weeks.
Regards,
Hans
--
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: [Fwd: How to debug problem with Playstation Eye webcam?]
> Forwarded Message > From: Tim Bird > I'm trying to get a Playstation Eye webcam working under a new install of > Fedora 11 and not having much luck. > > I'm running a stock Fedora kernel (2.6.29.4). > Hi Tim, before doing any further investigation about code in 2.6.29.4, forgive the silly question: is using a more recent kernel/driver an option for you? I've just tried latest code from v4l-dvb and it "just works" with the applications I use. You can get the mercurial repository here http://linuxtv.org/hg/v4l-dvb I know that there was a regression in 2.6.30 (not sure about 2.6.29.4) and a patch has been sent by Jim Paris to fix it, I don't know if it is already in a 2.6.30.x release, tho. The change is this one: http://patchwork.kernel.org/patch/42114/ > When I plug in the device, /dev/video0 is created, and the modules > gspca_main and gspca_ov534 are loaded into the kernel. > > The device responds to QUERYCAP and other interrogation commands > from user space, but when my test program actually tries to read > the device, I get a multi-second delay, and an eventual > errno of EIO. > I tested the driver with "mplayer" and "luvcview" during development, and I am now using it with "cheese", I've never run v4l-test. > I ran v4l-test version 0.19, and some tests succeeded and others failed. > Results are shown below. Note that I had to disable the test > "VIDIOC_G_CTRL with NULL parameter", because that resulted in a hang > of v4l-test when run against the 'Eye' webcam. > I confirm this happens also with the "just working" latest version. > A logitech web camera has mixed results from v4l-test as well > (succeeding and failing in different places from the Playstation Eye). > But the logitech works fine with my test program and a variety of > other programs. > > I'm not sure where to look next to continue debugging this. > I assume that the general relationship of components is: > test program ->linux kernel -> gspca main driver -> > USB and ov534 driver -> USB and camera hardware > > Any tips for how to figure out where the problem might be, > reports of previous experience with this webcam, or additional > diagnostic tools or techniques would be much appreciated. > I'd give a run to _latest_ code to see if the problem has been solved already, and if you really can't use it, then you isolate the fix and apply it to the code you have to use. Captain Obvious to the rescue :) > Thanks, > -- Tim > > = > Tim Bird > Architecture Group Chair, CE Linux Forum > Senior Staff Engineer, Sony Corporation of America > = > Regards, Antonio Ospite -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgpogafruQkjR.pgp Description: PGP signature
Re: [Fwd: How to debug problem with Playstation Eye webcam?]
Antonio Ospite wrote: > > Forwarded Message > > From: Tim Bird > > > I'm trying to get a Playstation Eye webcam working under a new install of > > Fedora 11 and not having much luck. > > > > I'm running a stock Fedora kernel (2.6.29.4). > > > > Hi Tim, > > before doing any further investigation about code in 2.6.29.4, forgive > the silly question: is using a more recent kernel/driver an option for > you? > I've just tried latest code from v4l-dvb and it "just works" with the > applications I use. You can get the mercurial repository here > http://linuxtv.org/hg/v4l-dvb > > I know that there was a regression in 2.6.30 (not sure about 2.6.29.4) > and a patch has been sent by Jim Paris to fix it, I don't know if it is > already in a 2.6.30.x release, tho. The change is this one: > http://patchwork.kernel.org/patch/42114/ I believe 2.6.29.4 should be okay. However, the Fedora folks might have pulled some newer patches which also added the bug. You might try a stock 2.6.29.4 kernel instead of Fedora's, or just apply the patch that Antonio refers to (if thta's the problem). If your kernel does have the same bug, the symptoms would be as you described, with the camera's red LED turning on during an attempted capture. Do you get the red LED? You would also probably see the same problem, regardless of kernel version, if the camera were connected to a full-speed instead of high-speed USB port. > I tested the driver with "mplayer" and "luvcview" during development, > and I am now using it with "cheese", I've never run v4l-test. Agreed. luvcview is probably the easiest to test with, and I can provide command lines for mplayer, ffmpeg, etc, if necessary. -jim -- 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: Using MSI StarCam 370i Webcam with Kubuntu Linux
2009/8/28 Thomas Kaiser : > On 08/28/2009 08:40 PM, Dotan Cohen wrote: >> >> I have the MSI StarCam 370i Webcam and I have trying to use it with >> Kubuntu Linux 9.04 Jaunty. According to this page, "The StarCam 370i >> is compliant with UVC, USB video class": >> >> http://gadgets.softpedia.com/gadgets/Computer-Peripherals/The-MSI-StarCam-370i-3105.html >> >> According to the Linux UVC driver and tools download page, "Linux >> 2.6.26 and newer includes the Linux UVC driver natively" which is nice >> as I am on a higher version: >> $ uname -r >> 2.6.28-15-generic >> >> However, plugging in the webcam and testing with camorama, cheese, and >> luvcview led me to no results: >> >> jaun...@laptop:~$ luvcview -f yuv >> luvcview 0.2.4 >> >> SDL information: >> Video driver: x11 >> A window manager is available >> Device information: >> Device path: /dev/video0 >> Stream settings: >> ERROR: Requested frame format YUYV is not available and no fallback >> format was found. >> Init v4L2 failed !! exit fatal >> jaun...@laptop:~$ luvcview -f uyvy >> luvcview 0.2.4 >> >> SDL information: >> Video driver: x11 >> A window manager is available >> Device information: >> Device path: /dev/video0 >> Stream settings: >> ERROR: Requested frame format UYVY is not available and no fallback >> format was found. >> Init v4L2 failed !! exit fatal >> jaun...@laptop:~$ luvcview >> luvcview 0.2.4 >> >> SDL information: >> Video driver: x11 >> A window manager is available >> Device information: >> Device path: /dev/video0 >> Stream settings: >> ERROR: Requested frame format MJPG is not available and no fallback >> format was found. >> Init v4L2 failed !! exit fatal >> >> >> Some more details: >> >> jaun...@laptop:~$ ls /dev/vi* >> /dev/video0 >> jaun...@laptop:~$ dmesg | tail >> [ 2777.811972] sn9c102: V4L2 driver for SN9C1xx PC Camera Controllers >> v1:1.47pre49 >> [ 2777.814989] usb 2-1: SN9C105 PC Camera Controller detected (vid:pid >> 0x0C45:0x60FC) >> [ 2777.842123] usb 2-1: HV7131R image sensor detected >> [ 2778.185108] usb 2-1: Initialization succeeded >> [ 2778.185220] usb 2-1: V4L2 device registered as /dev/video0 >> [ 2778.185225] usb 2-1: Optional device control through 'sysfs' >> interface disabled >> [ 2778.185283] usbcore: registered new interface driver sn9c102 >> [ 2778.216691] usbcore: registered new interface driver snd-usb-audio >> [ 2778.218738] usbcore: registered new interface driver sonixj >> [ 2778.218745] sonixj: registered >> jaun...@laptop:~$ lsusb >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 005 Device 002: ID 413c:8126 Dell Computer Corp. Wireless 355 >> Bluetooth >> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 004 Device 004: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical >> Bus 004 Device 003: ID 045e:00db Microsoft Corp. Natural Ergonomic >> Keyboard 4000 V1.0 >> Bus 004 Device 002: ID 05e3:0604 Genesys Logic, Inc. USB 1.1 Hub >> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 002 Device 002: ID 0c45:60fc Microdia PC Camera with Mic (SN9C105) >> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> jaun...@laptop:~$ >> >> >> >> Anything missing? What should I do? Thanks in advance! > > Hello Dotan, me again ;-) > > Looks like your cam is detected, but does not provide a good frame format. > You my have to use libv4l to convert to a know format. > > See: http://hansdegoede.livejournal.com/7622.html > Thanks. I will go through that tomorrow, but in the meantime I got a strange result. Despite the fact that this is a 32 bit Kubuntu install, I got these results from the tests at the beginning of the page: jaun...@laptop:~$ ls -d /usr/lib64 /usr/lib64 jaun...@laptop:~$ ls -d /usr/lib32 ls: cannot access /usr/lib32: No such file or directory jaun...@laptop:~$ According to what is written, with those results I should use the Fedora multilib instructions. Does that not sound unusual? -- Dotan Cohen http://what-is-what.com http://gibberish.co.il -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Aug 29 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12564:6f58a5d8c7c6 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc8-armv5: OK linux-2.6.31-rc8-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-rc8-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-rc8-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc8-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc8-m32r: OK linux-2.6.30-mips: ERRORS linux-2.6.31-rc8-mips: OK linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc8-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc8-x86_64: WARNINGS sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc8): 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: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS 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: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The 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
[PATCH] V4L/DVB (12098): dereference of state->internal in fe_stv0900_error stv0900_init_internal()
state->internal allocation may fail as well as the allocation of
stv0900_first_inode or new_node->next_inode in append_internal().
Signed-off-by: Roel Kluin
---
Is this the right thing to do if temp_int == NULL?
diff --git a/drivers/media/dvb/frontends/stv0900_core.c
b/drivers/media/dvb/frontends/stv0900_core.c
index 1da045f..b0aaf90 100644
--- a/drivers/media/dvb/frontends/stv0900_core.c
+++ b/drivers/media/dvb/frontends/stv0900_core.c
@@ -1407,7 +1407,14 @@ static enum fe_stv0900_error
stv0900_init_internal(struct dvb_frontend *fe,
return STV0900_NO_ERROR;
} else {
state->internal = kmalloc(sizeof(struct stv0900_internal),
GFP_KERNEL);
+ if (state->internal == NULL)
+ return STV0900_INVALID_HANDLE;
temp_int = append_internal(state->internal);
+ if (temp_int == NULL) {
+ kfree(state->internal);
+ state->internal == NULL;
+ return STV0900_INVALID_HANDLE;
+ }
state->internal->dmds_used = 1;
state->internal->i2c_adap = state->i2c_adap;
state->internal->i2c_addr = state->config->demod_address;
--
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: Using MSI StarCam 370i Webcam with Kubuntu Linux
On 08/29/2009 06:57 PM, Dotan Cohen wrote: 2009/8/28 Thomas Kaiser : On 08/28/2009 08:40 PM, Dotan Cohen wrote: I have the MSI StarCam 370i Webcam and I have trying to use it with Kubuntu Linux 9.04 Jaunty. According to this page, "The StarCam 370i is compliant with UVC, USB video class": http://gadgets.softpedia.com/gadgets/Computer-Peripherals/The-MSI-StarCam-370i-3105.html According to the Linux UVC driver and tools download page, "Linux 2.6.26 and newer includes the Linux UVC driver natively" which is nice as I am on a higher version: $ uname -r 2.6.28-15-generic However, plugging in the webcam and testing with camorama, cheese, and luvcview led me to no results: jaun...@laptop:~$ luvcview -f yuv luvcview 0.2.4 SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: ERROR: Requested frame format YUYV is not available and no fallback format was found. Init v4L2 failed !! exit fatal jaun...@laptop:~$ luvcview -f uyvy luvcview 0.2.4 SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: ERROR: Requested frame format UYVY is not available and no fallback format was found. Init v4L2 failed !! exit fatal jaun...@laptop:~$ luvcview luvcview 0.2.4 SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: ERROR: Requested frame format MJPG is not available and no fallback format was found. Init v4L2 failed !! exit fatal Some more details: jaun...@laptop:~$ ls /dev/vi* /dev/video0 jaun...@laptop:~$ dmesg | tail [ 2777.811972] sn9c102: V4L2 driver for SN9C1xx PC Camera Controllers v1:1.47pre49 [ 2777.814989] usb 2-1: SN9C105 PC Camera Controller detected (vid:pid 0x0C45:0x60FC) [ 2777.842123] usb 2-1: HV7131R image sensor detected [ 2778.185108] usb 2-1: Initialization succeeded [ 2778.185220] usb 2-1: V4L2 device registered as /dev/video0 [ 2778.185225] usb 2-1: Optional device control through 'sysfs' interface disabled [ 2778.185283] usbcore: registered new interface driver sn9c102 [ 2778.216691] usbcore: registered new interface driver snd-usb-audio [ 2778.218738] usbcore: registered new interface driver sonixj [ 2778.218745] sonixj: registered jaun...@laptop:~$ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 002: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 004: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical Bus 004 Device 003: ID 045e:00db Microsoft Corp. Natural Ergonomic Keyboard 4000 V1.0 Bus 004 Device 002: ID 05e3:0604 Genesys Logic, Inc. USB 1.1 Hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 0c45:60fc Microdia PC Camera with Mic (SN9C105) Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub jaun...@laptop:~$ Anything missing? What should I do? Thanks in advance! Hello Dotan, me again ;-) Looks like your cam is detected, but does not provide a good frame format. You my have to use libv4l to convert to a know format. See: http://hansdegoede.livejournal.com/7622.html Thanks. I will go through that tomorrow, but in the meantime I got a strange result. Despite the fact that this is a 32 bit Kubuntu install, I got these results from the tests at the beginning of the page: jaun...@laptop:~$ ls -d /usr/lib64 /usr/lib64 jaun...@laptop:~$ ls -d /usr/lib32 ls: cannot access /usr/lib32: No such file or directory jaun...@laptop:~$ According to what is written, with those results I should use the Fedora multilib instructions. Does that not sound unusual? Yes, this looks somehow strange. I don't have a 32 bit system at the moment to verify. You know you have 32 bit, then just use the none multilib instructions. You can install the version which ships with Ubuntu: sudo apt-get install libv4l-0 then do, To use a v4l1 aware application this should do it: LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so For a v4l2 aware application you should use: LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so to convert to a known video format. Thomas -- 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] Infrared Keycode standardization
Em Fri, 28 Aug 2009 09:30:42 -0300 Mauro Carvalho Chehab escreveu: > Em Fri, 28 Aug 2009 12:50:27 +0200 (CEST) > Patrick Boettcher escreveu: > > > Hi Mauro, > > > > On Fri, 28 Aug 2009, Mauro Carvalho Chehab wrote: > > > > > Em Fri, 28 Aug 2009 00:46:28 -0300 > > > Mauro Carvalho Chehab escreveu: > > > > > >> So, we need a sort of TODO list for IR changes. A start point (on a > > >> random > > >> order) would be something like: > > >> > > >> 2) Implement a v4l handler for EVIOCGKEYCODE/EVIOCSKEYCODE; > > >> 3) use a different arrangement for IR tables to not spend 16 K for IR > > >> table, > > >> yet allowing RC5 full table; > > >> 4) Use the common IR framework at the dvb drivers with their own > > >> iplementation; > > >> 5) Allow getkeycode/setkeycode to work with the dvb framework using the > > >> new > > >> methods; > > > > > > Ok, I have a code that handles the above for dvb-usb. Se enclosed. It > > > turned to be > > > simpler than what I've expected originally ;) > > > > Yeah, this is due to the nature of modularity of dvb-usb. > > Yes, but I was afraid that we would need to use a different struct for IR's. > This feature is already available for years at V4L, but the tables needed to > use scancode as their indexes to use the default handlers (I'm not sure, but > afaik, in the past there weren't ways to override them). > > > Saying that, all > > drivers which have (re)implemented IR-handling needs to ported as well. Or > > included in dvb-usb :P . > > My suggestion is to port the current implementation to ir-common.ko. This > module is not dependent of any other V4L or DVB specifics and has already > some code to handle GPIO polling based and GPIO IRQ based IR's. It contains > some IR tables for IR's that are used also on dvb-usb, like Hauppauge IR > keycodes. > > Yet, we will need first to change ir-common.ko, since it is currently using > the > tables indexed by a 7bit scancode (due to size constraints, V4L code discards > one RC5 byte), but this is already on our todo list (due to keycode > standardization). Ok, I've did several changes on both V4L and dvb-usb IR implementations. They scancode tables are now implemented at the same way, at: http://linuxtv.org/hg/~mchehab/IR I've also added there the current version of the getkeycode/setkeycode patch. Ah, the v4l2-apps/util/Makefile will now generate the scancode userspace tables for DVB IR's as well (currently, we have 85 IR layouts generated from source files). What's still missing: - For now, V4L is still using internally the old decoding process, based on the 7bit array of keycode. - I haven't yet added some extra empty data at dvb scancode tables; - although they're using the same structs, the code is still different. Please review. 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
[PULL] soc-camera: fix compiler warnings
Hi Mauro, Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following changeset: 01/01: soc-camera: remove now unneeded subdevice group ID assignments http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=aa426bbc82af soc_camera.c |1 - soc_camera_platform.c |1 - 2 files changed, 2 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pinnacle PCTV 310i active antenna
Hi Martin, Am Freitag, den 28.08.2009, 18:27 +0200 schrieb Martin Konopka: > Hallo Hermann, > > ich schreibe einmal abseits der Maillingliste, da ich eine Frage zu Windows > habe. Ich konnte mit meiner PCTV 310i die Antennenspannung in der Tv-Software > von Pinnacle nicht aktivieren, da das Feld "Aktivantennen" grau war. Konntest > Du die Antennenspannung dort aktivieren? Der einzige Unterschied scheint eine > etwas neuere Hardwareversion bei mir als bei Dir zu sein: Yes, as replied in German, I can get voltage to the antenna in windows on my card. The older driver from 2005 provides a tool to manually switch it on or off at any time, the current driver has only voltage for DVB-T and that tool is gone. > saa7133[0]: found at :04:06.0, rev: 209, irq: 20, latency: 64, mmio: > 0xfbfff800 > > Ziel ist es aber natürlich, die Spannung unter Linux zu aktivieren. :-) Yes, of course. We don't know, if it is on all cards the same and if all cards do support it. In combination with the LNA unknowns it might improve the mess not to know that too. A testhack, not a clean implementation, is attached and should give you voltage to the active antenna when using DVB-T. BTW, the radio seems to be broken since some weeks. It is not by that patch here. Cheers, Hermann > Vielen Dank! > > Martin > Am Freitag, 28. August 2009 03:08:27 schrieben Sie: > > Hi Martin, > > > > Am Dienstag, den 28.07.2009, 06:15 +0200 schrieb hermann pitton: > > > Hi Martin, > > > > > > Am Montag, den 27.07.2009, 21:36 +0200 schrieb Martin Konopka: > > > > Hi Hermann, > > > > > > > > I'm using kernel 2.6.28-11 on a mythbuntu distribution. I tried to > > > > load the drivers with the card=50 option and antenna_pwr=1. > > > > > > > > [ 8745.007384] saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV > > > > 300i DVB-T + PAL [card=50,insmod option] > > > > [ 8745.007628] saa7133[0]: board init: gpio is 600c000 > > > > [ 8745.007641] saa7133[0]: gpio: mode=0x0008000 in=0x6004000 > > > > out=0x0008000 [pre-init] > > > > [ 8745.148374] tuner' 1-004b: chip found @ 0x96 (saa7133[0]) > > > > > > > > [..] > > > > > > > > [ 8802.196576] dvb_init() allocating 1 frontend > > > > [ 8802.196583] saa7133[0]/dvb: pinnacle 300i dvb setup > > > > [ 8802.196845] mt352_read_register: readreg error (reg=127, ret==-5) > > > > [ 8802.196953] saa7133[0]/dvb: frontend initialization failed > > > > > > > > The antenna power is not activated. I then installed microsoft stuff. > > > > To my horror it turned out that the active antenna switch is greyed out > > > > in Pinnacle's TV application. > > > > > > > > So the card obviously does not have an active antenna, although the > > > > manual mentions it. Probably copy and paste from the 300i manual. > > > > > > > > Regards, > > > > > > > > Martin > > > > > > thanks a lot for reporting and for going to all that testing stuff. > > > > > > Since neither Hartmut nor me ever had such a card, Hartmut would be much > > > better than me on such, we should be able to exclude active voltage to > > > support the antenna on it now. > > > > > > For the other issues since 2.6.26 I don't have new ideas and such cards > > > seem not to be available on some e/xbay currently. > > > > > > The Hauppauge/Pinnacle US guys can't help much either currently and > > > there is no reason to blame them for something they don't know. (yet) > > > > > > So it is only what is posted so far. > > > > > > Thanks, > > > Hermann > > > > also for the record. > > > > The early variant of the 310i I have now has clearly support for 5 Volt > > antenna output. Easy to measure. > > > > I can install currently three different driver versions under vista, all > > with different gpio configuration. The one for testing the 5 Volt switch > > for now is with the original driver CD from 2005. > > > > Unfortunately, it has also these always changing gpios, like the TS > > interface is always on, but the voltage switch is no problem on vista > > with that old XP driver. Other stuff is ... > > > > dmesg from mine. > > > > saa7133[1]: registered device video1 [v4l2] > > saa7133[1]: registered device vbi1 > > saa7133[2]: setting pci latency timer to 64 > > saa7133[2]: found at :04:03.0, rev: 208, irq: 21, latency: 64, mmio: > > 0xfebfe800 saa7133[2]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i > > [card=101,insmod option] saa7133[2]: board init: gpio is 600e000 > > IRQ 21/saa7133[2]: IRQF_DISABLED is not guaranteed on shared IRQs > > saa7133[2]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 > > saa7133[2]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2c b0 22 ff ff > > saa7133[2]: i2c eeprom 20: 01 2c 01 02 02 01 04 30 98 ff 00 a5 ff 21 00 c2 > > saa7133[2]: i2c eeprom 30: 96 10 03 32 15 20 ff ff 0c 22 17 88 03 44 31 f9 > > saa7133[2]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff f
Re: [linux-dvb] Can ir polling be turned off in cx88 module for Leadtek 1000DTV card?
Thanks for looking into this Andy.
I modified your patch a bit (attached) I guess because the kernel version I'm
using (ubuntu 8.04, 2.6.24-24) isn't the most recent?
Anyway, I have attached the patch incase anyone else wants to use it with this
particular version. Also, I had to apply the option (in /etc/modprobe/options)
options cx88xx noir=1,1
rather than to cx88. Not sure if this is something to do with having an older
kernel version, but it worked. I followed instructions at
https://wiki.ubuntu.com/KernelCustomBuild re building modules. Now I can turn
off or on the polling which is very handy.
I'm sure others would find this useful too - can I suggest this as a feature
anywhere? As an extension/alternative, what about an option to control the
rate of polling - setting the rate to 0 would disable the polling altogether -
not setting it at all would use the default rate.
--- On Thu, 8/27/09, Andy Walls wrote:
> From: Andy Walls
> Subject: Re: [linux-dvb] Can ir polling be turned off in cx88 module for
> Leadtek 1000DTV card?
> To: linux-media@vger.kernel.org
> Cc: linux-...@linuxtv.org
> Date: Thursday, August 27, 2009, 9:30 AM
> On Wed, 2009-08-26 at 07:33 -0700,
> Dalton Harvie wrote:
> > Hi,
> >
> > I'm no expert with this stuff but have been using
> mythtv under ubuntu
> > for a while. Lately the machine became quite
> sluggish.
> >
> > I have two Leadtek 1000DTV cards and a usb remote in a
> ubuntu 8.04
> > (2.6.24-24-generic) machine with the standard packaged
> kernel.
> >
> > >From /var/log/dmesg
> > [ 56.656386] cx88[0]: subsystem:
> 107d:665f, board: WinFast DTV1000-T
> > [card=35,autodetected]
> >
> >
> > I installed powertop and found that there were 500
> wakeups/s occuring
> > from `run_workqueue (ir_timer)' which I assume is to
> do with polling
> > the built in remote receiver on these tuner
> cards. I no longer use
> > these Leadtek remotes, instead using a mceusb type one
> - so would like
> > to stop this polling.
> >
> > I tried a hack with my limited c knowledge - I edited
> cx88-input.c to
> > remove all references to the DTV1000 card (two places)
> and recompiled
> > the modules. Now the rapid polling has
> gone. The reponse of the new
> > mceusb remote seems to be much better now too.
> The problem is that I
> > don't want to have to recompile these modules each
> time there is an
> > update package to the kernel available.
> >
> > My question is - is there any way to stop this polling
> without having
> > to recompile the modules? Some option to pass to
> them maybe?
>
>
> No. No.
>
> > If there isn't, would it be a good
> idea?
>
> Maybe.
>
> > Thanks for any help.
>
>
> Try this. It adds a module option "noir" that accepts
> an array of
> int's. For a 0, that card's IR is set up as normal;
> for a 1, that
> card's IR is not initialized.
>
> # modprobe cx88 noir=1,1
>
> Regards,
> Andy
>
>
> cx88: Add module option for disabling IR
>
> If an IR receiver isn't in use, there's no need to incurr
> the penalties
> for polling.
>
> Reported-by: Dalton Harvie
> Signed-off-by: Andy Walls
>
> diff -r 28f8b0ebd224
> linux/drivers/media/video/cx88/cx88-cards.c
> ---
> a/linux/drivers/media/video/cx88/cx88-cards.c
> Sun Aug 23 13:55:25 2009 -0300
> +++
> b/linux/drivers/media/video/cx88/cx88-cards.c
> Wed Aug 26 19:23:17 2009 -0400
> @@ -32,14 +32,17 @@
> static unsigned int tuner[] = {[0 ... (CX88_MAXBOARDS -
> 1)] = UNSET };
> static unsigned int radio[] = {[0 ... (CX88_MAXBOARDS -
> 1)] = UNSET };
> static unsigned int card[] = {[0 ... (CX88_MAXBOARDS
> - 1)] = UNSET };
> +static unsigned int noir[] = {[0 ... (CX88_MAXBOARDS
> - 1)] = UNSET };
>
> module_param_array(tuner, int, NULL, 0444);
> module_param_array(radio, int, NULL, 0444);
> module_param_array(card, int, NULL, 0444);
> +module_param_array(noir, int, NULL, 0444);
>
> MODULE_PARM_DESC(tuner,"tuner type");
> MODULE_PARM_DESC(radio,"radio tuner type");
> MODULE_PARM_DESC(card,"card type");
> +MODULE_PARM_DESC(noir, "disable IR (default: 0, IR
> enabled)");
>
> static unsigned int latency = UNSET;
> module_param(latency,int,0444);
> @@ -3490,7 +3493,8 @@
> }
>
> cx88_card_setup(core);
> - cx88_ir_init(core, pci);
> + if (!noir[core->nr])
> + cx88_ir_init(core,
> pci);
>
> return core;
> }
>
>
>
> ___
> 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
>
cx88_irpolling_2.6.24-24-generic.diff
Description: Binary data
[PATCH] v4l2: fix typos in INSTALL
From: Márton Németh Fix some typos in INSTALL documentation coming from http://linuxtv.org/hg/v4l-dvb . Priority: low Signed-off-by: Márton Németh --- diff -r 6f58a5d8c7c6 INSTALL --- a/INSTALL Sat Aug 29 09:01:54 2009 -0300 +++ b/INSTALL Sun Aug 30 07:45:10 2009 +0200 @@ -1,7 +1,7 @@ Mauro Carvalho Chehab 2006 Apr 26 V4L/DVB building procedures are based at the use of Makefile rules. -Those rules are close tho the ones at Linux Kernel, to allow an easier +Those rules are close to the ones at Linux Kernel, to allow an easier usage. === @@ -9,7 +9,7 @@ make all == -For those that may want more than just build all stuff there are some +For those who may want more than just build all stuff there are some other interesting parameters to make: == -- 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_sunplus: problem with brightness control
Hi, I am using a "Trust 610 LCD pow...@m Zoom" device in webcam mode (USB ID=06d6:0031). I am running Linux 2.6.31-rc7 updated with the http://linuxtv.org/hg/v4l-dvb repository at version 12564:6f58a5d8c7c6. When I start watching to the webcam picture and change the brightness value then I get the following result. The possible brigthness values are between 0 and 255. for i in $(seq 0 255); do echo $i; v4lctl bright $i; done 0: average image | | lighter images v 127: the most light image | | "jump" in brightness v 128: the most dark image | | lighter images v 255: average image It seems to me that the values 128...255 are really negative numbers, so the possible range should be between -128...127 (two's complement representation) in case of this webcam. Note that the contrast and color controls does not have any jump in the range 0...255. Regards, Márton Németh -- 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
