Re: linux-next: Tree for April 9
On Thu, 9 Apr 2009 16:33:05 +1000 Stephen Rothwell wrote: > I have created today's linux-next tree at > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git It has a link failure with i386 allmodconfig due to missing __divdi3. It's due to this statement in drivers/media/video/cx88/cx88-dsp.c's int_goertzel(): return (u32)(((s64)s_prev2*s_prev2 + (s64)s_prev*s_prev - (s64)coeff*s_prev2*s_prev/32768)/N/N); that gem will need to be converted to use div64() or similar, please. -- 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] White Balance control for digital camera
Hi, I think the answer for this issue is quite clear. We already have queryctrl and querymenu API to check supported CIDs. That means application or middleware which handles camera device should check first CIDs supported by the device they handle. I hope this could be the answer for your concern. Cheers, Nate On Sat, Apr 11, 2009 at 9:30 AM, Theodore Kilgore wrote: > > > On Sat, 11 Apr 2009, Dongsoo, Nathaniel Kim wrote: > >> On Sat, Apr 11, 2009 at 2:39 AM, Theodore Kilgore >> wrote: >>> >>> >>> On Fri, 10 Apr 2009, Dongsoo, Nathaniel Kim wrote: >>> Hello everyone, I'm posting this RFC one more time because it seems to everyone has been forgot this, and I'll be appreciated if any of you who is reading this mailing list give me comment. >>> >>> I don't know much about the topic, and I wish I did. >>> I've got a big question popping up handling white balance with V4L2_CID_WHITE_BALANCE_TEMPERATURE CID. Because in digital camera we generally control over user interface with pre-defined white balance name. I mean, user controls white balance with presets not with kelvin number. I'm very certain that TEMPERATURE CID is needed in many of video capture devices, but also 100% sure that white balance preset control is also necessary for digital cameras. How can we control white balance through preset name with existing V4L2 API? >>> >>> Let's broaden the question to include digital still cameras, which >>> present >>> similar problems. They present data related to this kind of thing, that >>> is >>> obvious. But are there any standard meanings to what is there? Do you >>> know >>> anything about that? Can you help? >>> >> >> Exactly right, but we need to see this on the top of the user space first. >> Because there could be several types of camera devices could be handled. >> I mean, the device that I'm intending to handle is based on I2C device >> and the "digital still camera" you issued is totally based on USB >> communication. >> That could be different in driver implementation point of view, but >> user in user space should be using in same manner. >> And I think I can help to coordinate how to handle them in user space >> with V4L2 API, but not so much with usb communication with digital >> still cameras.(but I really want to help indeed) >> Actually my expertise is totally based on mobile camera devices like >> camera phone. Even though they are "mobile" camera modules, they are >> very close to regular digital camera in performance and quality level >> now days. > > Well, I would say of the top of my head that to do things the same way is a > good idea, whenever possible. But that would appear to me, then, that > libgphoto2 and things related to v4l would have to do these things, which > would probably result in some code being incorporated in both places, in the > end. > >> >>> Two examples: >>> >>> The SQ905 and SQ905C cameras in stillcam mode use an allocation table, >>> which >>> presents on each line some data about the given image. In this line, byte >>> 0 >>> is a one-byte code for pixel dimensions and compression setting. Then >>> some >>> more bytes give the starting and ending locations of the photo in the >>> camera's memory (actually irrelevant and superfluous information, because >>> you can only ask for the photos in sequence, and with a command which has >>> nothing to do with its memory location at all). Then some more bytes >>> obviously have something to do with contrast, brightness, white balance, >>> color balance, and so on. But I have no more idea than the Man in the >>> Moon >>> how those bytes are supposed to be interpreted. The SQ905 gives no such >>> equivalent information while in streaming mode, and so there is nothing >>> at >>> all which could be done with the nonexistent information. But the SQ905C >>> does obviously give such information, in a few bytes in the header of >>> each >>> frame. >> >> As far as I know, SQ905 (is that actually cheez camera?) > > You know, I really do not know the answer to that. The relation between some > of these outfits is very confusing. But what I *think* I know is > > -- Standard & Quality Technology (S&Q, or SQ) claims to make > the chips, and then a lot of companies sell cameras with those chips. > > -- CHE-eZ appears to me to be one of the companies which produces cameras, > which appears to be an activity of, more or less, putting a plastic case and > a decal or stencil logo on the outside of a plastic case containing the > electronics which allegedly came from SQ. There are lots of companies that > do that, as I said. > > -- The usb.ids file seems to think that Vendor 0x2770 is some Japanese > company called NHL. I think that the usb.ids file is probably not correct > and the number belongs to SQ, which actually makes the chips and is not (for > example) a mail drop for some other company. But how could I actually know? > I don't. > > What is the real
Re: [RFC] White Balance control for digital camera
On Sat, 11 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hello again, I forgot to give you reference about the range of color temperature to handle white balance as preset. Here is the wikipedia reference, I wish I could find better one but by now it seems to be no problem. http://en.wikipedia.org/wiki/Color_temperature#Categorizing_different_lighting Cheers, Nate I will have a look. -- 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] White Balance control for digital camera
On Sat, 11 Apr 2009, Dongsoo, Nathaniel Kim wrote: On Sat, Apr 11, 2009 at 2:39 AM, Theodore Kilgore wrote: On Fri, 10 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hello everyone, I'm posting this RFC one more time because it seems to everyone has been forgot this, and I'll be appreciated if any of you who is reading this mailing list give me comment. I don't know much about the topic, and I wish I did. I've got a big question popping up handling white balance with V4L2_CID_WHITE_BALANCE_TEMPERATURE CID. Because in digital camera we generally control over user interface with pre-defined white balance name. I mean, user controls white balance with presets not with kelvin number. I'm very certain that TEMPERATURE CID is needed in many of video capture devices, but also 100% sure that white balance preset control is also necessary for digital cameras. How can we control white balance through preset name with existing V4L2 API? Let's broaden the question to include digital still cameras, which present similar problems. They present data related to this kind of thing, that is obvious. But are there any standard meanings to what is there? Do you know anything about that? Can you help? Exactly right, but we need to see this on the top of the user space first. Because there could be several types of camera devices could be handled. I mean, the device that I'm intending to handle is based on I2C device and the "digital still camera" you issued is totally based on USB communication. That could be different in driver implementation point of view, but user in user space should be using in same manner. And I think I can help to coordinate how to handle them in user space with V4L2 API, but not so much with usb communication with digital still cameras.(but I really want to help indeed) Actually my expertise is totally based on mobile camera devices like camera phone. Even though they are "mobile" camera modules, they are very close to regular digital camera in performance and quality level now days. Well, I would say of the top of my head that to do things the same way is a good idea, whenever possible. But that would appear to me, then, that libgphoto2 and things related to v4l would have to do these things, which would probably result in some code being incorporated in both places, in the end. Two examples: The SQ905 and SQ905C cameras in stillcam mode use an allocation table, which presents on each line some data about the given image. In this line, byte 0 is a one-byte code for pixel dimensions and compression setting. Then some more bytes give the starting and ending locations of the photo in the camera's memory (actually irrelevant and superfluous information, because you can only ask for the photos in sequence, and with a command which has nothing to do with its memory location at all). Then some more bytes obviously have something to do with contrast, brightness, white balance, color balance, and so on. But I have no more idea than the Man in the Moon how those bytes are supposed to be interpreted. The SQ905 gives no such equivalent information while in streaming mode, and so there is nothing at all which could be done with the nonexistent information. But the SQ905C does obviously give such information, in a few bytes in the header of each frame. As far as I know, SQ905 (is that actually cheez camera?) You know, I really do not know the answer to that. The relation between some of these outfits is very confusing. But what I *think* I know is -- Standard & Quality Technology (S&Q, or SQ) claims to make the chips, and then a lot of companies sell cameras with those chips. -- CHE-eZ appears to me to be one of the companies which produces cameras, which appears to be an activity of, more or less, putting a plastic case and a decal or stencil logo on the outside of a plastic case containing the electronics which allegedly came from SQ. There are lots of companies that do that, as I said. -- The usb.ids file seems to think that Vendor 0x2770 is some Japanese company called NHL. I think that the usb.ids file is probably not correct and the number belongs to SQ, which actually makes the chips and is not (for example) a mail drop for some other company. But how could I actually know? I don't. What is the real story? Perhaps you can enlighten _me_. .. ... is a regular digital camera not a mobile camera module, so in that case it could be handled in gspca and totally control through usb_control_msg. Well the issue here with the supported SQ cameras is to be able to process better the data that came out of the camera. There is nothing which can be set up through usb_control_msg. These cameras do not have any control settings for changing what goes on inside the camera. The SQ905 cameras, as I said, do not even provide any data other than direct image data, whle streaming (though they do in stillcam mode). So one would not be able to do anything at all. The SQ905
Re: ir-kbd-i2c Compile Warnings
On Fri, Apr 10, 2009 at 10:10 AM, Brandon Jenkins wrote: > Hello all, > > Fresh clone of V4L this morning running on a fully patched ArchLinux > 64-bit system: > > /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.o > /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c: In function 'ir_attach': > /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:429: warning: > 'i2c_attach_client' is deprecated (declared at > include/linux/i2c.h:434) > /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:468: warning: > 'i2c_detach_client' is deprecated (declared at > include/linux/i2c.h:435) > /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c: In function 'ir_detach': > /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:484: warning: > 'i2c_detach_client' is deprecated (declared at > include/linux/i2c.h:435) > > Brandon > > uname -a > Linux sagetv-server 2.6.29-ARCH #1 SMP PREEMPT Wed Apr 8 12:39:28 CEST > 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel > GNU/Linux > Rolling back to kernel: Linux sagetv-server 2.6.28-ARCH #1 SMP PREEMPT Tue Mar 17 07:22:53 CET 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux Does not produce the same warnings. 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
Re: [RFC] White Balance control for digital camera
Hello again, I forgot to give you reference about the range of color temperature to handle white balance as preset. Here is the wikipedia reference, I wish I could find better one but by now it seems to be no problem. http://en.wikipedia.org/wiki/Color_temperature#Categorizing_different_lighting Cheers, Nate On Sat, Apr 11, 2009 at 5:44 AM, Dongsoo, Nathaniel Kim wrote: > On Sat, Apr 11, 2009 at 2:39 AM, Theodore Kilgore > wrote: >> >> >> On Fri, 10 Apr 2009, Dongsoo, Nathaniel Kim wrote: >> >>> Hello everyone, >>> >>> I'm posting this RFC one more time because it seems to everyone has >>> been forgot this, and I'll be appreciated if any of you who is reading >>> this mailing list give me comment. >> >> I don't know much about the topic, and I wish I did. >> >>> I've got a big question popping up handling white balance with >>> V4L2_CID_WHITE_BALANCE_TEMPERATURE CID. >>> >>> Because in digital camera we generally control over user interface >>> with pre-defined white balance name. I mean, user controls white >>> balance with presets not with kelvin number. >>> I'm very certain that TEMPERATURE CID is needed in many of video >>> capture devices, but also 100% sure that white balance preset control >>> is also necessary for digital cameras. >>> How can we control white balance through preset name with existing V4L2 >>> API? >> >> Let's broaden the question to include digital still cameras, which present >> similar problems. They present data related to this kind of thing, that is >> obvious. But are there any standard meanings to what is there? Do you know >> anything about that? Can you help? >> > > Exactly right, but we need to see this on the top of the user space first. > Because there could be several types of camera devices could be handled. > I mean, the device that I'm intending to handle is based on I2C device > and the "digital still camera" you issued is totally based on USB > communication. > That could be different in driver implementation point of view, but > user in user space should be using in same manner. > And I think I can help to coordinate how to handle them in user space > with V4L2 API, but not so much with usb communication with digital > still cameras.(but I really want to help indeed) > Actually my expertise is totally based on mobile camera devices like > camera phone. Even though they are "mobile" camera modules, they are > very close to regular digital camera in performance and quality level > now days. > >> Two examples: >> >> The SQ905 and SQ905C cameras in stillcam mode use an allocation table, which >> presents on each line some data about the given image. In this line, byte 0 >> is a one-byte code for pixel dimensions and compression setting. Then some >> more bytes give the starting and ending locations of the photo in the >> camera's memory (actually irrelevant and superfluous information, because >> you can only ask for the photos in sequence, and with a command which has >> nothing to do with its memory location at all). Then some more bytes >> obviously have something to do with contrast, brightness, white balance, >> color balance, and so on. But I have no more idea than the Man in the Moon >> how those bytes are supposed to be interpreted. The SQ905 gives no such >> equivalent information while in streaming mode, and so there is nothing at >> all which could be done with the nonexistent information. But the SQ905C >> does obviously give such information, in a few bytes in the header of each >> frame. > > As far as I know, SQ905 (is that actually cheez camera?) is a regular > digital camera not a mobile camera module, so in that case it could be > handled in gspca and totally control through usb_control_msg. > And with my experience, I think I can help you if I have any kind of > datasheet or user manual for that. > But even if I don't have datasheet and don't know which message field > means what I'm intending to do, I think it could be possible to make > it compatible with the parameters I'm trying to make in v4l2 control. > >> >> The MR97310A cameras give similar information in the header of the photo >> itself (and in this case the camera does the same thing in webcam mode, >> too). Again, I have no idea either what these mysterious bytes are supposed >> to mean, and how to use them constructively. >> >> I could mention several other examples, too, but these will do for a start. > > OK I've got what you mean. Can I have any information like user manual > or datasheet for those SQ and MR devices? > If we make a white balance preset api in v4l2, then we should have to > implement that functionality in every single camera drivers in v4l2 if > those devices are supporting for white balance presets. > > I want to make this clear that if we have white balance preset api in > v4l2, then we can handle every camera device's white balance more user > friendly. > > Thank you for your opinion by the way. > > Nate > >> >> Are there any agreed-upon standards about this ki
Re: [PATCH/RFC] soc-camera: Convert to a platform driver
Guennadi Liakhovetski writes: > On Thu, 9 Apr 2009, Robert Jarzmik wrote: > >> Guennadi Liakhovetski writes: >> > > Did you enable DEBUG? Looks like one of dev_dbg() had a (yet) invalid > device pointer. I'll have to try that too. No, don't think so. I think that calling mclk_get_divisor() too early, when pcdev->soc_host.dev is not set, is the issue here (dev_warn is mclk_get_divisor()). And for the same price, I'll give you another stack :) I'll leave that one up to you, as I'm not really confortable with that type of sequence : if (!icd->dev.parent || to_soc_camera_host(icd->dev.parent)->nr != icd->iface) [ 183.230769] [] (mt9m111_probe+0xcc/0x298 [mt9m111]) from [] (i2c_device_probe+0x8c/0x9c) [ 183.238108] [] (i2c_device_probe+0x8c/0x9c) from [] (driver_probe_device+0xa4/0x1a8) [ 183.245424] [] (driver_probe_device+0xa4/0x1a8) from [] (bus_for_each_drv+0x60/0x8c) [ 183.252617] [] (bus_for_each_drv+0x60/0x8c) from [] (device_attach+0x5c/0x74) [ 183.259792] [] (device_attach+0x5c/0x74) from [] (bus_attach_device+0x44/0x78) [ 183.266944] [] (bus_attach_device+0x44/0x78) from [] (device_add+0x394/0x5ac) [ 183.274084] [] (device_add+0x394/0x5ac) from [] (i2c_attach_client+0x80/0x148) [ 183.281228] [] (i2c_attach_client+0x80/0x148) from [] (i2c_new_device+0x6c/0x90) [ 183.288340] [] (i2c_new_device+0x6c/0x90) from [] (soc_camera_probe+0x4c/0x188 [soc_camera]) [ 183.295622] [] (soc_camera_probe+0x4c/0x188 [soc_camera]) from [] (driver_probe_device+0xa4/0x1a8) [ 183.302774] [] (driver_probe_device+0xa4/0x1a8) from [] (bus_for_each_drv+0x60/0x8c) [ 183.309863] [] (bus_for_each_drv+0x60/0x8c) from [] (device_attach+0x5c/0x74) [ 183.316902] [] (device_attach+0x5c/0x74) from [] (bus_attach_device+0x44/0x78) [ 183.323927] [] (bus_attach_device+0x44/0x78) from [] (device_add+0x394/0x5ac) [ 183.330947] [] (device_add+0x394/0x5ac) from [] (soc_camera_host_register+0x1a4/0x1ec [soc_camera]) [ 183.337997] [] (soc_camera_host_register+0x1a4/0x1ec [soc_camera]) from [] (pxa_camera_probe+0x2e4/0x42c [pxa_camera]) [ 183.345142] [] (pxa_camera_probe+0x2e4/0x42c [pxa_camera]) from [] (platform_drv_probe+0x1c/0x24) [ 183.352164] [] (platform_drv_probe+0x1c/0x24) from [] (driver_probe_device+0xa4/0x1a8) [ 183.359158] [] (driver_probe_device+0xa4/0x1a8) from [] (__driver_attach+0x84/0x88) [ 183.366088] [] (__driver_attach+0x84/0x88) from [] (bus_for_each_dev+0x54/0x80) [ 183.372983] [] (bus_for_each_dev+0x54/0x80) from [] (bus_add_driver+0xa4/0x218) [ 183.379873] [] (bus_add_driver+0xa4/0x218) from [] (driver_register+0x58/0x138) [ 183.386766] [] (driver_register+0x58/0x138) from [] (do_one_initcall+0x2c/0x180) [ 183.393705] [] (do_one_initcall+0x2c/0x180) from [] (sys_init_module+0x88/0x198) [ 183.400650] [] (sys_init_module+0x88/0x198) from [] (ret_fast_syscall+0x0/0x2c) [ 183.407554] Code: e3a03000 e1c53cb8 e2426020 e351 (e5968068) [ 183.411614] ---[ end trace b5c2161a92c2cf9d ]--- Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] SkyStar HD2 (TwinHan VP-1041/Mantis) S2API support
There is a new mantis tree being uploaded at: http://jusst.de/hg/mantis-v4l Please try this tree. The upload should finish within 2 hours and is using DVB api 5 (aka s2api). Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] White Balance control for digital camera
On Sat, Apr 11, 2009 at 2:39 AM, Theodore Kilgore wrote: > > > On Fri, 10 Apr 2009, Dongsoo, Nathaniel Kim wrote: > >> Hello everyone, >> >> I'm posting this RFC one more time because it seems to everyone has >> been forgot this, and I'll be appreciated if any of you who is reading >> this mailing list give me comment. > > I don't know much about the topic, and I wish I did. > >> I've got a big question popping up handling white balance with >> V4L2_CID_WHITE_BALANCE_TEMPERATURE CID. >> >> Because in digital camera we generally control over user interface >> with pre-defined white balance name. I mean, user controls white >> balance with presets not with kelvin number. >> I'm very certain that TEMPERATURE CID is needed in many of video >> capture devices, but also 100% sure that white balance preset control >> is also necessary for digital cameras. >> How can we control white balance through preset name with existing V4L2 >> API? > > Let's broaden the question to include digital still cameras, which present > similar problems. They present data related to this kind of thing, that is > obvious. But are there any standard meanings to what is there? Do you know > anything about that? Can you help? > Exactly right, but we need to see this on the top of the user space first. Because there could be several types of camera devices could be handled. I mean, the device that I'm intending to handle is based on I2C device and the "digital still camera" you issued is totally based on USB communication. That could be different in driver implementation point of view, but user in user space should be using in same manner. And I think I can help to coordinate how to handle them in user space with V4L2 API, but not so much with usb communication with digital still cameras.(but I really want to help indeed) Actually my expertise is totally based on mobile camera devices like camera phone. Even though they are "mobile" camera modules, they are very close to regular digital camera in performance and quality level now days. > Two examples: > > The SQ905 and SQ905C cameras in stillcam mode use an allocation table, which > presents on each line some data about the given image. In this line, byte 0 > is a one-byte code for pixel dimensions and compression setting. Then some > more bytes give the starting and ending locations of the photo in the > camera's memory (actually irrelevant and superfluous information, because > you can only ask for the photos in sequence, and with a command which has > nothing to do with its memory location at all). Then some more bytes > obviously have something to do with contrast, brightness, white balance, > color balance, and so on. But I have no more idea than the Man in the Moon > how those bytes are supposed to be interpreted. The SQ905 gives no such > equivalent information while in streaming mode, and so there is nothing at > all which could be done with the nonexistent information. But the SQ905C > does obviously give such information, in a few bytes in the header of each > frame. As far as I know, SQ905 (is that actually cheez camera?) is a regular digital camera not a mobile camera module, so in that case it could be handled in gspca and totally control through usb_control_msg. And with my experience, I think I can help you if I have any kind of datasheet or user manual for that. But even if I don't have datasheet and don't know which message field means what I'm intending to do, I think it could be possible to make it compatible with the parameters I'm trying to make in v4l2 control. > > The MR97310A cameras give similar information in the header of the photo > itself (and in this case the camera does the same thing in webcam mode, > too). Again, I have no idea either what these mysterious bytes are supposed > to mean, and how to use them constructively. > > I could mention several other examples, too, but these will do for a start. OK I've got what you mean. Can I have any information like user manual or datasheet for those SQ and MR devices? If we make a white balance preset api in v4l2, then we should have to implement that functionality in every single camera drivers in v4l2 if those devices are supporting for white balance presets. I want to make this clear that if we have white balance preset api in v4l2, then we can handle every camera device's white balance more user friendly. Thank you for your opinion by the way. Nate > > Are there any agreed-upon standards about this kind of thing, in the camera > industry? Is there any source of information about it? > > Theodore Kilgore > -- 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
Re: SkyStar HD2 (TwinHan VP-1041) S2API/multiproto issues
2009/4/10 Markus Rechberger : > On Fri, Apr 10, 2009 at 1:30 PM, Dave Lister wrote: >> ... >> Drivers tried: http://jusst.de/hg/multiproto, >> http://jusst.de/hg/mantis (couldn't make it compile) > > hmm this seems to work fine with linux 2.6.27 maybe try to downgrade > your kernel? > Thank you for the tip! I presume you mean the http://jusst.de/hg/mantis driver. When I was trying mantis tree with kernels 2.6.26 & 2.6.29 yesterday, I got this compilation error in both cases (mentioning for archival purposes, to help others): In file included from /n/data/src/mantis/v4l/tuner-xc2028.h:10, from /n/data/src/mantis/v4l/tuner-xc2028.c:21: ./v4l/dvb_frontend.h:52: error: field 'fe_params' has incomplete type ./v4l/dvb_frontend.h:297: warning: 'struct dvbfe_info' declared inside parameter list ./v4l/dvb_frontend.h:299: warning: 'enum dvbfe_delsys' declared inside parameter list ./v4l/dvb_frontend.h:316: error: field 'fe_events' has incomplete type ./v4l/dvb_frontend.h:317: error: field 'fe_params' has incomplete type ./v4l/dvb_frontend.h:354: warning: 'enum dvbfe_fec' declared inside parameter list ./v4l/dvb_frontend.h:354: warning: 'enum dvbfe_modulation' declared inside parameter list make[3]: *** [./v4l/tuner-xc2028.o] Error 1 Now, trying again (and harder) as you suggested, I realized my kernel's V4L headers (linux/dvb/frontend.h, etc) were taking precedence over mantis tree. I "fixed" it (just moved conflicting headers), but still ended up with the same fatal error as yesterday - struct net_device doesn't have a member called "priv". Turns out this incompatibility was introduced somewhere between 2.6.28-29. Debian 2.6.26 kernel worked fine this time and the driver compiled! Thanks to your heads up, I can finally scan and zap channels! :) There are still some issues, though. Perhaps you or somebody else will be able to help me. I tried several versions of dvb-apps/utils (deb, http://linuxtv.org/hg/dvb-apps, s2-liplianin, http://jusst.de/manu/scan.tar.bz2) and the only one working is the Debian package. This means, however, that I cannot use DVB-S2. To make it short: 1) Where do I get working S2-enabled dvb-apps for the mantis tree? 2) Zapping and scanning is _extremely_ slow - szap takes about 30 seconds to lock on any channel. Is it normal? 3) DiSEqC is not working with the standard packaged dvb-apps (-s 0, -s 1). Is DiSEqC supported at all? 4) I'm using trunk MythTV and compiled it yesterday against liplianin-s2. Do I need any patches (b/c of mantis driver) or will clean recompilation work (considering S2, etc)? I'll welcome any suggestions that might point me in the right direction. Thank you, -- David Lister -- 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: Kernel 2.6.29 breaks DVB-T ASUSTeK Tiger LNA Hybrid Capture Device
Hi, Am Donnerstag, den 09.04.2009, 02:05 +0100 schrieb Thomas Horsten: > Hi Hermann, > > 2009/4/8 hermann pitton : > > > does it make any difference too with the current mercurial v4l-dvb ? > > > > I did not look any further, since some tones coming currently from above > > I don't like, more those from Linus after having 800 plus patches. > > After installing the mercurial drivers and rebooting the symptoms are > exactly the same. Another tuner card in the same machine (a Hauppauge > Nova-T 500 Dual DVB-T) works fine. > > If you have any ideas I am willing to experiment to get this to work > again. If I have some time over Easter I might try git-dissecting the > changes to find the patch that introduced the behaviour but since it > is running on quite a big server the turnaround time to reboot and try > new modules is about 30 minutes :( > scrolled at least over some saa7134 related diffs just, thousands of lines, but no exact catch yet. It seems the i2c gate control of the tda8290 at 0x96 is broken in DVB-T mode open/close related. Correct behavior with current mercurial tuning the tuner at 0xc0. saa7133[0]: i2c xfer: < 10 06 [fd quirk] < 11 =af > saa7133[0]: i2c xfer: < 10 06 [fd quirk] < 11 =af > saa7133[0]: i2c xfer: < 10 06 [fd quirk] < 11 =af > saa7133[0]: i2c xfer: < 10 01 [fd quirk] < 11 =91 > saa7133[0]: i2c xfer: < 10 01 91 > saa7133[0]: i2c xfer: < 10 02 [fd quirk] < 11 =1c > saa7133[0]: i2c xfer: < 10 02 1c > saa7133[0]: i2c xfer: < 10 03 [fd quirk] < 11 =00 > saa7133[0]: i2c xfer: < 10 03 00 > saa7133[0]: i2c xfer: < 10 43 [fd quirk] < 11 =03 > saa7133[0]: i2c xfer: < 10 43 03 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 00 2e 70 00 16 14 4b 1c 06 24 00 > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 90 ff 60 00 59 > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 a0 40 > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c1 =09 =a8 > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 c0 99 > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 60 3c > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 30 11 > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 c0 39 > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 50 4f > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 10 01 [fd quirk] < 11 =91 > saa7133[0]: i2c xfer: < 10 01 91 > saa7133[0]: i2c xfer: < 10 02 [fd quirk] < 11 =1c > saa7133[0]: i2c xfer: < 10 02 1c > saa7133[0]: i2c xfer: < 10 02 [fd quirk] < 11 =1c > saa7133[0]: i2c xfer: < 10 02 1c > saa7133[0]: i2c xfer: < 10 03 [fd quirk] < 11 =00 > saa7133[0]: i2c xfer: < 10 03 00 > saa7133[0]: i2c xfer: < 10 31 54 > saa7133[0]: i2c xfer: < 10 32 03 > On the broken 2.6.29.1 it looks like that. saa7133[0]: i2c xfer: < 10 22 [fd quirk] < 11 =ff > saa7133[0]: i2c xfer: < 10 21 [fd quirk] < 11 =ff > saa7133[0]: i2c xfer: < 10 20 [fd quirk] < 11 =ff > saa7133[0]: i2c xfer: < 10 01 [fd quirk] < 11 =91 > saa7133[0]: i2c xfer: < 10 01 91 > saa7133[0]: i2c xfer: < 10 02 [fd quirk] < 11 =1c > saa7133[0]: i2c xfer: < 10 02 1c > saa7133[0]: i2c xfer: < 10 03 [fd quirk] < 11 =00 > saa7133[0]: i2c xfer: < 10 03 00 > saa7133[0]: i2c xfer: < 10 43 [fd quirk] < 11 =03 > saa7133[0]: i2c xfer: < 10 43 03 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 00 32 c0 00 16 5a 5b 1c 06 24 00 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 90 ff 60 00 59 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 a0 40 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c1 =09 =a8 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 c0 99 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 60 3c > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 30 10 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 c0 39 > saa7133[0]: i2c xfer: < 96 21 c0 > saa7133[0]: i2c xfer: < c0 50 5f > saa7133[0]: i2c xfer: < 96 21 80 > saa7133[0]: i2c xfer: < 10 01 [fd quirk] < 11 =91 > saa7133[0]: i2c xfer: < 10 01 91 > saa7133[0]: i2c xfer: < 10 02 [fd quirk] < 11 =1c > saa7133[0]: i2c xfer: < 10 02 1c > saa7133[0]: i2c xfer: < 10 02 [fd quirk] < 11 =1c > saa7133[0]: i2c xfer: < 10 02 1c > saa7133[0]: i2c xfer: < 10 03 [fd quirk] < 11 =00 > saa7133[0]: i2c xfer: < 10 03 00 > saa7133[0]: i2c xfer: < 10 31 60 > saa7133[0]: i2c xfer: < 10 32 02 > saa7133[0]: i2c xfer: < 10 33 aa > saa7133[0]: i2c xfer: < 10 34 aa > saa7133[0]: i2c xfer: < 10 35 ab > saa7133[0]: i2c xfer: < 10 4d 0c > saa7133[0]: i2c xfer: < 10 4e 00 > saa7133[0]: i2c xfer: < 10 16 [fd quirk] < 11 =a8 > saa7133[0]: i2c xfer: < 10 16 a8 >
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
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:Fri Apr 10 19:00:06 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11445:dba0b6fae413 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc1-armv5: ERRORS linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-rc1-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-rc1-i686: ERRORS 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-rc1-m32r: ERRORS linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29.1-mips: OK linux-2.6.30-rc1-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-rc1-x86_64: ERRORS fw/apps: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc1): OK linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: [RFC] White Balance control for digital camera
On Fri, 10 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hello everyone, I'm posting this RFC one more time because it seems to everyone has been forgot this, and I'll be appreciated if any of you who is reading this mailing list give me comment. I don't know much about the topic, and I wish I did. I've got a big question popping up handling white balance with V4L2_CID_WHITE_BALANCE_TEMPERATURE CID. Because in digital camera we generally control over user interface with pre-defined white balance name. I mean, user controls white balance with presets not with kelvin number. I'm very certain that TEMPERATURE CID is needed in many of video capture devices, but also 100% sure that white balance preset control is also necessary for digital cameras. How can we control white balance through preset name with existing V4L2 API? Let's broaden the question to include digital still cameras, which present similar problems. They present data related to this kind of thing, that is obvious. But are there any standard meanings to what is there? Do you know anything about that? Can you help? Two examples: The SQ905 and SQ905C cameras in stillcam mode use an allocation table, which presents on each line some data about the given image. In this line, byte 0 is a one-byte code for pixel dimensions and compression setting. Then some more bytes give the starting and ending locations of the photo in the camera's memory (actually irrelevant and superfluous information, because you can only ask for the photos in sequence, and with a command which has nothing to do with its memory location at all). Then some more bytes obviously have something to do with contrast, brightness, white balance, color balance, and so on. But I have no more idea than the Man in the Moon how those bytes are supposed to be interpreted. The SQ905 gives no such equivalent information while in streaming mode, and so there is nothing at all which could be done with the nonexistent information. But the SQ905C does obviously give such information, in a few bytes in the header of each frame. The MR97310A cameras give similar information in the header of the photo itself (and in this case the camera does the same thing in webcam mode, too). Again, I have no idea either what these mysterious bytes are supposed to mean, and how to use them constructively. I could mention several other examples, too, but these will do for a start. Are there any agreed-upon standards about this kind of thing, in the camera industry? Is there any source of information about it? Theodore Kilgore -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SkyStar HD2 (TwinHan VP-1041/Mantis) S2API support
On Fri, Apr 10, 2009 at 1:30 PM, Dave Lister wrote: > Hello all, > > I'd like to ask for your help. After weeks of research and > deliberation I bought two SkyStar HD2 cards (quite a lot money for > me). It seemed to be working for everybody, BUT I have already spent > two days reading mailing lists, downloading repositories, compiling > drivers, apps, kernels and bending code to make it compile. Please, > does anybody know how to help me? > > In short the driver doesn't seem to communicate with the card at all. > It's unable to send DiSEqC commands (not necessary in my case), unable > to tune the tuner, unable to report any signal strength info etc. I > have a dark sense of foreboding about this, because as things stand > now, it seems I'll have to recoup my losses (can't return these cards) > and buy different ones, possibly more expensive. Just these two cost > me half my month's salary. I was so damn sure they'll work - from all > the reports and success stories on the web, even LinuxTV said so. If > you knew my wife... I mean this is going to be a disaster. :( > > > Drivers tried: http://jusst.de/hg/multiproto, > http://jusst.de/hg/mantis (couldn't make it compile) hmm this seems to work fine with linux 2.6.27 maybe try to downgrade your kernel? Markus > Driver used: http://mercurial.intuxication.org/hg/s2-liplianin > Kernels tried w/driver: Debian 2.6.29; Debian 2.6.26; vanilla 2.6.29 > DVB apps/utils: 1.1.1+rev1207-4 > S2API DVB apps/utils: http://mercurial.intuxication.org/hg/{szap-s2,scan-s2} > > lspci -vv: > 07:01.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV > PCI Bridge Controller [Ver 1.0] (rev 01) > Subsystem: Device 1ae4:0003 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (2000ns min, 63750ns max) > Interrupt: pin A routed to IRQ 19 > Region 0: Memory at ec20 (32-bit, prefetchable) [size=4K] > Kernel driver in use: Mantis > Kernel modules: mantis > > Boot-up dmesg: > [ 6.704959] Mantis :07:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 > [ 6.705100] irq: 19, latency: 32 > [ 6.705101] memory: 0xec20, mmio: 0xf8286000 > [ 6.705183] found a VP-1041 PCI DSS/DVB-S/DVB-S2 device on (07:01.0), > [ 6.705228] Mantis Rev 1 [1ae4:0003], irq: 19, latency: 32 > [ 6.705261] memory: 0xec20, mmio: 0xf8286000 > [ 6.708020] MAC Address=[00:08:c9:e0:40:6a] > [ 6.708075] mantis_alloc_buffers (0): DMA=0x35d4 cpu=0xf5d4 > size=65536 > [ 6.708128] mantis_alloc_buffers (0): RISC=0x36327000 > cpu=0xf6327000 size=1000 > [ 6.708179] DVB: registering new adapter (Mantis dvb adapter) > [ 7.253355] stb0899_attach: Attaching STB0899 > [ 7.253397] mantis_frontend_init (0): found STB0899 DVB-S/DVB-S2 > frontend @0x68 > [ 7.253449] stb6100_attach: Attaching STB6100 > [ 7.253836] LNBx2x attached on addr=8DVB: registering adapter 0 > frontend 0 (STB0899 Multistandard)... > [ 7.253938] mantis_ca_init (0): Registering EN50221 device > [ 7.254033] mantis_ca_init (0): Registered EN50221 device > [ 7.254096] mantis_hif_init (0): Adapter(0) Initializing Mantis > Host Interface > > > Sat cable has 98% signal, Astra 19.2E, working in a TV/STB sitting > right next to the PC. I reconnect the cable from the TV into SkyStar > and try tuning: > > birko:~# scan-s2 -v /usr/share/dvb/dvb-s/Astra-19.2E > API major 5, minor 0 > ERROR: Cannot open rotor configuration file 'rotor.conf'. > scanning /usr/share/dvb/dvb-s/Astra-19.2E > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > initial transponder DVB-S 12551500 V 2200 5/6 AUTO AUTO > initial transponder DVB-S2 12551500 V 2200 5/6 AUTO AUTO > --> Using DVB-S tune to: 12551:vC56S0:S0.0W:22000: > DiSEqC: uncommitted switch pos 0 > DiSEqC: switch pos 0, 13V, hiband (index 2) > DVB-S IF freq is 1951500 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 > WARNING: >>> tuning failed!!! > --> Using DVB-S2 tune to: 12551:vC56S1:S0.0W:22000: > DiSEqC: uncommitted switch pos 0 > DiSEqC: switch pos 0, 13V, hiband (index 2) > DVB-S IF freq is 1951500 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 > WARNING: >>> tuning failed!!! > ERROR: initial tuning failed > dumping lists (0 services) > Done. > > Meanwhile, this is written to dmesg (repeating): > [43395.935293] stb6100_
ir-kbd-i2c Compile Warnings
Hello all, Fresh clone of V4L this morning running on a fully patched ArchLinux 64-bit system: /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.o /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c: In function 'ir_attach': /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:429: warning: 'i2c_attach_client' is deprecated (declared at include/linux/i2c.h:434) /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:468: warning: 'i2c_detach_client' is deprecated (declared at include/linux/i2c.h:435) /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c: In function 'ir_detach': /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:484: warning: 'i2c_detach_client' is deprecated (declared at include/linux/i2c.h:435) Brandon uname -a Linux sagetv-server 2.6.29-ARCH #1 SMP PREEMPT Wed Apr 8 12:39:28 CEST 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~anttip/af9015/
Hei Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9015: add new dvb_usb_device_properties entry for upcoming USB IDs af9015: support for AverMedia AVerTV Volar GPS 805 (A805) af9015: support for Conceptronic USB2.0 DVB-T CTVDIGRCU V3.0 Patch series adds support for two new devices. I want patches to the next release candidate of the Kernel 2.6.30 if possible. I didn't find any file from Kernel /Documentation/ which describes what kind of changes are allowed during RC phase, but I have feeling that adding new device IDs is allowed. How about remote tables for new devices? regards Antti -- http://palosaari.fi/ -- 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 v2 4/4] Add support to libv4l to use orientation from VIDIOC_ENUMINPUT
Thanks, I've applied this to my tree, it will be part of the next libv4l release. Regards, Hans On 03/30/2009 12:28 AM, Adam Baker wrote: Add check to libv4l of the sensor orientation as reported by VIDIOC_ENUMINPUT Signed-off-by: Adam Baker --- diff -r a647c2dfa989 v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.c --- a/v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.cTue Jan 20 11:25:54 2009 +0100 +++ b/v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.cSun Mar 29 22:59:56 2009 +0100 @@ -29,6 +29,11 @@ #define MIN(a,b) (((a)<(b))?(a):(b)) #define ARRAY_SIZE(x) ((int)sizeof(x)/(int)sizeof((x)[0])) +/* Workaround this potentially being missing from videodev2.h */ +#ifndef V4L2_IN_ST_VFLIP +#define V4L2_IN_ST_VFLIP 0x0020 /* Output is flipped vertically */ +#endif + /* Note for proper functioning of v4lconvert_enum_fmt the first entries in supported_src_pixfmts must match with the entries in supported_dst_pixfmts */ #define SUPPORTED_DST_PIXFMTS \ @@ -134,6 +139,7 @@ int i, j; struct v4lconvert_data *data = calloc(1, sizeof(struct v4lconvert_data)); struct v4l2_capability cap; + struct v4l2_input input; if (!data) return NULL; @@ -161,6 +167,13 @@ /* Check if this cam has any special flags */ data->flags = v4lconvert_get_flags(data->fd); + if ((syscall(SYS_ioctl, fd, VIDIOC_G_INPUT,&input.index) == 0)&& + (syscall(SYS_ioctl, fd, VIDIOC_ENUMINPUT,&input) == 0)) { +/* Don't yet support independent HFLIP and VFLIP so getting + * image the right way up is highest priority. */ +if (input.status& V4L2_IN_ST_VFLIP) + data->flags |= V4LCONVERT_ROTATE_180; + } if (syscall(SYS_ioctl, fd, VIDIOC_QUERYCAP,&cap) == 0) { if (!strcmp((char *)cap.driver, "uvcvideo")) data->flags |= V4LCONVERT_IS_UVC; -- 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
SkyStar HD2 (TwinHan VP-1041/Mantis) S2API support
Hello all, I'd like to ask for your help. After weeks of research and deliberation I bought two SkyStar HD2 cards (quite a lot money for me). It seemed to be working for everybody, BUT I have already spent two days reading mailing lists, downloading repositories, compiling drivers, apps, kernels and bending code to make it compile. Please, does anybody know how to help me? In short the driver doesn't seem to communicate with the card at all. It's unable to send DiSEqC commands (not necessary in my case), unable to tune the tuner, unable to report any signal strength info etc. I have a dark sense of foreboding about this, because as things stand now, it seems I'll have to recoup my losses (can't return these cards) and buy different ones, possibly more expensive. Just these two cost me half my month's salary. I was so damn sure they'll work - from all the reports and success stories on the web, even LinuxTV said so. If you knew my wife... I mean this is going to be a disaster. :( Drivers tried: http://jusst.de/hg/multiproto, http://jusst.de/hg/mantis (couldn't make it compile) Driver used: http://mercurial.intuxication.org/hg/s2-liplianin Kernels tried w/driver: Debian 2.6.29; Debian 2.6.26; vanilla 2.6.29 DVB apps/utils: 1.1.1+rev1207-4 S2API DVB apps/utils: http://mercurial.intuxication.org/hg/{szap-s2,scan-s2} lspci -vv: 07:01.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01) Subsystem: Device 1ae4:0003 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- GSI 19 (level, low) -> IRQ 19 [6.705100] irq: 19, latency: 32 [6.705101] memory: 0xec20, mmio: 0xf8286000 [6.705183] found a VP-1041 PCI DSS/DVB-S/DVB-S2 device on (07:01.0), [6.705228] Mantis Rev 1 [1ae4:0003], irq: 19, latency: 32 [6.705261] memory: 0xec20, mmio: 0xf8286000 [6.708020] MAC Address=[00:08:c9:e0:40:6a] [6.708075] mantis_alloc_buffers (0): DMA=0x35d4 cpu=0xf5d4 size=65536 [6.708128] mantis_alloc_buffers (0): RISC=0x36327000 cpu=0xf6327000 size=1000 [6.708179] DVB: registering new adapter (Mantis dvb adapter) [7.253355] stb0899_attach: Attaching STB0899 [7.253397] mantis_frontend_init (0): found STB0899 DVB-S/DVB-S2 frontend @0x68 [7.253449] stb6100_attach: Attaching STB6100 [7.253836] LNBx2x attached on addr=8DVB: registering adapter 0 frontend 0 (STB0899 Multistandard)... [7.253938] mantis_ca_init (0): Registering EN50221 device [7.254033] mantis_ca_init (0): Registered EN50221 device [7.254096] mantis_hif_init (0): Adapter(0) Initializing Mantis Host Interface Sat cable has 98% signal, Astra 19.2E, working in a TV/STB sitting right next to the PC. I reconnect the cable from the TV into SkyStar and try tuning: birko:~# scan-s2 -v /usr/share/dvb/dvb-s/Astra-19.2E API major 5, minor 0 ERROR: Cannot open rotor configuration file 'rotor.conf'. scanning /usr/share/dvb/dvb-s/Astra-19.2E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder DVB-S 12551500 V 2200 5/6 AUTO AUTO initial transponder DVB-S2 12551500 V 2200 5/6 AUTO AUTO --> Using DVB-S >>> tune to: 12551:vC56S0:S0.0W:22000: DiSEqC: uncommitted switch pos 0 DiSEqC: switch pos 0, 13V, hiband (index 2) DVB-S IF freq is 1951500 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING: >>> tuning failed!!! --> Using DVB-S2 >>> tune to: 12551:vC56S1:S0.0W:22000: DiSEqC: uncommitted switch pos 0 DiSEqC: switch pos 0, 13V, hiband (index 2) DVB-S IF freq is 1951500 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING: >>> tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Done. Meanwhile, this is written to dmesg (repeating): [43395.935293] stb6100_set_bandwidth: Bandwidth=5161 [43395.943657] stb6100_get_bandwidth: Bandwidth=1000 [43395.970435] stb6100_get_bandwidth: Bandwidth=1000 [43396.062102] stb6100_set_frequency: Frequency=1951500 [43396.070464] stb6100_get_frequency: Frequency=0 [43396.084862] stb6100_get_bandwidth: Bandwidth=1000 [43396.622789] stb6100_set_bandwidth: Bandwidth=5161 [43396.631150] stb6100_get_bandwidth: Bandwidth=1000 [43396.657947] stb6100_get_bandwidth: Bandwidth=1000 [43396.754182] stb6100_set_frequency: Frequency=1951500 [43396.762548] stb6100_get_frequency: Frequency=0 [43396.776884] stb6100_get_band