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:
*segfault when trying to change device while device is open *segfault when trying to change driver while device is open *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 *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.
Secondary fixes (meaning these are byproducts of the aforesaid fixes):
*Both Mode 0 and Mode 1passed to pix_texture now works with DV devices.
Here are relevant patches with verbose comments/explanations:
src/Pixes/pix_videoNEW.cpp:
59a60,69
/* 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.
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.
Ico Bukvic ico@vt.edu 2-18-07 */ #ifdef HAVE_LIBDV if (m_videoHandle)m_videoHandle->stopTransfer(); #endif /* DV4L */
src/Pixes/videoDV4L.cpp:
174c174,191 < int fd = -1; ---
/* If video feed is already open and "device <something>" message is passed this will segfault Pd. Hence, we need to check if the device is already
open
before trying to open it again.
Ico Bukvic ico@vt.edu 2-18-07 */ if(m_haveVideo){ post("Stream already going on. Doing some clean-up..."); stopTransfer(); } /* All of the errors in this method return -1 anyhow, so fd should be 0 to
allow
successful open if everything goes ok.
Ico Bukvic ico@vt.edu 2-18-07 */ int fd = 0;
221a239,243
/*Extra verbosity never hurt anyone...
Ico Bukvic ico@vt.edu 2-18-07 */ post("DV4L: Successfully opened...");
After several hours of testing this on my machine, I am glad to report that these patches fix aforesaid symptoms without any detectable regressions.
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.
Should you happen to have any additional questions and/or concerns, please do not hesitate to contact me.
Best wishes,
*Ivica Ico Bukvic, D.M.A. *Composition, Music Technology, CCTAD, CHCI Virginia Tech Department of Music Blacksburg, VA 24061-240 (540) 231-1137 (540) 231-5034 (fax) ico.bukvic.net http://ico.bukvic.net/
Ivica Ico Bukvic wrote:
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:
thanks a lot, i'll have a look at them.
it would be great if you could post patches as attachments rather than inline (makes downloading so much easier)
,f.asdr IOhannes
Ivica Ico Bukvic wrote:
Here are some of the patches for the Gem tree for the videoDV4L devices.
and after looking(!) at the patches: would it be possible to post unified diffs? like: "diff -u videoDV4L.cpp.org videoDV4L.cpp > videoDV4L.patch" or "cvs diff -i videoDV4L.cpp > videoDV4L.patch"
mfga.sdr IOhannes
No problem. Wasn't sure if attachments were ok on this mailing list...
Please see attached (used diff -u as instructed below).
Best wishes,
Ico
On 2/19/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Ivica Ico Bukvic wrote:
Here are some of the patches for the Gem tree for the videoDV4L devices.
and after looking(!) at the patches: would it be possible to post unified diffs? like: "diff -u videoDV4L.cpp.org videoDV4L.cpp > videoDV4L.patch" or "cvs diff -i videoDV4L.cpp > videoDV4L.patch"
mfga.sdr IOhannes
hi.
thanks for the patches; this makes it much more easy for me.
Ivica Ico Bukvic wrote:
No problem. Wasn't sure if attachments were ok on this mailing list...
good reason. i think attachments are ok as long as they are small enough (BIG emails will hang in mailman).
as an alternative, you can post patches to the sourceforge tracker for gem, found at http://sourceforge.net/projects/pd-gem
fmga.sdr IOhannes
hi.
i have applied the change to videoDV4L, but i think the pix_vieoNEW.cpp-issue should be handled differently:
Ivica Ico Bukvic wrote:
+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.
+Ico Bukvic ico@vt.edu 2-18-07 +*/ +#ifdef HAVE_LIBDV
- if (m_videoHandle)m_videoHandle->stopTransfer();
+#endif /* DV4L */ }
this is weird and does not make full sense to me. e.g. if you have compiled Gem with v4l AND libdv support (2 drivers), then the stopTransfer() of the currently used handle will be called on destruction of the [pix_video] object. (this could as well be the V4L-handle; so the define does not exactly what it suggests that it might do)
i have replaced your suggestion by calling the destructor of all existing handles on destruction of pix_videoNEW.
please check whether this still fixes your issues.
fgmad.r IOhannes
+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.
+Ico Bukvic ico@vt.edu 2-18-07 +*/ +#ifdef HAVE_LIBDV
- if (m_videoHandle)m_videoHandle->stopTransfer();
+#endif /* DV4L */ }
this is weird and does not make full sense to me. e.g. if you have compiled Gem with v4l AND libdv support (2 drivers), then the stopTransfer() of the currently used handle will be called on destruction of the [pix_video] object. (this could as well be the V4L-handle; so the define does not exactly what it suggests that it might do)
i have replaced your suggestion by calling the destructor of all existing handles on destruction of pix_videoNEW.
please check whether this still fixes your issues.
I just checked out the CVS. Yes, your solution is more universal. I simply wasn't sure what were the implications without digging much deeper into the code so my proposed solution was simply a well isolated "hack" to expose the problem while limiting its impact on the overall functionality. Thanks for making this more transparent!
I will check this shortly and will let you know if it works as expected (I anticipate it will).
Best wishes,
Ico
Ugh... Tried recompiling updated CVS and now I keep getting
./Gem.pd_linux: undefined symbol: glUniform2i Gem: can't load library
What else was updated in that should've caused this problem?
Ico
On 2/19/07, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
+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.
+Ico Bukvic ico@vt.edu 2-18-07 +*/ +#ifdef HAVE_LIBDV
- if (m_videoHandle)m_videoHandle->stopTransfer();
+#endif /* DV4L */ }
this is weird and does not make full sense to me. e.g. if you have compiled Gem with v4l AND libdv support (2 drivers), then the stopTransfer() of the currently used handle will be called on destruction of the [pix_video] object. (this could as well be the V4L-handle; so the define does not exactly what it suggests that it might do)
i have replaced your suggestion by calling the destructor of all existing handles on destruction of pix_videoNEW.
please check whether this still fixes your issues.
I just checked out the CVS. Yes, your solution is more universal. I simply wasn't sure what were the implications without digging much deeper into the code so my proposed solution was simply a well isolated "hack" to expose the problem while limiting its impact on the overall functionality. Thanks for making this more transparent!
I will check this shortly and will let you know if it works as expected (I anticipate it will).
Best wishes,
Ico
The OpenGL driver is not fully compliant with version 2.0 of the spec. You can either get a newer driver or remove the glsl_ objects.
On 2/19/07, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
Ugh... Tried recompiling updated CVS and now I keep getting
./Gem.pd_linux: undefined symbol: glUniform2i Gem: can't load library
What else was updated in that should've caused this problem?
Ico
Just figured that one out... Apparently, ATI's fglrx drivers suck as they are apparently missing a huge chunk from the 2.0 spec:
glBlendEquationSeparate glDrawBuffers glStencilOpSeparate glStencilFuncSeparate glStencilMaskSeparate glAttachShader glBindAttribLocation glCompileShader glCreateProgram glCreateShader glDeleteProgram glDeleteShader glDetachShader glDisableVertexAttribArray glEnableVertexAttribArray glGetActiveAttrib glGetActiveUniform glGetAttachedShaders glGetAttribLocation glGetProgramiv glGetProgramInfoLog glGetShaderiv glGetShaderInfoLog glGetShaderSource glGetUniformLocation glGetUniformfv glGetUniformiv glGetVertexAttribdv glGetVertexAttribfv glGetVertexAttribiv glGetVertexAttribPointerv glIsProgram glIsShader glLinkProgram glShaderSource glUseProgram glUniform1f glUniform2f glUniform3f glUniform4f glUniform1i glUniform2i glUniform3i glUniform4i glUniform1fv glUniform2fv glUniform3fv glUniform4fv glUniform1iv glUniform2iv glUniform3iv glUniform4iv glUniformMatrix2fv glUniformMatrix3fv glUniformMatrix4fv glValidateProgram glVertexAttrib1d glVertexAttrib1dv glVertexAttrib1f glVertexAttrib1fv glVertexAttrib1s glVertexAttrib1sv glVertexAttrib2d glVertexAttrib2dv glVertexAttrib2f glVertexAttrib2fv glVertexAttrib2s glVertexAttrib2sv glVertexAttrib3d glVertexAttrib3dv glVertexAttrib3f glVertexAttrib3fv glVertexAttrib3s glVertexAttrib3sv glVertexAttrib4Nbv glVertexAttrib4Niv glVertexAttrib4Nsv glVertexAttrib4Nub glVertexAttrib4Nubv glVertexAttrib4Nuiv glVertexAttrib4Nusv glVertexAttrib4bv glVertexAttrib4d glVertexAttrib4dv glVertexAttrib4f glVertexAttrib4fv glVertexAttrib4iv glVertexAttrib4s glVertexAttrib4sv glVertexAttrib4ubv glVertexAttrib4uiv glVertexAttrib4usv glVertexAttribPointer
That being said, is there a way to force GL to be pre 2.0 even though the driver says otherwise? This way I would still have ARB version of those objects...
One way to do this is obviously to hand-edit Base/glew.h and remove mention of the GL 2.0, but there perhaps should be a more "elegant" way with a configure flag (I am a total newb when it comes to editing configure scripts, though).
Ico
One way to do this is obviously to hand-edit Base/glew.h and remove mention of the GL 2.0, but there perhaps should be a more "elegant" way with a configure flag (I am a total newb when it comes to editing configure scripts, though).
Well, I tried removing #define GL_VERSION_2_0 1 alltogether from Base/glew.h but that made no difference (I did make clean and distclean in between attempts). I even tried removing the whole GL_VERSION_2_0 section. Still no difference. Yet according to the glsl objects, if GL_VERSION_2_0 is not defined, it should never venture into the questionable parts of the code.
So, is there another way to impose this without losing those glsl objects?
Ico
Apologies for an apparent salvo of e-mails. Here's one proposed option. Hasn't been tested thoroughly but so far it appears to work ok:
--- GemGL.h~ 2006-09-26 05:56:33.000000000 -0400 +++ GemGL.h 2007-02-19 17:09:03.000000000 -0500 @@ -53,6 +53,9 @@ * so, if your system lacks GL/glext.h, * just undefine the appropriate line in Base/configNT.h */ + +#define GL_GLEXT_VERSION 21 + # if (!defined GL_GLEXT_VERSION) # include <GL/glext.h> # endif /* GL_GLEXT_VERSION */
(namely by adding GL_GLEXT_VERSION 21 which corresponds to OpenGL 1.5)
This would still keep ARB enabled in those files, rather than totally obliterating them...
This is however a brute force fix for buggy fglrx drivers. Would it be perhaps possible to have a configure option, i.e. --force-gl-1.5 or something like that which would define this variable in this particular place? As I mentioned earlier I am not too familiar with the configure scripts so if this is to be ok'd by Iohannes and others, I would greatly appreciate it if someone else did the part of integrating it.
Many thanks!
Best wishes,
Ico
Ivica Ico Bukvic wrote:
Apologies for an apparent salvo of e-mails. Here's one proposed option. Hasn't been tested thoroughly but so far it appears to work ok:
--- GemGL.h~ 2006-09-26 05:56:33.000000000 -0400 +++ GemGL.h 2007-02-19 17:09: 03.000000000 -0500 @@ -53,6 +53,9 @@
- so, if your system lacks GL/glext.h,
- just undefine the appropriate line in Base/configNT.h
*/
+#define GL_GLEXT_VERSION 21
# if (!defined GL_GLEXT_VERSION) # include <GL/glext.h> # endif /* GL_GLEXT_VERSION */
(namely by adding GL_GLEXT_VERSION 21 which corresponds to OpenGL 1.5)
This would still keep ARB enabled in those files, rather than totally obliterating them...
This is however a brute force fix for buggy fglrx drivers. Would it be perhaps possible to have a configure option, i.e. --force-gl-1.5 or
yes it is a good idea. i will add something like this.
mfg.asdr IOhannes
IOhannes m zmoelnig wrote:
This is however a brute force fix for buggy fglrx drivers. Would it be perhaps possible to have a configure option, i.e. --force-gl-1.5 or
yes it is a good idea. i will add something like this.
i have no added a "--with-glversion=X.Y" flag to configure, which allows you to specify the maximum openGL-version you want (possibly lowering the version found in the headers). running configure with "--with-glversion=1.5" should produce an openGL-1.5 compatible binary. since my drivers do support openGL-2.0, please test whether this works.
apart from that: i think Gem now supports all versions of openGL, down to 1.0. should we require a minimum version of openGL? this might tidy up the code (esp. in pix_texture) a bit. which version could this be? is windows-openGL still 1.2 or was it 1.3? which platforms might get unsupported if we require at least 1.2 (better 1.3)?
mfg.asdr IOhannes
Many thanks!
Ico
-----Original Message----- From: gem-dev-bounces@iem.at [mailto:gem-dev-bounces@iem.at] On Behalf Of IOhannes m zmoelnig Sent: Tuesday, February 20, 2007 5:13 AM Cc: gem-dev@iem.at Subject: Re: minimum openGL version (waas Re: [GEM-dev] Gem patches to fixDV4L bugs and crashes)
IOhannes m zmoelnig wrote:
i have no added a "--with-glversion=X.Y" flag to configure, which
allows
this should read: "i have now added"
mfg.asdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
As promised, here's the final report on the merged patches:
1) the proposed alteration to the pix_videoNEW.cpp fix works perfectly.
2) merged patches in the videoDV4L.cpp are ok too except that stderr message "dropped at least n frames" does not have a newline at the end now that it is being routed to stderr, resulting in a less legible output. I am currently away from my Linux box so here's the excerpt from the online CVS browser:
videoDV4L.cpp: 102 if (dvst.dropped_frames > 0) { 103 fprintf(stderr,"dv1394: dropped at least %d frames.", dvst.dropped_frames); 104 }
Line 103 needs to have a \n after "frames."
3) the proposed hack to force OpenGL 1.5 also works like a charm thus keeping at least the ARB functions in the glsl files available (not sure if this makes any difference but IMHO it sure seems to me better way than deleting files prior to compiling). It would be nice to have this included as a configure flag since fglrx drivers continue to lack a list of 2.0 specs. For more info on this topic, please see my previous e-mail.
Many thanks for all the help!
Best wishes,
Ico
-
chris clepper -
IOhannes m zmoelnig -
Ivica Ico Bukvic