Re: Media controller: sysfs vs ioctl
Hi, Am Freitag, den 11.09.2009, 19:01 -0400 schrieb Andy Walls: > On Sat, 2009-09-12 at 00:21 +0200, Hans Verkuil wrote: > > Hi all, > > > > I've started this as a new thread to prevent polluting the discussions of > > the > > media controller as a concept. > > > > First of all, I have no doubt that everything that you can do with an ioctl, > > you can also do with sysfs and vice versa. That's not the problem here. > > > > The problem is deciding which approach is the best. > > I've wanted to reply earlier but I cannot collect enough time to do > proper research, but since you asked this particular question, I happen > to have something which may help. > > I would suggest evaluating a representative proposals by applying > Baldwin and Clark's Net Options Value (NOV) metric to a simple system > representation. The system to which to apply the metric would comprise: > > - a representative user space app > - a representative v4l-dvb driver > - an API concept/suggestion/proposal > > I think this metric is appropriate to apply, because the NOV is a way to > assign value to implementing options (i.e. options in modular systems). > An API itself is not a modular system and hard to evaluate in isolation, > so it needs to be evaluated in the context of the options it provies to > the system designers and maintainers. > > The NOV boils to simple concepts: > > 1. a system design has a total value that is its present value plus the > value of it's options that can be exploited in the future. > > 2. an option represents a potential value that may provide a return in > the future > > 3. an option has only a potential value (in the present) > > 4. an option only yields a return if that option may be exploited in the > future. The probability that the option may be exploited needs to be > taken into account. > > 5. an option has costs associated with exploiting it (in the future) > > I'm not advocating a rigorous computation of the metric for the > proposals, but more a qualitative look at the proposals but still using > the precise definition of the metric (sorry I don't have a URL > handy...). > > > I will note that I think am in agreement with Hans on sysfs. I think > the cost of trying to exploit any option provided through sysfs in a > userspace apppllication will nullify any technical benefit of said > option to the application. > > Lets say we want to convert an existing app to a "Media Controller > aware" version of that app. There is a cost to do that. Will the API > proposal make exploting some options have a large cost? Do some of the > options of the API have a low probability of being exploited? Do some > of the options of the API provide very low technical benefit? What does > the API proposal do to the total value of the system (e.g. an API with > no flexibility fixes the total value close to the present value and > there is no value to be realized from exploiting options in the future). > > > OK, I hope I've communicated what I mean. I feel like that all may be > less than clear. > > > These ideas have come from a confluence of research I've been doing at > work, and V4L-DVB work (thinking about Multiproto vs. DVB v5, and the > v4l2_subdev IR ops, etc.). > > > Regards, > Andy > just as a side note. We are not forced to accept any hardware design under all conditions anymore. If there are reasons, we can also tell them to go to Bill and Steve and to pay their fees per device. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: image quality of Labtec Webcam 2200
Also , about the negative value. It happens to when using Pac7311 on libv4l_convert. Usually it an -EAGAIN, that should be ignored. svv application, just ignore that, and another apps take in account. But would be nice to re test your webcam to find where the real problem is. Best Regards 2009/9/11 Németh Márton : > Márton Németh wrote: >> Hi, >> >> I have a Labtec Webcam 2200 and I have problems with the image quality >> with Linux 2.6.31 + libv4l 0.6.1. I made some experiments and stored >> each captured image as raw data and when libv4l was able to convert >> then I also stored the result as bmp. >> >> You can find my results at >> http://v4l-test.sourceforge.net/results/test-20090911/index.html >> There are three types of problems: >> a) Sometimes the picture contains a 8x8 pixel error, like in image #9 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 >> b) Sometimes the brightness of the half picture is changed, like in >> images #7, #36 and #37 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 >> c) Sometimes the libv4l cannot convert the raw image and the errno >> is set to EAGAIN (11), for example image #1, #2 and #3 >> >> Do you know how can I fix these problems? > > I investigated the c) point a little bit. When I get a negative return value > from the v4lconvert_convert() function then I print out the error message > what the > v4lconvert_get_error_message() function returns. With the result log file > I executed a "grep v4l-convert |sort |uniq" command. All the error messages > are > coming from the tinyjpeg.c (Small jpeg decoder library): > > v4l-convert: error decompressing JPEG: error: more then 63 AC components (65) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (66) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (67) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (68) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (69) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (70) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (71) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (72) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (73) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (75) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (76) > in huffman unit > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x00 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x01 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x02 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x04 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x08 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x09 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x0a > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x10 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x12 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x14 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x1a > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x1b > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x1c > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x1f > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x80 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x82 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x87 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x88 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x89 > v4l-convert: error decompressing JPEG: Pixart JPEG error: i
Re: image quality of Labtec Webcam 2200
Hi , i tested it with 2.6.31-rc9 & libvl 0.6.1 + svv and cannot reproduce. 301147.626826] gspca: probing 093a:2626 [301147.641578] gspca: probe ok [301147.641607] gspca: probing 093a:2626 [301147.641770] gspca: probing 093a:2626 [301147.641829] usbcore: registered new interface driver pac7311 [301147.641835] pac7311: registered Could you try testing with svv.c app? pd: quality is not the best, but works ok. Seem that the format is not the proper or expected "pjpeg" on your streaming. 2009/9/11 Németh Márton : > Márton Németh wrote: >> Hi, >> >> I have a Labtec Webcam 2200 and I have problems with the image quality >> with Linux 2.6.31 + libv4l 0.6.1. I made some experiments and stored >> each captured image as raw data and when libv4l was able to convert >> then I also stored the result as bmp. >> >> You can find my results at >> http://v4l-test.sourceforge.net/results/test-20090911/index.html >> There are three types of problems: >> a) Sometimes the picture contains a 8x8 pixel error, like in image #9 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 >> b) Sometimes the brightness of the half picture is changed, like in >> images #7, #36 and #37 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 >> c) Sometimes the libv4l cannot convert the raw image and the errno >> is set to EAGAIN (11), for example image #1, #2 and #3 >> >> Do you know how can I fix these problems? > > I investigated the c) point a little bit. When I get a negative return value > from the v4lconvert_convert() function then I print out the error message > what the > v4lconvert_get_error_message() function returns. With the result log file > I executed a "grep v4l-convert |sort |uniq" command. All the error messages > are > coming from the tinyjpeg.c (Small jpeg decoder library): > > v4l-convert: error decompressing JPEG: error: more then 63 AC components (65) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (66) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (67) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (68) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (69) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (70) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (71) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (72) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (73) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (75) > in huffman unit > v4l-convert: error decompressing JPEG: error: more then 63 AC components (76) > in huffman unit > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x00 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x01 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x02 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x04 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x08 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x09 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x0a > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x10 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x12 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x14 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x1a > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x1b > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x1c > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x1f > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x80 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x82 > v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: > 0x87 > v4l-convert: error decompressing
Re: Media controller: sysfs vs ioctl
On Sat, 2009-09-12 at 00:21 +0200, Hans Verkuil wrote: > Hi all, > > I've started this as a new thread to prevent polluting the discussions of the > media controller as a concept. > > First of all, I have no doubt that everything that you can do with an ioctl, > you can also do with sysfs and vice versa. That's not the problem here. > > The problem is deciding which approach is the best. I've wanted to reply earlier but I cannot collect enough time to do proper research, but since you asked this particular question, I happen to have something which may help. I would suggest evaluating a representative proposals by applying Baldwin and Clark's Net Options Value (NOV) metric to a simple system representation. The system to which to apply the metric would comprise: - a representative user space app - a representative v4l-dvb driver - an API concept/suggestion/proposal I think this metric is appropriate to apply, because the NOV is a way to assign value to implementing options (i.e. options in modular systems). An API itself is not a modular system and hard to evaluate in isolation, so it needs to be evaluated in the context of the options it provies to the system designers and maintainers. The NOV boils to simple concepts: 1. a system design has a total value that is its present value plus the value of it's options that can be exploited in the future. 2. an option represents a potential value that may provide a return in the future 3. an option has only a potential value (in the present) 4. an option only yields a return if that option may be exploited in the future. The probability that the option may be exploited needs to be taken into account. 5. an option has costs associated with exploiting it (in the future) I'm not advocating a rigorous computation of the metric for the proposals, but more a qualitative look at the proposals but still using the precise definition of the metric (sorry I don't have a URL handy...). I will note that I think am in agreement with Hans on sysfs. I think the cost of trying to exploit any option provided through sysfs in a userspace apppllication will nullify any technical benefit of said option to the application. Lets say we want to convert an existing app to a "Media Controller aware" version of that app. There is a cost to do that. Will the API proposal make exploting some options have a large cost? Do some of the options of the API have a low probability of being exploited? Do some of the options of the API provide very low technical benefit? What does the API proposal do to the total value of the system (e.g. an API with no flexibility fixes the total value close to the present value and there is no value to be realized from exploiting options in the future). OK, I hope I've communicated what I mean. I feel like that all may be less than clear. These ideas have come from a confluence of research I've been doing at work, and V4L-DVB work (thinking about Multiproto vs. DVB v5, and the v4l2_subdev IR ops, etc.). Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFCv2: Media controller proposal
On Friday 11 September 2009 23:28:47 Mauro Carvalho Chehab wrote: > Em Fri, 11 Sep 2009 22:29:41 +0200 > Hans Verkuil escreveu: > > > On Friday 11 September 2009 21:54:03 Mauro Carvalho Chehab wrote: > > > Em Fri, 11 Sep 2009 21:08:13 +0200 > > > Hans Verkuil escreveu: > > > > > > > > > > OK, so instead we require an application to construct a file containing > > > > a new > > > > topology, write something to a sysfs file, require code in the v4l core > > > > to load > > > > and parse that file, then find out which links have changed (since you > > > > really > > > > don't want to set all the links: there can be many, many links, believe > > > > me on > > > > that), and finally call the driver to tell it to change those links. > > > > > > As I said before, the design should take into account how frequent are > > > those > > > changes. If they are very infrequent, this approach works, and offers one > > > advantage: the topology will survive to application crashes and warm/cold > > > reboots. If the changes are frequent, an approach like the audio > > > user_pin_configs work better (see my previous email - note that this > > > approach > > > can be used for atomic operations if needed). You add at a sysfs node > > > just the > > > dynamic changes you need. We may even have both ways, as alsa seems to > > > have > > > (init_pin_configs and user_pin_configs). > > > > How frequent those changes are will depend entirely on the application. > > Never underestimate the creativity of the end-users :-) > > > > I think that a good worst case guideline would be 60 times per second. > > Say for a surveillance type application that switches between video decoders > > for each frame. > > The video input switch control, is already used by surveillance applications > for a long time. There's no need to add any API for it. > > > Or some 3D type application that switches between two sensors for each > > frame. > > Also, another case of video input selection. True, bad example. Given enough time I can no doubt come up with some example :-) > We shouldn't design any new device for it. > > I may be wrong, but from Vaibhav and your last comments, I'm starting to think > that you're wanting to replace V4L2 by a new "media controller" based new API. > > So, let's go one step back and better understand what's expected by the media > controller. > > From my previous understanding, those are the needs: > > 1) V4L2 API will keep being used to control the devices and to do streaming, > working under the already well defined devices; Yes. > 2) One Kernel object is needed to represent the entire board as a hole, to > enumerate its sub-devices and to change their topology; Yes. > 3) For some very specific cases, it should be possible to "tweak" some > sub-devices to act on a non-usual way; This will not be for 'some very specific cases'. This will become an essential feature on embedded platforms. It's probably the most important part of the media controller proposal. > 4) Some new ioctls are needed to control some parts of the devices that aren't > currently covered by V4L2 API. No, that is not part of the proposal. Of course, as drivers for the more advanced devices are submitted there may be some functionality that is general enough to warrant inclusion in the V4L2 API, but that's business as usual. > > Right? > > If so: > > (1) already exists; Obviously. > (2) is the "topology manager" of the media controller, that should use > sysfs, due to its nature. See the separate thread I started on sysfs vs ioctl. > For (3), there are a few alternatives. IMO, the better is to use also sysfs, > since we'll have all subdevs already represented there. So, to change > something, it is just a matter to write something to a sysfs node. See that same thread why that is a really bad idea. > Another > alternative would be to create separate subdevs at /dev, but this will end on > creating much more complex drivers than probably needed. I agree with this. > (4) is implemented by some new ioctl additions at V4L2 API. Not an issue as stated above. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/em28xx-vbi3
On Fri, 2009-09-11 at 17:04 -0400, Devin Heitmueller wrote: > On Fri, Sep 11, 2009 at 4:56 PM, Andy Walls wrote: > > + /* FIXME: hard-coded for NTSC support */ > > + format->fmt.vbi.sampling_rate = 675 * 4 / 2; /* FIXME: ??? */ > > > > The BT.656 Pixel clock for both 60 Hz and 50 Hz systems is 13.5 > > Mpixels/sec. Unless you switch to PAL or NTSC square pixel timing for > > some reason, I would expect this particular number to stay the same for > > both PAL and NTSC. > > > > A pixel in BT.656 consists of 1 Y sample and 1 U or V sample. So, in > > the VBI active line regions, I would have expected 2 * 13.5 Msamples/sec > > for VBI data. I don't know if any app in userland actually pays > > attention to this number though > > > > Regards, > > Andy > > Hey Andy, > > Well, when I said "hard-coded for NTSC support", I was referring to > the entire block of code that followed, not just the one on the > sampling rate. I expect the line count and start offsets to be > different for PAL as well. Ah, OK. Yes they are. > > In reality, the "???" was because I actually didn't know what the > proper value needs to be. I copied it from another driver without > fully understanding its role, and changing it caused userland to break > (zvbi-ntsc-cc in this case). > Worth noting that we are actually delivering 8-bit VBI info, as > opposed to 16-bit yuyv (there are some USB bandwidth issues I'm > actively working and doing 16-bit put me over the limit), so I'm not > confident that the generalization for ITU656 applies. OK. You can always work backwards to get the number: For example, if your hardware uses the BT.656 pixel clock of 13.5 Mpixels/sec and BT.656 pixel count of 720 pixels per active region of a horizontal line, then: 720 pixels/line active region / 13.5 Mpixels/sec = 53. usecs / line active region And so your VBI sample rate is: n VBI samples/line active region / 53. usecs/line active region with n being whatever the driver provides per VBI line. Ah and now I see you're only providing 720 samples per line. So yes, 13.5 Msamples/sec is the right number. Mea culpa. Regards, Andy > As I get the PAL support working, that area will certainly get some cleanup... > Cheers, > > Devin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFCv2: Media controller proposal
On Friday 11 September 2009 23:37:58 Mauro Carvalho Chehab wrote: > Em Fri, 11 Sep 2009 22:15:15 +0200 > Hans Verkuil escreveu: > > > On Friday 11 September 2009 21:59:37 Mauro Carvalho Chehab wrote: > > > Em Fri, 11 Sep 2009 21:23:44 +0200 > > > Hans Verkuil escreveu: > > > > > > > > In the case of resizer, I don't see why this can't be implemented as > > > > > an ioctl > > > > > over /dev/video device. > > > > > > > > Well, no. Not in general. There are two problems. The first problem > > > > occurs if > > > > you have multiple instances of a resizer (OK, not likely, but you *can* > > > > have > > > > multiple video encoders or decoders or sensors). If all you have is the > > > > streaming device node, then you cannot select to which resizer (or video > > > > encoder) the ioctl should go. The media controller allows you to select > > > > the > > > > recipient of the ioctl explicitly. Thus providing the control that these > > > > applications need. > > > > > > This case doesn't apply, since, if you have multiple encoders and/or > > > decoders, > > > you'll also have multiple /dev/video instances. All you need is to call > > > it at > > > the right device you need to control. Am I missing something here? > > > > Typical use-case: two video decoders feed video into a composer that > > combines > > the two (e.g. for PiP) and streams the result to one video node. > > > > Now you want to change e.g. the contrast on one of those video decoders. > > That's > > not going to be possible using /dev/video. > > On your above example, each video decoder will need a /dev/video, and also the > video composer. Why? The video decoders do not do any streaming. There may well be just one DMA engine that DMAs the output from the video composer. 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
Media controller: sysfs vs ioctl
Hi all, I've started this as a new thread to prevent polluting the discussions of the media controller as a concept. First of all, I have no doubt that everything that you can do with an ioctl, you can also do with sysfs and vice versa. That's not the problem here. The problem is deciding which approach is the best. What is sysfs? (taken from http://lwn.net/Articles/31185/) "Sysfs is a virtual filesystem which provides a userspace-visible representation of the device model. The device model and sysfs are sometimes confused with each other, but they are distinct entities. The device model functions just fine without sysfs (but the reverse is not true)." Currently both a v4l driver and the device nodes are all represented in sysfs. This is handled automatically by the kernel. Sub-devices are not represented in sysfs since they are not based on struct device. They are v4l-internal structures. Actually, if the subdev represents an i2c device, then that i2c device will be present in sysfs, but not all subdevs are i2c devices. Should we make all sub-devices based on struct device? Currently this is not required. Doing this would probably mean registering a virtual bus, then attaching the sub-device to that. Of course, this only applies to sub-devices that represent something that is not an i2c device (e.g. something internal to the media board like a resizer, or something connected to GPIO pins). If we decide to go with sysfs, then we have to do this. This part shouldn't be too difficult to implement. And also if we do not go with sysfs this might be interesting to do eventually. The media controller topology as I see it should contain the device nodes since the application has to know what device node to open to do the streaming. It should also contain the sub-devices so the application can control them. Is this enough? I think that eventually we also want to show the physical connectors. I left them out (mostly) from the initial media controller proposal, but I suspect that we want those as well eventually. But connectors are definitely not devices. In that respect the entity concept of the media controller is more abstract than sysfs. However, for now I think we can safely assume that sub-devices can be made visible in sysfs. The next point is how to access sub-devices. One approach is to create sub-device attributes that can be read and written. The other approach is to use a media controller device node and use ioctls. A third approach would be to create device nodes for each sub-device. This was the original idea I had when they were still called 'media processors'. I no longer think that is a good idea. The problem with that is that it will create even more device nodes (dozens in some cases) in addition to the many streaming device nodes that we already have. We have no choice in the case of streaming, but very few sub-devices (if any) will need to do read/write or streaming. Should this be needed, then it is always possible to create a device node just for that and link it as an output to the sub-device. In 99% of the cases we just need to be able to call ioctl on the sub-device. And we can do that through a media controller device just as well. What sort of interaction do we need with sub-devices? 1) Controls. Most sub-devices will have controls. Some of these controls are the same as are exposed through a v4l device node (brightness, contrast, etc), but others are more advanced controls. E.g. fine-grained gain controls. We have seen this lately in several driver submissions that there are a lot of controls that are hardware specific and that we do not want to expose to the average xawtv-type application. But advanced apps still want to be able to use them. Making such controls private to the sub-device is a good solution. What that means is that they do not appear when you do QUERYCTRL on the video device node, but you can set/get them when dealing directly to the sub-device. If we do this with an ioctl then we can just reuse the existing ioctls for dealing with controls. As you know I am working on a control framework that will move most of the implementation details to the core. It is easy to make this available as well to sub-devices. So calling QUERYCTRL through a media controller will also enumerate all the 'private' controls. In addition, with VIDIOC_S/G_EXT_CTRLS you can set and get multiple controls atomically. Such a control framework can also expose those controls as sysfs attributes. This works fine except for setting multiple controls atomically. E.g. for motor control you will definitely want this. You can do this I guess by implementing an 'all' attribute that will output all the control values when queried and you can write things like: motor_x=100 motor_y=200 to the 'all' attribute. Yuck. Oh, and I don't see how you can implement the information that v4l2_queryctrl and v4l2_querymenu can return in sysfs. Except by creating even more attributes. Note that I woul
Re: [PATCH 2/3] Add driver for OmniVision OV9640 sensor
On Fri, 4 Sep 2009, Marek Vasut wrote:
> Dne Po 24. srpna 2009 20:06:29 Guennadi Liakhovetski napsal(a):
> > Hi Marek
> >
> > On Sat, 22 Aug 2009, Marek Vasut wrote:
> > > From 479aafc9a6540efec8a691a84aff166eb0218a72 Mon Sep 17 00:00:00 2001
> > > From: Marek Vasut
> > > Date: Sat, 22 Aug 2009 05:14:23 +0200
> > > Subject: [PATCH 2/3] Add driver for OmniVision OV9640 sensor
> > >
> > > Signed-off-by: Marek Vasut
> >
> > Ok, I see, you rebased your patches on my soc-camera patch-stack, this is
> > good, thanks. But you missed a couple of my comments - you still have a
> > few static functions in the ov9640.c marked inline: ov9640_set_crop() is
> > not used at all, ov9640_set_bus_param() gets assigned to a struct member,
> > so, cannot be inline. ov9640_alter_regs() is indeed only called at one
> > location, but see Chapter 15 in Documentation/CodingStyle. You left at
> > least one multi-line comment wrongly formatted. You left some broken
> > printk format lines, etc. You moved your header under drivers/... - that's
> > good. But, please, address all my comments that I provided in a private
> > review, or explain why you do not agree. Otherwise I feel like I wasted my
> > time. Besides, your mailer has wrapped lines. Please, read
> > Documentation/email-clients.txt on how to configure your email client to
> > send patches properly. In the worst case, you can inline your patches
> > while reviewing, and then attach them for a final submission. This is,
> > however, discouraged, because it makes review and test of your
> > intermediate patches with wrapped lines more difficult. Also, please check
> > your patches with scripts/checkpatch.pl.
> >
>
> Fixed patch follows, my mailer is fixed as much as possible (working on
> getting
> git-email to work, but that's still to be done). Please consider applying,
> thanks.
Ok, a couple more simple questions / remarks, In principle, there's just
one principle objection - if we agree, that the correct format is BGR565
and RGB565X, then we should change that. There's no BGR565 format
currently in the kernel, so, we'd have to add it (and the documentation
for the mercurial tree).
Thanks
Guennadi
>
> Add driver for OmniVision OV9640 sensor
>
> Signed-off-by: Marek Vasut
> ---
> drivers/media/video/Kconfig |6 +
> drivers/media/video/Makefile|1 +
> drivers/media/video/ov9640.c| 811
> +++
> drivers/media/video/ov9640.h| 206 ++
> include/media/v4l2-chip-ident.h |1 +
> 5 files changed, 1025 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/ov9640.c
> create mode 100644 drivers/media/video/ov9640.h
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 84b6fc1..fddd654 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -772,6 +772,12 @@ config SOC_CAMERA_OV772X
> help
> This is a ov772x camera driver
>
> +config SOC_CAMERA_OV9640
> + tristate "ov9640 camera support"
> + depends on SOC_CAMERA && I2C
> + help
> + This is a ov9640 camera driver
> +
> config MX1_VIDEO
> bool
>
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index 9f2e321..e18efd5 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111)+= mt9m111.o
> obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o
> obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o
> obj-$(CONFIG_SOC_CAMERA_OV772X) += ov772x.o
> +obj-$(CONFIG_SOC_CAMERA_OV9640) += ov9640.o
> obj-$(CONFIG_SOC_CAMERA_TW9910) += tw9910.o
>
> # And now the v4l2 drivers:
> diff --git a/drivers/media/video/ov9640.c b/drivers/media/video/ov9640.c
> new file mode 100644
> index 000..289e82d
> --- /dev/null
> +++ b/drivers/media/video/ov9640.c
> @@ -0,0 +1,811 @@
> +/*
> + * OmniVision OV96xx Camera Driver
> + *
> + * Copyright (C) 2009 Marek Vasut
> + *
> + * Based on ov772x camera driver:
> + *
> + * Copyright (C) 2008 Renesas Solutions Corp.
> + * Kuninori Morimoto
> + *
> + * Based on ov7670 and soc_camera_platform driver,
> + *
> + * Copyright 2006-7 Jonathan Corbet
> + * Copyright (C) 2008 Magnus Damm
> + * Copyright (C) 2008, Guennadi Liakhovetski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ov9640.h"
> +
> +/* default register setup */
> +static const struct ov9640_reg ov9640_regs_dflt[] = {
> + { OV9640_COM5, OV9640_COM5_SYSCLK | OV9640_COM5_LONGEXP },
> + { OV9640_COM6, OV9640_COM6_OPT_BLC | OV9640_COM6_ADBLC_BIAS |
> + OV9640_COM6_FMT_RST | OV9640_COM6_A
Re: RFCv2: Media controller proposal
Em Fri, 11 Sep 2009 22:15:15 +0200 Hans Verkuil escreveu: > On Friday 11 September 2009 21:59:37 Mauro Carvalho Chehab wrote: > > Em Fri, 11 Sep 2009 21:23:44 +0200 > > Hans Verkuil escreveu: > > > > > > In the case of resizer, I don't see why this can't be implemented as an > > > > ioctl > > > > over /dev/video device. > > > > > > Well, no. Not in general. There are two problems. The first problem > > > occurs if > > > you have multiple instances of a resizer (OK, not likely, but you *can* > > > have > > > multiple video encoders or decoders or sensors). If all you have is the > > > streaming device node, then you cannot select to which resizer (or video > > > encoder) the ioctl should go. The media controller allows you to select > > > the > > > recipient of the ioctl explicitly. Thus providing the control that these > > > applications need. > > > > This case doesn't apply, since, if you have multiple encoders and/or > > decoders, > > you'll also have multiple /dev/video instances. All you need is to call it > > at > > the right device you need to control. Am I missing something here? > > Typical use-case: two video decoders feed video into a composer that combines > the two (e.g. for PiP) and streams the result to one video node. > > Now you want to change e.g. the contrast on one of those video decoders. > That's > not going to be possible using /dev/video. On your above example, each video decoder will need a /dev/video, and also the video composer. So, if you want to control the first decoder, you'll use /dev/video0. If you want to control the second, /dev/video1, and the mux, /dev/video2. The topology will be properly described at the media controller sysfs nodes. > > > > The second problem is that this will pollute the 'namespace' of a v4l > > > device > > > node. Device drivers need to pass all those private ioctls to the right > > > sub-device. But they shouldn't have to care about that. If someone wants > > > to > > > tweak the resizer (e.g. scaling coefficients), then pass it straight to > > > the > > > resizer component. > > > > Sorry, I missed your point here > > Example: a sub-device can produce certain statistics. You want to have an > ioctl to obtain those statistics. If you call that through /dev/videoX, then > that main driver has to handle that ioctl in vidioc_default and pass it on > to the right subdev. So you have to write that vidioc_default handler, > know about the sub-devices that you have and which sub-device is linked to > the device node. You really don't want to have to do that. Especially not > when you are dealing with i2c devices that are loaded from platform code. > If a video encoder supports private ioctls, then an omap3 driver doesn't > want to know about that. Oh, and before you ask: just broadcasting that > ioctl is not a solution if you have multiple identical video encoders. This can be as easy as reading from /sys/class/media/dsp:stat0/stats 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: RFCv2: Media controller proposal
Em Fri, 11 Sep 2009 22:29:41 +0200 Hans Verkuil escreveu: > On Friday 11 September 2009 21:54:03 Mauro Carvalho Chehab wrote: > > Em Fri, 11 Sep 2009 21:08:13 +0200 > > Hans Verkuil escreveu: > > > > > > OK, so instead we require an application to construct a file containing a > > > new > > > topology, write something to a sysfs file, require code in the v4l core > > > to load > > > and parse that file, then find out which links have changed (since you > > > really > > > don't want to set all the links: there can be many, many links, believe > > > me on > > > that), and finally call the driver to tell it to change those links. > > > > As I said before, the design should take into account how frequent are those > > changes. If they are very infrequent, this approach works, and offers one > > advantage: the topology will survive to application crashes and warm/cold > > reboots. If the changes are frequent, an approach like the audio > > user_pin_configs work better (see my previous email - note that this > > approach > > can be used for atomic operations if needed). You add at a sysfs node just > > the > > dynamic changes you need. We may even have both ways, as alsa seems to have > > (init_pin_configs and user_pin_configs). > > How frequent those changes are will depend entirely on the application. > Never underestimate the creativity of the end-users :-) > > I think that a good worst case guideline would be 60 times per second. > Say for a surveillance type application that switches between video decoders > for each frame. The video input switch control, is already used by surveillance applications for a long time. There's no need to add any API for it. > Or some 3D type application that switches between two sensors for each frame. Also, another case of video input selection. We shouldn't design any new device for it. I may be wrong, but from Vaibhav and your last comments, I'm starting to think that you're wanting to replace V4L2 by a new "media controller" based new API. So, let's go one step back and better understand what's expected by the media controller. >From my previous understanding, those are the needs: 1) V4L2 API will keep being used to control the devices and to do streaming, working under the already well defined devices; 2) One Kernel object is needed to represent the entire board as a hole, to enumerate its sub-devices and to change their topology; 3) For some very specific cases, it should be possible to "tweak" some sub-devices to act on a non-usual way; 4) Some new ioctls are needed to control some parts of the devices that aren't currently covered by V4L2 API. Right? If so: (1) already exists; (2) is the "topology manager" of the media controller, that should use sysfs, due to its nature. For (3), there are a few alternatives. IMO, the better is to use also sysfs, since we'll have all subdevs already represented there. So, to change something, it is just a matter to write something to a sysfs node. Another alternative would be to create separate subdevs at /dev, but this will end on creating much more complex drivers than probably needed. (4) is implemented by some new ioctl additions at V4L2 API. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/em28xx-vbi3
On Fri, Sep 11, 2009 at 4:56 PM, Andy Walls wrote: > + /* FIXME: hard-coded for NTSC support */ > + format->fmt.vbi.sampling_rate = 675 * 4 / 2; /* FIXME: ??? */ > > The BT.656 Pixel clock for both 60 Hz and 50 Hz systems is 13.5 > Mpixels/sec. Unless you switch to PAL or NTSC square pixel timing for > some reason, I would expect this particular number to stay the same for > both PAL and NTSC. > > A pixel in BT.656 consists of 1 Y sample and 1 U or V sample. So, in > the VBI active line regions, I would have expected 2 * 13.5 Msamples/sec > for VBI data. I don't know if any app in userland actually pays > attention to this number though > > Regards, > Andy Hey Andy, Well, when I said "hard-coded for NTSC support", I was referring to the entire block of code that followed, not just the one on the sampling rate. I expect the line count and start offsets to be different for PAL as well. In reality, the "???" was because I actually didn't know what the proper value needs to be. I copied it from another driver without fully understanding its role, and changing it caused userland to break (zvbi-ntsc-cc in this case). Worth noting that we are actually delivering 8-bit VBI info, as opposed to 16-bit yuyv (there are some USB bandwidth issues I'm actively working and doing 16-bit put me over the limit), so I'm not confident that the generalization for ITU656 applies. As I get the PAL support working, that area will certainly get some cleanup... Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/em28xx-vbi3
On Fri, 2009-09-11 at 00:00 -0400, Devin Heitmueller wrote: > Hello Mauro, > > Please PULL from http://kernellabs.com/hg/~dheitmueller/em28xx-vbi3 > for the following > > em28xx: better describe vinctrl registers > em28xx: make video isoc stream work when VBI is enabled > em28xx: add raw VBI support for NTSC + /* FIXME: hard-coded for NTSC support */ + format->fmt.vbi.sampling_rate = 675 * 4 / 2; /* FIXME: ??? */ The BT.656 Pixel clock for both 60 Hz and 50 Hz systems is 13.5 Mpixels/sec. Unless you switch to PAL or NTSC square pixel timing for some reason, I would expect this particular number to stay the same for both PAL and NTSC. A pixel in BT.656 consists of 1 Y sample and 1 U or V sample. So, in the VBI active line regions, I would have expected 2 * 13.5 Msamples/sec for VBI data. I don't know if any app in userland actually pays attention to this number though Regards, Andy > em28xx: fix mmap_mapper with vbi > em28xx: restructure fh/dev locking to handle both video and vbi > em28xx: remove unreferenced variable > em28xx: do not create /dev/vbiX device if VBI not supported > em28xx: only advertise VBI capability if supported > em28xx: implement g_std v4l call > em28xx: remove unneeded code that set VINCTRL register > em28xx: fix unused variable warning > > Note: the support currently only works for NTSC. I will be getting > PAL support working in the next couple of weeks as I get an > environment setup for testing. > > Special thanks go out to EyeMagnet Limited for sponsoring this work. > > Thanks, > > Devin > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFCv2: Media controller proposal
On Friday 11 September 2009 21:54:03 Mauro Carvalho Chehab wrote: > Em Fri, 11 Sep 2009 21:08:13 +0200 > Hans Verkuil escreveu: > > OK, so instead we require an application to construct a file containing a > > new > > topology, write something to a sysfs file, require code in the v4l core to > > load > > and parse that file, then find out which links have changed (since you > > really > > don't want to set all the links: there can be many, many links, believe me > > on > > that), and finally call the driver to tell it to change those links. > > As I said before, the design should take into account how frequent are those > changes. If they are very infrequent, this approach works, and offers one > advantage: the topology will survive to application crashes and warm/cold > reboots. If the changes are frequent, an approach like the audio > user_pin_configs work better (see my previous email - note that this approach > can be used for atomic operations if needed). You add at a sysfs node just the > dynamic changes you need. We may even have both ways, as alsa seems to have > (init_pin_configs and user_pin_configs). How frequent those changes are will depend entirely on the application. Never underestimate the creativity of the end-users :-) I think that a good worst case guideline would be 60 times per second. Say for a surveillance type application that switches between video decoders for each frame. Or some 3D type application that switches between two sensors for each frame. Of course, in the future you might want to get 3D done at 60 fps, meaning that you have to switch between sensors 120 times per second. One problem with media boards is that it is very hard to predict how they will be used and what they will be capable of in the future. Note that I am pretty sure that no application wants to have a media board boot into an unpredicable initial topology. That would make life very difficult for them. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFCv2: Media controller proposal
On Friday 11 September 2009 21:59:37 Mauro Carvalho Chehab wrote: > Em Fri, 11 Sep 2009 21:23:44 +0200 > Hans Verkuil escreveu: > > > > In the case of resizer, I don't see why this can't be implemented as an > > > ioctl > > > over /dev/video device. > > > > Well, no. Not in general. There are two problems. The first problem occurs > > if > > you have multiple instances of a resizer (OK, not likely, but you *can* have > > multiple video encoders or decoders or sensors). If all you have is the > > streaming device node, then you cannot select to which resizer (or video > > encoder) the ioctl should go. The media controller allows you to select the > > recipient of the ioctl explicitly. Thus providing the control that these > > applications need. > > This case doesn't apply, since, if you have multiple encoders and/or decoders, > you'll also have multiple /dev/video instances. All you need is to call it at > the right device you need to control. Am I missing something here? Typical use-case: two video decoders feed video into a composer that combines the two (e.g. for PiP) and streams the result to one video node. Now you want to change e.g. the contrast on one of those video decoders. That's not going to be possible using /dev/video. > > The second problem is that this will pollute the 'namespace' of a v4l device > > node. Device drivers need to pass all those private ioctls to the right > > sub-device. But they shouldn't have to care about that. If someone wants to > > tweak the resizer (e.g. scaling coefficients), then pass it straight to the > > resizer component. > > Sorry, I missed your point here Example: a sub-device can produce certain statistics. You want to have an ioctl to obtain those statistics. If you call that through /dev/videoX, then that main driver has to handle that ioctl in vidioc_default and pass it on to the right subdev. So you have to write that vidioc_default handler, know about the sub-devices that you have and which sub-device is linked to the device node. You really don't want to have to do that. Especially not when you are dealing with i2c devices that are loaded from platform code. If a video encoder supports private ioctls, then an omap3 driver doesn't want to know about that. Oh, and before you ask: just broadcasting that ioctl is not a solution if you have multiple identical video encoders. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFCv2: Media controller proposal
Em Fri, 11 Sep 2009 21:23:44 +0200 Hans Verkuil escreveu: > > In the case of resizer, I don't see why this can't be implemented as an > > ioctl > > over /dev/video device. > > Well, no. Not in general. There are two problems. The first problem occurs if > you have multiple instances of a resizer (OK, not likely, but you *can* have > multiple video encoders or decoders or sensors). If all you have is the > streaming device node, then you cannot select to which resizer (or video > encoder) the ioctl should go. The media controller allows you to select the > recipient of the ioctl explicitly. Thus providing the control that these > applications need. This case doesn't apply, since, if you have multiple encoders and/or decoders, you'll also have multiple /dev/video instances. All you need is to call it at the right device you need to control. Am I missing something here? > The second problem is that this will pollute the 'namespace' of a v4l device > node. Device drivers need to pass all those private ioctls to the right > sub-device. But they shouldn't have to care about that. If someone wants to > tweak the resizer (e.g. scaling coefficients), then pass it straight to the > resizer component. Sorry, I missed your point here 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: RFCv2: Media controller proposal
Em Fri, 11 Sep 2009 21:08:13 +0200 Hans Verkuil escreveu: > > > No, devices aren't created or deleted. Only links between devices. > > > > I think that there are some cases where devices are created/deleted. For > > example, on some hardware, you have some blocks that allow you to have > > either 4 SD > > video inputs or 1 HD video input. So, if you change the type of input, > > you'll > > end by creating or deleting devices. > > Normally you will create four device nodes, but if you switch to HD mode, > then only one is active and attempting to use the others will return EBUSY > or something. That's what the davinci driver does. > > Creating and deleting device nodes depending on the mode makes a driver very > complex and the application as well. Say you are in SD mode and you have nodes > video[0-3], now you switch to HD mode and you have only node video0. You go > back to SD mode and you may end up with nodes video0 and video[2-4] if in the > meantime the user connected a USB webcam which took up video1. > > Just create them upfront. You know beforehand what the maximum number of video > nodes is since that is determined by the hardware. Let's keep things simple. > Media boards are getting very, very complex and we should keep away from > adding > unnecessary further complications. Ok, we may start with this approach, and move to a more complex one only if needed. This should be properly documented to avoid miss-understandings. > > See above. If you're grouping 4 A/D blocks into one A/D for handling HD, > > you're > > doing more than just changing links, since the HD device will be just one > > device: one STD, one video input mux, one audio input mux, etc. > > So? You will just deactivate three SD device nodes. I don't see a problem with > that, and that concept has already been proven to work in the davinci driver. If just disabling applies to all cases, I agree stick with this idea. The issue with enabling/disabling devices is that some complex hardware may need to register a large amount of devices to expose all the different possibilities, but only a very few of them being possible to be enabled. Let's see as time goes by. To work like you said, this means that we'll need an enable attribute at the corresponding sysfs entry. It should be noticed that, even not deleting a hardware, udev can still be called. For example, an userspace application (like lirc) may need to be started/stopped if you enable/disable IR (or restarted on some topology changes, like using a different IR protocol). > > Even when streaming, providing that you don't touch at the used IC blocks, > > it > > should be possible to reconfigure the unused parts. It is just a matter of > > having the right resource locks at the driver. > > As you say, this will depend on the driver. Yes. > Some may be able to do this, > others may just return -EBUSY. I would do the latter, personally, since > allowing this would just make the driver more complicated for IMHO little > gain. Ok. Both approaches are valid. So the API should be able to support both ways, providing a thread safe interface to userspace. > > It would be easy to implement something like: > > > > echo 1 >/sys/class/media/mc0/config_reload > > > > to call request_firmware() and load the new topology. This is enough to > > have an > > atomic operation, and we don't need to implement a shadow config. > > OK, so instead we require an application to construct a file containing a new > topology, write something to a sysfs file, require code in the v4l core to > load > and parse that file, then find out which links have changed (since you really > don't want to set all the links: there can be many, many links, believe me on > that), and finally call the driver to tell it to change those links. As I said before, the design should take into account how frequent are those changes. If they are very infrequent, this approach works, and offers one advantage: the topology will survive to application crashes and warm/cold reboots. If the changes are frequent, an approach like the audio user_pin_configs work better (see my previous email - note that this approach can be used for atomic operations if needed). You add at a sysfs node just the dynamic changes you need. We may even have both ways, as alsa seems to have (init_pin_configs and user_pin_configs). 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: LinuxTV firmware blocks all wireless connections / traffic
On 09/11/2009 08:50 PM, Aleksandr V. Piskunov wrote: Ok, I did read basics of USB 2.0 protocol, gotta love these 600 page specs.. So using my fresh knowledge I went away and hacked ce6230 to use Isochronous transfer endpoint instead of Bulk one. And it helped, tuner works, no corruption with af9015 running on same controller at the same time. Looks like chipset driver issue as you said. Of course it isn't a fix per se, af9015 still corrupts if I start bulk reading from a flash drive, etc. And there are no Isochronous endpoints on af9015, so no alternative to bulk transfers :) y, correct. Welcome to hacking DVB drivers. But at least I'm getting closer to pinpointing the real problem and so far everything points to AMD SB700 chipset driver. Google says it has quite some hardware bugs and several workarounds in linux drivers... P.S. Rather unrelated question, what type of USB transfer is generally preferred for USB media stream devices, BULK or ISOC? Antti, why did you choose BULK for ce6230? Because chipset Windows driver was using BULK. Very many, I think even most, DVB chipset offers both ISOC and BULK. BULK is still used commonly, only few drivers are using ISOC. Devin answered already why BULK is used generally for DVB streams. :) I read also USB "bible" book yesterday and it says it is better to use biggest BULK urb supported. I want to change it biggest possible one, but there is other side that limits it - memory needed for buffers. That's why I am thinking twice whether to increase it 8k or 16k or even more. I currently think 16k will be good compromise for most configurations / devices. Antti -- http://palosaari.fi/ -- 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: RFCv2: Media controller proposal
On Friday 11 September 2009 20:52:17 Mauro Carvalho Chehab wrote: > Em Fri, 11 Sep 2009 23:04:13 +0530 > "Hiremath, Vaibhav" escreveu: > > > [Hiremath, Vaibhav] I was referring to standard V4L2 interface; I was > > referring to backward compatibility between Media controller devices itself. > > Huh? There's no media controller concept implemented yet. Hans proposal is to > add a new API to enumerate devices, not to replace what currently exists. > > > > Have you thought of custom parameter configuration? For example > > H3A(20)/Resizer(64) sub-device will have coeff. Which is non-standard (we > > had some discussion in the past) - > > > > I'm not saying that all new features should be implemented via sysfs. I'm just > saying that sysfs is the way Linux Kernel uses to describe device topology, > and, due to that, this is is the interface that applies at under the "media > controller" proposal. > > In the case of resizer, I don't see why this can't be implemented as an ioctl > over /dev/video device. Well, no. Not in general. There are two problems. The first problem occurs if you have multiple instances of a resizer (OK, not likely, but you *can* have multiple video encoders or decoders or sensors). If all you have is the streaming device node, then you cannot select to which resizer (or video encoder) the ioctl should go. The media controller allows you to select the recipient of the ioctl explicitly. Thus providing the control that these applications need. The second problem is that this will pollute the 'namespace' of a v4l device node. Device drivers need to pass all those private ioctls to the right sub-device. But they shouldn't have to care about that. If someone wants to tweak the resizer (e.g. scaling coefficients), then pass it straight to the resizer component. Regards, Hans > > > With SYSFS approach it is really difficult to pass big parameter to > > sub-device, which we can easily achieve using IOCTL. > > I didn't get you point here. With sysfs, you can pass everything, even a mix > of > strings and numbers, since get operation can be parsed via sscanf and > generated > set uses sprintf (this doesn't mean that this is the recommended way to use > it). > > For example, on kernel 2.6.31, we have the complete hda audio driver pinup by > reading to just one var: > > # cat /sys/class/sound/hwC0D0/init_pin_configs > 0x11 0x02214040 > 0x12 0x01014010 > 0x13 0x991301f0 > 0x14 0x02a19020 > 0x15 0x01813030 > 0x16 0x413301f0 > 0x17 0x41a601f0 > 0x18 0x41a601f0 > 0x1a 0x41f301f0 > 0x1b 0x414511f0 > 0x1c 0x41a190f0 > > If you want to alter PIN 0x15 output config, all you need to do is: > > # echo "0x15 0x02214040" >/sys/class/sound/hwC0D0/user_pin_configs > (or open /sys/class/sound/hwC0D0/init_pin_configs and write "0x15 0x02214040" > to it) > > And to reset to init config: > # echo 1 >/sys/class/sound/hwC0D0/clear > > One big advantage is that you can have a shell script to do the needed setup, > automatically called by some udev rule, without needing to write a single line > of code. So, for those advanced configuration parameters that doesn't change > (for example board xtal speeds), you don't need to code it on your > application. > Yet, you can do there, if needed. > > 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 > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFCv2: Media controller proposal
Mauro, I am going to move the ioctl vs sysfs discussion to a separate thread. I'll post an analysis of that later today or tomorrow. See below for my comments on some misunderstandings for non-sysfs issues. On Friday 11 September 2009 17:13:42 Mauro Carvalho Chehab wrote: > > > > All this requires that there has to be a way to connect and disconnect > > > > parts > > > > of the internal topology of a video board at will. > > > > > > We should design this with care, since each change at the internal > > > topology may > > > create/delete devices. > > > > No, devices aren't created or deleted. Only links between devices. > > I think that there are some cases where devices are created/deleted. For > example, on some hardware, you have some blocks that allow you to have either > 4 SD > video inputs or 1 HD video input. So, if you change the type of input, you'll > end by creating or deleting devices. Normally you will create four device nodes, but if you switch to HD mode, then only one is active and attempting to use the others will return EBUSY or something. That's what the davinci driver does. Creating and deleting device nodes depending on the mode makes a driver very complex and the application as well. Say you are in SD mode and you have nodes video[0-3], now you switch to HD mode and you have only node video0. You go back to SD mode and you may end up with nodes video0 and video[2-4] if in the meantime the user connected a USB webcam which took up video1. Just create them upfront. You know beforehand what the maximum number of video nodes is since that is determined by the hardware. Let's keep things simple. Media boards are getting very, very complex and we should keep away from adding unnecessary further complications. And yes, I too can generate hypothetical situations where this might be needed. But that's something we can tackle when it arrives. > > > > If you do such changes at topology, udev will need to > > > delete the old devices and create the new ones. > > > > udev is not involved at all. Exception: open issue #2 suggests that we > > dynamically register device nodes when they are first linked to some source > > or sink. That would involve udev. > > > > All devices are setup when the board is configured. But the links between > > them can be changed. This is nothing more than bringing the board's block > > diagram to life: each square of the diagram (video device node, resizer, > > video > > encoder or decoder) is a v4l2-subdev with inputs and outputs. And in some > > cases > > you can change links dynamically (in effect this will change a mutex > > register). > > See above. If you're grouping 4 A/D blocks into one A/D for handling HD, > you're > doing more than just changing links, since the HD device will be just one > device: one STD, one video input mux, one audio input mux, etc. So? You will just deactivate three SD device nodes. I don't see a problem with that, and that concept has already been proven to work in the davinci driver. > > > This will happen on separate > > > threads and may cause locking issues at the device, especially since you > > > can be > > > modifying several components at the same time (being even possible to do > > > it on > > > separate threads). > > > > This is definitely not something that should be allowed while streaming. I > > would like to hear from e.g. TI whether this could be a problem or not. I > > suspect that it isn't a problem unless streaming is in progress. > > Even when streaming, providing that you don't touch at the used IC blocks, it > should be possible to reconfigure the unused parts. It is just a matter of > having the right resource locks at the driver. As you say, this will depend on the driver. Some may be able to do this, others may just return -EBUSY. I would do the latter, personally, since allowing this would just make the driver more complicated for IMHO little gain. > > > I've seen some high-end core network routers that implements topology > > > changes > > > on an interesting way: any changes done are not immediately applied at the > > > node, but are stored into a file, where the configuration that can be > > > changed > > > anytime. However, the topology changes only happen after giving a commit > > > command. After commit, it validates the new config and apply them > > > atomically > > > (e. g. or all changes are applied or none), to avoid bad effects that > > > intermediate changes could cause. > > > > > > As we are at kernelspace, we need to take care to not create a very > > > complex > > > interface. Yet, the idea of applying the new topology atomically seems > > > interesting. > > > > I see no need for it. At least, not for any of the current or forthcoming > > devices that I am aware of. Should it ever be needed, then we can introduce > > a > > 'shadow topology' in the future. You can change the shadow links and when > > done > > commit it. That wouldn't be too difficult and
Re: RFCv2: Media controller proposal
Em Fri, 11 Sep 2009 23:04:13 +0530 "Hiremath, Vaibhav" escreveu: > [Hiremath, Vaibhav] I was referring to standard V4L2 interface; I was > referring to backward compatibility between Media controller devices itself. Huh? There's no media controller concept implemented yet. Hans proposal is to add a new API to enumerate devices, not to replace what currently exists. > > Have you thought of custom parameter configuration? For example > H3A(20)/Resizer(64) sub-device will have coeff. Which is non-standard (we had > some discussion in the past) - > I'm not saying that all new features should be implemented via sysfs. I'm just saying that sysfs is the way Linux Kernel uses to describe device topology, and, due to that, this is is the interface that applies at under the "media controller" proposal. In the case of resizer, I don't see why this can't be implemented as an ioctl over /dev/video device. > With SYSFS approach it is really difficult to pass big parameter to > sub-device, which we can easily achieve using IOCTL. I didn't get you point here. With sysfs, you can pass everything, even a mix of strings and numbers, since get operation can be parsed via sscanf and generated set uses sprintf (this doesn't mean that this is the recommended way to use it). For example, on kernel 2.6.31, we have the complete hda audio driver pinup by reading to just one var: # cat /sys/class/sound/hwC0D0/init_pin_configs 0x11 0x02214040 0x12 0x01014010 0x13 0x991301f0 0x14 0x02a19020 0x15 0x01813030 0x16 0x413301f0 0x17 0x41a601f0 0x18 0x41a601f0 0x1a 0x41f301f0 0x1b 0x414511f0 0x1c 0x41a190f0 If you want to alter PIN 0x15 output config, all you need to do is: # echo "0x15 0x02214040" >/sys/class/sound/hwC0D0/user_pin_configs (or open /sys/class/sound/hwC0D0/init_pin_configs and write "0x15 0x02214040" to it) And to reset to init config: # echo 1 >/sys/class/sound/hwC0D0/clear One big advantage is that you can have a shell script to do the needed setup, automatically called by some udev rule, without needing to write a single line of code. So, for those advanced configuration parameters that doesn't change (for example board xtal speeds), you don't need to code it on your application. Yet, you can do there, if needed. 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
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 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 Sep 11 19:00:02 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12711:13c47deee3b1 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: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.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: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: 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: WARNINGS linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: image quality of Labtec Webcam 2200
Márton Németh wrote: > Hi, > > I have a Labtec Webcam 2200 and I have problems with the image quality > with Linux 2.6.31 + libv4l 0.6.1. I made some experiments and stored > each captured image as raw data and when libv4l was able to convert > then I also stored the result as bmp. > > You can find my results at > http://v4l-test.sourceforge.net/results/test-20090911/index.html > There are three types of problems: > a) Sometimes the picture contains a 8x8 pixel error, like in image #9 > http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 > b) Sometimes the brightness of the half picture is changed, like in > images #7, #36 and #37 > http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 > http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 > http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 > c) Sometimes the libv4l cannot convert the raw image and the errno > is set to EAGAIN (11), for example image #1, #2 and #3 > > Do you know how can I fix these problems? I investigated the c) point a little bit. When I get a negative return value from the v4lconvert_convert() function then I print out the error message what the v4lconvert_get_error_message() function returns. With the result log file I executed a "grep v4l-convert |sort |uniq" command. All the error messages are coming from the tinyjpeg.c (Small jpeg decoder library): v4l-convert: error decompressing JPEG: error: more then 63 AC components (65) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (66) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (67) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (68) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (69) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (70) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (71) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (72) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (73) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (75) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (76) in huffman unit v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x00 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x01 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x02 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x04 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x08 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x09 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x0a v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x10 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x12 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x14 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1a v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1b v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1c v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1f v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x80 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x82 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x87 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x88 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x89 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8a v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8b v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8c v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8d v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8e v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8f v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x90 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x91 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x92 v4l-convert: error decompressing JPEG: Pixart JPEG error: inv
Re: LinuxTV firmware blocks all wireless connections / traffic
On Fri, Sep 11, 2009 at 1:50 PM, Aleksandr V. Piskunov wrote: > Ok, I did read basics of USB 2.0 protocol, gotta love these 600 page specs.. > So using my fresh knowledge I went away and hacked ce6230 to use Isochronous > transfer endpoint instead of Bulk one. And it helped, tuner works, no > corruption with af9015 running on same controller at the same time. > > Of course it isn't a fix per se, af9015 still corrupts if I start bulk > reading from a flash drive, etc. And there are no Isochronous endpoints on > af9015, so no alternative to bulk transfers :) > > But at least I'm getting closer to pinpointing the real problem and so far > everything points to AMD SB700 chipset driver. Google says it has quite > some hardware bugs and several workarounds in linux drivers... > > P.S. Rather unrelated question, what type of USB transfer is generally > preferred for USB media stream devices, BULK or ISOC? Antti, why did you > choose BULK for ce6230? The core difference between bulk and isoc is that with bulk you use get reliable delivery, but there is no reservation of bandwidth (bulk uses all available bandwidth). With isoc, you have reserved the bandwidth up front, but don't have reliable delivery (no retry mechanism, etc). With something like a hard drive, you want to use all available bandwidth, and you can do retries to ensure delivery, making bulk an appropriate choice. However, for streaming video, you usually want the bandwidth reserved up front, because if two devices are using the bus then frames will get dropped (and in a realtime streaming video device, there is no "retry" capability for dropped packets). 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: LinuxTV firmware blocks all wireless connections / traffic
On Fri, Sep 11, 2009 at 05:38:08PM +0300, Antti Palosaari wrote: > On 09/10/2009 10:39 PM, Aleksandr V. Piskunov wrote: >> On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote: >>> On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote: Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. Now powertop shows only about 220 wakeups on my computer for the both sticks. Please test and tell what powertop says: http://linuxtv.org/hg/~anttip/urb_size/ I wonder if we can decide what URB size DVB USB drivers should follow and even add new module param for overriding driver default. >>> >>> Thanks, Antti! >>> >>> Tested your branch on affected system. >>> >>> Load definitely went down, from ~7000 wakeups to ~250 for each tuner >>> according to powertop. >>> Both tuners still working ok if not used simultaneously or if used the >>> same time on different USB controllers. >>> >>> Bad news are that original problem still persists: putting both tuners >>> on same USB controller and zapping simultaneously corrupts stream. >>> Interesting observation: no matter in what sequence tuners are connected >>> (i.e. become adapter0 or adapter1), af9015 stream always gets heavily >>> distorted, visually mplayer picture becomes like 80% corrupted with >>> random color blocks and pixels, sound becomes a mess. At the same time >>> ce6230 gets slight corruption, a few discolored blocks at the time and >>> sound hickups. >>> >>> Anyway, will try to do a few more tests: >>> 1) Two usb flash drives on same controller calculating md5sum of >>> big .iso file, to check if it is/isn't dvb-usb problem. >>> 2) Will see if same issue persists on another PC with same motherboard >>> (slightly different revision) to rule out hardware issues. If I manage >>> to wire antenna there, that is... >> >> Ok, two USB flash drives on same controller, no problem when bulk reading >> from both at the same time, no speed drops, no corruption. >> >> Now if I plug ce6230 tuner, zap to channel and then start reading from >> flash drive: >> * slightly corrupted TS stream >> * flash drive read getting starved on bandwidth, speed drops from 10 MB/s >>to ~7 MB/s >> >> If I plug af9015 tuner, zap and read from flash >> * heavy corruption of TS stream >> * flash drive read speed drops from 10 MB/s to 2(!) MB/s >> >> Now I don't really know the USB protocol under-the-hood details, all the >> different types of bandwidth, reservation and so on. But shouldn't one >> 480 Mbit/sec controller handle rather large number of digital tuners, each >> pushing 20-25 Mbit/sec max, even considering all the overhead? > > I have no any problems here, ce6230 and af9015 with dual tuners (3x > DVB-T 22Mbit/sec TS streams) running same time on same bus. > > One possibility is that there is RF-noise looping from device to device > disturbing USB transfer or RF-signal. I have seen such situation when I > connect multiple DVB-C devices to same antenna cable using cheap > splitter. > > Anyhow, I increased URB sizes to 65k. Now ce6230 gives 70 wakeups and > af9015 120 wakeups - due to remote polling. You can test if you wish, > but results are most likely same as earlier. I cannot do much more. > http://linuxtv.org/hg/~anttip/urb_size/ Ok, I did read basics of USB 2.0 protocol, gotta love these 600 page specs.. So using my fresh knowledge I went away and hacked ce6230 to use Isochronous transfer endpoint instead of Bulk one. And it helped, tuner works, no corruption with af9015 running on same controller at the same time. Of course it isn't a fix per se, af9015 still corrupts if I start bulk reading from a flash drive, etc. And there are no Isochronous endpoints on af9015, so no alternative to bulk transfers :) But at least I'm getting closer to pinpointing the real problem and so far everything points to AMD SB700 chipset driver. Google says it has quite some hardware bugs and several workarounds in linux drivers... P.S. Rather unrelated question, what type of USB transfer is generally preferred for USB media stream devices, BULK or ISOC? Antti, why did you choose BULK for ce6230? -- 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: RFCv2: Media controller proposal
> -Original Message- > From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] > Sent: Friday, September 11, 2009 10:34 PM > To: Hiremath, Vaibhav > Cc: Devin Heitmueller; Hans Verkuil; linux-media@vger.kernel.org > Subject: Re: RFCv2: Media controller proposal > > Em Fri, 11 Sep 2009 21:23:50 +0530 > "Hiremath, Vaibhav" escreveu: > > > > -Original Message- > > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > > ow...@vger.kernel.org] On Behalf Of Devin Heitmueller > > > Sent: Friday, September 11, 2009 9:16 PM > > > To: Mauro Carvalho Chehab > > > Cc: Hans Verkuil; linux-media@vger.kernel.org > > > Subject: Re: RFCv2: Media controller proposal > > > > > > On Fri, Sep 11, 2009 at 11:13 AM, Mauro Carvalho Chehab > > > wrote: > > > > Em Thu, 10 Sep 2009 23:35:52 +0200 > > > > Hans Verkuil escreveu: > > > > > > > > > > > > > > I was talking not about specific attributes, but about the > V4L2 > > > API controls > > > > that you may eventually need to "hijack" (using that context- > > > sensitive > > > > thread-unsafe approach you described). > > > > > > > > Anyway, by using sysfs, you won't have any thread issues, > since > > > you'll be able > > > > to address each sub-device individually: > > > > > > > > echo 1 >/sys/class/media/mc0/video:dsp0/enable_stats > > > > > > > > > > > > > > > > Cheers, > > > > Mauro > > > > > > Mauro, > > > > > > Please, *seriously* reconsider the notion of making sysfs a > > > dependency > > > of V4L. While sysfs is great for a developer who wants to poke > > > around > > > at various properties from a command line during debugging, it > is an > > > absolute nightmare for any developer who wants to write an > > > application > > > in C that is expected to actually use the interface. The amount > of > > > extra code for all the string parsing alone would be ridiculous > > > (think > > > of how many calls you're going to have to make to sscanf or > atoi). > > > It's so much more straightforward to be able to have ioctl() > calls > > > that can return an actual struct with nice things like > enumeration > > > data types etc. > > The complexity of the interface will greatly depend on the way > things will be > mapped there, and the number of tree levels will be used. Also, as > sysfs > accepts soft links, we may have the same node pointed on different > places. > This can be useful to ek speed. > > In order to have something optimized for application, we can imagine > having, > for example, under /sys/class/media/mc0/subdevs, links to all the > several subdevs, > like: > > video:vin0 > video:vin1 > audio:audio0 > audio:audio1 > dsp:dsp0 > dsp:dsp0 > dvb:adapter0 > i2c:vin0:tvp5150 > ... > > each of them being a link to some specific sysfs node, all of this > created by > V4L2 core, to be sure that all devices will implement it at the > standard way. > > If some parameter should be bind, for example at the video input > device 0, you > just need to write to a node like: > /sys/class/media/mc0/subdevs/attr/ > > (all the above names are just examples - we'll need to properly > define the > sysfs tree we need to fulfill the requirements). > > Also, it should be noticed that you'll need to use sysfs anyway, to > get subdev's > major/minor numbers and to associate them with a file name under > /dev. > > > > > > > Just my opinion, of course. > > > > > [Hiremath, Vaibhav] Mauro, > > > > Definitely SYSFS interface is a nightmare for the application > developer, and again we have not thought of backward compatibility > here. > > What do you mean by backward compatibility? An application using the > standard > V4L2 API will keep working, but if they'll use the media controller > sysfs, they'll have > extra functionality. > [Hiremath, Vaibhav] I was referring to standard V4L2 interface; I was referring to backward compatibility between Media controller devices itself. Have you thought of custom parameter configuration? For example H3A(20)/Resizer(64) sub-device will have coeff. Which is non-standard (we had some discussion in the past) - With SYSFS approach it is really difficult to pass big parameter to sub-device, which we can easily achieve using IOCTL. Thanks, Vaibhav > I'm not saying that we should use what we currently have, but to use > sysfs to > create standard classes (and/or buses) that fulfill the needs for > media > controller to match the RFC requirements. > > > How application would know/decide on which node is exist and > stuff? Every video board will have his separate way of notions for > creating SYSFS nodes and maintaining standard between them would be > really mess. > > Yes, but none currently have a media controller node. As sysfs > provides links, > we can link the media controller to the old nodes or vice versa (for > the few > devices that already have their proper nodes). > > > There has to be enumeration kind of interface to make standard > applic
Re: RFCv2: Media controller proposal
Em Fri, 11 Sep 2009 21:23:50 +0530 "Hiremath, Vaibhav" escreveu: > > -Original Message- > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > ow...@vger.kernel.org] On Behalf Of Devin Heitmueller > > Sent: Friday, September 11, 2009 9:16 PM > > To: Mauro Carvalho Chehab > > Cc: Hans Verkuil; linux-media@vger.kernel.org > > Subject: Re: RFCv2: Media controller proposal > > > > On Fri, Sep 11, 2009 at 11:13 AM, Mauro Carvalho Chehab > > wrote: > > > Em Thu, 10 Sep 2009 23:35:52 +0200 > > > Hans Verkuil escreveu: > > > > > > > > > > I was talking not about specific attributes, but about the V4L2 > > API controls > > > that you may eventually need to "hijack" (using that context- > > sensitive > > > thread-unsafe approach you described). > > > > > > Anyway, by using sysfs, you won't have any thread issues, since > > you'll be able > > > to address each sub-device individually: > > > > > > echo 1 >/sys/class/media/mc0/video:dsp0/enable_stats > > > > > > > > > > > > Cheers, > > > Mauro > > > > Mauro, > > > > Please, *seriously* reconsider the notion of making sysfs a > > dependency > > of V4L. While sysfs is great for a developer who wants to poke > > around > > at various properties from a command line during debugging, it is an > > absolute nightmare for any developer who wants to write an > > application > > in C that is expected to actually use the interface. The amount of > > extra code for all the string parsing alone would be ridiculous > > (think > > of how many calls you're going to have to make to sscanf or atoi). > > It's so much more straightforward to be able to have ioctl() calls > > that can return an actual struct with nice things like enumeration > > data types etc. The complexity of the interface will greatly depend on the way things will be mapped there, and the number of tree levels will be used. Also, as sysfs accepts soft links, we may have the same node pointed on different places. This can be useful to ek speed. In order to have something optimized for application, we can imagine having, for example, under /sys/class/media/mc0/subdevs, links to all the several subdevs, like: video:vin0 video:vin1 audio:audio0 audio:audio1 dsp:dsp0 dsp:dsp0 dvb:adapter0 i2c:vin0:tvp5150 ... each of them being a link to some specific sysfs node, all of this created by V4L2 core, to be sure that all devices will implement it at the standard way. If some parameter should be bind, for example at the video input device 0, you just need to write to a node like: /sys/class/media/mc0/subdevs/attr/ (all the above names are just examples - we'll need to properly define the sysfs tree we need to fulfill the requirements). Also, it should be noticed that you'll need to use sysfs anyway, to get subdev's major/minor numbers and to associate them with a file name under /dev. > > > > Just my opinion, of course. > > > [Hiremath, Vaibhav] Mauro, > > Definitely SYSFS interface is a nightmare for the application developer, and > again we have not thought of backward compatibility here. What do you mean by backward compatibility? An application using the standard V4L2 API will keep working, but if they'll use the media controller sysfs, they'll have extra functionality. I'm not saying that we should use what we currently have, but to use sysfs to create standard classes (and/or buses) that fulfill the needs for media controller to match the RFC requirements. > How application would know/decide on which node is exist and stuff? Every > video board will have his separate way of notions for creating SYSFS nodes > and maintaining standard between them would be really mess. Yes, but none currently have a media controller node. As sysfs provides links, we can link the media controller to the old nodes or vice versa (for the few devices that already have their proper nodes). > There has to be enumeration kind of interface to make standard application > work seamlessly. That's for sure. 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: PCI/e with dual DVB-T + AV-in (HVR-2200?)
Jed's email isn't hitting the mailing list -- lets see if I can send it. On Fri, Sep 11, 2009 at 12:21 PM, Jed wrote: > Yeah I realised after seeing your 2nd email that Hauppauge only says > mpeg2 because that's all the Windows dvr does! :-D > > I also noticed on the website that it only talks about hw encode being > for the analog rf tuners, is there no hw encode for av-in?! > It seems to be other way round for most other cards > > Having the *option* to bypass hw encode whether it be on the analog > rf-in or av-in would be a very handy feature! > Because one could instead use CPU/GPGPU resources (if suited) and more > flexible software, or even dedicated encoder/transcoder addon devices. > Or in the case of video editing leave it raw for easier editing, and > then transocde it as required... Hi, I came across these two pdf's which seem to suggest that the references cards that the hvr-2200/2250 are based-on can do component in! Could it be that (like the limitation with hw encode in Windows to mpeg2) component in is also not advertised, simply because it's not supported in Windows? Assuming the cards are based-on the reference cards, then the hardware support seems to be there! Can someone please address my earlier points above too if you have an answer/opinion? Thanks heaps! Jed >> >> Hi Kernellabs or anyone involved with driver development of the HVR-2200, >> >> I know this is long wy down the priority list of features to be added, >> if ever! >> But I'm wanting to know if the *possibility* is there 'hardware-wise' for >> the following: >> >> 1) h.263/mpeg4/VC-1/DivX/Xvid hardware encode of A/V-in >> 2) Component input for the A/V-in >> 3) Hw encode bypass for A/V-in >> 4) Is Hw encode purely for A/V-in? (hauppauge's site seems to suggest >> otherwise but it may be a typo) >> 5) If not then questions 1) & 3) also apply to RF-in! >> >> I've attached the reference cards spec. sheets again for your perusal. >> I would be proactive in providing as much feed-back as needed for the dev. >> of such features. >> >> Most Sincerely, >> Jed > > For some inexplicable reason my last two posts have not appeared on the > ML, it seems I've been scrubbed! > Hence I'm forwarding straight to you to answer or forward to colleagues > to answer when possible. > > Regards, > Jed > P.S. > I have been posting in plain text > > -- 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: PCI/e with dual DVB-T + AV-in (HVR-2200?)
On 9/11/09 12:11 PM, Jed wrote: Yeah I realised after seeing your 2nd email that Hauppauge only says mpeg2 because that's all the Windows dvr does! :-D I also noticed on the website that it only talks about hw encode being for the analog rf tuners, is there no hw encode for av-in?! It seems to be other way round for most other cards Having the *option* to bypass hw encode whether it be on the analog rf-in or av-in would be a very handy feature! Because one could instead use CPU/GPGPU resources (if suited) and more flexible software, or even dedicated encoder/transcoder addon devices. Or in the case of video editing leave it raw for easier editing, and then transocde it as required... Hi, I came across these two pdf's which seem to suggest that the references cards that the hvr-2200/2250 are based-on can do component in! Could it be that (like the limitation with hw encode in Windows to mpeg2) component in is also not advertised, simply because it's not supported in Windows? Assuming the cards are based-on the reference cards, then the hardware support seems to be there! Can someone please address my earlier points above too if you have an answer/opinion? Thanks heaps! Jed Hi Kernellabs or anyone involved with driver development of the HVR-2200, I know this is long wy down the priority list of features to be added, if ever! But I'm wanting to know if the *possibility* is there 'hardware-wise' for the following: 1) h.263/mpeg4/VC-1/DivX/Xvid hardware encode of A/V-in 2) Component input for the A/V-in 3) Hw encode bypass for A/V-in 4) Is Hw encode purely for A/V-in? (hauppauge's site seems to suggest otherwise but it may be a typo) 5) If not then questions 1) & 3) also apply to RF-in! I've attached the reference cards spec. sheets again for your perusal. I would be proactive in providing as much feed-back as needed for the dev. of such features. Most Sincerely, Jed For some inexplicable reason my last two posts have not appeared on the ML, it seems I've been scrubbed! Hence I'm forwarding straight to you to answer or forward to colleagues to answer when possible. Oh, I saw your posting to the list. It's in my inbox, along with many other emails I'd like to respond to over the next few weeks. Nothing personal, I'm just too busy right now to deal with your ongoing daily list of questions. Please post all your questions to the ML and people will respond when they can, if they can. -- 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
[PATCH 3/8] drivers/media/video/hdpvr: introduce missing kfree
From: Julia Lawall
Error handling code following a kzalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x...@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
ret...@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
//
Signed-off-by: Julia Lawall
---
drivers/media/video/hdpvr/hdpvr-video.c|4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/hdpvr/hdpvr-video.c
b/drivers/media/video/hdpvr/hdpvr-video.c
index 2eb9dc2..0d17ce5 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -132,7 +132,7 @@ int hdpvr_alloc_buffers(struct hdpvr_device *dev, uint
count)
buf = kzalloc(sizeof(struct hdpvr_buffer), GFP_KERNEL);
if (!buf) {
v4l2_err(&dev->v4l2_dev, "cannot allocate buffer\n");
- goto exit;
+ goto exit_nobuf;
}
buf->dev = dev;
@@ -162,6 +162,8 @@ int hdpvr_alloc_buffers(struct hdpvr_device *dev, uint
count)
}
return 0;
exit:
+ kfree(buf);
+exit_nobuf:
hdpvr_free_buffers(dev);
return retval;
}
--
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 2/8] drivers/media/video/uvc: introduce missing kfree
From: Julia Lawall
Error handling code following kmalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x...@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
ret...@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
//
Signed-off-by: Julia Lawall
---
drivers/media/video/uvc/uvc_video.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index 5b757f3..ce2c484 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -128,8 +128,11 @@ static int uvc_get_video_ctrl(struct uvc_streaming *stream,
if (data == NULL)
return -ENOMEM;
- if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) && query == UVC_GET_DEF)
- return -EIO;
+ if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
+ query == UVC_GET_DEF) {
+ ret = -EIO;
+ goto out;
+ }
ret = __uvc_query_ctrl(stream->dev, query, 0, stream->intfnum,
probe ? UVC_VS_PROBE_CONTROL : UVC_VS_COMMIT_CONTROL, data,
--
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: RFCv2: Media controller proposal
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Devin Heitmueller > Sent: Friday, September 11, 2009 9:16 PM > To: Mauro Carvalho Chehab > Cc: Hans Verkuil; linux-media@vger.kernel.org > Subject: Re: RFCv2: Media controller proposal > > On Fri, Sep 11, 2009 at 11:13 AM, Mauro Carvalho Chehab > wrote: > > Em Thu, 10 Sep 2009 23:35:52 +0200 > > Hans Verkuil escreveu: > > > > > > I was talking not about specific attributes, but about the V4L2 > API controls > > that you may eventually need to "hijack" (using that context- > sensitive > > thread-unsafe approach you described). > > > > Anyway, by using sysfs, you won't have any thread issues, since > you'll be able > > to address each sub-device individually: > > > > echo 1 >/sys/class/media/mc0/video:dsp0/enable_stats > > > > > > > > Cheers, > > Mauro > > Mauro, > > Please, *seriously* reconsider the notion of making sysfs a > dependency > of V4L. While sysfs is great for a developer who wants to poke > around > at various properties from a command line during debugging, it is an > absolute nightmare for any developer who wants to write an > application > in C that is expected to actually use the interface. The amount of > extra code for all the string parsing alone would be ridiculous > (think > of how many calls you're going to have to make to sscanf or atoi). > It's so much more straightforward to be able to have ioctl() calls > that can return an actual struct with nice things like enumeration > data types etc. > > Just my opinion, of course. > [Hiremath, Vaibhav] Mauro, Definitely SYSFS interface is a nightmare for the application developer, and again we have not thought of backward compatibility here. How application would know/decide on which node is exist and stuff? Every video board will have his separate way of notions for creating SYSFS nodes and maintaining standard between them would be really mess. There has to be enumeration kind of interface to make standard application work seamlessly. Thanks, Vaibhav > 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 -- 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: RFCv2: Media controller proposal
On Fri, Sep 11, 2009 at 11:13 AM, Mauro Carvalho Chehab
wrote:
> Em Thu, 10 Sep 2009 23:35:52 +0200
> Hans Verkuil escreveu:
>
>> > First of all, a generic comment: you enumerated on your RFC several needs
>> > that
>> > you expect to be solved with a media controller, but you didn't mention
>> > what
>> > userspace API will be used to solve it (e. g. what ioctls, sysfs
>> > interfaces,
>> > etc). As this is missing, I'm adding a few notes about how this can be
>> > implemented. For example, as I've already pointed when you sent the first
>> > proposal and at LPC, sysfs is the proper kernel API for enumerating things.
>>
>> I hate sysfs with a passion. All of the V4L2 API is designed around ioctls,
>> and so is the media controller.
>>
>> Note that I did not go into too much implementation detail in this RFC. The
>> best way to do that is by trying to implement it. Only after implementing it
>> for a few drivers will you get a real feel of what works and what doesn't.
>>
>> Of course, whether to use sysfs or ioctls is something that has to be
>> designed
>> beforehand.
>
>> > > 1) Discovering the various device nodes that are typically created by a
>> > > video
>> > > board, such as: video nodes, vbi nodes, dvb nodes, alsa nodes,
>> > > framebuffer
>> > > nodes, input nodes (for e.g. webcam button events or IR remotes).
>> >
>> > In fact, this can already be done by using the sysfs interface. the current
>> > version of v4l2-sysfs-path.c already enumerates the associated nodes to
>> > a /dev/video device, by just navigating at the already existing device
>> > description nodes at sysfs. I hadn't tried yet, but I bet that a similar
>> > kind
>> > of topology can be obtained from a dvb device (probably, we need to do some
>> > adjustments).
>>
>> sysfs is crap. It's a poorly documented public API that is hell to use. Take
>> a device node entity as enumerated by the media controller: I want to provide
>> the application with information like the sort of node (alsa, fb, v4l, etc),
>> how to access it (alsa card nr or major/minor), a description ("Captured MPEG
>> stream"), possibly some capabilities and addition data. With an ENUM ioctl
>> you can just call it. With sysfs you have to open/read/close files for each
>> of
>> these properties, walk through the tree to find related alsa/v4l/fb devices,
>
> sysfs is an hierarchical description of the kernel objects, used to describe
> devices, buses, sub-devices, etc. navigating on it, reading, etc is very fast,
> since it is done in ram, as described in:
>
> http://lwn.net/Articles/31185/
>
> Unfortunately, it were designed after V4L2 API, otherwise, probably several
> things at the API would be different.
>
> Of course, we need to properly document the media controller sysfs nodes at
> V4L2.
>
>> and in drivers you must write a hell of a lot of code just to make those
>> sysfs
>> nodes. It's an uncontrollable mess.
>
> Huh? How much sysfs code is currently present at the drivers? Nothing. Yet,
> you
> can already enumerate several things as shown with v4l2-sysfs-path, since
> V4L2 core
> already has the code for implementing it. Of course if you want to have a
> customized set of nodes for changing some attributes, you'll need to say to
> sysfs the name of the attribute, and have a get/set pair of methods. Nothing
> different from what we currently have. In a matter of fact, it is even
> simpler,
> since you don't need to add an enum method.
>
> So, it is the proper Kernel API for the objectives you described. Doing it via
> ioctl will duplicate things, since the sysfs stuff will still be there, and
> will use a wrong API.
>
> So, we should use sysfs for media controller.
>
>> > The big missing component is an userspace library that will properly
>> > return the
>> > device components to the applications. Maybe we need to do also some
>> > adjustments at the sysfs nodes to represent all that it is needed.
>>
>> So we write a userspace library that collects all that information? So that
>> has to:
>>
>> 1) walk through the sysfs tree trying to find all the related parts of the
>> media board.
>> 2) open the property that we are interested in.
>> 3) attempt to read the property's value.
>> 4) the driver will then copy that value into a buffer that is returned to the
>> application, usually through a sprintf() call.
>> 5) the library than uses atol() to convert the string back to an integer and
>> stores the result in a struct.
>> 6) repeat for all properties.
>>
>> Isn't that the same as calling an enum ioctl() with a struct pointer? Except
>> a zillion times slower and more obfuscated?
>
> You'll need a similar process with enum, to get each value. Also, by using
> sysfs, it is easy to write udev rules that, once a new sysfs node is created,
> some action will be started, like for example the action of setting the board
> into the needed configuration.
>
>> > The better would be to create a /sys/class/media node, and having the
>> > media c
Re: RFCv2: Media controller proposal
Em Thu, 10 Sep 2009 23:35:52 +0200
Hans Verkuil escreveu:
> > First of all, a generic comment: you enumerated on your RFC several needs
> > that
> > you expect to be solved with a media controller, but you didn't mention what
> > userspace API will be used to solve it (e. g. what ioctls, sysfs interfaces,
> > etc). As this is missing, I'm adding a few notes about how this can be
> > implemented. For example, as I've already pointed when you sent the first
> > proposal and at LPC, sysfs is the proper kernel API for enumerating things.
>
> I hate sysfs with a passion. All of the V4L2 API is designed around ioctls,
> and so is the media controller.
>
> Note that I did not go into too much implementation detail in this RFC. The
> best way to do that is by trying to implement it. Only after implementing it
> for a few drivers will you get a real feel of what works and what doesn't.
>
> Of course, whether to use sysfs or ioctls is something that has to be designed
> beforehand.
> > > 1) Discovering the various device nodes that are typically created by a
> > > video
> > > board, such as: video nodes, vbi nodes, dvb nodes, alsa nodes, framebuffer
> > > nodes, input nodes (for e.g. webcam button events or IR remotes).
> >
> > In fact, this can already be done by using the sysfs interface. the current
> > version of v4l2-sysfs-path.c already enumerates the associated nodes to
> > a /dev/video device, by just navigating at the already existing device
> > description nodes at sysfs. I hadn't tried yet, but I bet that a similar
> > kind
> > of topology can be obtained from a dvb device (probably, we need to do some
> > adjustments).
>
> sysfs is crap. It's a poorly documented public API that is hell to use. Take
> a device node entity as enumerated by the media controller: I want to provide
> the application with information like the sort of node (alsa, fb, v4l, etc),
> how to access it (alsa card nr or major/minor), a description ("Captured MPEG
> stream"), possibly some capabilities and addition data. With an ENUM ioctl
> you can just call it. With sysfs you have to open/read/close files for each of
> these properties, walk through the tree to find related alsa/v4l/fb devices,
sysfs is an hierarchical description of the kernel objects, used to describe
devices, buses, sub-devices, etc. navigating on it, reading, etc is very fast,
since it is done in ram, as described in:
http://lwn.net/Articles/31185/
Unfortunately, it were designed after V4L2 API, otherwise, probably several
things at the API would be different.
Of course, we need to properly document the media controller sysfs nodes at
V4L2.
> and in drivers you must write a hell of a lot of code just to make those sysfs
> nodes. It's an uncontrollable mess.
Huh? How much sysfs code is currently present at the drivers? Nothing. Yet, you
can already enumerate several things as shown with v4l2-sysfs-path, since V4L2
core
already has the code for implementing it. Of course if you want to have a
customized set of nodes for changing some attributes, you'll need to say to
sysfs the name of the attribute, and have a get/set pair of methods. Nothing
different from what we currently have. In a matter of fact, it is even simpler,
since you don't need to add an enum method.
So, it is the proper Kernel API for the objectives you described. Doing it via
ioctl will duplicate things, since the sysfs stuff will still be there, and
will use a wrong API.
So, we should use sysfs for media controller.
> > The big missing component is an userspace library that will properly return
> > the
> > device components to the applications. Maybe we need to do also some
> > adjustments at the sysfs nodes to represent all that it is needed.
>
> So we write a userspace library that collects all that information? So that
> has to:
>
> 1) walk through the sysfs tree trying to find all the related parts of the
> media board.
> 2) open the property that we are interested in.
> 3) attempt to read the property's value.
> 4) the driver will then copy that value into a buffer that is returned to the
> application, usually through a sprintf() call.
> 5) the library than uses atol() to convert the string back to an integer and
> stores the result in a struct.
> 6) repeat for all properties.
>
> Isn't that the same as calling an enum ioctl() with a struct pointer? Except
> a zillion times slower and more obfuscated?
You'll need a similar process with enum, to get each value. Also, by using
sysfs, it is easy to write udev rules that, once a new sysfs node is created,
some action will be started, like for example the action of setting the board
into the needed configuration.
> > The better would be to create a /sys/class/media node, and having the
> > media controllers above that struct. So, mc0 will be at
> > /sys/class/media/mc0.
>
> Why? It's a device. Devices belong in /dev. That's where applications and
> users
> look for devices. Not in sysfs.
A device is somethin
Re: LinuxTV firmware blocks all wireless connections / traffic
On 09/10/2009 10:39 PM, Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote: Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. Now powertop shows only about 220 wakeups on my computer for the both sticks. Please test and tell what powertop says: http://linuxtv.org/hg/~anttip/urb_size/ I wonder if we can decide what URB size DVB USB drivers should follow and even add new module param for overriding driver default. Thanks, Antti! Tested your branch on affected system. Load definitely went down, from ~7000 wakeups to ~250 for each tuner according to powertop. Both tuners still working ok if not used simultaneously or if used the same time on different USB controllers. Bad news are that original problem still persists: putting both tuners on same USB controller and zapping simultaneously corrupts stream. Interesting observation: no matter in what sequence tuners are connected (i.e. become adapter0 or adapter1), af9015 stream always gets heavily distorted, visually mplayer picture becomes like 80% corrupted with random color blocks and pixels, sound becomes a mess. At the same time ce6230 gets slight corruption, a few discolored blocks at the time and sound hickups. Anyway, will try to do a few more tests: 1) Two usb flash drives on same controller calculating md5sum of big .iso file, to check if it is/isn't dvb-usb problem. 2) Will see if same issue persists on another PC with same motherboard (slightly different revision) to rule out hardware issues. If I manage to wire antenna there, that is... Ok, two USB flash drives on same controller, no problem when bulk reading from both at the same time, no speed drops, no corruption. Now if I plug ce6230 tuner, zap to channel and then start reading from flash drive: * slightly corrupted TS stream * flash drive read getting starved on bandwidth, speed drops from 10 MB/s to ~7 MB/s If I plug af9015 tuner, zap and read from flash * heavy corruption of TS stream * flash drive read speed drops from 10 MB/s to 2(!) MB/s Now I don't really know the USB protocol under-the-hood details, all the different types of bandwidth, reservation and so on. But shouldn't one 480 Mbit/sec controller handle rather large number of digital tuners, each pushing 20-25 Mbit/sec max, even considering all the overhead? I have no any problems here, ce6230 and af9015 with dual tuners (3x DVB-T 22Mbit/sec TS streams) running same time on same bus. One possibility is that there is RF-noise looping from device to device disturbing USB transfer or RF-signal. I have seen such situation when I connect multiple DVB-C devices to same antenna cable using cheap splitter. Anyhow, I increased URB sizes to 65k. Now ce6230 gives 70 wakeups and af9015 120 wakeups - due to remote polling. You can test if you wish, but results are most likely same as earlier. I cannot do much more. http://linuxtv.org/hg/~anttip/urb_size/ Antti -- http://palosaari.fi/ -- 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
Fwd: Re: [PATCH] fix lock imbalances in /drivers/media/video/cafe_ccic.c
On Thu, Sep 10, 2009 at 09:30:03AM -0600, Jonathan Corbet wrote: > On Thu, 10 Sep 2009 18:37:34 + > iceberg wrote: > > > In ./drivers/media/video/cafe_ccic.c, in function cafe_pci_probe: > > Mutex must be unlocked before exit > > 1. On paths starting with mutex lock in line 1912, then continuing in lines: > > 1929, 1936 (goto unreg) and 1940 (goto iounmap) . > > 2. On path starting in line 1971 mutex lock, and then continuing in line 1978 > > (goto out_smbus) mutex. > > That's a definite bug, but I hate all those unlocks in the error > branches. As it happens, we don't really need the mutex until the > device has been exposed to the rest of the kernel, so I propose the > following as a better patch. > > Thanks for pointing this out, If we can first pair of mutex_lock and mutex_unlock: Fix lock imbalances in function device_authorization. Signed-off-by: Alexander Strakh --- diff --git a/./drivers/media/video/cafe_ccic.c b/../b/drivers/media/video/cafe_ccic.c index c4d181d..4c6bc86 100644 --- a/./drivers/media/video/cafe_ccic.c +++ b/../b/drivers/media/video/cafe_ccic.c @@ -1909,7 +1909,6 @@ static int cafe_pci_probe(struct pci_dev *pdev, goto out_free; mutex_init(&cam->s_mutex); - mutex_lock(&cam->s_mutex); spin_lock_init(&cam->dev_lock); cam->state = S_NOTREADY; cafe_set_config_needed(cam, 1); @@ -1949,7 +1948,6 @@ static int cafe_pci_probe(struct pci_dev *pdev, * because the sensor could attach in this call chain, leading to * unsightly deadlocks. */ - mutex_unlock(&cam->s_mutex); /* attach can deadlock */ ret = cafe_smbus_setup(cam); if (ret) goto out_freeirq; @@ -1975,7 +1973,7 @@ static int cafe_pci_probe(struct pci_dev *pdev, cam->vdev.v4l2_dev = &cam->v4l2_dev; ret = video_register_device(&cam->vdev, VFL_TYPE_GRABBER, -1); if (ret) - goto out_smbus; + goto out_unlock; video_set_drvdata(&cam->vdev, cam); /* @@ -1990,6 +1988,8 @@ static int cafe_pci_probe(struct pci_dev *pdev, mutex_unlock(&cam->s_mutex); return 0; +out_unlock: + mutex_unlock(&cam->s_mutex); out_smbus: cafe_smbus_shutdown(cam); out_freeirq: -- 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: Hyperlinks in linuxtv.org mercurial RSS feeds broken
On Fri, Sep 11, 2009 at 02:59:22PM +0200, Matthias Schwarzott wrote: > > After having reported this some weeks ago, the hyperlinks in the linuxtv.org > mercurial RSS feeds are still broken. > > In this feed: http://linuxtv.org/hg/v4l-dvb?cmd=changelog;style=rss > a link looks like this: > http://linuxtv.orghttp//linuxtv.org/hg/v4l-dvb/rev/13c47deee3b1 I'm sorry, I forgot to come back to you on this. I reported this bug upstream and I'm still waiting for a fix. http://mercurial.selenic.com/bts/issue1772 Johannes -- 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] fix lock imbalances in /drivers/media/video/cafe_ccic.c
On Thursday 10 September 2009 15:30:03 you wrote:
Incorrect patch. See path starting with "if (cam->sensor == null) {" in
line
1960. In this case we goto out_smbs and try mutex_unlock on unlocking mutex.
> On Thu, 10 Sep 2009 18:37:34 +
>
> iceberg wrote:
> > In ./drivers/media/video/cafe_ccic.c, in function cafe_pci_probe:
> > Mutex must be unlocked before exit
> > 1. On paths starting with mutex lock in line 1912, then continuing in
> > lines: 1929, 1936 (goto unreg) and 1940 (goto iounmap) .
> > 2. On path starting in line 1971 mutex lock, and then continuing in line
> > 1978 (goto out_smbus) mutex.
>
> That's a definite bug, but I hate all those unlocks in the error
> branches. As it happens, we don't really need the mutex until the
> device has been exposed to the rest of the kernel, so I propose the
> following as a better patch.
>
> Thanks for pointing this out,
>
> jon
>
> ---
> Fix a mutex leak
>
> Certain error exits from cafe_pci_probe() can leave the camera mutex
> locked. For much of the time, we didn't need the mutex anyway; take it out
> and add an unlock in the path where it is needed.
>
> Reported-by: Alexander Strakh
> Signed-off-by: Jonathan Corbet
> ---
> drivers/media/video/cafe_ccic.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/video/cafe_ccic.c
> b/drivers/media/video/cafe_ccic.c index c4d181d..0f62b5e 100644
> --- a/drivers/media/video/cafe_ccic.c
> +++ b/drivers/media/video/cafe_ccic.c
> @@ -1909,7 +1909,6 @@ static int cafe_pci_probe(struct pci_dev *pdev,
> goto out_free;
>
> mutex_init(&cam->s_mutex);
> - mutex_lock(&cam->s_mutex);
> spin_lock_init(&cam->dev_lock);
> cam->state = S_NOTREADY;
> cafe_set_config_needed(cam, 1);
> @@ -1949,7 +1948,6 @@ static int cafe_pci_probe(struct pci_dev *pdev,
>* because the sensor could attach in this call chain, leading to
>* unsightly deadlocks.
>*/
> - mutex_unlock(&cam->s_mutex); /* attach can deadlock */
> ret = cafe_smbus_setup(cam);
> if (ret)
> goto out_freeirq;
> @@ -1991,6 +1989,7 @@ static int cafe_pci_probe(struct pci_dev *pdev,
> return 0;
>
> out_smbus:
> + mutex_unlock(&cam->s_mutex);
> cafe_smbus_shutdown(cam);
> out_freeirq:
> cafe_ctlr_power_down(cam);
--
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: RFCv2: Media controller proposal
Em Thu, 10 Sep 2009 16:27:20 -0400 Devin Heitmueller escreveu: > On Thu, Sep 10, 2009 at 4:20 PM, Mauro Carvalho > Chehab wrote: > > In fact, this can already be done by using the sysfs interface. the current > > version of v4l2-sysfs-path.c already enumerates the associated nodes to > > a /dev/video device, by just navigating at the already existing device > > description nodes at sysfs. I hadn't tried yet, but I bet that a similar > > kind > > of topology can be obtained from a dvb device (probably, we need to do some > > adjustments). > > For the audio case, I did some digging into this a bit and It's worth > noting that this behavior varies by driver (at least on USB). In some > cases, the parent points to the USB device, in other cases it points > to the USB interface. My original thought was to pick one or the > other and make the various drivers consistent, but even that is a > challenge since in some cases the audio device was provided by > snd-usb-audio (which has no knowledge of the v4l subsystem). We may consider adding a quick at snd-usb-audio for em28xx devices, in order to create the proper sysfs nodes. 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
Hyperlinks in linuxtv.org mercurial RSS feeds broken
Hi there! After having reported this some weeks ago, the hyperlinks in the linuxtv.org mercurial RSS feeds are still broken. In this feed: http://linuxtv.org/hg/v4l-dvb?cmd=changelog;style=rss a link looks like this: http://linuxtv.orghttp//linuxtv.org/hg/v4l-dvb/rev/13c47deee3b1 Regards Matthias -- 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 1/1] FM TX: si4713: Kconfig: Fixed two typos.
On Fri, Sep 11, 2009 at 09:38:04AM +0200, Aaltonen Matti.J (Nokia-D/Tampere) wrote: > Fixed two typos. > > Signed-off-by: Matti J. Aaltonen Acked-by: Eduardo Valentin > > diff -r 5582a6427a41 -r ff80edccfe24 linux/drivers/media/radio/Kconfig > --- a/linux/drivers/media/radio/Kconfig Tue Sep 01 22:16:23 2009 +0200 > +++ b/linux/drivers/media/radio/Kconfig Fri Sep 11 10:25:13 2009 +0300 > @@ -346,7 +346,7 @@ > ---help--- > Say Y here if you want support to Si4713 FM Radio Transmitter. > This device can transmit audio through FM. It can transmit > - EDS and EBDS signals as well. This module is the v4l2 radio > + RDS and RBDS signals as well. This module is the v4l2 radio > interface for the i2c driver of this device. > > To compile this driver as a module, choose M here: the > -- Eduardo Valentin -- 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
Kernel OOPS in "dvb_demux_release"
Hi, yesterday i tried to set up my linux DBV TV (following the description on http://www.linuxtv.org/wiki/) and got a kernal OOPS. My hardware: WinTV NOVA-T (USB Stick) rev.D1F4 I have running an Ubuntu 4.08 (kernel 2.6.24-24). Current v4l build from http://linuxtv.org/hg/v4l-dvb Firmware is dvb-usb-dib0700-1.20.fw dmesg confirms a running firmware: [ 2451.437786] usb 2-9.2: new high speed USB device using ehci_hcd and address 7 [ 2451.483223] usb 2-9.2: configuration #1 chosen from 1 choice [ 2451.483456] dvb-usb: found a 'Hauppauge Nova-T Stick' in cold state, will try to load a firmware [ 2451.549092] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [ 2451.645168] dib0700: firmware started successfully. [ 2451.853933] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state. [ 2451.853978] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 2451.854807] DVB: registering new adapter (Hauppauge Nova-T Stick) [ 2451.951183] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [ 2452.026905] DiB0070: successfully identified [ 2452.026969] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb2/2-9/2-9.2/input/input7 [ 2452.042118] dvb-usb: schedule remote query interval to 50 msecs. [ 2452.042123] dvb-usb: Hauppauge Nova-T Stick successfully initialized and connected. Afterwards my TV client (MeTV) is able to scan several channels and starts to play the first one found. As soon as i try to chance the channel (to whatever i like) the client hangs and dmesg shows the following: [ 2542.022459] BUG: unable to handle kernel NULL pointer dereference at virtual address [ 2542.022465] printing eip: f8a951f3 *pde = [ 2542.022469] Oops: [#1] SMP [ 2542.022471] Modules linked in: binfmt_misc af_packet rfcomm l2cap bluetooth nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ipv6 ppdev powernow_k8 cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand freq_table cpufreq_conservative video output sbs sbshc dock container battery iptable_filter ip_tables x_tables isofs nls_iso8859_1 nls_cp437 vfat fat ac ndiswrapper sbp2 lp usb_storage usbhid libusual hid dvb_usb_dib0700 dib7000p dib7000m dvb_usb dvb_core dib3000mc dibx000_common dib0070 nvidia(P) agpgart snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device i2c_nforce2 k8temp snd button i2c_core shpchp pci_hotplug parport_pc parport evdev soundcore pcspkr ext3 jbd mbcache sd_mod sg sr_mod cdrom sata_nv pata_amd pata_acpi ehci_hcd ohci1394 ohci_hcd ata_generic ieee1394 usbcore forcedeth libata scsi_mod thermal processor fan fbcon tileblit font bitblit softcursor fuse [ 2542.022513] [ 2542.022515] Pid: 8068, comm: me-tv Tainted: P (2.6.24-24-generic #1) [ 2542.022517] EIP: 0060:[] EFLAGS: 00210217 CPU: 1 [ 2542.022527] EIP is at dvb_dmxdev_delete_pids+0x13/0x60 [dvb_core] [ 2542.022529] EAX: EBX: f8c850c0 ECX: EDX: d8afa000 [ 2542.022531] ESI: fff8 EDI: f8c850c4 EBP: f8c850c0 ESP: d8afbf38 [ 2542.022533] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 2542.022535] Process me-tv (pid: 8068, ti=d8afa000 task=e9feab80 task.ti=d8afa000) [ 2542.022537] Stack: f8c850c0 cc88e90c f7ae7cc0 cc88e950 f8a953ab 42b01ea1 d2ed3000 f8c85138 [ 2542.022541]0008 d2ed3000 f7ae7cc0 dfbc2218 c0192e37 f7ae7cc0 [ 2542.022545]f7d69280 dfbc2218 d2ed3000 f70c8900 d8afa000 c018fdc9 d2ed3000 [ 2542.022549] Call Trace: [ 2542.022555] [] dvb_demux_release+0x16b/0x170 [dvb_core] [ 2542.022570] [] __fput+0xa7/0x190 [ 2542.022582] [] filp_close+0x49/0x80 [ 2542.022588] [] sys_close+0x6e/0xd0 [ 2542.022593] [] sysenter_past_esp+0x6b/0xa9 [ 2542.022609] === [ 2542.022610] Code: ff ff c7 43 04 00 00 00 00 eb c5 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 89 c5 57 56 53 8b 40 04 8d 7d 04 89 c1 8d 70 f8 39 f9 <8b> 56 08 89 f8 74 37 8d 5a f8 eb 02 89 c3 8b 41 04 8b 11 89 42 [ 2542.022629] EIP: [] dvb_dmxdev_delete_pids+0x13/0x60 [dvb_core] SS:ESP 0068:d8afbf38 [ 2542.022639] ---[ end trace 0a443d8e9c7877f1 ]--- Afterwards i can't kill the me-tv process (stays as zombie) and a second instance of me-tv isn't able to find a demuxer 'Oeffnen des Video Streams gescheitert: Kein Demuxerplugin'. Any suggestions? Greeting - 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: Azurewave AD-CP400 (Twinhan VP-2040 DVB-C)
Claes Lindblom wrote: >> More majordomo info at http://vger.kernel.org/majordomo-info.html > Hi, I have the same problem with Slave RACK Fail on my Azurewave > AP-SP400 (VP-1041). > Do you really mean that to don't get theese problems when turning off > the log from open-sasc-ng or was the problem on open-sasc-ng? > I have turned off the log completely for a long time since it was > problems in open-sasc-ng but I still have problems with Slave RACK Fail. > I'm using the same drivers with Ubuntu server x86_64 2.6.28-13-generic > kernel. > > Have you done anything else to work properly, like patching open-sasc-ng > or the driver? > From my experience it really starts to fail when using MythTV, otherwise > I can tune channels for several days straight without any problems. > But when doing a complete channels scan it can make the driver fail so I > would not blame mythtv to much but it's feels like something messes > it up. > Maybe it's getting better in Mythtv 0.22... > > I'm almost about to sell my tv-card if it does not start to work > properly. :( > > Best regards > /Claes > If you read the entire thread it was MartinG that had the problem with "Slave RACK Fail". My machine just completely locked up before I removed the logging in open-sasc-ng. I'm currently using a vanilla 2.6.30.5 kernel, with open-sasc-ng r77 and s2-liplianin-16e3dc6f2758, on a Debian system with MythTV 0.21 from the vanilla sources. The only thing I've had to do to get open-sasc-ng to compile was comment out the lines containing "owner", specifically lines 175,187,196,221 in dvbloopback/module/dvblb_proc.c I can remember seeing Slave RACK Fail errors when using the older mantis driver from Manu (not the mantis-v4l one). That was however only when booting up, since it paused for a few seconds while displaying 4 of those errors. I don't see it now with the newer drivers though. Keep in mind that we don't even have the same card, since I have the AD-CP400 (DVB-C version). Thanks, Magnus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support, no idea what to try.
um .. help, please ? how can i make the driver read 1011011 instead of 011011 when i press Power instead of record on the remote ? thanks Morvan Le Meut a écrit : from cx88-input.c case CX88_BOARD_ADSTECH_DVB_T_PCI: ir_codes = ir_codes_adstech_dvb_t_pci; ir->gpio_addr = MO_GP1_IO; ir->mask_keycode = 0xbf; ir->mask_keyup = 0x40; ir->polling = 50; /* ms */ break; I'm not sure how much of the adstech instant tv dvb-t pci can be copied for the non dvb-t one but could the solution be something along the lines of that "ir->gpio_addr" thing ? or is that specific to the cx88 driver ? -- 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 1/1] FM TX: si4713: Kconfig: Fixed two typos.
Fixed two typos. Signed-off-by: Matti J. Aaltonen diff -r 5582a6427a41 -r ff80edccfe24 linux/drivers/media/radio/Kconfig --- a/linux/drivers/media/radio/Kconfig Tue Sep 01 22:16:23 2009 +0200 +++ b/linux/drivers/media/radio/Kconfig Fri Sep 11 10:25:13 2009 +0300 @@ -346,7 +346,7 @@ ---help--- Say Y here if you want support to Si4713 FM Radio Transmitter. This device can transmit audio through FM. It can transmit - EDS and EBDS signals as well. This module is the v4l2 radio + RDS and RBDS signals as well. This module is the v4l2 radio interface for the i2c driver of this device. To compile this driver as a module, choose M here: the -- 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: TeVii S650 DVB-S2 USB und s2-liplianin drivers
On Thu, Sep 10, 2009 at 11:56 PM, Igor M. Liplianin wrote: > On 10 сентября 2009, linux-media@vger.kernel.org wrote: >> Hi, >> I tried today s2-liplianin drivers with tevii s650 and vdr cant lock >> any channels with this error msg: >> >> <---snip> >> <6>stv0900_search: <7><6>Search Fail >> stv0900_read_status: <7>DEMOD LOCK FAIL >> stv0900_read_status: <7>DEMOD LOCK FAIL >> <6>stb0900_set_property(..) >> <6>stv0900_set_tone: On >> <---snip---> >> >> Then i found from old installation compiled drivers from rev12458 and >> installed it and everything work fine >> (s2-liplianin-hg-12458-1-i686.pkg.tar.gz). >> >> I am on archlinux x86 with 2.6.30.5-1 kernel >> -- >> 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 > Hi > I have s650 and tested it already. It works just fine. > Send you the firmware. Put it in /lib/firmware > Brief: > hg clone http://mercurial.intuxication.org/hg/s2-liplianin/ > cd s2-liplianin > make release > make > sudo make install > > BR > -- > Igor M. Liplianin > Microsoft Windows Free Zone - Linux used for all Computing Tasks > Hi,thnx for your replay. I already have had that firmware but i overwrited the old one (same size) just to be shure, i pulled again source and compiled but the problem is still there, this is from dmesg: <---snip> dvb-usb: found a 'TeVii S650 USB2.0' in cold state, will try to load a firmware usb 2-1: firmware: requesting dvb-usb-dw2104.fw usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid dvb-usb: downloading firmware from file 'dvb-usb-dw2104.fw' dw2102: start downloading DW210X firmware dvb-usb: found a 'TeVii S650 USB2.0' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TeVii S650 USB2.0) dvb-usb: MAC address: 00:00:00:00:00:00 <6>stv0900_init_internal <6>stv0900_init_internal: Create New Internal Structure! <6>stv0900_st_dvbs2_single <6>stv0900_set_ts_parallel_serial <6>stv0900_set_mclk: Mclk set to 13500, Quartz = 800 <6>stv0900_get_mclk_freq: Calculated Mclk = 48400 <6>stv0900_get_mclk_freq: Calculated Mclk = 48400 stv0900_attach: Attaching STV0900 demodulator(0) STV6110 attached on addr=60! dw2102: Attached STV0900! DVB: registering adapter 0 frontend 0 (STV0900 frontend)... input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:06.1/usb2/2-1/input/input7 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TeVii S650 USB2.0 successfully initialized and connected. usbcore: registered new interface driver dw2102 <6>stv0900_init stv0900_read_status: <7>DEMOD LOCK FAIL stv0900_read_status: <7>DEMOD LOCK FAIL stv0900_read_status: <7>DEMOD LOCK FAIL stv0900_read_status: <7>DEMOD LOCK FAIL stv0900_read_status: <7>DEMOD LOCK FAIL <6>stv0900_search: <7><6>Search Fail stv0900_read_status: <7>DEMOD LOCK FAIL <6>stv0900_search: <7><6>Search Fail stv0900_read_status: <7>DEMOD LOCK FAIL stv0900_read_status: <7>DEMOD LOCK FAIL <6>stb0900_set_property(..) <6>stv0900_set_tone: On <---snip> Durning compiling i sow some warnings: <---snip---> CC [M] /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/tevii_pwr.o /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/tevii_pwr.c: In function 'tevii_dvbs2_set_voltage': /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/tevii_pwr.c:335: warning: 'QuestionBuffer' may be used uninitialized in this function CC [M] /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/et61x251_core.o /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/et61x251_core.c: In function 'et61x251_ioctl_v4l2': /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/et61x251_core.c:2491: warning: the frame size of 1208 bytes is larger than 1024 bytes CC [M] /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/zc0301_core.o /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/zc0301_core.c: In function 'zc0301_ioctl_v4l2': /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/zc0301_core.c:1892: warning: the frame size of 1208 bytes is larger than 1024 bytes CC [M] /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/dib3000mc.o /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/dib3000mc.c: In function 'dib3000mc_i2c_enumeration': /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/dib3000mc.c:863: warning: the frame size of 1052 bytes is larger than 1024 bytes CC [M] /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/dib7000p.o /home/crow/archvdr/trunk/archvdr/s2-liplianin-hg/src/s2-liplianin-build/v4l/dib70
image quality of Labtec Webcam 2200
Hi, I have a Labtec Webcam 2200 and I have problems with the image quality with Linux 2.6.31 + libv4l 0.6.1. I made some experiments and stored each captured image as raw data and when libv4l was able to convert then I also stored the result as bmp. You can find my results at http://v4l-test.sourceforge.net/results/test-20090911/index.html There are three types of problems: a) Sometimes the picture contains a 8x8 pixel error, like in image #9 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 b) Sometimes the brightness of the half picture is changed, like in images #7, #36 and #37 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 c) Sometimes the libv4l cannot convert the raw image and the errno is set to EAGAIN (11), for example image #1, #2 and #3 Do you know how can I fix these problems? Regards, Márton Németh -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
