Hey, I tried my camera logitech quickcam e2500 (046d:089d) with ekiga and its working. As i had read in a thread, i installed libv4l and then used the instruction: LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
However its still not working with gridflow , infact when i select and device #0 to#7 in #camera it causes PD to crash. Now what?
Sisil.
On running dmesg this is what i found: for the camera: [ 11.713178] gspca: main v2.3.0 registered [ 11.724021] gspca: probing 046d:089d [ 11.724024] zc3xx: Sensor MC501CB [ 11.729220] gspca: probe ok [ 11.729230] gspca: probing 046d:089d [ 11.729239] gspca: probing 046d:089d [ 11.729261] usbcore: registered new interface driver zc3xx [ 11.729264] zc3xx: registered [ 11.733789] synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume [ 11.798591] usbcore: registered new interface driver snd-usb-audio
for the pd crash: [ 1694.021521] btusb_send_frame: hci0 urb f5cd6200 submission failed [ 2318.464312] CE: hpet increasing min_delta_ns to 22500 nsec [ 4483.504429] CE: hpet increasing min_delta_ns to 33750 nsec [ 6333.403769] pd[31018]: segfault at 4 ip b74f25dc sp bffa0e70 error 6 in libstdc++.so.6.0.10[b7439000+e4000] [ 6389.806394] pd[31100]: segfault at 4 ip b74d95dc sp bf987c90 error 6 in libstdc++.so.6.0.10[b7420000+e4000] [ 6545.228881] pd[31220]: segfault at 461 ip b70d22eb sp bfa37830 error 4 in gridflow.pd_linux[b7058000+30b000] [ 7255.056889] pd[31866]: segfault at 0 ip b717a2eb sp bfcddad0 error 4 in gridflow.pd_linux[b7100000+30b000] [ 7830.520891] pd[32375]: segfault at 4 ip b75c25dc sp bff70e40 error 6 in libstdc++.so.6.0.10[b7509000+e4000
On Fri, Aug 7, 2009 at 2:54 AM, sisil mehta sisilmet2000@gmail.com wrote:
Hey, I tried my camera logitech quickcam e2500 (046d:089d) with ekiga and its working. As i had read in a thread, i installed libv4l and then used the instruction: LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
However its still not working with gridflow , infact when i select and device #0 to#7 in #camera it causes PD to crash. Now what?
Sisil.
On Fri, 7 Aug 2009, sisil mehta wrote:
[ 6389.806394] pd[31100]: segfault at 4 ip b74d95dc sp bf987c90 error 6 in libstdc++.so.6.0.10[b7420000+e4000] [ 6545.228881] pd[31220]: segfault at 461 ip b70d22eb sp bfa37830 error 4 in gridflow.pd_linux[b7058000+30b000]
This is probably related to the ATI driver conflict we just talked about, unfortunately. The quick fix is to make sure Gem is not loaded (nor any other OpenGL thing), but when you actually need Gem to be loaded, it's a bit complicated.
What the conflict does, is turn every error message of GridFlow into a crash. Therefore if you fix this, then you will see GridFlow's error messages correctly and will see what's wrong.
(You can actually see those messages using gdb too, but it's a lot less cumbersome to remove the conflict first.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
umm i'm using pd-extended 0.41.4 . So in this case apart from gem which lib uses opengl ??
Sisil
On Sat, Aug 15, 2009 at 9:59 PM, Mathieu Bouchard matju@artengine.cawrote:
On Fri, 7 Aug 2009, sisil mehta wrote:
[ 6389.806394] pd[31100]: segfault at 4 ip b74d95dc sp bf987c90 error 6 in
libstdc++.so.6.0.10[b7420000+e4000] [ 6545.228881] pd[31220]: segfault at 461 ip b70d22eb sp bfa37830 error 4 in gridflow.pd_linux[b7058000+30b000]
This is probably related to the ATI driver conflict we just talked about, unfortunately. The quick fix is to make sure Gem is not loaded (nor any other OpenGL thing), but when you actually need Gem to be loaded, it's a bit complicated.
What the conflict does, is turn every error message of GridFlow into a crash. Therefore if you fix this, then you will see GridFlow's error messages correctly and will see what's wrong.
(You can actually see those messages using gdb too, but it's a lot less cumbersome to remove the conflict first.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Sat, 15 Aug 2009, sisil mehta wrote:
umm i'm using pd-extended 0.41.4 . So in this case apart from gem which lib uses opengl ??
uh... that would be 3DP (from PDP) and the OpenSceneGraph plugins... and any GEM plugins that aren't part of GEM... I don't know what else. You could use the "ldd" command in the shell, to find out, like
ldd *.pd_linux
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Sat, Aug 15, 2009 at 12:47 PM, sisil mehtasisilmet2000@gmail.com wrote:
umm i'm using pd-extended 0.41.4 . So in this case apart from gem which lib uses opengl ??
I would suggest that for debugging purposes you start with pd-vanilla, so:
$sudo mv /usr/lib/pd/default.pdsettings /usr/lib/pd/default.pdsettings.bak
And if you created some custom settings you may have .pdsetting and/or .pdrc in your $HOME
$mv ~/.pdsettings ~/pdsettings.bak $mv ~/.pdrc ~/pdrc.bak
Following that, pd should start only with internals and no 3rd party objects. Then you simply do pd -path /path/to/gf/ -lib gridflow and take it from there.
And only then you start adding other libraries/externals until you find the conflicting setup.
./MiS
On Sun, 16 Aug 2009, Michal Seta wrote:
I would suggest that for debugging purposes you start with pd-vanilla, so: $sudo mv /usr/lib/pd/default.pdsettings /usr/lib/pd/default.pdsettings.bak And if you created some custom settings you may have .pdsetting and/or .pdrc in your $HOME $mv ~/.pdsettings ~/pdsettings.bak $mv ~/.pdrc ~/pdrc.bak
I should stress out that the leading "$" isn't part of the command!
I remember a beginners' intro to unix that prefixed every command with "%" in bold (the csh prompt). Some people actually retyped the "%" and got frustrated over it! But in that case, there was a space after the prompt character so it was more recognisable as such, than $mv. Frankly, I can imagine a script that has $sudo and $mv written in it for real and for a reason, which is the reason I decided to talk about this rather than not.
Following that, pd should start only with internals and no 3rd party objects. Then you simply do pd -path /path/to/gf/ -lib gridflow and take it from there. And only then you start adding other libraries/externals until you find the conflicting setup.
Yeah, but if you don't want to do it blindly with trial and error, then you gotta use the «ldd» commands on all externals, and then «|grep libGL» on that.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hey, I've only loaded the gridflow library in the beginninng....no other libs.
on the other thread by me discussing the crashing problem, i had updated the GF from svn as mathieu suggested, and it still crashed. i again ran the where and backtrace full commands and attached the new results in that thread.
Sisil.
On Sun, Aug 16, 2009 at 8:52 PM, Mathieu Bouchard matju@artengine.cawrote:
On Sun, 16 Aug 2009, Michal Seta wrote:
I would suggest that for debugging purposes you start with pd-vanilla, so: $sudo mv /usr/lib/pd/default.pdsettings /usr/lib/pd/default.pdsettings.bak And if you created some custom settings you may have .pdsetting and/or .pdrc in your $HOME $mv ~/.pdsettings ~/pdsettings.bak $mv ~/.pdrc ~/pdrc.bak
I should stress out that the leading "$" isn't part of the command!
I remember a beginners' intro to unix that prefixed every command with "%" in bold (the csh prompt). Some people actually retyped the "%" and got frustrated over it! But in that case, there was a space after the prompt character so it was more recognisable as such, than $mv. Frankly, I can imagine a script that has $sudo and $mv written in it for real and for a reason, which is the reason I decided to talk about this rather than not.
Following that, pd should start only with internals and no 3rd party
objects. Then you simply do pd -path /path/to/gf/ -lib gridflow and take it from there. And only then you start adding other libraries/externals until you find the conflicting setup.
Yeah, but if you don't want to do it blindly with trial and error, then you gotta use the «ldd» commands on all externals, and then «|grep libGL» on that.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Mon, 17 Aug 2009, sisil mehta wrote:
I've only loaded the gridflow library in the beginninng....no other libs. on the other thread by me discussing the crashing problem, i had updated the GF from svn as mathieu suggested, and it still crashed. i again ran the where and backtrace full commands and attached the new results in that thread.
I just thought about some other possible fix that I never tried. Run this command in the same shell used to start pd, before starting pd:
export LD_PRELOAD=/usr/lib/libstdc++.so
don't use this exact command, use it for each version of the lib you have. e.g. on my computer, I'd try:
export LD_PRELOAD=/usr/lib/libstdc++.so.5 pd examples/nervous_video.pd export LD_PRELOAD=/usr/lib/libstdc++.so.6 pd examples/nervous_video.pd
maybe I'm completely mistaken about LD_PRELOAD, or that I'm missing something else, but I can't test it at the moment.
But even if this happens to work, I'd still rather have a tweak that I'd do to GridFlow so that users don't have to do it at all.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hmm...i'll try this in the morning (and also the other method u had stated before ....)
On Wed, Aug 19, 2009 at 1:52 AM, Mathieu Bouchard matju@artengine.cawrote:
On Mon, 17 Aug 2009, sisil mehta wrote:
I've only loaded the gridflow library in the beginninng....no other libs.
on the other thread by me discussing the crashing problem, i had updated the GF from svn as mathieu suggested, and it still crashed. i again ran the where and backtrace full commands and attached the new results in that thread.
I just thought about some other possible fix that I never tried. Run this command in the same shell used to start pd, before starting pd:
export LD_PRELOAD=/usr/lib/libstdc++.so
don't use this exact command, use it for each version of the lib you have. e.g. on my computer, I'd try:
export LD_PRELOAD=/usr/lib/libstdc++.so.5 pd examples/nervous_video.pd export LD_PRELOAD=/usr/lib/libstdc++.so.6 pd examples/nervous_video.pd
maybe I'm completely mistaken about LD_PRELOAD, or that I'm missing something else, but I can't test it at the moment.
But even if this happens to work, I'd still rather have a tweak that I'd do to GridFlow so that users don't have to do it at all.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec