Re: problems with using the -rc kernel in the git tree
On Sun, Dec 19, 2010 at 6:56 PM, Theodore Kilgore wrote: > > Hans, > > Thanks for the helpful advice about how to set up a git tree for current > development so that I can get back into things. > > However, there is a problem with that -rc kernel, at least as far as my > hardware is concerned. So if I am supposed to use it to work on camera > stuff there is an obstacle. > > I started by copying my .config file over to the tree, and then running > make oldconfig (as you said and as I would have done anyway). > > The problem seems to be centered right here (couple of lines > from .config follow) > > CONFIG_DRM_RADEON=m > # CONFIG_DRM_RADEON_KMS is not set > > I have a Radeon video card, obviously. Specifically, it is (extract from X > config file follows) > > # Device configured by xorgconfig: > > Section "Device" > Identifier "ATI Radeon HD 3200" > Driver "radeon" > > Now, what happens is that with the kernel configuration (see above) I > cannot start X in the -rc kernel. I get bumped out with an error > message (details below) whereas that _was_ my previous configuration > setting. > > But if in the config for the -rc kernel I change the second line by > turning on CONFIG_DRM_RADEON_KMS the situation is even worse. Namely, the > video cuts off during the boot process, with the monitor going blank and > flashing up a message that it lost signal. After that the only thing to do > is a hard reset, which strangely does not result in any check for a dirty > file system, showing that things _really_ got screwed. These problems wit > the video cutting off at boot are with booting into the _terminal_, BTW. I > do not and never have made a practice of booting into X. I start X from > the command line after boot. Thus, the video cutting off during boot has > nothing to do with X at all, AFAICT. > > So as I said there are two alternatives, both of them quite unpleasant. > > Here is what the crash message is on the screen from the attempt to start > up X, followed by what seem to be the relevant lines from the log file, > with slightly more detail. > > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 19 14:32:12 2010 > (==) Using config file: "/etc/X11/xorg.conf" > (==) Using system config directory "/usr/share/X11/xorg.conf.d" > (II) [KMS] drm report modesetting isn't supported. > (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22) > (EE) RADEON(0): Memory map the MMIO region failed > (EE) Screen(s) found, but none have a usable configuration. > > Fatal server error: > no screens found > > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > Please also check the log file at "/var/log/Xorg.0.log" for additional > information. > > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error > xinit: unable to connect to X server: Connection refused > xinit: server error > kilg...@khayyam:~$ > > And the following, too, from the log file, which perhaps contains one or > two > more details: > > [ 48.050] (--) using VT number 7 > > [ 48.052] (II) [KMS] drm report modesetting isn't supported. > [ 48.052] (II) RADEON(0): TOTO SAYS feaf > [ 48.052] (II) RADEON(0): MMIO registers at 0xfeaf: size > 64KB > [ 48.052] (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument > (22) > [ 48.052] (EE) RADEON(0): Memory map the MMIO region failed > [ 48.052] (II) UnloadModule: "radeon" > [ 48.052] (EE) Screen(s) found, but none have a usable configuration. > [ 48.052] > Fatal server error: > [ 48.052] no screens found > [ 48.052] > > There are a couple of suggestions about things to try, such as compiling > with CONFIG_DRM_RADEON_KMS and then passing the parameter modeset=0 to the > radeon module. But that does not seem to help, either. > > The help screens in make menuconfig do not seem to praise the > CONFIG_DRM_RADEON_KMS very highly, and seem to indicate that this is still > a very experimental feature. > > There are no such equivalent problems with my current kernel, which is a > home-compiled 2.6.35.7. > > I realize that this is a done decision, but it is exactly this kind of > thing that I had in mind when we had the Great Debate on the linux-media > list about whether to use hg or git. My position was to let hardware > support people to run hg with the compatibility layer for recent kernels > (and 2.6.35.7 is certainly recent!). Well, the people who had such a > position did not win. So now here is unfortunately the foreseeable result. > An experimental kernel with some totally unrelated bug which affects my > hardware and meanwhile stops all progress. If you enable radeon KMS, you need to enable fbcon in your kernel or you will lose video when the radeon
Re: tm6000 and IR
Hi If Apple use full 32-bit scancode we need full raw 32-bit keytable for compatibility. For this need rework all keytables and all keyread function for add scanmask configuration and rework single byte scancode code -> key << 8. Use scanmask and return IR reading bytes on real place. For tm6000 don't need restore full scancode Only address filter scanmask = 0xff00ff00; return byte[1] << 24 | byte[0] <<8 With my best regards, Dmitry. > Hi Dmitri/Stefan, > > Em 17-12-2010 05:08, Dmitri Belimov escreveu: > > On Fri, 17 Dec 2010 06:18:31 +0100 > > Stefan Ringel wrote: > > > >> Am 17.12.2010 02:46, schrieb Dmitri Belimov: > >>> Hi Stefan > >>> > Am 16.12.2010 10:38, schrieb Dmitri Belimov: > > Hi > > > >>> I think your mean is wrong. Our IR remotes send extended NEC > >>> it is 4 bytes. We removed inverted 4 byte and now we have 3 > >>> bytes from remotes. I think we must have full RCMAP with this > >>> 3 bytes from remotes. And use this remotes with some > >>> different IR recievers like some TV cards and LIRC-hardware > >>> and other. No need different RCMAP for the same remotes to > >>> different IR recievers like now. > >> Your change doesn't work with my terratec remote control !! > > I found what happens. Try my new patch. > > > > What about NEC. Original NEC send > > address (inverted address) key (inverted key) > > this is realy old standart now all remotes use extended NEC > > (adress high) (address low) key (inverted key) > > The trident 5600/6000/6010 use old protocol but didn't test > > inverted address byte. > > > > I think much better discover really address value and write it > > to keytable. For your remotes I add low address byte. This > > value is incorrent but usefull for tm6000. When you found > > correct value update keytable. > > > That is not acceptable. Have you forgotten what Mauro have > written? The Terratec rc map are use from other devices. > >>> NO > >>> The RC_MAP_NEC_TERRATEC_CINERGY_XS used only in tm6000 module. > >>> My patch didn't kill support any other devices. > >> That is not true. > > > > I search "RC_MAP_NEC_TERRATEC_CINERGY_XS" on FULL linux kernel > > sources. And found this string in: > > include/media/rc-map.h > > drivers/staging//tm6000/tm6000-cards.c > > drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c > > > > No any other devices didn't use this keymap. > > > The best are only the > received data without additional data. And I think the Trident > chip send only compatibly data (send all extended data like > standard data). The device decoded the protocols not the driver. > >>> You can't use this remotes with normal working IR receivers > >>> because this receivers returned FULL scancodes. Need add one more > >>> keytable. > >>> > >>> 1. With my variant we have one keytable of remote and some > >>> workaround in device drivers. And can switch keytable and remotes > >>> on the fly (of course when keytable has really value and device > >>> driver has workaround) > >>> > >>> 2. With your variant we have some keytables for one remote for > >>> different IR recevers. Can't use incompatible keytable with other > >>> IR recievers. It is black magic for understanding what remotes is > >>> working with this hardware. > >>> > >>> I think my variant much better. > >>> > >>> With my best regards, Dmitry. > >>> > >> I think your variant is bad. > > > > Mauro we need your opinion about this question. > > I'm c/c Jarod, as he has a similar issue with some NEC-based boards > (Apple "variant"). > > I also have experienced some cases where the NEC protocol in-hardware > decoder can provide only part of the NEC "extended" range. > > I don't have a clear opinion about this issue, but I think that > putting all our brains to think about that, we may have a solution > for it. > > Let me summarize the issues. Please complete/correct me if is there > anything else. > > 1) NEC original format is 16 bits. However, some variants use 24 bits > for it (it is called, currently, NEC extended). A few other > manufacturers, like Apple, defines NEC protocol with 32 bits, > removing both address and command checksums. > > 2) NEC raw decoder is capable of decoding the entire NEC code, but it > only accepts 16 or 24 bits, returning the scan code as: > > scancode = address << 8 | command; > > for 16 bits, and: > > scancode = address << 16 | not_address << 8 | command; > > for 24 bits. There were some proposals to extend it to something like: > > scancode = address << 24 | not_address << 16 | not_command << > 8 | command; (or some other bit order) > > Or just return the complete 32 bits even for the original NEC > protocol. However, changing it will break the existing userspace > decoding tables. > > Another way would be to store the length of the scancode, using it as > well during the scancode->keycode translation. >
Re: Power frequency detection.
On Sun, 19 Dec 2010, Andy Walls wrote: > On Sun, 2010-12-19 at 18:13 -0600, Theodore Kilgore wrote: > > > > On Sun, 19 Dec 2010, Andy Walls wrote: > > > > The Software for our Sakar branded Jeilin camera was a little smarter. > > > > Oh. So _you_ had a Sakar branded camera. This was one of the things that > > causes problems recently. In gspca.txt we have the supported camera listed > > as > > > > jeilinj 0979:0280 Sakar 57379 > > > > which seemed to me to be quite wrong, as (unless I have made a bad > > mistake) the Sakar 57379 has a Jeilin 2005C or D chip inside (proprietary > > interface camera, Product number 0x227, definitely not one of these guys) > > and AFAICT the Jeilin 2005C-D cameras can not be made to stream at all, > > operating only in stillcam mode. So, when I was contacted about this new > > camera I saw that listing and thought it had to be wrong! OK, I looked again more closely in libgphoto2/camlibs/jl2005c/library.c, in which one sees Sakar no. 75379 If you are my age you _do_ need to look twice. Then three times. Then have a friend point out that you did not see something right. In case you are missing it, too 57379 != 75379 So, thanks. At least that is one thing I do not need to fix. > > > > Hoping that you still have some way to check what the Sakar product number > > of your cam really was... > > The Internet never forgets: > > http://www.spinics.net/lists/linux-media/msg07025.html > > http://www.spinics.net/lists/linux-media/msg07127.html Yes, I guess that clears it all up. I _do_ still have those messages somewhere, but it is every so much easier to do it this way. > > It looks like I hypothesized my camera had a JL2008 chips given the AVI > files it created had "JL2008V2C" in it. This appears to be a very reasonable hypothesis. I never thought the camera has a JL2005C chip in it. I just thought I had erroneously listed a camera in gspca.txt which was in fact some other kind of camera. But, as I said, 57379 != 75379 and they are not the same camera, either. Thanks again. 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: Power frequency detection.
On Sun, 2010-12-19 at 18:13 -0600, Theodore Kilgore wrote: > > On Sun, 19 Dec 2010, Andy Walls wrote: > > The Software for our Sakar branded Jeilin camera was a little smarter. > > Oh. So _you_ had a Sakar branded camera. This was one of the things that > causes problems recently. In gspca.txt we have the supported camera listed > as > > jeilinj 0979:0280 Sakar 57379 > > which seemed to me to be quite wrong, as (unless I have made a bad > mistake) the Sakar 57379 has a Jeilin 2005C or D chip inside (proprietary > interface camera, Product number 0x227, definitely not one of these guys) > and AFAICT the Jeilin 2005C-D cameras can not be made to stream at all, > operating only in stillcam mode. So, when I was contacted about this new > camera I saw that listing and thought it had to be wrong! > > Hoping that you still have some way to check what the Sakar product number > of your cam really was... The Internet never forgets: http://www.spinics.net/lists/linux-media/msg07025.html http://www.spinics.net/lists/linux-media/msg07127.html It looks like I hypothesized my camera had a JL2008 chips given the AVI files it created had "JL2008V2C" in it. I hope that email thread archive has the information you need. Also there is this thread where Jean-Francois talked about the contents of gspca.txt: http://www.spinics.net/lists/linux-media/msg08477.html Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Power frequency detection.
On Sun, 2010-12-19 at 18:21 -0600, Theodore Kilgore wrote: > If the controls are locked while the workqueue is doing the streaming, > then probably that does fix the problem? Most likely, that is the simplest > thing to do. Drivers are allowed to return -EBUSY per the V4L2 spec. http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-ctrl.html http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-ext-ctrls.html Regards, Andy > 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: Power frequency detection.
On Sun, 19 Dec 2010, Adam Baker wrote: > On Sunday 19 Dec 2010, Theodore Kilgore wrote: > > Finally, one concern that I have in the back of my mind is the question of > > control settings for a camera which streams in bulk mode and requires the > > setup of a workqueue. The owner of the camera says that he has > > "encountered no problems" with running the two controls mentioned above. > > Clearly, that is not a complete answer which overcomes all possible > > objections. Rather, things are OK if and only if we can ensure that these > > controls can be run only while the workqueue that does the streaming is > > inactive. Somehow, I suspect that the fact that a sensible user would only > > run such commands at camera setup is an insufficient guarantee that no > > problems will ever be encountered. > > > > So, as I said, the question of interaction of a control and a workqueue is > > another problem interesting little problem. Your thoughts on this > > interesting little problem would be appreciated. > > I don't think you can assume a user won't try to adjust such controls while > streaming - what I said, actually if I had one I'd certainly want to try swapping the control while > streaming to see if I could see any affect on the output. Yeah, I tell people that I like to see if I can hook things together and make something go "bang." Or, that I do research about locating that elusive magic smoke in the hardware, which makes it run. So maybe I would try that too, just for the pure hell of it. But I did say something about a "sensible user"? Neither of us, apparently. And come down to it, if one cannot trust you, and cannot trust me, as much work as we did together, then nobody can be trusted at all. :-} Even though sq905.c > doesn't have any controls on the camera it still ended up needing the locking > that would make this safe. See the header comment on sq905_dostream If the controls are locked while the workqueue is doing the streaming, then probably that does fix the problem? Most likely, that is the simplest thing to do. 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
General Question regarding SNR
Hello, i hope it's okay to ask here. I'm wondering how the SNR is calculated, and how someone can calculate the "real" snr in db. This caused me a lot of nerves and i don't seem to be able to calculate the correct snr. For that some examples. I'm using DVB-T and a Hauppauge WinTV-HVR1200 (Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02)) dvbsnoop reports cycle: 1 d_time: 0.001 s Sig: 63993 SNR: 185 BER: 839 UBLK: 11 Stat: 0x00 [] cycle: 2 d_time: 0.003 s Sig: 64507 SNR: 185 BER: 839 UBLK: 18 Stat: 0x00 [] cycle: 3 d_time: 0.003 s Sig: 63993 SNR: 168 BER: 839 UBLK: 28 Stat: 0x00 [] WITHOUT a antenna connected, WITHOUT a sender tuned. I guess it's quite unlikely that i have 185 db snr, without anything connected nor tuned. Alright. With a 42 db amplified antenna connected, i get SNRs between 143 and 178 (calculated with bash and tzap.. e.g.: ((snr_in_db=16#$snr_from_tzap)) -> ((var=16#0092)) echo $var 146 (should be db) Doing so, reports also db values of 215 which should be quite unlikely even when using cable (correct me if i'm wrong). So let's assume that the value which is reported needs to be subtracted from the above value. Then we would have: 215 - 185 = 30 db (sounds resonable) 146 - 185 = -39 db (errm... ok.. so this can't be) AAnother try, some guy reported to calculate the snr (reported snr = 0f1f1 (though seems to be for dvb-s, and i'm dealing with dvb-t) like this: 0xf1 / 8 = 30.125 db (sounds reasonable) But why did he removed the last two parts? (0xf1 = 0f1f1 ???) ok.. so let's try again: 0092 .. => 146. 146 / 8 = 18. So 18 db, sounds reasonable, though remember dvbsnoop reports 185 snr without anything connected, if i take this as "noise" and want to remove it to get the real value i'd have: 185 = 23 and 18 db - 23 db = -5 db. So.. errm. WTF? Who can enlighten me? -- 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: Power frequency detection.
On Sunday 19 Dec 2010, Theodore Kilgore wrote: > Finally, one concern that I have in the back of my mind is the question of > control settings for a camera which streams in bulk mode and requires the > setup of a workqueue. The owner of the camera says that he has > "encountered no problems" with running the two controls mentioned above. > Clearly, that is not a complete answer which overcomes all possible > objections. Rather, things are OK if and only if we can ensure that these > controls can be run only while the workqueue that does the streaming is > inactive. Somehow, I suspect that the fact that a sensible user would only > run such commands at camera setup is an insufficient guarantee that no > problems will ever be encountered. > > So, as I said, the question of interaction of a control and a workqueue is > another problem interesting little problem. Your thoughts on this > interesting little problem would be appreciated. I don't think you can assume a user won't try to adjust such controls while streaming - if I had one I'd certainly want to try swapping the control while streaming to see if I could see any affect on the output. Even though sq905.c doesn't have any controls on the camera it still ended up needing the locking that would make this safe. See the header comment on sq905_dostream Adam -- 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: Power frequency detection.
On Sun, 19 Dec 2010, Andy Walls wrote: > On Sun, 2010-12-19 at 14:51 -0600, Theodore Kilgore wrote: > > > > On Sun, 19 Dec 2010, Andy Walls wrote: > > > > > Theodore, > > > > > > Aside from detect measurment of the power line, isn't a camera the best > > > sort of sensor for this measurment anyway? > > > > > > Just compute the average image luminosity over several frames and look > > > for (10 Hz ?) periodic variation (beats), indicating a mismatch. > > > > > > Sure you could just ask the user, but where's the challenge in that. ;) > > > > > > Regards, > > > Andy > > > > Well, if it is "established policy" to go with doing this as a control, I > > guess we can just go ahead instead of doing something fancy. > > My policy is let computers do what computers do well, and let people do > what people do well. Looking at an image, recognizing flicker, and > twiddling knobs to make it go away (to one's own satisfaction) is much > better left to a person for one time adjustments. OK. > > But it is nice to hear from you. Here is why. > > > > The camera in question is another jeilinj camera. Its OEM software for > > that other OS does present the option to choose line frequency. It also > > asks for the user to specify an image quality index. I can not recall that > > the software I got with my camera did any such thing. As I recall, it > > merely let the camera to start streaming. Bur at the moment I have no idea > > where I put that old CD. > > The Software for our Sakar branded Jeilin camera was a little smarter. Oh. So _you_ had a Sakar branded camera. This was one of the things that causes problems recently. In gspca.txt we have the supported camera listed as jeilinj 0979:0280 Sakar 57379 which seemed to me to be quite wrong, as (unless I have made a bad mistake) the Sakar 57379 has a Jeilin 2005C or D chip inside (proprietary interface camera, Product number 0x227, definitely not one of these guys) and AFAICT the Jeilin 2005C-D cameras can not be made to stream at all, operating only in stillcam mode. So, when I was contacted about this new camera I saw that listing and thought it had to be wrong! Hoping that you still have some way to check what the Sakar product number of your cam really was... > I seem to recall image size adjustments. Yes, the new one does. And these adjustments do seem to work with my old one, too. I also recall the driver > binary contained multiple different MJPEG headers that I guess it could > have tack back on to the incoming stream. Hmmm. Probably that had something to do with the "quality" setting? > > However, the camera suffered such love/abuse at the hands of my 11 year > old daughter that it no longer functions, even with the electrical tape > that still holds the case together. ;) > > > > So, while I have you on the line, do you recall whether or not the OEM > > software for the camera you bought for your daughter present any such > > setup options? > > I cannot. > > > > The new camera may be different in some particulars from the ones we have. > > It does have a new Product number, so apparently Jeilin might not have > > thought it is identical to the other ones. It does use a slightly > > different initialization sequence. Therefore, the quick-and-dirty way to > > support it would be just to introduce a patch which has switch statements > > or conditionals all over the place, and just to support whatever the > > camera was observed to do. However, that is obviously dirty as well as > > quick. > > > > While playing around with the code a bit, I have managed to make my > > old camera work with essentially the same init sequence that the new > > one is using. If this can be done right, it would clear a lot of crud out > > of the driver code. Unfortunately, doing it right involves testing... > > When researching Jeilin's offerings on their website long ago I recall a > few different chipsets, but only one that matched the MJPEG type camera > application. It's probably just the difference between different > firmware versions in the camera with the same Jeilin camera chipset. > > > > Finally, one concern that I have in the back of my mind is the question of > > control settings for a camera which streams in bulk mode and requires the > > setup of a workqueue. The owner of the camera says that he has > > "encountered no problems" with running the two controls mentioned above. > > Clearly, that is not a complete answer which overcomes all possible > > objections. Rather, things are OK if and only if we can ensure that these > > controls can be run only while the workqueue that does the streaming is > > inactive. Somehow, I suspect that the fact that a sensible user would only > > run such commands at camera setup is an insufficient guarantee that no > > problems will ever be encountered. > > > > So, as I said, the question of interaction of a control and a workqueue is > > another probl
problems with using the -rc kernel in the git tree
Hans, Thanks for the helpful advice about how to set up a git tree for current development so that I can get back into things. However, there is a problem with that -rc kernel, at least as far as my hardware is concerned. So if I am supposed to use it to work on camera stuff there is an obstacle. I started by copying my .config file over to the tree, and then running make oldconfig (as you said and as I would have done anyway). The problem seems to be centered right here (couple of lines from .config follow) CONFIG_DRM_RADEON=m # CONFIG_DRM_RADEON_KMS is not set I have a Radeon video card, obviously. Specifically, it is (extract from X config file follows) # Device configured by xorgconfig: Section "Device" Identifier "ATI Radeon HD 3200" Driver "radeon" Now, what happens is that with the kernel configuration (see above) I cannot start X in the -rc kernel. I get bumped out with an error message (details below) whereas that _was_ my previous configuration setting. But if in the config for the -rc kernel I change the second line by turning on CONFIG_DRM_RADEON_KMS the situation is even worse. Namely, the video cuts off during the boot process, with the monitor going blank and flashing up a message that it lost signal. After that the only thing to do is a hard reset, which strangely does not result in any check for a dirty file system, showing that things _really_ got screwed. These problems wit the video cutting off at boot are with booting into the _terminal_, BTW. I do not and never have made a practice of booting into X. I start X from the command line after boot. Thus, the video cutting off during boot has nothing to do with X at all, AFAICT. So as I said there are two alternatives, both of them quite unpleasant. Here is what the crash message is on the screen from the attempt to start up X, followed by what seem to be the relevant lines from the log file, with slightly more detail. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 19 14:32:12 2010 (==) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (II) [KMS] drm report modesetting isn't supported. (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22) (EE) RADEON(0): Memory map the MMIO region failed (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error xinit: unable to connect to X server: Connection refused xinit: server error kilg...@khayyam:~$ And the following, too, from the log file, which perhaps contains one or two more details: [48.050] (--) using VT number 7 [48.052] (II) [KMS] drm report modesetting isn't supported. [48.052] (II) RADEON(0): TOTO SAYS feaf [48.052] (II) RADEON(0): MMIO registers at 0xfeaf: size 64KB [48.052] (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22) [48.052] (EE) RADEON(0): Memory map the MMIO region failed [48.052] (II) UnloadModule: "radeon" [48.052] (EE) Screen(s) found, but none have a usable configuration. [48.052] Fatal server error: [48.052] no screens found [48.052] There are a couple of suggestions about things to try, such as compiling with CONFIG_DRM_RADEON_KMS and then passing the parameter modeset=0 to the radeon module. But that does not seem to help, either. The help screens in make menuconfig do not seem to praise the CONFIG_DRM_RADEON_KMS very highly, and seem to indicate that this is still a very experimental feature. There are no such equivalent problems with my current kernel, which is a home-compiled 2.6.35.7. I realize that this is a done decision, but it is exactly this kind of thing that I had in mind when we had the Great Debate on the linux-media list about whether to use hg or git. My position was to let hardware support people to run hg with the compatibility layer for recent kernels (and 2.6.35.7 is certainly recent!). Well, the people who had such a position did not win. So now here is unfortunately the foreseeable result. An experimental kernel with some totally unrelated bug which affects my hardware and meanwhile stops all progress. 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
[RESEND] [PATCH for 2.6.37] cx23885, cx25840: Provide IR Rx timeout event reports
(Resending because Mauro reported losing some emails on IRC)
Provide CX2388[578] IR receive timeout (RTO) reports in the
final space raw event sent up the chain to the raw IR pulse
decoders. This should allow the lirc decoder to actually
measure the inter-transmission gap properly.
Signed-off-by: Andy Walls
---
drivers/media/video/cx23885/cx23888-ir.c | 12
drivers/media/video/cx25840/cx25840-ir.c | 12
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23888-ir.c
b/drivers/media/video/cx23885/cx23888-ir.c
index e37be6f..bb1ce34 100644
--- a/drivers/media/video/cx23885/cx23888-ir.c
+++ b/drivers/media/video/cx23885/cx23888-ir.c
@@ -673,7 +673,7 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
unsigned int i, n;
union cx23888_ir_fifo_rec *p;
- unsigned u, v;
+ unsigned u, v, w;
n = count / sizeof(union cx23888_ir_fifo_rec)
* sizeof(union cx23888_ir_fifo_rec);
@@ -692,11 +692,12 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
if ((p->hw_fifo_data & FIFO_RXTX_RTO) == FIFO_RXTX_RTO) {
/* Assume RTO was because of no IR light input */
u = 0;
- v4l2_dbg(2, ir_888_debug, sd, "rx read: end of rx\n");
+ w = 1;
} else {
u = (p->hw_fifo_data & FIFO_RXTX_LVL) ? 1 : 0;
if (invert)
u = u ? 0 : 1;
+ w = 0;
}
v = (unsigned) pulse_width_count_to_ns(
@@ -707,9 +708,12 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
init_ir_raw_event(&p->ir_core_data);
p->ir_core_data.pulse = u;
p->ir_core_data.duration = v;
+ p->ir_core_data.timeout = w;
- v4l2_dbg(2, ir_888_debug, sd, "rx read: %10u ns %s\n",
-v, u ? "mark" : "space");
+ v4l2_dbg(2, ir_888_debug, sd, "rx read: %10u ns %s %s\n",
+v, u ? "mark" : "space", w ? "(timed out)" : "");
+ if (w)
+ v4l2_dbg(2, ir_888_debug, sd, "rx read: end of rx\n");
}
return 0;
}
diff --git a/drivers/media/video/cx25840/cx25840-ir.c
b/drivers/media/video/cx25840/cx25840-ir.c
index 627926f..b210c29 100644
--- a/drivers/media/video/cx25840/cx25840-ir.c
+++ b/drivers/media/video/cx25840/cx25840-ir.c
@@ -668,7 +668,7 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
u16 divider;
unsigned int i, n;
union cx25840_ir_fifo_rec *p;
- unsigned u, v;
+ unsigned u, v, w;
if (ir_state == NULL)
return -ENODEV;
@@ -694,11 +694,12 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
if ((p->hw_fifo_data & FIFO_RXTX_RTO) == FIFO_RXTX_RTO) {
/* Assume RTO was because of no IR light input */
u = 0;
- v4l2_dbg(2, ir_debug, sd, "rx read: end of rx\n");
+ w = 1;
} else {
u = (p->hw_fifo_data & FIFO_RXTX_LVL) ? 1 : 0;
if (invert)
u = u ? 0 : 1;
+ w = 0;
}
v = (unsigned) pulse_width_count_to_ns(
@@ -709,9 +710,12 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
init_ir_raw_event(&p->ir_core_data);
p->ir_core_data.pulse = u;
p->ir_core_data.duration = v;
+ p->ir_core_data.timeout = w;
- v4l2_dbg(2, ir_debug, sd, "rx read: %10u ns %s\n",
-v, u ? "mark" : "space");
+ v4l2_dbg(2, ir_debug, sd, "rx read: %10u ns %s %s\n",
+v, u ? "mark" : "space", w ? "(timed out)" : "");
+ if (w)
+ v4l2_dbg(2, ir_debug, sd, "rx read: end of rx\n");
}
return 0;
}
--
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
[RESEND] [PATCH for 2.6.37 REGRESSION] cx25840: Prevent device probe failure due to volume control ERANGE error
(Resending because Mauro reported losing some emails on IRC.)
This patch was created and tested against linux-next
( git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ),
tag next-20101203, and fixes a regression that crept into 2.6.36.
The volume control scale in the cx25840 driver has an unusual mapping
from register values to v4l2 volume control values. Enforce the mapping
limits, so that the default volume control setting does not fall out of
bounds to prevent the cx25840 module device probe from failing.
Signed-off-by: Andy Walls
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
---
drivers/media/video/cx25840/cx25840-core.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx25840/cx25840-core.c
b/drivers/media/video/cx25840/cx25840-core.c
index dfb198d..f164618 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -1989,8 +1989,23 @@ static int cx25840_probe(struct i2c_client *client,
v4l2_ctrl_new_std(&state->hdl, &cx25840_ctrl_ops,
V4L2_CID_HUE, -128, 127, 1, 0);
if (!is_cx2583x(state)) {
- default_volume = 228 - cx25840_read(client, 0x8d4);
- default_volume = ((default_volume / 2) + 23) << 9;
+ default_volume = cx25840_read(client, 0x8d4);
+ /*
+* Enforce the legacy PVR-350/MSP3400 to PVR-150/CX25843 volume
+* scale mapping limits to avoid -ERANGE errors when
+* initializing the volume control
+*/
+ if (default_volume > 228) {
+ /* Bottom out at -96 dB, v4l2 vol range 0x2e00-0x2fff */
+ default_volume = 228;
+ cx25840_write(client, 0x8d4, 228);
+ }
+ else if (default_volume < 20) {
+ /* Top out at + 8 dB, v4l2 vol range 0xfe00-0x */
+ default_volume = 20;
+ cx25840_write(client, 0x8d4, 20);
+ }
+ default_volume = (((228 - default_volume) >> 1) + 23) << 9;
state->volume = v4l2_ctrl_new_std(&state->hdl,
&cx25840_audio_ctrl_ops, V4L2_CID_AUDIO_VOLUME,
--
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: Power frequency detection.
On Sun, 2010-12-19 at 17:00 -0500, Andy Walls wrote: > On Sun, 2010-12-19 at 14:51 -0600, Theodore Kilgore wrote: Just a few more details... > So I might not be able to provide too much help. I have 2 ideas for you > coming from the perspective of me being a USB idiot: > > > 1. Since the jlj_dostream() work handler function is essentially just a > synchronous poll loop on the device, you could just have it process the > ioctl() requests to change a control synchronously. > > a. The ioctl() call for the v4l2 control would submit a command to some > queue you set up for the purpose, and then sleep on a wait queue. > > b. The jlj_dostream() function would check the command queue at its > convenience, process any control command, and then wake up the wait > queue that the ioctl() is waiting on. > > For this idea, don't forget to implement the command queue with proper > locking or other mutual exclusion. You'll also need to think about how > to place ioctl() callers on the wait_queue and how to wake them up in > FIFO order, if you use this idea and allow multiple v4l2 control ioctl() > to be queued. > > > > 2. Restructure the workqueue function, jlj_dostream(), to handle a work > object in one pass (e.g. no loop to read more than one frame), handle > two different types of work objects (one for stream polling and one for > control ioctl() requests), and have it automatically reschedule the > stream polling work object. > > a. When streaming, the current, single work object would still be used > and jlj_dostream() must be able to check that the work object is the one > indicating streaming work. jlj_dostream() would only perform work > required to read one whole frame, unless you want to get fancy and deal > with partial frames. The jlj_dostream() handler would then reschedule > the work object for streaming - maybe with a sensible delay. > > b. For a V4L2 control ioctl() that needs to send a command to the > device, the ioctl() fills out the needed parameters in a scratch-pad > location and queues a different work object, associated with those > scratchpad parameters. The ioctl() then sleeps on a wait queue > associated with that work object. When the work handler function, > jlj_dostream(), gets called it must be able to determine the work object > is the one associated with an ioctl() control. jlj_dostream() then > performs the actions required for the ioctl() and the wakes up the > wait_queue on which the ioctl() is waiting. The work object is not > rescheduled by the work handler function. > > > For this idea, you'll be relying on the single-threaded workqueue to > provide mutual exclusion between processing of the two different types > of work objects (streaming and v4l2 control ioctl). You can structure > things to have more than 1 work object for V4L2 control ioctl() > processing, if you like, since the workqueue can queue any number of > work objects. But if you allow more than one ioctl() related work > object to be queued, you'll have to be careful about how things are > placed on the wait_queue and how they are awakened. > > For implementing either of these ideas, you may also wish to investigate the use of completions instead of wait_queues. I've never used completions myself, so I'm not sure if they'll work. With a quick grep through the kernel, I only find the cx18 driver and libsas as examples using multiple work objects for a work handler function. In both of those, the purpose of the of work object is indicated with a field in the structure that also contains the work object. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Power frequency detection.
On Sun, 2010-12-19 at 14:51 -0600, Theodore Kilgore wrote: > > On Sun, 19 Dec 2010, Andy Walls wrote: > > > Theodore, > > > > Aside from detect measurment of the power line, isn't a camera the best > > sort of sensor for this measurment anyway? > > > > Just compute the average image luminosity over several frames and look for > > (10 Hz ?) periodic variation (beats), indicating a mismatch. > > > > Sure you could just ask the user, but where's the challenge in that. ;) > > > > Regards, > > Andy > > Well, if it is "established policy" to go with doing this as a control, I > guess we can just go ahead instead of doing something fancy. My policy is let computers do what computers do well, and let people do what people do well. Looking at an image, recognizing flicker, and twiddling knobs to make it go away (to one's own satisfaction) is much better left to a person for one time adjustments. > But it is nice to hear from you. Here is why. > > The camera in question is another jeilinj camera. Its OEM software for > that other OS does present the option to choose line frequency. It also > asks for the user to specify an image quality index. I can not recall that > the software I got with my camera did any such thing. As I recall, it > merely let the camera to start streaming. Bur at the moment I have no idea > where I put that old CD. The Software for our Sakar branded Jeilin camera was a little smarter. I seem to recall image size adjustments. I also recall the driver binary contained multiple different MJPEG headers that I guess it could have tack back on to the incoming stream. However, the camera suffered such love/abuse at the hands of my 11 year old daughter that it no longer functions, even with the electrical tape that still holds the case together. ;) > So, while I have you on the line, do you recall whether or not the OEM > software for the camera you bought for your daughter present any such > setup options? I cannot. > The new camera may be different in some particulars from the ones we have. > It does have a new Product number, so apparently Jeilin might not have > thought it is identical to the other ones. It does use a slightly > different initialization sequence. Therefore, the quick-and-dirty way to > support it would be just to introduce a patch which has switch statements > or conditionals all over the place, and just to support whatever the > camera was observed to do. However, that is obviously dirty as well as > quick. > > While playing around with the code a bit, I have managed to make my > old camera work with essentially the same init sequence that the new > one is using. If this can be done right, it would clear a lot of crud out > of the driver code. Unfortunately, doing it right involves testing... When researching Jeilin's offerings on their website long ago I recall a few different chipsets, but only one that matched the MJPEG type camera application. It's probably just the difference between different firmware versions in the camera with the same Jeilin camera chipset. > Finally, one concern that I have in the back of my mind is the question of > control settings for a camera which streams in bulk mode and requires the > setup of a workqueue. The owner of the camera says that he has > "encountered no problems" with running the two controls mentioned above. > Clearly, that is not a complete answer which overcomes all possible > objections. Rather, things are OK if and only if we can ensure that these > controls can be run only while the workqueue that does the streaming is > inactive. Somehow, I suspect that the fact that a sensible user would only > run such commands at camera setup is an insufficient guarantee that no > problems will ever be encountered. > > So, as I said, the question of interaction of a control and a workqueue is > another problem interesting little problem. Your thoughts on this > interesting little problem would be appreciated. I am unfamiliar with: 1. Any USB interface mutual exclusions the kernel USB API and subsystem provides as well as what the GSPCA framework provides. 2. Any USB transaction buffering and tracking the kernel USB subsystem provides. 3. Whether the kernel and Jeilin chip allow USB sends and receives to be interleaved to different bulk endpoints. So I might not be able to provide too much help. I have 2 ideas for you coming from the perspective of me being a USB idiot: 1. Since the jlj_dostream() work handler function is essentially just a synchronous poll loop on the device, you could just have it process the ioctl() requests to change a control synchronously. a. The ioctl() call for the v4l2 control would submit a command to some queue you set up for the purpose, and then sleep on a wait queue. b. The jlj_dostream() function would check the command queue at its convenience, process any control command, and then wake up the wait queue that the ioctl() is waiting on. Fo
Re: lot of bugs in cx88-blackbird
On Sunday, December 19, 2010 21:01:27 Martin Dauskardt wrote:
> The HVR1300 driver has several bugs:
>
> 1.
> When executing VIDIOC_S_EXT_CTRLS or VIDIOC_S_FREQUENCY on the mpeg device
> while the mpeg device is active (capturing), the driver calls
> blackbird_stop_codec(). This stops the encoder (API call
> CX2341X_ENC_STOP_CAPTURE).
> Unfortunately, the encoder gets never restarted after the ioctl is finished.
>
> To restart the encoder, we now need to stop capturing and restart reading.
> But if this is required anyway, the code could be much easier when the driver
> would simply return EBUSY.
>
> I think the bug was introduced in May 2007 (!) with this patch:
> (V4L/DVB (6828): cx88-blackbird: audio improvements)
> http://git.linuxtv.org/media_tree.git?a=commitdiff;h=f9e54e0c84da869ad9bc372fb4eab26d558dbfc2
>
> The necessary CX2341X_ENC_START_CAPTURE API command to restart the encoder
> was
> moved with this patch from blackbird_initialize_codec() to a new function
> blackbird_start_codec(), but this new function is not called.
>
> For vidioc_s_ext_ctrls the patch ("Stop the mpeg encoder when changing
> parameters ") totally misses a solution to restart the encoder.
>
> The different methods to switch channels with mpeg encoder cards have been
> discussed in the ivtv-devel list lately:
> http://www.gossamer-threads.com/lists/ivtv/devel/41154
>
> My suggestion is that the driver should return EBUSY for VIDIOC_S_FREQUENCY
> and all critical settings (standard, bitrate, format, ...) while a capture is
> in progess. This should happen not only on the mpeg device but also on the
> analogue device.
>
>
> 2.
> On this hybrid card, we have an analogue and an mpeg device. As far as I
> know
> there is still no application which knows how to handle this.
> If the User Controls (Brightness, Contrast, Saturation, Hue, Volume) are
> executed on the analogue device while the mpeg device is active, the result
> is
> static on audio+video. We need to stop reading and re-tune the current
> frequency by executing VIDIOC_S_FREQUENCY on the mpeg device.
>
> 3.
> When executing VIDIOC_S_FREQENCY or any other ioctl on the analogue device,
> the result is always static video+audio. v4l2-ctl --get-freq still shows the
> right frequency, but the tuner is obviously on another frequency.
>
> 4.
> If we use VIDIOC_S_STD on the analogue device, a following "v4l2-ctl --get-
> standard" (executed on the mpeg device) shows still the previous standard.
>
> 5.
> The default video size for mpeg is 720x480 (which is right for the default
> standard NTSC-M). If we change the standard to PAL-BG, the size is still
> 720x480. As far as I remember, the cx2341x does only work properly with
> height
> 576 when the video standard is 50Hz. The ivtv driver adjustes this
> automatically.
>
> 6.
> Setting the video size with VIDIOC_S_FMT for V4L2_BUF_TYPE_VIDEO_CAPTURE
> works
> only when executed on the mpeg device. How should an application know this?
> (for cards with saa7134-empress it is vice versa, VIDIOC_S_FMT works only on
> the analogue device...)
>
> 7.
> switching from an external input back to TV (input 0) often results in audio
> static. Re-setting the video standard helps.
>
> 8.
> The external input "S-Video" has no colour although an Y/C signal is supplied.
>
> 9.
> reading from mpeg device fails randomly with Input/output error. Even a
> driver
> reload is not sufficient - I have to reboot my machine to get it working
> again.
>
> 10.
> vidioc_s_ext_ctrls only supports V4L2_CTRL_CLASS_MPEG, but not
> V4L2_CTRL_CLASS_USER. The driver should internally pass these to
> vidioc_s_ctrl
> instead of returning EINVAL.
>
> 11.
> When switching from input Television to Input Composite1 , then switching to
> a
> radio channel and switching back to Composite 1, the video comes from
> Composite1 but the audio from Television (previous TV channel). Directly
> switching from Television to radio and then to Composite1 has no problems.
>
>
> I am not a driver developer and can't fix this myself. But I could do
> testings
> and hope there is a developer who is willing to have a look at these problems.
Some of these problems are related to control handling. One of the items on my
(very long) TODO list is to convert cx88 to use the new control framework.
Although I would very much appreciate it if someone else could take on that job.
The main problem is that there is no active maintainer for this driver. Unless
someone is willing to put in the hours needed I don't expect to see any
improvements :-(
One option is that you try to step in. If you know C, then doing driver
programming isn't really that magical. You already know a lot about V4L2, so
that will definitely help.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.or
Re: Power frequency detection.
On Sun, 19 Dec 2010, Andy Walls wrote: > On Sun, 2010-12-19 at 13:21 -0500, Andy Walls wrote: > > Theodore, > > Gah. I need to learn how to type or wear my glasses more often. > > > Aside from detect measurment of the power line, isn't a camera the > ^ > direct measurement > > > best sort of sensor for this measurment anyway? > ^^ > measurement > > > Just compute the average image luminosity over several frames and look > ^^^ > for Hey, never mind. My eyes are not what they used to be, either. 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: Power frequency detection.
On Sun, 2010-12-19 at 13:21 -0500, Andy Walls wrote:
> Theodore,
Gah. I need to learn how to type or wear my glasses more often.
> Aside from detect measurment of the power line, isn't a camera the
^
direct measurement
> best sort of sensor for this measurment anyway?
^^
measurement
> Just compute the average image luminosity over several frames and look
^^^
for
Regards,
Andy
> for (10 Hz ?) periodic variation (beats), indicating a mismatch.
>
> Sure you could just ask the user, but where's the challenge in
> that. ;)
>
> Regards,
> Andy
>
> Theodore Kilgore wrote:
>
> >
> >
> >On Sun, 19 Dec 2010, Paulo Assis wrote:
> >
> >> Hi,
> >>
> >> 2010/12/18 Theodore Kilgore :
> >> >
> >> > Does anyone know whether, somewhere in the kernel, there exists a scheme
> >> > for detecting whether the external power supply of the computer is using
> >> > 50hz or 60hz?
> >> >
> >> > The reason I ask:
> >> >
> >> > A certain camera is marketed with Windows software which requests the
> >> > user
> >> > to set up the option of 50hz or 60hz power during the setup.
> >> >
> >> > Judging by what exists in videodev2.h, for example, it is evidently
> >> > possible to set up this as a control setting in a Linux driver. I am not
> >> > aware of any streaming app which knows how to access such an option.
> >> >
> >>
> >> Most uvc cameras present this as a control, so any v4l2 control app
> >> should let you access it.
> >> If your camera driver also supports this control then this shouldn't
> >> be a problem for any generci v4l2 app.
> >> here are a couple of ones:
> >>
> >> v4l2ucp (control panel)
> >> guvcview ("guvcview --control_only" will work along side other apps
> >> just like v4l2ucp)
> >> uvcdynctrl from libwebcam for command line control utility .
> >>
> >> Regards,
> >> Paulo
> >
> >Thank you.
> >
> >I still think that it would be even more clever to detect the line
> >frequency automatically and then just to set the proper setting, if needed
> >or desirable. That was one of the parts of my question about it, after
> >all. But if nobody has ever had a reason to do such detection already it
> >would perhaps be much more trouble than it is worth just do support a
> >cheap camera.
> >
> >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
> NrybXǧv^){.n+{bj)w* jg ݢj/zޖ2ޙ&)ߡa Ghj:+vw٥
--
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: Power frequency detection.
On Sun, 19 Dec 2010, Andy Walls wrote: > Theodore, > > Aside from detect measurment of the power line, isn't a camera the best sort > of sensor for this measurment anyway? > > Just compute the average image luminosity over several frames and look for > (10 Hz ?) periodic variation (beats), indicating a mismatch. > > Sure you could just ask the user, but where's the challenge in that. ;) > > Regards, > Andy Well, if it is "established policy" to go with doing this as a control, I guess we can just go ahead instead of doing something fancy. But it is nice to hear from you. Here is why. The camera in question is another jeilinj camera. Its OEM software for that other OS does present the option to choose line frequency. It also asks for the user to specify an image quality index. I can not recall that the software I got with my camera did any such thing. As I recall, it merely let the camera to start streaming. Bur at the moment I have no idea where I put that old CD. So, while I have you on the line, do you recall whether or not the OEM software for the camera you bought for your daughter present any such setup options? The new camera may be different in some particulars from the ones we have. It does have a new Product number, so apparently Jeilin might not have thought it is identical to the other ones. It does use a slightly different initialization sequence. Therefore, the quick-and-dirty way to support it would be just to introduce a patch which has switch statements or conditionals all over the place, and just to support whatever the camera was observed to do. However, that is obviously dirty as well as quick. While playing around with the code a bit, I have managed to make my old camera work with essentially the same init sequence that the new one is using. If this can be done right, it would clear a lot of crud out of the driver code. Unfortunately, doing it right involves testing... Finally, one concern that I have in the back of my mind is the question of control settings for a camera which streams in bulk mode and requires the setup of a workqueue. The owner of the camera says that he has "encountered no problems" with running the two controls mentioned above. Clearly, that is not a complete answer which overcomes all possible objections. Rather, things are OK if and only if we can ensure that these controls can be run only while the workqueue that does the streaming is inactive. Somehow, I suspect that the fact that a sensible user would only run such commands at camera setup is an insufficient guarantee that no problems will ever be encountered. So, as I said, the question of interaction of a control and a workqueue is another problem interesting little problem. Your thoughts on this interesting little problem would be appreciated. As I said, Merry Christmas :-) 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
lot of bugs in cx88-blackbird
The HVR1300 driver has several bugs:
1.
When executing VIDIOC_S_EXT_CTRLS or VIDIOC_S_FREQUENCY on the mpeg device
while the mpeg device is active (capturing), the driver calls
blackbird_stop_codec(). This stops the encoder (API call
CX2341X_ENC_STOP_CAPTURE).
Unfortunately, the encoder gets never restarted after the ioctl is finished.
To restart the encoder, we now need to stop capturing and restart reading.
But if this is required anyway, the code could be much easier when the driver
would simply return EBUSY.
I think the bug was introduced in May 2007 (!) with this patch:
(V4L/DVB (6828): cx88-blackbird: audio improvements)
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=f9e54e0c84da869ad9bc372fb4eab26d558dbfc2
The necessary CX2341X_ENC_START_CAPTURE API command to restart the encoder was
moved with this patch from blackbird_initialize_codec() to a new function
blackbird_start_codec(), but this new function is not called.
For vidioc_s_ext_ctrls the patch ("Stop the mpeg encoder when changing
parameters ") totally misses a solution to restart the encoder.
The different methods to switch channels with mpeg encoder cards have been
discussed in the ivtv-devel list lately:
http://www.gossamer-threads.com/lists/ivtv/devel/41154
My suggestion is that the driver should return EBUSY for VIDIOC_S_FREQUENCY
and all critical settings (standard, bitrate, format, ...) while a capture is
in progess. This should happen not only on the mpeg device but also on the
analogue device.
2.
On this hybrid card, we have an analogue and an mpeg device. As far as I know
there is still no application which knows how to handle this.
If the User Controls (Brightness, Contrast, Saturation, Hue, Volume) are
executed on the analogue device while the mpeg device is active, the result is
static on audio+video. We need to stop reading and re-tune the current
frequency by executing VIDIOC_S_FREQUENCY on the mpeg device.
3.
When executing VIDIOC_S_FREQENCY or any other ioctl on the analogue device,
the result is always static video+audio. v4l2-ctl --get-freq still shows the
right frequency, but the tuner is obviously on another frequency.
4.
If we use VIDIOC_S_STD on the analogue device, a following "v4l2-ctl --get-
standard" (executed on the mpeg device) shows still the previous standard.
5.
The default video size for mpeg is 720x480 (which is right for the default
standard NTSC-M). If we change the standard to PAL-BG, the size is still
720x480. As far as I remember, the cx2341x does only work properly with height
576 when the video standard is 50Hz. The ivtv driver adjustes this
automatically.
6.
Setting the video size with VIDIOC_S_FMT for V4L2_BUF_TYPE_VIDEO_CAPTURE works
only when executed on the mpeg device. How should an application know this?
(for cards with saa7134-empress it is vice versa, VIDIOC_S_FMT works only on
the analogue device...)
7.
switching from an external input back to TV (input 0) often results in audio
static. Re-setting the video standard helps.
8.
The external input "S-Video" has no colour although an Y/C signal is supplied.
9.
reading from mpeg device fails randomly with Input/output error. Even a driver
reload is not sufficient - I have to reboot my machine to get it working
again.
10.
vidioc_s_ext_ctrls only supports V4L2_CTRL_CLASS_MPEG, but not
V4L2_CTRL_CLASS_USER. The driver should internally pass these to vidioc_s_ctrl
instead of returning EINVAL.
11.
When switching from input Television to Input Composite1 , then switching to a
radio channel and switching back to Composite 1, the video comes from
Composite1 but the audio from Television (previous TV channel). Directly
switching from Television to radio and then to Composite1 has no problems.
I am not a driver developer and can't fix this myself. But I could do testings
and hope there is a developer who is willing to have a look at these problems.
Greets,
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
[cron job] v4l-dvb daily build: 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:Sun Dec 19 19:00:23 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: 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 V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Power frequency detection.
Theodore,
Aside from detect measurment of the power line, isn't a camera the best sort of
sensor for this measurment anyway?
Just compute the average image luminosity over several frames and look for (10
Hz ?) periodic variation (beats), indicating a mismatch.
Sure you could just ask the user, but where's the challenge in that. ;)
Regards,
Andy
Theodore Kilgore wrote:
>
>
>On Sun, 19 Dec 2010, Paulo Assis wrote:
>
>> Hi,
>>
>> 2010/12/18 Theodore Kilgore :
>> >
>> > Does anyone know whether, somewhere in the kernel, there exists a scheme
>> > for detecting whether the external power supply of the computer is using
>> > 50hz or 60hz?
>> >
>> > The reason I ask:
>> >
>> > A certain camera is marketed with Windows software which requests the user
>> > to set up the option of 50hz or 60hz power during the setup.
>> >
>> > Judging by what exists in videodev2.h, for example, it is evidently
>> > possible to set up this as a control setting in a Linux driver. I am not
>> > aware of any streaming app which knows how to access such an option.
>> >
>>
>> Most uvc cameras present this as a control, so any v4l2 control app
>> should let you access it.
>> If your camera driver also supports this control then this shouldn't
>> be a problem for any generci v4l2 app.
>> here are a couple of ones:
>>
>> v4l2ucp (control panel)
>> guvcview ("guvcview --control_only" will work along side other apps
>> just like v4l2ucp)
>> uvcdynctrl from libwebcam for command line control utility .
>>
>> Regards,
>> Paulo
>
>Thank you.
>
>I still think that it would be even more clever to detect the line
>frequency automatically and then just to set the proper setting, if needed
>or desirable. That was one of the parts of my question about it, after
>all. But if nobody has ever had a reason to do such detection already it
>would perhaps be much more trouble than it is worth just do support a
>cheap camera.
>
>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
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: Power frequency detection.
On Sun, 19 Dec 2010, Paulo Assis wrote:
> Hi,
>
> 2010/12/18 Theodore Kilgore :
> >
> > Does anyone know whether, somewhere in the kernel, there exists a scheme
> > for detecting whether the external power supply of the computer is using
> > 50hz or 60hz?
> >
> > The reason I ask:
> >
> > A certain camera is marketed with Windows software which requests the user
> > to set up the option of 50hz or 60hz power during the setup.
> >
> > Judging by what exists in videodev2.h, for example, it is evidently
> > possible to set up this as a control setting in a Linux driver. I am not
> > aware of any streaming app which knows how to access such an option.
> >
>
> Most uvc cameras present this as a control, so any v4l2 control app
> should let you access it.
> If your camera driver also supports this control then this shouldn't
> be a problem for any generci v4l2 app.
> here are a couple of ones:
>
> v4l2ucp (control panel)
> guvcview ("guvcview --control_only" will work along side other apps
> just like v4l2ucp)
> uvcdynctrl from libwebcam for command line control utility .
>
> Regards,
> Paulo
Thank you.
I still think that it would be even more clever to detect the line
frequency automatically and then just to set the proper setting, if needed
or desirable. That was one of the parts of my question about it, after
all. But if nobody has ever had a reason to do such detection already it
would perhaps be much more trouble than it is worth just do support a
cheap camera.
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: Problem with sound on SAA7134 TV card
On Saturday 18 December 2010, Chris Clayton wrote:
> [chris:~]$ dmesg | grep saa7
> saa7130/34: v4l2 driver version 0.2.16 loaded
> saa7134 :03:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> saa7133[0]: found at :03:00.0, rev: 209, irq: 20, latency: 32, mmio:
> 0xe1605000
> saa7133[0]: subsystem: 0070:6707, board: Hauppauge WinTV-HVR1120
> DVB-T/Hybrid [card=156,autodetected]
> saa7133[0]: board init: gpio is 440100
> saa7133[0]: i2c eeprom 00: 70 00 07 67 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
> saa7133[0]: i2c eeprom 10: ff ff ff 0e ff 20 ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 20: 01 40 01 32 32 01 01 33 88 ff 00 b0 ff ff ff ff
> saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 40: ff 35 00 c0 96 10 06 32 97 04 00 20 00 ff ff ff
> saa7133[0]: i2c eeprom 50: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom 80: 84 09 00 04 20 77 00 40 c4 ce 6e f0 73 05 29 00
> saa7133[0]: i2c eeprom 90: 84 08 00 06 89 06 01 00 95 39 8d 72 07 70 73 09
> saa7133[0]: i2c eeprom a0: 23 5f 73 0a f4 9b 72 0b 2f 72 0e 01 72 0f 45 72
> saa7133[0]: i2c eeprom b0: 10 01 72 11 ff 73 13 a2 69 79 95 00 00 00 00 00
> saa7133[0]: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> saa7133[0]: hauppauge eeprom: model=67209
> tuner 1-004b: chip found @ 0x96 (saa7133[0])
> saa7133[0]: dsp access error
> saa7133[0]: dsp access error
> saa7133[0]: registered device video1 [v4l2]
> saa7133[0]: registered device vbi0
> saa7133[0]: registered device radio0
> DVB: registering new adapter (saa7133[0])
> saa7134 ALSA driver for DMA sound loaded
> saa7133[0]/alsa: saa7133[0] at 0xe1605000 irq 20 registered as card -1
>
> That last line looks a little suspicious to me with the card being
> registered as -1. The two "dsp access error" lines might mean something
> too.
>
After looking at the code I see that the report that the card is registered
as -1 isn't actually a problem, although the message is a bit deceptive.
The two dsp access error message are emitted by saa_dsp_wait_bit() in
saa7134_tvaudio.c, but the message sdon't appear every boot and even when they
don't the sound output is of the poor quality that I have reported.
I shoulfd also mention that I get the same problem with 2.6.37-rc{5,6}+ or
2.6.36.2. With 2 6 .35.9, mplayer reports an error opening a device.
That's the end of my debugging capablities reached, so I would be grateful for
any help that can be offered.
--
The more I see, the more I know. The more I know, the less I understand.
Changing Man - Paul Weller
--
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: Power frequency detection.
Hi,
2010/12/18 Theodore Kilgore :
>
> Does anyone know whether, somewhere in the kernel, there exists a scheme
> for detecting whether the external power supply of the computer is using
> 50hz or 60hz?
>
> The reason I ask:
>
> A certain camera is marketed with Windows software which requests the user
> to set up the option of 50hz or 60hz power during the setup.
>
> Judging by what exists in videodev2.h, for example, it is evidently
> possible to set up this as a control setting in a Linux driver. I am not
> aware of any streaming app which knows how to access such an option.
>
Most uvc cameras present this as a control, so any v4l2 control app
should let you access it.
If your camera driver also supports this control then this shouldn't
be a problem for any generci v4l2 app.
here are a couple of ones:
v4l2ucp (control panel)
guvcview ("guvcview --control_only" will work along side other apps
just like v4l2ucp)
uvcdynctrl from libwebcam for command line control utility .
Regards,
Paulo
> Information about which streaming app ought to be used which could take
> advantage of a setting for line frequency would be welcome, too, of
> course. As I said, I do not know of a single one and would therefore have
> trouble with testing any such control setting unless I could find the
> software which can actually present the choice to the user.
>
> But my main question is whether the kernel already does detect the line
> frequency anywhere else, for whatever reason. For, it occurs to me that a
> far more elegant solution -- if the camera really does need to have the
> line frequency detected -- would be do do the job automatically and not to
> bother the user about such a thing.
>
> In other news, in case anyone has any children who are in love with Lego,
> the "Lego Bionicle" camera which is currently on sale has an SQ905C type
> chip in it. I just added its Product number to the Gphoto driver last
> night. And it works perfectly in webcam mode if one adds its product
> number in gspca/sq905c.c. I will get around to doing that formally, of
> course, when I get time. But if anyone wants just to add the number and
> re-compile the Vendor:Product number for the new camera is 0x2770:0x9051.
>
> Merry Christmas.
>
> 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
>
--
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
bttv problem
Hi, i have 2 Provideo PV150 multi-capture PCI board video cards (4 bt878 chipsets in every board), i have the four ports of the first multi-capture boards used in a xorg session with 4 instances of tvtime application showing the realtime of the four ports, and the other one recording with Helix producer. Many times a day i have this errors in kernel: [447547.296022] bttv7: timeout: drop=3276 irq=1957469/35501901, risc=204bb9ac, bits: HSYNC OFLOW [447547.836020] bttv7: timeout: drop=3287 irq=1957508/35501981, risc=2a9a89ac, bits: HSYNC OFLOW [448114.536016] bttv6: timeout: drop=4747 irq=26301665/59788770, risc=2050c998, bits: HSYNC OFLOW [449923.196018] bttv1: timeout: drop=57206 irq=33728690/35680137, risc=19d83acc, bits: HSYNC OFLOW FBUS [449923.736024] bttv1: timeout: drop=57217 irq=33728729/35680176, risc=344faf20, bits: HSYNC OFLOW FBUS Tvtime seems to survive but the helix producer processess die with this error, if i don't load the xorg session with tvtime and at the same time I disable acpi in linux i don't get this erros, i have tried to disable acpi because i have read about other people having the same problem and fixing this way, but if i use tvtime at the same time the problem remains regardless of the acpi status, i have now gbuffers at 16 but still the same result. My system it is using debian squeeze with 2.6.32 kernel in a Asus P5E-V HDMI with an intel G-35 chipset. Any ideas on how i could fix this problem please? Regards, Miguel Angel. -- 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: TeVii S470 dvb-s2 issues - 2nd try ,)
Am Saturday 18 December 2010 schrieben Sie:
> On Sat, 2010-12-18 at 14:40 +0100, Boris Cuber wrote:
> > Am Friday 17 December 2010 schrieben Sie:
> > > On Fri, 2010-12-17 at 12:19 +0100, Boris Cuber wrote:
> > > > Hello linux-media people!
> > > >
> > > > I have to problems with my dvb card ("TeVii S470"). I already
> > > > filed 2 bug reports some time ago, but no one seems to have
> > > > noticed/read them, so i'm trying it here now.
> > > > If you need a "full" dmesg, then please take a look at
> > > > https://bugzilla.kernel.org/attachment.cgi?id=40552
> > > >
> > > > 1) "TeVii S470 dvbs-2 card (cx23885) is not usable after
> > > > pm-suspend/resume" https://bugzilla.kernel.org/show_bug.cgi?id=16467
> > >
> > > The cx23885 driver does not implement power management. It would
> > > likely take many, many hours of coding and testing to implement it
> > > properly.
> > >
> > > If you need resume/suspend, use the power management scripts on your
> > > machine to kill all the applications using the TeVii S470, and then
> > > unload the cx23885 module just before suspend.
> > >
> > > On resume, have the power management scripts reload the cx23885 module.
> >
> > Well, this doesn't work. If i did tune a channel before or used the dvb
> > card somehow for watching tv, unloading and reloading the cx23885
> > module also makes the card unuseable.
> > In dmesg there's lots of "do_IRQ: 1.161 No irq handler for vector (irq
> > -1)" messages then. This can only be fixed by rebooting the computer.
>
> That is s a known issue with the CX2388[578] chip and PCIe MSI.
>
> The CX2388[578] will not accept a different value for its "MSI Data"
> field in its PCI config space, when MSI has been enabled on the hardware
> once.
>
> The kernel will always try to give a different value for the "MSI Data"
> field to the CX2388[578] chip, on cx23885 module unload and reload.
>
> So suspend and then resume didn't reset the chip hardware?
>
> You can set "pci=nomsi" on your kernel command line to prevent the
> cx23885 driver, and your whole system unfortunately, from using MSI.
>
Ah, now i got it. Simply reloading the module kills the card with that nasty
do_IRQ thing (until reboot), but
-> 1) unloading module 2) suspending 3) resuming 4) loading module
actually works. It's kinda dirty solution (with some hackish script in
/etc/pm/sleep.d/), but it works somehow.
Perhaps someday there will be a better solution (power management?).
> Regards,
> Andy
Thanks for your time,
Boris
--
http://boris64.net 20xx ;)
signature.asc
Description: This is a digitally signed message part.
Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
Wednesday 15 December 2010 18:01:42 Russell King - ARM Linux wrote: > On Wed, Dec 15, 2010 at 12:39:20PM +, Catalin Marinas wrote: > > > > Should we not try to fix the generic code and still allow platforms > > to use dma_declare_coherent_memory() in a safer way? I guess it may > > need some arguing/explanation on linux-arch. > > I think so - Hi Russel, I've already started implementing what you've suggested, with an already working result, but have two questions: 1. Is it save to leave iounmap() being called on virtual addresses not obtained with ioremap()? This would make things less complicated. 2. Can I quote your full explanation, just like it looks below, in my commit message? Thanks, Janusz Wednesday 15 December 2010 18:01:42 Russell King - ARM Linux wrote: > ... one of the issues with dma_declare_coherent_memory() is > that it's original intention (as I understand it) was to allow > drivers to use on-device dma coherent memory. > > Eg, a network controller with its own local SRAM which it can fetch > DMA descriptors from, which tells it where in the bus address space > to fetch packets from. This SRAM is not part of the hosts memory, > but is on the peripheral's bus, and so ioremap() (or maybe > ioremap_wc()) would be appropriate for it. > > However, ioremap() on system RAM (even that which has been taken out > on the memory map) may be problematical. > > I think the correct solution would be to revise the interface so it > takes a void * pointer, which can be handed out by > dma_alloc_coherent() directly without the API having to worry about > how to map the memory. IOW, push the mapping of that memory up a > level to the caller of > dma_declare_coherent_memory(). > > We can then sanely do preallocations via dma_coherent_alloc() and > caching them back into dma_declare_coherent_memory() without creating > additional mappings which cause architectural violations. -- 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: DuoFlex CT PCIe
On 17 Dec 2010, at 18:23, PC12 Ching wrote: > Hello Bert > > I raised the same question two weeks ago, I only got an offline answer, see > below.$ > I hope to get some more replies too. > > -- > I wanted to know if the Digital Devices DuoFlex CT PCIe TWIN Combo DVB-C > DVB-T card is supported. I think this is related to the SatixS2 I have and uses the same driver, if so there is some support working, have a look at this thread: http://www.spinics.net/lists/linux-media/msg25462.html When I asked why the newer driver made 5 devices for a dual tuner the answer was because of support for the digital devices duoflex adaptors. Andre > This card has 2 Ports, using one PCIe slot. Additionally it can be extended > by 2 tuners to a total of 4 tuners, still using only one > PCIe slot. > There is also a Octopus version who is able to run 8 tuners using only one > PCIe slot. > > Is this card supported, is it performing well with 2/4 tuners ? > Will it be able to stream 4 HD channels at once via one PCIe slot ? The Satix S2 is happy to record 6 HD channels across two tuners, there are some small glitches when the second tuner changes freq but it's minor. I don't have any more channels in my subscription to test 8 HD! Andre-- 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
