Re: image quality of Labtec Webcam 2200
On Fri, 11 Sep 2009 09:09:20 +0200 Németh Márton wrote: > You can find my results at > http://v4l-test.sourceforge.net/results/test-20090911/index.html > There are three types of problems: a) Sometimes the picture contains > a 8x8 pixel error, like in image #9 > http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 > b) Sometimes the brightness of the half picture is changed, like in > images #7, #36 and #37 > http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 > http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 > http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 > c) Sometimes the libv4l cannot convert the raw image and the errno is > set to EAGAIN (11), for example image #1, #2 and #3 > > Do you know how can I fix these problems? The error EAGAIN is normal when decoding pac7311 images, because they are rotated 90°. But this error should occur one time only. I looked at the raw image #1, and it seems that there are JPEG errors inside (sequences ff ff). There should be a problem in the pac7311 driver. Hans, may you confirm? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: ZC0301 webcam, successful trace from spca5xx driver
On Sat, 12 Sep 2009 15:36:20 +0700 "test.r test.r" wrote: > Using the old spca5xx with Debian kernel 2.6.18 the webcam is working. > "Release 0.60.00 as spca5xx-v4l1-goodbye" available in Debian etch. > The traces below may help someone wanting to port this webcam to the > new driver architecture. Hi Guillaume, The spca5xx-v4l1-goodbye is for kernels < 2.6.11. Does the version gspcav1-20071224.tar.gz work too? I checked the source code of both gspca v1 and gspca v2 without finding any difference. A trace of gspca v1 may help. May you send me the full trace of the start of video streaming? (dmesg from 'spca5xx_open' till the end - please, no more than one second of streaming) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
TeVii S470 status?
Hi, I'm looking for a new DVB-S2 card for my linux server and I wonder if anyone have tried the TeVii S470 in linux with DVB-S and S2 and whats the status of it. Is it stable and good support, no problems like the TT3200 (A problem with locking high symbol rate channels (DVB-S2 3 3/4 transponders) . I need to tune channels with a high symbolrate at 3. It does not say much in linuxtv-wiki but the manufacturer has s2api driver at there homepage. How is it compared to Hauppauge HVR-4000, Nova HD S2 or the TT S2 1600? Thankful for all help. Best regards Claes -- 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: Media controller: sysfs vs ioctl
On Sunday 13 September 2009 08:13:04 Nathaniel Kim wrote: > > 2009. 9. 12., 오전 7:21, Hans Verkuil 작성: > > > Hi all, > > > > I've started this as a new thread to prevent polluting the > > discussions of the > > media controller as a concept. > > > > First of all, I have no doubt that everything that you can do with > > an ioctl, > > you can also do with sysfs and vice versa. That's not the problem > > here. > > > > The problem is deciding which approach is the best. > > > > What is sysfs? (taken from http://lwn.net/Articles/31185/) > > > > "Sysfs is a virtual filesystem which provides a userspace-visible > > representation > > of the device model. The device model and sysfs are sometimes > > confused with each > > other, but they are distinct entities. The device model functions > > just fine > > without sysfs (but the reverse is not true)." > > > > Currently both a v4l driver and the device nodes are all represented > > in sysfs. > > This is handled automatically by the kernel. > > > > Sub-devices are not represented in sysfs since they are not based on > > struct > > device. They are v4l-internal structures. Actually, if the subdev > > represents > > an i2c device, then that i2c device will be present in sysfs, but > > not all > > subdevs are i2c devices. > > > > Should we make all sub-devices based on struct device? Currently > > this is not > > required. Doing this would probably mean registering a virtual bus, > > then > > attaching the sub-device to that. Of course, this only applies to > > sub-devices > > that represent something that is not an i2c device (e.g. something > > internal > > to the media board like a resizer, or something connected to GPIO > > pins). > > > > If we decide to go with sysfs, then we have to do this. This part > > shouldn't > > be too difficult to implement. And also if we do not go with sysfs > > this might > > be interesting to do eventually. > > > > The media controller topology as I see it should contain the device > > nodes > > since the application has to know what device node to open to do the > > streaming. > > It should also contain the sub-devices so the application can > > control them. > > Is this enough? I think that eventually we also want to show the > > physical > > connectors. I left them out (mostly) from the initial media > > controller proposal, > > but I suspect that we want those as well eventually. But connectors > > are > > definitely not devices. In that respect the entity concept of the > > media > > controller is more abstract than sysfs. > > > > However, for now I think we can safely assume that sub-devices can > > be made > > visible in sysfs. > > > > Hans, > > First of all I'm very sorry that I had not enough time to go through > your new RFC. I'll checkout right after posting this mail. > > I think this is a good approach and I also had in my mind that sysfs > might be a good method if we could control and monitor through this. > Recalling memory when we had a talk in San Francisco, I was frustrated > that there is no way to catch events from sort of sub-devices like > lens actuator (I mean pizeo motors in camera module). As you know lens > actuator is an extremely slow device in comparison with common v4l2 > devices we are using and we need to know whether it has succeeded or > not in moving to expected position. > So I considered sysfs and udev as candidates for catching events from > sub-devices. events like success/failure of lens movement, change of > status of subdevices. > Does anybody experiencing same issue? I think I've seen a lens > controller driver in omap3 kernel from TI but not sure how did they > control that. > > My point is that we need a kind of framework to give and event to user > space and catching them properly just like udev does. When I was talking to Laurent Pinchart and Sakari and his team at Nokia we discussed just such a framework. It actually exists already, although it is poorly implemented. Look at include/linux/dvb/video.h, struct video_event and ioctl VIDEO_GET_EVENT. It is used in ivtv (ivtv-ioctl.c, look for VIDEO_GET_EVENT). The idea is that you can either call VIDEO_GET_EVENT to wait for an event or use select() and wait for an exception to arrive, and then call VIDEO_GET_EVENT to find which event it was. This is ideal for streaming-related events. In ivtv it is used to report VSYNCs and to report when the MPEG decoder stopped (there is a delay between stopping sending new data to the decoder and when it actually processed all its internal buffers). Laurent is going to look into this to clean it up and present it as a new proper official V4L2 event mechanism. For events completely specific to a subdev I wonder whether it wouldn't be a good idea to use the media controller device for that. I like the select() mechanism since in an application you can just select() on a whole bunch of filehandles. If you can't use select()
RFCv2.1: Media controller proposal
RFC: Media controller proposal Version 2.1 Changes from 2.0 - Forgot to mention Hans de Goede who was part of the recent meeting between Laurent, Guennadi and myself. My apologies! - Removed confusing and bogus VIDIOC_S_FMT example. - Mention the importance of documentation, also for private ioctls. - Added open issue #7: monitoring. - Added open issue #8: make the media controller a separate device independent of V4L. - Added open issue #9: sysfs vs ioctl. - Added a link to my initial implementation. - Start using the term 'pad' as a generic term to describe inputs and outputs. Background == This RFC is a new version of the original RFC that was written in cooperation with and on behalf of Texas Instruments about a year ago. Much work has been done in the past year to put the foundation in place to be able to implement a media controller and now it is time for this updated version. The intention is to discuss this in more detail during this years Plumbers Conference. Although the high-level concepts are the same as in the original RFC, many of the details have changed based on what was learned over the past year. This RFC is based on the original discussions with Manjunath Hadli from TI last year, on discussions during a recent meeting between Laurent Pinchart, Hans de Goede, Guennadi Liakhovetski and myself, and on recent discussions with Nokia. Thanks to Sakari Ailus for doing an initial review of this RFC. Two notes regarding terminology: a 'board' is the name I use for the SoC, PCI or USB device that contains the video hardware. Each board has its own driver instance and its own v4l2_device struct. Originally I called it 'device', but that name is already used in too many places. A 'pad' is the name for an input or output of some component. I borrowed this name from gstreamer since I realized that we needed a single term that describes both an input and an output. Another commonly used term for that is 'pin', but I decided against that since it is already used to describe the actual physical hardware pins on a chip or connector. A 'pad' is more abstract. Data is flowing from a 'source pad' or 'output pad' to a 'sink pad' or 'input pad'. What is a media controller? === In a nutshell: a media controller is a new v4l device node that can be used to discover and modify the topology of the board and to give access to the low-level nodes (such as previewers, resizers, color space converters, etc.) that are part of the topology. It does not do any streaming, that is the exclusive domain of video nodes. It is meant purely for controlling a board as a whole. It makes very few assumptions on the underlying functionality, it basically just enumerates components and the links between them and provides a way of accessing those components. An initial example implementation is available here: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-mc Why do we need one? === There are currently several problems that are impossible to solve within the current V4L2 API: 1) Discovering the various device nodes that are typically created by a video board, such as: video nodes, vbi nodes, dvb nodes, alsa nodes, framebuffer nodes, input nodes (for e.g. webcam button events or IR remotes). It would be very handy if an application can just open an /dev/v4l/mc0 node and be able to figure out where all the nodes are, and to be able to figure out what the capabilities of the board are (e.g. does it support DVB, is the audio going through a loopback cable or is there an alsa device, can it do compressed MPEG video, etc. etc.). Currently the end-user has no choice but to supply the device nodes manually. 2) Some of the newer SoC devices can connect or disconnect internal components dynamically. As an example, the omap3 can either connect a sensor output to a CCDC module to a previewer module to a resizer module and finally to a capture device node. But it is also possible to capture the sensor output directly after the CCDC module. The previewer can get its input from another video device node and output either to the resizer or to another video capture device node. The same is true for the resizer, that too can get its input from a device node. So there are lots of connections here that can be modified at will depending on what the application wants. And in real life there are even more links than I mentioned here. And it will only get more complicated in the future. All this requires that there has to be a way to connect and disconnect parts of the internal topology of a video board at will. 3) There is an increasing demand to be able to control e.g. sensors or video encoders/decoders at a much more precise manner. Currently the V4L2 API provides only limited support in the form of a set of controls. But when building a high-end camera the developer of the application controlling it needs very detailed control of the sensor and image processi
Re: image quality of Labtec Webcam 2200
Jean-Francois Moine wrote: > On Fri, 11 Sep 2009 09:09:20 +0200 > Németh Márton wrote: > >> You can find my results at >> http://v4l-test.sourceforge.net/results/test-20090911/index.html >> There are three types of problems: a) Sometimes the picture contains >> a 8x8 pixel error, like in image #9 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 >> b) Sometimes the brightness of the half picture is changed, like in >> images #7, #36 and #37 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 >> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 >> c) Sometimes the libv4l cannot convert the raw image and the errno is >> set to EAGAIN (11), for example image #1, #2 and #3 >> >> Do you know how can I fix these problems? > > The error EAGAIN is normal when decoding pac7311 images, because they > are rotated 90°. But this error should occur one time only. I have the feeling that the Labtec Webcam 2200 is not based on the PAC7311 but on PAC7312. The PAC7312 also contains a microphone input and the Labtec Webcam 2200 also have a built-in microphone. See http://www.pixart.com.tw/productsditel.asp?ToPage=1&productclassify_id=12&productclassify2_id=33 for the datasheets. See also http://labtec.com/index.cfm/gear/details/EUR/EN,crid=30,contentid=761 . > I looked at the raw image #1, and it seems that there are JPEG errors > inside (sequences ff ff). There should be a problem in the pac7311 > driver. Hans, may you confirm? > -- 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: Problems with Pinnacle 310i (saa7134) and recent kernels
Hi, hermann pitton arcor.de> writes: > > I'm sorry that we have some mess on some of such devices, but currently > really nobody can help much further. > > Mike and Hauppauge don't have any schematics for LNA and external > antenna voltage switching for now, he assured it to me personally and we > must live with the back hacks for now and try to further work through > it. > > However, mplayer should work as well, but my last checkout is a little > out dated. > > It will go to Nico anyway, he is usually at the list here. > > If you can tell me on what you are, I might be able to confirm or not. Do you mean the exact card I have? I can do some photos if they can help. Unfortunately I don't have the original eeprom content. In the matter of the IR, the modules seems to be loaded: tda1004x 13048 1 saa7134_dvb20772 0 videobuf_dvb5644 1 saa7134_dvb ir_kbd_i2c 5500 0 tda827x 8880 2 tuner 16960 1 saa7134 138436 1 saa7134_dvb ir_common 41828 2 ir_kbd_i2c,saa7134 videobuf_dma_sg 9876 2 saa7134_dvb,saa7134 videobuf_core 13596 3 videobuf_dvb,saa7134,videobuf_dma_sg tveeprom 10488 1 saa7134 But I can't find anything in /proc/bus/input/devices. > The only other issue I'm aware of is that radio is broken since guessed > 8 weeks on my tuners, only realized when testing on enabling external > active antenna voltage for DVB-T on a/some 310i. > > Might be anything, hm, hopefully I should not have caused it ;) The radio works for me, even if there's much noise (I don't usually use it). I'm using the internal audio cable. > Cheers, > Hermann 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
Terratec T USB XXS 0ccd:00ab device
Hello, I've just subscribed this list. I'm normally using knode to read news, but somehow I can not pull the groups etc from the vger server. I also tried to post to linux-dvb mailing list, but found out that it moved here. If you think I need to know something explicitly about participating to the list, please let me know. The issue I'm facing is that my old TV card (HVR900) stopped working, so I googled around and decided to buy Terratec T USB XXS, reading it was supported in dvb_usb_dib0700 However after installing the card (usb-stick) it was not recognized (my one has product id 0x00ab and not 0x0078), so I googled again and found a hint to change the device id in dvb_usb_ids.h which was working for other Terratec card. I pulled the latest v4l-dvb code and did it (perhaps I could have done it in the kernel 2.6.31), compiled, installed and it started working. However I can not handle udev to get the remote control links created correctly. Can someone help me with it? How can I provide useful output to developers to solve the issues with ir? I read and saw that ir control keys are coded in the driver, so if the ir part of the 0x00ab card is different, how can I get a useful information that can be coded for this card? Who is doing the work at linux-dvb? I read there are other people, returning the cards to the seller, because it's not working/supported by linux, which does not seem to be really true. Luckilly I have a bit kernel experience and good C knowledge and could do testing if somebody can have a look at the issues - the code is completely new to me so that I prefer to be an alpha tester for the device. thanks for patience in advance and kind regards -- pub 1024D/648C084C 2008-06-06 Emanoil Kotsev Primary key fingerprint: 002C AF99 232A 5A44 EF9E 6D7D 0D65 4160 648C 084C signature.asc Description: This is a digitally signed message part.
Re: Media controller: sysfs vs ioctl
Em Sun, 13 Sep 2009 15:13:04 +0900 Nathaniel Kim escreveu: > > 2009. 9. 12., 오전 7:21, Hans Verkuil 작성: > > > Hi all, > > > > I've started this as a new thread to prevent polluting the > > discussions of the > > media controller as a concept. > > > > First of all, I have no doubt that everything that you can do with > > an ioctl, > > you can also do with sysfs and vice versa. That's not the problem > > here. > > > > The problem is deciding which approach is the best. > > > > What is sysfs? (taken from http://lwn.net/Articles/31185/) > > > > "Sysfs is a virtual filesystem which provides a userspace-visible > > representation > > of the device model. The device model and sysfs are sometimes > > confused with each > > other, but they are distinct entities. The device model functions > > just fine > > without sysfs (but the reverse is not true)." > > > > Currently both a v4l driver and the device nodes are all represented > > in sysfs. > > This is handled automatically by the kernel. > > > > Sub-devices are not represented in sysfs since they are not based on > > struct > > device. They are v4l-internal structures. Actually, if the subdev > > represents > > an i2c device, then that i2c device will be present in sysfs, but > > not all > > subdevs are i2c devices. > > > > Should we make all sub-devices based on struct device? Currently > > this is not > > required. Doing this would probably mean registering a virtual bus, > > then > > attaching the sub-device to that. Of course, this only applies to > > sub-devices > > that represent something that is not an i2c device (e.g. something > > internal > > to the media board like a resizer, or something connected to GPIO > > pins). > > > > If we decide to go with sysfs, then we have to do this. This part > > shouldn't > > be too difficult to implement. And also if we do not go with sysfs > > this might > > be interesting to do eventually. > > > > The media controller topology as I see it should contain the device > > nodes > > since the application has to know what device node to open to do the > > streaming. > > It should also contain the sub-devices so the application can > > control them. > > Is this enough? I think that eventually we also want to show the > > physical > > connectors. I left them out (mostly) from the initial media > > controller proposal, > > but I suspect that we want those as well eventually. But connectors > > are > > definitely not devices. In that respect the entity concept of the > > media > > controller is more abstract than sysfs. > > > > However, for now I think we can safely assume that sub-devices can > > be made > > visible in sysfs. > > > > Hans, > > First of all I'm very sorry that I had not enough time to go through > your new RFC. I'll checkout right after posting this mail. > > I think this is a good approach and I also had in my mind that sysfs > might be a good method if we could control and monitor through this. > Recalling memory when we had a talk in San Francisco, I was frustrated > that there is no way to catch events from sort of sub-devices like > lens actuator (I mean pizeo motors in camera module). As you know lens > actuator is an extremely slow device in comparison with common v4l2 > devices we are using and we need to know whether it has succeeded or > not in moving to expected position. > So I considered sysfs and udev as candidates for catching events from > sub-devices. events like success/failure of lens movement, change of > status of subdevices. > Does anybody experiencing same issue? I think I've seen a lens > controller driver in omap3 kernel from TI but not sure how did they > control that. > > My point is that we need a kind of framework to give and event to user > space and catching them properly just like udev does. Maybe the Kernel event interface could be used for that. > Cheers, > > Nate > > = > DongSoo, Nathaniel Kim > Engineer > Mobile S/W Platform Lab. > Digital Media & Communications R&D 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 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: Terratec T USB XXS 0ccd:00ab device
Em Sun, 13 Sep 2009 14:56:56 +0200 Emanoil Kotsev escreveu: > Hello, I've just subscribed this list. I'm normally using knode to read news, > but somehow I can not pull the groups etc from the vger server. > > I also tried to post to linux-dvb mailing list, but found out that it moved > here. If you think I need to know something explicitly about participating to > the list, please let me know. > > The issue I'm facing is that my old TV card (HVR900) stopped working, so I > googled around and decided to buy Terratec T USB XXS, reading it was > supported in dvb_usb_dib0700 > > However after installing the card (usb-stick) it was not recognized (my one > has product id 0x00ab and not 0x0078), so I googled again and found a hint to > change the device id in dvb_usb_ids.h which was working for other Terratec > card. > > I pulled the latest v4l-dvb code and did it (perhaps I could have done it in > the kernel 2.6.31), compiled, installed and it started working. > > However I can not handle udev to get the remote control links created > correctly. Can someone help me with it? How can I provide useful output to > developers to solve the issues with ir? I read and saw that ir control keys > are coded in the driver, so if the ir part of the 0x00ab card is different, > how can I get a useful information that can be coded for this card? Who is > doing the work at linux-dvb? > > I read there are other people, returning the cards to the seller, because > it's > not working/supported by linux, which does not seem to be really true. > > Luckilly I have a bit kernel experience and good C knowledge and could do > testing if somebody can have a look at the issues - the code is completely > new to me so that I prefer to be an alpha tester for the device. > > thanks for patience in advance and kind regards Basically, all you need to do is to enable IR debug, when loading em28xx module and see what's the scan code for each pressed key on the IR. Then edit ir-keycodes.c, adding a new table there, and edit em28xx-cards.c to add a new board entry with the new code, with the new IR table. There's a page for Remote Controllers at linuxtv.org wiki showing what keycode names should be used for each key. 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: Media controller: sysfs vs ioctl
On Sunday 13 September 2009 15:27:57 Mauro Carvalho Chehab wrote: > Em Sun, 13 Sep 2009 15:13:04 +0900 > Nathaniel Kim escreveu: > > > > > 2009. 9. 12., 오전 7:21, Hans Verkuil 작성: > > > > > Hi all, > > > > > > I've started this as a new thread to prevent polluting the > > > discussions of the > > > media controller as a concept. > > > > > > First of all, I have no doubt that everything that you can do with > > > an ioctl, > > > you can also do with sysfs and vice versa. That's not the problem > > > here. > > > > > > The problem is deciding which approach is the best. > > > > > > What is sysfs? (taken from http://lwn.net/Articles/31185/) > > > > > > "Sysfs is a virtual filesystem which provides a userspace-visible > > > representation > > > of the device model. The device model and sysfs are sometimes > > > confused with each > > > other, but they are distinct entities. The device model functions > > > just fine > > > without sysfs (but the reverse is not true)." > > > > > > Currently both a v4l driver and the device nodes are all represented > > > in sysfs. > > > This is handled automatically by the kernel. > > > > > > Sub-devices are not represented in sysfs since they are not based on > > > struct > > > device. They are v4l-internal structures. Actually, if the subdev > > > represents > > > an i2c device, then that i2c device will be present in sysfs, but > > > not all > > > subdevs are i2c devices. > > > > > > Should we make all sub-devices based on struct device? Currently > > > this is not > > > required. Doing this would probably mean registering a virtual bus, > > > then > > > attaching the sub-device to that. Of course, this only applies to > > > sub-devices > > > that represent something that is not an i2c device (e.g. something > > > internal > > > to the media board like a resizer, or something connected to GPIO > > > pins). > > > > > > If we decide to go with sysfs, then we have to do this. This part > > > shouldn't > > > be too difficult to implement. And also if we do not go with sysfs > > > this might > > > be interesting to do eventually. > > > > > > The media controller topology as I see it should contain the device > > > nodes > > > since the application has to know what device node to open to do the > > > streaming. > > > It should also contain the sub-devices so the application can > > > control them. > > > Is this enough? I think that eventually we also want to show the > > > physical > > > connectors. I left them out (mostly) from the initial media > > > controller proposal, > > > but I suspect that we want those as well eventually. But connectors > > > are > > > definitely not devices. In that respect the entity concept of the > > > media > > > controller is more abstract than sysfs. > > > > > > However, for now I think we can safely assume that sub-devices can > > > be made > > > visible in sysfs. > > > > > > > Hans, > > > > First of all I'm very sorry that I had not enough time to go through > > your new RFC. I'll checkout right after posting this mail. > > > > I think this is a good approach and I also had in my mind that sysfs > > might be a good method if we could control and monitor through this. > > Recalling memory when we had a talk in San Francisco, I was frustrated > > that there is no way to catch events from sort of sub-devices like > > lens actuator (I mean pizeo motors in camera module). As you know lens > > actuator is an extremely slow device in comparison with common v4l2 > > devices we are using and we need to know whether it has succeeded or > > not in moving to expected position. > > So I considered sysfs and udev as candidates for catching events from > > sub-devices. events like success/failure of lens movement, change of > > status of subdevices. > > Does anybody experiencing same issue? I think I've seen a lens > > controller driver in omap3 kernel from TI but not sure how did they > > control that. > > > > My point is that we need a kind of framework to give and event to user > > space and catching them properly just like udev does. > > Maybe the Kernel event interface could be used for that. Are you talking about the input event interface? There is no standard kernel way of doing events afaik. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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://udev.netup.ru/hg/v4l-dvb-commits
Em Wed, 9 Sep 2009 19:21:12 +0300 "Igor M. Liplianin" escreveu: > Mauro, > > Please pull from http://udev.netup.ru/hg/v4l-dvb-commits I can't reach the server. the connection dies at utm.netup.ru. traceroute -n udev.netup.ru traceroute to udev.netup.ru (77.72.80.20), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 201.0.87.225 70.096 ms 70.345 ms 77.659 ms 5 201.0.5.69 125.153 ms 201.0.5.65 77.956 ms 201.0.5.69 125.311 ms 6 201.63.253.110 85.516 ms 200.100.98.97 63.072 ms 200.100.98.173 63.234 ms 7 84.16.6.193 63.207 ms 84.16.9.109 70.806 ms 84.16.6.141 63.449 ms 8 213.140.36.13 173.869 ms 213.140.43.109 181.653 ms 213.140.36.69 174.597 ms 9 84.16.13.53 213.031 ms 84.16.12.221 197.664 ms 84.16.13.53 205.391 ms 10 213.140.55.90 228.586 ms 229.547 ms 228.847 ms 11 207.138.94.70 339.372 ms 347.711 ms 340.608 ms 12 62.140.245.174 340.202 ms 332.198 ms 339.701 ms 13 193.203.36.250 348.137 ms 347.738 ms 348.086 ms 14 193.203.36.250 3140.511 ms !H 3037.629 ms !H 2998.439 ms !H > > for the following changeset: > > 01/01: Fix gpio mutex in NetUP Dual DVB-S2 CI card. > http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=2f1119c624eb > > > cimax2.c | 12 ++-- > cx23885-core.c |1 + > cx23885.h |1 + > 3 files changed, 8 insertions(+), 6 deletions(-) > > Thanks, > Igor > > -- > 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 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
RFC: bus and data format negotiation
(I promised that I would analyze this. Sorry that it took so long, but I had a lot of other things going on and this was one topic that I needed to really sit down for and think about carefully.) RFC: bus and data format negotiation Version 1.0 Background == As media boards become more complex it is getting harder to enumerate and setup the busses that connect the various components on the board and to map that to actual pixelformats (i.e. how the data will end up in memory). This is a particular problem for sensors that can often be connected in many different ways. Several attempts have been made to find a good internal API for this, but none were satisfactory. In this RFC I'll analyze how such connections are made, what the core problems are and I'll present a solution that hopefully solves these problems in a well-defined and not too complex way. This RFC is directly related to open issue #3 in the media controller RFC. Analysis In general you have two components, A and B, and some sort of a bus between them (i.e. the physical wires). This can be straightforward, e.g. 10 pins on either side are directly connected, or there can be additional components in between like level converters or perhaps even complex FPGAs that are not under our control but that nevertheless can make changes in how the data is presented. While information on such components may not be available at the driver level, it is available at platform (board) level. More complex boards have more than two components and multiple busses, but many of the basics remain the same. Bus configuration - In order to setup a component you will need to supply a bus configuration that sets up the physical properties of the bus: signal polarities, how the data should be sampled, etc. In many cases there is only one possible bus configuration. But especially sensors have more configurations. This configuration should come from the board specification and not be autonegotiated. Depending on the board layout a wrong bus configuration can have quite unpredictable results. Even though both sides of the bus may seemingly support a specific configuration additional board-specific factors may prevent that configuration from working reliably. Data formats For a given bus configuration a component can support one or more data formats. A data format is similar, but not identical, to a pixel format. A pixel format defines the format of the video in memory. A data format defines the format of the video on a bus. The component's driver will know which data formats it supports given the bus config. Note that changing the bus config on the fly will also change the list of supported data formats. Normally a bus config is setup once and not changed, but this is not necessarily always the case. Video timings - Once the bus is configured and the data format is set it is finally possible to determine what resolutions and framerates are supported. Here we run into a problem, though. The current V4L2 API is not clear on how that should be done. We have three enumeration ioctls involved in this: either VIDIOC_ENUMSTD to enumerate the supported video standards for analog TV video encoders and decoders, and VIDIOC_ENUM_FRAMESIZES/FRAMEINTERVALS to enumerate native sensor resolutions and framerates. Unfortunately the spec is not clear whether ENUM_FRAMESIZES/INTERVALS really refers to the sensor (or more general, the component that is the initial source of the video stream) or to the sizes and framerates that you can capture on the video node. What makes this worse is that there is an essential ioctl missing: you need to have the equivalent of VIDIOC_S_STD to setup a sensor to a specific resolution/framerate. Right now VIDIOC_S_FMT is used for that, but that is really meant to take an input resolution and scale it up or down to the desired resolution. It is not meant to setup a sensor (or video source or sink in general) to a particular resolution. To fix this we need to 1) specify that the framesize/interval enumeration relates to the video source and not to the output of a possible scaler, and 2) add support for setting up a sensor to a specific size/framerate. Murali Karicheri from TI is working on something similar. Using S_FMT to select a particular resolution never felt right, and now I realize why. Luckily I don't think any of the webcam drivers we have currently do any scaling, so using S_FMT will still work for those and applications do not need to be modified. To do the sensor setup in the new-style we can either introduce a new ioctl to specify the size and use VIDIOC_S_PARM (yuck!) to setup the framerate, or we use the new video timings ioctl that Murali is working on. Data format negotiation --- Depending on the bus configuration a component supports a list of data formats. The next step is to somehow coordinate both sides of the bus to select compatible da
Re: Media controller: sysfs vs ioctl
Em Sun, 13 Sep 2009 15:43:02 +0200 Hans Verkuil escreveu: > On Sunday 13 September 2009 15:27:57 Mauro Carvalho Chehab wrote: > > Em Sun, 13 Sep 2009 15:13:04 +0900 > > Nathaniel Kim escreveu: > > > > > > > > 2009. 9. 12., 오전 7:21, Hans Verkuil 작성: > > > > > > > Hi all, > > > > > > > > I've started this as a new thread to prevent polluting the > > > > discussions of the > > > > media controller as a concept. > > > > > > > > First of all, I have no doubt that everything that you can do with > > > > an ioctl, > > > > you can also do with sysfs and vice versa. That's not the problem > > > > here. > > > > > > > > The problem is deciding which approach is the best. > > > > > > > > What is sysfs? (taken from http://lwn.net/Articles/31185/) > > > > > > > > "Sysfs is a virtual filesystem which provides a userspace-visible > > > > representation > > > > of the device model. The device model and sysfs are sometimes > > > > confused with each > > > > other, but they are distinct entities. The device model functions > > > > just fine > > > > without sysfs (but the reverse is not true)." > > > > > > > > Currently both a v4l driver and the device nodes are all represented > > > > in sysfs. > > > > This is handled automatically by the kernel. > > > > > > > > Sub-devices are not represented in sysfs since they are not based on > > > > struct > > > > device. They are v4l-internal structures. Actually, if the subdev > > > > represents > > > > an i2c device, then that i2c device will be present in sysfs, but > > > > not all > > > > subdevs are i2c devices. > > > > > > > > Should we make all sub-devices based on struct device? Currently > > > > this is not > > > > required. Doing this would probably mean registering a virtual bus, > > > > then > > > > attaching the sub-device to that. Of course, this only applies to > > > > sub-devices > > > > that represent something that is not an i2c device (e.g. something > > > > internal > > > > to the media board like a resizer, or something connected to GPIO > > > > pins). > > > > > > > > If we decide to go with sysfs, then we have to do this. This part > > > > shouldn't > > > > be too difficult to implement. And also if we do not go with sysfs > > > > this might > > > > be interesting to do eventually. > > > > > > > > The media controller topology as I see it should contain the device > > > > nodes > > > > since the application has to know what device node to open to do the > > > > streaming. > > > > It should also contain the sub-devices so the application can > > > > control them. > > > > Is this enough? I think that eventually we also want to show the > > > > physical > > > > connectors. I left them out (mostly) from the initial media > > > > controller proposal, > > > > but I suspect that we want those as well eventually. But connectors > > > > are > > > > definitely not devices. In that respect the entity concept of the > > > > media > > > > controller is more abstract than sysfs. > > > > > > > > However, for now I think we can safely assume that sub-devices can > > > > be made > > > > visible in sysfs. > > > > > > > > > > Hans, > > > > > > First of all I'm very sorry that I had not enough time to go through > > > your new RFC. I'll checkout right after posting this mail. > > > > > > I think this is a good approach and I also had in my mind that sysfs > > > might be a good method if we could control and monitor through this. > > > Recalling memory when we had a talk in San Francisco, I was frustrated > > > that there is no way to catch events from sort of sub-devices like > > > lens actuator (I mean pizeo motors in camera module). As you know lens > > > actuator is an extremely slow device in comparison with common v4l2 > > > devices we are using and we need to know whether it has succeeded or > > > not in moving to expected position. > > > So I considered sysfs and udev as candidates for catching events from > > > sub-devices. events like success/failure of lens movement, change of > > > status of subdevices. > > > Does anybody experiencing same issue? I think I've seen a lens > > > controller driver in omap3 kernel from TI but not sure how did they > > > control that. > > > > > > My point is that we need a kind of framework to give and event to user > > > space and catching them properly just like udev does. > > > > Maybe the Kernel event interface could be used for that. > > Are you talking about the input event interface? There is no standard kernel > way of doing events afaik. Yes. It is designed for low-latency report of events, like mouse movements, where you expect that the movement will happen as mouse moves. So, it may work fine also for servo movements. A closer look on it, plus some tests should be done to see if it will work fine for such camera events. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@v
Re: Pinnacle PCTV 310i active antenna
Hi Hermann, thank you, the patch for the antenna power is working for me with the latest mercurial tree. I'm now able to receive additional weak channels. On the contrary a channel close by with a very strong signal disappeared. The stand-alone receiver with antenna power that I have can receive both channels at the same time. Am Sonntag, 30. August 2009 01:38:35 schrieb hermann pitton: > A testhack, not a clean implementation, is attached and should give you > voltage to the active antenna when using DVB-T. > > BTW, the radio seems to be broken since some weeks. > It is not by that patch here. > > Cheers, > Hermann > Cheers, Martin -- 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: image quality of Labtec Webcam 2200
Actually it based on pac7302. Pac7311/02 also has support ( since gspca1 ). I checked some old logs of the pac, and the driver init for 7302 seems ok. The "ff ff ff" sequence, seems to been taken in account on conversion. (libv4lconvert) /* Special Pixart versions of the *_nbits functions, these remove the special ff ff ff xx sequences pixart cams insert from the bitstream */ #define pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted) \ This is really a tricky cam. I be back on windows to do further test. pd: Nemeth, i could reproduce your problems now. 2009/9/13 Németh Márton : > Jean-Francois Moine wrote: >> On Fri, 11 Sep 2009 09:09:20 +0200 >> Németh Márton wrote: >> >>> You can find my results at >>> http://v4l-test.sourceforge.net/results/test-20090911/index.html >>> There are three types of problems: a) Sometimes the picture contains >>> a 8x8 pixel error, like in image #9 >>> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 >>> b) Sometimes the brightness of the half picture is changed, like in >>> images #7, #36 and #37 >>> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 >>> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 >>> http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 >>> c) Sometimes the libv4l cannot convert the raw image and the errno is >>> set to EAGAIN (11), for example image #1, #2 and #3 >>> >>> Do you know how can I fix these problems? >> >> The error EAGAIN is normal when decoding pac7311 images, because they >> are rotated 90°. But this error should occur one time only. > > I have the feeling that the Labtec Webcam 2200 is not based on the PAC7311 > but on PAC7312. The PAC7312 also contains a microphone input and the > Labtec Webcam 2200 also have a built-in microphone. > See > http://www.pixart.com.tw/productsditel.asp?ToPage=1&productclassify_id=12&productclassify2_id=33 > for the datasheets. See also > http://labtec.com/index.cfm/gear/details/EUR/EN,crid=30,contentid=761 . > >> I looked at the raw image #1, and it seems that there are JPEG errors >> inside (sequences ff ff). There should be a problem in the pac7311 >> driver. Hans, may you confirm? >> > > -- 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://kernellabs.com/hg/~dheitmueller/em28xx-vbi3
Em Fri, 11 Sep 2009 00:00:35 -0400
Devin Heitmueller escreveu:
> Hello Mauro,
>
> Please PULL from http://kernellabs.com/hg/~dheitmueller/em28xx-vbi3
> for the following
>
> em28xx: better describe vinctrl registers
> em28xx: make video isoc stream work when VBI is enabled
> em28xx: add raw VBI support for NTSC
> em28xx: fix mmap_mapper with vbi
> em28xx: restructure fh/dev locking to handle both video and vbi
> em28xx: remove unreferenced variable
> em28xx: do not create /dev/vbiX device if VBI not supported
> em28xx: only advertise VBI capability if supported
> em28xx: implement g_std v4l call
> em28xx: remove unneeded code that set VINCTRL register
> em28xx: fix unused variable warning
>
> Note: the support currently only works for NTSC. I will be getting
> PAL support working in the next couple of weeks as I get an
> environment setup for testing.
>
> Special thanks go out to EyeMagnet Limited for sponsoring this work.
Applied, thanks.
There are some CodingStyle fixes that need to be done. Please send a patch
later.
The first one is that drivers shouldn't contain emacs or other text editors
format tags. If you use such editors, use a local var instead, as stated at
Documentation/CodingStyle, chapter 18.
The remaining ones are pointed by checkpatch.pl:
/tmp/newpatches/hg_em28xx-vbi3_02.patch:
em28xx: make video isoc stream work when VBI is enabled
WARNING: printk() should include KERN_ facility level
#226: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:510:
+ printk("djh c should never happen\n");
WARNING: braces {} are not necessary for any arm of this statement
#238: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:522:
+ if (vbi_buf == NULL)
[...]
+ else {
[...]
WARNING: line over 80 characters
#241: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:525:
+ vbioutp =
videobuf_to_vmalloc(&vbi_buf->vb);
total: 0 errors, 3 warnings, 299 lines checked
/tmp/newpatches/hg_em28xx-vbi3_03.patch:
em28xx: add raw VBI support for NTSC
WARNING: printk() should include KERN_ facility level
#116: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:305:
+ printk("dev is null\n");
WARNING: printk() should include KERN_ facility level
#121: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:310:
+ printk("dma_q is null\n");
WARNING: printk() should include KERN_ facility level
#127: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:316:
+ printk("buf is null\n");
WARNING: printk() should include KERN_ facility level
#132: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:321:
+ printk("p is null\n");
WARNING: printk() should include KERN_ facility level
#136: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:325:
+ printk("outp is null\n");
WARNING: braces {} are not necessary for any arm of this statement
#446: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:1937:
+ if (fh->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
[...]
+ else {
[...]
ERROR: space required after that ',' (ctx:VxV)
#652: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:32:
+module_param(vbibufs,int,0644);
^
ERROR: space required after that ',' (ctx:VxV)
#652: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:32:
+module_param(vbibufs,int,0644);
^
ERROR: space required after that ',' (ctx:VxV)
#653: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:33:
+MODULE_PARM_DESC(vbibufs,"number of vbi buffers, range 2-32");
^
ERROR: space required after that ',' (ctx:VxV)
#656: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:36:
+module_param(vbi_debug,int,0644);
^
ERROR: space required after that ',' (ctx:VxV)
#656: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:36:
+module_param(vbi_debug,int,0644);
^
ERROR: space required after that ',' (ctx:VxV)
#657: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:37:
+MODULE_PARM_DESC(vbi_debug,"enable debug messages [vbi]");
^
ERROR: space required after that ',' (ctx:VxV)
#659: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:39:
+#define dprintk(level,fmt, arg...) if (vbi_debug >= level) \
^
total: 7 errors, 6 warnings, 698 lines checked
/tmp/newpatches/hg_em28xx-vbi3_05.patch:
em28xx: restructure fh/dev locking to handle both video and vbi
ERROR: return is not a function, parentheses are not required
#77: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:891:
+ return (fh->resources & bit);
ERROR: return is not a function, parentheses are not required
#82: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:896:
+ return (dev->resources & bit);
ERROR: space required after that ',' (ctx:VxV)
#150: FILE: linux/d
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/em28xx-vbi3
On Sun, Sep 13, 2009 at 10:58 AM, Mauro Carvalho Chehab
wrote:
> Em Fri, 11 Sep 2009 00:00:35 -0400
> Devin Heitmueller escreveu:
>
>> Hello Mauro,
>>
>> Please PULL from http://kernellabs.com/hg/~dheitmueller/em28xx-vbi3
>> for the following
>>
>> em28xx: better describe vinctrl registers
>> em28xx: make video isoc stream work when VBI is enabled
>> em28xx: add raw VBI support for NTSC
>> em28xx: fix mmap_mapper with vbi
>> em28xx: restructure fh/dev locking to handle both video and vbi
>> em28xx: remove unreferenced variable
>> em28xx: do not create /dev/vbiX device if VBI not supported
>> em28xx: only advertise VBI capability if supported
>> em28xx: implement g_std v4l call
>> em28xx: remove unneeded code that set VINCTRL register
>> em28xx: fix unused variable warning
>>
>> Note: the support currently only works for NTSC. I will be getting
>> PAL support working in the next couple of weeks as I get an
>> environment setup for testing.
>>
>> Special thanks go out to EyeMagnet Limited for sponsoring this work.
>
> Applied, thanks.
>
> There are some CodingStyle fixes that need to be done. Please send a patch
> later.
>
> The first one is that drivers shouldn't contain emacs or other text editors
> format tags. If you use such editors, use a local var instead, as stated at
> Documentation/CodingStyle, chapter 18.
>
> The remaining ones are pointed by checkpatch.pl:
>
> /tmp/newpatches/hg_em28xx-vbi3_02.patch:
> em28xx: make video isoc stream work when VBI is enabled
> WARNING: printk() should include KERN_ facility level
> #226: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:510:
> + printk("djh c should never happen\n");
>
> WARNING: braces {} are not necessary for any arm of this statement
> #238: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:522:
> + if (vbi_buf == NULL)
> [...]
> + else {
> [...]
>
> WARNING: line over 80 characters
> #241: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:525:
> + vbioutp =
> videobuf_to_vmalloc(&vbi_buf->vb);
>
> total: 0 errors, 3 warnings, 299 lines checked
>
> /tmp/newpatches/hg_em28xx-vbi3_03.patch:
> em28xx: add raw VBI support for NTSC
> WARNING: printk() should include KERN_ facility level
> #116: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:305:
> + printk("dev is null\n");
>
> WARNING: printk() should include KERN_ facility level
> #121: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:310:
> + printk("dma_q is null\n");
>
> WARNING: printk() should include KERN_ facility level
> #127: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:316:
> + printk("buf is null\n");
>
> WARNING: printk() should include KERN_ facility level
> #132: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:321:
> + printk("p is null\n");
>
> WARNING: printk() should include KERN_ facility level
> #136: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:325:
> + printk("outp is null\n");
>
> WARNING: braces {} are not necessary for any arm of this statement
> #446: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:1937:
> + if (fh->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> [...]
> + else {
> [...]
>
> ERROR: space required after that ',' (ctx:VxV)
> #652: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:32:
> +module_param(vbibufs,int,0644);
> ^
>
> ERROR: space required after that ',' (ctx:VxV)
> #652: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:32:
> +module_param(vbibufs,int,0644);
> ^
>
> ERROR: space required after that ',' (ctx:VxV)
> #653: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:33:
> +MODULE_PARM_DESC(vbibufs,"number of vbi buffers, range 2-32");
> ^
>
> ERROR: space required after that ',' (ctx:VxV)
> #656: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:36:
> +module_param(vbi_debug,int,0644);
> ^
>
> ERROR: space required after that ',' (ctx:VxV)
> #656: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:36:
> +module_param(vbi_debug,int,0644);
> ^
>
> ERROR: space required after that ',' (ctx:VxV)
> #657: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:37:
> +MODULE_PARM_DESC(vbi_debug,"enable debug messages [vbi]");
> ^
>
> ERROR: space required after that ',' (ctx:VxV)
> #659: FILE: linux/drivers/media/video/em28xx/em28xx-vbi.c:39:
> +#define dprintk(level,fmt, arg...) if (vbi_debug >= level) \
> ^
>
> total: 7 errors, 6 warnings, 698 lines checked
>
> /tmp/newpatches/hg_em28xx-vbi3_05.patch:
> em28xx: restructure fh/dev locking to handle both video and vbi
> ERROR: return is not a function, parentheses are not required
> #77: FILE: linux/drivers/media/video/em28xx/em28xx-video.c:891:
> +
Re: Media controller: sysfs vs ioctl
Hans Verkuil schrieb: Hi all, I've started this as a new thread to prevent polluting the discussions of the media controller as a concept. First of all, I have no doubt that everything that you can do with an ioctl, you can also do with sysfs and vice versa. That's not the problem here. The problem is deciding which approach is the best. Is it really a good idea to create a dependency to some virtual file system which may go away in future? From time to time some of those seem to go away, for example devfs. Is it really unavoidable to have something in sysfs, something which is really not possible with ioctls? And do you really want to depend on sysfs developers? --Winfried -- 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: image quality of Labtec Webcam 2200
On 09/13/2009 04:42 PM, leandro Costantino wrote: Actually it based on pac7302. Pac7311/02 also has support ( since gspca1 ). I checked some old logs of the pac, and the driver init for 7302 seems ok. The "ff ff ff" sequence, seems to been taken in account on conversion. (libv4lconvert) /* Special Pixart versions of the *_nbits functions, these remove the special ff ff ff xx sequences pixart cams insert from the bitstream */ #define pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted) \ This is really a tricky cam. I be back on windows to do further test. Hey All I thought Hans will come in, in this discussion... Anyway, I introduced support for the PAC7311 in gspcaV1 in 2006 [1] Pixart is using a proprietary JEPG Format to code the image. It took me (and help from Jörg Schummer) more than a year to find out the basics to decode a frame. They have this 0xffxx markers in the stream, I don't know for what this is good, just skip it. And they have a "MCU marker" for each MCU. As we know so far, this MCU marker tells what Quantization table should be used for decoding the MCU. Hans did implement my findings into lib4vl and improved it :-) So, when you get this errors, this is due to a unknown format Pixart is using. I guess we should know what marker you get and how the image should look like. Don't forget, this is all re-engineered -> guess work! Thomas [1] http://www.kaiser-linux.li/index.php?title=PAC7311 -- 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
test
this is a test -- 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: Media controller: sysfs vs ioctl
On Sunday 13 September 2009 17:54:11 wk wrote: > Hans Verkuil schrieb: > > Hi all, > > > > I've started this as a new thread to prevent polluting the discussions of > > the > > media controller as a concept. > > > > First of all, I have no doubt that everything that you can do with an ioctl, > > you can also do with sysfs and vice versa. That's not the problem here. > > > > The problem is deciding which approach is the best. > > > > > > Is it really a good idea to create a dependency to some virtual file > system which may go away in future? > From time to time some of those seem to go away, for example devfs. > > Is it really unavoidable to have something in sysfs, something which is > really not possible with ioctls? > And do you really want to depend on sysfs developers? One other interesting question is: currently the V4L2 API is also used by BSD variants for their video drivers. Our V4L2 header is explicitly dual-licensed to allow this. I don't think that BSD has sysfs. So making the media controller sysfs-based only would make it very hard for them if they ever want to port drivers that rely on that to BSD. Yes, I know that strictly speaking we don't have to care about that, but it is yet another argument against the use of sysfs as far as I am concerned. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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 2/3] Add driver for OmniVision OV9640 sensor
Dne Pá 11. září 2009 23:51:44 Guennadi Liakhovetski napsal(a): > On Fri, 4 Sep 2009, Marek Vasut wrote: > > Dne Po 24. srpna 2009 20:06:29 Guennadi Liakhovetski napsal(a): > > > Hi Marek > > > > > > On Sat, 22 Aug 2009, Marek Vasut wrote: > > > > From 479aafc9a6540efec8a691a84aff166eb0218a72 Mon Sep 17 00:00:00 > > > > 2001 From: Marek Vasut > > > > Date: Sat, 22 Aug 2009 05:14:23 +0200 > > > > Subject: [PATCH 2/3] Add driver for OmniVision OV9640 sensor > > > > > > > > Signed-off-by: Marek Vasut > > > > > > Ok, I see, you rebased your patches on my soc-camera patch-stack, this > > > is good, thanks. But you missed a couple of my comments - you still > > > have a few static functions in the ov9640.c marked inline: > > > ov9640_set_crop() is not used at all, ov9640_set_bus_param() gets > > > assigned to a struct member, so, cannot be inline. ov9640_alter_regs() > > > is indeed only called at one location, but see Chapter 15 in > > > Documentation/CodingStyle. You left at least one multi-line comment > > > wrongly formatted. You left some broken printk format lines, etc. You > > > moved your header under drivers/... - that's good. But, please, address > > > all my comments that I provided in a private review, or explain why you > > > do not agree. Otherwise I feel like I wasted my time. Besides, your > > > mailer has wrapped lines. Please, read > > > Documentation/email-clients.txt on how to configure your email client > > > to send patches properly. In the worst case, you can inline your > > > patches while reviewing, and then attach them for a final submission. > > > This is, however, discouraged, because it makes review and test of your > > > intermediate patches with wrapped lines more difficult. Also, please > > > check your patches with scripts/checkpatch.pl. > > > > Fixed patch follows, my mailer is fixed as much as possible (working on > > getting git-email to work, but that's still to be done). Please consider > > applying, thanks. > > Ok, a couple more simple questions / remarks, In principle, there's just > one principle objection - if we agree, that the correct format is BGR565 > and RGB565X, then we should change that. There's no BGR565 format > currently in the kernel, so, we'd have to add it (and the documentation > for the mercurial tree). I dont think I understand you at all. > > Thanks > Guennadi Inlined is a new version of the patch (I did some lookup through the datasheet). I might not need the BGR formats for now. btw. weren't you planning to merge the ov96xx drivers into .31? I havent seen any of them there. Cheers! From: Marek Vasut Date: Sat, 22 Aug 2009 05:14:23 +0200 Subject: [PATCH] Add driver for OmniVision OV9640 sensor Signed-off-by: Marek Vasut --- drivers/media/video/Kconfig |6 + drivers/media/video/Makefile|1 + drivers/media/video/ov9640.c| 818 +++ drivers/media/video/ov9640.h| 209 ++ include/media/v4l2-chip-ident.h |1 + 5 files changed, 1035 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ov9640.c create mode 100644 drivers/media/video/ov9640.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 84b6fc1..fddd654 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -772,6 +772,12 @@ config SOC_CAMERA_OV772X help This is a ov772x camera driver +config SOC_CAMERA_OV9640 + tristate "ov9640 camera support" + depends on SOC_CAMERA && I2C + help + This is a ov9640 camera driver + config MX1_VIDEO bool diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 9f2e321..e18efd5 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o +obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o # And now the v4l2 drivers: diff --git a/drivers/media/video/ov9640.c b/drivers/media/video/ov9640.c new file mode 100644 index 000..0701247 --- /dev/null +++ b/drivers/media/video/ov9640.c @@ -0,0 +1,818 @@ +/* + * OmniVision OV96xx Camera Driver + * + * Copyright (C) 2009 Marek Vasut + * + * Based on ov772x camera driver: + * + * Copyright (C) 2008 Renesas Solutions Corp. + * Kuninori Morimoto + * + * Based on ov7670 and soc_camera_platform driver, + * + * Copyright 2006-7 Jonathan Corbet + * Copyright (C) 2008 Magnus Damm + * Copyright (C) 2008, Guennadi Liakhovetski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#
Re: [PATCH] hdpvr: i2c fixups for fully functional IR support
On Tue, Sep 1, 2009 at 9:30 PM, Andy Walls wrote: > On Tue, 2009-09-01 at 10:19 -0400, Jarod Wilson wrote: >> Patch is against http://hg.jannau.net/hdpvr/ >> >> 1) Adds support for building hdpvr i2c support when i2c is built as a >> module (based on work by David Engel on the mythtv-users list) >> >> 2) Refines the hdpvr_i2c_write() success check (based on a thread in >> the sagetv forums) >> >> With this patch in place, and the latest lirc_zilog driver in my lirc >> git tree, the IR part in my hdpvr works perfectly, both for reception >> and transmitting. >> >> Signed-off-by: Jarod Wilson > > Jarod, > > I recall a problem Brandon Jenkins had from last year, that when I2C was > enabled in hdpvr, his machine with multiple HVR-1600s and an HD-PVR > would produce a kernel oops. > > Have you tested this on a machine with both an HVR-1600 and HD-PVR > installed? > > Regards, > Andy > > I don't mind testing. Currently I am running ArchLinux 64-bit, kernel26-2.6.30.6-1. Please tell me where to build the driver from. Thanks, Brandon -- 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:Sun Sep 13 19:00:10 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12757:bd45a3a75049 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: ERRORS linux-2.6.24.7-armv5: ERRORS linux-2.6.25.11-armv5: ERRORS linux-2.6.26-armv5: ERRORS linux-2.6.27-armv5: ERRORS linux-2.6.28-armv5: ERRORS linux-2.6.29.1-armv5: ERRORS linux-2.6.30-armv5: ERRORS linux-2.6.31-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: OK linux-2.6.28-armv5-omap2: ERRORS linux-2.6.29.1-armv5-omap2: ERRORS linux-2.6.30-armv5-omap2: ERRORS linux-2.6.31-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: ERRORS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30-i686: ERRORS linux-2.6.31-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK 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.30-mips: ERRORS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: ERRORS linux-2.6.27-x86_64: ERRORS linux-2.6.28-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30-x86_64: ERRORS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): 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: ERRORS linux-2.6.21.7-i686: ERRORS 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: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build 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
Re: [Patch 2/2] stv06xx webcams with HDCS 1xxx sensors
Hi, On 09/10/2009 09:51 AM, Erik Andrén wrote: Looks good! Thanks, Acked-by: Erik Andrén Erik, Are you going to merge these 2 patches in your tree, and let them find their way into the master this way, or shall I merge them in my tree ? Regards, Hans -- 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 2/2] stv06xx webcams with HDCS 1xxx sensors
2009/9/13 Hans de Goede : > Hi, > > On 09/10/2009 09:51 AM, Erik Andrén wrote: > > > >> >> Looks good! >> Thanks, >> >> Acked-by: Erik Andrén > > Erik, > > Are you going to merge these 2 patches in your tree, and let them find > their way into the master this way, or shall I merge them in my tree ? > Hi, I was under the impression that Jean-Francois took stv06xx patches directly into his tree. But you can of course take them too if you want to. Best regards, Erik > Regards, > > Hans > > -- 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 2/2] stv06xx webcams with HDCS 1xxx sensors
2009/9/13 Hans de Goede : > Hi, > > On 09/10/2009 09:51 AM, Erik Andrén wrote: > > > >> >> Looks good! >> Thanks, >> >> Acked-by: Erik Andrén > > Erik, > > Are you going to merge these 2 patches in your tree, and let them find > their way into the master this way, or shall I merge them in my tree ? > Also, It would be good if you are able to test the patches as you have HDCS based hardware. Best regards, Erik > Regards, > > Hans > > -- 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: image quality of Labtec Webcam 2200
Hi, On 09/13/2009 09:20 AM, Jean-Francois Moine wrote: On Fri, 11 Sep 2009 09:09:20 +0200 Németh Márton wrote: You can find my results at http://v4l-test.sourceforge.net/results/test-20090911/index.html There are three types of problems: a) Sometimes the picture contains a 8x8 pixel error, like in image #9 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 b) Sometimes the brightness of the half picture is changed, like in images #7, #36 and #37 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 c) Sometimes the libv4l cannot convert the raw image and the errno is set to EAGAIN (11), for example image #1, #2 and #3 Do you know how can I fix these problems? The error EAGAIN is normal when decoding pac7311 images, because they are rotated 90°. But this error should occur one time only. I looked at the raw image #1, and it seems that there are JPEG errors inside (sequences ff ff). There should be a problem in the pac7311 driver. Hans, may you confirm? The pac7311 / pac7302 are very cheap crap cams (I bought one brand new for 3 euros, and that was not in the bargain bin). These cams use a custom jpeg format, and we are very luky to be able to decompress this at all (thanks to some of the wizards who worked on the original gspca driver). Yes there are still some issues, but with no documentation what soever, and unreliable hardware (I've seen hang cams which needed to be unplugged / replugged to start working again), I'm afraid there is nothing we can do. Still if people want to work on improving support for them more power to then, I'll gladly help where I can. The ff ff you've found are special Pixart padding sequences, see tinyjpeg.c: pixart_fill_nbits() Also interesting is the comment about some of the special Pxiart markers in the tinyjpeg.c: pixart_decode_MCU_2x1_3planes() function. Which summaries what i've learned while getting pac7302 cams to work (to a certain extend). Regards, Hans -- 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: image quality of Labtec Webcam 2200
Hi, On 09/13/2009 05:59 PM, Thomas Kaiser wrote: I thought Hans will come in, in this discussion... Hey hey, its weekend, give me some time to respond already :) See my reply higher up in the thread. Regards, Hans -- 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 2/3] Add driver for OmniVision OV9640 sensor
On Sun, 13 Sep 2009, Marek Vasut wrote: > Dne Pá 11. záÅà 2009 23:51:44 Guennadi Liakhovetski napsal(a): > > > > Ok, a couple more simple questions / remarks, In principle, there's just > > one principle objection - if we agree, that the correct format is BGR565 > > and RGB565X, then we should change that. There's no BGR565 format > > currently in the kernel, so, we'd have to add it (and the documentation > > for the mercurial tree). > > I dont think I understand you at all. Your patch used RGB565X, which is the same as RGB565 but with _bytes_ swapped, whereas earlier you confirmed, that it's not a byte-swapped RGB565 but rather R and B _colours_ are swapped: http://marc.info/?l=linux-arm-kernel&m=125220918005429&w=2 , i.e., it is a BGR565. Now it looks like you don't change anything in your RGB processing code, but you declare it as plain RGB555 and RGB565 codes. So, are these really the normal unswapped formats or am I missing something? And you replaced VYUY with UYVY while also modifying register configuration, so, I hope, this has settled now and your current configuration works properly with the unmodified pxa270 for you, right? Oh, damn, I see now, I put my signature above the patch, so, you didn't look below it, and there were a couple more comments there:-( Sorry! All of them should be pretty easy to fix, so, please have a look at them. > Inlined is a new version of the patch (I did some lookup through the > datasheet). > I might not need the BGR formats for now. > > btw. weren't you planning to merge the ov96xx drivers into .31? I havent seen > any of them there. Which ov96xx drivers? Do you mean the ov9655 driver from Stefan Herbrechtsmeier? My doubt with the latter one was (and still is), that we already have two drivers in the mainline (gspca/sn9c20x.c and gspca/ov534.c) that seem to claim support for that chip, so, I wanted to see, if we could reuse them. There's also an ov7670 from Jonathan Cameron with the same issue. And for that merge we have to come closer to v4l2-subdev, which is happening just now. 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
Questions about Terratec Hybrid XS (em2882) [0ccd:005e]
Hello. I have the Terratec Cinergy Hybrid T XS USB (em2882) - usb-id 0ccd:005e. It works with Marcus Rechberger's em28xx-new driver, but since that code is unmaintained now, I tested this device with v4l-dvb today. The analog picture is there, but audio is very, very quiet, almost not there. Is there some way to increase the volume? Second question, what would be required to get DVB working? The final thing is not a question, it's actually something that works: the remote. It's the same one as comes with the other Hybrid XS (0ccd:0042), adding these two lines to the definition of this card in em28xx-cards.c makes it work: .ir_codes = &ir_codes_terratec_cinergy_xs_table, .xclk = EM28XX_XCLK_FREQUENCY_12MHZ, Any pointers to solving my issues (analog audio, dvb) appreciated. I can test patches, I can give ssh access to my machine if it helps. There's even a Windows install on this machine, so USB sniffing of the Windows driver is possible, I just need instructions on what exactly to do. Dmesg output for this device is attached. Regards, Uroš usb 1-4: new high speed USB device using ehci_hcd and address 6 usb 1-4: configuration #1 chosen from 1 choice Linux video capture interface: v2.00 em28xx: New device TerraTec Electronic GmbH Cinergy Hybrid T USB XS (2882) @ 480 Mbps (0ccd:005e, interface 0, class 0) em28xx #0: chip ID is em2882/em2883 em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 5e 00 d0 12 5c 03 9e 40 de 1c em28xx #0: i2c eeprom 10: 6a 34 27 57 46 07 01 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 31 00 b8 00 14 00 5b 1e 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 00 00 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 34 03 54 00 65 00 em28xx #0: i2c eeprom 70: 72 00 72 00 61 00 54 00 65 00 63 00 20 00 45 00 em28xx #0: i2c eeprom 80: 6c 00 65 00 63 00 74 00 72 00 6f 00 6e 00 69 00 em28xx #0: i2c eeprom 90: 63 00 20 00 47 00 6d 00 62 00 48 00 00 00 40 03 em28xx #0: i2c eeprom a0: 43 00 69 00 6e 00 65 00 72 00 67 00 79 00 20 00 em28xx #0: i2c eeprom b0: 48 00 79 00 62 00 72 00 69 00 64 00 20 00 54 00 em28xx #0: i2c eeprom c0: 20 00 55 00 53 00 42 00 20 00 58 00 53 00 20 00 em28xx #0: i2c eeprom d0: 28 00 32 00 38 00 38 00 32 00 29 00 00 00 1c 03 em28xx #0: i2c eeprom e0: 30 00 36 00 30 00 39 00 30 00 32 00 30 00 31 00 em28xx #0: i2c eeprom f0: 33 00 38 00 34 00 33 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x7713bfbe em28xx #0: EEPROM info: em28xx #0: AC97 audio (5 sample rates) em28xx #0: 500mA max power em28xx #0: Table at 0x27, strings=0x409e, 0x1cde, 0x346a em28xx #0: Identified as Terratec Hybrid XS (em2882) (card=55) em28xx #0: em28xx #0: The support for this board weren't valid yet. em28xx #0: Please send a report of having this working em28xx #0: not to V4L mailing list (and/or to other addresses) tvp5150 4-005c: chip found @ 0xb8 (em28xx #0) tuner 4-0061: chip found @ 0xc2 (em28xx #0) xc2028 4-0061: creating new instance xc2028 4-0061: type set to XCeive xc2028/xc3028 tuner usb 1-4: firmware: requesting xc3028-v27.fw xc2028 4-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 4-0061: Loading firmware for type=BASE (1), id . xc2028 4-0061: Loading firmware for type=(0), id b700. SCODE (2000), id b700: xc2028 4-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. em28xx #0: Config register raw data: 0xd0 em28xx #0: AC97 vendor ID = 0x em28xx #0: AC97 features = 0x6a90 em28xx #0: Empia 202 AC97 audio processor detected tvp5150 4-005c: tvp5150am1 detected. em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 usbcore: registered new interface driver em28xx em28xx driver loaded em28xx-audio.c: probing for em28x1 non standard usbaudio em28xx-audio.c: Copyright (C) 2006 Markus Rechberger Em28xx: Initialized (Em28xx Audio Extension) extension tvp5150 4-005c: tvp5150am1 detected. xc2028 4-0061: Loading firmware for type=BASE F8MHZ (3), id . xc2028 4-0061: Loading firmware for type=(0), id 00010007. xc2028 4-0061: Loading SCODE for type=MONO SCODE HAS_IF_5320 (60008000), id 000f0007.
[PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
Mauro, Just some minor vflip quirks in this patch. I'll be posting a reworked m5602-ov7660 patch set shortly. Please pull from http://linuxtv.org/hg/~eandren/v4l-dvb for the following 2 changesets: 01/02: gspca - m5602-s5k4aa: Add vflip quirk for the Amilo Pa 2548 http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=95d9feab8d78 02/02: gspca - m5602-s5k4aa: Add vflip quirk for the GX700 http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=1436152bd9db m5602_s5k4aa.c | 13 + 1 file changed, 13 insertions(+) Thanks, Erik -- 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: test
Come listen to a story about a named Jed... --Original Message-- From: Jed Sender: linux-media-ow...@vger.kernel.org To: Linux Media Mailing List Sent: Sep 13, 2009 10:03 AM Subject: test this is a test -- 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 Sent from my Verizon Wireless BlackBerry -- 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 2/8] drivers/media/video/uvc: introduce missing kfree
On Friday 11 September 2009 18:21:18 Julia Lawall wrote:
> From: Julia Lawall
>
> Error handling code following kmalloc should free the allocated data.
>
> The semantic match that finds the problem is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
>
> //
> @r exists@
> local idexpression x;
> statement S;
> expression E;
> identifier f,f1,l;
> position p1,p2;
> expression *ptr != NULL;
> @@
>
> x...@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
> ...
> if (x == NULL) S
> <... when != x
> when != if (...) { <+...x...+> }
> (
> x->f1 = E
>
> (x->f1 == NULL || ...)
>
> f(...,x->f1,...)
> )
> ...>
> (
> return \(0\|<+...x...+>\|ptr\);
>
> ret...@p2 ...;
> )
>
> @script:python@
> p1 << r.p1;
> p2 << r.p2;
> @@
>
> print "* file: %s kmalloc %s return %s" %
> (p1[0].file,p1[0].line,p2[0].line) //
>
> Signed-off-by: Julia Lawall
> ---
> drivers/media/video/uvc/uvc_video.c |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/video/uvc/uvc_video.c
> b/drivers/media/video/uvc/uvc_video.c index 5b757f3..ce2c484 100644
> --- a/drivers/media/video/uvc/uvc_video.c
> +++ b/drivers/media/video/uvc/uvc_video.c
> @@ -128,8 +128,11 @@ static int uvc_get_video_ctrl(struct uvc_streaming
> *stream, if (data == NULL)
> return -ENOMEM;
>
> - if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) && query == UVC_GET_DEF)
> - return -EIO;
> + if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
> + query == UVC_GET_DEF) {
> + ret = -EIO;
> + goto out;
> + }
This check can be moved before kmalloc(), removing the need to free memory in
case of error.
Julia, do you want to submit a modified patch or should I do it myself ?
> ret = __uvc_query_ctrl(stream->dev, query, 0, stream->intfnum,
> probe ? UVC_VS_PROBE_CONTROL : UVC_VS_COMMIT_CONTROL, data,
>
--
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: [PATCH 2/8] drivers/media/video/uvc: introduce missing kfree
> > - if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) && query == UVC_GET_DEF)
> > - return -EIO;
> > + if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
> > + query == UVC_GET_DEF) {
> > + ret = -EIO;
> > + goto out;
> > + }
>
> This check can be moved before kmalloc(), removing the need to free memory in
> case of error.
>
> Julia, do you want to submit a modified patch or should I do it myself ?
I can do it. I will send a revised patch shortly.
julia
--
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 2/8] drivers/media/video/uvc: introduce missing kfree
From: Julia Lawall
Move the kzalloc and associated test after the stream/query test, to avoid
the need to free the allocated if the stream/query test fails.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x...@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
ret...@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
//
Signed-off-by: Julia Lawall
---
drivers/media/video/uvc/uvc_video.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index 5b757f3..f960e8e 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -124,13 +124,14 @@ static int uvc_get_video_ctrl(struct uvc_streaming
*stream,
int ret;
size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
+ if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
+ query == UVC_GET_DEF)
+ return -EIO;
+
data = kmalloc(size, GFP_KERNEL);
if (data == NULL)
return -ENOMEM;
- if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) && query == UVC_GET_DEF)
- return -EIO;
-
ret = __uvc_query_ctrl(stream->dev, query, 0, stream->intfnum,
probe ? UVC_VS_PROBE_CONTROL : UVC_VS_COMMIT_CONTROL, data,
size, UVC_CTRL_STREAMING_TIMEOUT);
--
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] hdpvr: i2c fixups for fully functional IR support
On Sep 13, 2009, at 1:23 PM, Brandon Jenkins wrote: On Tue, Sep 1, 2009 at 9:30 PM, Andy Walls wrote: On Tue, 2009-09-01 at 10:19 -0400, Jarod Wilson wrote: Patch is against http://hg.jannau.net/hdpvr/ 1) Adds support for building hdpvr i2c support when i2c is built as a module (based on work by David Engel on the mythtv-users list) 2) Refines the hdpvr_i2c_write() success check (based on a thread in the sagetv forums) With this patch in place, and the latest lirc_zilog driver in my lirc git tree, the IR part in my hdpvr works perfectly, both for reception and transmitting. Signed-off-by: Jarod Wilson Jarod, I recall a problem Brandon Jenkins had from last year, that when I2C was enabled in hdpvr, his machine with multiple HVR-1600s and an HD-PVR would produce a kernel oops. Have you tested this on a machine with both an HVR-1600 and HD-PVR installed? Regards, Andy I don't mind testing. Currently I am running ArchLinux 64-bit, kernel26-2.6.30.6-1. Please tell me where to build the driver from. Hrm... It *was* in Janne's hdpvr tree, but it seems to have gone missing... v4l-dvb tip + this patch should work too: http://wilsonet.com/jarod/junk/hdpvr-ir/hdpvr-ir-2.6.31.patch This is exactly what I put in the Fedora 2.6.31 kernel, iirc, and works a treat here. Have also tested against 2.6.29 in a box with a pcHDTV HD-3000 a Hauppauge HVR-1250 and HVR-1800 in it with no issues, so fingers crossed... -- Jarod Wilson ja...@wilsonet.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: RFC: bus and data format negotiation
On Sun, 13 Sep 2009, Hans Verkuil wrote: > (I promised that I would analyze this. Sorry that it took so long, but I > had a lot of other things going on and this was one topic that I needed to > really sit down for and think about carefully.) > > RFC: bus and data format negotiation > > Version 1.0 > > > Background > == > > As media boards become more complex it is getting harder to enumerate and > setup the busses that connect the various components on the board and to > map that to actual pixelformats (i.e. how the data will end up in memory). > > This is a particular problem for sensors that can often be connected in > many different ways. > > Several attempts have been made to find a good internal API for this, but > none were satisfactory. > > In this RFC I'll analyze how such connections are made, what the core problems > are and I'll present a solution that hopefully solves these problems in a > well-defined and not too complex way. This RFC is directly related to open > issue #3 in the media controller RFC. > > > Analysis > > > In general you have two components, A and B, and some sort of a bus between > them (i.e. the physical wires). This can be straightforward, e.g. 10 pins > on either side are directly connected, or there can be additional components > in between like level converters or perhaps even complex FPGAs that are not > under our control but that nevertheless can make changes in how the data is > presented. Or a multiplexer. > While information on such components may not be available at the > driver level, it is available at platform (board) level. > > More complex boards have more than two components and multiple busses, but > many of the basics remain the same. > > > Bus configuration > - > > In order to setup a component you will need to supply a bus configuration > that sets up the physical properties of the bus: signal polarities, how the > data should be sampled, etc. > > In many cases there is only one possible bus configuration. But especially > sensors have more configurations. This configuration should come from the > board specification and not be autonegotiated. Depending on the board layout > a wrong bus configuration can have quite unpredictable results. Even though > both sides of the bus may seemingly support a specific configuration > additional > board-specific factors may prevent that configuration from working reliably. > > > Data formats > > > For a given bus configuration a component can support one or more data > formats. A data format is similar, but not identical, to a pixel format. A > pixel format defines the format of the video in memory. A data format defines > the format of the video on a bus. The component's driver will know which data > formats it supports given the bus config. Would be good to mention here, that a new enumeration will be created for those data formats. > Note that changing the bus config on the fly will also change the list of > supported data formats. Normally a bus config is setup once and not changed, > but this is not necessarily always the case. > > > Video timings > - > > Once the bus is configured and the data format is set it is finally possible > to determine what resolutions and framerates are supported. Here we run into > a problem, though. The current V4L2 API is not clear on how that should be > done. > > We have three enumeration ioctls involved in this: either VIDIOC_ENUMSTD to > enumerate the supported video standards for analog TV video encoders and > decoders, and VIDIOC_ENUM_FRAMESIZES/FRAMEINTERVALS to enumerate native > sensor resolutions and framerates. Unfortunately the spec is not clear whether > ENUM_FRAMESIZES/INTERVALS really refers to the sensor (or more general, the > component that is the initial source of the video stream) or to the sizes > and framerates that you can capture on the video node. > > What makes this worse is that there is an essential ioctl missing: you need > to have the equivalent of VIDIOC_S_STD to setup a sensor to a specific > resolution/framerate. Right now VIDIOC_S_FMT is used for that, but that is > really meant to take an input resolution and scale it up or down to the > desired resolution. It is not meant to setup a sensor (or video source or sink > in general) to a particular resolution. > > To fix this we need to 1) specify that the framesize/interval enumeration > relates to the video source and not to the output of a possible scaler, and > 2) add support for setting up a sensor to a specific size/framerate. Murali > Karicheri from TI is working on something similar. > > Using S_FMT to select a particular resolution never felt right, and now I > realize why. Luckily I don't think any of the webcam drivers we have currently > do any scaling, so using S_FMT will still work for those and applications do > not need to be modified. > > To do the sensor setup in the new-style we can either int
Re: RFC: bus and data format negotiation
On Sunday 13 September 2009 23:26:54 Guennadi Liakhovetski wrote: > On Sun, 13 Sep 2009, Hans Verkuil wrote: > > > (I promised that I would analyze this. Sorry that it took so long, but I > > had a lot of other things going on and this was one topic that I needed to > > really sit down for and think about carefully.) > > > > RFC: bus and data format negotiation > > > > Version 1.0 > > > > > > Background > > == > > > > As media boards become more complex it is getting harder to enumerate and > > setup the busses that connect the various components on the board and to > > map that to actual pixelformats (i.e. how the data will end up in memory). > > > > This is a particular problem for sensors that can often be connected in > > many different ways. > > > > Several attempts have been made to find a good internal API for this, but > > none were satisfactory. > > > > In this RFC I'll analyze how such connections are made, what the core > > problems > > are and I'll present a solution that hopefully solves these problems in a > > well-defined and not too complex way. This RFC is directly related to open > > issue #3 in the media controller RFC. > > > > > > Analysis > > > > > > In general you have two components, A and B, and some sort of a bus between > > them (i.e. the physical wires). This can be straightforward, e.g. 10 pins > > on either side are directly connected, or there can be additional components > > in between like level converters or perhaps even complex FPGAs that are not > > under our control but that nevertheless can make changes in how the data is > > presented. > > Or a multiplexer. > > > While information on such components may not be available at the > > driver level, it is available at platform (board) level. > > > > More complex boards have more than two components and multiple busses, but > > many of the basics remain the same. > > > > > > Bus configuration > > - > > > > In order to setup a component you will need to supply a bus configuration > > that sets up the physical properties of the bus: signal polarities, how the > > data should be sampled, etc. > > > > In many cases there is only one possible bus configuration. But especially > > sensors have more configurations. This configuration should come from the > > board specification and not be autonegotiated. Depending on the board layout > > a wrong bus configuration can have quite unpredictable results. Even though > > both sides of the bus may seemingly support a specific configuration > > additional > > board-specific factors may prevent that configuration from working reliably. > > > > > > Data formats > > > > > > For a given bus configuration a component can support one or more data > > formats. A data format is similar, but not identical, to a pixel format. A > > pixel format defines the format of the video in memory. A data format > > defines > > the format of the video on a bus. The component's driver will know which > > data > > formats it supports given the bus config. > > Would be good to mention here, that a new enumeration will be created for > those data formats. I'm not sure. It can be as simple as an array of data formats that is accessed from the v4l2_subdev struct. In that case no enumeration is needed. Although to be realistic I suspect we need one in the v4l2_subdev ops. What I don't know yet is whether we also need something like that in userspace for use with the media controller. I'd say we don't for now. > > Note that changing the bus config on the fly will also change the list of > > supported data formats. Normally a bus config is setup once and not changed, > > but this is not necessarily always the case. > > > > > > Video timings > > - > > > > Once the bus is configured and the data format is set it is finally possible > > to determine what resolutions and framerates are supported. Here we run into > > a problem, though. The current V4L2 API is not clear on how that should be > > done. > > > > We have three enumeration ioctls involved in this: either VIDIOC_ENUMSTD to > > enumerate the supported video standards for analog TV video encoders and > > decoders, and VIDIOC_ENUM_FRAMESIZES/FRAMEINTERVALS to enumerate native > > sensor resolutions and framerates. Unfortunately the spec is not clear > > whether > > ENUM_FRAMESIZES/INTERVALS really refers to the sensor (or more general, the > > component that is the initial source of the video stream) or to the sizes > > and framerates that you can capture on the video node. > > > > What makes this worse is that there is an essential ioctl missing: you need > > to have the equivalent of VIDIOC_S_STD to setup a sensor to a specific > > resolution/framerate. Right now VIDIOC_S_FMT is used for that, but that is > > really meant to take an input resolution and scale it up or down to the > > desired resolution. It is not meant to setup a sensor (or video source or > > sink > > i
Re: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support, giving up.
just out of curiosity ( and because google showed me a new trick to try
), i tried to load the module with gpio_tracking=1.
this gave me a new thing in dmesg :
gpio: mode=0x000 in=0x07f out=0x000 [pre-init]
Am i correct by thinkig that the in=0x07f part is the mask ? If it
is that then i am a problem : i did specify it as 0xff. Did i miss
something ?
hermann pitton a écrit :
Am Samstag, den 12.09.2009, 10:14 +0200 schrieb Morvan Le Meut:
Since i don't know where to look, i finally decided to use a basic
incorrect keymap :
/* ADS Tech Instant TV PCI Remote */
static struct ir_scancode ir_codes_adstech_pci[] = {
/* too many repeating codes : incorrect gpio ?. */
{ 0x1f, KEY_MUTE },
{ 0x1d, KEY_SEARCH },
{ 0x17, KEY_EPG },/* Guide */
{ 0x0f, KEY_UP },
{ 0x6, KEY_DOWN },
{ 0x16, KEY_LEFT },
{ 0x1e, KEY_RIGHT },
{ 0x0e, KEY_SELECT },/* Enter */
{ 0x1a, KEY_INFO },
{ 0x12, KEY_EXIT },
{ 0x19, KEY_PREVIOUS },
{ 0x11, KEY_NEXT },
{ 0x18, KEY_REWIND },
{ 0x10, KEY_FORWARD },
{ 0x4, KEY_PLAYPAUSE },
{ 0x07, KEY_STOP },
{ 0x1b, KEY_RECORD },
{ 0x13, KEY_TUNER },/* Live */
{ 0x0a, KEY_A },
{ 0x03, KEY_PROG1 },/* 1 */
{ 0x01, KEY_PROG2 },/* 2 */
{ 0x0, KEY_VIDEO },
{ 0x0b, KEY_CHANNELUP },
{ 0x08, KEY_CHANNELDOWN },
{ 0x15, KEY_VOLUMEUP },
{ 0x1c, KEY_VOLUMEDOWN },
};
struct ir_scancode_table ir_codes_adstech_pci_table = {
.scan = ir_codes_adstech_pci,
.size = ARRAY_SIZE(ir_codes_adstech_pci),
};
EXPORT_SYMBOL_GPL(ir_codes_adstech_pci_table);
No numbers in favor of arrows and ch+/- Vol+/- . Well 246 will be arrows
and 5 select, 7 and 8 are undefined, 9 become vol-, 1 epg and 3 is tuner.
If someone, one day, wants to find that missig bit, i'll be happy to
help. ( Strange anyway : it's as if there was a 0x7f mask even when i
specify a 0xff one )
Feel free to write a patch.
Morvan Le Meut a écrit :
um .. help, please ?
how can i make the driver read 1011011 instead of 011011 when i press
Power instead of record on the remote ?
thanks
Morvan,
I still have a huge mail backlash and are not in details what you may
have tried already, but if you have a missing/unknown gpio on such a
remote, you start to test for that one with mask_keycode = 0x0 in
saa7134-input.c and if it is then found, you do add it to that mask.
If that doesn't help, it might be something special.
Cheers,
Hermann
--
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] hdpvr: i2c fixups for fully functional IR support
On Sun, Sep 13, 2009 at 05:04:16PM -0400, Jarod Wilson wrote: > On Sep 13, 2009, at 1:23 PM, Brandon Jenkins wrote: > > > I don't mind testing. Currently I am running ArchLinux 64-bit, > > kernel26-2.6.30.6-1. Please tell me where to build the driver from. > > Hrm... It *was* in Janne's hdpvr tree, but it seems to have gone > missing... It's in http://hg.jannau.net/hdpvr. I just merged several weeks of v4l-dvb changes after the last commit. So it's not at the top of the log. Janne -- 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: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support, giving up.
Hi,
Am Sonntag, den 13.09.2009, 23:59 +0200 schrieb Morvan Le Meut:
> just out of curiosity ( and because google showed me a new trick to try
> ), i tried to load the module with gpio_tracking=1.
> this gave me a new thing in dmesg :
> gpio: mode=0x000 in=0x07f out=0x000 [pre-init]
> Am i correct by thinkig that the in=0x07f part is the mask ? If it
> is that then i am a problem : i did specify it as 0xff. Did i miss
> something ?
it does not cover the IR gpio settings, but what happens in the card
entry at saa7134-cards.c.
"mode" is the gpio mask defined there, if any. You have nothing set
there.
"in" is the actual configuration of the gpio pins. This can reflect
changes made to them, for example from using an other cards entry
previously, which can change some pins or changes in different modes on
them, which are not yet reset. By default it shows the manufacturers
gpio configuration. 0x7f can mean that the first seven pins (0-6) are
used for the gpio remote. That would be your mask keycode then.
"out" is what the driver writes to the gpios of that card.
In this mode only pins are changed, which are high in the mask,
this is called masked writes. In your case nothing happens.
See my next mail for a simple example of changing the single gpio21 pin
to 0 in Television mode.
Cheers,
Hermann
> hermann pitton a écrit :
> > Am Samstag, den 12.09.2009, 10:14 +0200 schrieb Morvan Le Meut:
> >
> >> Since i don't know where to look, i finally decided to use a basic
> >> incorrect keymap :
> >> /* ADS Tech Instant TV PCI Remote */
> >> static struct ir_scancode ir_codes_adstech_pci[] = {
> >> /* too many repeating codes : incorrect gpio ?. */
> >>
> >> { 0x1f, KEY_MUTE },
> >> { 0x1d, KEY_SEARCH },
> >> { 0x17, KEY_EPG },/* Guide */
> >> { 0x0f, KEY_UP },
> >> { 0x6, KEY_DOWN },
> >> { 0x16, KEY_LEFT },
> >> { 0x1e, KEY_RIGHT },
> >> { 0x0e, KEY_SELECT },/* Enter */
> >> { 0x1a, KEY_INFO },
> >> { 0x12, KEY_EXIT },
> >> { 0x19, KEY_PREVIOUS },
> >> { 0x11, KEY_NEXT },
> >> { 0x18, KEY_REWIND },
> >> { 0x10, KEY_FORWARD },
> >> { 0x4, KEY_PLAYPAUSE },
> >> { 0x07, KEY_STOP },
> >> { 0x1b, KEY_RECORD },
> >> { 0x13, KEY_TUNER },/* Live */
> >> { 0x0a, KEY_A },
> >> { 0x03, KEY_PROG1 },/* 1 */
> >> { 0x01, KEY_PROG2 },/* 2 */
> >> { 0x0, KEY_VIDEO },
> >> { 0x0b, KEY_CHANNELUP },
> >> { 0x08, KEY_CHANNELDOWN },
> >> { 0x15, KEY_VOLUMEUP },
> >> { 0x1c, KEY_VOLUMEDOWN },
> >> };
> >>
> >> struct ir_scancode_table ir_codes_adstech_pci_table = {
> >> .scan = ir_codes_adstech_pci,
> >> .size = ARRAY_SIZE(ir_codes_adstech_pci),
> >> };
> >> EXPORT_SYMBOL_GPL(ir_codes_adstech_pci_table);
> >>
> >> No numbers in favor of arrows and ch+/- Vol+/- . Well 246 will be arrows
> >> and 5 select, 7 and 8 are undefined, 9 become vol-, 1 epg and 3 is tuner.
> >> If someone, one day, wants to find that missig bit, i'll be happy to
> >> help. ( Strange anyway : it's as if there was a 0x7f mask even when i
> >> specify a 0xff one )
> >> Feel free to write a patch.
> >>
> >> Morvan Le Meut a écrit :
> >>
> >>> um .. help, please ?
> >>> how can i make the driver read 1011011 instead of 011011 when i press
> >>> Power instead of record on the remote ?
> >>>
> >>> thanks
> >>>
> >>>
> >
> > Morvan,
> >
> > I still have a huge mail backlash and are not in details what you may
> > have tried already, but if you have a missing/unknown gpio on such a
> > remote, you start to test for that one with mask_keycode = 0x0 in
> > saa7134-input.c and if it is then found, you do add it to that mask.
> >
> > If that doesn't help, it might be something special.
> >
> > Cheers,
> > Hermann
> >
--
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: Problems with Pinnacle 310i (saa7134) and recent kernels
Hi, Am Sonntag, den 13.09.2009, 12:02 + schrieb Avl Jawrowski: > Hi, > > hermann pitton arcor.de> writes: > > > > > I'm sorry that we have some mess on some of such devices, but currently > > really nobody can help much further. > > > > Mike and Hauppauge don't have any schematics for LNA and external > > antenna voltage switching for now, he assured it to me personally and we > > must live with the back hacks for now and try to further work through > > it. > > > > However, mplayer should work as well, but my last checkout is a little > > out dated. > > > > It will go to Nico anyway, he is usually at the list here. > > > > If you can tell me on what you are, I might be able to confirm or not. > > Do you mean the exact card I have? I can do some photos if they can help. > Unfortunately I don't have the original eeprom content. no, in this case I meant mplayer should work for you too. You need to have DVB support enabled and a channels.conf file in ~/.mplayer. We might collect pictures of the cards and remotes as well. To identify those card with an additional LNA circuitry is likely not easy hardware wise, since the tuner shielding is soldered with 16 pins, many close to lines. Maybe we can identify those boards by the card revision printed on them. Don't know how to auto detect them. > In the matter of the IR, the modules seems to be loaded: > > tda1004x 13048 1 > saa7134_dvb20772 0 > videobuf_dvb5644 1 saa7134_dvb > ir_kbd_i2c 5500 0 > tda827x 8880 2 > tuner 16960 1 > saa7134 138436 1 saa7134_dvb > ir_common 41828 2 ir_kbd_i2c,saa7134 > videobuf_dma_sg 9876 2 saa7134_dvb,saa7134 > videobuf_core 13596 3 videobuf_dvb,saa7134,videobuf_dma_sg > tveeprom 10488 1 saa7134 > > But I can't find anything in /proc/bus/input/devices. We might have more than the two supported remotes on such cards. After all that would not make me wonder anymore and the windows driver presents some more. Do you have that silver remote with colored buttons. There must be a device at 0x47 detected to support it. You might have to load ir-kbd-i2c at first or reload saa7134-alsa and saa7134-dvb, which includes saa7134. If OK, looks like this here. saa7133[2]: setting pci latency timer to 64 saa7133[2]: found at :04:03.0, rev: 208, irq: 21, latency: 64, mmio: 0xfebfe800 saa7133[2]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,insmod option] saa7133[2]: board init: gpio is 600c000 saa7133[2]: gpio: mode=0x000 in=0x600c000 out=0x000 [pre-init] IRQ 21/saa7133[2]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[2]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[2]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2c b0 22 ff ff saa7133[2]: i2c eeprom 20: 01 2c 01 02 02 01 04 30 98 ff 00 a5 ff 21 00 c2 saa7133[2]: i2c eeprom 30: 96 10 03 32 15 20 ff ff 0c 22 17 88 03 44 31 f9 saa7133[2]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff input: i2c IR (Pinnacle PCTV) as /class/input/input7 ir-kbd-i2c: i2c IR (Pinnacle PCTV) detected at i2c-3/3-0047/ir0 [saa7133[2]] tuner 3-004b: chip found @ 0x96 (saa7133[2]) tda829x 3-004b: setting tuner address to 61 tda829x 3-004b: type set to tda8290+75a saa7133[2]: gpio: mode=0x020 in=0x600e000 out=0x000 [Television] saa7133[2]: gpio: mode=0x020 in=0x600e000 out=0x000 [Television] saa7133[2]: gpio: mode=0x020 in=0x600c000 out=0x000 [Television] saa7133[2]: registered device video2 [v4l2] saa7133[2]: registered device vbi2 saa7133[2]: registered device radio0 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 29 -- ok saa7133[0]/dvb: setting GPIO21 to 1 (Radio antenna?) dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[1]) DVB: registering adapter 1 frontend 0 (Philips TDA10086 DVB-S)... dvb_init() allocating 1 frontend DVB: registering new
Re: Pinnacle PCTV 310i active antenna
Hi Martin, Am Sonntag, den 13.09.2009, 16:37 +0200 schrieb Martin Konopka: > Hi Hermann, > > thank you, the patch for the antenna power is working for me with the latest > mercurial tree. I'm now able to receive additional weak channels. On the > contrary a channel close by with a very strong signal disappeared. The > stand-alone receiver with antenna power that I have can receive both channels > at the same time. thanks for your testing! On many demods it is already reported, that a too strong signal might need attenuation. With the mix of different transmitters we now have, more established by means to serve federal states instead of having an over all concept, I don't wonder to get such a report now too the first time. It likely needs some RFC to think about all possible combinations of LNAs and active antenna support and how best to deal with it. Cheers, Hermann > Am Sonntag, 30. August 2009 01:38:35 schrieb hermann pitton: > > A testhack, not a clean implementation, is attached and should give you > > voltage to the active antenna when using DVB-T. > > > > BTW, the radio seems to be broken since some weeks. > > It is not by that patch here. > > > > Cheers, > > Hermann > > > > > Cheers, > > Martin -- 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: Media controller: sysfs vs ioctl
Em Sun, 13 Sep 2009 17:54:11 +0200 wk escreveu: > Hans Verkuil schrieb: > > Hi all, > > > > I've started this as a new thread to prevent polluting the discussions of > > the > > media controller as a concept. > > > > First of all, I have no doubt that everything that you can do with an ioctl, > > you can also do with sysfs and vice versa. That's not the problem here. > > > > The problem is deciding which approach is the best. > > > > > > Is it really a good idea to create a dependency to some virtual file > system which may go away in future? > From time to time some of those seem to go away, for example devfs. > Is it really unavoidable to have something in sysfs, something which is > really not possible with ioctls? > And do you really want to depend on sysfs developers? First of all, both ioctl's and sysfs are part of vfs support. Second: where did you got the wrong information that sysfs would be deprecated? There's no plan to deprecate sysfs, and, since there are lots of kernel-userspace API's depending on sysfs, you can't just remove it. It is completely different from what we had with devfs, where just device names were created there, on a limited way (for example, no directories were allowed at devfs). Yet, before devfs removal, sysfs was added to implement the same features, providing even more functionality. Removing sysfs is as hard as removing ioctl or procfs support on kernel. You may change their internal implementation, but not the userspace API. Btw, if we'll seek for the last internal changes, among those three API's, the more recent internal changes were at fs API where ioctl support is. There, the Kernel big logs were removed. This required a review on all driver locks and changes on almost all v4l/dvb drivers. Also, wanting or not, sysfs is called on every kernel driver, so this dependency already exists. 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
[ANOUNCE] Staging trees at V4L/DVB trees
Probably some of you already noticed that we're creating some staging trees at V4L/DVB trees. There are currently 2 staging trees: 1) /linux/drivers/staging - With drivers that aren't ready yet for merge, needing help for being finished. There are currently two drivers there: go7007 driver - Used on some designs with a Micronas encoder. cx25821 driver - Driver for Conexant cx25821 chips. The go7007 driver were written a long time ago and requires not only CodingStyle fixes but also porting to some new API's and to V4L2 framework. This driver is already at kernel upstream, under /drivers/staging. The cx25821 driver is a new driver written this year for some very powerful PCIe chips, capable of up to 10 simultaneous video input/outputs. The driver needs several CodingStyle fixes, and has duplicated code for each input/output. I intend to add tm6000 driver there later this week, if time permits to port it to the new i2c interface. The policy to accept new drivers code at staging tree is less rigid than at /drivers/media: the kernel driver for an unsupported hardware shouldn't depend on any userspace library other than libv4l and dvb-apps and the code should compile fine with the latest kernel, and the developer(s) should be working on fixing it for upstream inclusion. Drivers with bugs, CodingStyle errors, deprecated API usage, etc can be accepted. Also, drivers there not maintained for some time can be removed. 2) /staging-specs - This contains the latest V4L and DVB API specs, in DocBook XML 4.1.2. This is the same DocBook version used in kernel. It basically contains an effort to finally merge the API's at kernel DocBook directory. Currently, this is _not_ the official API, and the document still needs review and cleanups. My intention is to add the first tree upstream, under drivers/staging for kernel 2.6.32. As those drivers are new, if we can get them on a good shape during 2.6.32 rc cycle, it could be possible to move them to drivers/media for 2.6.32. All depends on how they'll evolute. If time is enough and we have the DocBook tree in good shape on the next two weeks, I intend to add it also to 2.6.32. Feel free to contribute to both trees. Have Fun! 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
[PATCH] tda18271 add FM filter selction + minor fixes
This patch adds support for FM filter selection. The tda18271 has two rf
inputs RF_IN (45-864 MHz) and FM_IN (65-108 MHz). The code automatically
enables the antialiasing filter for radio reception and depending on the
FM input selected configures EB23 register.
Additional fixes:
- Fixed the temerature comensation, see revision history of TDA18271HD_4
spec.
- Minor cosmetic change in the tda18271_rf_band[]
- Fixed one value and removed a duplicate in tda18271_cid_target[]
Signed-off-by: henk.vergo...@gmail.com
diff -r 2b49813f8482 linux/drivers/media/common/tuners/tda18271-fe.c
--- a/linux/drivers/media/common/tuners/tda18271-fe.c Thu Sep 03 09:06:34
2009 -0300
+++ b/linux/drivers/media/common/tuners/tda18271-fe.c Mon Sep 14 01:45:49
2009 +0200
@@ -99,6 +99,22 @@
if (tda_fail(ret))
goto fail;
+ /* update FM filter selection */
+ if (map->std == 0) {
+ /* std == FM radio */
+ regs[R_EB23] |= 0x06; /* 1.5 Mhz cut-off freq */
+ } else if (map->fm_rfn) {
+ /* antenna FM_IN, std != FM radio */
+ regs[R_EB23] |= 0x04; /* set FORCELP */
+ regs[R_EB23] &= ~0x02; /* clear LP_FC */
+ } else {
+ /* antenna RF_IN, std != FM radio */
+ regs[R_EB23] &= ~0x06; /* clear FORCELP, LP_FC */
+ }
+ ret = tda18271_write_regs(fe, R_EB23, 1);
+ if (tda_fail(ret))
+ goto fail;
+
/* --- */
/* disable Power Level Indicator */
@@ -272,7 +288,7 @@
tda18271_lookup_map(fe, RF_CAL_DC_OVER_DT, &freq, &dc_over_dt);
/* calculate temperature compensation */
- rfcal_comp = dc_over_dt * (tm_current - priv->tm_rfcal);
+ rfcal_comp = dc_over_dt * (tm_current - priv->tm_rfcal) / 1000;
regs[R_EB14] = approx + rfcal_comp;
ret = tda18271_write_regs(fe, R_EB14, 1);
diff -r 2b49813f8482 linux/drivers/media/common/tuners/tda18271-maps.c
--- a/linux/drivers/media/common/tuners/tda18271-maps.c Thu Sep 03 09:06:34
2009 -0300
+++ b/linux/drivers/media/common/tuners/tda18271-maps.c Mon Sep 14 01:45:49
2009 +0200
@@ -229,8 +229,8 @@
static struct tda18271_map tda18271_rf_band[] = {
{ .rfmax = 47900, .val = 0x00 },
{ .rfmax = 61100, .val = 0x01 },
+ { .rfmax = 121200, .val = 0x02 },
/* { .rfmax = 152600, .val = 0x02 }, */
- { .rfmax = 121200, .val = 0x02 },
{ .rfmax = 164700, .val = 0x03 },
{ .rfmax = 203500, .val = 0x04 },
{ .rfmax = 457800, .val = 0x05 },
@@ -962,10 +962,10 @@
static struct tda18271_cid_target_map tda18271_cid_target[] = {
{ .rfmax = 46000, .target = 0x04, .limit = 1800 },
{ .rfmax = 52200, .target = 0x0a, .limit = 1500 },
- { .rfmax = 79100, .target = 0x01, .limit = 4000 },
+ { .rfmax = 70100, .target = 0x01, .limit = 4000 },
+/* { .rfmax = 79100, .target = 0x01, .limit = 4000 },*/
{ .rfmax = 136800, .target = 0x18, .limit = 4000 },
{ .rfmax = 156700, .target = 0x18, .limit = 4000 },
- { .rfmax = 156700, .target = 0x18, .limit = 4000 },
{ .rfmax = 186250, .target = 0x0a, .limit = 4000 },
{ .rfmax = 23, .target = 0x0a, .limit = 4000 },
{ .rfmax = 345000, .target = 0x18, .limit = 4000 },
Re: [PATCH] hdpvr: i2c fixups for fully functional IR support
On 09/13/2009 06:13 PM, Janne Grunau wrote: On Sun, Sep 13, 2009 at 05:04:16PM -0400, Jarod Wilson wrote: On Sep 13, 2009, at 1:23 PM, Brandon Jenkins wrote: I don't mind testing. Currently I am running ArchLinux 64-bit, kernel26-2.6.30.6-1. Please tell me where to build the driver from. Hrm... It *was* in Janne's hdpvr tree, but it seems to have gone missing... It's in http://hg.jannau.net/hdpvr. I just merged several weeks of v4l-dvb changes after the last commit. So it's not at the top of the log. Bah, so it is. I looked at the actual source files and somehow thought I didn't see the latest bits in there, but I just looked again, and you're of course right, everything's there... -- Jarod Wilson ja...@wilsonet.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: Problems with Pinnacle 310i (saa7134) and recent kernels
On Monday 14 September 2009 00:42:16 hermann pitton wrote: > Hi, > > Am Sonntag, den 13.09.2009, 12:02 + schrieb Avl Jawrowski: > > Hi, > > > > hermann pitton arcor.de> writes: > > > > > > > > I'm sorry that we have some mess on some of such devices, but currently > > > really nobody can help much further. > > > > > > Mike and Hauppauge don't have any schematics for LNA and external > > > antenna voltage switching for now, he assured it to me personally and we > > > must live with the back hacks for now and try to further work through > > > it. > > > > > > However, mplayer should work as well, but my last checkout is a little > > > out dated. > > > > > > It will go to Nico anyway, he is usually at the list here. > > > > > > If you can tell me on what you are, I might be able to confirm or not. > > > > Do you mean the exact card I have? I can do some photos if they can help. > > Unfortunately I don't have the original eeprom content. > > no, in this case I meant mplayer should work for you too. > You need to have DVB support enabled and a channels.conf file in > ~/.mplayer. > > We might collect pictures of the cards and remotes as well. > To identify those card with an additional LNA circuitry is likely not > easy hardware wise, since the tuner shielding is soldered with 16 pins, > many close to lines. Maybe we can identify those boards by the card > revision printed on them. Don't know how to auto detect them. > > > In the matter of the IR, the modules seems to be loaded: > > > > tda1004x 13048 1 > > saa7134_dvb20772 0 > > videobuf_dvb5644 1 saa7134_dvb > > ir_kbd_i2c 5500 0 > > tda827x 8880 2 > > tuner 16960 1 > > saa7134 138436 1 saa7134_dvb > > ir_common 41828 2 ir_kbd_i2c,saa7134 > > videobuf_dma_sg 9876 2 saa7134_dvb,saa7134 > > videobuf_core 13596 3 videobuf_dvb,saa7134,videobuf_dma_sg > > tveeprom 10488 1 saa7134 > > > > But I can't find anything in /proc/bus/input/devices. > > We might have more than the two supported remotes on such cards. > After all that would not make me wonder anymore and the windows driver > presents some more. Do you have that silver remote with colored buttons. > There must be a device at 0x47 detected to support it. > > You might have to load ir-kbd-i2c at first or reload saa7134-alsa and > saa7134-dvb, which includes saa7134. > > If OK, looks like this here. > > saa7133[2]: setting pci latency timer to 64 > saa7133[2]: found at :04:03.0, rev: 208, irq: 21, latency: 64, mmio: > 0xfebfe800 > saa7133[2]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,insmod > option] > saa7133[2]: board init: gpio is 600c000 > saa7133[2]: gpio: mode=0x000 in=0x600c000 out=0x000 [pre-init] > IRQ 21/saa7133[2]: IRQF_DISABLED is not guaranteed on shared IRQs > saa7133[2]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 > saa7133[2]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2c b0 22 ff ff > saa7133[2]: i2c eeprom 20: 01 2c 01 02 02 01 04 30 98 ff 00 a5 ff 21 00 c2 > saa7133[2]: i2c eeprom 30: 96 10 03 32 15 20 ff ff 0c 22 17 88 03 44 31 f9 > saa7133[2]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[2]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > input: i2c IR (Pinnacle PCTV) as /class/input/input7 > ir-kbd-i2c: i2c IR (Pinnacle PCTV) detected at i2c-3/3-0047/ir0 [saa7133[2]] > tuner 3-004b: chip found @ 0x96 (saa7133[2]) > tda829x 3-004b: setting tuner address to 61 > tda829x 3-004b: type set to tda8290+75a > saa7133[2]: gpio: mode=0x020 in=0x600e000 out=0x000 [Television] > saa7133[2]: gpio: mode=0x020 in=0x600e000 out=0x000 [Television] > saa7133[2]: gpio: mode=0x020 in=0x600c000 out=0x000 [Television] > saa7133[2]: registered device video2 [v4l2] > saa7133[2]: registered device vbi2 > saa7133[2]: registered device radio0 > 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 rev
