RE: Fourcc for multiplanar formats
Hi. Any progress on the RFC for allowing user applications to specify separate user ptr for each plane of a multi-planar format? I have finished ver. 1 of V4L2 API, videobuf adaptations and tested everything on a slightly modified vivi. Patches are ready, I'm in the middle of writing the RFC. I should be posting everything really soon (still waiting for a green light but it's usually a matter of hours, couple of days at most). Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- 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: Proposal for a V4L2 Media Controller mini-summit
Hi Hans, On Wednesday 17 February 2010 19:33:33 Hans Verkuil wrote: On Friday 12 February 2010 15:50:08 Hans Verkuil wrote: There is another alternative and that is that I organize a mini-summit in May in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I think that it is more fun to do this during/before/after a conference. If only because there are a lot of linux kernel experts on hand during such a conference that you can ask for help if needed. Please let me know asap if you are interested in attending such a mini-summit and what dates are possible for you: a: April 10-11 (or 12) b: April 12-14 c: April 14 (or 15)-16 d: Somewhere in May (suggestions for dates are welcome) I would appreciate it if people/companies who are interested in attending would let me know as soon as possible. Options A and B are a no go, so it is either April 14-16, or it will be in May. It doesn't have to be definitive, but I would like to have an idea of what to expect. It's not a definitive no, but April 14-16 will be very difficult for me, so there's little chance I can attend. The V4L2 API work that is in progress is crucially important for embedded hardware, so getting involved now will ensure that your devices will work fine on linux in the future. And we get to see more of the complex use cases that we must cater to in the API. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to add DVB-S2 support to firedtv?
Hi, Regarding the documentation and code: From a quick glance, the LNB/QPSK2 code follows the documentation fairly good. I guess it could do with a deeper check (I could see that at least the FEC switch case does seems to have some invalid values) but I would prefer that this is done by someone that actually has a DVB-S(2) card. Regards, Henrik Hi all, what steps need to be taken to get DVB-S2 support into the firedtv driver? (The status is, as far as I understood: FireDTV S2 and Floppy DTV S2 devices recognize HD channels during channel scan but cannot tune to them. FireDTV C/CI DVB-C boxes however tune and play back HD channels just fine.) I suppose the frontend needs to be extended for s2api. Was there a respective conversion in another DVB driver that can serve as a good coding example? Is documentation from Digital Everywhere required regarding the vendor-specific AV/C requests (LNB_CONTROL? TUNE_QPSK2?) or is the current driver code enough to connect the dots? Is the transport stream different from DVB-C HD streams so that changes to the isochronous I/O part would be required? -- Stefan Richter -=-==-=- --=- -===- http://arcgraph.de/sr/ -- 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: alevt-dvb 1.7.0: new version, should be free from bugs now
--- On Thu, 2/18/10, Chicken Shack chicken.sh...@gmx.de wrote: From: Chicken Shack chicken.sh...@gmx.de Subject: Re: alevt-dvb 1.7.0: new version, should be free from bugs now To: Emil Meier emil27...@yahoo.com Cc: Linux media linux-media@vger.kernel.org, g...@kroah.com, francescola...@interfree.it Date: Thursday, February 18, 2010, 3:57 AM Am Mittwoch, den 17.02.2010, 15:50 -0800 schrieb Emil Meier: Or you can tune back to the original transponder or a transponder with the same provider, then alevt works again. So there is may be a check for the provider name. Not exactly. As long as there is no necessity to reread the PAT (Program association table) everything is working fine. At the current state the mechanism (or system call) to restart or reset the reading and parsing process of PAT, SDT, PMT is missing. And that exactly poses the problems as soon as you change the transponder.. As long as you do not change the transponder, PAT, SDT and PMT stay the same. Transponder is not equal to provider google is your friend or have a look at etsi.org... Yes, but I have tested a Transponder change, where the Provider name of the new transponder is the same as before, then alevt changes to a new channel (may be the first one) and continues to work again. As I have edited my kaffeine channels.dvb on my own, I am very sure, that I have changed the transponder... Is your version 1.7.0 connected to the version 1.7.0 which Uwe Bulga sent to me? I will test your new version this evening. As I am using alevt since I think over 10 years, I hope that I can use this application again with vanilla kernels without reverse-patching!!! At the moment I am using 2.6.32.7 with a reverse patch Uwe sent to me... This works fine as before... Maybe 2.6.32.8 can correct the dvb-demux driver. The required monitoring demon MUST work independently from the external player application doing the tuning. My current script switches off and restarts alevt at every channel change, including waitstates so that the player application and alevt do not interfere when accessing the demux device (-timing issue) But that's just a very dirty workaround. I will have a look into alevt, why the update and eventhandling stops after changing transponder/provider... May be I can find something. The task is to change that behaviour. alevt-dvb should follow the new channel. In mtt (by Gerd Hoffmann @ bytesex.org - xawtv-4.0 pre) a module called dvb-monitor does that job. Cheers CS Thanks for your this version. You're welcome as every other user is. Emil Emil and others: Will you please use the appended version? I kicked out a nasty error message that printed out an error every time when alevt was entering a zero entry in the PAT. This error message wasn't even relevant for debug purposes, so I eliminated it. I dropped some lines about external dependencies in the README file. Some critical words on that one: http://linuxtv.org/hg/dvb-apps/rev/7de0663facd9 1. alevt-dvb is not a DVB-only application. It's core origin is to address analogue cards. Only within a rather incomplete patchset alevt can address DVB cards too. In so far that's a bad idea to put it into the dvb-apps. 2. With the exception of Christoph Pfister who has done a very good job with the latest kaffeine the personal scenery @ linuxtv.org is like a rat race in the production of appropriate drivers. Production and maintenance of applications is rather cemetary-like @ linuxtv.org, i. e. de facto not existing. It's for instance hihghly questionable why there are still 2 formats for a channels.conf file (vdr format and the reduced zap format). The zap format is obsolete IMHO. As the situation is as it is, this expectation at least sounds utmost naive and has got nothing to do with reality as it is: What about adding this program to v4l-dvb (under v4l2-apps/util/)? AFAIK, alevt currently doesn't have a proper site where development could take place. I think it would enjoy a better maintenance if it was hosted in vl4-dvb, and it could be an additional testing tool useful for drivers development. And it is GPL-licensed. (Francesco Lavra) For Greg Kroah-Hartman: This one should go into kernel 2.6.32, just to close a gap of kernel regressions: http://linuxtv.org/hg/v4l-dvb/rev/2dfe2234e7ea ENJOY! CS Thanks Emil -- 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: Proposal for a V4L2 Media Controller mini-summit
Laurent Pinchart wrote: Hi Hans, On Wednesday 17 February 2010 19:33:33 Hans Verkuil wrote: On Friday 12 February 2010 15:50:08 Hans Verkuil wrote: There is another alternative and that is that I organize a mini-summit in May in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I think that it is more fun to do this during/before/after a conference. If only because there are a lot of linux kernel experts on hand during such a conference that you can ask for help if needed. Please let me know asap if you are interested in attending such a mini-summit and what dates are possible for you: a: April 10-11 (or 12) b: April 12-14 c: April 14 (or 15)-16 d: Somewhere in May (suggestions for dates are welcome) I would appreciate it if people/companies who are interested in attending would let me know as soon as possible. Options A and B are a no go, so it is either April 14-16, or it will be in May. It doesn't have to be definitive, but I would like to have an idea of what to expect. It's not a definitive no, but April 14-16 will be very difficult for me, so there's little chance I can attend. I can confirm now that only the May dates are possible for me. :-\ -- 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: Proposal for a V4L2 Media Controller mini-summit
Laurent Pinchart wrote: Hi Hans, On Wednesday 17 February 2010 19:33:33 Hans Verkuil wrote: On Friday 12 February 2010 15:50:08 Hans Verkuil wrote: There is another alternative and that is that I organize a mini-summit in May in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I think that it is more fun to do this during/before/after a conference. If only because there are a lot of linux kernel experts on hand during such a conference that you can ask for help if needed. Please let me know asap if you are interested in attending such a mini-summit and what dates are possible for you: a: April 10-11 (or 12) b: April 12-14 c: April 14 (or 15)-16 d: Somewhere in May (suggestions for dates are welcome) I would appreciate it if people/companies who are interested in attending would let me know as soon as possible. Options A and B are a no go, so it is either April 14-16, or it will be in May. It doesn't have to be definitive, but I would like to have an idea of what to expect. It's not a definitive no, but April 14-16 will be very difficult for me, so there's little chance I can attend. I can confirm now that only the May dates are possible for me. :-\ Darn. Having a mini-summit without Laurent and yourself is pointless since you are both key developers. New proposal: May 5-7 in Lysaker, Norway. Does that work? 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
tm6000: patch serie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mauro, have you seen my patch serie from monday? Stefan Ringel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLfT6gAAoJEDX/lZlmjdJl+KQH/iVFTWfj730HfR7pkX9FvtMn sRA4IYhwUPRxm/sElZ+SSoQVska+i7VlJEWEMyujYociGqNYz7QaJeLqAzy0DidI zlyBk33Z1JzOCTvPzFIwMWPPjsc+ylfgvx0/DVcFI89aZ7royJBjxUwZmpU4TsNM x4CquEIegDDLWnfPJvz2DdUy2Br/77KfI4mEwHq20TG9NA2GWS1pcKsoq+RVXEIO Atm0jlwRe/p1HEtxDIBC2+6PH5/ttl9OKcGeZf4IFoFgB9xylyMbapiB2IdESrE/ UInuVcPH0tIYyGafmRlS0QIPX+zjComNRntU4pHWXz5o9BibONVGF41veQuOpns= =84YQ -END PGP SIGNATURE- -- 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: Proposal for a V4L2 Media Controller mini-summit
Hans Verkuil wrote: New proposal: May 5-7 in Lysaker, Norway. Does that work? Fits very well to my schedule. -- 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
aver
Hi! I learned that you can help with the driver for AverTV Studio 509 UA. From what I know about him: TV part works with the option card = 102 (AverTV Studio 507) tuner = 38 (PHILIPS_FM1216ME_MK3) but FM radio is made on tea5764hn and these options will not work (the driver has been written belaven...@gmail.com). Eugene Batsman -- 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] Question about telnet interface of dvbstream
Il giovedì 18 febbraio 2010 13:59:30 Mike Martin ha scritto: Hi I develop an application using dvbstream and am looking into the telnet interface. My question is whether the telnet interface can attach to a running instance of dvbstream (on the same multiplex obviously) Or does it have the same issues with locking dvb card thanks I have to say that I haven't tested the telnet interface in centuries; actually I don't know if it's broken, sorry. -- 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: where I can get UVC svn repository
hi: 2010/2/8 Paulo Assis pj.as...@gmail.com: Hi, linuxtv uses mercurial (or git) not svn, please check the how-to: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers regards, Paulo 2010/2/8 loody milo...@gmail.com: Dear all: I hear UVC is change its repository to linxutv. But I tried several possible repositories like svn co http://linuxtv.org/hg/~pinchartl/uvcvideo/tags svn co http://linuxtv.org/hg/~pinchartl/uvcvideo/rev/75c97b2d1a2a But svn says the repository is incorrect. Would anyone tell me where is the correct location? appreciate your help, miloody thanks for ur help :) I have successfully check the source code out. I have 2 questions: 1.When looking into the v4l folder, I find it seems different than kernel/driver/media/video; it seems more files than the one in kernel source. in my opinion, the source I checkout should be the same as kernel/driver/media/video, since they are kernel driver, right? 2. I try to build v4l2-apps but it seems I need to have at4 in advance. My distribution is ubuntu and I have already sudo apt-get install qt4-dev-tools, but it still complain: g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I../../include -I../../libv4l2util -I../../libv4l/include -I. -o qv4l2.o qv4l2.cpp In file included from qv4l2.cpp:20: qv4l2.h:23:23: error: QMainWindow: No such file or directory I find it is really no any qt4 headers in the include file that -I point to. does that mean I apt-get the wrong package? appreciate your kind help, miloody -- 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: alevt-dvb 1.7.0: new version, should be free from bugs now
On Thu, Feb 18, 2010 at 09:57:56AM +0100, Chicken Shack wrote: For Greg Kroah-Hartman: This one should go into kernel 2.6.32, just to close a gap of kernel regressions: http://linuxtv.org/hg/v4l-dvb/rev/2dfe2234e7ea I have no idea what you are asking me to do here. If you need a patch in the -stable tree, send the git commit id of the patch that is in Linus's tree to the sta...@kernel.org email address. If it is not in Linus's tree, I can not accept it. confused, greg k-h -- 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: alevt-dvb 1.7.0: new version, should be free from bugs now
Am Donnerstag, den 18.02.2010, 06:40 -0800 schrieb Greg KH: On Thu, Feb 18, 2010 at 09:57:56AM +0100, Chicken Shack wrote: For Greg Kroah-Hartman: This one should go into kernel 2.6.32, just to close a gap of kernel regressions: http://linuxtv.org/hg/v4l-dvb/rev/2dfe2234e7ea I have no idea what you are asking me to do here. If you need a patch in the -stable tree, send the git commit id of the patch that is in Linus's tree to the sta...@kernel.org email address. OK. So this is a bit new and confusing, and it is definitely not my job, as there are so-called MAINTAINERS for that, but I will try my best: Here is the link: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=691c9ae099b9bcb5c27125af00a4a90120977458 and this ought to be the commit id: commit 691c9ae099b9bcb5c27125af00a4a90120977458 SOB etc. please see link. If it is not in Linus's tree, I can not accept it. It is there, please see above! Instead of doing a steady maintainers job, Mauro Carvalho Chehab prefers to play kiddish games by substituting functionable kernel patches with his own disfunctionable ones, as you can see here: http://www.spinics.net/lists/linux-media/msg15749.html and here: http://www.spinics.net/lists/linux-media/msg15761.html The maintainers job would have been to send the commit ID to sta...@kernel.org, but foolish experiments seem to be more important than a fix for a stable kernel. confused, greg k-h enlightened and delighted, Chicken Shack :) :) sta...@kernel.org Cced. -- 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: alevt-dvb 1.7.0: new version, should be free from bugs now
On Thu, Feb 18, 2010 at 04:15:47PM +0100, Chicken Shack wrote: Am Donnerstag, den 18.02.2010, 06:40 -0800 schrieb Greg KH: On Thu, Feb 18, 2010 at 09:57:56AM +0100, Chicken Shack wrote: For Greg Kroah-Hartman: This one should go into kernel 2.6.32, just to close a gap of kernel regressions: http://linuxtv.org/hg/v4l-dvb/rev/2dfe2234e7ea I have no idea what you are asking me to do here. If you need a patch in the -stable tree, send the git commit id of the patch that is in Linus's tree to the sta...@kernel.org email address. OK. So this is a bit new and confusing, and it is definitely not my job, as there are so-called MAINTAINERS for that, but I will try my best: Here is the link: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=691c9ae099b9bcb5c27125af00a4a90120977458 and this ought to be the commit id: commit691c9ae099b9bcb5c27125af00a4a90120977458 SOB etc. please see link. That patch is already queued up for the next 2.6.32-stable kernel release. The people involved in that patch should have already gotten an email saying so. If it is not in Linus's tree, I can not accept it. It is there, please see above! Instead of doing a steady maintainers job, Mauro Carvalho Chehab prefers to play kiddish games by substituting functionable kernel patches with his own disfunctionable ones, as you can see here: I have a 6 year old with better manners, please leave these kinds of insults at home. The maintainers already properly notified the stable team of that patch, as you can see by it already being queued up. bah, greg k-h -- 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: alevt-dvb 1.7.0: new version, should be free from bugs now
Am Donnerstag, den 18.02.2010, 07:34 -0800 schrieb Greg KH: On Thu, Feb 18, 2010 at 04:15:47PM +0100, Chicken Shack wrote: Am Donnerstag, den 18.02.2010, 06:40 -0800 schrieb Greg KH: On Thu, Feb 18, 2010 at 09:57:56AM +0100, Chicken Shack wrote: For Greg Kroah-Hartman: This one should go into kernel 2.6.32, just to close a gap of kernel regressions: http://linuxtv.org/hg/v4l-dvb/rev/2dfe2234e7ea I have no idea what you are asking me to do here. If you need a patch in the -stable tree, send the git commit id of the patch that is in Linus's tree to the sta...@kernel.org email address. OK. So this is a bit new and confusing, and it is definitely not my job, as there are so-called MAINTAINERS for that, but I will try my best: Here is the link: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=691c9ae099b9bcb5c27125af00a4a90120977458 and this ought to be the commit id: commit 691c9ae099b9bcb5c27125af00a4a90120977458 SOB etc. please see link. That patch is already queued up for the next 2.6.32-stable kernel release. The people involved in that patch should have already gotten an email saying so. Thanks! This is the only thing I wanted to make sure. Regards CS -- 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: tm6000: patch serie
Stefan Ringel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mauro, have you seen my patch serie from monday? Yes, I've seen. I'll be handling it likely today. PS.: Next time, just take a look at patchwork.kernel.org. If the patches are there marked as New, they are on my queue ;) Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] video_device: don't free_irq() an element past array vpif_obj.dev[] and fix test
Roel,
Thanks for the patch.
In vpif_get_std_info(): std_info doesn't need the NULL test, it was already
dereferenced anyway. If std_info-stdid is 0 we could early return -1.
In vpif_probe(): local variable q was only assigned. If we error out with
either last two goto's then j equals VPIF_DISPLAY_MAX_DEVICES. So after the
probe_out: label, k also reaches VPIF_DISPLAY_MAX_DEVICES after the loop.
In
the first iteration in the loop after vpif_int_err: a free_irq() can occur
of an element vpif_obj.dev[VPIF_DISPLAY_MAX_DEVICES]-channel_id which is
outside vpif_obj.dev[] array boundaries.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Or am I mistaken?
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index dfddef7..8f6605d 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -383,7 +383,7 @@ static int vpif_get_std_info(struct channel_obj *ch)
int index;
std_info-stdid = vid_ch-stdid;
- if (!std_info)
+ if (!std_info-stdid)
return -1;
This is a NACK. We shouldn't check for stdid since the function is supposed
to update std_info. So just remove
if (!std_info)
return -1;
I am okay with the below change. So please re-submit the patch with the
above change and my ACK.
Thanks
Murali
for (index = 0; index ARRAY_SIZE(ch_params); index++) {
@@ -1423,7 +1423,7 @@ static __init int vpif_probe(struct platform_device
*pdev)
{
struct vpif_subdev_info *subdevdata;
struct vpif_display_config *config;
- int i, j = 0, k, q, m, err = 0;
+ int i, j = 0, k, m, err = 0;
struct i2c_adapter *i2c_adap;
struct common_obj *common;
struct channel_obj *ch;
@@ -1573,10 +1573,12 @@ probe_out:
video_device_release(ch-video_dev);
ch-video_dev = NULL;
}
+ if (k == VPIF_DISPLAY_MAX_DEVICES)
+ k = VPIF_DISPLAY_MAX_DEVICES - 1;
vpif_int_err:
v4l2_device_unregister(vpif_obj.v4l2_dev);
vpif_err(VPIF IRQ request failed\n);
- for (q = k; k = 0; k--) {
+ for (; k = 0; k--) {
for (m = i; m = res-start; m--)
free_irq(m, (void *)(vpif_obj.dev[k]-channel_id));
res = platform_get_resource(pdev, IORESOURCE_IRQ, k-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
--
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-next: Tree for February 18 (media/video/gspca)
On 02/18/10 01:49, Stephen Rothwell wrote: Hi all, Changes since 20100217: when CONFIG_INPUT is not enabled: drivers/media/video/gspca/gspca.c:2345: error: 'struct gspca_dev' has no member named 'input_dev' drivers/media/video/gspca/gspca.c:2347: error: 'struct gspca_dev' has no member named 'input_dev' -- ~Randy -- 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
gst-launch and locking of dvb adapter
Hi does anyone know if it is possible to use gst-launch to record two dvb streams simultaneously with dvbsrc I am trying a pipeline such as gst-launch dvbsrc pids=6881:6882 ! filesink location=ds9a.ps but I keep getting problems with freeing pipeline I know dvbstreamer can do it so it should be possible somehow any hints appreciated -- 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] Updated videobuf documentation
Here (finally) is a new version of the videobuf documentation patch. As requested by Mauro, I have cleaned up the (now) redundant information in v4l2-framework.txt. A couple of errors from the first version have also been remedied. jon V4L2: Add a document describing the videobuf layer Videobuf is a moderately complex API which most V4L2 drivers should use, but its documentation is...sparse. This document attempts to improve the situation. Signed-off-by: Jonathan Corbet cor...@lwn.net --- Documentation/video4linux/v4l2-framework.txt | 107 +--- Documentation/video4linux/videobuf | 345 ++ 2 files changed, 356 insertions(+), 96 deletions(-) create mode 100644 Documentation/video4linux/videobuf diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index b806eda..5402d19 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -587,99 +587,14 @@ struct v4l2_device *v4l2_dev = vdev-v4l2_dev; video buffer helper functions - -The v4l2 core API provides a standard method for dealing with video -buffers. Those methods allow a driver to implement read(), mmap() and -overlay() on a consistent way. - -There are currently methods for using video buffers on devices that -supports DMA with scatter/gather method (videobuf-dma-sg), DMA with -linear access (videobuf-dma-contig), and vmalloced buffers, mostly -used on USB drivers (videobuf-vmalloc). - -Any driver using videobuf should provide operations (callbacks) for -four handlers: - -ops-buf_setup - calculates the size of the video buffers and avoid they - to waste more than some maximum limit of RAM; -ops-buf_prepare - fills the video buffer structs and calls - videobuf_iolock() to alloc and prepare mmaped memory; -ops-buf_queue - advices the driver that another buffer were - requested (by read() or by QBUF); -ops-buf_release - frees any buffer that were allocated. - -In order to use it, the driver need to have a code (generally called at -interrupt context) that will properly handle the buffer request lists, -announcing that a new buffer were filled. - -The irq handling code should handle the videobuf task lists, in order -to advice videobuf that a new frame were filled, in order to honor to a -request. The code is generally like this one: - if (list_empty(dma_q-active)) - return; - - buf = list_entry(dma_q-active.next, struct vbuffer, vb.queue); - - if (!waitqueue_active(buf-vb.done)) - return; - - /* Some logic to handle the buf may be needed here */ - - list_del(buf-vb.queue); - do_gettimeofday(buf-vb.ts); - wake_up(buf-vb.done); - -Those are the videobuffer functions used on drivers, implemented on -videobuf-core: - -- Videobuf init functions - videobuf_queue_sg_init() - Initializes the videobuf infrastructure. This function should be - called before any other videobuf function on drivers that uses DMA - Scatter/Gather buffers. - - videobuf_queue_dma_contig_init - Initializes the videobuf infrastructure. This function should be - called before any other videobuf function on drivers that need DMA - contiguous buffers. - - videobuf_queue_vmalloc_init() - Initializes the videobuf infrastructure. This function should be - called before any other videobuf function on USB (and other drivers) - that need a vmalloced type of videobuf. - -- videobuf_iolock() - Prepares the videobuf memory for the proper method (read, mmap, overlay). - -- videobuf_queue_is_busy() - Checks if a videobuf is streaming. - -- videobuf_queue_cancel() - Stops video handling. - -- videobuf_mmap_free() - frees mmap buffers. - -- videobuf_stop() - Stops video handling, ends mmap and frees mmap and other buffers. - -- V4L2 api functions. Those functions correspond to VIDIOC_foo ioctls: - videobuf_reqbufs(), videobuf_querybuf(), videobuf_qbuf(), - videobuf_dqbuf(), videobuf_streamon(), videobuf_streamoff(). - -- V4L1 api function (corresponds to VIDIOCMBUF ioctl): - videobuf_cgmbuf() - This function is used to provide backward compatibility with V4L1 - API. - -- Some help functions for read()/poll() operations: - videobuf_read_stream() - For continuous stream read() - videobuf_read_one() - For snapshot read() - videobuf_poll_stream() - polling help function - -The better way to understand it is to take a look at vivi driver. One -of the main reasons for vivi is to be a videobuf usage example. the -vivi_thread_tick() does the task that the IRQ callback would do on PCI -drivers (or the irq callback on USB). +The v4l2 core API provides a standard method (called videobuf) for +dealing with video buffers. Those methods allow a driver to implement +read(), mmap() and overlay() on a consistent way. There
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 3 changesets: 01/03: gspca - sonixj: Add vertical flip control for sensor hv7131r. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=cdce9bf1b2e0 02/03: gspca - sonixj: Set the vertical flip at capture start for all sensors. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=e093382280d5 03/03: gspca - main: Fix a compile error when CONFIG_INPUT is not set. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=d8fafa7d88dc gspca.c |6 ++ sonixj.c | 30 +++--- 2 files changed, 25 insertions(+), 11 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal for a V4L2 Media Controller mini-summit
On Thu, 18 Feb 2010, Sakari Ailus wrote: Hans Verkuil wrote: New proposal: May 5-7 in Lysaker, Norway. Does that work? Fits very well to my schedule. May I also attend? 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: [PATCH] radio-si470x-common: -EINVAL overwritten in si470x_vidioc_s_tuner()
Hello Mauro,
no, the default value of retval makes no difference to the function.
Retval is set by si470x_disconnect_check and si470x_set_register.
After each call, retval is checked.
There is no need to reset it passed.
You may just do then:
int retval = si470x_disconnect_check(radio);
In all other set/get functions of v4l2_ioctl_ops in the driver, I just set the
default value of retval to 0.
To be identical in si470x_vidioc_s_tuner, I modified the patch to the one below.
I already pushed this and another cosmetic patch into mercurial:
http://linuxtv.org/hg/~tlorenz/v4l-dvb/rev/72a2f38d5956
http://linuxtv.org/hg/~tlorenz/v4l-dvb/rev/3efd5d32a618
Mauro, can you pull them?
Bye,
Tobias
--- a/linux/drivers/media/radio/si470x/radio-si470x-common.cThu Feb 11
23:11:30 2010 -0200
+++ b/linux/drivers/media/radio/si470x/radio-si470x-common.cThu Feb 18
20:31:33 2010 +0100
@@ -748,7 +748,7 @@
struct v4l2_tuner *tuner)
{
struct si470x_device *radio = video_drvdata(file);
- int retval = -EINVAL;
+ int retval = 0;
/* safety checks */
retval = si470x_disconnect_check(radio);
--
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] video_device: don't free_irq() an element past array vpif_obj.dev[] and fix test
- if (!std_info)
+ if (!std_info-stdid)
return -1;
This is a NACK. We shouldn't check for stdid since the function is supposed
to update std_info. So just remove
if (!std_info)
return -1;
I don't see how std_info could get updated. consider the loop in case
std_info-stdid equals 0:
for (index = 0; index ARRAY_SIZE(ch_params); index++) {
config = ch_params[index];
(config is a local variable)
if (config-stdid std_info-stdid) {
This fails for every index if std_info-stdid equals 0.
memcpy(std_info, config, sizeof(*config));
break;
}
}
So we always reach this with index == ARRAY_SIZE(ch_params)
if (index == ARRAY_SIZE(ch_params))
return -1;
So we could have returned -1 earlier.
I am okay with the below change. So please re-submit the patch with the
above change and my ACK.
Thanks
Murali
+ if (k == VPIF_DISPLAY_MAX_DEVICES)
+ k = VPIF_DISPLAY_MAX_DEVICES - 1;
actually I think this is still not right. shouldn't it be be
k = VPIF_DISPLAY_MAX_DEVICES - 1;
are you using this driver in your project?
No, I just found this in the code.
Thanks, Roel
--
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 09/11] zl10353: tm6000: bugfix reading problems with tm6000 i2c host
stefan.rin...@arcor.de wrote:
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
diff --git a/drivers/media/dvb/frontends/zl10353.c
b/drivers/media/dvb/frontends/zl10353.c
index 8c61271..9716d7e 100644
--- a/drivers/media/dvb/frontends/zl10353.c
+++ b/drivers/media/dvb/frontends/zl10353.c
@@ -74,7 +74,7 @@ static int zl10353_write(struct dvb_frontend *fe, u8 *ibuf,
int ilen)
return 0;
}
-static int zl10353_read_register(struct zl10353_state *state, u8 reg)
+static int zl10353_read1_register(struct zl10353_state *state, u8 reg)
{
int ret;
u8 b0[1] = { reg };
@@ -97,6 +97,41 @@ static int zl10353_read_register(struct zl10353_state
*state, u8 reg)
return b1[0];
}
+static int zl10353_read2_register(struct zl10353_state *state, u8 reg)
+{
+ int ret;
+ u8 b0[1] = { reg - 1 };
+ u8 b1[1] = { 0 };
+ struct i2c_msg msg[2] = { { .addr = state-config.demod_address,
+ .flags = 0,
+ .buf = b0, .len = 1 },
+ { .addr = state-config.demod_address,
+ .flags = I2C_M_RD,
+ .buf = b1, .len = 2 } };
+
+ ret = i2c_transfer(state-i2c, msg, 2);
+
+ if (ret != 2) {
+ printk(%s: readreg error (reg=%d, ret==%i)\n,
+__func__, reg, ret);
+ return ret;
+ }
+
+ return b1[1];
+}
This patch doesn't look correct to me. The size of the zl10353 read register
doesn't
change when it is used with tm6000. The solution should be at tm6000-i2c,
basically
using the same REQ for 2 bytes when only 1 byte is being read.
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
[GIT FIXES FOR 2.6.34] uvcvideo updates
Hi Mauro, The following changes since commit 8e17df0d68f260e9e722b5f3adfa18f553542f93: Randy Dunlap (1): V4L/DVB: dvb: fix sparse warnings are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo Laurent Pinchart (7): uvcvideo: Increase the streaming control timeout to 5 seconds uvcvideo: Use %pUl printk format specifier to print GUIDs uvcvideo: Return -ERANGE when setting a control to an out-of-range menu index uvcvideo: Cache control min, max, res and def query results uvcvideo: Clamp control values to the minimum and maximum values uvcvideo: Blacklist gain control for Asus EeePC T91 integrated webcam uvcvideo: Check uvc_ctrl_begin return value in VIDIOC_S_CTRL drivers/media/video/uvc/uvc_ctrl.c | 242 +- drivers/media/video/uvc/uvc_driver.c |9 +- drivers/media/video/uvc/uvc_v4l2.c |4 +- drivers/media/video/uvc/uvcvideo.h | 15 +-- 4 files changed, 159 insertions(+), 111 deletions(-) Douglas, commit 2/7 (uvcvideo: Use %pUl printk format specifier to print GUIDs) needs so love when ported to -hg. The code will still compile fine on older kernels, but the %pUl format was added between 2.6.32 an d 2.6.33-rc1. #ifdef magic is required for kernels older than 2.6.33-rc1 to ignore the changes made by the commit. Should I send you a patch, or is it the kind of things you handle yourself ? If a patch is needed, what tree/branch should I based it on ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] video_device: don't free_irq() an element past array vpif_obj.dev[] and fix test
- if (!std_info)
+ if (!std_info-stdid)
return -1;
This is a NACK. We shouldn't check for stdid since the function is
supposed
to update std_info. So just remove
if (!std_info)
return -1;
I don't see how std_info could get updated. consider the loop in case
std_info-stdid equals 0:
Ok. You are right! The ch_params[] is a table for keeping the information
about different standards supported. For a given stdid in std_info, the
function matches the stdid with that in the table and get the corresponding
entry.
I am okay with the below change. So please re-submit the patch with the
above change and my ACK.
Thanks
Murali
+ if (k == VPIF_DISPLAY_MAX_DEVICES)
+ k = VPIF_DISPLAY_MAX_DEVICES - 1;
actually I think this is still not right. shouldn't it be be
k = VPIF_DISPLAY_MAX_DEVICES - 1;
What you mean here? What you suggest here is same as in your patch, right?
Murali
are you using this driver in your project?
No, I just found this in the code.
Thanks, Roel
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: [PATCH 07/11] tm6000: add i2c send recv functions
stefan.rin...@arcor.de wrote: From: Stefan Ringel stefan.rin...@arcor.de Signed-off-by: Stefan Ringel stefan.rin...@arcor.de Why do you need to split it into two functions? It should be noticed that the naming tm6000_i2c_recv_word is wrong, since the size can be bigger than 2. Also, this patch broke compilation on -git: CC [M] drivers/staging/tm6000/tm6000-i2c.o drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_send_byte’: drivers/staging/tm6000/tm6000-i2c.c:50: error: ‘REQ_16_SET_GET_I2C_WR1_RND’ undeclared (first use in this function) drivers/staging/tm6000/tm6000-i2c.c:50: error: (Each undeclared identifier is reported only once drivers/staging/tm6000/tm6000-i2c.c:50: error: for each function it appears in.) drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_recv_byte’: drivers/staging/tm6000/tm6000-i2c.c:55: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token drivers/staging/tm6000/tm6000-i2c.c:55: error: expected expression before ‘:’ token drivers/staging/tm6000/tm6000-i2c.c:60: error: ‘rc’ undeclared (first use in this function) drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_recv_word’: drivers/staging/tm6000/tm6000-i2c.c:68: error: ‘REQ_14_SET_GET_I2C_WR2_RND’ undeclared (first use in this function) make[1]: ** [drivers/staging/tm6000/tm6000-i2c.o] Erro 1 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
[patch] em28xx : Terratec Cinergy Hybrid T USB XS FR is working.
Hi,
I succed in running Cinergy Hybrid T USB XS FR in both modes.
I enclose the patch against v4l-dvb-14021dfc00f3
Regards.
Michel.
diff -ru v4l-dvb-14021dfc00f3-orig/linux/drivers/media/video/em28xx/em28xx-cards.c v4l-dvb-14021dfc00f3-mod/linux/drivers/media/video/em28xx/em28xx-cards.c
--- v4l-dvb-14021dfc00f3-orig/linux/drivers/media/video/em28xx/em28xx-cards.c 2010-02-12 02:11:30.0 +0100
+++ v4l-dvb-14021dfc00f3-mod/linux/drivers/media/video/em28xx/em28xx-cards.c 2010-02-18 21:52:43.0 +0100
@@ -774,15 +774,12 @@
[EM2880_BOARD_TERRATEC_HYBRID_XS_FR] = {
.name = Terratec Hybrid XS Secam,
- .valid= EM28XX_BOARD_NOT_VALIDATED,
.has_msp34xx = 1,
.tuner_type = TUNER_XC2028,
.tuner_gpio = default_tuner_gpio,
.decoder = EM28XX_TVP5150,
-#if 0 /* FIXME: add an entry at em28xx-dvb */
.has_dvb = 1,
.dvb_gpio = default_digital,
-#endif
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
diff -ru v4l-dvb-14021dfc00f3-orig/linux/drivers/media/video/em28xx/em28xx-dvb.c v4l-dvb-14021dfc00f3-mod/linux/drivers/media/video/em28xx/em28xx-dvb.c
--- v4l-dvb-14021dfc00f3-orig/linux/drivers/media/video/em28xx/em28xx-dvb.c 2010-02-12 02:11:30.0 +0100
+++ v4l-dvb-14021dfc00f3-mod/linux/drivers/media/video/em28xx/em28xx-dvb.c 2010-02-15 21:45:30.0 +0100
@@ -503,6 +503,7 @@
}
break;
case EM2880_BOARD_TERRATEC_HYBRID_XS:
+ case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
case EM2882_BOARD_DIKOM_DK300:
dvb-frontend = dvb_attach(zl10353_attach,
[PATCH 07/11] tm6000: add i2c send recv functions
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 6b17d0b..9d02674 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -42,6 +42,32 @@ MODULE_PARM_DESC(i2c_debug, enable debug messages [i2c]);
printk(KERN_DEBUG %s at %s: fmt, \
dev-name, __FUNCTION__ , ##args); } while (0)
+int tm6000_i2c_send_byte (struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
+{
+ return tm6000_read_write_usb (dev, USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0, buf, len);
+}
+
+int tm6000_i2c_recv_byte (struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
+{
+ int rc:
+
+ rc = tm6000_read_write_usb (dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0, buf, len);
+
+ return rc;
+}
+
+int tm6000_i2c_recv_word (struct tm6000_core *dev, unsigned char addr, __u16
reg, char *buf , int len)
+{
+ int rc;
+
+ rc = tm6000_read_write_usb (dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
+
+ return rc;
+}
+
static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg msgs[], int num)
{
@@ -76,13 +102,14 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
i2c_dprintk(2, ; joined to read %s len=%d:,
i == num - 2 ? stop : nonstop,
msgs[i + 1].len);
- rc = tm6000_read_write_usb (dev,
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- msgs[i].len == 1 ? REQ_16_SET_GET_I2C_WR1_RDN
-: REQ_14_SET_GET_I2C_WR2_RDN,
- addr | msgs[i].buf[0] 8,
- msgs[i].len == 1 ? 0 : msgs[i].buf[1],
- msgs[i + 1].buf, msgs[i + 1].len);
+
+ if (msgs[i].len == 1) {
+ rc = tm6000_i2c_recv_byte (dev, addr,
msgs[i].buf[0],
+ msgs[i + 1].buf, msgs[i + 1].len);
+ } else {
+ rc = tm6000_i2c_recv_word (dev, addr,
msgs[i].buf[0] 8 | msgs[i].buf[1],
+ msgs[i + 1].buf, msgs[i + 1].len);
+ }
i++;
if ((dev-dev_type == TM6010) (addr == 0xc2)) {
@@ -97,10 +124,8 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
if (i2c_debug = 2)
for (byte = 0; byte msgs[i].len; byte++)
printk( %02x, msgs[i].buf[byte]);
- rc = tm6000_read_write_usb(dev,
- USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN,
- addr | msgs[i].buf[0] 8, 0,
+
+ rc = tm6000_i2c_send_byte(dev, addr, msgs[i].buf[0],
msgs[i].buf + 1, msgs[i].len - 1);
if ((dev-dev_type == TM6010) (addr == 0xc2)) {
--
1.6.6.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
Documentation questions
Hi, (Please cc: me, I'm not subscribed yet) After struggling to work out how stuff worked from the existing DVB API docs(+), I'm currently attempting to improve the API documentation, to cover the v5 API, and I've got a few questions: * Is anyone else working on docs right now? (i.e. am I wasting my time?) * Looking at the current kernel sources, the properties DTV_DISEQC_MASTER, DTV_DISEQC_SLAVE_REPLY, DTV_FE_CAPABILITY and DTV_FE_CAPABILITY_COUNT don't seem to be implemented. Is this actually the case, or have I missed something? * Most of the information in struct dvb_frontend_info doesn't seem to exist in the v5 API. Is there an expected way of getting this info (or isn't it considered useful any more?) Is FE_GET_INFO still recommended for that purpose in the v5 API? * DTV_DELIVERY_SYSTEM is writable. What does this do? I would have thought it's a read-only property. * Is there any way of telling which properties are useful for which delivery system types, or should I be going back to the relevant specifications for each type to get that information? * Is the v5 API for frontends only, or is there a similar key/value system in place/planned for the other DVB components such as demuxers? Thanks, Hugo. (+) Actually, the docs were pretty helpful, up to a point. Certainly better than some I've tried to read in the past. The biggest problem is the lack of coverage of the v5 API. -- === Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- How deep will this sub go? Oh, she'll go all the way to --- the bottom if we don't stop her. signature.asc Description: Digital signature
Re: [PATCH 0/4] DocBook additions for V4L new formats
On 02/17/10 18:31, Randy Dunlap wrote: On 02/17/10 09:06, Mauro Carvalho Chehab wrote: Adds DocBook items for Bayer and two proprietary formats used on gspca. In the past, a few targets were generated at the Mercurial development tree. However, at the beginning of this year, we moved to use -git as the primary resource. So, the Makefile logic to autogenerate those targets needs to be moved to git as well. While here, I noticed that DocBook is too verbose to generate the htmldocs target. So, make it less verbose, if V=0. Guennadi Liakhovetski (1): V4L/DVB: v4l: document new Bayer and monochrome pixel formats Mauro Carvalho Chehab (3): DocBook/Makefile: Make it less verbose DocBook: Add rules to auto-generate some media docbooks DocBook/v4l/pixfmt.xml: Add missing formats for gspca cpia1 and sn9c2028 drivers Hi Mauro, Patches 1 3 are OK. I'm having problems with patch 2/4 when I use O=DOCDIR on the make command (which I always do). videodev2.h.xml is not being generated, and after that it goes downhill. I will let you know more when I have more info, or you or Guennadi can send a fixup patch for that. I'm not making any progress on this. make O=DOCDIR htmldocs needs to work, but it does not: Also, $(objtree)/Documentation/DocBook/index.html is no longer being generated after these 4 patches are applied. That needs to be fixed also. I get lots of these: grep: /lnx/src/lnx-2633-rc8-docbook/DOC2/Documentation/DocBook/v4l/vidioc-*.xml: No such file or directory grep: /lnx/src/lnx-2633-rc8-docbook/DOC2/Documentation/DocBook/v4l/vidioc-*.xml: No such file or directory grep: /lnx/src/lnx-2633-rc8-docbook/DOC2/Documentation/DocBook/v4l/vidioc-*.xml: No such file or directory followed by: GEN Documentation/DocBook/media-indices.tmpl GEN Documentation/DocBook/v4l/videodev2.h.xml /bin/bash: line 1: Documentation/DocBook/v4l/videodev2.h.xml: No such file or directory make[2]: *** [Documentation/DocBook/v4l/videodev2.h.xml] Error 1 The patches do seem to be OK if O=dirname is not used... except that the main index.html is still not being generated. Documentation/DocBook/Makefile | 493 +++- Documentation/DocBook/dvb/frontend.h.xml | 415 -- Documentation/DocBook/media-entities.tmpl| 383 -- Documentation/DocBook/media-indices.tmpl | 89 -- Documentation/DocBook/v4l/pixfmt-srggb10.xml | 90 ++ Documentation/DocBook/v4l/pixfmt-srggb8.xml | 67 + Documentation/DocBook/v4l/pixfmt-y10.xml | 79 ++ Documentation/DocBook/v4l/pixfmt.xml | 18 +- Documentation/DocBook/v4l/videodev2.h.xml| 1757 -- 9 files changed, 738 insertions(+), 2653 deletions(-) delete mode 100644 Documentation/DocBook/dvb/frontend.h.xml delete mode 100644 Documentation/DocBook/media-entities.tmpl delete mode 100644 Documentation/DocBook/media-indices.tmpl create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb10.xml create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb8.xml create mode 100644 Documentation/DocBook/v4l/pixfmt-y10.xml delete mode 100644 Documentation/DocBook/v4l/videodev2.h.xml -- ~Randy -- 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: Proposal for a V4L2 Media Controller mini-summit
On Thursday 18 February 2010 19:58:07 Guennadi Liakhovetski wrote: On Thu, 18 Feb 2010, Sakari Ailus wrote: Hans Verkuil wrote: New proposal: May 5-7 in Lysaker, Norway. Does that work? Fits very well to my schedule. May I also attend? Certainly! It's an open invitation! Regards, Hans Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Documentation questions
On Thu, 2010-02-18 at 21:12 +, Hugo Mills wrote: Hi, (Please cc: me, I'm not subscribed yet) After struggling to work out how stuff worked from the existing DVB API docs(+), I'm currently attempting to improve the API documentation, to cover the v5 API, and I've got a few questions: * Is anyone else working on docs right now? (i.e. am I wasting my time?) About a year ago, I stated I was going to add the DVB API v5 additions. Well, you see how far that has gotten: nowhere. :P So please, your are welcome to help. * Looking at the current kernel sources, the properties DTV_DISEQC_MASTER, DTV_DISEQC_SLAVE_REPLY, DTV_FE_CAPABILITY and DTV_FE_CAPABILITY_COUNT don't seem to be implemented. Is this actually the case, or have I missed something? * Most of the information in struct dvb_frontend_info doesn't seem to exist in the v5 API. Is there an expected way of getting this info (or isn't it considered useful any more?) Is FE_GET_INFO still recommended for that purpose in the v5 API? * DTV_DELIVERY_SYSTEM is writable. What does this do? I would have thought it's a read-only property. * Is there any way of telling which properties are useful for which delivery system types, or should I be going back to the relevant specifications for each type to get that information? I have no comment on these at the moment. I'd need to look into things and get back to you. * Is the v5 API for frontends only, or is there a similar key/value system in place/planned for the other DVB components such as demuxers? As far as I know for the DVB v5 additions, that came from what was originally called S2API, yes, they are only for frontends. Some additional ioctl()'s related to the demux have been added as well and are unrelated to the S2API additions. Regards, Andy Thanks, Hugo. (+) Actually, the docs were pretty helpful, up to a point. Certainly better than some I've tried to read in the past. The biggest problem is the lack of coverage of the v5 API. -- 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
eb1a:2861 (K-VOX Mini USB MovieEditor) em28xx card=10
Hi all, I have an USB video capture dongle, labelled K-VOX Mini USB MovieEditor, which was not detected correctly by em28xx module. In the syslog I saw I should send a report if I got this device work. I have tried a few card=xx parameters, and finally this worked: # modprobe em28xx card=10 # lsusb [snip] Bus 001 Device 028: ID eb1a:2861 eMPIA Technology, Inc. [snip] (syslog messages on first connection, reformatted) kernel: em28xx: New device @ 480 Mbps (eb1a:2861, interface 0, class 0) kernel: em28xx #0: chip ID is em2860 kernel: em28xx #0: board has no eeprom kernel: em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) kernel: em28xx #0: found i2c device @ 0xb8 [tvp5150a] kernel: em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. kernel: em28xx #0: You may try to use card=n insmod option to workaround that. kernel: em28xx #0: Please send an email with this log to: kernel: em28xx #0: V4L Mailing List linux-media@vger.kernel.org kernel: em28xx #0: Board eeprom hash is 0x kernel: em28xx #0: Board i2c devicelist hash is 0x77800080 kernel: em28xx #0: Here is a list of valid choices for the card=n insmod option: kernel: em28xx #0: card=0 - Unknown EM2800 video grabber [snip] kernel: em28xx #0: card=73 - Reddo DVB-C USB TV Box kernel: em28xx #0: Config register raw data: 0x10 kernel: em28xx #0: AC97 vendor ID = 0x kernel: em28xx #0: AC97 features = 0x6a90 kernel: em28xx #0: Empia 202 AC97 audio processor detected kernel: em28xx #0: v4l2 driver version 0.1.2 kernel: em28xx #0: V4L2 video device registered as /dev/video1 kernel: em28xx #0: V4L2 VBI device registered as /dev/vbi0 kernel: em28xx audio device (eb1a:2861): interface 1, class 1 kernel: em28xx audio device (eb1a:2861): interface 2, class 1 kernel: usbcore: registered new interface driver em28xx kernel: em28xx driver loaded modprobe: FATAL: Error running install command for snd_usb_audio (syslog messages with card=10, reformatted) kernel: usb 1-2: new high speed USB device using ehci_hcd and address 28 kernel: usb 1-2: New USB device found, idVendor=eb1a, idProduct=2861 kernel: usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 kernel: usb 1-2: configuration #1 chosen from 1 choice kernel: em28xx: New device @ 480 Mbps (eb1a:2861, interface 0, class 0) kernel: em28xx #0: chip ID is em2860 kernel: em28xx #0: board has no eeprom kernel: em28xx #0: Identified as Hauppauge WinTV HVR 900 (card=10) kernel: tveeprom 3-0050: Encountered bad packet header [00]. Corrupt or not a Hauppauge eeprom. kernel: tvp5150 3-005c: chip found @ 0xb8 (em28xx #0) kernel: input: em28xx IR (em28xx #0) as /class/input/input14 kernel: em28xx #0: Config register raw data: 0x10 kernel: em28xx #0: AC97 vendor ID = 0x kernel: em28xx #0: AC97 features = 0x6a90 kernel: em28xx #0: Empia 202 AC97 audio processor detected kernel: tvp5150 3-005c: tvp5150am1 detected. kernel: em28xx #0: v4l2 driver version 0.1.2 kernel: em28xx #0: V4L2 video device registered as /dev/video1 kernel: em28xx #0: V4L2 VBI device registered as /dev/vbi0 kernel: em28xx audio device (eb1a:2861): interface 1, class 1 kernel: em28xx audio device (eb1a:2861): interface 2, class 1 modprobe: FATAL: Error running install command for snd_usb_audio kernel: tvp5150 3-005c: tvp5150am1 detected. # lsusb -vvv [snip] Bus 001 Device 029: ID eb1a:2861 eMPIA Technology, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0xeb1a eMPIA Technology, Inc. idProduct 0x2861 bcdDevice1.00 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 555 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Robert Lowery wrote:
Mauro's new code does the 50 offset unconditionally for DTV7 by
setting offset = 225, not just when the ZARLINK456 or DIBCOM52 tables
were explicitly selected. This change is what appears to cause issues for
me.
I've reviewed all information and troubles we have with xc3028 tuning,
including the reports related to newer firmwares for XC3028L. I think
that the right fix is the one provided on this patch.
Could you all please verify if this patch fixes the issues, without causing
any regression?
Cheers,
Mauro.
---
V4L/DVB: tuner-xc2028: fix tuning logic
There's one reported regression in Australia (DTV7) and some
reported troubles with newer firmwares. Rework the logic to improve
tuner on those cases.
Thanks-to: Robert Lowery rglow...@exemail.com.au
Thanks-to: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tuner-xc2028.c | 51
1 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..eb782a0 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -932,30 +932,49 @@ static int generic_set_freq(struct dvb_frontend *fe, u32
freq /* in HZ */,
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
- if (new_mode == T_ANALOG_TV)
+ if (new_mode == T_ANALOG_TV) {
rc = send_seq(priv, {0x00, 0x00});
- /*
-* Digital modes require an offset to adjust to the
-* proper frequency.
-* Analog modes require offset = 0
-*/
- if (new_mode == T_DIGITAL_TV) {
- /* Sets the offset according with firmware */
+ /* Analog modes require offset = 0 */
+ } else {
+ /*
+* Digital modes require an offset to adjust to the
+* proper frequency. The offset depends on what
+* firmware version is used.
+*/
+
+ /*
+* Adjust to the center frequency. This is calculated by the
+* formula: offset = 1.25MHz - BW/2
+* For DTV 7/8, the firmware uses BW = 8000, so it needs a
+* further adjustment to get the frequency center on VHF
+*/
if (priv-cur_fw.type DTV6)
offset = 175;
else if (priv-cur_fw.type DTV7)
offset = 225;
else/* DTV8 or DTV78 */
offset = 275;
+ if ((priv-cur_fw.type DTV78) freq 47000)
+ offset -= 50;
/*
-* We must adjust the offset by 500kHz when
-* tuning a 7MHz VHF channel with DTV78 firmware
-* (used in Australia, Italy and Germany)
+* xc3028 additional magic
+* Depending on the firmware version, it needs some adjustments
+* to properly centralize the frequency. This seems to be
+* needed to compensate the SCODE table adjustments made by
+* newer firmwares
*/
- if ((priv-cur_fw.type DTV78) freq 47000)
- offset -= 50;
+
+ if (priv-firm_version = 0x0302) {
+ if (priv-cur_fw.type DTV7)
+ offset -= 30;
+ else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8
*/
+ offset += 20;
+ } else {
+ if (priv-cur_fw.type DTV7)
+ offset -= 50;
+ }
}
div = (freq - offset + DIV / 2) / DIV;
@@ -1114,7 +1133,11 @@ static int xc2028_set_params(struct dvb_frontend *fe,
/* All S-code tables need a 200kHz shift */
if (priv-ctrl.demod) {
- demod = priv-ctrl.demod + 200;
+ /*
+* Newer firmwares require a 200 kHz offset only for ATSC
+*/
+ if (type == ATSC || priv-firm_version 0x0302)
+ demod = priv-ctrl.demod + 200;
/*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
--
1.6.6.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
[GIT PULL for 2.6.33-rc8] Some bug and regression fixes for V4L/DVB
The following changes since commit f8b55f251012e104093e105483c45c5d85ad3040: Christine Caulfield (1): Orphan DECnet are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Ben Hutchings (1): V4L/DVB: cxusb: Select all required frontend and tuner modules Jean Delvare (1): V4L/DVB: bttv: Move I2C IR initialization Kuninori Morimoto (1): soc-camera: mt9t112: modify exiting conditions from standby mode Martin Fuzzey (1): V4L/DVB: Video : pwc : Fix regression in pwc_set_shutter_speed caused by bad constant = sizeof conversion. Richard Guenther (1): V4L/DVB: dvb: l64781.ko broken with gcc 4.5 drivers/media/dvb/dvb-usb/Kconfig |4 +++- drivers/media/dvb/frontends/l64781.c|4 ++-- drivers/media/video/bt8xx/bttv-driver.c |1 + drivers/media/video/bt8xx/bttv-i2c.c|8 ++-- drivers/media/video/bt8xx/bttvp.h |1 + drivers/media/video/mt9t112.c |2 +- drivers/media/video/pwc/pwc-ctrl.c |2 +- 7 files changed, 15 insertions(+), 7 deletions(-) -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Robert Lowery wrote:
Mauro's new code does the 50 offset unconditionally for DTV7 by
setting offset = 225, not just when the ZARLINK456 or DIBCOM52
tables
were explicitly selected. This change is what appears to cause issues
for
me.
I've reviewed all information and troubles we have with xc3028 tuning,
including the reports related to newer firmwares for XC3028L. I think
that the right fix is the one provided on this patch.
Could you all please verify if this patch fixes the issues, without
causing
any regression?
Thanks Mauro, I'll test this ASAP.
I suspect there will still be issues with the demod + 500 shift in my
scenario as I had to remove this in the past when changing the offset back
to 275 or else I could not get a tuning lock.
I'll let you know.
-Rob
Cheers,
Mauro.
---
V4L/DVB: tuner-xc2028: fix tuning logic
There's one reported regression in Australia (DTV7) and some
reported troubles with newer firmwares. Rework the logic to improve
tuner on those cases.
Thanks-to: Robert Lowery rglow...@exemail.com.au
Thanks-to: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tuner-xc2028.c | 51
1 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..eb782a0 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -932,30 +932,49 @@ static int generic_set_freq(struct dvb_frontend *fe,
u32 freq /* in HZ */,
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
- if (new_mode == T_ANALOG_TV)
+ if (new_mode == T_ANALOG_TV) {
rc = send_seq(priv, {0x00, 0x00});
- /*
- * Digital modes require an offset to adjust to the
- * proper frequency.
- * Analog modes require offset = 0
- */
- if (new_mode == T_DIGITAL_TV) {
- /* Sets the offset according with firmware */
+ /* Analog modes require offset = 0 */
+ } else {
+ /*
+ * Digital modes require an offset to adjust to the
+ * proper frequency. The offset depends on what
+ * firmware version is used.
+ */
+
+ /*
+ * Adjust to the center frequency. This is calculated by the
+ * formula: offset = 1.25MHz - BW/2
+ * For DTV 7/8, the firmware uses BW = 8000, so it needs a
+ * further adjustment to get the frequency center on VHF
+ */
if (priv-cur_fw.type DTV6)
offset = 175;
else if (priv-cur_fw.type DTV7)
offset = 225;
else/* DTV8 or DTV78 */
offset = 275;
+ if ((priv-cur_fw.type DTV78) freq 47000)
+ offset -= 50;
/*
- * We must adjust the offset by 500kHz when
- * tuning a 7MHz VHF channel with DTV78 firmware
- * (used in Australia, Italy and Germany)
+ * xc3028 additional magic
+ * Depending on the firmware version, it needs some adjustments
+ * to properly centralize the frequency. This seems to be
+ * needed to compensate the SCODE table adjustments made by
+ * newer firmwares
*/
- if ((priv-cur_fw.type DTV78) freq 47000)
- offset -= 50;
+
+ if (priv-firm_version = 0x0302) {
+ if (priv-cur_fw.type DTV7)
+ offset -= 30;
+ else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8
*/
+ offset += 20;
+ } else {
+ if (priv-cur_fw.type DTV7)
+ offset -= 50;
+ }
}
div = (freq - offset + DIV / 2) / DIV;
@@ -1114,7 +1133,11 @@ static int xc2028_set_params(struct dvb_frontend
*fe,
/* All S-code tables need a 200kHz shift */
if (priv-ctrl.demod) {
- demod = priv-ctrl.demod + 200;
+ /*
+ * Newer firmwares require a 200 kHz offset only for ATSC
+ */
+ if (type == ATSC || priv-firm_version 0x0302)
+ demod = priv-ctrl.demod + 200;
/*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
--
1.6.6.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
