Re: Upgrading from FC4 to current Linux
On Fri, Oct 2, 2009 at 11:24 PM, Jarod Wilson wrote: >> (Non-emulated) OSS was ditched by the linux kernel folks long ago. And >> I thought xawtv and tvtime were abandon-ware. > > Yeah, seems that way. Though Devin's been talking about maybe starting up a > new tvtime maintenance tree, which Fedora would be happy to contribute to > and track... (nudge, nudge, Devin ;) Yeah, I started working on it when I was at the Plumbers Conference, but haven't wanted to commit to it publicly until I had something working, mainly because it's a project I'm working on in the background (and I've already got three or four such projects). And like most stuff I'm working on, progress can always be sped up considerably if a commercial party comes along and decides its worth sponsoring (but the converse applies as well - progress slows down on background items when I'm working on other sponsored work). In the worst case, tvtime is my target use case for the part of the Media Controller framework that allows you to associate video streams with ALSA and VBI devices, so it *will* get done eventually. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa716x compiling problem
On Fri, Oct 2, 2009 at 1:11 PM, Beepo / Vanguard wrote: > Hi, > > You could try http://mercurial.intuxication.org/hg/s2-liplianin To my knowledge there is no working saa716x driver and I certainly wouldn't expect one from that s2-liplianin tree if jusst.de doesn't have a proper one yet since that's the real dev tree. -- 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] i2c_board_info can be local
On Oct 2, 2009, at 4:47 AM, Jean Delvare wrote: Recent fixes to the em28xx and saa7134 drivers have been overzealous. While the ir-kbd-i2c platform data indeed needs to be persistent, the struct i2c_board_info doesn't, as it is only used by i2c_new_device(). So revert a part of the original fixes, to save some memory. Signed-off-by: Jean Delvare Cc: Mauro Carvalho Chehab Yeah, good call. Acked-by: Jarod Wilson -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrading from FC4 to current Linux
On Oct 2, 2009, at 4:14 PM, Andy Walls wrote: Video used to be easy, plug in the capture device, install xawtv via rpm, and use. However, recent versions of Fedora simply don't work, even on the same hardware, due to /dev/dsp no longer being created and the applications like xawtv or tvtime still looking for it. (Non-emulated) OSS was ditched by the linux kernel folks long ago. And I thought xawtv and tvtime were abandon-ware. Yeah, seems that way. Though Devin's been talking about maybe starting up a new tvtime maintenance tree, which Fedora would be happy to contribute to and track... (nudge, nudge, Devin ;) The people who will be using this are looking for hardware which is still made and sold new, and software which can be installed by a support person who can plug in cards (PCI preferred) or USB devices, and install rpms. rpmfusion, ATrpms, and I even think Fedora have MythTV available now. mplayer is probably also available from 2 of those 3 resources. MythTV and mplayer are both only in RPM Fusion and ATrpms. Both rely on ffmpeg, which is no-go for Fedora itself. For any open source software that implements video and audio decoders, you will need to investigate if you must pay someone licensing fees to use the decoders you need to meet your usage requirements. Fedora has a mechanism in place by which you can pay for the non-free codecs, IIRC. Sort of. If you're using something gstreamer-based (like totem). Fedora used to have codeina (formerly codec-buddy) that would point you at Fluendo's site for some gstreamer codec plugins you could buy. The current world order is PackageKit with a codec plugin that tries to find a plugin that provides the codec in your configured yum repos. Can't recall if it points at Fluendo if nothing is found... -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IR device at I2C address 0x7a
On Oct 2, 2009, at 4:20 PM, hermann pitton wrote: Am Freitag, den 02.10.2009, 13:47 +0200 schrieb Jean Delvare: ... While investigating another issue, I have noticed the following message in the kernel logs of a saa7134 user: i2c-adapter i2c-0: Invalid 7-bit address 0x7a The address in question is attempted by an IR device probe, and is only probed on SAA7134 adapters. The problem with this address is that it is reserved by the I2C specification for 10-bit addressing, and is thus not a valid 7-bit address. Before the conversion of ir-kbd-i2c to the new-style i2c device driver binding model, device probing was done by ir-kbd-i2c itself so no check was done by i2c-core for address validity. But since kernel 2.6.31, probing at address 0x7a will be denied by i2c-core. So, SAA7134 adapters with an IR device at 0x7a are currently broken. Do we know how many devices use this address for IR and which they are? Tracking the changes in the source code, this address was added in kernel 2.6.8 by Gerd Knorr: http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=581f0d1a0ded3e3d4408e5bb7f81b9ee221f6b7a So this would be used by the "Upmost Purple TV" adapter. Question is, are there other? Yes, currently 0x7a is only used by the Upmost Purple TV (Yuan Tun800). Here are some more details. http://archives.devshed.com/forums/linux-97/troubles-with-yuan-tun900-board-detected-as-upmost-purple-tv-1283673.html Support for the card and the i2c remote was added by Wang-Chan Chen. For testers it is useful to know that the card is still not fully supported. It has a NEC D64083GF video enhancer converting TV baseband video from tuner to S-Video and shares the vmux = 7 with the S-Video input. By default it comes up in external S-Video input mode. There is a Pericom videomux on it and we don't know how to switch it. Chen used to boot at first windows, switched there to tuner input and rebooted to GNU/Linux ... Some web research has pointed me to the Yuan TUN-900: http://www.linuxtv.org/pipermail/linux-dvb/2008-January/023405.html but it isn't clear to me whether the device at 0x7a on this adapter is the same as the one on the Purple TV. And saa7134-cards says of the TUN-900: "Remote control not yet implemented" so maybe we can just ignore it for now. Yes, that card has a device at 0xf4/0x7a too. I asked to test the remote with the Upmost Purple TV entry, but never got a reply. As we know these days, radio amux is wrong too on Yuan TUN900 card=66. Last contact to Chen was four years back, but he confirmed that both cards have the same PCI subsystem. Some bytes in the eeprom, meaning unknown, are different, though. If we have to, I could make i2c-core more permissive, but I am rather reluctant to letting invalid addressed being probed, because you never know how complying chips on the I2C bus will react. I am OK supporting invalid addresses if they really exist out there, but the impact should be limited to the hardware in question. If we only have to care about the Upmost Purple TV, then the following patch should solve the problem: For what is known so far. Acked-by: hermann pitton Seems like a sane thing to do to me too, and I've not seen nor heard of any other devices that use 0x7a. (Hell, I wasn't even aware of these ones 'til now). Acked-by: Jarod Wilson -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Skipping commercials?
On Oct 2, 2009, at 9:44 PM, Mikhail Ramendik wrote: Hello, I would like to skip commercials in my dvb recordings. I know mythtv has some methods but I don't really want the hassle of mythtv setup and use. It is relatively early stage software Um. If you say so. Been happily using it for over six years now... and besides, I prefer to have a normal window-based UI. I use kaffeine and except for absence of commercial skipping, like it. Ideally I would want a program to run on an already existing recording, to mark or cut out ads. A Windows program, comskip, exists. It is closed source and its configuration seems opaque. I will still try it under wine, but perhaps there is a better way? MythTV is open-source. Look at the code specific to the mythcommflag binary. Adapt it for stand-alone use. It wouldn't even have to do the actual cutting, just output a cutlist something like gopchop, avidemux or similar could use to set cut points. -- Jarod Wilson ja...@wilsonet.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
Skipping commercials?
Hello, I would like to skip commercials in my dvb recordings. I know mythtv has some methods but I don't really want the hassle of mythtv setup and use. It is relatively early stage software and besides, I prefer to have a normal window-based UI. I use kaffeine and except for absence of commercial skipping, like it. Ideally I would want a program to run on an already existing recording, to mark or cut out ads. A Windows program, comskip, exists. It is closed source and its configuration seems opaque. I will still try it under wine, but perhaps there is a better way? -- Yours, Mikhail Ramendik -- 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: pxa_camera + mt9m1111: Failed to configure for format 50323234
On Fri, 2 Oct 2009, Antonio Ospite wrote: > Hi, > > after updating to 2.6.32-rc2 I can't capture anymore with the setup in the > subject. Indeed:-( Please, verify, that this patch fixes your problem (completely untested), if it does, I'll push it for 2.6.32: pxa_camera: fix camera pixel format configuration A typo prevents correct picel format negotiation with client drivers. Signed-off-by: Guennadi Liakhovetski --- diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c index 6952e96..aa831d5 100644 --- a/drivers/media/video/pxa_camera.c +++ b/drivers/media/video/pxa_camera.c @@ -1432,7 +1432,9 @@ static int pxa_camera_set_fmt(struct soc_camera_device *icd, icd->sense = &sense; cam_f.fmt.pix.pixelformat = cam_fmt->fourcc; - ret = v4l2_subdev_call(sd, video, s_fmt, f); + ret = v4l2_subdev_call(sd, video, s_fmt, &cam_f); + cam_f.fmt.pix.pixelformat = pix->pixelformat; + *pix = cam_f.fmt.pix; icd->sense = NULL; Thanks Guennadi > > Here's the message from userspace: > # ./capture-example > Cannot open '/dev/video0': 22, Invalid argument > which is from the very first open() call. > > Here's the relevant snippet from dmesg with debug enabled: > [ 15.613749] i2c /dev entries driver > [ 15.626308] Linux video capture interface: v2.00 > [ 15.640834] pxa27x-camera pxa27x-camera.0: Limiting master clock to > 2600 > [ 15.648696] pxa27x-camera pxa27x-camera.0: LCD clock 10400Hz, target > freq 2600Hz, divisor 1 > [ 15.656494] pxa27x-camera pxa27x-camera.0: got DMA channel 1 > [ 15.665398] pxa27x-camera pxa27x-camera.0: got DMA channel (U) 2 > [ 15.673461] pxa27x-camera pxa27x-camera.0: got DMA channel (V) 3 > [ 15.686771] camera 0-0: Probing 0-0 > [ 15.707545] pxa27x-camera pxa27x-camera.0: Registered platform device at > cc889380 data c03a1e98 > [ 15.715265] pxa27x-camera pxa27x-camera.0: pxa_camera_activate: Init gpios > [ 15.723488] pxa27x-camera pxa27x-camera.0: PXA Camera driver attached to > camera 0 > [ 15.739092] mt9m111 0-005d: read reg.00d -> 0008 > [ 15.743812] mt9m111 0-005d: write reg.00d = 0008 -> 0 > [ 15.748702] mt9m111 0-005d: read reg.00d -> 0008 > [ 15.753237] mt9m111 0-005d: write reg.00d = 0009 -> 0 > [ 15.757864] mt9m111 0-005d: read reg.00d -> 0009 > [ 15.762386] mt9m111 0-005d: write reg.00d = 0029 -> 0 > [ 15.766938] mt9m111 0-005d: read reg.00d -> 0029 > [ 15.771670] mt9m111 0-005d: write reg.00d = 0008 -> 0 > [ 15.776136] mt9m111 0-005d: write reg.0c8 = 970b -> 0 > [ 15.781325] mt9m111 0-005d: read reg.106 -> 700e > [ 15.785695] mt9m111 0-005d: write reg.106 = 700e -> 0 > [ 15.792896] mt9m111 0-005d: read reg.000 -> 143a > [ 15.796790] mt9m111 0-005d: Detected a MT9M11x chip ID 143a > [ 15.805505] pxa27x-camera pxa27x-camera.0: Providing format Planar YUV422 > 16 bit using CbYCrY 16 bit > [ 15.813285] pxa27x-camera pxa27x-camera.0: Providing format CbYCrY 16 bit > packed > [ 15.820729] pxa27x-camera pxa27x-camera.0: Providing format CrYCbY 16 bit > packed > [ 15.828221] pxa27x-camera pxa27x-camera.0: Providing format YCbYCr 16 bit > packed > [ 15.835484] pxa27x-camera pxa27x-camera.0: Providing format YCrYCb 16 bit > packed > [ 15.842888] pxa27x-camera pxa27x-camera.0: Providing format RGB 565 packed > [ 15.850455] pxa27x-camera pxa27x-camera.0: Providing format RGB 555 packed > [ 15.858077] pxa27x-camera pxa27x-camera.0: Providing format Bayer (sRGB) 8 > bit in pass-through mode > [ 15.872455] pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from > camera 0 > ... > [ 70.377781] pxa27x-camera pxa27x-camera.0: Registered platform device at > cc889380 data c03a1e98 > [ 70.377866] pxa27x-camera pxa27x-camera.0: pxa_camera_activate: Init gpios > [ 70.378259] pxa27x-camera pxa27x-camera.0: PXA Camera driver attached to > camera 0 > [ 70.378336] mt9m111 0-005d: mt9m111_s_fmt fmt=50323234 left=24, top=8, > width=1280, height=1024 > [ 70.379630] mt9m111 0-005d: write reg.002 = 0018 -> 0 > [ 70.380589] mt9m111 0-005d: write reg.001 = 0008 -> 0 > [ 70.382382] mt9m111 0-005d: write reg.1a0 = 0500 -> 0 > [ 70.383347] mt9m111 0-005d: write reg.1a3 = 0400 -> 0 > [ 70.384312] mt9m111 0-005d: write reg.1a1 = 0500 -> 0 > [ 70.385267] mt9m111 0-005d: write reg.1a4 = 0400 -> 0 > [ 70.386227] mt9m111 0-005d: write reg.1a6 = 0500 -> 0 > [ 70.387188] mt9m111 0-005d: write reg.1a9 = 0400 -> 0 > [ 70.393180] mt9m111 0-005d: write reg.1a7 = 0500 -> 0 > [ 70.394155] mt9m111 0-005d: write reg.1aa = 0400 -> 0 > [ 70.394224] mt9m111 0-005d: Pixel format not handled : 50323234 > [ 70.394265] pxa27x-camera pxa27x-camera.0: Failed to configure for format > 50323234 > [ 70.394310] pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from > camera 0 > > Format 50323234 is 422P, it looks like pxa-camera is trying to force > its native format to the sensor, but I am still inve
Re: mt9t031-VPFE integration issues...
Hi Murali On Fri, 2 Oct 2009, Karicheri, Muralidharan wrote: > I am currently integrating latest MT9T031 driver to vpfe_capture driver > and see following issues:- > > 1) Currently MT9T031 Kconfig configuration variable has a dependency on > SOC_CAMERA. We need to remove this dependency since this sensor can be > used on other platforms like DM6446/DM355/DM365. This is trivial and I > can send a patch to remove the dependency. > > 2) The code still has reference to soc_camera_device and associated > changes. I think this should be removed so that it can be used on other > platforms as well. I am expecting these will go away once the bus > parameter as well data format related RFCs are approved. If this is > true, I can wait until the same is approved. If not, we need to work > together so that this driver can be integrated with vpfe capture driver. You're certainly right - soc-camera based drivers, including mt9t031, still depend on the soc-camera core, although most of the API has been converted to v4l2-subdev. Yes, the two biggest issues are bus-parameter and data-format negotiation. Also, we'll have to find a way to supply the data to the drivers, that is currently set in platform code. So, ideally, yes, we have to wait until the respective RFCs get implemented and until soc-camera gets completely converted, but if this is something urgent - maybe it would be acceptable to start modifying some drivers for "dual operation" - either with soc-camera API or in pure v4l2-subdev mode. This would be a bit of an extra work, and I don't know what others think about this. So, if you can wait, perhaps, this would be the best. Thanks Guennadi --- Guennadi Liakhovetski -- 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] Global video buffers pool
Laurent Pinchart ideasonboard.com> writes: > > Hi Stefan, > > On Monday 28 September 2009 16:04:58 Stefan.Kost nokia.com wrote: > > hi, > > > > >-Original Message- > > >From: ext Laurent Pinchart [mailto:laurent.pinchart ideasonboard.com] > > >Sent: 16 September, 2009 18:47 > > >To: linux-media vger.kernel.org; Hans Verkuil; Sakari Ailus; > > >Cohen David.A (Nokia-D/Helsinki); Koskipaa Antti > > >(Nokia-D/Helsinki); Zutshi Vimarsh (Nokia-D/Helsinki); Kost > > >Stefan (Nokia-D/Helsinki) > > >Subject: [RFC] Global video buffers pool > > > > > > Hi everybody, > > > > > > I didn't want to miss this year's pretty flourishing RFC > > > season, so here's another one about a global video buffers pool. > > > > Sorry for ther very late reply. > > No worries, better late than never. > > > I have been thinking about the problem on a bit broader scale and see the > > need for something more kernel wide. E.g. there is some work done from intel > > for graphics: > > http://keithp.com/blogs/gem_update/ > > > > and this is not so much embedded even. If there buffer pools are > > v4l2specific then we need to make all those other subsystems like xvideo, > > opengl, dsp-bridges become v4l2 media controllers. > > The global video buffers pool topic has been discussed during the v4l2 mini- > summit at Portland last week, and we all agreed that it needs more research. > > The idea of having pools at the media controller level has been dropped in > favor of a kernel-wide video buffers pool. Whether we can make the buffers > pool not v4l2-specific still needs to be tested. As you have pointed out, we > currently have a GPU memory manager in the kernel, and being able to interact > with it would be very interesting if we want to DMA video data to OpenGL > texture buffers for instance. I'm not sure if that would be possible though, > as the GPU and the video acquisition hardware might have different memory > requirements, at least in the general case. I will contact the GEM guys at > Intel to discuss the topic. > > If we can't share the buffers between the GPU and the rest of the system, we > could at least create a V4L2 wrapper on top of the DSP bridge core (which will > require a major cleanup/restructuring), making it possible to share video > buffers between the ISP and the DSP. > TI has been providing this sort of contiguous buffer support for quite a few years now. TI provides a SW package named LinuxUtils, and it contains a module named CMEM (stand for Contiguous MEMory manager). Latest LinuxUtils release, contains cdocs of CMEM: http://software- dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/2_24_03/exports/l inuxutils_2_24_03.tar.gz And the background/usage article here: http://tiexpressdsp.com/index.php/CMEM_Overview CMEM solves lots of the same sorts of things that the driver described in this thread does. However, it doesn't integrate into other drivers, and it's accessed through the CMEM user interface. Also, CMEM alleviates some of the issues raised in this thread since it uses memory not known to the kernel (user "carves out" a chunk by reducing kernel memory through u-boot mem= param), which IMO can be both good and bad (good - alleviates locking/unavailable memory issues, bad - doesn't cooperate with the kernel in getting memory, requiring user intervention). Regards, Robert Tivy MGTS Systems Software Texas Instruments, Santa Barbara -- 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] Any PCIe DVB-T Dual Tuner cards yet working under Linux?
On Fri, Oct 2, 2009 at 6:27 PM, Christophe Boyanique wrote: > On Fri, Oct 02, 2009 at 01:48:17PM -0400, Devin Heitmueller wrote: > >> > I am also looking for a device (PCIe preferred, or PCI or at worst USB >> > stick) with a dual HD tuner which is buyable from France or Europe... > >> Have you looked at the HVR-2200 (PCIe, dual DVB-T)? > > This card sounds great but it does not seem to be HD :( > > Christophe. Yes, it does HD. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Any PCIe DVB-T Dual Tuner cards yet working under Linux?
On Fri, Oct 02, 2009 at 01:48:17PM -0400, Devin Heitmueller wrote: > > I am also looking for a device (PCIe preferred, or PCI or at worst USB > > stick) with a dual HD tuner which is buyable from France or Europe... > Have you looked at the HVR-2200 (PCIe, dual DVB-T)? This card sounds great but it does not seem to be HD :( Christophe. -- 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
AVerTV MCE 116 Plus remote
Preliminary version of patch adding support for AVerTV MCE 116 Plus remote.
This board has an IR sensor is connected to EM78P153S, general purpose 8-bit
microcontroller with a 1024 × 13 bits of OTP-ROM. According to i2cdetect, it is
sitting on address 0x40.
Patch allows ir-kbd-i2c to probe cx2341x boards for this address. Manually
loading ir-kbd-i2c now detects remote, every key is working as expected.
As I understand, current I2C/probing code is being redesigned/refactored. Sheer
amount of #ifdefs for every second kernel version is making my eyes bleed, so
please somebody involved check if patch is ok.
Should I also add the 0x40 address to addr_list[] in ivtv-i2c.c? How to point
ivtv to this remote and autoload ir-kbd-i2c?
diff --git a/linux/drivers/media/video/ir-kbd-i2c.c
b/linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.c
+++ b/linux/drivers/media/video/ir-kbd-i2c.c
@@ -461,7 +461,7 @@
}
break;
case 0x40:
- name= "AVerMedia Cardbus remote";
+ name= "AVerMedia RM-FP/RM-KH remote";
ir->get_key = get_key_avermedia_cardbus;
ir_type = IR_TYPE_OTHER;
ir_codes= &ir_codes_avermedia_cardbus_table;
@@ -706,8 +706,12 @@
ir_attach(adap, msg.addr, 0, 0);
}
- /* Special case for AVerMedia Cardbus remote */
- if (adap->id == I2C_HW_SAA7134) {
+ /* Special case for AVerMedia remotes:
+ * AVerTV Hybrid+FM Cardbus
+ * AVerTV MCE 116 Plus
+ * probably others with RM-FP, RM-KH remotes and microcontroller
+chip @ 0x40 */
+ if ((adap->id == I2C_HW_SAA7134) || (adap->id == I2C_HW_B_CX2341X)) {
unsigned char subaddr, data;
struct i2c_msg msg[] = { { .addr = 0x40, .flags = 0,
.buf = &subaddr, .len = 1},
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bulk] V4L-DVB Summit Day 3
On Fri, Oct 2, 2009 at 7:56 PM, CityK wrote: > Hans Verkuil wrote: >> I made the following list: >> >> - We created a new mc mailinglist: linux...@googlegroups.com >> >> This is a temporary mailinglist where we can post and review patches during >> prototyping of the mc API. We don't want to flood the linux-media list with >> those patches since that is already quite high-volume. >> >> The mailinglist should be active, although I couldn't find it yet from >> www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did >> something wrong. >> > > I'm scratching my head on this one. Seems the last thing that is needed > is YET another mailing list. Further, it > - fractures the development community. this is what I think too. I'm mainly interested in keeping up compatibility with that framework The traffic on this mailinglist is rather small and it should be ok to mix up developer mails with a few support mails (whereas people usually use to CC anyone who might be involved anyway). > - persons unaware of the decision, and whom might be interested, would > never find it . i.e. alienation if you try to send an email as adviced to that googlemail mailinglist you'll just get an email back that it doesn't work :-) nothing else to write about it I totally agree. One question I have though, what is the impact to the existing API, will they start to require that MC interface? TI hardware is rather specialized and most other devices will not need any of those changes, I don't see the benefit of bloating up the API for devices which already work fine, for simple devices it should better remain simple. (This question is mainly because we also maintain our own player which supports the v4l2/dvbV(3/5) API, but the driver should still support legacy applications in the future) Best Regards, Markus -- 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: IR device at I2C address 0x7a
Hi,
Am Freitag, den 02.10.2009, 13:47 +0200 schrieb Jean Delvare:
> Hi all,
>
> [Executive summary: Upmost Purple TV adapter testers wanted!]
unlikely that anybody with such a card is on the new list currently or
any. I add some old known owners, but mail might bounce.
> While investigating another issue, I have noticed the following message
> in the kernel logs of a saa7134 user:
>
> i2c-adapter i2c-0: Invalid 7-bit address 0x7a
>
> The address in question is attempted by an IR device probe, and is only
> probed on SAA7134 adapters. The problem with this address is that it is
> reserved by the I2C specification for 10-bit addressing, and is thus
> not a valid 7-bit address. Before the conversion of ir-kbd-i2c to the
> new-style i2c device driver binding model, device probing was done by
> ir-kbd-i2c itself so no check was done by i2c-core for address
> validity. But since kernel 2.6.31, probing at address 0x7a will be
> denied by i2c-core.
>
> So, SAA7134 adapters with an IR device at 0x7a are currently broken.
> Do we know how many devices use this address for IR and which they
> are? Tracking the changes in the source code, this address was added
> in kernel 2.6.8 by Gerd Knorr:
>
> http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=581f0d1a0ded3e3d4408e5bb7f81b9ee221f6b7a
> So this would be used by the "Upmost Purple TV" adapter. Question is,
> are there other?
Yes, currently 0x7a is only used by the Upmost Purple TV (Yuan Tun800).
Here are some more details.
http://archives.devshed.com/forums/linux-97/troubles-with-yuan-tun900-board-detected-as-upmost-purple-tv-1283673.html
Support for the card and the i2c remote was added by Wang-Chan Chen.
For testers it is useful to know that the card is still not fully
supported.
It has a NEC D64083GF video enhancer converting TV baseband video from
tuner to S-Video and shares the vmux = 7 with the S-Video input.
By default it comes up in external S-Video input mode.
There is a Pericom videomux on it and we don't know how to switch it.
Chen used to boot at first windows, switched there to tuner input and
rebooted to GNU/Linux ...
> Some web research has pointed me to the Yuan TUN-900:
> http://www.linuxtv.org/pipermail/linux-dvb/2008-January/023405.html
> but it isn't clear to me whether the device at 0x7a on this adapter is
> the same as the one on the Purple TV. And saa7134-cards says of the
> TUN-900: "Remote control not yet implemented" so maybe we can just
> ignore it for now.
Yes, that card has a device at 0xf4/0x7a too.
I asked to test the remote with the Upmost Purple TV entry, but never
got a reply. As we know these days, radio amux is wrong too on Yuan
TUN900 card=66.
Last contact to Chen was four years back, but he confirmed that both
cards have the same PCI subsystem. Some bytes in the eeprom, meaning
unknown, are different, though.
> If we have to, I could make i2c-core more permissive, but I am rather
> reluctant to letting invalid addressed being probed, because you never
> know how complying chips on the I2C bus will react. I am OK supporting
> invalid addresses if they really exist out there, but the impact should
> be limited to the hardware in question.
>
> If we only have to care about the Upmost Purple TV, then the following
> patch should solve the problem:
For what is known so far.
Acked-by: hermann pitton
Cheers,
Hermann
> * * * * *
>
> From: Jean Delvare
> Subject: saa7134: Fix IR support for Purple TV
>
> The i2c core prevents us from probing I2C address 0x7a because it's
> not a valid 7-bit address (reserved for 10-bit addressing.) So we must
> stop probing this address, and explicitly list all adapters which use
> it. Under the assumption that only the Upmost Purple TV adapter uses
> this invalid address, this fix should do the trick.
>
> Signed-off-by: Jean Delvare
> ---
> linux/drivers/media/video/saa7134/saa7134-input.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
> 2009-10-02 13:26:39.0 +0200
> +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-10-02
> 13:26:49.0 +0200
> @@ -746,7 +746,7 @@ void saa7134_probe_i2c_ir(struct saa7134
> {
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
> const unsigned short addr_list[] = {
> - 0x7a, 0x47, 0x71, 0x2d,
> + 0x47, 0x71, 0x2d,
> I2C_CLIENT_END
> };
>
> @@ -813,6 +813,7 @@ void saa7134_probe_i2c_ir(struct saa7134
> dev->init_data.name = "Purple TV";
> dev->init_data.get_key = get_key_purpletv;
> dev->init_data.ir_codes = &ir_codes_purpletv_table;
> + info.addr = 0x7a;
> #endif
> break;
> case SAA7134_BOARD_MSI_TVATANYWHERE_PLUS:
>
>
--
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
Re: saa716x compiling problem
Hi, You could try http://mercurial.intuxication.org/hg/s2-liplianin I think the jusst.de version is outdated regarding the newer kernels. BR: Beepo - Original Message - From: "Jonathan" To: linux-media@vger.kernel.org Sent: Friday, October 2, 2009 9:44:05 PM GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: saa716x compiling problem Hello, I'm trying to compile saa716x module for kernel 2.6.30 but I'm getting some errors. It seems that sources need to be adapted to latest kernel versions to work. I'm using code located at http://www.jusst.de/hg/saa716x/ (last change was three months ago). Is there any patch to solve this problem? Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upgrading from FC4 to current Linux
Bill, On Fri, 2009-10-02 at 09:04 -0400, Bill Davidsen wrote: > I am looking for a video solution which works on recent Linux, like Fedora-11. The video4linux ML is just about dead. You should post to linux-media@vger.kernel.org > Video used to be easy, plug in the capture device, install xawtv via rpm, and > use. However, recent versions of Fedora simply don't work, even on the same > hardware, due to /dev/dsp no longer being created and the applications like > xawtv or tvtime still looking for it. (Non-emulated) OSS was ditched by the linux kernel folks long ago. And I thought xawtv and tvtime were abandon-ware. > The people who will be using this are looking for hardware which is still > made > and sold new, and software which can be installed by a support person who can > plug in cards (PCI preferred) or USB devices, and install rpms. rpmfusion, ATrpms, and I even think Fedora have MythTV available now. mplayer is probably also available from 2 of those 3 resources. For any open source software that implements video and audio decoders, you will need to investigate if you must pay someone licensing fees to use the decoders you need to meet your usage requirements. Fedora has a mechanism in place by which you can pay for the non-free codecs, IIRC. > I maintain the > servers on Linux there, desktop support is unpaid (meaning I want a solution > they can use themselves). > > We looked at vlc, which seems to want channel frequencies in kHz rather than > channels, mythtv, which requires a database their tech isn't able (or > willing) > to support, etc. After vlc or mplayer has started capturing, just use ivtv-tune to change analog channels by channel numbers (using your applicable channel table built into ivtv-tune). You can even set the channel before starting the capture, if you can supress vlc from trying to change the channel. > It seems that video has gone from "easy as Windows" 3-4 years ago to > "insanely > complex" according to to one person in that group who wanted an upgrade on > his > laptop. Most people perceive large number of "options", and the control afforded to the user by those options, as "complexity". I'd say that Linux is all about giving the user options and control. I wouldn't expect that to go away any time soon. If your user wants someone else to put in the effort for him, he either has to give up control (e.g. buy Windows) or incentivize someone to manage the options and flexibility (a.k.a. complexity) he does not wish to manage. > There is some pressure from Windows users to mandate Win7 as the > desktop, which Linux users are rejecting. And if the Linux users value their freedoms and control over their own destiny, you think they'd be willing to put in the effort to maintain it. The price of freedom is eternal vigilance. As far as mandates go, those are usually short-sighted one-size-fits-all solution attempts, often backed by flawed reasoning along the lines of: "Keeping track of all these different things (computers and OSen, and software apps) is complex. My life would be simpler, if I reduced the complexity by standardizing on what I think is right; regardless of all the domain or department specific subtlties and requirements that I'm choosing to ignore." Mandates are easy to push back on once you debunk the cost equation the person is using to justify the mandate. They often haven't considered everthing. > The local cable is a mix of analog channels (for old TVs) and clear qam. The > capture feeds from the monitor system are either S-video or three wire > composite > plus L-R audio. Any reasonable combination of cards (PCI best, PCIe > acceptable), An HVR-1600 is a PCI board based on the CX23418, that can capture analog (NTSC for RF, Worldwide for CVBS or SVideo) and digital (ATSC or QAM) TV simultaneously. The Leadtek WinFast DVR 3100 H board, based on the CX23418, can accept Y Pr Pb inputs as analog baseband. I would need to fix the cx18 driver under Linux to actually support that input (so far no one has asked for it and I don't have test hardware). Simultaneous analog and digital capture are possible as long as they both aren't trying to use the XCeive tuner (which can only do one thing at any one time). But PCI is rapidly disappearly from modern motherboards. I assume within 5 years, most PCI-only motherboards will be failing due to old age. > USB device, and application which can monitor/record would be fine, but the > users are not going to type in kHz values, create channel tables, etc. Honestly, a separate analog tuning app is something one can easily write to meet the exact requirements of one's demanding userbase. Of course ivtv-tune is good enough for mostly everyone I've heard express a need. With DVB under linux, you have no choice but to build a channels.conf file. Whether that's MythTV, mplayer, or something else. You could build a single file for all your users and install it for the
pxa_camera + mt9m1111: Failed to configure for format 50323234
Hi, after updating to 2.6.32-rc2 I can't capture anymore with the setup in the subject. Here's the message from userspace: # ./capture-example Cannot open '/dev/video0': 22, Invalid argument which is from the very first open() call. Here's the relevant snippet from dmesg with debug enabled: [ 15.613749] i2c /dev entries driver [ 15.626308] Linux video capture interface: v2.00 [ 15.640834] pxa27x-camera pxa27x-camera.0: Limiting master clock to 2600 [ 15.648696] pxa27x-camera pxa27x-camera.0: LCD clock 10400Hz, target freq 2600Hz, divisor 1 [ 15.656494] pxa27x-camera pxa27x-camera.0: got DMA channel 1 [ 15.665398] pxa27x-camera pxa27x-camera.0: got DMA channel (U) 2 [ 15.673461] pxa27x-camera pxa27x-camera.0: got DMA channel (V) 3 [ 15.686771] camera 0-0: Probing 0-0 [ 15.707545] pxa27x-camera pxa27x-camera.0: Registered platform device at cc889380 data c03a1e98 [ 15.715265] pxa27x-camera pxa27x-camera.0: pxa_camera_activate: Init gpios [ 15.723488] pxa27x-camera pxa27x-camera.0: PXA Camera driver attached to camera 0 [ 15.739092] mt9m111 0-005d: read reg.00d -> 0008 [ 15.743812] mt9m111 0-005d: write reg.00d = 0008 -> 0 [ 15.748702] mt9m111 0-005d: read reg.00d -> 0008 [ 15.753237] mt9m111 0-005d: write reg.00d = 0009 -> 0 [ 15.757864] mt9m111 0-005d: read reg.00d -> 0009 [ 15.762386] mt9m111 0-005d: write reg.00d = 0029 -> 0 [ 15.766938] mt9m111 0-005d: read reg.00d -> 0029 [ 15.771670] mt9m111 0-005d: write reg.00d = 0008 -> 0 [ 15.776136] mt9m111 0-005d: write reg.0c8 = 970b -> 0 [ 15.781325] mt9m111 0-005d: read reg.106 -> 700e [ 15.785695] mt9m111 0-005d: write reg.106 = 700e -> 0 [ 15.792896] mt9m111 0-005d: read reg.000 -> 143a [ 15.796790] mt9m111 0-005d: Detected a MT9M11x chip ID 143a [ 15.805505] pxa27x-camera pxa27x-camera.0: Providing format Planar YUV422 16 bit using CbYCrY 16 bit [ 15.813285] pxa27x-camera pxa27x-camera.0: Providing format CbYCrY 16 bit packed [ 15.820729] pxa27x-camera pxa27x-camera.0: Providing format CrYCbY 16 bit packed [ 15.828221] pxa27x-camera pxa27x-camera.0: Providing format YCbYCr 16 bit packed [ 15.835484] pxa27x-camera pxa27x-camera.0: Providing format YCrYCb 16 bit packed [ 15.842888] pxa27x-camera pxa27x-camera.0: Providing format RGB 565 packed [ 15.850455] pxa27x-camera pxa27x-camera.0: Providing format RGB 555 packed [ 15.858077] pxa27x-camera pxa27x-camera.0: Providing format Bayer (sRGB) 8 bit in pass-through mode [ 15.872455] pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from camera 0 ... [ 70.377781] pxa27x-camera pxa27x-camera.0: Registered platform device at cc889380 data c03a1e98 [ 70.377866] pxa27x-camera pxa27x-camera.0: pxa_camera_activate: Init gpios [ 70.378259] pxa27x-camera pxa27x-camera.0: PXA Camera driver attached to camera 0 [ 70.378336] mt9m111 0-005d: mt9m111_s_fmt fmt=50323234 left=24, top=8, width=1280, height=1024 [ 70.379630] mt9m111 0-005d: write reg.002 = 0018 -> 0 [ 70.380589] mt9m111 0-005d: write reg.001 = 0008 -> 0 [ 70.382382] mt9m111 0-005d: write reg.1a0 = 0500 -> 0 [ 70.383347] mt9m111 0-005d: write reg.1a3 = 0400 -> 0 [ 70.384312] mt9m111 0-005d: write reg.1a1 = 0500 -> 0 [ 70.385267] mt9m111 0-005d: write reg.1a4 = 0400 -> 0 [ 70.386227] mt9m111 0-005d: write reg.1a6 = 0500 -> 0 [ 70.387188] mt9m111 0-005d: write reg.1a9 = 0400 -> 0 [ 70.393180] mt9m111 0-005d: write reg.1a7 = 0500 -> 0 [ 70.394155] mt9m111 0-005d: write reg.1aa = 0400 -> 0 [ 70.394224] mt9m111 0-005d: Pixel format not handled : 50323234 [ 70.394265] pxa27x-camera pxa27x-camera.0: Failed to configure for format 50323234 [ 70.394310] pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from camera 0 Format 50323234 is 422P, it looks like pxa-camera is trying to force its native format to the sensor, but I am still investigating; I'll come back when I find more or if I come up with a solution. Thanks, Antonio -- 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? pgpUHc7QdHfnE.pgp Description: PGP signature
saa716x compiling problem
Hello, I'm trying to compile saa716x module for kernel 2.6.30 but I'm getting some errors. It seems that sources need to be adapted to latest kernel versions to work. I'm using code located at http://www.jusst.de/hg/saa716x/ (last change was three months ago). Is there any patch to solve this problem? Jonathan -- 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:Fri Oct 2 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13044:6b7617d4a0be 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-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS 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-armv5-omap2: ERRORS 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: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS 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: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): 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/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bulk] V4L-DVB Summit Day 3
Hans Verkuil wrote: > I made the following list: > > - We created a new mc mailinglist: linux...@googlegroups.com > > This is a temporary mailinglist where we can post and review patches during > prototyping of the mc API. We don't want to flood the linux-media list with > those patches since that is already quite high-volume. > > The mailinglist should be active, although I couldn't find it yet from > www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did > something wrong. > I'm scratching my head on this one. Seems the last thing that is needed is YET another mailing list. Further, it - fractures the development community. - persons unaware of the decision, and whom might be interested, would never find it . i.e. alienation - disinterested parties can simply hit the delete key and not bother with the message - blah blah blah .. PS. In regards to yesterday's business announcements, I hope your new forthcoming overlords are as kind to you as your last -- 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] Any PCIe DVB-T Dual Tuner cards yet working under Linux?
On Fri, Oct 2, 2009 at 1:23 PM, Christophe Boyanique wrote: > > Hello,, > >> Is anyone on the list currently using a DVB-T card that has DUAL >> tuners (i.e. I'm looking to replace Hauppage 500's which work great). > > That is an excellent question and I am looking forward to here people > about success stories. > > I am also looking for a device (PCIe preferred, or PCI or at worst USB > stick) with a dual HD tuner which is buyable from France or Europe... > > I found this models which seem to be NOT supported: > - TerraTec Cinergy 2400i DT (not supported from wiki) > - TerraTec T5 Stick (no information found) > - PCTV Stick Dual DVB-T Diversity (2001e) (not supported from wiki) > - AVerMedia AVerTV Duo Hybrid PCI-E A188H (no information found) > > I found this card which seems to be supported: > - Dvico FusionHDTV DVB-T Dual Express > but I do not find any reseller in Europe. > > I found an online reseller in the USA here: > http://www.cyberestore.com/hdtv-tv-tuner-cards/dvico-fusionhdtv-dvb-t-dual-express.html > > But I am not sure that a card sold in the USA will work in Europe as USA > uses NTSC and ATSC (instead of PAL and DVB in Europe). > > Christophe. Have you looked at the HVR-2200 (PCIe, dual DVB-T)? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Any PCIe DVB-T Dual Tuner cards yet working under Linux?
Christophe Boyanique wrote: > Hello,, > > >> Is anyone on the list currently using a DVB-T card that has DUAL >> tuners (i.e. I'm looking to replace Hauppage 500's which work great). >> > > That is an excellent question Which has actually been posed a couple of times in the recent months. Try a search on: http://www.mail-archive.com/linux-media@vger.kernel.org/ using "dual" you'll find one of them quickly enough at least -- 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: Mem2Mem V4L2 devices [RFC]
Hi Marek, On Fri, 2009-10-02 at 13:45 +0200, Marek Szyprowski wrote: > Hello, > > During the V4L2 mini-summit and the Media Controller RFC discussion on > Linux Plumbers 2009 Conference a mem2mem video device has been mentioned > a few times (usually in a context of a 'resizer device' which might be a > part of Camera interface pipeline or work as a standalone device). We > are doing a research how our custom video/multimedia drivers can fit > into the V4L2 framework. Most of our multimedia devices work in mem2mem > mode. > > I did a quick research and I found that currently in the V4L2 framework > there is no device that processes video data in a memory-to-memory > model. In terms of V4L2 framework such device would be both video sink > and source at the same time. The main problem is how the video nodes > (/dev/videoX) should be assigned to such a device. > > The simplest way of implementing mem2mem device in v4l2 framework would > use two video nodes (one for input and one for output). Such an idea has > been already suggested on V4L2 mini-summit. Each DMA engine (either > input or output) that is available in the hardware should get its own > video node. In this approach an application can write() source image to > for example /dev/video0 and then read the processed output from for > example /dev/video1. Source and destination format/params/other custom > settings also can be easily set for either source or destination node. > Besides a single image, user applications can also process video streams > by calling stream_on(), qbuf() + dqbuf(), stream_off() simultaneously on > both video nodes. > > This approach has a limitation however. As user applications would have > to open 2 different file descriptors to perform the processing of a > single image, the v4l2 driver would need to match read() calls done on > one file descriptor with write() calls from the another. The same thing > would happen with buffers enqueued with qbuf(). In practice, this would > result in a driver that allows only one instance of /dev/video0 as well > as /dev/video1 opened. Otherwise, it would not be possible to track > which opened /dev/video0 instance matches which /dev/video1 one. > > The real limitation of this approach is the fact, that it is hardly > possible to implement multi-instance support and application > multiplexing on a video device. In a typical embedded system, in > contrast to most video-source-only or video-sink-only devices, a mem2mem > device is very often used by more than one application at a time. Be it > either simple one-shot single video frame processing or stream > processing. Just consider that the 'resizer' module might be used in > many applications for scaling bitmaps (xserver video subsystem, > gstreamer, jpeglib, etc) only. > > At the first glance one might think that implementing multi-instance > support should be done in a userspace daemon instead of mem2mem drivers. > However I have run into problems designing such a user space daemon. > Usually, video buffers are passed to v4l2 device as a user pointer or > are mmaped directly from the device. The main issue that cannot be > easily resolved is passing video buffers from the client application to > the daemon. The daemon would queue a request on the device and return > results back to the client application after a transaction is finished. > Passing userspace pointers between an application and the daemon cannot > be done, as they are two different processes. Mmap-type buffers are > similar in this aspect - at least 2 buffer copy operations are required > (from client application to device input buffers mmaped in daemon's > memory and then from device output buffers to client application). > Buffer copying and process context switches add both latency and > additional cpu workload. In our custom drivers for mem2mem multimedia > devices we implemented a queue shared between all instances of an opened > mem2mem device. Each instance is assigned to an open device file > descriptor. The queue is serviced in the device context, thus maximizing > the device throughput. This is achieved by scheduling the next > transaction in the driver (kernel) context. This may not even require a > context switch at all. > > Do you have any ideas how would this solution fit into the current v4l2 > design? > > Another solution that came into my mind that would not suffer from this > limitation is to use the same video node for both writing input buffers > and reading output buffers (or queuing both input and output buffers). > Such a design causes more problems with the current v4l2 design however: > > 1. How to set different color space or size for input and output buffer > each? It could be solved by adding a set of ioctls to get/set source > image format and size, while the existing v4l2 ioctls would only refer > to the output buffer. Frankly speaking, we don't like this idea.
Re: Global Video Buffers Pool - PMM and UPBuffer reference drivers [RFC]
I am not a fan of the large and static driver based bootmem allocations in the samsung-ap-2.6 git. This work at least addresses that issue. Thanks. Below are some comments. Perhaps I am not "getting it". According to Marek Szyprowski: > > algorithm itself would typically be changed to fit a usage pattern. > > In our solution all memory buffers are all allocated by user-space > applications, because only user applications have enough information > which devices will be used in the video processing pipeline. For > example: > > MFC video decoder -> Post Processor (scaler and color space converter) > -> Frame Buffer memory. > > If such a translation succeeds the > physical memory region will be properly locked and is guaranteed to be > in the memory till the end of transaction. Each transaction must be > closed by the multimedia device driver explicitly. Since this is a *physical* memory manager, I would never expect the memory to not be in memory... > > > Technical details > - > > 1. Physical memory allocation > > PMM reserves the contiguous physical memory with bootmem kernel > allocator. A boot parameter is used to provide information how much > memory should be allocated, for example: adding a 'pmm=32M' parameter > would reserve 32MiB of system memory on system boot. > > 2. Allocating a buffer from userspace > > PMM provides a /dev/pmm special device. Each time the application wants > to allocate a buffer it opens the /dev/pmm special file, calls > IOCTL_PMM_ALLOC ioctl and the mmaps it into its virtual memory. The > struct pmm_area_info parameter for IOCTL_PMM_ALLOC ioctl describes the > memory requirements for the buffer (please refer to > include/linux/s3c/pmm.h) - like buffer size, memory alignment, memory > type (PMM supports different memory types, although currently only one > is used) and cpu cache coherency rules (memory can be mapped as > cacheable or non-cacheable). The buffer is freed when the file > descriptor reference count reaches zero (so the file is closed, is > unmmaped from applications memory and released from multimedia devices). I prefer using mmap semantics with a driver than messes with *my* address space. Ioctls that mess with my address space gives me hives. mmap is the call a user makes to map a memory/file object into its space. ioctl is for things that don't fit read/write/mmap. :-) 1. memory alignment will be page size 4k (no?). Or are you suggesting larger alignment requirements? Are any of the target devices 24 bit dma clients? (Crossing a 16MB boundary would then not work...) 2. Since these buffers will be dma sources/targets, cache will be off (no?) Many CPUs ldr/stm memcpy do burst access to DDR so non-cached is still pretty zipping for non-bit banging apps. Forcing non-cached makes much of the "sync" semantic you have "go away". Is there a use-case for cached graphics controller memory that I am missing? > 3. Buffer locking > > If user application performed a mmap call on some special device and a > driver mapped some physical memory into user address space (usually with > remap_pfn_range function), this will create a vm_area structure with > VM_PFNMAP flag set in user address space map. UPBuffer layer can easily > perform a reverse mapping (virtual address to physical memory address) > by simply reading the PTE values and checking if it is contiguous in > physical memory. The only problem is how to guarantee the security of > this solution. VM_PFNMAP-type areas do not have associated page > structures so that memory pages cannot be locked directly in page cache. > However such memory area would not be freed until the special file that > is behind it is still in use. We found that is can be correctly locked > by increasing reference counter of that special file (vm_area->vm_file). > This would lock the mapping from being freed if user would accidently do > something really nasty like unmapping that area. I am still missing it. Your /dev/pmm is allocating *physical memory* -- which it (the pmm) owns for all time (bootmem). If the user unmaps it, it is still pmm's physical memory. Now, returning the allocated memory to the pmm freelist requires both the source and target to relinquish. That implies both drivers "know" to relinquish on last-close. Otherwise, you leak like a sieve. Returning the pmm memory to the freelist when the user unmaps means that dma registers in HW still reference that memory. Only the driver knows when it is "done". Drivers "own" the PMM lifecycle. Users get transient mappings. > 7. SYSV SHM integration > SysV shm is a nice touch. Good job. Re: configuration There are quite a few CONFIG variables. Forcing s3c-mm drivers to use PMM would knock quite a few of them out. You have presented a very flexible, general purpose bootmem allocator/mapper. (cache/uncached, bounce/pmm, etc.) The problem you were trying to solve is a means to generalize multiple compile-time fixed b
Re: [PATCH] Fix wrong sizeof
linux/drivers/media/video/saa7164/saa7164-cmd.c |2 +- Acked-By: Steven Toth -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Programming sensor through firmware files bc of NDA
Hi all, I'm currently interested in knowing what is the stand on having a v4l2_subdev driver that uses some kind of binary for programming registers in a image sensor driver. NOTE: I must confess I currently don't know how to do it (Any pointers/samples for doing it on a proper way?) The only reason for doing this is to avoid potential violation of NDA with sensor manufacturer by exposing all register details. Please comment. Regards, Sergio-- 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
mt9t031-VPFE integration issues...
Hi Guennadi, I am currently integrating latest MT9T031 driver to vpfe_capture driver and see following issues:- 1) Currently MT9T031 Kconfig configuration variable has a dependency on SOC_CAMERA. We need to remove this dependency since this sensor can be used on other platforms like DM6446/DM355/DM365. This is trivial and I can send a patch to remove the dependency. 2) The code still has reference to soc_camera_device and associated changes. I think this should be removed so that it can be used on other platforms as well. I am expecting these will go away once the bus parameter as well data format related RFCs are approved. If this is true, I can wait until the same is approved. If not, we need to work together so that this driver can be integrated with vpfe capture driver. Please let me know what you think on this. Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.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
[PATCH] ir-kbd-i2c: Don't reject unknown I2C addresses
I do not think it makes sense any longer for ir-kbd-i2c to reject
devices at unknown I2C addresses. The caller can provide all the
details about how the device should be handled. Having to add new
addresses to ir-kbd-i2c so that they aren't rejected is a pain we
don't need. Unsupported devices will be spotted a few lines later
anyway.
This already lets us unlist 2 addresses (0x7a and 0x2d) for which
handling details are always provided by the caller (saa7134-input).
Hopefully we can remove more in the future.
Signed-off-by: Jean Delvare
---
linux/drivers/media/video/ir-kbd-i2c.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/ir-kbd-i2c.c 2009-10-02
14:52:33.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ir-kbd-i2c.c 2009-10-02
14:58:33.0 +0200
@@ -373,7 +373,7 @@ static int ir_probe(struct i2c_client *c
{
struct ir_scancode_table *ir_codes = NULL;
const char *name = NULL;
- int ir_type;
+ int ir_type = 0;
struct IR_i2c *ir;
struct input_dev *input_dev;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
@@ -438,10 +438,8 @@ static int ir_probe(struct i2c_client *c
ir_type = IR_TYPE_RC5;
ir_codes= &ir_codes_fusionhdtv_mce_table;
break;
- case 0x7a:
case 0x47:
case 0x71:
- case 0x2d:
if (adap->id == I2C_HW_B_CX2388x ||
adap->id == I2C_HW_B_CX2341X) {
/* Handled by cx88-input */
@@ -466,10 +464,6 @@ static int ir_probe(struct i2c_client *c
ir_type = IR_TYPE_OTHER;
ir_codes= &ir_codes_avermedia_cardbus_table;
break;
- default:
- dprintk(1, DEVNAME ": Unsupported i2c address 0x%02x\n", addr);
- err = -ENODEV;
- goto err_out_free;
}
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
@@ -513,7 +507,7 @@ static int ir_probe(struct i2c_client *c
}
/* Make sure we are all setup before going on */
- if (!name || !ir->get_key || !ir_codes) {
+ if (!name || !ir->get_key || !ir_type || !ir_codes) {
dprintk(1, DEVNAME ": Unsupported device at address 0x%02x\n",
addr);
err = -ENODEV;
--
Jean Delvare
--
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://kernellabs.com/hg/~mkrufky/tda18271
Mauro, We have discovered some major bugs in the tda18271 driver. With these changes, reception using this tuner has improved drastically. The fixes for these problems were relatively simple, but I need these merged into Linus' tree as soon as possible so that I can generate patches to be backported into the -stable series. Please merge these and send to Linus ASAP. Please pull from: http://kernellabs.com/hg/~mkrufky/tda18271 for the following: - tda18271: fix overflow in FM radio frequency calculation - tda8290: enable deemphasis_50 module parameter - tda18271: fix signedness issue in tda18271_rf_tracking_filters_init - tda18271: use temporary variables in tda18271_rf_tracking_filters_init - tda18271: more signedness fixes - tda18271: display some state information in debug output tda18271-fe.c | 44 +++- tda18271-maps.c |1 tda18271-priv.h | 43 ++- tda8290.c |1 4 files changed, 53 insertions(+), 36 deletions(-) Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~mkrufky/v4l-dvb
On Mon, Sep 28, 2009 at 12:24 AM, Michael Krufky wrote: > Mauro, > > Included in this pull request are some important fixes to the tda18271 > tuner driver. Please include these patches in your next pull request > to Linus. Please disregard this pull request -- we found a problem in the Zolid AGC control patch -- I will resubmit this as two separate pull requests -- 1) tda* changes 2) Zolid tweaks. Thanks, Mike > Please pull from: > > http://kernellabs.com/hg/~mkrufky/v4l-dvb > > for the following: > > - tda18271: fix overflow in FM radio frequency calculation > - tda8290: enable deemphasis_50 module parameter > - tda18271: fix signedness issue in tda18271_rf_tracking_filters_init > - tda18271: use temporary variables in tda18271_rf_tracking_filters_init > - tda18271: more signedness fixes > - merge: ~mkrufky/tda18271 > - saa7134: add AGC control for Zolid Hybrid PCI card > > common/tuners/tda18271-fe.c | 84 -- > common/tuners/tda18271-priv.h | 22 +++-- > common/tuners/tda8290.c | 2 > video/saa7134/saa7134-cards.c | 25 ++ > video/saa7134/saa7134-dvb.c | 9 ++ > 5 files changed, 94 insertions(+), 48 deletions(-) > > Cheers, > > Mike > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Zolid Hybrid PCI card add AGC control
On Fri, Oct 2, 2009 at 5:12 AM, wrote:
> On Thu, Sep 24, 2009 at 02:55:42PM -0400, Michael Krufky wrote:
>> On Tue, Sep 22, 2009 at 5:09 PM, wrote:
>> >
>> > Switches IF AGC control via GPIO 21 of the saa7134. Improves DTV reception
>> > and
>> > FM radio reception.
>> >
>> > Signed-off-by: henk.vergo...@gmail.com
>>
>> Reviewed-by: Michael Krufky
>>
>> Henk,
>>
>> This is *very* interesting... Have you taken a scope to the board to
>> measure AGC interference? This seems to be *very* similar to
>> Hauppauge's design for the HVR1120 and HVR1150 boards, which are
>> actually *not* based on any reference design.
>>
>> I have no problems with this patch, but I would be interested to hear
>> that you can prove it is actually needed by using a scope. If you
>> don't have a scope, I understand but this certainly peaks my
>> interest.
>>
>> Do you have schematics of that board?
>>
>> Regards,
>>
>> Mike Krufky
>>
>
> One note: I have tested the tda18271 signedness fixes in the debug
> repository. This is a big improvement in reception.
>
> Based on the latest testing with all the fixes I would say that
> switching the AGC line via gpio is not needed and leaving it at 0 gives
> the best results.
> (This is purely based on SNR and BER readings from tzap)
>
> So I would recomend: leaving config at zero.
>
> static struct tda18271_config zolid_tda18271_config = {
> .std_map = &zolid_tda18271_std_map,
> .gate = TDA18271_GATE_ANALOG,
> - .config = 3,
> +// .config = 3,
> .output_opt = TDA18271_OUTPUT_LT_OFF,
> };
>
I removed the patch from my tree awaiting merge, "saa7134: add AGC
control for Zolid Hybrid PCI card".
It wasn't as simple as changing the 3 to a 0, since the function,
"saa7134_tda18271_zolid_toggle_agc" becomes a no-op.
Also, you've been sending the sign-off's in the wrong format in your
previous submissions.
Please send in the "FM reception via RF_IN" as a separate patch, and
include your sign-off using the actual format:
Signed-off-by: Your Name
Regards,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] saa7134: Complete the IR address list
Google is pretty clear that the HVR 1110 IR chip is always at address
0x71 and the BeholdTV IR chip is always at address 0x2d. This
completes the list of IR device addresses for the SAA7134-based
adapters, and we no longer need to probe any of them.
Signed-off-by: Jean Delvare
---
Note: this goes on top of the other saa7134 patches I've sent earlier
today.
linux/drivers/media/video/saa7134/saa7134-input.c | 25 ++---
1 file changed, 8 insertions(+), 17 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-10-02 13:50:12.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-10-02
14:29:07.0 +0200
@@ -746,10 +746,6 @@ void saa7134_probe_i2c_ir(struct saa7134
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
struct i2c_board_info info;
- const unsigned short addr_list[] = {
- 0x47, 0x71, 0x2d,
- I2C_CLIENT_END
- };
struct i2c_msg msg_msi = {
.addr = 0x50,
@@ -846,6 +842,7 @@ void saa7134_probe_i2c_ir(struct saa7134
dev->init_data.name = "HVR 1110";
dev->init_data.get_key = get_key_hvr1110;
dev->init_data.ir_codes = &ir_codes_hauppauge_new_table;
+ info.addr = 0x71;
#endif
break;
case SAA7134_BOARD_BEHOLD_607FM_MK3:
@@ -869,30 +866,24 @@ void saa7134_probe_i2c_ir(struct saa7134
dev->init_data.name = "BeholdTV";
dev->init_data.get_key = get_key_beholdm6xx;
dev->init_data.ir_codes = &ir_codes_behold_table;
+ info.addr = 0x2d;
#endif
break;
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 30)
- default:
- dprintk("Shouldn't get here: Unknown board %x for I2C
IR?\n",dev->board);
-#else
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
case SAA7134_BOARD_AVERMEDIA_CARDBUS_501:
case SAA7134_BOARD_AVERMEDIA_CARDBUS_506:
info.addr = 0x40;
-#endif
break;
+#endif
+ default:
+ dprintk("No I2C IR support for board %x\n", dev->board);
+ return;
}
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
if (dev->init_data.name)
info.platform_data = &dev->init_data;
- /* No need to probe if address is known */
- if (info.addr) {
- i2c_new_device(&dev->i2c_adap, &info);
- return;
- }
-
- /* Address not known, fallback to probing */
- i2c_new_probed_device(&dev->i2c_adap, &info, addr_list);
+ i2c_new_device(&dev->i2c_adap, &info);
#endif
}
--
Jean Delvare
--
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: dqbuf in blocking mode
Laurent Pinchart wrote: [clip] If I'm not mistaken videobuf_dqbuf() only returns -EIO if the buffer state is VIDEOBUF_ERROR. This is the direct result of either - videobuf_queue_cancel() being called, or - the device driver marking the buffer as erroneous because of a (possibly transient) device error In the first case VIDIOC_DQBUF should in my opinion return with an error. In the second case things are not that clear. A transient error could be hidden from the application, or, if returned to the application through -EIO, shouldn't be treated as a fatal error. Non-transient errors should result in the application stopping video streaming. Unfortunately there V4L2 API doesn't offer a way to find out if the error is transient or fatal: "EIO VIDIOC_DQBUF failed due to an internal error. Can also indicate temporary problems like signal loss. Note the driver might dequeue an (empty) buffer despite returning an error, or even stop capturing." -EIO can mean many different things that need to be handled differently by applications. I especially hate the "the driver might dequeue an (empty) buffer despite returning an error". Drivers should always or never dequeue a buffer when an error occurs, not sometimes. The problem is for the application to recognize the difference between a transient and a fatal error in a backward-compatible way. The errors in this case are transient and for blocking mode IMO the safest way is to return the buffer only when there's one available. Which is what the driver is doing now. What I'd probably change, however, is to move the handling to the ISP driver instead. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.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
Re: cx23885 audio
Steven Toth wrote: On 10/1/09 11:52 PM, David T.L. Wong wrote: Hi all, It there any cx23885 audio support on current v4l-dvb tree, Or any development tree for cx23885 audio? http://www.kernellabs.com/blog/?p=788 I'm about to start on this. Cool, Let's work on that together. David -- 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: cx23885 audio
On 10/1/09 11:52 PM, David T.L. Wong wrote: Hi all, It there any cx23885 audio support on current v4l-dvb tree, Or any development tree for cx23885 audio? http://www.kernellabs.com/blog/?p=788 I'm about to start on this. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
IR device at I2C address 0x7a
Hi all,
[Executive summary: Upmost Purple TV adapter testers wanted!]
While investigating another issue, I have noticed the following message
in the kernel logs of a saa7134 user:
i2c-adapter i2c-0: Invalid 7-bit address 0x7a
The address in question is attempted by an IR device probe, and is only
probed on SAA7134 adapters. The problem with this address is that it is
reserved by the I2C specification for 10-bit addressing, and is thus
not a valid 7-bit address. Before the conversion of ir-kbd-i2c to the
new-style i2c device driver binding model, device probing was done by
ir-kbd-i2c itself so no check was done by i2c-core for address
validity. But since kernel 2.6.31, probing at address 0x7a will be
denied by i2c-core.
So, SAA7134 adapters with an IR device at 0x7a are currently broken.
Do we know how many devices use this address for IR and which they
are? Tracking the changes in the source code, this address was added
in kernel 2.6.8 by Gerd Knorr:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=581f0d1a0ded3e3d4408e5bb7f81b9ee221f6b7a
So this would be used by the "Upmost Purple TV" adapter. Question is,
are there other?
Some web research has pointed me to the Yuan TUN-900:
http://www.linuxtv.org/pipermail/linux-dvb/2008-January/023405.html
but it isn't clear to me whether the device at 0x7a on this adapter is
the same as the one on the Purple TV. And saa7134-cards says of the
TUN-900: "Remote control not yet implemented" so maybe we can just
ignore it for now.
If we have to, I could make i2c-core more permissive, but I am rather
reluctant to letting invalid addressed being probed, because you never
know how complying chips on the I2C bus will react. I am OK supporting
invalid addresses if they really exist out there, but the impact should
be limited to the hardware in question.
If we only have to care about the Upmost Purple TV, then the following
patch should solve the problem:
* * * * *
From: Jean Delvare
Subject: saa7134: Fix IR support for Purple TV
The i2c core prevents us from probing I2C address 0x7a because it's
not a valid 7-bit address (reserved for 10-bit addressing.) So we must
stop probing this address, and explicitly list all adapters which use
it. Under the assumption that only the Upmost Purple TV adapter uses
this invalid address, this fix should do the trick.
Signed-off-by: Jean Delvare
---
linux/drivers/media/video/saa7134/saa7134-input.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-10-02 13:26:39.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-10-02
13:26:49.0 +0200
@@ -746,7 +746,7 @@ void saa7134_probe_i2c_ir(struct saa7134
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
const unsigned short addr_list[] = {
- 0x7a, 0x47, 0x71, 0x2d,
+ 0x47, 0x71, 0x2d,
I2C_CLIENT_END
};
@@ -813,6 +813,7 @@ void saa7134_probe_i2c_ir(struct saa7134
dev->init_data.name = "Purple TV";
dev->init_data.get_key = get_key_purpletv;
dev->init_data.ir_codes = &ir_codes_purpletv_table;
+ info.addr = 0x7a;
#endif
break;
case SAA7134_BOARD_MSI_TVATANYWHERE_PLUS:
--
Jean Delvare
--
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
Mem2Mem V4L2 devices [RFC]
Hello, During the V4L2 mini-summit and the Media Controller RFC discussion on Linux Plumbers 2009 Conference a mem2mem video device has been mentioned a few times (usually in a context of a 'resizer device' which might be a part of Camera interface pipeline or work as a standalone device). We are doing a research how our custom video/multimedia drivers can fit into the V4L2 framework. Most of our multimedia devices work in mem2mem mode. I did a quick research and I found that currently in the V4L2 framework there is no device that processes video data in a memory-to-memory model. In terms of V4L2 framework such device would be both video sink and source at the same time. The main problem is how the video nodes (/dev/videoX) should be assigned to such a device. The simplest way of implementing mem2mem device in v4l2 framework would use two video nodes (one for input and one for output). Such an idea has been already suggested on V4L2 mini-summit. Each DMA engine (either input or output) that is available in the hardware should get its own video node. In this approach an application can write() source image to for example /dev/video0 and then read the processed output from for example /dev/video1. Source and destination format/params/other custom settings also can be easily set for either source or destination node. Besides a single image, user applications can also process video streams by calling stream_on(), qbuf() + dqbuf(), stream_off() simultaneously on both video nodes. This approach has a limitation however. As user applications would have to open 2 different file descriptors to perform the processing of a single image, the v4l2 driver would need to match read() calls done on one file descriptor with write() calls from the another. The same thing would happen with buffers enqueued with qbuf(). In practice, this would result in a driver that allows only one instance of /dev/video0 as well as /dev/video1 opened. Otherwise, it would not be possible to track which opened /dev/video0 instance matches which /dev/video1 one. The real limitation of this approach is the fact, that it is hardly possible to implement multi-instance support and application multiplexing on a video device. In a typical embedded system, in contrast to most video-source-only or video-sink-only devices, a mem2mem device is very often used by more than one application at a time. Be it either simple one-shot single video frame processing or stream processing. Just consider that the 'resizer' module might be used in many applications for scaling bitmaps (xserver video subsystem, gstreamer, jpeglib, etc) only. At the first glance one might think that implementing multi-instance support should be done in a userspace daemon instead of mem2mem drivers. However I have run into problems designing such a user space daemon. Usually, video buffers are passed to v4l2 device as a user pointer or are mmaped directly from the device. The main issue that cannot be easily resolved is passing video buffers from the client application to the daemon. The daemon would queue a request on the device and return results back to the client application after a transaction is finished. Passing userspace pointers between an application and the daemon cannot be done, as they are two different processes. Mmap-type buffers are similar in this aspect - at least 2 buffer copy operations are required (from client application to device input buffers mmaped in daemon's memory and then from device output buffers to client application). Buffer copying and process context switches add both latency and additional cpu workload. In our custom drivers for mem2mem multimedia devices we implemented a queue shared between all instances of an opened mem2mem device. Each instance is assigned to an open device file descriptor. The queue is serviced in the device context, thus maximizing the device throughput. This is achieved by scheduling the next transaction in the driver (kernel) context. This may not even require a context switch at all. Do you have any ideas how would this solution fit into the current v4l2 design? Another solution that came into my mind that would not suffer from this limitation is to use the same video node for both writing input buffers and reading output buffers (or queuing both input and output buffers). Such a design causes more problems with the current v4l2 design however: 1. How to set different color space or size for input and output buffer each? It could be solved by adding a set of ioctls to get/set source image format and size, while the existing v4l2 ioctls would only refer to the output buffer. Frankly speaking, we don't like this idea. 2. Input and output in the same video node would not be compatible with the upcoming media controller, with which we will get an ability to arrange devices into a custom pipeline. Piping together two separate input-output nodes to
Re: What is the status of the driver TT CT-3650
On Fri, Oct 2, 2009 at 9:20 AM, Hasse Hagen Johansen wrote: > Hi > > I have recently bought such a card and tried to get it working. Does > anyone know if it is possible. I have compiled the dvb drivers from > s2-liplianin > > And tried to use the scan program from the dvb-apps mercurial tarball. I > also compile scan-s2 and tried that, but I always get "tuning failed" > > Anyone know how to get this working or this card is in a working state > under linux. Because if it not working yet I will stop wasting my time > :-) > it didn't work for me either, so I returned it and stick with my old DVB-T device again.. James -- 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
What is the status of the driver TT CT-3650
Hi I have recently bought such a card and tried to get it working. Does anyone know if it is possible. I have compiled the dvb drivers from s2-liplianin And tried to use the scan program from the dvb-apps mercurial tarball. I also compile scan-s2 and tried that, but I always get "tuning failed" Anyone know how to get this working or this card is in a working state under linux. Because if it not working yet I will stop wasting my time :-) Regards Hasse H. Johansen -- 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 4/4] Zolid Hybrid PCI card add AGC control
On Thu, Sep 24, 2009 at 02:55:42PM -0400, Michael Krufky wrote:
> On Tue, Sep 22, 2009 at 5:09 PM, wrote:
> >
> > Switches IF AGC control via GPIO 21 of the saa7134. Improves DTV reception
> > and
> > FM radio reception.
> >
> > Signed-off-by: henk.vergo...@gmail.com
>
> Reviewed-by: Michael Krufky
>
> Henk,
>
> This is *very* interesting... Have you taken a scope to the board to
> measure AGC interference? This seems to be *very* similar to
> Hauppauge's design for the HVR1120 and HVR1150 boards, which are
> actually *not* based on any reference design.
>
> I have no problems with this patch, but I would be interested to hear
> that you can prove it is actually needed by using a scope. If you
> don't have a scope, I understand but this certainly peaks my
> interest.
>
> Do you have schematics of that board?
>
> Regards,
>
> Mike Krufky
>
One note: I have tested the tda18271 signedness fixes in the debug
repository. This is a big improvement in reception.
Based on the latest testing with all the fixes I would say that
switching the AGC line via gpio is not needed and leaving it at 0 gives
the best results.
(This is purely based on SNR and BER readings from tzap)
So I would recomend: leaving config at zero.
static struct tda18271_config zolid_tda18271_config = {
.std_map = &zolid_tda18271_std_map,
.gate= TDA18271_GATE_ANALOG,
- .config = 3,
+// .config = 3,
.output_opt = TDA18271_OUTPUT_LT_OFF,
};
Regards,
Henk
--
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] Fix wrong sizeof
Which is why I have always preferred sizeof(struct foo) over sizeof(var). Signed-off-by: Jean Delvare --- linux/drivers/media/dvb/dvb-usb/ce6230.c|2 +- linux/drivers/media/video/saa7164/saa7164-cmd.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-usb/ce6230.c 2009-09-26 13:10:08.0 +0200 +++ v4l-dvb/linux/drivers/media/dvb/dvb-usb/ce6230.c2009-10-02 11:03:17.0 +0200 @@ -105,7 +105,7 @@ static int ce6230_i2c_xfer(struct i2c_ad int i = 0; struct req_t req; int ret = 0; - memset(&req, 0, sizeof(&req)); + memset(&req, 0, sizeof(req)); if (num > 2) return -EINVAL; --- v4l-dvb.orig/linux/drivers/media/video/saa7164/saa7164-cmd.c 2009-09-26 13:10:09.0 +0200 +++ v4l-dvb/linux/drivers/media/video/saa7164/saa7164-cmd.c 2009-10-02 11:03:21.0 +0200 @@ -347,7 +347,7 @@ int saa7164_cmd_send(struct saa7164_dev /* Prepare some basic command/response structures */ memset(&command_t, 0, sizeof(command_t)); - memset(&response_t, 0, sizeof(&response_t)); + memset(&response_t, 0, sizeof(response_t)); pcommand_t = &command_t; presponse_t = &response_t; command_t.id = id; -- Jean Delvare -- 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] i2c_board_info can be local
Recent fixes to the em28xx and saa7134 drivers have been overzealous.
While the ir-kbd-i2c platform data indeed needs to be persistent, the
struct i2c_board_info doesn't, as it is only used by i2c_new_device().
So revert a part of the original fixes, to save some memory.
Signed-off-by: Jean Delvare
Cc: Mauro Carvalho Chehab
---
linux/drivers/media/video/em28xx/em28xx-cards.c |9 +
linux/drivers/media/video/em28xx/em28xx.h |1 -
linux/drivers/media/video/saa7134/saa7134-input.c | 21 +++--
linux/drivers/media/video/saa7134/saa7134.h |1 -
4 files changed, 16 insertions(+), 16 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-cards.c
2009-09-26 13:10:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-cards.c 2009-10-02
10:05:47.0 +0200
@@ -2306,6 +2306,7 @@ void em28xx_register_i2c_ir(struct em28x
return;
}
#else
+ struct i2c_board_info info;
const unsigned short addr_list[] = {
0x30, 0x47, I2C_CLIENT_END
};
@@ -2313,9 +2314,9 @@ void em28xx_register_i2c_ir(struct em28x
if (disable_ir)
return;
- memset(&dev->info, 0, sizeof(&dev->info));
+ memset(&info, 0, sizeof(struct i2c_board_info));
memset(&dev->init_data, 0, sizeof(dev->init_data));
- strlcpy(dev->info.type, "ir_video", I2C_NAME_SIZE);
+ strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
#endif
/* detect & configure */
@@ -2361,8 +2362,8 @@ void em28xx_register_i2c_ir(struct em28x
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
if (dev->init_data.name)
- dev->info.platform_data = &dev->init_data;
- i2c_new_probed_device(&dev->i2c_adap, &dev->info, addr_list);
+ info.platform_data = &dev->init_data;
+ i2c_new_probed_device(&dev->i2c_adap, &info, addr_list);
#endif
}
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx.h 2009-09-26
13:10:09.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx.h 2009-10-02
10:13:10.0 +0200
@@ -625,7 +625,6 @@ struct em28xx {
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
/* I2C keyboard data */
- struct i2c_board_info info;
struct IR_i2c_init_data init_data;
#endif
};
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-09-26 13:10:09.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-10-02
10:15:04.0 +0200
@@ -745,6 +745,7 @@ void saa7134_probe_i2c_ir(struct saa7134
#endif
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
+ struct i2c_board_info info;
const unsigned short addr_list[] = {
0x7a, 0x47, 0x71, 0x2d,
I2C_CLIENT_END
@@ -771,9 +772,9 @@ void saa7134_probe_i2c_ir(struct saa7134
}
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
- memset(&dev->info, 0, sizeof(dev->info));
+ memset(&info, 0, sizeof(struct i2c_board_info));
memset(&dev->init_data, 0, sizeof(dev->init_data));
- strlcpy(dev->info.type, "ir_video", I2C_NAME_SIZE);
+ strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
#endif
switch (dev->board) {
@@ -791,7 +792,7 @@ void saa7134_probe_i2c_ir(struct saa7134
#else
dev->init_data.get_key = get_key_pinnacle_color;
dev->init_data.ir_codes =
&ir_codes_pinnacle_color_table;
- dev->info.addr = 0x47;
+ info.addr = 0x47;
#endif
} else {
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 30)
@@ -800,7 +801,7 @@ void saa7134_probe_i2c_ir(struct saa7134
#else
dev->init_data.get_key = get_key_pinnacle_grey;
dev->init_data.ir_codes = &ir_codes_pinnacle_grey_table;
- dev->info.addr = 0x47;
+ info.addr = 0x47;
#endif
}
break;
@@ -824,7 +825,7 @@ void saa7134_probe_i2c_ir(struct saa7134
dev->init_data.name = "MSI t...@nywhere Plus";
dev->init_data.get_key = get_key_msi_tvanywhere_plus;
dev->init_data.ir_codes = &ir_codes_msi_tvanywhere_plus_table;
- dev->info.addr = 0x30;
+ info.addr = 0x30;
/* MSI t...@nywhere Plus controller doesn't seem to
respond to probes unless we read something from
an existing device. Weird...
@@ -875,22 +876,22 @@ void saa7134_probe_i2c_ir(struct saa7134
#else
case SAA7134_BOARD_AVERMEDIA_CARDBUS_501:
case SAA7134_BOARD_AVERMEDIA_CARDBUS_506:
- dev->info.addr = 0x40;
+ info.addr = 0x40;
#endif
break;
}
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
if (dev->init_data.name)
- dev->info.platform_data = &dev-
