On Wed, 27 Oct 2010 16:23:10 +0100 Daniel Drake <[email protected]> wrote:
> Testing with clean linux-next as of today. 2 via-camera issues: If that's all that goes wrong we've come a fair ways...:) > 1. Approx 13 "VIA DMA timeout!" messages are printed every second That seems undesirable. In the past there was trouble with the user-space xv code mucking around with the interrupt control registers, but I *thought* that had been fixed. One could try lengthening the msleep() call right before that message (it's in via-core.c), but that shouldn't really be necessary. > 2. If you start a capture with "gst-launch v4l2src ! xvimagesink" then > change to a VT console then back to X, the display stops updating > properly - it seems to have locked itself onto a few frames from > before the VT switch happened, and plays them in an endless loop > Also happens with "gst-launch v4l2src ! ffmpegcolorspace ! ximagesink" I thought I had tried that, but, evidently not. Something in the framebuffer switch code is clearly interfering with the video capture engine, it would be nice to figure out what that is. If you're capturing to a file, you'd really want that to survive a switch. This will be something deep in the viafb code. Will take a bit of digging; I don't know much about how VT switch actually works. My guess is it's mucking with a register it shouldn't be. I can take a look at both, but not before KS/Plumbers. jon _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
