[Kwintv] Re: v4l fix

[Dirk Ziegelmeier]

On Sunday 14 December 2003 22:33, Koos Vriezen wrote:
> Dirk wrote:
> > I'm familiar with races and locking concepts, but I currently have no
> > idea _why_ the qApp->lock() fixes the v4l plugin. All painting is now
> > done in the grabber thread with the event loop waiting. But what's the
> > difference between posting events (thread-safe) and copying a permanent
> > buffer into a widget from the event loop? And where is a race condition
> > in there???
>
> Note that in both cases painting is done while the event loop is waiting.
Errr... why? The old postEvent() _queues_ the event in the event queue, and 
the Qt event loop takes it from the queue and processes it. So painting is 
done in Qt's event loop. sendEvent() processes the event immediately, so 
painting is done in the grabber thread.

> My analyses was that the fatal io error occurs while doing
> a ioctl in V4LDev::grab or V4LDev::initGrabbing by the grabber thread and
> the main thread doing XvPutImage in KXvDevice::displayImage at the same
> time. I guess that the race is in accessing XVideo or v4l kernel module.
> (to really track this down would be to add a mutex on these I suppose and
> see if it helps - if so, async grabbing and painting will never work)
Hmmm. But why does it only happen on resize? The situation you describe should 
nearly always happen during normal playback. It must have something to do 
with the widget size change (the clipping was my favourite candidate until 
today, but it was not the cause).

Ciao,
Dirk

--
Dirk Ziegelmeier * dirk at ziegelmeier.net * http://www.ziegelmeier.net