As I suspected, issue is much more acute. I just tried the identical setup on vanilla FC6 and it exhibits *exactly* the same problem (Kino works, but Gem doesn't using the same ieee1394 device, namely ADVC-100). So, now we have Dapper, Edgy, and FC6 for sure having this problem and I would not be surprised to hear that there are more recent distros which exhibit this issue (Debian for sure due to its relationship to Ubuntu).

Regarding your questions Studio, please see my previous e-mails, they are pretty verbose as to what is missing and/or what is the behavior. FWIW, I do not have /dev/dv1394-0, but rather /dev/dv1394/0 device. This is the case on both FC6 and Ubuntu. The problem is exhibited via pd-extended install, totally from scratch source install (mine on Ubuntu had everything yes except for libmpeg1 and ffmpeg; libmpeg3 was also yes), and now also the CCRMA build.

This may seem that newer udev plus latest ieee1394 libs/drivers are at odds with the Gem way of addressing them.  I have traced the problem down to Gem/src/Pixes/videoDV4L.cpp which deals with dv1394 device and from which all of the errors come. Commenting any of the tripwires simply triggers the next one ( i.e. closed error, then ioctl WAIT_FRAMES, then ioctl GET_STATUS, etc.). Commenting all "return NULL" evokes these errors on every frame flodding the shell. I could probably take a stab on this one if I knew more about ieee1394 and more precisely dv1394 stuff but I don't. Learning so would take way too much time and more importantly it would be redundant as I am sure the community already has those who are well-versed in this area. I will, however, gladly provide necessary access/feedback and even code provided I am given some help in understanding dv1394 stuff so that the code is altered accordingly.

I hope you will agree with me that this is a pretty big deal as it will preclude use of dv1394 in conjunction with Gem without exceptions until this issue is resolved. My plea is please push this to the top of the TODO list and I'll do all I can to assist in resolving the issue.

Many thanks!

Best wishes,

Ico

On 12/28/06, Studio Zodiak <studiozodiak@yahoo.ca> wrote:
This is interesting.
Like I said before,
I asked this list before with the same problem.

maybe we can share info.
 
Are you compiling Gem?

I have used the compiling options --with-ieee1394-includes
and --with-ieee1394-libs
-I don't know where to set the libs thaugh- /usr/lib/?

Anyway, at the end of the configure, I get no for the ieee1394 option.

even disabling v4l is not doing much.

I went on the ieee1394 website and saw that the api relies on two libraries.

Just for you information,
last time I succeeded in making my dvcamera work with Gem on linux was on red hat 9.

This I have tried on breezy and dapper with no success.

I grepped for /dev/ieee1394 in the Gem's src directory and found that it is supposed to default to ieee1394 from v4l (is this correct?).

I remember having to send a driver 1 message to pix_video like on a mac.

Only on my Edgy machine the repertoire is /dev/ieee1394-0

could one do as such perhaps?

1. ln -s /dev/ieee1394 /dev/ieee1394-0

2. permissions

Anyway, just my 2 cents for now.

Sylvain







Ivica Ico Bukvic <ico.bukvic@gmail.com> wrote:
> Despite those thoughts I still haven't had a look at unicap yet, still too
> many other things TODO first.

Well, I just wasted another 2 hours trying to get my 5+ (!) year old webcam
working which is still unsupported in Linux (intel pocket pc cam cs780, even
though CS630 and CS430 are supported). Ironically, in Windoze everything
"just worked."

Based on my tests I am suspecting that this is a lib/distro-independent
issue, and as such am also wondering what will happen with pd/gem on Linux
in 6 months when most of the other distros pump out their next release with
libs similar to Edgy (maybe some of them already are?) leaving gem video for
all intents and purposes broken. I also looked at the videojack project
Mathieu pointed out and it really looks, well, promising, but it is by no
means a complete and/or well supported product despite its huge potential.
Perhaps this video issue should be bumped higher on the gem TODO list given
the current situation?

Thanks for all your help!

Best wishes,

Ico


_______________________________________________
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com