possible progress on XO-1 camera issues

[Peter Robinson]

On Thu, Dec 17, 2009 at 2:47 PM, César D. Rodas
<crodas at paraguayeduca.org> wrote:
> Hi Peter,
> On Thu, 2009-12-17 at 14:18 +0000, Peter Robinson wrote:
>> Hi César,
>>
>> >> > The problem with the camera seems to be the xf86-video-geode package.
>> >> > The cafe_ccic module is loaded automatically. Cheese and recordactivity
>> >> > crashed right before show any picture. Then I tested remotely with ssh
>> >> > -X and it worked for olpc and root user and it works.
>> >> >
>> >> > This test was done with:
>> >> >
>> >> >      * XO-1 kernel: 2.6.31_xo1-20091214.1334.1.olpc.49c30d0
>> >> >      * os10
>> >> >
>> >> > Even if it works remotely, there are a lots of warning messages on
>> >> > the /var/log/messages:
>> >>
>> >> The gstreamer pipeline i used on the command line to take a photo is:
>> >>
>> >> gst-launch-0.10 v4l2src ! ffmpegcolorspace ! pngenc ! filesink
>> >> location=foo.png
>> > It works perfectly fine, thanks for your help.
>> >
>> > It seems to be that X is having a hard time displaying the video feed
>> > for some reason I can't discover (yet). I took a look at
>> > the /var/log/Xorg.0.log file (while attempting to run cheese) and it
>> > said:
>> >
>> > "Could not allocate memory for the video"
>> >
>> > That's why it worked remotely before (apparently). I also tried loading
>> > extra modules in xorg.conf (the ones that are loaded in the XO-1.5
>> > config) but no go.
>> >
>> > I'm looking forward to read clues about how to fix it.
>>
>> It sounds suspiciously like a Xv issue. That could be anything from a
>> missing kernel module to a X driver bug. Out of interest can you play
>> video using totem? Possibly record a video using a XO-1 with the
>> working 802 build and see if it will play on one with the F11 build.
>> That would rule out that issue, or possibly we could craft up a
>> gstreamer pipeline that takes the output of the camera and displays it
>> on the screen. Let me know how you go with the totem test and then
>> we'll see where we can take it from there, if that works I can work
>> out what the pipeline would need to be to test that raw.
>
> Well, I've tried what you've suggested me, and it has the same problem.
>
> $ totem /media/34F7-79FD/11-Music-Painter\ \(medium\).ogg
>
> Gdk-ERROR **: The program 'totem' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadAlloc (insufficient resources for operation)'.
>  (Details: serial 101 error_code 11 request_code 131 minor_code 19)
>  (Note to programmers: normally, X errors are reported asynchronously;
>   that is, you will receive the error a while after causing it.
>   To debug your program, run it with the --sync command line
>   option to change this behavior. You can then get a meaningful
>   backtrace from your debugger if you break on the gdk_x_error()
> function.)
> aborting...
> aborted
>
>
> Is this output helping somehow? Is there a way I can help out to fix it?

Yes, it looks like an X bug. I had a similar issue previously with
another X driver. To get a proper backtrace using GDB can you do the
following, this will then allow us to file a bug.

Run gdb and then from the gdb prompt run the following commands. If
gdb isn't installed you'll need to do a 'yum install -y gdb'. You'll
probably need to install quite a few debuginfo packages to ensure we
get a useful backtrace but if you post the backtrace first we can work
out what we need.

(gdb) exec-file totem --sync
(gdb) break gdk_x_error()
(gdb) r

You'll then get totem come up. Try and play the video as before and
you'll have it crash. The run the following with gdb

(gdb) thread apply all bt

and paste the complete output into a file and put it somewhere I can
see it (it might be somewhat large). You can see a sample one from an
issue I had with the nouveau driver previously here
https://bugzilla.redhat.com/attachment.cgi?id=369702

And we'll see where we need to go from there.

Cheers,
Peter