Re: video capture driver interlacing question (easycap)
Hi, i.e., no, you should not merge fields in the driver, IIRC, you just hand them over to the user in separate buffers. Thanks a lot for your answer. However, in that case I'm a little confused by the fact that em28xx driver merges both fields by copying one line from each into a buffer before handing it back to user. I'd love if someone could clarify this issue. Thanks a lot again, Ezequiel. -- 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: video capture driver interlacing question (easycap)
On Thu, Apr 26, 2012 at 5:33 PM, Ezequiel García elezegar...@gmail.com wrote: Hi everyone, As you may know I'm re-writing from scratch the staging/easycap driver. Finally, after digging through the labyrinthic staging/easycap code, I've reached a point where I'm able to understand isoc packets. Despite not having any documentation (I asked several times) from chip vendor, I can separate packets in odd and even. So, instead of receiving frames the device is sending me fields, right? My doubt now is this: * Do I have to *merge* this pair of fields for each frame, or can I give it to v4l? If affirmative: how should I *merge* them? * Is this related to multiplanar buffers (should I use vb2_plane_addr)? Currently, staging/easycap does some strange and complex conversion, from the pair of fields buffers, to get a frame buffer (!) but I'm not sure if it's the correct way to do it? I guess I can keep staring at em28xx (together with vivi/uvc/pwc) driver, but if someone cares to give me a small hint or point me at a small portion of code I'll be grateful. Thanks, Ezequiel. Anyone? -- 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
video capture driver interlacing question (easycap)
Hi everyone, As you may know I'm re-writing from scratch the staging/easycap driver. Finally, after digging through the labyrinthic staging/easycap code, I've reached a point where I'm able to understand isoc packets. Despite not having any documentation (I asked several times) from chip vendor, I can separate packets in odd and even. So, instead of receiving frames the device is sending me fields, right? My doubt now is this: * Do I have to *merge* this pair of fields for each frame, or can I give it to v4l? If affirmative: how should I *merge* them? * Is this related to multiplanar buffers (should I use vb2_plane_addr)? Currently, staging/easycap does some strange and complex conversion, from the pair of fields buffers, to get a frame buffer (!) but I'm not sure if it's the correct way to do it? I guess I can keep staring at em28xx (together with vivi/uvc/pwc) driver, but if someone cares to give me a small hint or point me at a small portion of code I'll be grateful. Thanks, Ezequiel. -- 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] TDA9887 PAL-Nc fix
Hola ;) From other discussions we've had at the ML, it seems that devices sold in Argentina with analog tuners sometimes come with a NTSC tuner, and sometimes come with an European PAL tuner. They solve the frequency shifts that happen there via some tda9887 (and/or tuner-simple) adjustments. It seems that the setup, when using one type, is different than the other. That's why we need to know exactly what it is the tuner that your device has. So, from time to time, we receive patches from someone in Argentina fixing support for one type, but breaking support for the other type. What we need is that someone with technical expertise and with the two types of devices, with access to real PAL-Nc signals, to work on a solution that would set it accordingly, depending on the actual tuner used on it. I live in Argentina, and have access to digital signal and some tuners. Perhaps I could help, provided someone cares to send me the relevant devices? Gonzalo: What device is that? -- 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: dvb lock patch
Josu, On Tue, Apr 17, 2012 at 10:30 AM, Josu Lazkano josu.lazk...@gmail.com wrote: 2012/3/24 Mauro Carvalho Chehab mche...@redhat.com: [snip] That doesn't sound right to me, and can actually cause race issues. Regards, Mauro. Thanks for the patch Mauro. I think Mauro is *not* giving you a patch, rather the opposite: pointing out that the patch can cause problems! Regards, Ezequiel. -- 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 0/5] Make em28xx-input.c a separate module
Hi, This patchset isolates em28xx-input code and turns it into a module, as suggested by Mauro [1]. Contrary to my initial expectations, the patch produces code that's actually cleaner and a slightly less spaghetti. I've tried to make the whole change as clear as possible by splitting it into several patches. This was done to ease the maintainer job and also in the hope that someone cares to review and provide feeback. As I don't have em28xx hardware, I did virtually no test at all so :( drivers/media/video/em28xx/Kconfig|4 +- drivers/media/video/em28xx/Makefile |5 +- drivers/media/video/em28xx/em28xx-cards.c | 66 + drivers/media/video/em28xx/em28xx-core.c |3 + drivers/media/video/em28xx/em28xx-i2c.c |3 - drivers/media/video/em28xx/em28xx-input.c | 250 +++-- drivers/media/video/em28xx/em28xx.h | 32 + 7 files changed, 175 insertions(+), 188 deletions(-) [1] http://www.spinics.net/lists/linux-media/msg45416.html Regards, Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV HVR 930C-HD - new USB ID 2040:b130 ?
Hi, 2012/3/26 Steffen Neumann sneum...@ipb-halle.de: sorry for bothering you directly, but I saw that No problem. you kinda work on em288xx. I asked yesterday on linux-media True about kinda, I don't own any em28xx devices :) about my problems with the em28xx based 930C on a 3.3 vanilla kernel. Yes, I saw the mail. I think indeed you have a device that is not supported (yet?) by em28xx. If lsusb says 2040:b130 rather than 2040:1605 then I guess it's a new kind of device, different chipset, I'm not sure (not an expert, sorry). Is this this the correct list to ask, and I just need to have more patience ? Or should I bring the issue up somewhere else ? Not sure wherelse you can post your question. Just wait for a while and ping again in a few weeks, or so. I believe we are in the middle of a merge window so developers are a little busy right now. Hope it helps! Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV HVR 930C-HD - new USB ID 2040:b130 ?
On 3/26/12, Neumann, Steffen sneum...@ipb-halle.de wrote: Not the answer I was looking for, But thanks everybody for the clarification. I'll try to register for the wiki and add I guess as a customer you could also contact the vendors and ask to support the device. Can't hurt, right? -- 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: [Q] v4l buffer format inside isoc
2012/3/20 Andy Walls awa...@md.metrocast.net: Section 8.10 of the SAA7113 data sheet shows 16 data formats. The interesting one for video is #15 Y:U:V 4:2:2. Thanks. Perhaps, I should have done my homework. The EM28xx chip programming might rearrange some data, but I have no knowledge or experience with the eMPIA chips. The chip is not eMPIA, but rather stk1160. It's a new chipset that's not currently supported (there is a similar one in stk-webcam). -- 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: [Q] v4l buffer format inside isoc
Hi, 2012/3/21 Jean-Francois Moine moin...@free.fr: In the gspca test tarball (see my site), I merged the spca506 code into the spca505 for a webcam which may also do analog video capture. The webcam works, but the analog video capture has never been tested. Also, the gspca_main - subdriver interface for vidioc_s_input and vidioc_s_std is not very clean. I'm not sure about this. The device is based on a new chip stk1160, and according to Mauro a new driver is needed. Since the chip supports tuner and other stuff besides video capture, perhaps adding a new driver might ease future development. Anyway, with saa7115 driver and the new videobuf2/v4l interface the driver we'll be very minimal (I hope). Thanks. -- 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: [Q] v4l buffer format inside isoc
Hi, 2012/3/21 Devin Heitmueller dheitmuel...@kernellabs.com: Every USB bridge provides their raw video over isoc in a slightly different format (not just in terms of the colorspace but also how to read the isoc header to detect the start of video frame, which field is being sent, etc). Regarding the colorspace, in many cases it's simply 16-bit YUYV, so I would probably start there. Ok. So, it's not saa7113 related, but rather stk1160 related? When there is no video, isoc urbs are received with actual length=4. This is header right? -- 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: [Q] v4l buffer format inside isoc
2012/3/21 Devin Heitmueller dheitmuel...@kernellabs.com: I'm not sure what you mean by no video. Do you have capture disabled? Are you saying that you didn't connect the video cable to your input? Most devices will continue to generate video frames over isoc even if there is no actual video signal present. I mean there is no signal at video input. But yeah, most of the solutions I have seen have every isoc packet starting with a header that includes descriptors for things like start of video frame, odd/even field, etc. Thanks, I'll keep reading sources and info. Hope it gets me somewhere. -- 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] go7007 patch for 3.2.x
Hi Volokh, You would need to make this at least against the 3.3 kernel, preferably against the linux-next branch. You can follow the instructions here to work off the for_v3.4 branch: http://git.linuxtv.org/media_tree.git Also, you didn't read the Documentation/SubmittingPatches file, please follow it properly, otherwise there is nothing we can do with your patch :( I think you will find this useful: http://www.youtube.com/watch?v=LLBrBBImJt4 It shows how you can submit patches using nothing but git. It's *much* easier than using diff yourself. It also shows the usage of checkpatch and get_maintainers script. Also, please read other patches sent to the list, so you can see how commit messages should look like. A little googling won't hurt: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html http://spheredev.org/wiki/Git_for_the_lazy#Writing_good_commit_messages Don't get discourage if your patches aren't accepted right away: it looks hard at first, but it's only until you get used to. Hope it helps, Ezequiel. -- 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
[Q] v4l buffer format inside isoc
Hello, I'm a little lost while writing a driver for an easycap device (saa7113 capture device). I have my isoc handler, and the isoc urb flying OK. I also have the videobuf2 queue setup (or at least I think so), and I understand I need to call vb2_buffer_done() with a filled buffer. What I DON'T understand is how should I fill such buffer? I mean, what *format* comes inside the isoc buffer? Should I look at saa7113 datasheet? Should I base in em28xx? I'm sorry to ask such a generic question. Perhaps, someone cares enough to give me a hint. Thanks, Ezequiel. -- 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: A second easycap driver implementation
Hi Mauro,
On 3/7/12, Mauro Carvalho Chehab mche...@redhat.com wrote:
The usage of saa711x is simple. All you need to do is to implement
an I2C bus at your easycap driver, load the module, and then, redirect
any demod ioctl call to the I2C bus, like:
static int vidioc_querystd(struct file *file, void *priv, v4l2_std_id *norm)
{
struct em28xx_fh *fh = priv;
struct em28xx *dev = fh-dev;
intrc;
rc = check_dev(dev);
if (rc 0)
return rc;
v4l2_device_call_all(dev-v4l2_dev, 0, video, querystd, norm);
return 0;
}
An I2C device has an address that needs to be send through the I2C
bus.
The saa711x devices use one of the I2C addresses below:
static unsigned short saa711x_addrs[] = {
0x4a 1, 0x48 1, /* SAA7111, SAA7111A and SAA7113 */
0x42 1, 0x40 1, /* SAA7114, SAA7115 and SAA7118 */
I2C_CLIENT_END };
I made my easycap driver use saa7115 driver to detect its saa7113 chip.
It wasn't so hard after some head scratching.
The problem is now modprobe is taking too long, mainly because saa7115 does
some probing.
I was thinking (since we already discussed deferring stuff to a workqueue):
Would it be problematic (in any fashion) to do add the i2c sub device
v4l2_i2c_new_subdev(dev-v4l2_dev, dev-i2c_adap,
saa7115_auto, 0, saa711x_addrs);
in a workqueue, (in the same way modules are loaded in workqueues)?
I think not, since we won't call i2c directly, but rather through
v4l2_device_call_all(), right?
Thanks,
Ezequiel.
--
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: eMPIA EM2710 Webcam (em28xx) and LIRC
Hi Mauro, On 3/15/12, Mauro Carvalho Chehab mche...@redhat.com wrote: If you won't take it, it is likely that some day someone will do it, but, as this is just a cleanup, the main developers won't likely have time for doing it, as they're generally busy adding support for new hardware. I have no problem submitting the two patches in discussion. (Actually, I've already wroten the first one). If Rui wants to help me, it would be nice to get this tested, since I don't have the necessary hardware. One thing I haven't got clear is this: I've seen that ir_raw_init() does not call request_module() directly but rather defers it through a work queue. I don't understand fully the rc code, but still I don't get what happens if I need the raw decoders *now* (so to speak) but the work queue hasn't been run yet? Thanks, Ezequiel. -- 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] media: rc: Pospone ir raw decoders loading until really needed
if (dev-driver_type == RC_DRIVER_IR_RAW) {
+ /* Load raw decoders, if they aren't already */
+ if (dev-raw_init) {
The logic here seems to be inverted. it should be, instead !dev-raw_init.
Duh! Sorry about that. I'm *way* too accustomed to test things first.
Will pay more attention in the future.
Thanks for the review. I'm resending it now.
Ezequiel.
--
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 v2] media: rc: Pospone ir raw decoders loading until really needed
Hi Jarod, On Thu, Mar 15, 2012 at 6:35 PM, Jarod Wilson ja...@redhat.com wrote: So yeah, ok, I'm fine with this. Haven't tested it with actual raw IR hardware, but I don't see any reason it wouldn't work. Acked-by: Jarod Wilson ja...@redhat.com Thanks for the feedback. I have a paranoid question: Is it ok to solve this with a static variable? I don't like static (as I fear globals), but in this case I saw no cleaner solution. Thanks again, Ezequiel. -- 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: eMPIA EM2710 Webcam (em28xx) and LIRC
Hi Rui,
On Wed, Mar 14, 2012 at 8:28 AM, Rui Salvaterra rsalvate...@gmail.com wrote:
Hi, everyone.
I apologise in advance for the noise if this is the wrong place to ask
such questions. I have a couple of eMPIA EM2710 (Silvercrest) USB
webcams which work quite well, except for the fact that most of LIRC
Exactly what module do you refer to? Could you just send a snippet
of dmesg when module is loaded?
is unnecessarily loaded when the em28xx module loads. I suppose it
shouldn't be necessary, since these are webcams and don't have any
Looking at source code, I noticed two things:
1. You have a module param named disable-ir, perhaps you could
try to use this (do you know how?).
2. EM2710 board is defined like this:
.name = EM2710/EM2750/EM2751 webcam grabber,
.xclk = EM28XX_XCLK_FREQUENCY_20MHZ,
.tuner_type= TUNER_ABSENT,
.is_webcam = 1,
.input = { {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = 0,
.amux = EM28XX_AMUX_VIDEO,
.gpio = silvercrest_reg_seq,
} },
As opposed to:
.name = Terratec Cinergy 250 USB,
.tuner_type = TUNER_LG_PAL_NEW_TAPC,
.has_ir_i2c = 1,
.tda9887_conf = TDA9887_PRESENT,
.decoder = EM28XX_SAA711X,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = SAA7115_COMPOSITE2,
.amux = EM28XX_AMUX_LINE_IN,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = SAA7115_COMPOSITE0,
.amux = EM28XX_AMUX_LINE_IN,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = SAA7115_SVIDEO3,
.amux = EM28XX_AMUX_LINE_IN,
} },
},
Noticed the lack of has_ir_i2c definition in the EM2710.
So I don't know how that module is being loaded. Probably I'm missing something.
Hope it helps,
Ezequiel.
--
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: eMPIA EM2710 Webcam (em28xx) and LIRC
Hi, 2012/3/14 Rui Salvaterra rsalvate...@gmail.com: Hi, Ezequiel. Thanks a lot for your reply. I'm attaching a copy of my full dmesg, its a bit hard to spot exactly where all modules are loaded (since the boot sequence became asynchronous). Indeed. Sure, no problem at all. I booted with em28xx disable_ir=1 and got the same result. Additionally: rui@wilykat:~$ lsmod | grep ir ir_lirc_codec 12901 0 lirc_dev 19204 1 ir_lirc_codec ir_mce_kbd_decoder 12724 0 ir_sanyo_decoder 12513 0 ir_sony_decoder 12510 0 ir_jvc_decoder 12507 0 ir_rc6_decoder 12507 0 ir_rc5_decoder 12507 0 ir_nec_decoder 12507 0 rc_core 26373 9 ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,em28xx,ir_rc5_decoder,ir_nec_decoder rui@wilykat:~$ Mmmm... Are you completely sure that em28xx driver is triggering the load of the ir related modules? Perhaps you could disable the module (blacklist, or compile out the module, or erase em28xx.ko to make sure) so you can see that effectively em28xx doesn't load and the rest of the modules doesn't load either, do you follow my line of reasoning? I'm also no kernel expert, just trying to be helpful. Hope it helps, Ezequiel. -- 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
[Q] tracing/printing
Hi, I'm writing a video capture device and have a doubt about how to correctly print to screen. First, I suppose I should follow the rule don't print unless there is something surprising to say, right? Second, I've found I need to print in a very verbose manner at developing stage so I should implement a debug param. I will probably adopt videobuf2 way (like many others) of defining a macro (dprintk or something). However, reading the source I've found there isn't a unified way to do this: some use printk (as defined macros), others use v4l_xxx, others use dev_xxx. I've adopted the latter, because I thought there could be many devices plugged, and using dev_xxx with the usb_device-dev helps seeing which is tracing. I'm not really sure if it is ok so I would love to hear some opinions about this sensible issue. Thanks! -- 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: eMPIA EM2710 Webcam (em28xx) and LIRC
Hi, I'm positive, the LIRC modules aren't loaded at all if I boot with the webcam disconnected. As soon as I plug it into an USB port, em28xx and LIRC are loaded. So... why don't you post *this* dmesg: First boot the computer. Then change the kernel debug level so to get every output possible. Then insert the module. This dmesg is of some interest, not the previous one. A couple of things you can test: 1. If your module is getting loaded when the device is plugged, then udev must be running. I suggest you to turn it off, just to remove it from the equation. Once you do this, you'll have to load module manually. 2. Also modprobe maybe handling dependencies. To check this you can do: $ modprobe -v em28xx 3. You can try *not* to use modprobe. So start fresh (from boot) and load with insmod providing full path, like this: $ insmod /lib/modules/3.3.0-rc3-athlon-full-preempt-gentoo+/kernel/drivers/media/video/em28xx/em28xx.ko Probably you'll bump into unknown symbol errors. You can see them with dmesg. Hope it helps, Ezequiel. -- 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: A second easycap driver implementation
Hi, Have you considered instead slowly moving the existing easycap driver over to all the new infrastructure we have now. For starters replace its buffer management with videobuf2, then in another patch replace some other bits, etc. ? See what I've done to the pwc driver :) Yes. And that was what I was doing until now. Yet, after some work it seemed much easier to simply start over from scratch. Besides, it's being a great learning experience :) So, since the driver is not yet working I guess there is no point in submitting anything. Instead, anyone the wants to help I can send what I have now or we can start working through github. If someone owns this device, it would be a *huge* help with testing. However, as soon as this is capturing video I would like to put it on staging, so everyone can help. Is this possible? Thanks, Ezequiel. -- 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: A second easycap driver implementation
On Wed, Mar 7, 2012 at 1:35 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Yes, the driver is weird, as it encapsulates the demod code inside it , instead of using the saa7115 driver, that covers most of saa711x devices, including saa7113. Btw, is this driver really needed? The em28xx driver has support for the Easy Cap Capture DC-60 model (I had access to one of those in the past, and I know that the driver works properly). What's the chipset using on your Easycap device? Chipset is STK116. I'm not entirely sure but is seems that there are to models: DC60 and DC60+. Apparently, the former would be using STK1160. If it is not an Empiatech em28xx USB bridge, then it makes sense to have a separate driver for it. Otherwise, it is just easier and better to add support for your device there. Ok, I'll take a look at the em28xx driver and also at the saa711x to see how would it be possible to add support for this device. Perhaps, we'll end up with a separate driver but based on some common code. Thanks, Ezequiel. -- 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: A second easycap driver implementation
Hi Mauro,
em28xx is a good reference.
I'm looking at it.
In fact, I have a first question: why there is a limit to the number of devices
the driver support? I found the same idea in easycap original
implementation, but I
can't understand why do we have to limit in such a way.
/* Check to see next free device and mark as used */
do {
nr = find_first_zero_bit(em28xx_devused, EM28XX_MAXBOARDS);
if (nr = EM28XX_MAXBOARDS) {
/* No free device slots */
printk(DRIVER_NAME : Supports only %i em28xx
boards.\n,
EM28XX_MAXBOARDS);
retval = -ENOMEM;
goto err_no_slot;
}
} while (test_and_set_bit(nr, em28xx_devused));
It is not clear, from the easycap code, where the I2C address
is stored:
int write_saa(struct usb_device *p, u16 reg0, u16 set0)
{
if (!p)
return -ENODEV;
SET(p, 0x200, 0x00);
SET(p, 0x204, reg0);
SET(p, 0x205, set0);
SET(p, 0x200, 0x01);
return wait_i2c(p);
}
I think i2c_address it is near registers 0x200/0x204, which gets
initialised at setup_stk().
I'll have a closer look.
Thanks for your comments,
Ezequiel.
--
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
A second easycap driver implementation
Hello, After some research on v4l2 and videbuf2, and considering that easycap driver is pretty outdated I've decided to start writing a new driver from scratch. I am using the excellent vivi driver and some usb video capture drivers as a starting point. And of course, I'm using the current easycap implementation as a reference (it works pretty well). I have a couple of doubts regarding the development itself (how to trace properly, where to allocate urbs, and such) but perhaps the maintainers prefer to take a look at the code. However, currently the driver is just a skeleton: it does all v4l2 and videobuf2 intialization but it doesn't actually stream video or submit urbs. So, 1. Should I try to have something more finished before submit or can I submit as it is? 2. In any case, how should I submit it? (Considering there is already a working driver). Thanks, Ezequiel. -- 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
A second easycap driver implementation
Hello, After some research on v4l2 and videbuf2, and considering that easycap driver is pretty outdated I've decided to start writing a new driver from scratch. I am using the excellent vivi driver and some usb video capture drivers as a starting point. And of course, I'm using the current easycap implementation as a reference (it works pretty well). I have a couple of doubts regarding the development itself (how to trace properly, where to allocate urbs, and such) but perhaps the maintainers prefer to take a look at the code. However, currently the driver is just a skeleton: it does all v4l2 and videobuf2 intialization but it doesn't actually stream video or submit urbs. So, 1. Should I try to have something more finished before submit or can I submit as it is? 2. In any case, how should I submit it? (Considering there is already a working driver). Thanks, Ezequiel. -- 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: easycap: reset()
Hi Mike, On Sun, Feb 26, 2012 at 6:56 AM, R.M. Thomas rmtho...@sciolus.org wrote: Hi Ezequiel, As you probably know, I originally developed the driver on the Sourceforge site. Before uploading any new version of the driver I carried out extensive automated testing using various scripts I had written for this purpose. I attach the tarball for the final version of the Sourceforge driver in order to explain what I mean. When you unpack the tarball you will find the script ./tools/checktestPAL.sh, and you will see that this runs the script ./testPAL.sh unattended for 36 test cases. Early versions of the driver did not have the extra reset() calls, and I found that when I carried out the automated testing with ./tools/checktestPAL.sh and similar scripts the EasyCAP would sometimes fail to initialize correctly. In these cases no video stream was visible, with mplayer then displaying an unchanging green or black window. On average, I would see this failure in 5-10% of the test cases, but the behavior was not reproducible: failure would occur randomly on different test cases when I ran ./tools/checktestPAL.sh again. I never discovered what caused the failures. I assumed (without any evidence) that one of the EasyCAP chips was prone to latch-up or some similar hardware problem, but I may have been wrong about this. The practical workaround which I found was to forcibly reset the hardware registers whenever the driver detected problems at initialization. This is the reason for the time-consuming repeated use of the function reset(). It would certainly be desirable to remove the extra reset() calls if possible, and I hope you will be able to do so. However, I suggest that driver modifications involving reset() should be subjected to automated testing, because any resulting problems may not be apparent if testing is limited to one or two cases. I see. I'll pospone the reset() patch until further testing shows it is stable enough. Thanks a lot for the test scripts, they'll be of much help. On a more general point, I believe the easycap driver would benefit from some radical rewriting. At present it is not integrated with the V4L2 mainstream (for historical reasons), and this needs to be corrected: https://lkml.org/lkml/2010/11/29/376 That's true. However, the driver works fine and I'm not sure a complete rewrite is a good option. Unfortunately I cannot contribute to this myself, not only because I am fully committed now to an entirely different project, but also because I know so little about the V4L2 infrastructure that I could not be of much use. I do hope you will be able to make some progress with it. I understand. I also hope we make some progress with it :) If it is at all possible I would like to ask you to send me any information about the driver you have, I mean datasheets and that sort of stuff. Thanks a lot for your feedback, Ezequiel. -- 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: [question] v4l read() operation
Hi Dave, 2012/2/25 Dave Hylands dhyla...@gmail.com: I'm not all that familiar with v4l, but based on what you've posted, you need to populate the read routine in your v4l2_fops structure to support read. My bad! You are totally right: I forgot about my webcam. When I did: $ cat /dev/video0 I was actually getting data from my webcam (which supports read), and not from the easycap device, which is /dev/video1. So, everything makes sense now: $ cat /dev/video1 ... open(/dev/video1, O_RDONLY|O_LARGEFILE) = 3 ... read(3, 0x8835000, 32768) = -1 EINVAL (Invalid argument) This is clearly shown by the piece of code mentioned before. Thanks and sorry for the noise, Ezequiel. -- 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
[question] between probe() and open()
Hello, This is a question in general about usb drivers and in particular about easycap driver. Is there any way a driver can be accesed between after usb_probe() but before device open()? I guess not, since any further operation on the device needs a struct file pointer, i.e. a file descriptor on the user side. In particular: easycap driver currently calls reset() on usb_probe(), reset() does some hardware initialization among other stuff. However, the reset() is called once again on open(). This seems redundant, right? The reset() is a heavy function since it access the hardware, so it would be benefitial to change it, but I would like someone to ack this, since it is not so trivial. Some measures on the device shows how heavy the reset() is: # calling reset() on usb_probe() time modprobe easycap real0m1.516s user0m0.000s sys 0m0.009s --- # not calling reset() on usb_probe() time modprobe easycap real0m0.003s user0m0.000s sys 0m0.002s Thanks, Ezequiel. -- 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
[question] v4l read() operation
Hi,
If I register a video device with this fops:
static const struct v4l2_file_operations v4l2_fops = {
.owner = THIS_MODULE,
.open= xxx_open,
.unlocked_ioctl = xxx_unlocked_ioctl,
.poll = xxx_poll,
.mmap = xxx_mmap,
};
then if I cat the device
$ cat /dev/video0
Who is supporting read() ?
I thought it could be v4l2_read(),
however this function seems to return EINVAL:
static ssize_t v4l2_read(struct file *filp, char __user *buf,
size_t sz, loff_t *off)
{
struct video_device *vdev = video_devdata(filp);
int ret = -ENODEV;
if (!vdev-fops-read)
return -EINVAL;
if (vdev-lock mutex_lock_interruptible(vdev-lock))
return -ERESTARTSYS;
if (video_is_registered(vdev))
ret = vdev-fops-read(filp, buf, sz, off);
if (vdev-lock)
mutex_unlock(vdev-lock);
return ret;
}
Thanks,
Ezequiel.
--
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 5/9] staging: easycap: Push video registration to easycap_register_video()
Hi Dan, On Fri, Feb 24, 2012 at 3:39 PM, Dan Carpenter dan.carpen...@oracle.com wrote: On Fri, Feb 24, 2012 at 12:24:18PM -0300, Ezequiel Garcia wrote: + rc = easycap_register_video(peasycap); + if (rc 0) return -ENODEV; Don't resend. These are beautiful patches you are sending and I wouldn't want to slow you down. But it would have been better to return rc here. Ok, I'll do that in the future. Thanks for the feedback, and feel free to keep it coming :) Thanks for taking the time to review. I have to say I'm thrilled with having time (and knowledge) to work on the linux kernel. It was 12 years ago when I first installed a linux distro and I had no idea what to do with it back then! ;) -- 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
[question] USB video capture reference driver
Hi, I'm doing some work on easycap (staging) driver and I would like to ask which similar driver is available and/or recommended to follow code style and code design. Reading cx231xx driver I noticed that video buffer allocation and ioctl handling are done in a very different way using some v4l facilities. I believe this would be prefered over the current status, right? Thanks, Ezequiel. -- 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
Cleanup proposal for media/gspca
Hi folks,
In 'media/video/gspca/gspca.c' I really hated this cast (maybe because
I am too dumb to understand it):
gspca_dev = (struct gspca_dev *) video_devdata(file);
wich is only legal because a struct video_device is the first member
of gspca_dev. IMHO, this is 'unnecesary obfuscation'.
The thing is the driver is surely working fine and there is no good
reasong for the change.
Is it ok to submit a patchset to change this? Something like this:
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 881e04c..5d962ce 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1304,9 +1306,11 @@ static void gspca_release(struct video_device *vfd)
static int dev_open(struct file *file)
{
struct gspca_dev *gspca_dev;
+ struct video_device *vdev;
PDEBUG(D_STREAM, [%s] open, current-comm);
- gspca_dev = (struct gspca_dev *) video_devdata(file);
+ vdev = video_devdata(file);
+ gspca_dev = video_get_drvdata(vdev);
if (!gspca_dev-present)
Thanks,
Ezequiel.
--
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
