Here are some of the patches for the Gem tree for the videoDV4L devices. All of the below are Linux-specific unless stated otherwise. Problems fixed include:<br><br>*segfault when trying to change device while device is open
<br>*segfault when trying to change driver while device is open<br>*fix misreporting error of the fd init error in the openDevice method which prevented startTransfer from operating properly and consequently resulting in previous 2 crashes
<br>*fix proper disengagement of the capturing thread when a patch is forcefully closed which resulted in DV device being busy on subsequent "open" attempts and/or crashes listed above. This fix may be applicable to opening of other devices as well (definitely on Linux, possibly also on other OS's). However, since I do not have any V4L devices handy, this fix was provided with the most restrictive ifdef available (have DV4L) so as to prevent possible regressions to other parts of the code.
<br><br>Secondary fixes (meaning these are byproducts of the aforesaid fixes):<br><br>*Both Mode 0 and Mode 1passed to pix_texture now works with DV devices.<br><br>Here are relevant patches with verbose comments/explanations:
<br><br>src/Pixes/pix_videoNEW.cpp:<br><br>59a60,69<br>> /*<br>> It appears that Gem fails to close video thread if a patch is closed immediately after having been opened with loadbangs in place to set up pix_video object. Same goes for patches which are opened, Gem window is created and then closed before Gem window is destroyed.
<br>> <br>> NB: It is very likely that it may be necessary for this method to exist for other types of video devices, but since I was unable to test them, I've put it under the most restrictive ifdef available.<br>
> <br>> Ico Bukvic <a href="mailto:ico@vt.edu">ico@vt.edu</a> 2-18-07<br>> */<br>> #ifdef HAVE_LIBDV<br>> if (m_videoHandle)m_videoHandle->stopTransfer();<br>> #endif /* DV4L */<br><br><br><br><br><br>
src/Pixes/videoDV4L.cpp:<br><br>174c174,191<br>< int fd = -1;<br>---<br>> /*<br>> If video feed is already open and "device <something>" message is passed<br>> this will segfault Pd. Hence, we need to check if the device is already open
<br>> before trying to open it again.<br>> <br>> Ico Bukvic <a href="mailto:ico@vt.edu">ico@vt.edu</a> 2-18-07<br>> */<br>> if(m_haveVideo){<br>> post("Stream already going on. Doing some clean-up...");
<br>> stopTransfer();<br>> }<br>> /*<br>> All of the errors in this method return -1 anyhow, so fd should be 0 to allow<br>> successful open if everything goes ok.<br>> <br>> Ico Bukvic
<a href="mailto:ico@vt.edu">ico@vt.edu</a> 2-18-07<br>> */<br>> int fd = 0; <br>221a239,243<br>> /*Extra verbosity never hurt anyone...<br>> <br>> Ico Bukvic <a href="mailto:ico@vt.edu">ico@vt.edu</a>
2-18-07<br>> */<br>> post("DV4L: Successfully opened...");<br><br>After several hours of testing this on my machine, I am glad to report that these patches fix aforesaid symptoms without any detectable regressions.
<br><br>So, given that I do not have dev access, I was wondering if any of the users with dev access would be so kind as to test and upload these to the Gem CVS.<br><br>Should you happen to have any additional questions and/or concerns, please do not hesitate to contact me.
<br><br>Best wishes,<br><br><strong><span style="font-weight: normal;">Ivica Ico Bukvic, D.M.A.</span><br>
</strong>Composition, Music Technology, CCTAD, CHCI<br>
Virginia Tech<br>
Department of Music<br>
Blacksburg, VA 24061-240<br>
(540) 231-1137<br>
(540) 231-5034 (fax)
<br>
<a href="http://ico.bukvic.net">ico.bukvic.net</a><a href="http://ico.bukvic.net/"></a><br>