Re: how can deal with the stream in only on-the-fly-output available HW block??
Hi Kim, On Tuesday 14 September 2010 07:11:29 Kim, HeungJun wrote: [snip] You probably need the upcoming media API to be able to correctly deal with these issues. Check the mailing list for the patches done by Laurent Pinchart. The current V4L2 API is really not able to handle changes in the internal video stream topology. Thanks to Hans. It's very helpful. I'll check Laurent's media topology patches. Hello, Laurent, I'm googling and find your patches, so I'm checking with. But, where can I get your patches?? Probably, I would find in this page : http://git.linuxtv.org/, so what's your repository? Clone http://git.linuxtv.org/pinchartl/media.git and checkout the media-0003- subdev-pad branch. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux V4L2 support dual stream video capture device
Hi Theodore, On Monday 13 September 2010 19:17:48 Theodore Kilgore wrote: On Mon, 13 Sep 2010, Laurent Pinchart wrote: On Friday 07 May 2010 20:20:38 Wang, Wen W wrote: Hi all, I'm wondering if V4L2 framework supports dual stream video capture device that transfer a preview stream and a regular stream (still capture or video capture) at the same time. We are developing a device driver with such capability. Our proposal to do this in V4L2 framework is to have two device nodes, one as primary node for still/video capture and one for preview. If the device supports multiple simultaneous video streams, multiple video nodes is the way to go. The primary still/video capture device node is used for device configuration which can be compatible with open sourced applications. This will ensure the normal V4L2 application can run without code modification. Device node for preview will only accept preview buffer related operations. Buffer synchronization for still/video capture and preview will be done internally in the driver. I suspect that the preview device node will need to support more than the buffer-related operations, as you probably want applications to configure the preview video stream format and size. This is our initial idea about the dual stream support in V4L2. Your comments will be appreciated! You should use the media controller framework. This will allow applications to configure all sizes in the pipeline, including the frame sizes for the two video nodes. Hi, Wen, You have hit upon an old and rather vexing problem. It affects many devices, not just your prospective one. The problem is that still mode is supported in Linux for a lot of cameras through userspace tools, namely libgphoto2 which uses libusb to interface with the device. But if the same device can also do video streaming then the streaming has to be supported through a kernel module. Thus until now it is not possible to do both of these smoothly and simultaneously. As I have written both the kernel support and the libgphoto2 support for several dual-mode cameras, I am looking into the related problems, along with Hans de Goede. But right now I am dealing instead with a rather severe illness of a family member. So there is not much coding going on over here. What I think that both of us (Hans and I) agree on is that the kernel modules for the affected devices have to be rewritten in order to allow the opening and closing of the different modes of the devices, and (perhaps) the userspace support has to take that into account as well. There might also have to be some additions to libv4l2 in order to make it aware of such devices. We have not gotten very far with this project. Hans is quite busy, and so am I (see above). In spite of my present preoccupation, however, I would be very curious about any details of your envisioned camera. For example: Does it use the isochronous mode for streaming and the bulk mode for stills? Or not? There seems to be a small misunderstanding. The device Wen is working on (as far as I'm aware of) isn't a USB device. In still mode, is it some kind of standard device, such as Mass Storage or PTP? Or will it use a proprietary or device-specific protocol? If so, it will clearly require a libgphoto2 driver. In video mode, will it use a proprietary or device-specific protocol, or will it be a standard USB video class device? If it is proprietary, then it will presumably need its own module, and if standard then in any event we have to figure out how to make the two different modes to coexist. If either of the still mode or the streaming video mode will use a proprietary protocol and especially if some unknown data compression algorithm is going to be in use, then clearly it is possible to get the support going much earlier if information is provided. Hoping that this will help you and thanking you for any additional information about the new camera. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: extend video capture example to capture mpeg video file
On Mon, 2010-09-13 at 21:43 -0700, bad boy wrote: Hi Please note, the video4linux-list is about dead; use linux-media@vger.kernel.org instead. I have a Hauppage TV capture card that seems to be working . I can use the cat /dev/video0 test.mpeg to capture a video file to hard disk. I am trying to adapt the video capture example, source capture.c to capture the mpeg file. The example code ins capture.c calls the read_frame() function that then calls process image, which writes a . to the screen. What do I need to modify to capture a proper mpeg file ? If you have a Hauppauge card whose driver supports the read() method and provides MPEG output (ivtv or cx18?), then 'cat /dev/video0' does capture a proper MPEG file to standard output. Drivers that support the read() method, like ivtv and cx18, usually do not support the methods that use mmap(). I'm guessing capture.c uses the one of the mmap() methods, which is a completely different way of reading from a video device node than a read() call. By the time you are done rewriting capture.c, you will end up with something close to cat.c. Your help would be deeply appreciated. $ mplayer /dev/video0 -cache 8192 will display the video and audio as it is captured. Regards, Andy Thanks badam -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v4 00/11] Media controller (core and V4L2)
Hi Mauro, On Thursday 09 September 2010 03:44:15 Mauro Carvalho Chehab wrote: Em 20-08-2010 12:29, Laurent Pinchart escreveu: Hi everybody, Here's the fourth version of the media controller patches. All comments received so far have hopefully been incorporated. Compared to the previous version, the patches have been rebased on top of 2.6.35 and a MEDIA_IOC_DEVICE_INFO ioctl has been added. I won't submit a rebased version of the V4L2 API additions and OMAP3 ISP patches right now. I will first clean up (and document) the V4L2 API additions patches, and I will submit them as a proper RFC instead of sample code. Hi Laurent, Sorry for a late review on the media controller API. I got flooded by patches and other work since the merge window. No worries. I was on holidays last week anyway. Anyway, just finished my review, and sent a per-patch comment for most patches. Thanks. One general comment about it: the userspace API should be documented via DocBook, to be consistent with V4L2 and DVB API specs. I feared so :-) I'll work on it. It should also be clear at the API specs there that not all media drivers will implement the media controller API, I agree. as its main focus is to allow better control of SoC devices, where there are needs to control some intrinsic characteristics of parts of the devices, complementing the V4L2 spec. Some consumer devices (ivtv for instance) will also benefit from the media controller, the API is not specific to SoC devices only. This means that it is needed to add some comments at the kernelspace API doc, saying that the drivers implementing the media controller API are required to work properly even when userspace is not using the media controller API; That's another issue. Drivers should make a best effort to allow pure V4L2 applications to work with a subset of the video device nodes, but they will only offer a subset of the hardware capabilities. For SoC devices it's even worse, it might be way too difficult to implement support for pure V4L2 applications in the kernel driver(s). In that case a device-specific libv4l plugin will configure the driver using the media controller API for pure V4L2 applications. This also means that it is needed to add some comments at the userspace API doc, saying that userspace applications should not assume that media drivers will implement the media controller API. Agreed. Many V4L2 drivers will not implement the media controller API. So, userspace applications implementing the media controller and V4L2 API's are required to work properly if the device doesn't present a media controler API interface. Applications can require support for the media controller API, but they should only do so for specific cases (for instance applications tied to specific SoC hardware, or graphical user interfaces on top of the media controller API similar to qv4l2). It should also say that no driver should just implement the media controller API. I haven't thought about that, as it would be pretty useless :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v4 00/11] Media controller (core and V4L2)
Hi Mauro, On Thursday 09 September 2010 03:44:15 Mauro Carvalho Chehab wrote: Em 20-08-2010 12:29, Laurent Pinchart escreveu: Hi everybody, Here's the fourth version of the media controller patches. All comments received so far have hopefully been incorporated. Compared to the previous version, the patches have been rebased on top of 2.6.35 and a MEDIA_IOC_DEVICE_INFO ioctl has been added. I won't submit a rebased version of the V4L2 API additions and OMAP3 ISP patches right now. I will first clean up (and document) the V4L2 API additions patches, and I will submit them as a proper RFC instead of sample code. Hi Laurent, Sorry for a late review on the media controller API. I got flooded by patches and other work since the merge window. No worries. I was on holidays last week anyway. Anyway, just finished my review, and sent a per-patch comment for most patches. Thanks. One general comment about it: the userspace API should be documented via DocBook, to be consistent with V4L2 and DVB API specs. I feared so :-) I'll work on it. It should also be clear at the API specs there that not all media drivers will implement the media controller API, I agree. as its main focus is to allow better control of SoC devices, where there are needs to control some intrinsic characteristics of parts of the devices, complementing the V4L2 spec. Some consumer devices (ivtv for instance) will also benefit from the media controller, the API is not specific to SoC devices only. This means that it is needed to add some comments at the kernelspace API doc, saying that the drivers implementing the media controller API are required to work properly even when userspace is not using the media controller API; That's another issue. Drivers should make a best effort to allow pure V4L2 applications to work with a subset of the video device nodes, but they will only offer a subset of the hardware capabilities. For SoC devices it's even worse, it might be way too difficult to implement support for pure V4L2 applications in the kernel driver(s). In that case a device-specific libv4l plugin will configure the driver using the media controller API for pure V4L2 applications. This also means that it is needed to add some comments at the userspace API doc, saying that userspace applications should not assume that media drivers will implement the media controller API. Agreed. Many V4L2 drivers will not implement the media controller API. So, userspace applications implementing the media controller and V4L2 API's are required to work properly if the device doesn't present a media controler API interface. Applications can require support for the media controller API, but they should only do so for specific cases (for instance applications tied to specific SoC hardware, or graphical user interfaces on top of the media controller API similar to qv4l2). It should also say that no driver should just implement the media controller API. I haven't thought about that, as it would be pretty useless :-) I actually think that it should be possible without too much effort to make the media API available automatically for those drivers that do not implement it themselves. For the standard drivers it basically just has to enumerate what is already known. It would help a lot with apps like MythTV that want to find related devices (e.g. audio/video/vbi). Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v4 00/11] Media controller (core and V4L2)
Em 14-09-2010 09:25, Laurent Pinchart escreveu: Hi Mauro, On Thursday 09 September 2010 03:44:15 Mauro Carvalho Chehab wrote: Em 20-08-2010 12:29, Laurent Pinchart escreveu: Hi everybody, Here's the fourth version of the media controller patches. All comments received so far have hopefully been incorporated. Compared to the previous version, the patches have been rebased on top of 2.6.35 and a MEDIA_IOC_DEVICE_INFO ioctl has been added. I won't submit a rebased version of the V4L2 API additions and OMAP3 ISP patches right now. I will first clean up (and document) the V4L2 API additions patches, and I will submit them as a proper RFC instead of sample code. Hi Laurent, Sorry for a late review on the media controller API. I got flooded by patches and other work since the merge window. No worries. I was on holidays last week anyway. Anyway, just finished my review, and sent a per-patch comment for most patches. Thanks. One general comment about it: the userspace API should be documented via DocBook, to be consistent with V4L2 and DVB API specs. I feared so :-) I'll work on it. It should also be clear at the API specs there that not all media drivers will implement the media controller API, I agree. as its main focus is to allow better control of SoC devices, where there are needs to control some intrinsic characteristics of parts of the devices, complementing the V4L2 spec. Some consumer devices (ivtv for instance) will also benefit from the media controller, the API is not specific to SoC devices only. I'm still in doubt about adding support for it at not so complex hardware devices. Yes, there are some consumer devices that can benefit on it, like cx25821, where it offers to 16 input/output video streams that can be grouped and changed from input into output (as far as I understood). So, for such devices, yes, it makes sense to use. But a simpler devices that has just one or two stream inputs, alsa and IR, I don't see much sense on using it. This means that it is needed to add some comments at the kernelspace API doc, saying that the drivers implementing the media controller API are required to work properly even when userspace is not using the media controller API; That's another issue. Drivers should make a best effort to allow pure V4L2 applications to work with a subset of the video device nodes, but they will only offer a subset of the hardware capabilities. Ok, but this subset is enough for 99.9% of the cases on non-embedded hardware. For SoC devices it's even worse, it might be way too difficult to implement support for pure V4L2 applications in the kernel driver(s). In that case a device-specific libv4l plugin will configure the driver using the media controller API for pure V4L2 applications. SoC devices used on embedded hardware will have different requirements. I'm ok on having an ancillary open source application to help to set the device, as we've discussed at Helsinki's meeting, but this should be an exception, handled case by case, and not the rule. This also means that it is needed to add some comments at the userspace API doc, saying that userspace applications should not assume that media drivers will implement the media controller API. Agreed. Many V4L2 drivers will not implement the media controller API. So, userspace applications implementing the media controller and V4L2 API's are required to work properly if the device doesn't present a media controler API interface. Applications can require support for the media controller API, but they should only do so for specific cases (for instance applications tied to specific SoC hardware, or graphical user interfaces on top of the media controller API similar to qv4l2). Yes. It should also say that no driver should just implement the media controller API. I haven't thought about that, as it would be pretty useless :-) Well, it doesn't hurt to write it at the spec ;) I won't doubt that people might try to merge bad things, abusing on the api, and later saying that they have an open source driver that it is not open at all. We've seen cases like that in the past, where one open webcam driver used to work only with an specific closed-source userspace application [1]. We need to take extra care with any API that might be used to control devices in raw mode, as we'll never allow any driver to abuse on it to deny open source applications to use it. Cheers, Mauro [1] http://marc.info/?l=linux-kernelm=109356393610149w=2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v4 00/11] Media controller (core and V4L2)
Hi Mauro, On Tuesday 14 September 2010 15:34:26 Mauro Carvalho Chehab wrote: Em 14-09-2010 09:25, Laurent Pinchart escreveu: On Thursday 09 September 2010 03:44:15 Mauro Carvalho Chehab wrote: Em 20-08-2010 12:29, Laurent Pinchart escreveu: Hi everybody, Here's the fourth version of the media controller patches. All comments received so far have hopefully been incorporated. Compared to the previous version, the patches have been rebased on top of 2.6.35 and a MEDIA_IOC_DEVICE_INFO ioctl has been added. I won't submit a rebased version of the V4L2 API additions and OMAP3 ISP patches right now. I will first clean up (and document) the V4L2 API additions patches, and I will submit them as a proper RFC instead of sample code. Hi Laurent, Sorry for a late review on the media controller API. I got flooded by patches and other work since the merge window. No worries. I was on holidays last week anyway. Anyway, just finished my review, and sent a per-patch comment for most patches. Thanks. One general comment about it: the userspace API should be documented via DocBook, to be consistent with V4L2 and DVB API specs. I feared so :-) I'll work on it. It should also be clear at the API specs there that not all media drivers will implement the media controller API, I agree. as its main focus is to allow better control of SoC devices, where there are needs to control some intrinsic characteristics of parts of the devices, complementing the V4L2 spec. Some consumer devices (ivtv for instance) will also benefit from the media controller, the API is not specific to SoC devices only. I'm still in doubt about adding support for it at not so complex hardware devices. Yes, there are some consumer devices that can benefit on it, like cx25821, where it offers to 16 input/output video streams that can be grouped and changed from input into output (as far as I understood). So, for such devices, yes, it makes sense to use. But a simpler devices that has just one or two stream inputs, alsa and IR, I don't see much sense on using it. The media controller API is also used to find out which audio, dvb, fb, ir and v4l devices belong together. Applications such as mythtv are interested in that. This means that it is needed to add some comments at the kernelspace API doc, saying that the drivers implementing the media controller API are required to work properly even when userspace is not using the media controller API; That's another issue. Drivers should make a best effort to allow pure V4L2 applications to work with a subset of the video device nodes, but they will only offer a subset of the hardware capabilities. Ok, but this subset is enough for 99.9% of the cases on non-embedded hardware. Yes, I was thinking about embedded hardware. For SoC devices it's even worse, it might be way too difficult to implement support for pure V4L2 applications in the kernel driver(s). In that case a device-specific libv4l plugin will configure the driver using the media controller API for pure V4L2 applications. SoC devices used on embedded hardware will have different requirements. I'm ok on having an ancillary open source application to help to set the device, as we've discussed at Helsinki's meeting, but this should be an exception, handled case by case, and not the rule. This also means that it is needed to add some comments at the userspace API doc, saying that userspace applications should not assume that media drivers will implement the media controller API. Agreed. Many V4L2 drivers will not implement the media controller API. So, userspace applications implementing the media controller and V4L2 API's are required to work properly if the device doesn't present a media controler API interface. Applications can require support for the media controller API, but they should only do so for specific cases (for instance applications tied to specific SoC hardware, or graphical user interfaces on top of the media controller API similar to qv4l2). Yes. It should also say that no driver should just implement the media controller API. I haven't thought about that, as it would be pretty useless :-) Well, it doesn't hurt to write it at the spec ;) I won't doubt that people might try to merge bad things, abusing on the api, and later saying that they have an open source driver that it is not open at all. We've seen cases like that in the past, where one open webcam driver used to work only with an specific closed-source userspace application [1]. We need to take extra care with any API that might be used to control devices in raw mode, as we'll never allow any driver to abuse on it to deny open source applications to use it. [1] http://marc.info/?l=linux-kernelm=109356393610149w=2 -- Regards, Laurent Pinchart -- To unsubscribe from this list:
Re: [RFC/PATCH v4 00/11] Media controller (core and V4L2)
Hi Hans, On Tuesday 14 September 2010 15:24:41 Hans Verkuil wrote: On Thursday 09 September 2010 03:44:15 Mauro Carvalho Chehab wrote: It should also say that no driver should just implement the media controller API. I haven't thought about that, as it would be pretty useless :-) I actually think that it should be possible without too much effort to make the media API available automatically for those drivers that do not implement it themselves. For the standard drivers it basically just has to enumerate what is already known. It would help a lot with apps like MythTV that want to find related devices (e.g. audio/video/vbi). I think Mauro meant that no driver should implement the media controller API without implementing any other standard API (ALSA, DVB, FB, IR, V4L, ...). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v4 03/11] media: Entities, pads and links
Hi Mauro,
On Thursday 09 September 2010 02:41:54 Mauro Carvalho Chehab wrote:
Em 20-08-2010 12:29, Laurent Pinchart escreveu:
[snip]
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 781c641..eeb002e 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
[snip]
+/**
+ * media_device_register_entity - Register an entity with a media device
+ * @mdev: The media device
+ * @entity:The entity
+ */
+int __must_check media_device_register_entity(struct media_device *mdev,
+ struct media_entity *entity)
+{
+ /* Warn if we apparently re-register an entity */
+ WARN_ON(entity-parent != NULL);
Instead, it should just return -EINVAL and use __must_check.
What's the sense of allowing registering it twice?
It's a driver bug. Entities must not be registered twice. The WARN_ON is meant
as a way to catch driver bugs. I can replace it with a BUG_ON.
[snip]
+EXPORT_SYMBOL(media_entity_init);
Just use EXPORT_SYMBOL_GPL() for all symbols that needs to be exported.
OK.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v4 04/11] media: Entity graph traversal
Hi Mauro,
On Thursday 09 September 2010 02:46:45 Mauro Carvalho Chehab wrote:
Em 20-08-2010 12:29, Laurent Pinchart escreveu:
From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Add media entity graph traversal. The traversal follows active links by
depth first. Traversing graph backwards is prevented by comparing the
next possible entity in the graph with the previous one. Multiply
connected graphs are thus not supported.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Vimarsh Zutshi vimarsh.zut...@nokia.com
---
Documentation/media-framework.txt | 40 +
drivers/media/media-entity.c | 115
+ include/media/media-entity.h
| 15 +
3 files changed, 170 insertions(+), 0 deletions(-)
diff --git a/Documentation/media-framework.txt
b/Documentation/media-framework.txt index 35d74e4..a599824 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -238,3 +238,43 @@ Links have flags that describe the link capabilities
and state.
MEDIA_LINK_FLAG_ACTIVE must also be set since an immutable link is
always active.
+
+Graph traversal
+---
+
+The media framework provides APIs to iterate over entities in a graph.
+
+To iterate over all entities belonging to a media device, drivers can
use the +media_device_for_each_entity macro, defined in
include/media/media-device.h. +
+ struct media_entity *entity;
+
+ media_device_for_each_entity(entity, mdev) {
+ /* entity will point to each entity in turn */
+ ...
+ }
+
+Drivers might also need to iterate over all entities in a graph that can
be +reached only through active links starting at a given entity. The
media +framework provides a depth-first graph traversal API for that
purpose. +
+Note that graphs with cycles (whether directed or undirected) are *NOT*
+supported by the graph traversal API.
Please document that a maximum depth exists to prevent loops, currently
defined as 16 (MEDIA_ENTITY_ENUM_MAX_DEPTH).
Good idea, will do.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: Introduction of M2M capability and buffer types
Hello, Mem2mem devices currently use V4L2_CAP_VIDEO_CAPTURE and V4L2_CAP_VIDEO_OUTPUT capabilities. One might expect that a capture device is a camera and an output device can display images. If I remember correct our discussion during the Helsinki v4l2 summit, Hans de Goede has pointed that such devices are listed in applications and can confuse users. The user expects a camera and he has to choose from a long list of devices. The solution to this would be the introduction of two new capability V4L2_CAP_VIDEO_M2M. Such devices would not be listed when user is expected to choose which webcam or TV tuner device to use. Another thing about m2m devices is the naming of buffers: V4L2_BUF_TYPE_VIDEO_CAPTURE means the destination buffer and V4L2_BUF_TYPE_VIDEO_OUTPUT means source. This indeed is confusing, so I think the introduction of two new buffer types is justified. I would recommend V4L2_BUF_TYPE_M2M_SOURCE and V4L2_BUF_TYPE_M2M_DESTINATION to clearly state what is the buffer's purpose. I would be grateful for your comments to this RFC. Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle independent CA devices
Hi Ralph, On Thu, Sep 09, 2010 at 11:52:25PM +0200, rjkm wrote: cards like the Digital Devices DuoFlex S2, cineS2 and upcoming hardware (octuple, network, etc.) have independent CA devices. This means that instead of having the stream routed from the frontend through the CI and only then into memory a stream can be sent from memory through the CI and back. So, the current device model does not fit this hardware. One could hide this fact inside the driver and send the stream from the frontend through the CI transparently to the API but this would prevent people from implementing new features like decoding a stream from a different DVB card, decoding streams from hard disk or even decoding several sub-streams from different transponders. The latter works with the current Windows driver but I have not implemented it in Linux yet. It also has to be supported by the CI modules. Some can decode 12 streams (6 times video/audio) at once. But decoding single streams already works fine. Currently, I am registering a different adapter for the CI. On a CineS2 with CI attached at the IO port I then have /dev/dvb/adapter[01] for the two DVB-S2 frontends and /dev/dvb/adapter2 just for the ca0 device. I am abusing the unused sec0 to write/read data to/from the CI module. For testing I hacked zap from dvb-apps to tune on adapter0 but use adapter2/ca0 to talk to the CI module. I then write the encrypted stream from adapter0/dvr0 into adapter2/sec0 and read the decoded stream back from adapter2/sec0. The encrypted stream of course has to contain all the PIDs of the ca_pmt. So, I would like to hear your opinions about how to handle such CA devices regarding device names/types, the DVB API and user libraries. it looks like there isn't much interest from DVB developers in that topic... I'll try... IMHO there are three sub topics: 1. be compatible with existing applications (I guess this means: feed stream from frontend through CI transparently) 2. create an API which would also work for CI-only devices like this Hauppauge WinTV-CI USB thingy 3. how to switch between these modes? This sec0 device is history (unused and deprecated for years), right? How about the following: Rename it to ci0. When ci0 is closed the stream is routed transparently from frontend through CI, if it's opened one needs to read/write the stream from userspace. If you can't get responses here I guess you could talk to vdr or other application developers. After all they'll have to use the API. Cheers, Johannes -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux V4L2 support dual stream video capture device
On Tue, 14 Sep 2010, Laurent Pinchart wrote: Hi Theodore, On Monday 13 September 2010 19:17:48 Theodore Kilgore wrote: On Mon, 13 Sep 2010, Laurent Pinchart wrote: On Friday 07 May 2010 20:20:38 Wang, Wen W wrote: Hi all, I'm wondering if V4L2 framework supports dual stream video capture device that transfer a preview stream and a regular stream (still capture or video capture) at the same time. We are developing a device driver with such capability. Our proposal to do this in V4L2 framework is to have two device nodes, one as primary node for still/video capture and one for preview. If the device supports multiple simultaneous video streams, multiple video nodes is the way to go. The primary still/video capture device node is used for device configuration which can be compatible with open sourced applications. This will ensure the normal V4L2 application can run without code modification. Device node for preview will only accept preview buffer related operations. Buffer synchronization for still/video capture and preview will be done internally in the driver. I suspect that the preview device node will need to support more than the buffer-related operations, as you probably want applications to configure the preview video stream format and size. This is our initial idea about the dual stream support in V4L2. Your comments will be appreciated! You should use the media controller framework. This will allow applications to configure all sizes in the pipeline, including the frame sizes for the two video nodes. Hi, Wen, You have hit upon an old and rather vexing problem. It affects many devices, not just your prospective one. The problem is that still mode is supported in Linux for a lot of cameras through userspace tools, namely libgphoto2 which uses libusb to interface with the device. But if the same device can also do video streaming then the streaming has to be supported through a kernel module. Thus until now it is not possible to do both of these smoothly and simultaneously. As I have written both the kernel support and the libgphoto2 support for several dual-mode cameras, I am looking into the related problems, along with Hans de Goede. But right now I am dealing instead with a rather severe illness of a family member. So there is not much coding going on over here. What I think that both of us (Hans and I) agree on is that the kernel modules for the affected devices have to be rewritten in order to allow the opening and closing of the different modes of the devices, and (perhaps) the userspace support has to take that into account as well. There might also have to be some additions to libv4l2 in order to make it aware of such devices. We have not gotten very far with this project. Hans is quite busy, and so am I (see above). In spite of my present preoccupation, however, I would be very curious about any details of your envisioned camera. For example: Does it use the isochronous mode for streaming and the bulk mode for stills? Or not? There seems to be a small misunderstanding. The device Wen is working on (as far as I'm aware of) isn't a USB device. Ah, OK. Put down the misunderstanding to the fact that I am too busy dealing with someone's illness right now, and I seem to have time only for quick skimming of the mail. Sorry. Theodore Kilgore -- 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/RFC v2 0/8] dsbr100: driver cleanup and fixes
Alexey, Can you review/test this patch series? Patches 2/8, 3/8, and 5/8 are bug fixes the rest are mainly cleanups. Patch 2/8 should fix a crash in the normal case if the device is disconnected while not in use. Regards, David Ellingsworth On Thu, May 27, 2010 at 12:39 PM, David Ellingsworth da...@identd.dyndns.org wrote: This patch series addresses several issues in the dsbr100 driver. This series is based on the v4l-dvb master git branch and has been compile tested only. It should be tested before applying. This is the second version of this series. An additional patch has been added to cleanup/clarify the return values from dsbr100_start and dsbr100_stop. The following patches are included in this series: [PATCH/RFC v2 1/8] dsbr100: implement proper locking [PATCH/RFC v2 2/8] dsbr100: fix potential use after free [PATCH/RFC v2 3/8] dsbr100: only change frequency upon success [PATCH/RFC v2 4/8] dsbr100: remove disconnected indicator [PATCH/RFC v2 5/8] dsbr100: cleanup return value of start/stop handlers [PATCH/RFC v2 6/8] dsbr100: properly initialize the radio [PATCH/RFC v2 7/8] dsbr100: cleanup usb probe routine [PATCH/RFC v2 8/8] dsbr100: simplify access to radio device Regards, David Ellingsworth -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 0/8] dsbr100: driver cleanup and fixes
Hi David, On Tue, Sep 14, 2010 at 11:56 AM, David Ellingsworth da...@identd.dyndns.org wrote: Alexey, Can you review/test this patch series? Patches 2/8, 3/8, and 5/8 are bug fixes the rest are mainly cleanups. Patch 2/8 should fix a crash in the normal case if the device is disconnected while not in use. I will also check your patches soon. I have this old hardware at home. Cheers Douglas -- 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
Videomed Videosmart VX-3001
I've just got my hands on Videosmart VX-3001 medical video-grabber. It seems it has some common hardware under the hood, but I only managed to get dark-green screen in Cheese. I include some of my specs, dmesg and lsub. Being completely green in driver development I'd like to get some help in figuring out how to make it work. 2.6.35-20-generic #29-Ubuntu SMP Fri Sep 3 14:55:28 UTC 2010 x86_64 GNU/Linux Bus 001 Device 004: ID eb1a:2861 eMPIA Technology, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0xeb1a eMPIA Technology, Inc. idProduct 0x2861 bcdDevice1.00 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 555 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 2 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type
[cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Sep 14 19:00:11 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15148:990bbeaeb761 git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: 991403c594f666a2ed46297c592c60c3b9f4e1e2 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-rc2-i686: ERRORS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec: ERRORS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/18] dvb/bt8xx: kill the big kernel lock
The bt8xx driver only uses the big kernel lock in its dst_ca_ioctl function and never to serialize against other code, so we can trivially replace it with a private mutex. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab mche...@infradead.org --- drivers/media/dvb/bt8xx/dst_ca.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb/bt8xx/dst_ca.c b/drivers/media/dvb/bt8xx/dst_ca.c index cf87051..d75788b 100644 --- a/drivers/media/dvb/bt8xx/dst_ca.c +++ b/drivers/media/dvb/bt8xx/dst_ca.c @@ -22,7 +22,7 @@ #include linux/module.h #include linux/slab.h #include linux/init.h -#include linux/smp_lock.h +#include linux/mutex.h #include linux/string.h #include linux/dvb/ca.h #include dvbdev.h @@ -52,6 +52,7 @@ } while(0) +static DEFINE_MUTEX(dst_ca_mutex); static unsigned int verbose = 5; module_param(verbose, int, 0644); MODULE_PARM_DESC(verbose, verbose startup messages, default is 1 (yes)); @@ -564,7 +565,7 @@ static long dst_ca_ioctl(struct file *file, unsigned int cmd, unsigned long ioct void __user *arg = (void __user *)ioctl_arg; int result = 0; - lock_kernel(); + mutex_lock(dst_ca_mutex); dvbdev = file-private_data; state = (struct dst_state *)dvbdev-priv; p_ca_message = kmalloc(sizeof (struct ca_msg), GFP_KERNEL); @@ -652,7 +653,7 @@ static long dst_ca_ioctl(struct file *file, unsigned int cmd, unsigned long ioct kfree (p_ca_slot_info); kfree (p_ca_caps); - unlock_kernel(); + mutex_unlock(dst_ca_mutex); return result; } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Trouble building v4l-dvb
Trouble building v4l-dvb Asus eee netbook, running EasyPeasy. o...@ole-eee:~$ cat /etc/issue Ubuntu 9.04 \n \l o...@ole-eee:~$ uname -a Linux ole-eee 2.6.30.5-ep0 #10 SMP PREEMPT Thu Aug 27 19:45:06 CEST 2009 i686 GNU/Linux Rationale for building from source: I have bought a USB TV with mpg4 support from Sandberg, Mini DVB-T dongle. I also received an archive with driver routines for this from Sandberg. These should be copied into the v4l-dvd three and just rebuild with make. I have installed the kernel headers: apt-get install mercurial linux-headers-$(uname -r) build-essential Then I have downloaded the v4l-dvb source (assuming this is a stable release): hg clone http://linuxtv.org/hg/v4l-dvb I wanted to try to build before applying the patch from Sandberg. Issuing make yield the following : LIRC: Requires at least kernel 2.6.36 IR_LIRC_CODEC: Requires at least kernel 2.6.36 IR_IMON: Requires at least kernel 2.6.36 IR_MCEUSB: Requires at least kernel 2.6.36 VIDEOBUF_DMA_CONTIG: Requires at least kernel 2.6.31 V4L2_MEM2MEM_DEV: Requires at least kernel 2.6.33 and a few more lines Ignoring these and just continuing : CC [M] /home/ole/work/v4l-dvb/v4l/firedtv-dvb.o CC [M] /home/ole/work/v4l-dvb/v4l/firedtv-fe.o CC [M] /home/ole/work/v4l-dvb/v4l/firedtv-1394.o /home/ole/work/v4l-dvb/v4l/firedtv-1394.c:22:17: error: dma.h: No such file or directory /home/ole/work/v4l-dvb/v4l/firedtv-1394.c:23:21: error: csr1212.h: No such file or directory /home/ole/work/v4l-dvb/v4l/firedtv-1394.c:24:23: error: highlevel.h: No such file or directory and many many more similar errors. After some time the make bails out. I assume this have some connection with the 9.04 being too old. Hints ? Regards, Ole W. Saastad -- 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
Fw: [linux-dvb] DSM-CC question
Hi, First of all, I am new to this list, so I am not sire if this is right place for this question. If not, please forgive me and point me to right list. I am writing a DSMCC decoding implementation to persist it to local filesystem. I am unable to understand few thiings related to srg I know, it represents the top level directory. But how do I get the name of this directory? I can extract the names of subdirs and files using name components but where is the name of top level directory? Also, as far as I understand it, I can't start writing to the local filesystem until I have acquired the whole carousel. Can, anyone please provide me some guidance. Thanks in Advance, rs ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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
cx23885 / HVR 1200 - A/V Inputs?
Hello, ago some time ( Wed, 24 Feb 2010 16:34:05 +0100 ) i asked whether there's some status for the A/V Inputs on this card, Devin said there was no progress, so .. any new status? something beta i could test? Cheers -- Jean-Michel Bruenn jean.bru...@ip-minds.de -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need info to understand TeVii S470 cx23885 MSI problem
On Tue, 2010-09-14 at 01:08 +0300, Igor M. Liplianin wrote: В сообщении от 13 сентября 2010 23:41:21 автор Igor M. Liplianin написал: В сообщении от 13 сентября 2010 23:38:28 автор Igor M. Liplianin написал: В сообщении от 12 сентября 2010 22:56:57 автор Andy Walls написал: The linux kernel should be writing the MSI IRQ vector into the PCI configuration space of the CX23885. It looks like when you unload and reload the cx23885 module, it is not changing the vector. Error appears only and if you zap actual channel(interrupts actually calls). First time module loaded and zapped some channel. At this point there is no errors. /proc/interrupts shows some irq's for cx23885. Then rmmod-insmod and szap again. Voilla! No irq vector. /proc/interrupts shows zero irq calls for cx23885. In my case Do_irq complains about irq 153, dmesq says cx23885 uses 45. Forget to mention. The tree is media_tree, branch staging/v2.6.37 Hi Igor, On the surface what is going on is now obvious to me: bash-4.1# szap -l10750 bridge-tv -x reading channels from file '/root/.szap/channels.conf' zapping to 6 'bridge-tv': sat 1, frequency = 12303 MHz H, symbolrate 2750, vpid = 0x0134, apid = 0x0100 sid = 0x003b using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 1f | signal fde8 | snr e128 | ber | unc 000b | FE_HAS_LOCK bash-4.1# lspci -d 14f1: - - 02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) Subsystem: Device d470:9022 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: fee0300c Data: 4191 a0: 05 00 81 00 0c 30 e0 fe 00 00 00 00 91 41 00 00 ^^^ || MSI Enabled--+| | Linux MSI vector (0x91 = 145) + bash-4.1# rmmod cx23885 bash-4.1# insmod cx23885.ko bash-4.1# lspci -d 14f1: - - 02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) Subsystem: Device d470:9022 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: fee0300c Data: 4199 a0: 05 00 81 00 0c 30 e0 fe 00 00 00 00 99 41 00 00 ^^^ || MSI Enabled--+| | Linux MSI vector (0x99 = 153) + bash-4.1# szap -l10750 bridge-tv -x reading channels from file '/root/.szap/channels.conf' zapping to 6 'bridge-tv': sat 1, frequency = 12303 MHz H, symbolrate 2750, vpid = 0x0134, apid = 0x0100 sid = 0x003b using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal f618 | snr e128 | ber | unc 000b | Message from sysl...@localhost at Tue Sep 14 01:00:50 2010 ... localhost kernel: do_IRQ: 0.145 No irq handler for vector (irq -1) ^^^ | Previous MSI vector used --+ (145 = 0x91 and is not 0x99 ! ) The CX23885 hardware is sending the old/previous MSI data in the PCIe MSI message. The likely reasons I can think of for this to happen are: 1. The CX23885 chip has a bug and send at least one PCIe MSI message with the old MSI data, when the MSI data payload in the PCIe config space of the CX23885 has changed. 2. Your kernel is using the PCI Enhanced Configuration Access Method (Linux calls it MMCONFIG in dmesg) and PCI MMIO Configuration writes to the CX23885 are getting reordered due to motherboard/chipset design problem. Under these conditions, MSI on the CX23885 could be re-enabled before the MSI Data vector is updated in the CX23885's PCI config space. (See page 5 of: http://www.pcisig.com/specifications/pciexpress/PciEx_ECN_MMCONFIG_040217.pdf ) To eliminate #2 being a problem, could you please boot your kernel with pci=nommconf on the kernel command line and see if the MSI data vector problem goes away? Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Videomed Videosmart VX-3001
Em 14-09-2010 13:19, Paweł Kuźniar escreveu: I've just got my hands on Videosmart VX-3001 medical video-grabber. It seems it has some common hardware under the hood, but I only managed to get dark-green screen in Cheese. I include some of my specs, dmesg and lsub. Being completely green in driver development I'd like to get some help in figuring out how to make it work. Ok, yet another em28xx webcam ;) [ 177.200295] usb 1-3: new high speed USB device using ehci_hcd and address 4 [ 177.492308] Linux video capture interface: v2.00 [ 177.493907] IR NEC protocol handler initialized [ 177.499529] IR RC5(x) protocol handler initialized [ 177.564668] IR RC6 protocol handler initialized [ 177.570875] em28xx: New device @ 480 Mbps (eb1a:2861, interface 0, class 0) [ 177.571060] em28xx #0: chip ID is em2860 [ 177.618639] IR JVC protocol handler initialized [ 177.621594] IR Sony protocol handler initialized [ 177.667519] lirc_dev: IR Remote Control driver registered, major 250 [ 177.669829] IR LIRC bridge handler initialized [ 177.741359] em28xx #0: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741386] em28xx #0: i2c eeprom 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741409] em28xx #0: i2c eeprom 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741431] em28xx #0: i2c eeprom 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741453] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741476] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741498] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741520] em28xx #0: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741542] em28xx #0: i2c eeprom 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741564] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741586] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741608] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741630] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741652] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741674] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741696] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 177.741719] em28xx #0: EEPROM ID= 0x, EEPROM hash = 0x [ 177.741724] em28xx #0: EEPROM info: Something got wrong at I2C. It is just returning zero for everything. [ 177.741728] em28xx #0: No audio on board. [ 177.741732] em28xx #0: 500mA max power [ 177.741737] em28xx #0: Table at 0x00, strings=0x, 0x, 0x [ 177.763662] Unknown Micron Sensor 0x There's no sensor 0x. [ 177.763672] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 177.764416] em28xx #0: found i2c device @ 0x0 [???] [ 177.765167] em28xx #0: found i2c device @ 0x2 [???] [ 177.765912] em28xx #0: found i2c device @ 0x4 [???] ... [ 177.818696] em28xx #0: found i2c device @ 0xfe [???] See? It is returning zero for everything at the I2C bus. [ 180.220449] 4:2:1: endpoint lacks sample rate attribute bit, cannot set. [ 180.220561] 4:2:2: endpoint lacks sample rate attribute bit, cannot set. [ 180.220684] 4:2:3: endpoint lacks sample rate attribute bit, cannot set. [ 180.220808] 4:2:4: endpoint lacks sample rate attribute bit, cannot set. [ 180.220936] 4:2:5: endpoint lacks sample rate attribute bit, cannot set. [ 180.224764] usbcore: registered new interface driver snd-usb-audio [ 180.311098] 4:2:2: endpoint lacks sample rate attribute bit, cannot set. [ 180.313775] 4:2:2: endpoint lacks sample rate attribute bit, cannot set. This also doesn't sound good. There are a few frequencies that could be used for I2C: #define EM28XX_I2C_FREQ_1_5_MHZ 0x03 /* bus frequency (bits [1-0]) */ #define EM28XX_I2C_FREQ_25_KHZ 0x02 #define EM28XX_I2C_FREQ_400_KHZ 0x01 #define EM28XX_I2C_FREQ_100_KHZ 0x00 In general, most hardware accept up to 100 kHz, but there are a few devices where this needs to be reduced to 25 kHz in order to work. We never found one em28xx-based hardware needing to reduce I2C speed, but it seems that you got one ;) Eventually, this might also be caused by a device responding badly to i2c scan. Please try the enclosed patch, forcing the driver to use card=1, by adding: option em28xx card=1 at /etc/modprobe (or the similar modprobe config on your distro). This patch should reduce the bus speed to 25 kHz, hopefully giving us more information about your device. Cheers, Mauro diff --git a/drivers/media/video/em28xx/em28xx-cards.c b/drivers/media/video/em28xx/em28xx-cards.c index ffbe544..0213536 100644
Re: How to handle independent CA devices
Hi Johannes, Johannes Stezenbach writes: So, I would like to hear your opinions about how to handle such CA devices regarding device names/types, the DVB API and user libraries. it looks like there isn't much interest from DVB developers in that topic... I'll try... IMHO there are three sub topics: 1. be compatible with existing applications (I guess this means: feed stream from frontend through CI transparently) 2. create an API which would also work for CI-only devices like this Hauppauge WinTV-CI USB thingy 3. how to switch between these modes? This sec0 device is history (unused and deprecated for years), right? Yes, the former DiSEqC, etc. device. I only use it because it is is unused and I do not have to change anything in dvb-core this way. But trivial to change it or add ci0. How about the following: Rename it to ci0. When ci0 is closed the stream is routed transparently from frontend through CI, if it's opened one needs to read/write the stream from userspace. You still need a mechanism to decide which tuner gets it. First one which opens its own ca device? Sharing the CI (multi-stream decoding) in such an automatic way would also be complicated. I think I will only add such a feature if there is very high demand and rather look into the separate API solution. If you can't get responses here I guess you could talk to vdr or other application developers. After all they'll have to use the API. I am in contact with some. Just wanted to check what people think about it on this list. Thanks for your comments. -Ralph -- 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] mt9p031 support for dm355-evm
This patch was created from the linux-davinci staging kernel at
arago-project.org
---
arch/arm/mach-davinci/board-dm355-evm.c| 49 ++-
drivers/media/video/Kconfig| 10 +
drivers/media/video/Makefile |1 +
drivers/media/video/davinci/vpfe_capture.c |2 +-
drivers/media/video/mt9p031.c | 834
drivers/mfd/dm355evm_msp.c | 12 +-
include/media/davinci/vpfe_capture.h |1 +
include/media/v4l2-chip-ident.h|3 +
8 files changed, 902 insertions(+), 10 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 5d3946e..dd329dd 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -179,9 +179,11 @@ static struct i2c_board_info dm355evm_i2c_info[] = {
{ I2C_BOARD_INFO(dm355evm_msp, 0x25),
.platform_data = dm355evm_mmcsd_gpios,
},
+#if defined(CONFIG_SOC_CAMERA_MT9T031)
{
I2C_BOARD_INFO(PCA9543A, 0x73),
},
+#endif
/* { plus irq }, */
{ I2C_BOARD_INFO(tlv320aic33, 0x1b), },
};
@@ -190,8 +192,10 @@ static struct i2c_board_info dm355evm_i2c_info[] = {
static inline int have_sensor(void)
{
#if defined(CONFIG_SOC_CAMERA_MT9T031) || \
-defined(CONFIG_SOC_CAMERA_MT9T031_MODULE)
- return 1;
+defined(CONFIG_SOC_CAMERA_MT9T031_MODULE) || \
+defined(CONFIG_VIDEO_MT9P031) || \
+defined(CONFIG_VIDEO_MT9P031_MODULE)
+ return 1;
#else
return 0;
#endif
@@ -204,8 +208,10 @@ static void __init evm_init_i2c(void)
gpio_request(5, dm355evm_msp);
gpio_direction_input(5);
dm355evm_i2c_info[0].irq = gpio_to_irq(5);
+#if defined(CONFIG_SOC_CAMERA_MT9T031)
if (have_sensor())
i2c_add_driver(pca9543a_driver);
+#endif
i2c_register_board_info(1, dm355evm_i2c_info,
ARRAY_SIZE(dm355evm_i2c_info));
}
@@ -266,18 +272,21 @@ static int dm355evm_enable_pca9543a(int en)
*/
static int dm355evm_setup_video_input(enum vpfe_subdev_id id)
{
- int ret;
-
+ int ret = 0;
+#if defined CONFIG_VIDEO_CAPTURE_DRIVERS
switch (id) {
+ case VPFE_SUBDEV_MT9P031:
case VPFE_SUBDEV_MT9T031:
{
ret = dm355evm_msp_write(MSP_VIDEO_IMAGER,
DM355EVM_MSP_VIDEO_IN);
+#if defined(CONFIG_SOC_CAMERA_MT9T031)
if (ret = 0)
ret = dm355evm_enable_pca9543a(1);
else
/* switch off i2c switch since we failed */
ret = dm355evm_enable_pca9543a(0);
+#endif
break;
}
case VPFE_SUBDEV_TVP5146:
@@ -288,6 +297,7 @@ static int dm355evm_setup_video_input(enum
vpfe_subdev_id id)
default:
return -EINVAL;
}
+#endif
return (ret = 0 ? 0 : ret);
}
@@ -300,6 +310,15 @@ static struct v4l2_input mt9t031_inputs[] = {
}
};
+/* Input available at the mt9p031 */
+static struct v4l2_input mt9p031_inputs[] = {
+ {
+ .index = 0,
+ .name = Camera,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ }
+};
+
static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -357,6 +376,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
.platform_data = tvp5146_pdata,
},
},
+#if defined(CONFIG_SOC_CAMERA_MT9T031)
{
.module_name = mt9t031,
.is_camera = 1,
@@ -373,7 +393,26 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
/* this is for PCLK rising edge */
.platform_data = (void *)1,
},
- }
+ },
+#elif defined(CONFIG_VIDEO_MT9P031) /* mutually exclusive (same i2c
addr) */
+ {
+ .module_name = mt9p031,
+ .is_camera = 1,
+ .grp_id = VPFE_SUBDEV_MT9P031,
+ .num_inputs = ARRAY_SIZE(mt9p031_inputs),
+ .inputs = mt9p031_inputs,
+ .ccdc_if_params = {
+ .if_type = VPFE_RAW_BAYER,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(mt9p031, 0x5d),
+ /* this is for PCLK rising edge */
+// .platform_data = (void *)1,
+ },
+ },
+#endif
};
static struct vpfe_config vpfe_cfg = {
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index becefc9..866f72c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1002,6 +1002,16 @@ config
Re: How to handle independent CA devices
rjkm a écrit : Hi Johannes, Johannes Stezenbach writes: So, I would like to hear your opinions about how to handle such CA devices regarding device names/types, the DVB API and user libraries. it looks like there isn't much interest from DVB developers in that topic... I'll try... IMHO there are three sub topics: 1. be compatible with existing applications (I guess this means: feed stream from frontend through CI transparently) 2. create an API which would also work for CI-only devices like this Hauppauge WinTV-CI USB thingy 3. how to switch between these modes? This sec0 device is history (unused and deprecated for years), right? Yes, the former DiSEqC, etc. device. I only use it because it is is unused and I do not have to change anything in dvb-core this way. But trivial to change it or add ci0. How about the following: Rename it to ci0. When ci0 is closed the stream is routed transparently from frontend through CI, if it's opened one needs to read/write the stream from userspace. You still need a mechanism to decide which tuner gets it. First one which opens its own ca device? Sharing the CI (multi-stream decoding) in such an automatic way would also be complicated. I think I will only add such a feature if there is very high demand and rather look into the separate API solution. If you can't get responses here I guess you could talk to vdr or other application developers. After all they'll have to use the API. I am in contact with some. Just wanted to check what people think about it on this list. Thanks for your comments. You might also want to check on mythtv-dev list, there was a guy (James Courtier-Dutton) who wanted to hack exactly this in mythtv. I guess he would have the user space point-of-view. Hope you succeed, because having an independant CI would be perfect to enable real multirec for DVB cards by decoding after the fact. Bye Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle independent CA devices
Hi Ralph, On Wed, Sep 15, 2010 at 5:26 AM, rjkm r...@metzlerbros.de wrote: Hi Johannes, Johannes Stezenbach writes: So, I would like to hear your opinions about how to handle such CA devices regarding device names/types, the DVB API and user libraries. it looks like there isn't much interest from DVB developers in that topic... I'll try... IMHO there are three sub topics: 1. be compatible with existing applications (I guess this means: feed stream from frontend through CI transparently) 2. create an API which would also work for CI-only devices like this Hauppauge WinTV-CI USB thingy 3. how to switch between these modes? This sec0 device is history (unused and deprecated for years), right? Yes, the former DiSEqC, etc. device. I only use it because it is is unused and I do not have to change anything in dvb-core this way. But trivial to change it or add ci0. How about the following: Rename it to ci0. When ci0 is closed the stream is routed transparently from frontend through CI, if it's opened one needs to read/write the stream from userspace. You still need a mechanism to decide which tuner gets it. First one which opens its own ca device? Sharing the CI (multi-stream decoding) in such an automatic way would also be complicated. I think I will only add such a feature if there is very high demand and rather look into the separate API solution. It would be advantageous, if we do have just a simple input path, where it is not restricted for CA/CI alone. I have some hardware over here, where it has a DMA_TO_DEVICE channel (other than for the SG table), where it can write a TS to any post-processor connected to it, such as a CA/CI device, or even a decoder, for example. In short, it could be anything, to put short. In this case, the device can accept processed stream (muxed TS for multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You can flip some registers for the device, for it to read from userspace, or for that DMA channel to read from the hardware page tables of another DMA channel which is coming from the tuner. Maybe, we just need a simple mechanism/ioctl to select the CA/CI input for the stream to the bridge. ie like a MUX: a 1:n select per adapter, where the CA/CI device has 1 input and there are 'n' sources. Best Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linux V4L2 support dual stream video capture device
Hi Laurent, and Hans, I checked media frameworks, it was helpful for me, but It's not usable on my case. Because, before defining the device for using media frameworks, the device must be defined by some other device like FB, ALSA, DVB, etc. But, this H/W Block is no way to define using any other method in current V4L2 frameworks. So, I wanna listen to your advices about this cases. It has 2 modes, the Preview mode to have Capturing FIFOing capability, and the Capture mode to DMAing capabilitiy. Exactly, in Preview mode, it dosen't need any other V4L2 IOCTL calls related with buffer, like VIDIOC_REQBUFS, VIDIOC_QUERYBUFS, and mmap() operation. Using just VIDIOC_S_FMT IOCTL calls, is able to define this block. Because, it has no buffers. The QBUF and DQBUF looping, also is same any other V4L2 driver working process. On the other hand, In Capture mode, the same stream of Preview mode, is able to get using WDMA. So, at this mode, it need V4L2 IOCTL calls related with buffers. I would show this SoC's media H/W Blocks flowchart briefly. +--+ | FIFO Link| +---| using |---+ | | Internal SRAM | | +---+| +--+ | | C || | | C | ++---+ +---+ | D | | H/W Block A || H/W Block B | | | +---++ Vsync issued +---+ | S +---+ Sensor| Pre - | using Interrupt |Post - | | E | | Interface | Processor | recognized at| Processor | | N | ++--++ H/W Block B +-+-+ | S || | | | O |+--+ | | R | Vsync issued | DMA Link +---+ using Interrupt | recognized in H/W Block A | | +---+-+ | DMA Bus | +-+ If the flowchart is crashed, copy and paste in the notepad or something. In the fixed size font, it will looks well. Actualy my opinion, any other buf_type is needed to define in such case, like a V4L2_BUF_FLAG_FIFO, not using media framework. Thanks to reading, and I'll wait any advises and opinions. Regards, HeungJun, Kim -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Tuesday, September 14, 2010 6:53 PM To: Theodore Kilgore Cc: Wang, Wen W; linux-media@vger.kernel.org; Zhang, Xiaolin; Huang, Kai; Hu, Gang A Subject: Re: Linux V4L2 support dual stream video capture device Hi Theodore, On Monday 13 September 2010 19:17:48 Theodore Kilgore wrote: On Mon, 13 Sep 2010, Laurent Pinchart wrote: On Friday 07 May 2010 20:20:38 Wang, Wen W wrote: Hi all, I'm wondering if V4L2 framework supports dual stream video capture device that transfer a preview stream and a regular stream (still capture or video capture) at the same time. We are developing a device driver with such capability. Our proposal to do this in V4L2 framework is to have two device nodes, one as primary node for still/video capture and one for preview. If the device supports multiple simultaneous video streams, multiple video nodes is the way to go. The primary still/video capture device node is used for device configuration which can be compatible with open sourced applications. This will ensure the normal V4L2 application can run without code modification. Device node for preview will only accept preview buffer related operations. Buffer synchronization for still/video capture and preview will be done internally in the driver. I suspect that the preview device node will need to support more than the buffer-related operations, as you probably want applications to configure the preview video stream format and size. This is our initial idea about the dual stream support in V4L2. Your comments will be appreciated! You should use the media controller framework. This will allow applications to configure all sizes in the pipeline, including the frame sizes for the two video nodes. Hi, Wen, You have hit upon an old and rather vexing problem. It affects many devices, not just your prospective one. The problem is that still mode is supported in Linux for a lot of cameras through
