no video device
Hi, dvb professionals, I followed the advices on http://www.linuxtv.org/wiki/index.php/How_to_Obtain%2C_Build_and_Install_V4L-DVB_Device_Drivers#Optional_Pre-Compilation_Steps Build and Installation Instructions downloaded the v4l sources via mercurial, make and sudo make install finished without error messages. rebooted the computer dmesg shows the device: --- usb 2-1: new high speed USB device using ehci_hcd and address 6 usb 2-1: configuration #1 chosen from 1 choice usb 2-1: New USB device found, idVendor=0b48, idProduct=300d usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1: Product: TT-USB2.0 usb 2-1: Manufacturer: TechnoTrend usb 2-1: SerialNumber: LHKAMG --- no error if I unplug and plug it on USB again the connected box is a TechnoTrend CT 3560 CI I googled and found chipset names like TDA8274 + TDA10023 did not find anything in wiki, so I could not determine module or driver names to be identified with lsmod. there is no created /dev/dvb or /dev/video device google did not help me answering the question do I need firmware, and if so where to get it uname -a shows Linux rolf9 2.6.28-7.slh.6-sidux-686 #1 SMP PREEMPT Sat Mar 14 02:30:40 UTC 2009 i686 GNU/Linux for now I got stuck. Do you know of a next step towards having tv on my laptop? Rolf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision
On Tuesday 17 March 2009 22:26:16 Dwaine Garden wrote: Invalid link for http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision? It's already been merged in the master, so use http://www.linuxtv.org/hg/v4l-dvb instead. Thanks for testing this! Regards, Hans From: Mauro Carvalho Chehab mche...@infradead.org To: Thierry MERLE thierry.me...@free.fr; Dwaine Garden dwainegar...@rogers.com Cc: Hans Verkuil hverk...@xs4all.nl; linux-media@vger.kernel.org Sent: Thursday, February 26, 2009 2:28:06 PM Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision On Sat, 21 Feb 2009 22:17:10 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision for the following: - v4l2-common: add v4l2_i2c_subdev_addr() - usbvision: convert to v4l2_device/v4l2_subdev. Thierry/Dwaine, Could you please check if everything is ok with usbvision after those patches? Thanks, Hans diffstat: drivers/media/video/usbvision/usbvision-core.c |2 drivers/media/video/usbvision/usbvision-i2c.c | 147 ++-- drivers/media/video/usbvision/usbvision-video.c | 63 -- drivers/media/video/usbvision/usbvision.h |8 - drivers/media/video/v4l2-common.c |9 + include/media/v4l2-common.h |2 6 files changed, 86 insertions(+), 145 deletions(-) Cheers, Mauro -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: About white balance control.
Hi Kim, On Wed, 2009-03-18 at 13:32 +0900, Dongsoo, Nathaniel Kim wrote: Hello, I accidently realized today that I was using white balance control in wrong way. As far as I understand we've got V4L2_CID_AUTO_WHITE_BALANCE which activate auto white balance adjustment in runtime, V4L2_CID_DO_WHITE_BALANCE_TEMPERATURE specifying absolute kelvin value but can't get what V4L2_CID_DO_WHITE_BALANCE is for. My understanding is that V4L2_CID_DO_WHITE_BALANCE enable/disable white balance processing, while with V4L2_CID_DO_WHITE_BALANCE_TEMPERATURE you can specify explicitly ambient temperature. I think after issuing V4L2_CID_AUTO_WHITE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE, the white balance functionality works immediately. Isn't it right? What exactly is the button type V4L2_CID_DO_WHITE_BALANCE for? Because the V4L2 API document says that (the value is ignored). Does that mean that even we have issued V4L2_CID_AUTO_WHITE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE, we can't see the white balance working at that moment? And one more thing. If I want to serve several white balance presets, like cloudy, dawn, sunny and so on, what should I do? I think it should be supported as menu type, but most of drivers are using white balance CID with integer type...then what should I do? Define preset names with kelvin number like this? I also will like to see controls which specify different kind of white balance mode (cloudy, sunny, tungsten...). in this case we can thing about V4L2_CID_WHITE_BALANCE_TEMPERATURE as 'manual' mode, and let other modes to be handled by some clever algorithms ;). IIvanov #define WB_CLOUDY 8000 Pretty confusing... anyone knows what should I do? Nate -- 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: No subsystem id (and therefore no cx88_dvb loaded) after reboot
Ang Way Chuang wrote: I experience similar problem with HVR4000 Lite cards that we have in the lab. The card can't tune after cold boot, but a reboot will fix the problem. I will check whether it has the similar invalid subsystem id problem. Unfortunately, I can't reproduce the cold boot tuning problem now. We'll send syslog information if our partner universities report the similar issue. Sorry. Grant Gardner wrote: I'm looking for some pointers on debugging a problem with my DVICO FusionHDTV Hybrid DVB-T card. The device was working perfectly prior to a reconfiguration of my machine, kernel upgrade etc... Now, on a cold start everything seems to start smoothly but I can't tune channels. Then, after a reboot the device is not detected due to invalid subsystem id. As below lspci reports no subsystem information at all. Comparing the lspci output seems to be around the Region 0: Memory at ee00 v de00, but I'm not sure what this means, and whether fixing the reboot problem will fix the channel tuning problem. Running mythbuntu 8.10 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux lspci -vvnn after cold start 00:0a.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at de00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 Kernel modules: cx8800 00:0a.1 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8811] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1000ns min, 63750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at df00 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel modules: cx88-alsa 00:0a.2 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1500ns min, 22000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at e000 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) currently, though we're working on a commercial implementation of the RTP profile. If you're interested in the GPL'ed UDP profile code, we can email it to you in a week or two (we'll eventually make it available on our website as well, but currently it needs to be cleaned up a bit). T.C. Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 lspci -vvnn after warm reboot 00:0a.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 Kernel modules: cx8800 -- 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
soc-camera - v4l2-device: possible API extension requirements
Hi Hans, I am doing the first step of the soc-camera integration with your v4l2-device API. As discussed on IRC, this first step changes the probing / releasing procedures in soc-camera to match v4l2-device expectations. While at it I came across a few points in your current API, which might need to be changed to be used with soc-camera, or maybe I just misunderstand something and you will be able to resolve my questions: 1. this can be kept, maybe, just it doesn't seem very comfortable to me: the fact that v4l2_i2c_new_subdev() relies on loading of the i2c driver for the subdevice. First, you put the call to request_module() under #ifdef MODULE which means, if v4l2-common.c is compiled as a module, it will also assume that the i2c subdevice driver is a module, which doesn't have to be the case. Secondly, this means manual unloading and loading of the module at a later time will be impossible. No, I do not know why one would need this - apart from during development. But even the inability to do this during driver development already makes this questionable, IMHO. The only way I see possible so far, is, for example, if I have the pxa-camera driver and a sensor driver, then I can first unload the pxa-camera driver, which should cause v4l2_device_unregister_subdev() to be called, then unload the sensor driver, then load the pxa-camera driver again, which should then auto-load the sensor driver. 2. In a comment you write to v4l2_i2c_new_subdev(): /* Load an i2c sub-device. It assumes that i2c_get_adapdata(adapter) returns the v4l2_device and that i2c_get_clientdata(client) returns the v4l2_subdev. */ I don't think this is possible with generic SoC i2c adapters. On soc-camera systems v4l2 subdevices are connected to generic i2c busses, so, you cannot require, that i2c_get_adapdata(adapter) returns the v4l2_device. 3. Currently soc-camera works in a way, that during probing of an i2c (sub)device, the Master Clock of the host camera interface is turned on, after the probing it is turned off again. Then it is turned on at first open() and off at last close(). This should also be possible with the module autoloading in v4l2_i2c_new_subdev(), but this adds even more fragileness to the system. I think, a simple addition to the v4l2-device API could solve this problems and make the API more transparent: 1. hi, I am driver X's probing routine, going to probe device Y, please, turn it on (action: master clock on) 2. probing for device Y completed (un)successfully (action: master clock off, if successful - create /dev/videoY) 3. driver X is being unloaded, I am releasing device Y (action: rip /dev/videoY) We could agree on keeping /dev/videoY even when no sensor driver is present and just return -ENODEV on open(), and thus simplify the above but I am not sure if this is desired. I am sure I will have more questions or suggestions, I will keep posting to this thread as they appear. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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: soc-camera - v4l2-device: possible API extension requirements
Hi Guennadi, Hi Hans, I am doing the first step of the soc-camera integration with your v4l2-device API. As discussed on IRC, this first step changes the probing / releasing procedures in soc-camera to match v4l2-device expectations. While at it I came across a few points in your current API, which might need to be changed to be used with soc-camera, or maybe I just misunderstand something and you will be able to resolve my questions: 1. this can be kept, maybe, just it doesn't seem very comfortable to me: the fact that v4l2_i2c_new_subdev() relies on loading of the i2c driver for the subdevice. First, you put the call to request_module() under #ifdef MODULE which means, if v4l2-common.c is compiled as a module, it will also assume that the i2c subdevice driver is a module, which doesn't have to be the case. Ah, good catch. That's not right. The intention is to test whether module support is configured at all in the kernel, but I think that is CONFIG_MODULE or something like that. I'll change this. Secondly, this means manual unloading and loading of the module at a later time will be impossible. No, I do not know why one would need this - apart from during development. But even the inability to do this during driver development already makes this questionable, IMHO. The only way I see possible so far, is, for example, if I have the pxa-camera driver and a sensor driver, then I can first unload the pxa-camera driver, which should cause v4l2_device_unregister_subdev() to be called, then unload the sensor driver, then load the pxa-camera driver again, which should then auto-load the sensor driver. In v4l devices these i2c devices are an integral part of the v4l device. It is not like the sensor i2c devices that are basically independent devices. Also, many i2c drivers used by v4l have internal state, so unloading them on the fly and reloading them later will in general not work. If a v4l driver loads an i2c module and it can obtain a v4l2_subdev pointer successfully, then it increases the module's refcount to prevent it from being unloaded. This is by design. Without autoprobing I also see no point in allowing an i2c module to be unloaded while in use. Reloading it won't re-attach it to the adapter anyway. BTW, when developing I usually run 'make unload' from the top v4l-dvb directory. That will unload all v4l drivers. 2. In a comment you write to v4l2_i2c_new_subdev(): /* Load an i2c sub-device. It assumes that i2c_get_adapdata(adapter) returns the v4l2_device and that i2c_get_clientdata(client) returns the v4l2_subdev. */ I don't think this is possible with generic SoC i2c adapters. On soc-camera systems v4l2 subdevices are connected to generic i2c busses, so, you cannot require, that i2c_get_adapdata(adapter) returns the v4l2_device. Good point, I'll look at this. I don't think it is difficult to change, although I will probably wait until several pending driver conversions are merged. Then I can fix this in one sweep. 3. Currently soc-camera works in a way, that during probing of an i2c (sub)device, the Master Clock of the host camera interface is turned on, after the probing it is turned off again. Then it is turned on at first open() and off at last close(). This should also be possible with the module autoloading in v4l2_i2c_new_subdev(), but this adds even more fragileness to the system. I think, a simple addition to the v4l2-device API could solve this problems and make the API more transparent: 1. hi, I am driver X's probing routine, going to probe device Y, please, turn it on (action: master clock on) 2. probing for device Y completed (un)successfully (action: master clock off, if successful - create /dev/videoY) 3. driver X is being unloaded, I am releasing device Y (action: rip /dev/videoY) We could agree on keeping /dev/videoY even when no sensor driver is present and just return -ENODEV on open(), and thus simplify the above but I am not sure if this is desired. I don't follow you. It is the adapter driver that controls which subdevs are loaded/probed, when they are loaded or unloaded and it can also decide when to start/stop the master clock. This new situation is different in that loading an i2c module will no longer work, the initiative has to come from the adapter/bridge/host/whatever driver who determines what has to be done based on platform board info. I am sure I will have more questions or suggestions, I will keep posting to this thread as they appear. Looking forward to this! Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: About white balance control.
Hi Ivan, 2009/3/18 Ivan T. Ivanov iiva...@mm-sol.com: Hi Kim, On Wed, 2009-03-18 at 13:32 +0900, Dongsoo, Nathaniel Kim wrote: Hello, I accidently realized today that I was using white balance control in wrong way. As far as I understand we've got V4L2_CID_AUTO_WHITE_BALANCE which activate auto white balance adjustment in runtime, V4L2_CID_DO_WHITE_BALANCE_TEMPERATURE specifying absolute kelvin value but can't get what V4L2_CID_DO_WHITE_BALANCE is for. My understanding is that V4L2_CID_DO_WHITE_BALANCE enable/disable white balance processing, while with V4L2_CID_DO_WHITE_BALANCE_TEMPERATURE you can specify explicitly ambient temperature. OK, then according to your explanation DO_WHITE_BALANCE is only for AUTO_WHITE_BALANCE. Am I following? Because only auto white balance mode does processing and make changes in color temperature while preview is working. I think after issuing V4L2_CID_AUTO_WHITE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE, the white balance functionality works immediately. Isn't it right? What exactly is the button type V4L2_CID_DO_WHITE_BALANCE for? Because the V4L2 API document says that (the value is ignored). Does that mean that even we have issued V4L2_CID_AUTO_WHITE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE, we can't see the white balance working at that moment? And one more thing. If I want to serve several white balance presets, like cloudy, dawn, sunny and so on, what should I do? I think it should be supported as menu type, but most of drivers are using white balance CID with integer type...then what should I do? Define preset names with kelvin number like this? I also will like to see controls which specify different kind of white balance mode (cloudy, sunny, tungsten...). in this case we can thing about V4L2_CID_WHITE_BALANCE_TEMPERATURE as 'manual' mode, and let other modes to be handled by some clever algorithms ;). If there isn't any driver which is driving white balance with menu type, there should be some reason for that. I want to make it clear if I could. I hope Hans or other maintainer could answer this. Cheers, Nate IIvanov #define WB_CLOUDY 8000 Pretty confusing... anyone knows what should I do? Nate -- 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 -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
Terratec Cinergy C
I just got a Terratec Cinergy C PCI HD CI, and as often happens, I notice problems right after the buy. In this case, it seems that CAM support is not available. While preparing to return the card, I wanted to check whether the support is expected soon. However, I have not been able to learn what the issues are from reading the archives. Can someone enlighten me? As a matter of principle, I would prefer getting this to work, so if I can help out with testing or even programming, do let me know. 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: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2/
On Mon, 16 Mar 2009 14:12:19 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Mon, Mar 16, 2009 at 2:05 PM, Trent Piepho xy...@speakeasy.org wrote: On Sun, 15 Mar 2009, Devin Heitmueller wrote: au0828: remove memset calls in v4l2 routines. The userland callers are responsible for clearing the output buffers, so remove the unneeded memset calls. A driver should not assume that _userspace_ has cleared the buffers. In some cases userspace is supposed to clear certain fields, but you shouldn't assume it. AFAIK, for read-only ioctls there is no expectation at all that userspace will clear the buffer. Your patch is still right though, as now the videodev core will take care of this so individual drivers don't have to. Thanks for the feedback. Admittedly I just took Mauro's word that the buffers need to be cleared without fully investigating what is responsible. I guess I jumped to the conclusion that it was done in userland, when in fact it is done in the videodev core. My mistake. The cleanups are now done at videodev core, thanks to a Trent's patch. That's why we don't need to do it inside the drivers anymore. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About white balance control.
Thank you Pingchart. So, V4L2_CID_DO_WHITE_BALANCE acts WB adjustment at every single time it has issued when device is in manual WB mode like V4L2_CID_WHITE_BALANCE_TEMPERATURE? Now I get it. But CID still missing for white balance presets like cloudy, sunny, fluorescentand so on. I think some sort of menu type CID could be useful to handle them, because WB presets differ for each devices. Cheers, Nate 2009/3/18 Laurent Pinchart laurent.pinch...@skynet.be: Hi Kim, On Wednesday 18 March 2009 05:32:08 Dongsoo, Nathaniel Kim wrote: Hello, I accidently realized today that I was using white balance control in wrong way. As far as I understand we've got V4L2_CID_AUTO_WHITE_BALANCE which activate auto white balance adjustment in runtime, V4L2_CID_DO_WHITE_BALANCE_TEMPERATURE specifying absolute kelvin value I suppose you mean V4L2_CID_WHITE_BALANCE_TEMPERATURE here. but can't get what V4L2_CID_DO_WHITE_BALANCE is for. I think after issuing V4L2_CID_AUTO_WHITE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE, the white balance functionality works immediately. Isn't it right? What exactly is the button type V4L2_CID_DO_WHITE_BALANCE for? Because the V4L2 API document says that (the value is ignored). Does that mean that even we have issued V4L2_CID_AUTO_WHITE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE, we can't see the white balance working at that moment? V4L2_CID_AUTO_WHITE_BALANCE to enables or disables automatic white balance adjustment. When automatic white balance is enabled the device adjusts the white balance continuously. V4L2_CID_WHITE_BALANCE_TEMPERATURE controls the white balance adjustment manually. The control is only effective when automatic white balance is disabled. V4L2_CID_DO_WHITE_BALANCE instructs the device to run the automatic white balance adjustment algorithm once and use the results for white balance correction. It only makes sense when automatic white balance is disabled. And one more thing. If I want to serve several white balance presets, like cloudy, dawn, sunny and so on, what should I do? I think it should be supported as menu type, but most of drivers are using white balance CID with integer type...then what should I do? Define preset names with kelvin number like this? #define WB_CLOUDY 8000 Pretty confusing... anyone knows what should I do? Best regards, Laurent Pinchart -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
gspca/v4l - HP Webcam 1.3 - Device Request
Hope this is the correct place for requesting to add a device. I'm also assuming that it's a gspca/VC032x driver problem, as it's counter-part in windows in usbvm326. Name: HP Webcam 1.3 Megapixal (USB) Model: rd345aa USB_id: 15b8:6001 Env: Suse 11.1 (Kernel 2.6.27 64bit) uname: Linux liana 2.6.27.19-3.2-default #1 SMP 2009-02-25 15:40:44 +0100 x86_64 x86_64 x86_64 GNU/Linux v4l 0.5.8-0 (packaged with Suse)... (hacked from gspca-3b1ce192115d.tar.bz2) (d/l'ed from linuxtv) Toshiba P205D-7438 AMD Athlon X2 - see lspci output at bottom for for info Synopsis: Runs with driver usbvm326 under windows. tried hacking VC032x.c, forcing use of... BRIDGE_VC0323 = got a constant framebuffer overruns, then tried, BRIDGE_VC0321 = ran, but picture out of sync and possibly b/w picture (hard to tell). Sorry, but my so-called expertise stops about here. Outputs to follow. Thank you, Diana 'dmesg' output Mar 16 15:18:49 liana kernel: usb 1-5: new high speed USB device using ci_hcd and address 3 Mar 16 15:18:50 liana kernel: usb 1-5: configuration #1 chosen from 1 choice Mar 16 15:18:50 liana kernel: usb 1-5: New USB device found, idVendor=15b8, idProduct=6001 Mar 16 15:18:50 liana kernel: usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Mar 16 15:18:50 liana kernel: usb 1-5: Product: HP Webcam Mar 16 15:18:50 liana kernel: usb 1-5: Manufacturer: HP Mar 16 15:18:50 liana kernel: usbcore: registered new interface driver snd-usb-audio 'lsusb -v' result: Bus 001 Device 003: ID 15b8:6001 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x15b8 idProduct 0x6001 bcdDevice1.00 iManufacturer 1 HP iProduct2 HP Webcam iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 385 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 7 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 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 7 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x0080 1x 128 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 2 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3
Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic
On Wed, Mar 18, 2009 at 3:51 AM, Timothy D. Lenz tl...@vorgon.com wrote: Anyone know how to get the crash data to a log file? A way to redirect main monitor to an ssh client or second linux computer through serial port and null modem cable? See the Documentation/serial-console.txt file in your kernel source tree. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Sat, 14 Mar 2009 16:49:40 +0100
Hans Verkuil hverk...@xs4all.nl wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
following:
- v4l2-device: add v4l2_device_disconnect
- v4l2: call v4l2_device_disconnect in USB drivers.
- tvaudio: add tda9875 support.
Hmm...
tvaudio: add tda9875 support.
From: Hans Verkuil hverk...@xs4all.nl
This change allows bttv to use tvaudio for this device. Since this device
has the same i2c address as the tda9874 we need to support both in the same
tvaudio driver. This makes it possible for tvaudio to detect which chip is
used. Originally the tda9875 was only available in the dedicated tda9875
driver, but that makes life very hard for bttv since loading tvaudio might
misdetect a tda9875 as a tda9874.
I think we've already discussed about this patch (it were part of your bttv RFC
tree): please remove the mute bug fix for the tda9875 addition.
@@ -1519,23 +1651,26 @@ static int tvaudio_g_ctrl(struct v4l2_su
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- ctrl-value=chip-muted;
+ if (!(desc-flags CHIP_HAS_INPUTSEL))
+ break;
+ ctrl-value = chip-muted;
return 0;
The other changesets are OK.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2/
On Sun, 15 Mar 2009 20:30:54 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: Hello Mauro, Please issue a pull request from http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2 for the following: au0828: remove memset calls in v4l2 routines. au0828: remove some unneeded braces au0828: add entry for undefined input type au0828/au8522: Codingstyle fixes au0828: rename macro for currently non-function VBI support au8522: move the analog decoder source file au0828: finish videodev/subdev conversion au8522: finish conversion to v4l2_device/subdev I believe this addresses all the outstanding comments from both you and Hans. Applied, thanks. I'll likely need to move some hunks from one changeset into another, due to au8522: move the analog decoder source file to avoid -git bisect breakages. I do recommend for all new drivers to have a completely separate patch for the Kbuild changes, since the trivial fix for git bisect is generally just moving the Kconfig/Makefile changes to be the last patch at the series. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2/
On Wed, Mar 18, 2009 at 11:13 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I'll likely need to move some hunks from one changeset into another, due to au8522: move the analog decoder source file to avoid -git bisect breakages. No problem. I did put the original move in the same changeset as the change to the Makefile in an attempt to avoid bisect breakage, but this obviously didn't take into account the first move which broke the in-kernel build. Thanks, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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
ISP Configuration for RAW Bayer sensor
Hi, I am working with MT9V023 RAW sensor. The data format from the sensor is B G B G B G B G ... G R G R G R G R ... B G B G B G B G ... G R G R G R G R [ Format 1] The sources I am using for ISP drivers are pulled on top of linux-omap-2.6.29-rc7 from [git pull git://git.gitorious.org/omap3camera/mainline.git v4l iommu omap3camera base]. I want to use the ISP on the OMAP for doing interpolation and format conversion to UYVY. I am able to capture the images from the sensor, however I notice that the color information is missing. I dug the sources and found that in the RAW capture mode ISP is getting configured to input format G R G R G R G R ... B G B G B G B G ... G R G R G R G R ... B G B G B G B G ... [Format 2] Has anyone tried sensors with BGGR ( Format 1) on OMAP? Can anyone give me some pointers or information on how to configure ISP for BGGR (Format 1) Thanks in advance for all the help. Thanks, Suresh -- 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] gspca: add missing .type field check in VIDIOC_G_PARM
From: Márton Németh nm...@freemail.hu
The gspca webcam driver does not check the .type field of struct
v4l2_streamparm.
This field is an input parameter for the driver according to V4L2 API
specification,
revision 0.24 [1]. Add the missing check.
The missing check was recognised by v4l-test 0.10 [2] together with
gspca_sunplus driver
and with Trust 610 LCD pow...@m ZOOM webcam. This patch was verified also with
v4l-test 0.10.
References:
[1] V4L2 API specification, revision 0.24
http://v4l2spec.bytesex.org/spec/r11680.htm
[2] v4l-test: Test environment for Video For Linux Two API
http://v4l-test.sourceforge.net/
Signed-off-by: Márton Németh nm...@freemail.hu
---
--- linux-2.6.29-rc8/drivers/media/video/gspca/gspca.c.orig 2009-03-14
12:29:38.0 +0100
+++ linux-2.6.29-rc8/drivers/media/video/gspca/gspca.c 2009-03-18
16:51:03.0 +0100
@@ -1320,6 +1320,9 @@ static int vidioc_g_parm(struct file *fi
{
struct gspca_dev *gspca_dev = priv;
+ if (parm-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
memset(parm, 0, sizeof *parm);
parm-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
parm-parm.capture.readbuffers = gspca_dev-nbufread;
--
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: soc-camera - v4l2-device: possible API extension requirements
On Wednesday 18 March 2009 09:41:58 Hans Verkuil wrote: Hi Guennadi, 2. In a comment you write to v4l2_i2c_new_subdev(): /* Load an i2c sub-device. It assumes that i2c_get_adapdata(adapter) returns the v4l2_device and that i2c_get_clientdata(client) returns the v4l2_subdev. */ I don't think this is possible with generic SoC i2c adapters. On soc-camera systems v4l2 subdevices are connected to generic i2c busses, so, you cannot require, that i2c_get_adapdata(adapter) returns the v4l2_device. Good point, I'll look at this. I don't think it is difficult to change, although I will probably wait until several pending driver conversions are merged. Then I can fix this in one sweep. The fix for this is simple: just add an extra struct v4l2_device to v4l2_i2c_new_(probed_)device and let those functions use that instead of calling i2c_get_adapdata(). It's the only place where it is currently used. But I'm going to postpone implementing this until all outstanding conversion trees are merged. However, you can just do it yourself while working on the soc-camera conversion. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: SNR status for demods
I have updated my compiled list of the various demods and how they currently report SNR info (including feedback from people in the last round). http://www.devinheitmueller.com/snr.txt What about signal strength and BER readout in parallel for each device listed here? Needs the same docs and would not add too much work.. tda10021: MSE[7..0] (= reg 0x18 ) Mean Square Error of the demodulated output signal. MSE can be used as a representation of the signal quality. u8 quality = ~tda10021_readreg(state, 0x18); *snr = (quality 8) | quality; ves1820:the same. tda10023: seems to be the same. (no info, but chip is very close to tda10021) -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-common: remove incorrect MODULE test - au0828: fix compilation on kernels 2.6.20 and 2.6.21. - au8522: fix compilation warning. - mt9v022: fix compilation warning for kernels 2.6.26. Devin, please note the au changes I made. The au8522 change we've discussed already (normal_i2c isn't needed for old kernels), the au0828 change simply adds the linux/mm.h header which turns out to be needed on older kernels. Thanks, Hans diffstat: dvb/frontends/au8522_decoder.c |6 -- video/au0828/au0828-video.c|1 + video/mt9v022.c|4 video/v4l2-common.c|8 4 files changed, 13 insertions(+), 6 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Wed, Mar 18, 2009 at 3:46 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-common: remove incorrect MODULE test - au0828: fix compilation on kernels 2.6.20 and 2.6.21. - au8522: fix compilation warning. - mt9v022: fix compilation warning for kernels 2.6.26. Devin, please note the au changes I made. The au8522 change we've discussed already (normal_i2c isn't needed for old kernels), the au0828 change simply adds the linux/mm.h header which turns out to be needed on older kernels. Yeah, the au* changes look fine to me. I just didn't get a chance to cut the normal_i2c entry (I was slated to do it this week). Thanks, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: Topro 6800 driver [JPEG decoding solved]
Thomas Kaiser wrote: Hello Anders Good news, I could decode a frame which I extracted from the usbsnoobs I did :-). See attached picture frame3-03.jpg. It uses the quality 0. Your black frame you sent me gets now correctly decode, too (frameA-01.jpg) I found the Huffman table in the Windoz driver file (TP6810.sys) at offset 0x2a59c. The QTable which I found in a text file on my Windoz box can be found in this driver file, also. I attached some binary files which I used to build the 2 attached jpeg. For example use: cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin frame3-03.jpg to make the picture frame3-03.jpg. This information should the cam get going in Linux ;-) Happy Hacking, Thomas PS: I sent this to the linux-media mail list, because somebody else is interested about this information, too. Just some comments about the observation you made on the frame header: ff d8 ff fe 28 3c 01 - Byte 6: Yes, it is the current quality setting - Byte 4 5: I think it is related to resolution. My snoops were done with 320x240 (0x141e) and Anders were made with 640x480 (0x283c), twice as big! - The rest is static Thomas -- 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: REVIEW: bttv conversion to v4l2_subdev
On Wednesday 18 March 2009 21:48:45 Trent Piepho wrote: On Sun, 15 Mar 2009, Hans Verkuil wrote: On Sunday 15 March 2009 18:28:42 Trent Piepho wrote: On Sun, 15 Mar 2009, Hans Verkuil wrote: On Sunday 15 March 2009 17:04:43 Trent Piepho wrote: On Sun, 15 Mar 2009, Hans Verkuil wrote: Hi Mauro, Can you review my ~hverkuil/v4l-dvb-bttv2 tree? It would be a lot easier if you would provide patch descriptions. Here it is: - bttv: convert to v4l2_subdev. You aren't even trying. I could easily write two pages on this patch. You are right. Mauro already knew about all this, but since I posted it to linux-media as well I should have given a more detailed explanation. The problem is that these changes are going into the kernel with NO documentation what so ever. Which is I feel is completely unacceptable. What will happens is that 6 months to two years from now the number of people who use this code will increase by orders of magnitude as the distros switch their stock kernels to ones that have it. Module options that people have been using for years will disappear. All the various distro's hardware auto-configuration programs will need to be changed. The way the helper modules are loaded and unloaded has completely changed. Someone's obscure card is going to break. People with out of tree modifications for specialized hardware will find their patches no longer apply. So, two years from now, someone is going to wonder WTF happened to bttv and they will check the change log. And they'll find convert to v4l2_subdev. Which tells them *nothing*! YOU will wonder two years from now why you did something a certain way in the bttv driver, but since you didn't bother to document anything when you did it, you'll just gave to figure it out all over again. Someone is going to want to fix a bug in the bttv driver years from now and they are going to look at the changelog to see how the driver works. If they wonder what the MUXSEL() macro is for, my changelog entry describes how and why it's there. If they wonder why the unused has_saa6588 field is there, your changelog entry tells them nothing at all about it. Proper documentation of patches isn't just for *before* they go into the kernel, out of consideration for developers who will review the patch and out respect to other developers who also need to understand what is going on in the code *we all* work on. It is also there for after the patch is in the kernel, to provide documentation about how the driver works, why things are they way they are, the user visible affects of driver changes, and so on for users, developers who will look at the code in the future, and even to refresh the memory of the author of the patch themselves. Trent, those changes do not go into the kernel. As the subject clearly stated I put it up for *review*, precisely for feedback like this. I'm redoing the bttv tree incorporating all the feedback, so it will be amply documented. No need to keep going on and on about it. I know that I should do better in my commit comments and you are free to request improvements if they are unclear. But really, you've made you point loud and clear. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
[PULL] http://hg.jannau.net/hdpvr-merge/ - Hauppauge HD PVR driver
Hi Mauro, please pull from http://hg.jannau.net/hdpvr-merge/ for the Hauppauge HD PVR driver. The repo has only two changesets. One adding V4L2_CID_SHARPNESS to a method in v4l2-common.c and the complete driver. The history of the driver will be available at http://hg.jannau.net/hdpvr/ so I think it's not worth adding the complete history to the kernel repo. [Janne Grunau j...@jannau.net] adds V4L2_CID_SHARPNESS to v4l2_ctrl_query_fill() V4L2 Driver for the Hauppauge HD PVR usb capture device diffstat linux/drivers/media/video/hdpvr/Kconfig | 10 linux/drivers/media/video/hdpvr/Makefile |7 linux/drivers/media/video/hdpvr/hdpvr-control.c | 201 +++ linux/drivers/media/video/hdpvr/hdpvr-core.c | 446 +++ linux/drivers/media/video/hdpvr/hdpvr-i2c.c | 145 ++ linux/drivers/media/video/hdpvr/hdpvr-video.c | 1228 ++ linux/drivers/media/video/hdpvr/hdpvr.h | 298 + linux/drivers/media/video/Kconfig |2 linux/drivers/media/video/Makefile|2 linux/drivers/media/video/v4l2-common.c |1 linux/include/linux/i2c-id.h |1 11 files changed, 2341 insertions(+) -- 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] gspca: add missing .type field check in VIDIOC_G_PARM
2009/3/18 Németh Márton nm...@freemail.hu:
From: Márton Németh nm...@freemail.hu
The gspca webcam driver does not check the .type field of struct
v4l2_streamparm.
This field is an input parameter for the driver according to V4L2 API
specification,
revision 0.24 [1]. Add the missing check.
The missing check was recognised by v4l-test 0.10 [2] together with
gspca_sunplus driver
and with Trust 610 LCD pow...@m ZOOM webcam. This patch was verified also
with
v4l-test 0.10.
References:
[1] V4L2 API specification, revision 0.24
http://v4l2spec.bytesex.org/spec/r11680.htm
[2] v4l-test: Test environment for Video For Linux Two API
http://v4l-test.sourceforge.net/
Signed-off-by: Márton Németh nm...@freemail.hu
---
--- linux-2.6.29-rc8/drivers/media/video/gspca/gspca.c.orig 2009-03-14
12:29:38.0 +0100
+++ linux-2.6.29-rc8/drivers/media/video/gspca/gspca.c 2009-03-18
16:51:03.0 +0100
@@ -1320,6 +1320,9 @@ static int vidioc_g_parm(struct file *fi
{
struct gspca_dev *gspca_dev = priv;
+ if (parm-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
memset(parm, 0, sizeof *parm);
parm-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
^^^
This line should be deleted as it's no longer needed.
parm-parm.capture.readbuffers = gspca_dev-nbufread;
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
Re: [PULL] http://hg.jannau.net/hdpvr-merge/ - Hauppauge HD PVR driver
On Wed, 18 Mar 2009 22:23:37 +0100
Janne Grunau j...@jannau.net wrote:
Hi Mauro,
please pull from http://hg.jannau.net/hdpvr-merge/ for the Hauppauge HD
PVR driver.
The repo has only two changesets. One adding V4L2_CID_SHARPNESS to a
method in v4l2-common.c and the complete driver. The history of the
driver will be available at http://hg.jannau.net/hdpvr/ so I think it's
not worth adding the complete history to the kernel repo.
[Janne Grunau j...@jannau.net]
adds V4L2_CID_SHARPNESS to v4l2_ctrl_query_fill()
V4L2 Driver for the Hauppauge HD PVR usb capture device
diffstat
linux/drivers/media/video/hdpvr/Kconfig | 10
linux/drivers/media/video/hdpvr/Makefile |7
linux/drivers/media/video/hdpvr/hdpvr-control.c | 201 +++
linux/drivers/media/video/hdpvr/hdpvr-core.c | 446 +++
linux/drivers/media/video/hdpvr/hdpvr-i2c.c | 145 ++
linux/drivers/media/video/hdpvr/hdpvr-video.c | 1228
++
linux/drivers/media/video/hdpvr/hdpvr.h | 298 +
linux/drivers/media/video/Kconfig |2
linux/drivers/media/video/Makefile|2
linux/drivers/media/video/v4l2-common.c |1
linux/include/linux/i2c-id.h |1
11 files changed, 2341 insertions(+)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Janne,
Everything looks ok, except for this part of your code:
+static long hdpvr_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
+{
+ struct hdpvr_fh *fh = (struct hdpvr_fh *)filp-private_data;
+ struct hdpvr_device *dev = fh-dev;
+ int res;
+
+ if (video_is_unregistered(dev-video_dev))
+ return -EIO;
+
+ mutex_lock(dev-io_mutex);
+ switch (cmd) {
+ case VIDIOC_TRY_ENCODER_CMD:
+ case VIDIOC_ENCODER_CMD: {
+ struct v4l2_encoder_cmd *enc = (struct v4l2_encoder_cmd *)arg;
+ int try = cmd == VIDIOC_TRY_ENCODER_CMD;
+
+ memset(enc-raw, 0, sizeof(enc-raw));
+ switch (enc-cmd) {
+ case V4L2_ENC_CMD_START:
+ enc-flags = 0;
+ if (try)
+ return 0;
+ res = hdpvr_start_streaming(dev);
+ break;
+ case V4L2_ENC_CMD_STOP:
+ if (try)
+ return 0;
+ res = hdpvr_stop_streaming(dev);
+ break;
+ default:
+ v4l2_dbg(MSG_INFO, hdpvr_debug, dev-video_dev,
+Unsupported encoder cmd %d\n, enc-cmd);
+ return -EINVAL;
+ }
+ break;
+ }
+ default:
+ res = video_ioctl2(filp, cmd, arg);
+ }
+ mutex_unlock(dev-io_mutex);
+ return res;
+}
Why haven't you just used the two video_ioctl2 handlers for vidioc_encoder_cmd
and vidioc_try_encoder_cmd, like ivtv and cx18, instead of the above code?
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://hg.jannau.net/hdpvr-merge/ - Hauppauge HD PVR driver
On Wed, Mar 18, 2009 at 08:12:17PM -0300, Mauro Carvalho Chehab wrote:
Everything looks ok, except for this part of your code:
+static long hdpvr_ioctl(struct file *filp, unsigned int cmd, unsigned long
arg)
+{
+ struct hdpvr_fh *fh = (struct hdpvr_fh *)filp-private_data;
+ struct hdpvr_device *dev = fh-dev;
+ int res;
+
+ if (video_is_unregistered(dev-video_dev))
+ return -EIO;
+
+ mutex_lock(dev-io_mutex);
+ switch (cmd) {
+ case VIDIOC_TRY_ENCODER_CMD:
+ case VIDIOC_ENCODER_CMD: {
+ struct v4l2_encoder_cmd *enc = (struct v4l2_encoder_cmd *)arg;
+ int try = cmd == VIDIOC_TRY_ENCODER_CMD;
+
+ memset(enc-raw, 0, sizeof(enc-raw));
+ switch (enc-cmd) {
+ case V4L2_ENC_CMD_START:
+ enc-flags = 0;
+ if (try)
+ return 0;
+ res = hdpvr_start_streaming(dev);
+ break;
+ case V4L2_ENC_CMD_STOP:
+ if (try)
+ return 0;
+ res = hdpvr_stop_streaming(dev);
+ break;
+ default:
+ v4l2_dbg(MSG_INFO, hdpvr_debug, dev-video_dev,
+Unsupported encoder cmd %d\n, enc-cmd);
+ return -EINVAL;
+ }
+ break;
+ }
+ default:
+ res = video_ioctl2(filp, cmd, arg);
+ }
+ mutex_unlock(dev-io_mutex);
+ return res;
+}
Why haven't you just used the two video_ioctl2 handlers for vidioc_encoder_cmd
and vidioc_try_encoder_cmd, like ivtv and cx18, instead of the above code?
They were missing in the video_ioctl2 handler then I wrote the code.
I forgot to check if that's still the case. I'll change it in a minute.
Janne
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic
On Wed, 2009-03-18 at 19:16 -0700, Timothy D. Lenz wrote: I've added console=ttyS0,115200 console=tty0 to the kernel command line options and with out the console=tty0 part the dump no longer shows on the monitor, so redirect seems to work but loging the serial port on a second computer gets nothing. I tested the connection with echo and that worked but the kernel dump won't go out the port. The last 2 lines of the screen are: EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESP 0068:f778dd24 Kernel panic - not syncing: Fatal exception in interrupt Hmm. The only thing in the cx23885 driver that tries to schedule work, and thus the only thing that could possibly pass in a bad argument, is the netup_ci_slot_status() function. It gets called when an IRQ comes in indicating a GPIO[01] event, and the driver thinks the card is a NetUp Dual DVB-S2 CI card. That's consistent with the fatal exception in interrupt, but without the backtrace, one can't be completely sure this call to queue work was initiated by the cx23885 driver and a problem with cx23885 data structures. (But it is the most likely scenario, IMO) I just can't see how netup_ci_slot_status() get's called for your card. Any way to get the dump to go out the serial port? Does 9600 baud help? (Just a guess.) Regards, Andy - Original Message - From: Andy Walls awa...@radix.net To: Timothy D. Lenz tl...@vorgon.com Cc: linux-media@vger.kernel.org Sent: Monday, March 16, 2009 6:07 PM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic On Mon, 2009-03-16 at 17:46 -0700, Timothy D. Lenz wrote: When it panics, there is no log, just a bunch of stuff that that scrolls fast on the main monitor then cold lock. No way to scroll back. Not even Shift+PageUp ? I looked at the logs and the ones that are text had nothing about it. Digital camera or pencil and paper will be least complex way to capture the ooops data. Please don't leave out the Code bytes at the bottom and do your best to make sure those are absolutely correct. Regards, Andy - Original Message - From: Steven Toth st...@linuxtv.org To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Monday, March 16, 2009 6:59 AM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic Timothy D. Lenz wrote: Using kernel 2.6.26.8 and v4l from a few days ago. When I modprobe cx23885 to load the drivers, I get kernel panic We'll need the oops. - Steve ___ 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 ___ 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
