Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On Thu, Jan 27, 2011 at 04:58:57PM -0200, Mauro Carvalho Chehab wrote: Em 27-01-2011 15:21, Dmitry Torokhov escreveu: On Thu, Jan 27, 2011 at 08:30:00AM -0200, Mauro Carvalho Chehab wrote: On my tests here, this is working fine, with Fedora and RHEL 6, on my usual test devices, so I don't believe that the tool itself is broken, nor I think that the issue is due to the fix patch. I remember that when Kay added a persistence utility tool that opens a V4L device in order to read some capabilities, this caused a race condition into a number of drivers that use to register the video device too early. The result is that udev were opening the device before the end of the register process, causing OOPS and other problems. Well, this is quite possible. The usev ruls in the v4l-utils reads: ACTION==add, SUBSYSTEM==rc, RUN+=/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name So we act when we add RC device to the system. The corresponding input device has not been registered yet (and will not be for some time because before creating input ddevice we invoke request_module() to load initial rc map module) so the tool runs simultaneously with kernel registering input device and it could very well be it can't find something it really wants. This would explain why Mark sees the segfault only when invoked via udev but not when ran manually. However I still do not understand why Mark does not see the same issue without the patch. Like I said, maybe if Mark could recompile with debug data and us a core we'd see what is going on. Race conditions are hard to track... probably the new code added some delay, and this allowed the request_module() to finish his job. BTW, that means that we need to redo udev rules. If there's a race condition, then the proper fix is to lock the driver until it is ready to receive a fops. Maybe we'll need a mutex to preventing opening the device until it is completely initialized. No, not at all. The devices are ready to handle everything when they are created, it's just some devices are not there yet. What you do with current udev rule is similar to trying to mount filesystem as soon as you discover a PCI SCSI card. The controller is there but disks have not been discovered, block devices have not been created, and so on. It is hard to tell, as Mark didn't provide us yet the dmesg info (at least on the emails I was c/c), so I don't even know what device he has, and what drivers are used. I belie you have been copied on the mail that had the following snippet: kernel: Registered IR keymap rc-rc5-tv udevd-event[6438]: run_program: '/usr/bin/ir-keytable' abnormal exit kernel: input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input7 kernel: ir-keytable[6439]: segfault at 8 ip 004012d2 sp 7fff6d43ca60 error 4 in ir-keytable[40+7000] kernel: rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0 kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0] Maybe we should split the utility into 2 parts - one dealing with rcX device and for keymap setting reuse udev's existing utility that adjusts maps on ann input devices, not for RCs only. It could be done, but then we'll need to pollute the existing input tools with RC-specific stuff. For IR, there are some additional steps, like the need to select the IR protocol, otherwise the keytable is useless. That should be done by the separate utility that fires up when udev gets event for /sys/class/rc/rcX device. Also, the keytable and persistent info is provided via /sys/class/rc/rc?/uevent. So, the tool need to first read the RC class, check what keytable should be associated with that device (based on a custom file), and load the proper table. And this could be easily added to the udev's keymap utility that is fired up when we discover evdevX devices. Also, I'm currently working on a way to map media keys for remote controllers into X11 (basically, mapping them into the keyspace between 8-255, passing through Xorg evdev.c, and then mapping back into some X11 symbols). This way, we don't need to violate the X11 protocol. (Yeah, I know this is hacky, but while X11 cannot pass the full evdev keycode, at least the Remote Controllers will work). This probably means that we may need to add some DBus logic inside ir-keytable, when called via udev, to allow it to announce to X11. The same issue is present with other types of input devices (multimedia keyboards emitting codes that X can't consume) and so it again would make sense to enhance udev's utility instead of confining it all to ir-keytable. Thanks. -- Dmitry -- 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 v8 03/12] media: Entities, pads and links
Hi Laurent,
Thanks for the patches!
I've got one comment that I should have made long time ago... Pads are
inputs or outputs... or: are they sinks or sources? I recall that it was
agreed on some occasion that sink and source are much less ambiguous and
they should be used instead.
So we'd have MEDIA_PAD_FL_{SINK,SOURCE}, for example. Currently the
source and documentation is using input/output and source/sink
interchangeably. I think sink and source should be used all the time.
What do you think?
Regards,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Em 28-01-2011 07:39, Dmitry Torokhov escreveu: On Thu, Jan 27, 2011 at 04:58:57PM -0200, Mauro Carvalho Chehab wrote: Em 27-01-2011 15:21, Dmitry Torokhov escreveu: On Thu, Jan 27, 2011 at 08:30:00AM -0200, Mauro Carvalho Chehab wrote: On my tests here, this is working fine, with Fedora and RHEL 6, on my usual test devices, so I don't believe that the tool itself is broken, nor I think that the issue is due to the fix patch. I remember that when Kay added a persistence utility tool that opens a V4L device in order to read some capabilities, this caused a race condition into a number of drivers that use to register the video device too early. The result is that udev were opening the device before the end of the register process, causing OOPS and other problems. Well, this is quite possible. The usev ruls in the v4l-utils reads: ACTION==add, SUBSYSTEM==rc, RUN+=/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name So we act when we add RC device to the system. The corresponding input device has not been registered yet (and will not be for some time because before creating input ddevice we invoke request_module() to load initial rc map module) so the tool runs simultaneously with kernel registering input device and it could very well be it can't find something it really wants. This would explain why Mark sees the segfault only when invoked via udev but not when ran manually. However I still do not understand why Mark does not see the same issue without the patch. Like I said, maybe if Mark could recompile with debug data and us a core we'd see what is going on. Race conditions are hard to track... probably the new code added some delay, and this allowed the request_module() to finish his job. BTW, that means that we need to redo udev rules. If there's a race condition, then the proper fix is to lock the driver until it is ready to receive a fops. Maybe we'll need a mutex to preventing opening the device until it is completely initialized. No, not at all. The devices are ready to handle everything when they are created, it's just some devices are not there yet. What you do with current udev rule is similar to trying to mount filesystem as soon as you discover a PCI SCSI card. The controller is there but disks have not been discovered, block devices have not been created, and so on. The rc-core register (and the corresponding input register) is done when the device detected a remote controller, so, it should be safe to register on that point. If not, IMHO, there's a bug somewhere. Yet, I agree that udev tries to set devices too fast. It would be better if it would wait for a few milisseconds, to reduce the risk of race conditions. It is hard to tell, as Mark didn't provide us yet the dmesg info (at least on the emails I was c/c), so I don't even know what device he has, and what drivers are used. I belie you have been copied on the mail that had the following snippet: kernel: Registered IR keymap rc-rc5-tv udevd-event[6438]: run_program: '/usr/bin/ir-keytable' abnormal exit kernel: input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input7 kernel: ir-keytable[6439]: segfault at 8 ip 004012d2 sp 7fff6d43ca60 error 4 in ir-keytable[40+7000] kernel: rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0 kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0] Ok, the last line says it is a ivtv board, using IR. However, it doesn't show the I2C detection of other devices that might be racing to gain access to the I2C bus, nor if some OOPS were hit by kernel. I don't have any ivtv boards handy, but there are some developers at linux-media ML that may help with this. Maybe we should split the utility into 2 parts - one dealing with rcX device and for keymap setting reuse udev's existing utility that adjusts maps on ann input devices, not for RCs only. It could be done, but then we'll need to pollute the existing input tools with RC-specific stuff. For IR, there are some additional steps, like the need to select the IR protocol, otherwise the keytable is useless. That should be done by the separate utility that fires up when udev gets event for /sys/class/rc/rcX device. Also, the keytable and persistent info is provided via /sys/class/rc/rc?/uevent. So, the tool need to first read the RC class, check what keytable should be associated with that device (based on a custom file), and load the proper table. And this could be easily added to the udev's keymap utility that is fired up when we discover evdevX devices. Yes, it can, if you add the IR protocol selection on that tool. A remote controller keycode table has both the protocol and the keycodes. This basically means to merge 99% of the logic inside ir-keytable into the evdev generic tool. I'm not against it, although I prefer a specialized tool for RC. Also, I'm currently working on a way to map media keys for remote
[PATCH 1/2] v4l2: vb2: fix queue reallocation and REQBUFS(0) case
This patch fixes 2 minor bugs in videobuf2 core:
1. Queue should be reallocated if one change the memory access
method without changing the number of buffers.
2. In case of REQBUFS(0), the request should not be passed to the
driver.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf2-core.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index cc7ab0a..2f724ed 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -488,7 +488,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
return -EINVAL;
}
- if (req-count == 0 || q-num_buffers != 0) {
+ if (req-count == 0 || q-num_buffers != 0 || q-memory != req-memory)
{
/*
* We already have buffers allocated, so first check if they
* are not in use and can be freed.
@@ -501,6 +501,13 @@ int vb2_reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
ret = __vb2_queue_free(q);
if (ret != 0)
return ret;
+
+ /*
+* In case of REQBUFS(0) return immedietely without calling
+* driver's queue_setup() callback and allocating resources.
+*/
+ if (req-count == 0)
+ return 0;
}
/*
--
1.7.1.569.g6f426
--
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/2] Videobuf2 hot fixes
Hello! This is a small set of bugfixes for videobuf2 framework. It looks that even review done by 3 other developers can miss some minor bugs. I hope they can be applied to v2.6.38-rcX kernel series once vb2 finally gets into Linus tree. Best regards -- Marek Szyprowski Samsung Poland RD Center Patch summary: Andrzej Pietrasiewicz (1): v4l2: vb2-dma-sg: fix memory leak Marek Szyprowski (1): v4l2: vb2: fix queue reallocation and REQBUFS(0) case drivers/media/video/videobuf2-core.c |9 - drivers/media/video/videobuf2-dma-sg.c |2 ++ 2 files changed, 10 insertions(+), 1 deletions(-) -- 1.7.1.569.g6f426 -- 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/2] v4l2: vb2-dma-sg: fix memory leak
From: Andrzej Pietrasiewicz andrze...@samsung.com This patch fixes two minor memory leaks in videobuf2-dma-sg module. They might happen only in case some other operations (like memory allocation) failed. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- drivers/media/video/videobuf2-dma-sg.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/videobuf2-dma-sg.c b/drivers/media/video/videobuf2-dma-sg.c index 20b5c5d..d5311ff 100644 --- a/drivers/media/video/videobuf2-dma-sg.c +++ b/drivers/media/video/videobuf2-dma-sg.c @@ -88,6 +88,7 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long size) fail_pages_alloc: while (--i = 0) __free_page(buf-pages[i]); + kfree(buf-pages); fail_pages_array_alloc: vfree(buf-sg_desc.sglist); @@ -176,6 +177,7 @@ userptr_fail_get_user_pages: num_pages_from_user, buf-sg_desc.num_pages); while (--num_pages_from_user = 0) put_page(buf-pages[num_pages_from_user]); + kfree(buf-pages); userptr_fail_pages_array_alloc: vfree(buf-sg_desc.sglist); -- 1.7.1.569.g6f426 -- 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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On Fri, Jan 28, 2011 at 09:55:58AM -0200, Mauro Carvalho Chehab wrote: Em 28-01-2011 07:39, Dmitry Torokhov escreveu: On Thu, Jan 27, 2011 at 04:58:57PM -0200, Mauro Carvalho Chehab wrote: Em 27-01-2011 15:21, Dmitry Torokhov escreveu: On Thu, Jan 27, 2011 at 08:30:00AM -0200, Mauro Carvalho Chehab wrote: On my tests here, this is working fine, with Fedora and RHEL 6, on my usual test devices, so I don't believe that the tool itself is broken, nor I think that the issue is due to the fix patch. I remember that when Kay added a persistence utility tool that opens a V4L device in order to read some capabilities, this caused a race condition into a number of drivers that use to register the video device too early. The result is that udev were opening the device before the end of the register process, causing OOPS and other problems. Well, this is quite possible. The usev ruls in the v4l-utils reads: ACTION==add, SUBSYSTEM==rc, RUN+=/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name So we act when we add RC device to the system. The corresponding input device has not been registered yet (and will not be for some time because before creating input ddevice we invoke request_module() to load initial rc map module) so the tool runs simultaneously with kernel registering input device and it could very well be it can't find something it really wants. This would explain why Mark sees the segfault only when invoked via udev but not when ran manually. However I still do not understand why Mark does not see the same issue without the patch. Like I said, maybe if Mark could recompile with debug data and us a core we'd see what is going on. Race conditions are hard to track... probably the new code added some delay, and this allowed the request_module() to finish his job. BTW, that means that we need to redo udev rules. If there's a race condition, then the proper fix is to lock the driver until it is ready to receive a fops. Maybe we'll need a mutex to preventing opening the device until it is completely initialized. No, not at all. The devices are ready to handle everything when they are created, it's just some devices are not there yet. What you do with current udev rule is similar to trying to mount filesystem as soon as you discover a PCI SCSI card. The controller is there but disks have not been discovered, block devices have not been created, and so on. The rc-core register (and the corresponding input register) is done when the device detected a remote controller, so, it should be safe to register on that point. If not, IMHO, there's a bug somewhere. It is not a matter of safe or unsafe registration. Registration is fine. The problem is that with the current set up is that utility is fired when trunk of [sub]tree is created, but the utility wants to operate on leaves which may not be there yet. Yet, I agree that udev tries to set devices too fast. It tries to set devices exacty when you tell it to do so. It's not like it goes trolling for random devices is sysfs. It would be better if it would wait for a few milisseconds, to reduce the risk of race conditions. Gah, I really prefer using properly engineered solutions instead of adding crutches. It is hard to tell, as Mark didn't provide us yet the dmesg info (at least on the emails I was c/c), so I don't even know what device he has, and what drivers are used. I belie you have been copied on the mail that had the following snippet: kernel: Registered IR keymap rc-rc5-tv udevd-event[6438]: run_program: '/usr/bin/ir-keytable' abnormal exit kernel: input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input7 kernel: ir-keytable[6439]: segfault at 8 ip 004012d2 sp 7fff6d43ca60 error 4 in ir-keytable[40+7000] kernel: rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0 kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0] Ok, the last line says it is a ivtv board, using IR. However, it doesn't show the I2C detection of other devices that might be racing to gain access to the I2C bus, nor if some OOPS were hit by kernel. I don't have any ivtv boards handy, but there are some developers at linux-media ML that may help with this. Maybe we should split the utility into 2 parts - one dealing with rcX device and for keymap setting reuse udev's existing utility that adjusts maps on ann input devices, not for RCs only. It could be done, but then we'll need to pollute the existing input tools with RC-specific stuff. For IR, there are some additional steps, like the need to select the IR protocol, otherwise the keytable is useless. That should be done by the separate utility that fires up when udev gets event for /sys/class/rc/rcX device. Also, the keytable and persistent info is provided via /sys/class/rc/rc?/uevent. So, the tool need
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On Thu, Jan 27, 2011 at 11:53:25AM -0800, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 01:12:48PM -0500, Mark Lord wrote: On 11-01-27 11:39 AM, Dmitry Torokhov wrote: On Wed, Jan 26, 2011 at 10:18:53PM -0500, Mark Lord wrote: No, it does not seem to segfault when I unload/reload ir-kbd-i2c and then invoke it by hand with the same parameters. Quite possibly the environment is different when udev invokes it, and my strace attempt with udev killed the system, so no info there. Hmm, what about compiling with debug and getting a core then? Sure. debug is easy, -g, but you'll have to tell me how to get it do produce a core dump. See if adjusting /etc/security/limits.conf will enable it to dump core. Otherwise you'll have to stick 'ulimit -c unlimited' somewhere... Mark, Any luck with getting the core? I'd really like to resolve this issue. Thanks. -- Dmitry -- 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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Em 28-01-2011 14:40, Dmitry Torokhov escreveu: On Fri, Jan 28, 2011 at 09:55:58AM -0200, Mauro Carvalho Chehab wrote: The rc-core register (and the corresponding input register) is done when the device detected a remote controller, so, it should be safe to register on that point. If not, IMHO, there's a bug somewhere. It is not a matter of safe or unsafe registration. Registration is fine. The problem is that with the current set up is that utility is fired when trunk of [sub]tree is created, but the utility wants to operate on leaves which may not be there yet. I'm not an udev expert. Is there a udev event that hits only after having the driver completely loaded? Starting an udev rule while modprobe is still running is asking for race conditions. I'm not entirely convinced that this is the bug that Mark is hitting, as rc-core does all needed setups before registering the evdev device. We need the core and the dmesg to be sure about what's happening there. Yet, I agree that udev tries to set devices too fast. It tries to set devices exacty when you tell it to do so. It's not like it goes trolling for random devices is sysfs. It would be better if it would wait for a few milisseconds, to reduce the risk of race conditions. Gah, I really prefer using properly engineered solutions instead of adding crutches. I agree. And this could be easily added to the udev's keymap utility that is fired up when we discover evdevX devices. Yes, it can, if you add the IR protocol selection on that tool. A remote controller keycode table has both the protocol and the keycodes. This basically means to merge 99% of the logic inside ir-keytable into the evdev generic tool. Or just have an utility producing keymap name and feed it as input to the generic tools. The way most of utilities work... I don't like the idea of running a some logic at udev that would generate such keymap in runtime just before calling the generic tool. The other alternative (e. g.) to maintain the RC-protocol dependent keytables separate from the RC protocol used by each table will be a maintenance nightmare. Also, I'm currently working on a way to map media keys for remote controllers into X11 (basically, mapping them into the keyspace between 8-255, passing through Xorg evdev.c, and then mapping back into some X11 symbols). This way, we don't need to violate the X11 protocol. (Yeah, I know this is hacky, but while X11 cannot pass the full evdev keycode, at least the Remote Controllers will work). This probably means that we may need to add some DBus logic inside ir-keytable, when called via udev, to allow it to announce to X11. The same issue is present with other types of input devices (multimedia keyboards emitting codes that X can't consume) and so it again would make sense to enhance udev's utility instead of confining it all to ir-keytable. I agree with you, but I'm not sure if we can find a solution that will work for both RC and media keyboards, as X11 evdev just maps keyboards on the 8-255 range. I was thinking to add a detection there for RC, and use a separate map for them, as RC don't need most of the normal keyboard keys. Well, there will always be clashes - there is reason why evdev goes beyond 255 keycodes... Yeah. The most appropriate fix would be for X to just use the full evdev keycode range. However, I'm not seeing any indication that such change will happen soon. Not sure if there are some news about it at LCA, as there were one speech about this subject there. 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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On Fri, Jan 28, 2011 at 03:01:58PM -0200, Mauro Carvalho Chehab wrote: Em 28-01-2011 14:40, Dmitry Torokhov escreveu: On Fri, Jan 28, 2011 at 09:55:58AM -0200, Mauro Carvalho Chehab wrote: The rc-core register (and the corresponding input register) is done when the device detected a remote controller, so, it should be safe to register on that point. If not, IMHO, there's a bug somewhere. It is not a matter of safe or unsafe registration. Registration is fine. The problem is that with the current set up is that utility is fired when trunk of [sub]tree is created, but the utility wants to operate on leaves which may not be there yet. I'm not an udev expert. Is there a udev event that hits only after having the driver completely loaded? Define completely loaded? For a PCI SCSI controller does fully loaded mean all attached devices are discovered and registered with block layer? For a wireless NIC does it mean that it assocuated with an AP? What if you have more than one device that driver serves? So teh answer is no and there should not be. Starting an udev rule while modprobe is still running is asking for race conditions. Not if we write stuff properly. I'm not entirely convinced that this is the bug that Mark is hitting, as I do not know yet. rc-core does all needed setups before registering the evdev device. We need the core and the dmesg to be sure about what's happening there. I will say it again. Your udev rule triggers when you create rcX device. eventX device may apeear 2 hours after that (I could have evdev as a module and blacklisted and load it later manually). You need to split it into 2 separate steps: 1. Triggers when rcX appears, accesses only rcX and it's parents and does rcX related stuff. 2. Triggers when eventX appears and loads keymap and what not. Because it is a child of rcX (in specific case of remotes) it may examine rcX attributes as well. Yet, I agree that udev tries to set devices too fast. It tries to set devices exacty when you tell it to do so. It's not like it goes trolling for random devices is sysfs. It would be better if it would wait for a few milisseconds, to reduce the risk of race conditions. Gah, I really prefer using properly engineered solutions instead of adding crutches. I agree. And this could be easily added to the udev's keymap utility that is fired up when we discover evdevX devices. Yes, it can, if you add the IR protocol selection on that tool. A remote controller keycode table has both the protocol and the keycodes. This basically means to merge 99% of the logic inside ir-keytable into the evdev generic tool. Or just have an utility producing keymap name and feed it as input to the generic tools. The way most of utilities work... I don't like the idea of running a some logic at udev that would generate such keymap in runtime just before calling the generic tool. The other Why? You'd just call something like: keymap $name `rc-keymap-name -d $name` where 'keymap' is udev's utility and 'rc-keymap-name' is new utility that incorporates map selection logic currently found in rc-keytable. It looks like format of the keymaps is compatible between 'keymap' and 'ir-keytable' and metadata that is present in your keymaps will not confuse 'keymap' utility. alternative (e. g.) to maintain the RC-protocol dependent keytables separate from the RC protocol used by each table will be a maintenance nightmare. I do not propose splitting keytables, I propose splittign utilities. ir-keytable is a kitchen sink now. It implements 'keymap', 'evtest' and bucnch of other stuff and would be much cleaner if split apart. Also, I'm currently working on a way to map media keys for remote controllers into X11 (basically, mapping them into the keyspace between 8-255, passing through Xorg evdev.c, and then mapping back into some X11 symbols). This way, we don't need to violate the X11 protocol. (Yeah, I know this is hacky, but while X11 cannot pass the full evdev keycode, at least the Remote Controllers will work). This probably means that we may need to add some DBus logic inside ir-keytable, when called via udev, to allow it to announce to X11. The same issue is present with other types of input devices (multimedia keyboards emitting codes that X can't consume) and so it again would make sense to enhance udev's utility instead of confining it all to ir-keytable. I agree with you, but I'm not sure if we can find a solution that will work for both RC and media keyboards, as X11 evdev just maps keyboards on the 8-255 range. I was thinking to add a detection there for RC, and use a separate map for them, as RC don't need most of the normal keyboard keys. Well, there will always be clashes - there is reason why evdev goes beyond 255 keycodes... Yeah. The most appropriate fix would be for X to just use
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Em 28-01-2011 15:33, Dmitry Torokhov escreveu: On Fri, Jan 28, 2011 at 03:01:58PM -0200, Mauro Carvalho Chehab wrote: Em 28-01-2011 14:40, Dmitry Torokhov escreveu: On Fri, Jan 28, 2011 at 09:55:58AM -0200, Mauro Carvalho Chehab wrote: The rc-core register (and the corresponding input register) is done when the device detected a remote controller, so, it should be safe to register on that point. If not, IMHO, there's a bug somewhere. It is not a matter of safe or unsafe registration. Registration is fine. The problem is that with the current set up is that utility is fired when trunk of [sub]tree is created, but the utility wants to operate on leaves which may not be there yet. I'm not an udev expert. Is there a udev event that hits only after having the driver completely loaded? Define completely loaded? For a PCI SCSI controller does fully loaded mean all attached devices are discovered and registered with block layer? For a wireless NIC does it mean that it assocuated with an AP? What if you have more than one device that driver serves? So teh answer is no and there should not be. Starting an udev rule while modprobe is still running is asking for race conditions. Not if we write stuff properly. I'm not entirely convinced that this is the bug that Mark is hitting, as I do not know yet. rc-core does all needed setups before registering the evdev device. We need the core and the dmesg to be sure about what's happening there. I will say it again. Your udev rule triggers when you create rcX device. eventX device may apeear 2 hours after that (I could have evdev as a module and blacklisted and load it later manually). Blacklisting it won't (or shouldn't work). From rc-main, the registering sequence is: dev_set_name(dev-dev, rc%ld, dev-devno); dev_set_drvdata(dev-dev, dev); rc = device_add(dev-dev); if (rc) return rc; rc = ir_setkeytable(dev, rc_map); if (rc) goto out_dev; dev-input_dev-dev.parent = dev-dev; memcpy(dev-input_dev-id, dev-input_id, sizeof(dev-input_id)); dev-input_dev-phys = dev-input_phys; dev-input_dev-name = dev-input_name; rc = input_register_device(dev-input_dev); if (rc) goto out_table; rc-main will wait for input_register_device() to finish, so even if you blacklist it, rc-core will load it, in order to solve the symbol dependency. Btw, there's really a race issue there: device_add is happening before input_register_device(), so the udev rule will cause troubles. You need to split it into 2 separate steps: 1. Triggers when rcX appears, accesses only rcX and it's parents and does rcX related stuff. 2. Triggers when eventX appears and loads keymap and what not. Because it is a child of rcX (in specific case of remotes) it may examine rcX attributes as well. The fix is probably simpler: we need to change the udev rules to work at evdev registration and only if the device is a remote controller. This should solve the current issue. Yet, I agree that udev tries to set devices too fast. It tries to set devices exacty when you tell it to do so. It's not like it goes trolling for random devices is sysfs. It would be better if it would wait for a few milisseconds, to reduce the risk of race conditions. Gah, I really prefer using properly engineered solutions instead of adding crutches. I agree. And this could be easily added to the udev's keymap utility that is fired up when we discover evdevX devices. Yes, it can, if you add the IR protocol selection on that tool. A remote controller keycode table has both the protocol and the keycodes. This basically means to merge 99% of the logic inside ir-keytable into the evdev generic tool. Or just have an utility producing keymap name and feed it as input to the generic tools. The way most of utilities work... I don't like the idea of running a some logic at udev that would generate such keymap in runtime just before calling the generic tool. The other Why? You'd just call something like: keymap $name `rc-keymap-name -d $name` where 'keymap' is udev's utility and 'rc-keymap-name' is new utility that incorporates map selection logic currently found in rc-keytable. It looks like format of the keymaps is compatible between 'keymap' and 'ir-keytable' and metadata that is present in your keymaps will not confuse 'keymap' utility. The format is, currently compatible. However, we'll likely need to change it (or to allow the tool to handle also a different format), due to some reasons: 1) Protocol and the device name where it is found by default is currently a comment; 2) We'll need to add a field there specifying the number of the bits to be used by the keymap table, in order to use the proper length with _V2 ioctls; 3) There are
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On Fri, Jan 28, 2011 at 04:15:51PM -0200, Mauro Carvalho Chehab wrote: Em 28-01-2011 15:33, Dmitry Torokhov escreveu: On Fri, Jan 28, 2011 at 03:01:58PM -0200, Mauro Carvalho Chehab wrote: Em 28-01-2011 14:40, Dmitry Torokhov escreveu: On Fri, Jan 28, 2011 at 09:55:58AM -0200, Mauro Carvalho Chehab wrote: The rc-core register (and the corresponding input register) is done when the device detected a remote controller, so, it should be safe to register on that point. If not, IMHO, there's a bug somewhere. It is not a matter of safe or unsafe registration. Registration is fine. The problem is that with the current set up is that utility is fired when trunk of [sub]tree is created, but the utility wants to operate on leaves which may not be there yet. I'm not an udev expert. Is there a udev event that hits only after having the driver completely loaded? Define completely loaded? For a PCI SCSI controller does fully loaded mean all attached devices are discovered and registered with block layer? For a wireless NIC does it mean that it assocuated with an AP? What if you have more than one device that driver serves? So teh answer is no and there should not be. Starting an udev rule while modprobe is still running is asking for race conditions. Not if we write stuff properly. I'm not entirely convinced that this is the bug that Mark is hitting, as I do not know yet. rc-core does all needed setups before registering the evdev device. We need the core and the dmesg to be sure about what's happening there. I will say it again. Your udev rule triggers when you create rcX device. eventX device may apeear 2 hours after that (I could have evdev as a module and blacklisted and load it later manually). Blacklisting it won't (or shouldn't work). From rc-main, the registering sequence is: dev_set_name(dev-dev, rc%ld, dev-devno); dev_set_drvdata(dev-dev, dev); rc = device_add(dev-dev); if (rc) return rc; rc = ir_setkeytable(dev, rc_map); if (rc) goto out_dev; dev-input_dev-dev.parent = dev-dev; memcpy(dev-input_dev-id, dev-input_id, sizeof(dev-input_id)); dev-input_dev-phys = dev-input_phys; dev-input_dev-name = dev-input_name; rc = input_register_device(dev-input_dev); if (rc) goto out_table; rc-main will wait for input_register_device() to finish, so even if you blacklist it, rc-core will load it, in order to solve the symbol dependency. No, input_register_device() and input core itself does not have symbol dependency on evdev (which provides /dev/input/eventX), which is just an input handler. A very important, but still an optional, handler. Btw, there's really a race issue there: device_add is happening before input_register_device(), so the udev rule will cause troubles. That's what I have been saying in the last 3+ emails, yes. You need to split it into 2 separate steps: 1. Triggers when rcX appears, accesses only rcX and it's parents and does rcX related stuff. 2. Triggers when eventX appears and loads keymap and what not. Because it is a child of rcX (in specific case of remotes) it may examine rcX attributes as well. The fix is probably simpler: we need to change the udev rules to work at evdev registration and only if the device is a remote controller. This should solve the current issue. The problem I have with it is that it violates layering. You affect different subsystems/layers, why do you insist on jamming them togetehr? Don't do the kitchen sink style, pretty please. Yet, I agree that udev tries to set devices too fast. It tries to set devices exacty when you tell it to do so. It's not like it goes trolling for random devices is sysfs. It would be better if it would wait for a few milisseconds, to reduce the risk of race conditions. Gah, I really prefer using properly engineered solutions instead of adding crutches. I agree. And this could be easily added to the udev's keymap utility that is fired up when we discover evdevX devices. Yes, it can, if you add the IR protocol selection on that tool. A remote controller keycode table has both the protocol and the keycodes. This basically means to merge 99% of the logic inside ir-keytable into the evdev generic tool. Or just have an utility producing keymap name and feed it as input to the generic tools. The way most of utilities work... I don't like the idea of running a some logic at udev that would generate such keymap in runtime just before calling the generic tool. The other Why? You'd just call something like: keymap $name `rc-keymap-name -d $name` where 'keymap' is udev's utility and 'rc-keymap-name' is new utility that incorporates map selection logic currently found in rc-keytable. It looks
RE: DM6446
1) Is your driver for ASUS TV tuner right? 2) tvtime ( http://tvtime.sourceforge.net/ ) may work for you better, as it's designed for TV tuner type of capture cards. 3) For V4L/V4L2 compliance test, I like Xawtv better (personally). Though it's old, it's mature and stable. Best regards, Charlie X. Liu @ Sensoray Co. -Original Message- From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-boun...@redhat.com] On Behalf Of Phillip Pi Sent: Friday, January 28, 2011 9:36 AM To: video4linux-l...@redhat.com Subject: Re: DM6446 Wow, these are old. Did Xawtv project die or something? Is there an updated fork or anything? I never got my old ASUS TV tuner to work with it. :( On Fri, Jan 28, 2011 at 11:25:48AM -0600, char...@sensoray.com wrote: It's in: http://rbytes.net/linux/xawtv-review/ http://linux.wareseeker.com/Multimedia/xawtv-3.95.zip/322997 http://nixbit.com/cat/multimedia/video/xawtv/ Does any one has resources/source of XAWTV ?! -- Quote of the Week: A coconut shell full of water is a(n) sea/ocean to an ant. --Indians /\___/\ Phil./Ant @ http://antfarm.ma.cx (Personal Web Site) / /\ /\ \ Ant's Quality Foraged Links: http://aqfl.net | |o o| | E-mail: phi...@earthlink.net/a...@zimage.com \ _ / If crediting, then please kindly use Ant nickname ( ) and AQFL URL/link. -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list -- 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 RFC] uvcvideo: Add support for MPEG-2 TS payload
Parse the UVC 1.0 and UVC 1.1 VS_FORMAT_MPEG2TS descriptors.
This a stream based format, so we generate a dummy frame descriptor
with a dummy frame interval range.
---
drivers/media/video/uvc/uvc_driver.c | 41 ++
drivers/media/video/uvc/uvcvideo.h |3 ++
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index a1e9dfb..6bcb9e1 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -103,6 +103,11 @@ static struct uvc_format_desc uvc_fmts[] = {
.guid = UVC_GUID_FORMAT_BY8,
.fcc= V4L2_PIX_FMT_SBGGR8,
},
+ {
+ .name = MPEG2 TS,
+ .guid = UVC_GUID_FORMAT_MPEG,
+ .fcc= V4L2_PIX_FMT_MPEG,
+ },
};
/*
@@ -398,6 +403,33 @@ static int uvc_parse_format(struct uvc_device *dev,
break;
case UVC_VS_FORMAT_MPEG2TS:
+ n = dev-uvc_version = 0x0110 ? 23 : 7;
+ if (buflen n) {
+ uvc_trace(UVC_TRACE_DESCR, device %d videostreaming
+ interface %d FORMAT error\n,
+ dev-udev-devnum,
+ alts-desc.bInterfaceNumber);
+ return -EINVAL;
+ }
+
+ strlcpy(format-name, MPEG2 TS, sizeof format-name);
+ format-fcc = V4L2_PIX_FMT_MPEG;
+ format-flags = UVC_FMT_FLAG_COMPRESSED | UVC_FMT_FLAG_STREAM;
+ format-bpp = 0;
+ ftype = 0;
+
+ /* Create a dummy frame descriptor. */
+ frame = format-frame[0];
+ memset(format-frame[0], 0, sizeof format-frame[0]);
+ frame-bFrameIntervalType = 0;
+ frame-dwDefaultFrameInterval = 1;
+ frame-dwFrameInterval = *intervals;
+ *(*intervals)++ = 1;
+ *(*intervals)++ = 1000;
+ *(*intervals)++ = 1;
+ format-nframes = 1;
+ break;
+
case UVC_VS_FORMAT_STREAM_BASED:
/* Not supported yet. */
default:
@@ -673,6 +705,14 @@ static int uvc_parse_streaming(struct uvc_device *dev,
break;
case UVC_VS_FORMAT_MPEG2TS:
+ /* MPEG2TS format has no frame descriptor. We will
create a
+* dummy frame descriptor with a dummy frame interval
range.
+*/
+ nformats++;
+ nframes++;
+ nintervals += 3;
+ break;
+
case UVC_VS_FORMAT_STREAM_BASED:
uvc_trace(UVC_TRACE_DESCR, device %d videostreaming
interface %d FORMAT %u is not supported.\n,
@@ -724,6 +764,7 @@ static int uvc_parse_streaming(struct uvc_device *dev,
switch (buffer[2]) {
case UVC_VS_FORMAT_UNCOMPRESSED:
case UVC_VS_FORMAT_MJPEG:
+ case UVC_VS_FORMAT_MPEG2TS:
case UVC_VS_FORMAT_DV:
case UVC_VS_FORMAT_FRAME_BASED:
format-frame = frame;
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 45f01e7..e522f99 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -152,6 +152,9 @@ struct uvc_xu_control {
#define UVC_GUID_FORMAT_BY8 \
{ 'B', 'Y', '8', ' ', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_MPEG \
+ { 'M', 'P', 'E', 'G', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
/*
* Driver specific constants.
--
1.7.3.5
--
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 RFC] uvcvideo: Add a mapping for H.264 payloads
Associate the H.264 GUID with an H.264 pixel format so that frame
and stream based format descriptors with this GUID are recognized
by the UVC video driver.
---
drivers/media/video/uvc/uvc_driver.c |5 +
drivers/media/video/uvc/uvcvideo.h |3 +++
include/linux/videodev2.h|1 +
3 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index 6bcb9e1..a5a86ce 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -108,6 +108,11 @@ static struct uvc_format_desc uvc_fmts[] = {
.guid = UVC_GUID_FORMAT_MPEG,
.fcc= V4L2_PIX_FMT_MPEG,
},
+ {
+ .name = H.264,
+ .guid = UVC_GUID_FORMAT_H264,
+ .fcc= V4L2_PIX_FMT_H264,
+ },
};
/*
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index e522f99..4f65ac6 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -155,6 +155,9 @@ struct uvc_xu_control {
#define UVC_GUID_FORMAT_MPEG \
{ 'M', 'P', 'E', 'G', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_H264 \
+ { 'H', '2', '6', '4', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
/*
* Driver specific constants.
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 5f6f470..d3b5877 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -341,6 +341,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG
*/
#define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /* 1394
*/
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
*/
+#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H.264 Annex-B
NAL Units */
/* Vendor-specific formats */
#define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
--
1.7.3.5
--
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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Dmitry / Mauro, I'm encouraged by all of the good dialog happening here, and regret that I am unable to poke any further at the issue with ir-keytable for now. The system in question is now getting rebuilt with new/modern userspace, and I expect the original issue to vanish as a result. If I do see ir-keytable acting up again afterward, I'll let you know. But it will be whatever version Ubuntu 10.10 installs, not the newer one I used earlier in this thread. Cheers! -Mark -- 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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-28 11:42 AM, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 11:53:25AM -0800, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 01:12:48PM -0500, Mark Lord wrote: On 11-01-27 11:39 AM, Dmitry Torokhov wrote: .. Hmm, what about compiling with debug and getting a core then? Sure. debug is easy, -g, but you'll have to tell me how to get it do produce a core dump. See if adjusting /etc/security/limits.conf will enable it to dump core. Otherwise you'll have to stick 'ulimit -c unlimited' somewhere... .. Any luck with getting the core? I'd really like to resolve this issue. .. I'm upgrading the box to new userspace now. But I still have the old installation drive, so perhaps I'll go there now and try this. My plan is to replace /usr/bin/ir-keytable with a script that issues the 'ulimit -c unlimited' command and then invokes the original /usr/bin/ir-keytable binary. Should take half an hour or so before I get back here again. -ml -- 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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-28 03:55 PM, Mark Lord wrote: On 11-01-28 11:42 AM, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 11:53:25AM -0800, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 01:12:48PM -0500, Mark Lord wrote: On 11-01-27 11:39 AM, Dmitry Torokhov wrote: .. Hmm, what about compiling with debug and getting a core then? Sure. debug is easy, -g, but you'll have to tell me how to get it do produce a core dump. See if adjusting /etc/security/limits.conf will enable it to dump core. Otherwise you'll have to stick 'ulimit -c unlimited' somewhere... .. Any luck with getting the core? I'd really like to resolve this issue. .. I'm upgrading the box to new userspace now. But I still have the old installation drive, so perhaps I'll go there now and try this. My plan is to replace /usr/bin/ir-keytable with a script that issues the 'ulimit -c unlimited' command and then invokes the original /usr/bin/ir-keytable binary. Should take half an hour or so before I get back here again. No-go. According to the syslog, the segfault has not happened since I reconfigured the kernel and startup sequence two days ago to resolve an XFS mount issue. Something in there changed the init timing just enough to make it go away, I believe. Now I'm blowing it all away in favour of fresh userspace, with a whole new set of issues to resolve. :) Off-Topic: Ubuntu (Mythbuntu) really has a ton of timing issues with this upstart thing at startup and shutdown.. running from an SSD really exposes the flaws. Cheers -- 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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On Fri, Jan 28, 2011 at 04:03:07PM -0500, Mark Lord wrote: On 11-01-28 03:55 PM, Mark Lord wrote: On 11-01-28 11:42 AM, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 11:53:25AM -0800, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 01:12:48PM -0500, Mark Lord wrote: On 11-01-27 11:39 AM, Dmitry Torokhov wrote: .. Hmm, what about compiling with debug and getting a core then? Sure. debug is easy, -g, but you'll have to tell me how to get it do produce a core dump. See if adjusting /etc/security/limits.conf will enable it to dump core. Otherwise you'll have to stick 'ulimit -c unlimited' somewhere... .. Any luck with getting the core? I'd really like to resolve this issue. .. I'm upgrading the box to new userspace now. But I still have the old installation drive, so perhaps I'll go there now and try this. My plan is to replace /usr/bin/ir-keytable with a script that issues the 'ulimit -c unlimited' command and then invokes the original /usr/bin/ir-keytable binary. Should take half an hour or so before I get back here again. No-go. According to the syslog, the segfault has not happened since I reconfigured the kernel and startup sequence two days ago to resolve an XFS mount issue. Something in there changed the init timing just enough to make it go away, I believe. OK, this reinforces my suspicion that the cause of segfault is the race we were discussing with Mauro, not the keymap retrieval fix. I shall be sending the patch to Linus/stable in the next pull then. Thank you for your help. -- Dmitry -- 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: omap3-isp segfault
On 1/27/2011 2:44 PM, Neil MacMunn wrote: When I use media-ctl the pipeline gets configured properly. I can generate graphs before and after and see the pipeline change. However, my system hangs when I attempt to use yavta. I've also tried outputting to video4. Does anybody know how I can capture images from the camera? From previous posts it appears that I'm not the first to go through this process. Thanks. Neil A few questions that would help to diagnose problems: What version of the ISP drivers and the MT9V032 driver are you using? Kernel version? You could try to force the format on the gst-launch command, as a further test, although I don't know why it's not matching up to the YUVY format you configured in the pipeline. Eino-Ville Talvala Stanford University -- 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: omap3-isp segfault
A few questions that would help to diagnose problems: What version of the ISP drivers and the MT9V032 driver are you using? Kernel version? I'm using the ISP drivers and MT9V032 driver from git://linuxtv.org/pinchartl/media.git head=media-0006-sensors. My kernel is 2.6.36. You could try to force the format on the gst-launch command, as a further test, although I don't know why it's not matching up to the YUVY format you configured in the pipeline. Eino-Ville Talvala Stanford University -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message tomajord...@vger.kernel.org More majordomo info athttp://vger.kernel.org/majordomo-info.html This is my setup script: #!/bin/sh ./media-ctl -r; ./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]'; ./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]'; ./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]'; ./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'; ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]'; ./media-ctl -f 'OMAP3 ISP CCDC:2[SGRBG10 752x480]'; ./media-ctl -f 'OMAP3 ISP preview:0[SGRBG10 752x480]'; ./media-ctl -f 'OMAP3 ISP preview:1[YUYV 752x480]'; ./media-ctl -f 'OMAP3 ISP resizer:1[YUYV 1024x768]'; Which gives me: # ./config_camera Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:2 - 7:0 [1] Setting up link 7:1 - 10:0 [1] Setting up link 10:1 - 12:0 [1] Setting up format SGRBG10 752x480 on pad mt9v032 3-005c/0 Format set: SGRBG10 752x480 Setting up format SGRBG10 752x480 on pad OMAP3 ISP CCDC/0 Format set: SGRBG10 752x480 Setting up format SGRBG10 752x480 on pad OMAP3 ISP CCDC/2 Format set: SGRBG10 752x479 Setting up format SGRBG10 752x479 on pad OMAP3 ISP preview/0 Format set: SGRBG10 752x479 Setting up format SGRBG10 752x479 on pad OMAP3 ISP AEWB/0 Unable to set format: Invalid argument (-22) Setting up format SGRBG10 752x479 on pad OMAP3 ISP AF/0 Unable to set format: Invalid argument (-22) Setting up format SGRBG10 752x479 on pad OMAP3 ISP histogram/0 Unable to set format: Invalid argument (-22) Setting up format SGRBG10 752x480 on pad OMAP3 ISP preview/0 Format set: SGRBG10 752x480 Setting up format YUYV 752x480 on pad OMAP3 ISP preview/1 Format set: YUYV 734x472 Setting up format YUYV 734x472 on pad OMAP3 ISP resizer/0 Format set: YUYV 734x472 Setting up format YUYV 1024x768 on pad OMAP3 ISP resizer/1 Format set: YUYV 1024x768 And herein lies the problem: root@overo:~# ./yavta --enum-formats /dev/video2 Device /dev/video2 opened: OMAP3 ISP CCDC output (media). - Available formats: Video format: () 0x0 root@overo:~# ./yavta --enum-formats /dev/video4 Device /dev/video4 opened: OMAP3 ISP preview output (media). - Available formats: Video format: () 0x0 root@overo:~# ./yavta --enum-formats /dev/video6 Device /dev/video6 opened: OMAP3 ISP resizer output (media). - Available formats: Video format: () 0x0 Not sure whether this is a driver problem or... -- 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 driver for TerraTec H7 - how do I install them?
Update: On Wed, Jan 26, 2011 at 6:35 PM, Bjørn Mork bj...@mork.no wrote: Sure is. But even if you get past the build errors, you'll soon discover that Terratec forgot to include the necessary firmware as well. You can find it and some other hints in this thread: http://www.vdr-portal.de/board/thread.php?threadid=103040 I just installed yaVDR 0.3.0 on a machine and connected the TerraTec H7 to it, in the hope that the necessary drivers was included with yaVDR already (I'm not very good at reading german). Yes, I did copy the firmware to /lib/firmware first. Unfortunately, it doesn't look like the drivers for H7 are included. I have now posted a question on the vdr-portal.de forum, I'll post here if it leads to anything. -- Regards, Torfinn Ingolfsen -- 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/RFC 2/3] V4L: soc-camera: convert to videobuf2
Convert soc-camera core to the videobuf2 API.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/soc_camera.c | 53 +
include/media/soc_camera.h | 10 ---
3 files changed, 37 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index ce3555a..15515d9 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -749,7 +749,7 @@ config VIDEO_NOON010PC30
config SOC_CAMERA
tristate SoC camera support
depends on VIDEO_V4L2 HAS_DMA I2C
- select VIDEOBUF_GEN
+ select VIDEOBUF2_CORE
help
SoC Camera is a common API to several cameras, not connecting
over a bus like PCI or USB. For example some i2c camera connected
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index a66811b..c451493 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -33,7 +33,7 @@
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
#include media/v4l2-dev.h
-#include media/videobuf-core.h
+#include media/videobuf2-core.h
#include media/soc_mediabus.h
/* Default to VGA resolution */
@@ -196,18 +196,13 @@ static int soc_camera_reqbufs(struct file *file, void
*priv,
{
int ret;
struct soc_camera_device *icd = file-private_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
WARN_ON(priv != file-private_data);
if (icd-streamer icd-streamer != file)
return -EBUSY;
- ret = videobuf_reqbufs(icd-vb_vidq, p);
- if (ret 0)
- return ret;
-
- ret = ici-ops-reqbufs(icd, p);
+ ret = vb2_reqbufs(icd-vb_vidq, p);
if (!ret !icd-streamer)
icd-streamer = file;
@@ -221,7 +216,7 @@ static int soc_camera_querybuf(struct file *file, void
*priv,
WARN_ON(priv != file-private_data);
- return videobuf_querybuf(icd-vb_vidq, p);
+ return vb2_querybuf(icd-vb_vidq, p);
}
static int soc_camera_qbuf(struct file *file, void *priv,
@@ -234,7 +229,7 @@ static int soc_camera_qbuf(struct file *file, void *priv,
if (icd-streamer != file)
return -EBUSY;
- return videobuf_qbuf(icd-vb_vidq, p);
+ return vb2_qbuf(icd-vb_vidq, p);
}
static int soc_camera_dqbuf(struct file *file, void *priv,
@@ -247,7 +242,7 @@ static int soc_camera_dqbuf(struct file *file, void *priv,
if (icd-streamer != file)
return -EBUSY;
- return videobuf_dqbuf(icd-vb_vidq, p, file-f_flags O_NONBLOCK);
+ return vb2_dqbuf(icd-vb_vidq, p, file-f_flags O_NONBLOCK);
}
/* Always entered with .video_lock held */
@@ -363,8 +358,8 @@ static int soc_camera_set_fmt(struct soc_camera_device *icd,
icd-user_width = pix-width;
icd-user_height= pix-height;
icd-colorspace = pix-colorspace;
- icd-vb_vidq.field =
- icd-field = pix-field;
+// icd-vb_vidq.field =
+ icd-field = pix-field;
if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
dev_warn(icd-dev, Attention! Wrong buf-type %d\n,
@@ -444,7 +439,9 @@ static int soc_camera_open(struct file *file)
if (ret 0)
goto esfmt;
- ici-ops-init_videobuf(icd-vb_vidq, icd);
+ ret = ici-ops-init_videobuf(icd-vb_vidq, icd);
+ if (ret 0)
+ goto einitvb;
}
file-private_data = icd;
@@ -456,6 +453,7 @@ static int soc_camera_open(struct file *file)
* First four errors are entered with the .video_lock held
* and use_count == 1
*/
+einitvb:
esfmt:
pm_runtime_disable(icd-vdev-dev);
eresume:
@@ -482,6 +480,7 @@ static int soc_camera_close(struct file *file)
pm_runtime_disable(icd-vdev-dev);
ici-ops-remove(icd);
+ vb2_queue_release(icd-vb_vidq);
soc_camera_power_set(icd, icl, 0);
}
@@ -517,7 +516,7 @@ static int soc_camera_mmap(struct file *file, struct
vm_area_struct *vma)
if (icd-streamer != file)
return -EBUSY;
- err = videobuf_mmap_mapper(icd-vb_vidq, vma);
+ err = vb2_mmap(icd-vb_vidq, vma);
dev_dbg(icd-dev, vma start=0x%08lx, size=%ld, ret=%d\n,
(unsigned long)vma-vm_start,
@@ -535,14 +534,23 @@ static unsigned int soc_camera_poll(struct file *file,
poll_table *pt)
if (icd-streamer != file)
return -EBUSY;
- if (list_empty(icd-vb_vidq.stream)) {
- dev_err(icd-dev, Trying to poll with no queued buffers!\n);
- return POLLERR;
- }
-
return ici-ops-poll(file, pt);
}
+void soc_camera_lock(struct vb2_queue *vq)
+{
+ struct
[PATCH 1/3] V4L: add missing EXPORT_SYMBOL* statements to vb2
videobuf2-memops and videobuf2-core can be compiled as modules, in which case 3 more symbols from videobuf2-memops.c have to be exported. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/media/video/videobuf2-memops.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/videobuf2-memops.c b/drivers/media/video/videobuf2-memops.c index 053c157..a3eb656 100644 --- a/drivers/media/video/videobuf2-memops.c +++ b/drivers/media/video/videobuf2-memops.c @@ -77,6 +77,7 @@ void vb2_put_vma(struct vm_area_struct *vma) kfree(vma); } +EXPORT_SYMBOL_GPL(vb2_put_vma); /** * vb2_get_contig_userptr() - lock physically contiguous userspace mapped memory @@ -141,6 +142,7 @@ done: up_read(mm-mmap_sem); return ret; } +EXPORT_SYMBOL_GPL(vb2_get_contig_userptr); /** * vb2_mmap_pfn_range() - map physical pages to userspace @@ -180,6 +182,7 @@ int vb2_mmap_pfn_range(struct vm_area_struct *vma, unsigned long paddr, return 0; } +EXPORT_SYMBOL_GPL(vb2_mmap_pfn_range); /** * vb2_common_vm_open() - increase refcount of the vma -- 1.7.2.3 -- 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/RFC 3/3] V4L: sh_mobile_ceu_camera: convert to videobuf2
Convert the sh_mobile_ceu_camera driver to the videobuf2 API.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/Kconfig|2 +-
drivers/media/video/sh_mobile_ceu_camera.c | 249
2 files changed, 104 insertions(+), 147 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 15515d9..ee9fb70 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -876,7 +876,7 @@ config VIDEO_SH_MOBILE_CSI2
config VIDEO_SH_MOBILE_CEU
tristate SuperH Mobile CEU Interface driver
depends on VIDEO_DEV SOC_CAMERA HAS_DMA HAVE_CLK
- select VIDEOBUF_DMA_CONTIG
+ select VIDEOBUF2_DMA_CONTIG
---help---
This is a v4l2 driver for the SuperH Mobile CEU Interface
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 954222b..4f84754 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -38,7 +38,7 @@
#include media/v4l2-dev.h
#include media/soc_camera.h
#include media/sh_mobile_ceu.h
-#include media/videobuf-dma-contig.h
+#include media/videobuf2-dma-contig.h
#include media/v4l2-mediabus.h
#include media/soc_mediabus.h
@@ -87,7 +87,8 @@
/* per video frame buffer */
struct sh_mobile_ceu_buffer {
- struct videobuf_buffer vb; /* v4l buffer must be first */
+ struct vb2_buffer vb; /* v4l buffer must be first */
+ struct list_head queue;
enum v4l2_mbus_pixelcode code;
};
@@ -102,13 +103,15 @@ struct sh_mobile_ceu_dev {
/* lock used to protect videobuf */
spinlock_t lock;
struct list_head capture;
- struct videobuf_buffer *active;
+ struct vb2_buffer *active;
+ struct vb2_alloc_ctx *alloc_ctx;
struct sh_mobile_ceu_info *pdata;
u32 cflcr;
enum v4l2_field field;
+ int sequence;
unsigned int image_mode:1;
unsigned int is_16bit:1;
@@ -133,6 +136,11 @@ struct sh_mobile_ceu_cam {
enum v4l2_mbus_pixelcode code;
};
+static struct sh_mobile_ceu_buffer *to_ceu_vb(struct vb2_buffer *vb)
+{
+ return container_of(vb, struct sh_mobile_ceu_buffer, vb);
+}
+
static unsigned long make_bus_param(struct sh_mobile_ceu_dev *pcdev)
{
unsigned long flags;
@@ -205,11 +213,11 @@ static int sh_mobile_ceu_soft_reset(struct
sh_mobile_ceu_dev *pcdev)
/*
* Videobuf operations
*/
-static int sh_mobile_ceu_videobuf_setup(struct videobuf_queue *vq,
- unsigned int *count,
- unsigned int *size)
+static int sh_mobile_ceu_videobuf_setup(struct vb2_queue *vq,
+ unsigned int *count, unsigned int *num_planes,
+ unsigned long sizes[], void *alloc_ctxs[])
{
- struct soc_camera_device *icd = vq-priv_data;
+ struct soc_camera_device *icd = container_of(vq, struct
soc_camera_device, vb_vidq);
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
struct sh_mobile_ceu_dev *pcdev = ici-priv;
int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
@@ -218,39 +226,25 @@ static int sh_mobile_ceu_videobuf_setup(struct
videobuf_queue *vq,
if (bytes_per_line 0)
return bytes_per_line;
- *size = bytes_per_line * icd-user_height;
+ *num_planes = 1;
- if (0 == *count)
+ pcdev-sequence = 0;
+ sizes[0] = bytes_per_line * icd-user_height;
+ alloc_ctxs[0] = pcdev-alloc_ctx;
+
+ if (!*count)
*count = 2;
if (pcdev-video_limit) {
- if (PAGE_ALIGN(*size) * *count pcdev-video_limit)
- *count = pcdev-video_limit / PAGE_ALIGN(*size);
+ if (PAGE_ALIGN(sizes[0]) * *count pcdev-video_limit)
+ *count = pcdev-video_limit / PAGE_ALIGN(sizes[0]);
}
- dev_dbg(icd-dev.parent, count=%d, size=%d\n, *count, *size);
+ dev_dbg(icd-dev.parent, count=%d, size=%lu\n, *count, sizes[0]);
return 0;
}
-static void free_buffer(struct videobuf_queue *vq,
- struct sh_mobile_ceu_buffer *buf)
-{
- struct soc_camera_device *icd = vq-priv_data;
- struct device *dev = icd-dev.parent;
-
- dev_dbg(dev, %s (vb=0x%p) 0x%08lx %zd\n, __func__,
- buf-vb, buf-vb.baddr, buf-vb.bsize);
-
- if (in_interrupt())
- BUG();
-
- videobuf_waiton(vq, buf-vb, 0, 0);
- videobuf_dma_contig_free(vq, buf-vb);
- dev_dbg(dev, %s freed\n, __func__);
- buf-vb.state = VIDEOBUF_NEEDS_INIT;
-}
-
#define CEU_CETCR_MAGIC 0x0317f313 /* acknowledge magical interrupt sources */
#define CEU_CETCR_IGRW (1 4) /* prohibited register access interrupt bit */
#define CEU_CEIER_CPEIE (1 0) /* one-frame capture end interrupt */
@@ -309,7 +303,10
[PATCH] Input: rc-keymap - return KEY_RESERVED for unknown mappings
Do not respond with -EINVAL to EVIOCGKEYCODE for not-yet-mapped scancodes,
but rather return KEY_RESERVED.
This fixes breakage with Ubuntu's input-kbd utility that stopped returning
full keymaps for remote controls.
Tested-by: Mauro Carvalho Chehab mche...@redhat.com
Tested-by: Mark Lord ker...@teksavvy.com
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
Linus,
Due to the fact that contents of drivers/media in my 'for-linus' branch
are quite different from mainline/Mauro's trees and I am not planning on
merging this branch until closer to the next merge window I am sending
this regression fix in patch form instead of pull request.
Please consider applying.
Thanks,
Dmitry
drivers/media/rc/rc-main.c | 28 +---
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 72be8a0..512a2f4 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -458,21 +458,27 @@ static int ir_getkeycode(struct input_dev *idev,
index = ir_lookup_by_scancode(rc_map, scancode);
}
- if (index = rc_map-len) {
- if (!(ke-flags INPUT_KEYMAP_BY_INDEX))
- IR_dprintk(1, unknown key for scancode 0x%04x\n,
- scancode);
+ if (index rc_map-len) {
+ entry = rc_map-scan[index];
+
+ ke-index = index;
+ ke-keycode = entry-keycode;
+ ke-len = sizeof(entry-scancode);
+ memcpy(ke-scancode, entry-scancode, sizeof(entry-scancode));
+
+ } else if (!(ke-flags INPUT_KEYMAP_BY_INDEX)) {
+ /*
+* We do not really know the valid range of scancodes
+* so let's respond with KEY_RESERVED to anything we
+* do not have mapping for [yet].
+*/
+ ke-index = index;
+ ke-keycode = KEY_RESERVED;
+ } else {
retval = -EINVAL;
goto out;
}
- entry = rc_map-scan[index];
-
- ke-index = index;
- ke-keycode = entry-keycode;
- ke-len = sizeof(entry-scancode);
- memcpy(ke-scancode, entry-scancode, sizeof(entry-scancode));
-
retval = 0;
out:
--
1.7.3.5
--
Dmitry
--
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
