RE: [PATCH 1/4] V4L2: Added New V4L2 CIDs VIDIOC_S/G_COLOR_SPACE_CONV
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Friday, October 16, 2009 5:57 PM
To: Hiremath, Vaibhav
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH 1/4] V4L2: Added New V4L2 CIDs
VIDIOC_S/G_COLOR_SPACE_CONV
Hi,
On Friday 16 October 2009 12:19:20 hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/v4l2-ioctl.c | 19 +++
include/linux/videodev2.h| 14 ++
include/media/v4l2-ioctl.h |4
3 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c index 30cc334..d3140e0 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -284,6 +284,8 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_DBG_G_CHIP_IDENT)] =
VIDIOC_DBG_G_CHIP_IDENT,
[_IOC_NR(VIDIOC_S_HW_FREQ_SEEK)] = VIDIOC_S_HW_FREQ_SEEK,
#endif
+ [_IOC_NR(VIDIOC_S_COLOR_SPACE_CONV)] =
VIDIOC_S_COLOR_SPACE_CONV,
+ [_IOC_NR(VIDIOC_G_COLOR_SPACE_CONV)] =
VIDIOC_G_COLOR_SPACE_CONV,
};
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
This should go through a control, not an ioctl. Strings control have
recently
been introduced, it should be fairly easy to create binary controls
for such
cases.
[Hiremath, Vaibhav] I am really not sure how we can fit this into string
control.
Atleast from OMAP3 point of view we need nine 11 bit signed coeff. We can not
use string control here but we can leverage same mechanism.
I can have __s32 * in v4l2_ext_control which will point to array of nine 11 bit
coeff.
Again there is control over full or limited range conversion.
Thanks,
Vaibhav
--
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-uvc-devel] again Logitech QuickCam Pro for Notebooks 046d:0991
Hi Alexey, On Wednesday 28 October 2009 10:58:24 Alexey Fisher wrote: Am Mittwoch, den 28.10.2009, 00:27 +0100 schrieb Laurent Pinchart: On Monday 26 October 2009 15:06:41 Hans de Goede wrote: On 10/26/2009 12:52 PM, Alexey Fisher wrote: Am Sonntag, den 25.10.2009, 14:21 +0100 schrieb Hans de Goede: [snip] fwiw I'm a v4l kernel developer, but I'm not involved in the UVC driver, I'm however a contributor to cheese, I thought that my input that cheese would give up even if the driver has a long enough timeout would be helpful. To try and see if this (the cheese timeout is the issue), you will need to re-compile cheese from source, after unpacking cheese, edit src/cheese-webcam.c and goto line 716 (in 2.28.0) And change the 10 * GST_SECOND there in something bigger. I also see that I'm mistaken and the timeout in cheese is not 3 but 10 seconds, it might have changed recently, or my memory has been playing tricks on me. I still believe this might be the cause, the trace you have posted seems consistent with cheese's behaviour. Also noticed that there never is a successfull DQBUF the first time cheese opens the device. If cheese (or rather gstreamer) does not manage to DQBUF the first time, then cheese will not work with the device. There is a limitation in gstreamer (or maybe in the way cheese uses it) where gstreamer needs to be streaming before cheese can tell the properties of the cam. If the stream does not start within the first 10 seconds, then cheese will fail to get the properties. If you go to cheese's edit - preferences menu, and your cam has no resolutions listed there (the resolution drop down is grayed out). This is what is happening. As for empathy, I'm not familiar with that. But if we can get cheese to work first I'm sure that that would be a good step in the right direction. Hallo Hans, thank you for your constructive response, I increased timeout to 15 seconds i now i can't reproduce camera freeze, i'll play with it more to be sure. There is still one issue with it - on cold start the image is zoomed in. I need to close cheese and open it again to get normal zoom. The resolution seems to be the same. Zoomed in ? Really ? As far as I know the QuickCam Pro for Notebooks has no optical or digital zoom. Could you please send me lsusb's output for your device ? Yes. I can use digital zoom under M$Win with Logitech software. That's probably implemented in software in the Windows driver. [snip] sudo lsusb -vd 046d:0991 Bus 001 Device 007: ID 046d:0991 Logitech, Inc. QuickCam Pro for Notebooks Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x046d Logitech, Inc. idProduct 0x0991 QuickCam Pro for Notebooks bcdDevice0.05 iManufacturer 0 iProduct0 iSerial 2 [removed] bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 1433 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 3 Video Interface Collection bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass14 Video bInterfaceSubClass 1 Video Control bInterfaceProtocol 0 iInterface 0 VideoControl Interface Descriptor: bLength13 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdUVC 1.00 wTotalLength 133 dwClockFrequency 48.00MHz bInCollection 1 baInterfaceNr( 0) 1 VideoControl Interface Descriptor: bLength18 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Camera Sensor bAssocTerminal 0 iTerminal 0 wObjectiveFocalLengthMin 0 wObjectiveFocalLengthMax
Re: [Linux-uvc-devel] again Logitech QuickCam Pro for Notebooks 046d:0991
Hi Laurent, Am Mittwoch, den 28.10.2009, 13:52 +0100 schrieb Laurent Pinchart: Hi Alexey, On Wednesday 28 October 2009 10:58:24 Alexey Fisher wrote: Am Mittwoch, den 28.10.2009, 00:27 +0100 schrieb Laurent Pinchart: On Monday 26 October 2009 15:06:41 Hans de Goede wrote: On 10/26/2009 12:52 PM, Alexey Fisher wrote: Am Sonntag, den 25.10.2009, 14:21 +0100 schrieb Hans de Goede: [snip] fwiw I'm a v4l kernel developer, but I'm not involved in the UVC driver, I'm however a contributor to cheese, I thought that my input that cheese would give up even if the driver has a long enough timeout would be helpful. To try and see if this (the cheese timeout is the issue), you will need to re-compile cheese from source, after unpacking cheese, edit src/cheese-webcam.c and goto line 716 (in 2.28.0) And change the 10 * GST_SECOND there in something bigger. I also see that I'm mistaken and the timeout in cheese is not 3 but 10 seconds, it might have changed recently, or my memory has been playing tricks on me. I still believe this might be the cause, the trace you have posted seems consistent with cheese's behaviour. Also noticed that there never is a successfull DQBUF the first time cheese opens the device. If cheese (or rather gstreamer) does not manage to DQBUF the first time, then cheese will not work with the device. There is a limitation in gstreamer (or maybe in the way cheese uses it) where gstreamer needs to be streaming before cheese can tell the properties of the cam. If the stream does not start within the first 10 seconds, then cheese will fail to get the properties. If you go to cheese's edit - preferences menu, and your cam has no resolutions listed there (the resolution drop down is grayed out). This is what is happening. As for empathy, I'm not familiar with that. But if we can get cheese to work first I'm sure that that would be a good step in the right direction. Hallo Hans, thank you for your constructive response, I increased timeout to 15 seconds i now i can't reproduce camera freeze, i'll play with it more to be sure. There is still one issue with it - on cold start the image is zoomed in. I need to close cheese and open it again to get normal zoom. The resolution seems to be the same. Zoomed in ? Really ? As far as I know the QuickCam Pro for Notebooks has no optical or digital zoom. Could you please send me lsusb's output for your device ? Yes. I can use digital zoom under M$Win with Logitech software. That's probably implemented in software in the Windows driver. [snip] The zoom control, if present, should have appeared here. As your camera doesn't expose any zoom control I really don't know where the zoom comes from. i don't really care about zoom problem. This not making this webcam freeze so probably nobody will find this issue. You can sleep well :) if you have some ideas about camera freeze, please let me know. regards, Alexey. -- 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-uvc-devel] again Logitech QuickCam Pro for Notebooks 046d:0991
On Wednesday 28 October 2009 14:36:33 Alexey Fisher wrote: Hi Laurent, Am Mittwoch, den 28.10.2009, 13:52 +0100 schrieb Laurent Pinchart: Hi Alexey, On Wednesday 28 October 2009 10:58:24 Alexey Fisher wrote: Am Mittwoch, den 28.10.2009, 00:27 +0100 schrieb Laurent Pinchart: On Monday 26 October 2009 15:06:41 Hans de Goede wrote: On 10/26/2009 12:52 PM, Alexey Fisher wrote: Am Sonntag, den 25.10.2009, 14:21 +0100 schrieb Hans de Goede: [snip] fwiw I'm a v4l kernel developer, but I'm not involved in the UVC driver, I'm however a contributor to cheese, I thought that my input that cheese would give up even if the driver has a long enough timeout would be helpful. To try and see if this (the cheese timeout is the issue), you will need to re-compile cheese from source, after unpacking cheese, edit src/cheese-webcam.c and goto line 716 (in 2.28.0) And change the 10 * GST_SECOND there in something bigger. I also see that I'm mistaken and the timeout in cheese is not 3 but 10 seconds, it might have changed recently, or my memory has been playing tricks on me. I still believe this might be the cause, the trace you have posted seems consistent with cheese's behaviour. Also noticed that there never is a successfull DQBUF the first time cheese opens the device. If cheese (or rather gstreamer) does not manage to DQBUF the first time, then cheese will not work with the device. There is a limitation in gstreamer (or maybe in the way cheese uses it) where gstreamer needs to be streaming before cheese can tell the properties of the cam. If the stream does not start within the first 10 seconds, then cheese will fail to get the properties. If you go to cheese's edit - preferences menu, and your cam has no resolutions listed there (the resolution drop down is grayed out). This is what is happening. As for empathy, I'm not familiar with that. But if we can get cheese to work first I'm sure that that would be a good step in the right direction. Hallo Hans, thank you for your constructive response, I increased timeout to 15 seconds i now i can't reproduce camera freeze, i'll play with it more to be sure. There is still one issue with it - on cold start the image is zoomed in. I need to close cheese and open it again to get normal zoom. The resolution seems to be the same. Zoomed in ? Really ? As far as I know the QuickCam Pro for Notebooks has no optical or digital zoom. Could you please send me lsusb's output for your device ? Yes. I can use digital zoom under M$Win with Logitech software. That's probably implemented in software in the Windows driver. [snip] The zoom control, if present, should have appeared here. As your camera doesn't expose any zoom control I really don't know where the zoom comes from. i don't really care about zoom problem. This not making this webcam freeze so probably nobody will find this issue. You can sleep well :) if you have some ideas about camera freeze, please let me know. You have been able to work around the freeze by raising cheese's timeout to 15 seconds, right ? I'll try to find a solution (or rather a work around) to the problem on the driver side but that might take around a week. -- 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-uvc-devel] again Logitech QuickCam Pro for Notebooks 046d:0991
Am Mittwoch, den 28.10.2009, 14:40 +0100 schrieb Laurent Pinchart: On Wednesday 28 October 2009 14:36:33 Alexey Fisher wrote: Hi Laurent, Am Mittwoch, den 28.10.2009, 13:52 +0100 schrieb Laurent Pinchart: Hi Alexey, On Wednesday 28 October 2009 10:58:24 Alexey Fisher wrote: Am Mittwoch, den 28.10.2009, 00:27 +0100 schrieb Laurent Pinchart: On Monday 26 October 2009 15:06:41 Hans de Goede wrote: On 10/26/2009 12:52 PM, Alexey Fisher wrote: Am Sonntag, den 25.10.2009, 14:21 +0100 schrieb Hans de Goede: [snip] fwiw I'm a v4l kernel developer, but I'm not involved in the UVC driver, I'm however a contributor to cheese, I thought that my input that cheese would give up even if the driver has a long enough timeout would be helpful. To try and see if this (the cheese timeout is the issue), you will need to re-compile cheese from source, after unpacking cheese, edit src/cheese-webcam.c and goto line 716 (in 2.28.0) And change the 10 * GST_SECOND there in something bigger. I also see that I'm mistaken and the timeout in cheese is not 3 but 10 seconds, it might have changed recently, or my memory has been playing tricks on me. I still believe this might be the cause, the trace you have posted seems consistent with cheese's behaviour. Also noticed that there never is a successfull DQBUF the first time cheese opens the device. If cheese (or rather gstreamer) does not manage to DQBUF the first time, then cheese will not work with the device. There is a limitation in gstreamer (or maybe in the way cheese uses it) where gstreamer needs to be streaming before cheese can tell the properties of the cam. If the stream does not start within the first 10 seconds, then cheese will fail to get the properties. If you go to cheese's edit - preferences menu, and your cam has no resolutions listed there (the resolution drop down is grayed out). This is what is happening. As for empathy, I'm not familiar with that. But if we can get cheese to work first I'm sure that that would be a good step in the right direction. Hallo Hans, thank you for your constructive response, I increased timeout to 15 seconds i now i can't reproduce camera freeze, i'll play with it more to be sure. There is still one issue with it - on cold start the image is zoomed in. I need to close cheese and open it again to get normal zoom. The resolution seems to be the same. Zoomed in ? Really ? As far as I know the QuickCam Pro for Notebooks has no optical or digital zoom. Could you please send me lsusb's output for your device ? Yes. I can use digital zoom under M$Win with Logitech software. That's probably implemented in software in the Windows driver. [snip] The zoom control, if present, should have appeared here. As your camera doesn't expose any zoom control I really don't know where the zoom comes from. i don't really care about zoom problem. This not making this webcam freeze so probably nobody will find this issue. You can sleep well :) if you have some ideas about camera freeze, please let me know. You have been able to work around the freeze by raising cheese's timeout to 15 seconds, right ? yes I'll try to find a solution (or rather a work around) to the problem on the driver side but that might take around a week. Thank you. -- 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: V4L2_MEMORY_USERPTR support in videobuf-core
Pawel, We have been using USERPTR IO in our vpfe capture driver. I also want to acknowledge the fact that the core layer expects index contrary to API specs as you have pointed Even if that was the case though, would an application be supposed to arbitrarily choose what index to pass? If so, how would it know what range is valid? And even if it would, the next check: (buf-state != VIDEOBUF_NEEDS_INIT buf_state != VIDEOBUF_IDLE) would most Why would this fails? The range that we use is based on the count in REQBUF. This is similar to MMAP case. If for the same index, if you pass different pointer in QBUF, the core calls the buf_release() (which would set the buffer state back to VIDEOBUF_NEEDS_INIT). So it works fine even if the user ptr is different for same index. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Pawel Osciak Sent: Tuesday, October 27, 2009 12:18 PM To: 'Mauro Carvalho Chehab' Cc: linux-media@vger.kernel.org; kyungmin.p...@samsung.com; Tomasz Fujak; Marek Szyprowski Subject: RE: V4L2_MEMORY_USERPTR support in videobuf-core Hi Mauro, thank you for your reply. On Tuesday, October 27, 2009 1:36 PM Mauro Carvalho Chehab [mailto:mche...@infradead.org] wrote: could anybody confirm that there is no full/working support for USERPTR in current videobuf-core? That is the conclusion I came up with after a more thorough investigation. I am currently working to fix that, and will hopefully be posting patches in the coming days/weeks. Is there any other development effort underway related to this problem? (...) The last time I tested the support for userptr at videobuf-core, it were working on x86 plataforms. On that time, I used vivi with videobuf-dma-sg for such tests (it were before its conversion to use videobuf-vmalloc). As support for userptr on videobuf-vmalloc is missing, vivi can't be used for such tests anymore (a good contribution would be to add userptr support on videobuf-vmalloc). I might be missing something, but for me the path looks as follows (sources: kernel, LWN articles, V4L2 API Specification): 1. open, query, format, other stuff, unimportant 2. VIDEOBUF_REQBUFS - pass type and set memory to V4L2_MEMORY_USERPTR only. 3. VIDEOBUF_QUERYBUFS - only for memory-mapped I/O, so not called. 4. VIDEOBUF_QBUF - pass type, memory, userptr and length fields only. As the API Specification states in section 3.3: No buffers are allocated beforehands, consequently they are not indexed and cannot be queried like mapped buffers with the VIDIOC_QUERYBUF ioctl. But when one calls QBUF, videobuf_qbuf() uses b-index for all types of memory. I have found no mention in the API Specs about passing/returning indexes in USERPTR, quite the contrary, they actually state that indexes are not used in that mode for neither REQBUFS nor QBUF at all. Even if that was the case though, would an application be supposed to arbitrarily choose what index to pass? If so, how would it know what range is valid? And even if it would, the next check: (buf-state != VIDEOBUF_NEEDS_INIT buf_state != VIDEOBUF_IDLE) would most probably fail anyway. How to enqueue and handle multiple userptr buffers? Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Hauppage HVR-2250 Tuning problems
On Wed, Oct 28, 2009 at 1:44 AM, dan danwalke...@gmail.com wrote: I do have 2 2-way splitters between the card in the wall. I tried hooking the card straight to the cable outlet on the wall and ran some more tests. It's a little difficult, because there's only one cable outlet in my whole apartment, and it means doing some re-arranging and being offline while I'm running the tests. Removing splitters proves it's probably not a weak signal issue (also the SNR or 39 on the TV). Can you apply some attenuation to reduce the overall rf strength? I'm thinking it's too hot. Something must be using your second tuner, mythtv maybe? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage HVR-2250 Tuning problems
On Wed, Oct 28, 2009 at 10:08 AM, Steven Toth st...@kernellabs.com wrote: On Wed, Oct 28, 2009 at 1:44 AM, dan danwalke...@gmail.com wrote: I do have 2 2-way splitters between the card in the wall. I tried hooking the card straight to the cable outlet on the wall and ran some more tests. It's a little difficult, because there's only one cable outlet in my whole apartment, and it means doing some re-arranging and being offline while I'm running the tests. Removing splitters proves it's probably not a weak signal issue (also the SNR or 39 on the TV). Can you apply some attenuation to reduce the overall rf strength? I'm thinking it's too hot. Something must be using your second tuner, mythtv maybe? Oh, and please try the card under windows ideally on the same PC using the same antenna feed, to rule out any card specific issues. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] mx31moboard: camera support
Guennadi Liakhovetski wrote: On Wed, 21 Oct 2009, Valentin Longchamp wrote: Sascha Hauer wrote: On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote: Hi Guennadi, Guennadi Liakhovetski wrote: Hi On Thu, 15 Oct 2009, Valentin Longchamp wrote: We have two mt9t031 cameras that have a muxed bus on the robot. We can control which one we are using with gpio outputs. This currently is not optimal So, what prevents you from registering two platform devices for your two cameras? Is there a problem with that? The lack of time until now to do it properly. I sent those patches as initial RFC (and by the way thanks for your comment). I would like to have one video interface only and that I can switch between the two physical camera using a quite simple system call. Would that be compatible with registering the two platform devices ? Wouldn't it be better to have /dev/video[01] for two cameras? How do keep the registers synchron between both cameras otherwise? Well, from my experimentations, most initializations are done when you open the device. So if you close the device, switch camera and open it again, the registers are initialized with the need values. Of course there is a problem is you switch camera while the device is open. It could be ok with /dev/video[01], but I would need something that would prevent one device to be opened when the other already is open (a mutex, but where ?). Besides, I have read a slide from Dongsoo Kim (http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFiledo=gettarget=Framework_for_digital_camera_in_linux-in_detail.ppt slides 41-47) and the cleanest solution would be to have the two chips enumerated with VIDIOC_ENUMINPUT as proposed. What would then be the v4l2 call to switch from one device to each other ? How to link it with the kernel code that make the real hardware switching ? Ok, I don't have a definite answer to this, so, just my thoughts: 1. soc-camera currently registers one struct v4l2_device device per _host_ immediately upon its registration, and one struct video_device per _client_ platform device. Ok understood. 2. we currently have 1 or 2 boards in the mainline with two video client devices on one interface: arch/sh/boards/mach-migor/ and (unsure about) arch/sh/boards/board-ap325rxa.c. At least the first of them exports two platform devices and thus gets /dev/video[01]. Accesses are synchronised with a mutex (I don't actually like that, I'd prefer to get a -EBUSY back instead of hanging in D in open()), and a successful acquisition of the mutex switches the respective camera on. See code for details. So, this approach is supported and it works. In this case we have one v4l2_device and two video_device instances, don't know whether this matches how this is supposed to be done, but it works so far:-) I am going to stick to this approach since it works now. This would allow me to have code that could go now into mainline. 3. to support switching inputs, significant modifications to soc_camera.c would be required. I read Nate's argument before, that as long as clients can only be accessed one at a time, this should be presented by multiple inputs rather than multiple device nodes. Somebody else from the V4L folk has also confirmed this opinion. In principle I don't feel strongly either way. But currently soc-camera uses a one i2c client to one device node model, and I'm somewhat reluctant to change this before we're done with the v4l2-subdev conversion. Sure, one step at a time. So for now the switching is not possible with soc_camera. My problem is that both cameras have the same I2C address since they are the same. Would I need to declare 2 i2c_device with the same address (I'm not sure it would even work ...) used by two _client_ platform_devices or would I have to have the two platform devices pointing to the same i2c_device ? Thanks Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- 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] Global video buffers pool
Hi Guennadi, On Tuesday 27 October 2009 08:49:15 Guennadi Liakhovetski wrote: Hi This is a general comment to the whole (contiguous) video buffer work: having given a talk at the ELC-E in Grenoble on soc-camera, I mentioned briefly a few related RFCs, including this one. I've got a couple of comments back, including the following ones (which is to say, opinions are not mine and may or may not be relevant, I'm just fulfilling my promise to pass them on;)): 1) has been requested to move this discussion to a generic mailing list like LKML. 2) the reason for (1) was, obviously, to consider making such a buffer pool also available to other subsystems, of which video / framebuffer drivers have been mentioned as likely interested parties. Those are good ideas. The global video buffers pool will sooner or later (and my guess is sooner) need to interact with X buffers (either for Xv rendering, or opengl textures). This needs to be discussed globally on the LKML. (btw, not sure if this has also been mentioned among those wishes - what about DVB? Can they also use such buffers?) If I'm not mistaken DVB uses read/write syscalls to transfer data from/to the driver. A video buffers pool wouldn't fit well in that scheme. -- 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
finalising soc-camera conversion to v4l2-subdev
Hi all As some of you will know, soc-camera framework is undergoing a conversion to the v4l2-subdev API. Most of the legacy soc-camera client API has been ported over to v4l2-subdev. Final conversion is blocked by missing functionality in the current v4l2 subsystem. Namely video bus configuration and data format negotiation. And from the progress of respective RFCs it looks like this could take a while to get them into the mainline, which is also understandable, given the amount of work. So, the question is - can we work out a way to finalise the porting yet before the final versions of those RFCs make it upstream? OTOH, we certainly do not want to have to create a solution, which will have to be thrown away completely later. We could decide to 1. make bus configuration optional. If no data provided - use defaults. 2. use something like the proposed imagebus API for data format negotiation. Even if it will be eventually strongly modified for new Media Controller Co. APIs, it already exists, so, the time has already been spent on it, and mainlining it will not require much more time. But I'm open to other ideas too. OR 3. use some intermediate solution - something, that we think will later allow an easy enough extension to the new APIs when they appear. Opinions? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa716x
Benjamin Valentin wrote: Am Fri, 23 Oct 2009 12:08:22 -0400 schrieb Devin Heitmueller dheitmuel...@kernellabs.com: You cannot use a saa7162 based device with the saa7164 driver. They chipsets are too dissimilar. This was why I tried the saa716x driver [1] that should work for saa7160, saa7161 and saa7162 based devices. However, after downloading and compiling the driver and loading all saa716x_* modules, there was no /dev/dvb nor /dev/video, neither were there any messages from saa716x in dmesg (but lsmod did show them up as loaded) Despite MAKE_ENTRY(NXP_REFERENCE_BOARD, PCI_ANY_ID, SAA7162,saa716x_atlantis_config) should have been true for my card as far as I understand, I've added #define PINNACLE0x1131 #define PINNACLE_PCTV_7010IX0x7162 MAKE_ENTRY(PINNACLE, PINNACLE_PCTV_7010IX, SAA7162, saa716x_atlantis_config) with no change after repeating the procedure (and unloading the saa716x_hybrid module of cause) lspci oddly recognizes the board as Pinnacle PCTV 3010iX, which only has one tuner module. I've included lspci and dmesg output. I'm looking forward for someone who could explain what is happening here and what I may do about it. Best regards benjamin [1] http://jusst.de/hg/saa716x/ [2] http://www.computerbase.de/bildstrecke/14665/2/ sorry for forking out another discussion. I am curious to know the status of saa716x driver, because I have a DMB-TH card with saa7160, does it has i2c and TS port working? regards, David -- 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: pinnacle pctv 7010ix and saa716x
On Wed, Oct 28, 2009 at 5:29 PM, Benjamin Valentin benpi...@zedat.fu-berlin.de wrote: lspci oddly recognizes the board as Pinnacle PCTV 3010iX, which only has one tuner module. Probably not relevant to your problem, but my 3010iX has 2 tuners (hybrid, each can do DVB-T + analog). Luca -- 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
bt878 card: no sound and only xvideo support in 2.6.31 after perfect support in 2.6.24
Hello! My Hercules SmartTv Stereo PCI had perfect support under 2.6.24 in Ubuntu 8.04 with below modprobe settings. Now I switched to Ubuntu 9.10 and have: - no sound except some faint garbled noises when I turn up the volume to max. - only have a picture via xvideo/overlay (using the xvideo plugin in kdetv before it worked using the v4l2 plugin in kdetv) Country is Belgium, TV Norm is PAL. Using the latest version compiled from the mercurial repository gives the same results. In Ubuntu 9.04 with kernel 2.6.28 I had the same symptoms but could use the tv card by simply reverting to kernel 2.6.24 without any other changes. Below are the modprobe settings that worked in 2.6.24, the lspci -v output and the relevant dmesg lines. Any pointers are more than welcome. Thanks and best regards, Michael #/etc/modprobe.d/bttv.conf alias char-major-89 i2c-dev options bttv card=0x64 tuner=38 automute=1 i2c_udelay=128 options tvaudio tda9874a=1 lspci -v: 03:06.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) Subsystem: PROVIDEO MULTIMEDIA Co Ltd Device 952b Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at fdeff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Kernel driver in use: bttv Kernel modules: bttv 03:06.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) Subsystem: PROVIDEO MULTIMEDIA Co Ltd Device 952b Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at fdefe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 dmesg: [ 10.180614] Linux video capture interface: v2.00 [ 10.206630] bttv: driver version 0.9.18 loaded [ 10.206632] bttv: using 8 buffers with 2080k (520 pages) each for capture [ 10.206852] bttv: Bt8xx card found (0). [ 10.207136] ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 [ 10.207140] bttv :03:06.0: PCI INT A - Link[APC1] - GSI 16 (level, low) - IRQ 16 [ 10.207149] bttv0: Bt878 (rev 17) at :03:06.0, irq: 16, latency: 32, mmio: 0xfdeff000 [ 10.207178] bttv0: subsystem: 1540:952b (UNKNOWN) [ 10.207180] please mail id, board name and the correct card= insmod option to linux-media@vger.kernel.org [ 10.207182] bttv0: using: Hercules Smart TV Stereo [card=100,insmod option] [ 10.207184] IRQ 16/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs [ 10.207210] bttv0: gpio: en=, out= in=00ff [init] [ 10.234435] bttv0: tuner type=38 [ 10.744660] tvaudio 1-0058: found tda9874a. [ 10.744662] tvaudio 1-0058: tda9874h/a found @ 0xb0 (bt878 #0 [sw]) [ 11.460205] All bytes are equal. It is not a TEA5767 [ 11.460258] tuner 1-0060: chip found @ 0xc0 (bt878 #0 [sw]) [ 11.810349] tuner-simple 1-0060: creating new instance [ 11.810352] tuner-simple 1-0060: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) [ 11.822666] bttv0: registered device video0 [ 11.822685] bttv0: registered device vbi0 [ 11.822705] bttv0: PLL: 28636363 = 35468950 .. ok -- 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
Problem compiling libv4l 0.6.3
# make make -C libv4lconvert V4L2_LIB_VERSION=0.6.3 all make[1]: Entering directory `/tmp/libv4l-0.6.3/libv4lconvert' gcc -Wp,-MMD,libv4lconvert.d,-MQ,libv4lconvert.o,-MP -c -I../include -I../../../include -fvisibility=hidden -fPIC -DLIBDIR=\/usr/local/lib\ -DLIBSUBDIR=\libv4l\ -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o libv4lconvert.o libv4lconvert.c cc1: error: unrecognized command line option -fvisibility=hidden make[1]: *** [libv4lconvert.o] Error 1 make[1]: Leaving directory `/tmp/libv4l-0.6.3/libv4lconvert' make: *** [all] Error 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
Lifeview hybrid saa7134 pci driver not working anymore pt2
pt1 is here http://linuxtv.org/pipermail/linux-dvb/2009-August/032334.html I have a Lifeview Hybrid Pci card and since around August 2009 the driver doesn't work in 64bit linux but works only in 32bit linux. Now, I am using vanilla 2.6.31.5 source with latest mercurial v4b-dvb snapshot. I tried today again in my 64bit system to see if the driver works but again I discovered that it just doesn't work. I am using the same firmware on both 32 and 64bit linux installations and in 32bits I have no problem, everything works. I am choosing the same options in both 32 and 64bit installations. The error that I get is in the attachement. It complains about firmware but the firmware is exactly the same with my 32bit installation where things work. What's wrong with the saa7134 driver ? Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.15 loaded ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17 saa7134 :05:07.0: PCI INT A - Link[APC2] - GSI 17 (level, low) - IRQ 17 saa7133[0]: found at :05:07.0, rev: 209, irq: 17, latency: 32, mmio: 0xd000 saa7133[0]: subsystem: 5168:3306, board: LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB [card=94,autodetected] saa7133[0]: board init: gpio is 21 IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]: i2c eeprom 00: 68 51 06 33 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: 00 00 62 08 ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 ff 01 16 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 05 01 01 16 32 15 ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff i2c-adapter i2c-2: Invalid 7-bit address 0x7a tuner 2-004b: chip found @ 0x96 (saa7133[0]) tda829x 2-004b: setting tuner address to 61 tda829x 2-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 saa7134 ALSA driver for DMA sound loaded IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]/alsa: saa7133[0] at 0xd000 irq 17 registered as card -1 dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[0]) DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: found firmware revision ea -- invalid tda1004x: trying to boot from eeprom tda1004x: found firmware revision ea -- invalid tda1004x: waiting for firmware upload... saa7134 :05:07.0: firmware: requesting dvb-fe-tda10046.fw tda1004x: Error during firmware upload tda1004x: found firmware revision ea -- invalid tda1004x: firmware upload failed tda827x_probe_version: could not read from tuner at addr: 0xc2
Re: Hint request for driver change
Mauro Carvalho Chehab mchehab at infradead.org writes: It is better to not rename it, to avoid confusion. Thank you for the answer :-) The only problem is that rewriting the full driver I will not be able to test all card supported by previous one (I just own one of them). Anyways I'll start with mine than ask for some test for the others. BTW, did you see my patch for adding Pinnacle PCTV310e support (DVB only) in current driver ? Did I post it correctly or it miss something ? Best regards Massimo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Oct 28 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13168:d6c09c3711b5 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: ERRORS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc3-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add support for Geniatech/MyGica U870 remote control
Hi,
This patch add codes for the Total Media In Hand remote control used by
Geniatech/MyGica U870 and X8507.
Thank's
Signed-off-by: Vagner Nishimoto vnishim...@tutopia.com.br
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-09-20
15:14:20.0 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-10-26
03:34:52.062907991 -0200
@@ -926,6 +926,43 @@ static struct dvb_usb_rc_key dib0700_rc_
{ 0x8618, KEY_RECORD },
{ 0x861a, KEY_STOP },
+
+ /* Key codes for the Total Media In Hand (Geniatech/MyGica U870 remote
control) */
+ { 0x0038, KEY_TV },
+ { 0x000c, KEY_MEDIA },
+ { 0x0001, KEY_1 },
+ { 0x0002, KEY_2 },
+ { 0x0003, KEY_3 },
+ { 0x0004, KEY_4 },
+ { 0x0005, KEY_5 },
+ { 0x0006, KEY_6 },
+ { 0x0007, KEY_7 },
+ { 0x0008, KEY_8 },
+ { 0x0009, KEY_9 },
+ { 0x, KEY_0 },
+ { 0x000a, KEY_MUTE },
+ { 0x0029, KEY_ESC },
+ { 0x0012, KEY_CHANNELUP },
+ { 0x0013, KEY_CHANNELDOWN },
+ { 0x002b, KEY_VOLUMEUP },
+ { 0x002c, KEY_VOLUMEDOWN },
+ { 0x0020, KEY_UP },
+ { 0x0021, KEY_DOWN },
+ { 0x0011, KEY_LEFT },
+ { 0x0010, KEY_RIGHT },
+ { 0x000d, KEY_OK },
+ { 0x001f, KEY_RECORD },
+ { 0x0017, KEY_PLAY },
+ { 0x0016, KEY_PAUSE },
+ { 0x000b, KEY_STOP },
+ { 0x0027, KEY_FASTFORWARD },
+ { 0x0026, KEY_REWIND },
+ { 0x001e, KEY_TIME },
+ { 0x000e, KEY_CAMERA },
+ { 0x002d, KEY_MENU },
+ { 0x000f, KEY_ZOOM },
+ { 0x0014, KEY_SHUFFLE },
+ { 0x0025, KEY_POWER },
};
/* STK7700P: Hauppauge Nova-T Stick, AVerMedia Volar */
--
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
HVR-950Q problem under MythTV
I just completed a fresh install of MythTV 0.22 RC1 on my fully-updated Fedora 11 system. My tuner is an HVR-950Q, connected to cable. The tuner works fine under tvtime (SD) and xine (HD). All MythTV functions work, except LiveTV. The problem is that mythfrontend times out waiting for the HVR-950Q to tune to the first station. This appears to be due to the very long HVR-950Q firmware load time, since no errors are reported by the backend. Unfortunately, mythfrontend has a hard-wired 7 second timeout for most requests sent to the backend. It seems this timeout works fine under normal circumstances for every other tuner MythTV works with. The following is repeated in dmesg after every attempt: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... usb 1-2: firmware: requesting dvb-fe-xc5000-1.6.114.fw xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete... It looks like the HVR-950Q driver reloads the firmware at every possible opportunity, independent of the hardware state, each time either the SD or HD device is opened, such as when changing from an SD channel on /dev/video0 to an HD channel on /dev/dvb/adapter0. Is this necessary? Is it possible to tell the driver to ease up on the firmware reloads? I don't mind if the first attempt fails, but the second attempt should succeed (without a reload). Alternatively, are faster firmware loads possible? Should I open a bug on this? -- 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: HVR-950Q problem under MythTV
On Wed, Oct 28, 2009 at 10:10 PM, Bob Cunningham rcunn...@acm.org wrote: I just completed a fresh install of MythTV 0.22 RC1 on my fully-updated Fedora 11 system. My tuner is an HVR-950Q, connected to cable. The tuner works fine under tvtime (SD) and xine (HD). All MythTV functions work, except LiveTV. The problem is that mythfrontend times out waiting for the HVR-950Q to tune to the first station. This appears to be due to the very long HVR-950Q firmware load time, since no errors are reported by the backend. Unfortunately, mythfrontend has a hard-wired 7 second timeout for most requests sent to the backend. It seems this timeout works fine under normal circumstances for every other tuner MythTV works with. The following is repeated in dmesg after every attempt: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... usb 1-2: firmware: requesting dvb-fe-xc5000-1.6.114.fw xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete... It looks like the HVR-950Q driver reloads the firmware at every possible opportunity, independent of the hardware state, each time either the SD or HD device is opened, such as when changing from an SD channel on /dev/video0 to an HD channel on /dev/dvb/adapter0. Is this necessary? Is it possible to tell the driver to ease up on the firmware reloads? I don't mind if the first attempt fails, but the second attempt should succeed (without a reload). Alternatively, are faster firmware loads possible? Should I open a bug on this? Hello Bob, In order to avoid the firmware reloading condition, you need to add a modprobe option called no_poweroff=1 for the xc5000 driver to your modprobe.conf file and then reboot your computer. I agree that this is a very annoying workaround, but have not had a chance to try to find another solution (the i2c master in the au0828 hardware is poorly designed and this same problem occurs in Windows but the problem is not as noticeable because the Windows application doesn't as aggressively power down the tuner). Also, in order for the video to be rendered properly, you need to make sure your capture resolution for LiveTV mode and the various capture modes is set to 720x480 (the default in MythTV is 480x480). Without this change, the picture will appear to be vertically stretched. This is actually a bug in MythTV not properly handling analog capture products that do not have an onboard hardware scaler (I did work in 0.22 to get the analog support working but have not had an opportunity to fix this bug yet). If you still have trouble, feel free to reply to this message. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-950Q problem under MythTV
On 10/28/2009 08:40 PM, Devin Heitmueller wrote: On Wed, Oct 28, 2009 at 10:10 PM, Bob Cunninghamrcunn...@acm.org wrote: I just completed a fresh install of MythTV 0.22 RC1 on my fully-updated Fedora 11 system. My tuner is an HVR-950Q, connected to cable. The tuner works fine under tvtime (SD) and xine (HD). All MythTV functions work, except LiveTV. The problem is that mythfrontend times out waiting for the HVR-950Q to tune to the first station. This appears to be due to the very long HVR-950Q firmware load time, since no errors are reported by the backend. Unfortunately, mythfrontend has a hard-wired 7 second timeout for most requests sent to the backend. It seems this timeout works fine under normal circumstances for every other tuner MythTV works with. The following is repeated in dmesg after every attempt: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... usb 1-2: firmware: requesting dvb-fe-xc5000-1.6.114.fw xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete... It looks like the HVR-950Q driver reloads the firmware at every possible opportunity, independent of the hardware state, each time either the SD or HD device is opened, such as when changing from an SD channel on /dev/video0 to an HD channel on /dev/dvb/adapter0. Is this necessary? Is it possible to tell the driver to ease up on the firmware reloads? I don't mind if the first attempt fails, but the second attempt should succeed (without a reload). Alternatively, are faster firmware loads possible? Should I open a bug on this? Hello Bob, In order to avoid the firmware reloading condition, you need to add a modprobe option called no_poweroff=1 for the xc5000 driver to your modprobe.conf file and then reboot your computer. I agree that this is a very annoying workaround, but have not had a chance to try to find another solution (the i2c master in the au0828 hardware is poorly designed and this same problem occurs in Windows but the problem is not as noticeable because the Windows application doesn't as aggressively power down the tuner). For F11, I appended the line options xc5000 no_poweroff=1 to /etc/modprobe.d/local.conf Rather than power down (shudder), I did the following: 1. Unplug HVR-950Q 2. rmmod xc5000 3. modprobe xc5000 no_poweroff=1 4. Plug in HVR-950Q Also, in order for the video to be rendered properly, you need to make sure your capture resolution for LiveTV mode and the various capture modes is set to 720x480 (the default in MythTV is 480x480). Without this change, the picture will appear to be vertically stretched. This is actually a bug in MythTV not properly handling analog capture products that do not have an onboard hardware scaler (I did work in 0.22 to get the analog support working but have not had an opportunity to fix this bug yet). Done. If you still have trouble, feel free to reply to this message. Cheers, Devin All is well with the world: The tuner is tuning, MythTV is mythic, and I am a vidiot. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-950Q problem under MythTV
On Thu, Oct 29, 2009 at 12:47 AM, Bob Cunningham rcunn...@acm.org wrote: For F11, I appended the line options xc5000 no_poweroff=1 to /etc/modprobe.d/local.conf Rather than power down (shudder), I did the following: 1. Unplug HVR-950Q 2. rmmod xc5000 3. modprobe xc5000 no_poweroff=1 4. Plug in HVR-950Q You would be shocked how many people have trouble with those four steps. So now I just tell people to reboot. All is well with the world: The tuner is tuning, MythTV is mythic, and I am a vidiot. That's great. Bear in mind that I only did a minimal amount of burn-in under MythTV, so if you see other issues, please speak up. I basically did enough to get rid of the segfaults, show the user video, and cleanup a couple of errors in the mythbackend.log (by implementing the hue and saturation controls). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-950Q problem under MythTV
On 10/28/2009 09:56 PM, Devin Heitmueller wrote: On Thu, Oct 29, 2009 at 12:47 AM, Bob Cunninghamrcunn...@acm.org wrote: For F11, I appended the line options xc5000 no_poweroff=1 to /etc/modprobe.d/local.conf Rather than power down (shudder), I did the following: 1. Unplug HVR-950Q 2. rmmod xc5000 3. modprobe xc5000 no_poweroff=1 4. Plug in HVR-950Q You would be shocked how many people have trouble with those four steps. So now I just tell people to reboot. All is well with the world: The tuner is tuning, MythTV is mythic, and I am a vidiot. That's great. Bear in mind that I only did a minimal amount of burn-in under MythTV, so if you see other issues, please speak up. I basically did enough to get rid of the segfaults, show the user video, and cleanup a couple of errors in the mythbackend.log (by implementing the hue and saturation controls). Devin I spoke too soon: Switching between SD and HD channels (or vice-versa) always works the first time, but generally dies the next time I try. The behavior is very inconsistent: If I switch from SD to HD 720p or higher, the tuner goes away the next time I try to tune an SD channel. If I switch between SD and 480i HD channels, I can do so up to 4 times before it stops working. I can switch among SD channels with no problem, and I can switch between HD channels of any resolution with no problem. Only switching back and forth between HD and SD causes the problem, and it always happens, sooner or later. Is there a way to force a quick dirty device reinitialization? Right now, I'm killing mythfrontend and mythbackend, re-plugging the HVR-950Q, and restarting mythbackend and mythfrontend. Probably overkill. Is there an easier way? -BobC -- 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 1/1] v4l2 doc: Added S/G_ROTATE, S/G_BG_COLOR information
From: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- v4l2-spec/controls.sgml | 20 +++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/v4l2-spec/controls.sgml b/v4l2-spec/controls.sgml index 477a970..a675f30 100644 --- a/v4l2-spec/controls.sgml +++ b/v4l2-spec/controls.sgml @@ -281,10 +281,28 @@ minimum value disables backlight compensation./entry constantV4L2_COLORFX_SEPIA/constant (2)./entry /row row + entryconstantV4L2_CID_ROTATE/constant/entry + entryinteger/entry + entryRotates the image by specified angle. Common angles are 90, + 270 and 180. Rotating the image to 90 and 270 will reverse the height + and width of the display window. It is necessary to set the new height and + width of the picture using S_FMT ioctl, see xref linkend=vidioc-g-fmt according to + the rotation angle selected./entry + /row + row + entryconstantV4L2_CID_BG_COLOR/constant/entry + entryinteger/entry + entrySets the background color on the current output device. + Background color needs to be specified in the RGB24 format. The + supplied 32 bit value is interpreted as bits 0-7 Red color information, + bits 8-15 Green color information, bits 16-23 Blue color + information and bits 24-31 must be zero./entry + /row + row entryconstantV4L2_CID_LASTP1/constant/entry entry/entry entryEnd of the predefined control IDs (currently -constantV4L2_CID_COLORFX/constant + 1)./entry +constantV4L2_CID_BG_COLOR/constant + 1)./entry /row row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] v4l2 doc: Added S/G_ROTATE, S/G_BG_COLOR information
Oops, below patch had wrong subject line (S/G). I just fixed the subject line (to CID_) and attached here. Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -Original Message- From: Hiremath, Vaibhav Sent: Thursday, October 29, 2009 11:13 AM To: linux-media@vger.kernel.org Cc: Hiremath, Vaibhav Subject: [PATCH 1/1] v4l2 doc: Added S/G_ROTATE, S/G_BG_COLOR information From: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- v4l2-spec/controls.sgml | 20 +++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/v4l2-spec/controls.sgml b/v4l2-spec/controls.sgml index 477a970..a675f30 100644 --- a/v4l2-spec/controls.sgml +++ b/v4l2-spec/controls.sgml @@ -281,10 +281,28 @@ minimum value disables backlight compensation./entry constantV4L2_COLORFX_SEPIA/constant (2)./entry /row row + entryconstantV4L2_CID_ROTATE/constant/entry + entryinteger/entry + entryRotates the image by specified angle. Common angles are 90, + 270 and 180. Rotating the image to 90 and 270 will reverse the height + and width of the display window. It is necessary to set the new height and + width of the picture using S_FMT ioctl, see xref linkend=vidioc-g-fmt according to + the rotation angle selected./entry + /row + row + entryconstantV4L2_CID_BG_COLOR/constant/entry + entryinteger/entry + entrySets the background color on the current output device. + Background color needs to be specified in the RGB24 format. The + supplied 32 bit value is interpreted as bits 0-7 Red color information, + bits 8-15 Green color information, bits 16-23 Blue color + information and bits 24-31 must be zero./entry + /row + row entryconstantV4L2_CID_LASTP1/constant/entry entry/entry entryEnd of the predefined control IDs (currently -constantV4L2_CID_COLORFX/constant + 1)./entry +constantV4L2_CID_BG_COLOR/constant + 1)./entry /row row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry -- 1.6.2.4 binMqju8Me6py.bin Description: 0001-v4l2-doc-Added-CID_ROTATE-CID_BG_COLOR-control-information.patch
