Hey David,
On Tue, 2003-02-11 at 21:24, David J. Topper wrote:
> If I don't join the thread, I get an Xlib error:
>
> Xlib: unexpected async reply (sequence 0xb4b)!
>
> of course the "sequence" changes. Yes, I am using the gtk_thread_init()
> call and the rest. There is no sharing of data in my app (yet) so it's
> not a mutex issue.
You're sharing the X display connection. Really, read the Gtk+ FAQ, it
has lots of info on this. "Do display processing only from one thread or
use mutexes". I sincerely recommend the first.
> 2. gdk_input_add case
> ----------------------
>
> If I set the following:
>
> fd = open("/dev/video",O_RDONLY);
>
> gdk_input_add(fd,
> GDK_INPUT_READ,
> GTK_SIGNAL_FUNC(read_video),
> NULL);
>
> NOTHING HAPPENS!!!!
[..]
> I've tested out this method w/o rendering the video to a window ... same
> problem. So it has something to do with the actual reading / polling of
> the video device.
Well, yes. Have you looked at the v4l API? First queue buffers, then you
can select()/poll() it (which is - I believe - what gdk_input_add() and
g_source_add() (same function, actually) do). Then, on response, sync on
the buffer.
this solution is actually much nicer than the first one, though it
requires BTTV-0.8/9.x.
Code looks like this (pseudocode):
--
read_func () {
static int buf = 0;
/* sync */
sync_buffer(buf); /* VIDIOCSYNC */
/* process data */
process_data(pointer_to_buffer, buf);
/* requeue buffer */
queue_buffer(buf); /* VIDIOCMCAPTURE */
/* and prepare for the next one */
buf++;
}
function1 () {
int num_buffers=..; /* you actually get this by doing VIDIOCCGMBUF) */
int n;
for (n=0;n=num_buffers;n++) {
queue_buffer(buf); /* VIDIOCMCAPTURE */
}
g_source_add(fd, blabla, (GSourceFunc) read_func, NULL);
}
--
This should be easily converted into something that compiles && works.
HTH,
Ronald
--
Ronald Bultje <rbultje@xxxxxxxxxxxxxxxxxxx>
Linux Video/Multimedia developer
