Re: iSight camera, debian squeeze libdc1394 2.1.3: YUV format problem?
Dear All,
thanks for the help (especially Stefan Richter) to debug my iSight
camera earlier this year.
FWIW, I discovered after nearly a month of failures that the camera
itself was faulty. I eliminated several possibilities: even the cable
was tested for functionality.
I was glad for the in depth introduction to the library, as it is now
one of my more reliable tools.
Thanks for a nice product.
Cheers,
Max
Stefan Richter <stefanr@...> a écrit :
> On Aug 04 Max BLANCO wrote:
>> Stefan,
>>
>> I have the newer firewire drivers. The older ones were not in my
>> debian kernel.
>
> If i find the time, I can try to boot one of my machines into stock 2.6.32
> and see what that does to reception from my iSight then.
>
>> I have now tried to make kernel 3.0 and 2.6.38.8 downloaded today from
>> kernel.org. Both failed at boot time with kernel panics.
>
> You can
> - find out where the panic comes from (one often encountered problem is
> that the root filesystem cannot be mounted because a device driver or
> filesystem driver is missing in the kernel image, or in the initrd if
> you use one),
> or
> - install a prebuilt Debian kernel package that is either much newer
> than 2.6.32 or contains the ieee1394 driver stack or both,
> or
> - build ieee1394 and friends from Debian's 2.6.32 sources with the exact
> same configuration of your current installed 2.6.32 kernel image
> except with the ieee1394 related options switched on.
>
> Oh wait, you already did the latter:
>
>> I have attempted to make the modules with the 2.6.32 kernel source and
>> transfer the modules to the working kernel /lib/modules area by hand.
>> When I try to use the old modules with the dc1394 examples, the
>> library fails to initialise, even though I ./configure'd it before I
>> make'd it. I'm at wit's end right now with this.
>
> In which way does it fail to initialize?
>
> Check that ieee1394, ohci1394, video1394, raw1394 are loaded into your
> kernel, that firewire-ohci and firewire-core were unloaded from the kernel
> before that, IOW that ohci1394 appears in /proc/interrupts, that no
> outright errors from the 1394 drivers are logged in /var/log/messages,
> that /sys/bus/ieee1394/devices/ contains entries for the controller and
> multiple entries for the iSight when it is attached, that /dev/video1394-*
> or /dev/video1394/* exist and your account has permission to access them,
> and that /dev/raw1394 exists and your account has permission to access it.
>
>> Xv is likely not the problem. The failure is the same when I use the
>> non-Xv example programs.
>
> Well, right you are.
>
>> I think the problem lies elsewhere, or _you_ wouldn't have failure
>> with grab_color_image but success with grab_color_image2. Check the
>> source code for each. Why does the former malfunction?
>
> Because grab_color_image knows only of a single specific video mode which
> the iSight does not implement. We can and should ignore grab_color_image
> together with iSight here.
>
>> I would like
>> to see your output (offlist?) when it malfunctions. If possible, take
>> reproducible images like of an all-red and/or all-blue image.
>
> FWIW, I will send you a sample from grab_color_image and grab_color_image2
> off-list.
> --
> Stefan Richter
> -=====-==-== =--- --=--
> http://arcgraph.de/sr/
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
RSS Feed