I am trying to take some guess work out of debugging cameras and firewire cards. I need some help from a C hacker.
Every so often something odd happens that makes me question if all of my equipment works. So I am trying to come up with good ways of testing it. In doing so I have discovered that when I remove a firewire EC card it takes the kernel 12 seconds to destroy the /dev/fw node. I have a feeling if I plug in some other device during that time bad things happen. I also have a feeling if a camera is plugged into the card when I insert the card, more badness. maybe. I haven't gotten that far in any sort of formal testing because I cam still trying to get a grip on what really works. I now have some udev rules that beep when the kernel is doing stuff, which I think will help keep my testing sane. I don't really care what happens if I un/plug a card really fast. I just want for all the beeps to stop, then I know it is safe. I have been running a test that Clemens Ladisch <[email protected]> wrote http://www.alsa-project.org/~clemens/async-test.c Stefan Richter <[email protected]> suggested some changes that I made: https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c Wrapped with fw_test.sh and I have been able to figure out that one of my laptops will not work with any firewire pccard. So that is progress. I won't bring that laptop to a show, it will never cause me to say WTF again. I asked Clemens >> Any reason not to add it to http://code.google.com/p/jujuutils/ (also his code) > It's not yet user-friendly enough. Yeah, it could use some love. Which is why I am posing here: My C skills are not up to this. It currently needs to be run twice: 1 to listen, 2nd to send. to see the output from both apps I do some crazy stuff with detached screen and xterm. it should do both send and receive in one instance. fw_test.sh sends in one direction till I hit enter, then sends in the other direction. (the broken laptop only fails in one direction, so this is needed.) It should concurrently send in both directions. And it tests async transfers, but dv cams are isochronous (or so I was told, I think) Here is some more Stefan comments on this project: http://sourceforge.net/mailarchive/message.php?msg_id=27577985 Anyway, I think everyone on this list knows what would help, so if anyone can produce something I would really appreciate it. I'll do what I can to test and debug, but doing the real work is not something I am suited for. maybe make python bindings :) -- Carl K
_______________________________________________ Debconf-video mailing list [email protected] http://lists.debconf.org/mailman/listinfo/debconf-video
