Hi Kids!
Time for a new adventure. I would like to have a working firewire camera input for manipulation in Gem on a linux box that is sitting here purring at me. The cam works fine with Kino and dvgrab, so the linux-firewire connection is all well.
But I am having no luck with pix_video or pdp_v4l. The main problem seems to be that (apparently) recently the naming conventions in debian and possibly linux in general were changed. So there is no more /dev/video0 for the v4l mode, and for pix_video trying to work directly with ieee1394, I get complaints that /dev/ieee1394/dv/ host/PAL/in "Is a directory".
Has anyone had more luck? Do I need to going from stable to testing in some parts of debian? Do I need to use some special somethings?
Looking forward to the d'Oh moment,
Tim
Hallo!
But I am having no luck with pix_video or pdp_v4l. The main problem seems to be that (apparently) recently the naming conventions in debian and possibly linux in general were changed. So there is no more /dev/video0 for the v4l mode, and for pix_video trying to work directly with ieee1394, I get complaints that /dev/ieee1394/dv/ host/PAL/in "Is a directory".
Yes we had this discussion quite some time ago: I think you can open the device with sending the message [driver /dev/ieee1394/dv/host/PAL/in( (fill in your device) to [pix_video]. If not let me know, then the fix was not added ...
LG Georg
Hi Georg,
Thanks for your reply. When you say "quite some time ago" when was that approximately? I see that in Dec 06 Ico Bukvic was having the same problem, but the thread stops on the PD list.
Anyway, I tried your suggestion.
When I try this I get "Bad argument for message 'driver' to object
'pix_videoNEW'"
Seeing as when I send |driver 1( to pix_video I receive the error message that refers to /dev/ieee1394/dv/host0/PAL/in, or host1 if I have send |device 1( message, then I would guess that the external is trying to do the right thing.
I must mention that /dev/ieee1394 does not even exist in my hierarchy. Perhaps something has not been created for this.
However, Kino and dvgrab work "out of the box" so the basics are all working fine. Only PD is trying to do the wrong thing.
Hmmm, any further ideas?
Cheers,
tim
On 15/08/2007, at 8:07 AM, Georg Holzmann wrote:
Hallo!
But I am having no luck with pix_video or pdp_v4l. The main problem seems to be that (apparently) recently the naming conventions in debian and possibly linux in general were changed. So there is no more /dev/video0 for the v4l mode, and for pix_video trying to work directly with ieee1394, I get complaints that /dev/ieee1394/ dv/ host/PAL/in "Is a directory".
Yes we had this discussion quite some time ago: I think you can
open the device with sending the message [driver /dev/ieee1394/dv/ host/PAL/in( (fill in your device) to [pix_video]. If not let me
know, then the fix was not added ...LG Georg
Le mardi 14 août 2007 à 22:19 +0200, Tim Boykett a écrit :
Hi Kids!
Time for a new adventure. I would like to have a working firewire camera input for manipulation in Gem on a linux box that is sitting here purring at me. The cam works fine with Kino and dvgrab, so the linux-firewire connection is all well.
But I am having no luck with pix_video or pdp_v4l. The main problem seems to be that (apparently) recently the naming conventions in debian and possibly linux in general were changed. So there is no more /dev/video0 for the v4l mode, and for pix_video trying to work directly with ieee1394, I get complaints that /dev/ieee1394/dv/ host/PAL/in "Is a directory".
Has anyone had more luck? Do I need to going from stable to testing in some parts of debian? Do I need to use some special somethings?
Hi apparently this is a problem related to the new behavior of udev under Debian. I wouldn't recommand to downgrad udev though. I read the following on videolan's website:
if you have a distribution that uses udev, then you must add/change the following line to the file 50-udev.rules in your /etc/udev/rules.d directory.
%vi /etc/udev/rules.d/50-udev.rules # IEEE1394 (firewire) devices (must be before raw devices below) KERNEL=="raw1394", NAME="%k" KERNEL=="dv1394", NAME="dv1394/%k" KERNEL=="video1394*", NAME="video1394/%n"
I havent tested it yet, since i havent any DV cam before hand at the moment.
The workaround i used at the time is the following:
first check that you belong to the right groups : disk and video by issuing the command groups
If not, then
$ sudo adduser username disk $ sudo adduser username video
then run the attached bash script as a superuser after each restart:
$ sudo bash ./dv.sh
you might have to chmod +x the shell script
Start Pd/Gem, pix_video should work as expected if feeded with the pathname given in the shell script (I cant remember well this part, i'm sorry i'm only sending a translation of my blog notes, i dont have access to the original machine and Pd program this week (public holiday).)
The shell was adapted from an article about Ubuntu Edgy and DV cams
http://tonywhitmore.co.uk/blog/2006/11/08/ubuntu-edgy-and-dv-cameras/
O.
Hi Olivier,
Thanks for your advice! I tried adding the line to udev-rules; I presumed that the result should be three lines: KERNEL=="raw1394", NAME="%k" KERNEL=="dv1394", NAME="dv1394/%k" KERNEL=="video1394*", NAME="video1394/%n"
I had the 2nd and 3rd, so I added the first. However, no change in
behaviour.
I am in the video and disk groups.
It seems that the dx.sh script was removed by the list program: could you send it directly?
However I somehow doubt that this is the problem: on the link you sent, they are talking about Kino not working. The other programs seem to be fine, it is PD that is having trouble, so I guess that something needs to be updated in the PD code. Which hurts!
I hope we can work our way forward to a solution!
cheers,
tim
On 15/08/2007, at 12:38 PM, Olivier Heinry wrote:
Le mardi 14 août 2007 à 22:19 +0200, Tim Boykett a écrit :
Hi Kids! Time for a new adventure. I would like to have a working
firewire camera input for manipulation in Gem on a linux box that
is sitting here purring at me. The cam works fine with Kino and
dvgrab, so the linux-firewire connection is all well. But I am
having no luck with pix_video or pdp_v4l. The main problem seems
to be that (apparently) recently the naming conventions in debian
and possibly linux in general were changed. So there is no more / dev/video0 for the v4l mode, and for pix_video trying to work
directly with ieee1394, I get complaints that /dev/ieee1394/dv/
host/PAL/in "Is a directory". Has anyone had more luck? Do I need
to going from stable to testing in some parts of debian? Do I need
to use some special somethings?Hi apparently this is a problem related to the new behavior of udev
under Debian. I wouldn't recommand to downgrad udev though. I read
the following on videolan's website:if you have a distribution that uses udev, then you must add/ change the following line to the file 50-udev.rules in your /etc/ udev/rules.d directory.
%vi /etc/udev/rules.d/50-udev.rules # IEEE1394 (firewire) devices (must be before raw devices below) KERNEL=="raw1394", NAME="%k" KERNEL=="dv1394", NAME="dv1394/%k"
KERNEL=="video1394*", NAME="video1394/%n"I havent tested it yet, since i havent any DV cam before hand at
the moment.The workaround i used at the time is the following:
first check that you belong to the right groups : disk and video by
issuing the command groupsIf not, then
$ sudo adduser username disk $ sudo adduser username video
then run the attached bash script as a superuser after each restart:
$ sudo bash ./dv.sh
you might have to chmod +x the shell script
Start Pd/Gem, pix_video should work as expected if feeded with the
pathname given in the shell script (I cant remember well this part, i'm sorry i'm only sending a
translation of my blog notes, i dont have access to the original
machine and Pd program this week (public holiday).)The shell was adapted from an article about Ubuntu Edgy and DV cams
http://tonywhitmore.co.uk/blog/2006/11/08/ubuntu-edgy-and-dv-cameras/
O. _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Hi, I'm having the same problem under fedore core 6 - there is no /dev/video
any advice? (there is no /dev/ieee1394 either
(kino see the camera fine)
thanks, Joseph
On 15/08/07, Tim Boykett tim@timesup.org wrote:
Hi Kids!
Time for a new adventure. I would like to have a working firewire camera input for manipulation in Gem on a linux box that is sitting here purring at me. The cam works fine with Kino and dvgrab, so the linux-firewire connection is all well.
But I am having no luck with pix_video or pdp_v4l. The main problem seems to be that (apparently) recently the naming conventions in debian and possibly linux in general were changed. So there is no more /dev/video0 for the v4l mode, and for pix_video trying to work directly with ieee1394, I get complaints that /dev/ieee1394/dv/ host/PAL/in "Is a directory".
Has anyone had more luck? Do I need to going from stable to testing in some parts of debian? Do I need to use some special somethings?
Looking forward to the d'Oh moment,
Tim
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Linux / DV users,
Summary: I think I have a fix for the problem with pix_video that has effected several people on some linux distributions. Please read on if this matters to you.
Note: this is probably for the pd-dev list, but I am not on it, so I
hope
that one of the PD-dev people can pick up on this and say "aha! I can
do this!"
I am using a machine with udev on it, so the device names are
not the ones expected by the pix_video object. In particular around
line 213 of videoDV4L.cpp I see that /dev/ieee1394/dv/host0/PAL/in is
being looked at, then
/dev/dv1394.
The error that I think I am seeing is that buf is being set to /dev/
ieee1394/dv/host0/PAL/in
then this is not working (it doesn't exist) and the next attempt to
access /dev/dv1394
is finding that this is a directory (on my machine). So I get the
nonsensical
error:
/dev/ieee1394/dv/host0/PAL/in: Is a directory
On my machine at least, the devices are /dev/dv1394/0 and /dev/dv1394/1. When I make a link from /dev/ieee1394/dv/host0/PAL/in to /dev/dv1394/0 then all is well.
Suggested solution: add more possibilities in this series of tests.
snprintf(buf, 32, "/dev/ieee1394/dv/host%d/%s/in", devnum,
(m_norm==NTSC)?"NTSC":"PAL");
if ((fd = open(buf, O_RDWR)) < 0) {
if ((fd=open("/dev/dv1394", O_RDWR)) < 0) {
snprintf(buf, 32, "/dev/dv1394/%d", devnum); /* new for
debian udev */
if ((fd=open(buf, O_RDWR)) < 0) {
perror(buf);
return -1;
}
}
}
I am sorry that I am not currently a developer and cannot do this
myself. I am sure someone else out there is clever enough to make it
work
quickly!
I am sure there is a more elegant way to go about this, but I cannot
work
out how to locate the appropriate devices using the "ever so clever"
udev
system. It seems that people who want to should be able to set up udev
to have special names for special devices. One possibly solution
would be to allow
a message to pass a device name to pix_video, then this device name
would be
used instead of pix_video trying to guess. In that case I might have
been able to
use a openpanel to point pix_video at the correct /dev/dv1394/0.
Perhaps other people who cannot get this to work can try to find out
what
the correct name on their machine is. The names that might work are like
/dev/dv1394, if I ls -l /dev/1394/0 on my machine I see
crw-rw---- 1 root video 171, 32 2007-08-22 03:42 /dev/dv1394/0
which means I am the right place: the c at the start tells me that this
is a "special character" device and the "major number" 171 tells me
(I think!)
that this is a video device.
So if you want to find some other devices that should be looked at in this opening routine, then perhaps suggest them now so that someone can add them to the source...
I am also not sure that this way of working through the list of possible places for the camera and reporting an error about the last one that was tried and failed is the best. But that's something for another day.
Cheers,
Tim
On 15/08/2007, at 2:55 PM, Joseph Barrows wrote:
Hi, I'm having the same problem under fedore core 6 - there is no /dev/ video
any advice? (there is no /dev/ieee1394 either
(kino see the camera fine)
thanks, Joseph
On 15/08/07, Tim Boykett tim@timesup.org wrote: Hi Kids!
Time for a new adventure. I would like to have a working firewire camera input for manipulation in Gem on a linux box that is sitting here purring at me. The cam works fine with Kino and dvgrab, so the linux-firewire connection is all well.
But I am having no luck with pix_video or pdp_v4l. The main problem seems to be that (apparently) recently the naming conventions in debian and possibly linux in general were changed. So there is no more /dev/video0 for the v4l mode, and for pix_video trying to work directly with ieee1394, I get complaints that /dev/ieee1394/dv/ host/PAL/in "Is a directory".
Has anyone had more luck? Do I need to going from stable to testing in some parts of debian? Do I need to use some special somethings?
Looking forward to the d'Oh moment,
Tim
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Joseph Barrows live video performance; web site design; new media artist jjbarrows.artwww.net jjbarrows@artwww.net _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Apologies for a slight stuff up,
The suggestion I made here, I now notice deep in the source, has been
made.
with the message
|device /dev/dv1394/0(
to pix_video I could have made this work all those days ago.
Cheers,
tm
On 21/08/2007, at 10:28 PM, Tim Boykett wrote:
to have special names for special devices. One possibly solution would be to allow a message to pass a device name to pix_video, then this device name would be used instead of pix_video trying to guess. In that case I might have been able to use a openpanel to point pix_video at the correct /dev/dv1394/0.
Le mardi 21 août 2007 à 22:49 +0200, Tim Boykett a écrit :
Apologies for a slight stuff up,
The suggestion I made here, I now notice deep in the source, has been
made. with the message|device /dev/dv1394/0(
to pix_video I could have made this work all those days ago.
Cheers,
tm
in this case, updating the pix_video doc would be sufficient
O.
On 21/08/2007, at 10:28 PM, Tim Boykett wrote:
to have special names for special devices. One possibly solution would be to allow a message to pass a device name to pix_video, then this device name would be used instead of pix_video trying to guess. In that case I might have been able to use a openpanel to point pix_video at the correct /dev/dv1394/0.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I plan to update the help file for pix_video before hans gets the next extended out the door.
cheers,
tim
On 22/08/2007, at 9:58 AM, Olivier Heinry wrote:
Le mardi 21 août 2007 à 22:49 +0200, Tim Boykett a écrit :
Apologies for a slight stuff up, The suggestion I made here, I now
notice deep in the source, has been made. with the message | device /dev/dv1394/0( to pix_video I could have made this work all
those days ago. Cheers, tmin this case, updating the pix_video doc would be sufficient
O.
On 21/08/2007, at 10:28 PM, Tim Boykett wrote: > to have special
names for special devices. One possibly solution > would be to
allow > a message to pass a device name to pix_video, then this
device name > would be > used instead of pix_video trying to
guess. In that case I might have > been able to > use a openpanel
to point pix_video at the correct /dev/dv1394/0.
_______________________________________________ PD-list@iem.at
mailing list UNSUBSCRIBE and account-management -> http:// lists.puredata.info/listinfo/pd-list
Tim Boykett schrieb:
Apologies for a slight stuff up,
The suggestion I made here, I now notice deep in the source, has been
made. with the message|device /dev/dv1394/0(
to pix_video I could have made this work all those days ago.
I should be documented in the help patch though ...
LG Georg
Tim Boykett schrieb:
Apologies for a slight stuff up,
The suggestion I made here, I now notice deep in the source, has been
made. with the message|device /dev/dv1394/0(
to pix_video I could have made this work all those days ago.
It should be documented in the help patch though ...
LG Georg
Hey,
If you do get this C code working, please submit a patch to the patch
tracker, then it can easily be included.
.hc
On Aug 21, 2007, at 4:28 PM, Tim Boykett wrote:
Hello Linux / DV users,
Summary: I think I have a fix for the problem with pix_video that has effected several people on some linux distributions. Please read on if this matters to you.
Note: this is probably for the pd-dev list, but I am not on it, so I hope that one of the PD-dev people can pick up on this and say "aha! I can do this!"
I am using a machine with udev on it, so the device names are not the ones expected by the pix_video object. In particular around line 213 of videoDV4L.cpp I see that /dev/ieee1394/dv/host0/PAL/in is being looked at, then /dev/dv1394.
The error that I think I am seeing is that buf is being set to /dev/ ieee1394/dv/host0/PAL/in then this is not working (it doesn't exist) and the next attempt to access /dev/dv1394 is finding that this is a directory (on my machine). So I get the nonsensical error: /dev/ieee1394/dv/host0/PAL/in: Is a directory
On my machine at least, the devices are /dev/dv1394/0 and /dev/dv1394/1. When I make a link from /dev/ieee1394/dv/host0/PAL/in to /dev/dv1394/0 then all is well.
Suggested solution: add more possibilities in this series of tests.
snprintf(buf, 32, "/dev/ieee1394/dv/host%d/%s/in", devnum,
(m_norm==NTSC)?"NTSC":"PAL"); if ((fd = open(buf, O_RDWR)) < 0) { if ((fd=open("/dev/dv1394", O_RDWR)) < 0) { snprintf(buf, 32, "/dev/dv1394/%d", devnum); /* new for debian udev */ if ((fd=open(buf, O_RDWR)) < 0) { perror(buf); return -1; } } }
I am sorry that I am not currently a developer and cannot do this myself. I am sure someone else out there is clever enough to make it work quickly!
I am sure there is a more elegant way to go about this, but I cannot work out how to locate the appropriate devices using the "ever so clever" udev system. It seems that people who want to should be able to set up udev to have special names for special devices. One possibly solution would be to allow a message to pass a device name to pix_video, then this device name would be used instead of pix_video trying to guess. In that case I might have been able to use a openpanel to point pix_video at the correct /dev/dv1394/0.
Perhaps other people who cannot get this to work can try to find out what the correct name on their machine is. The names that might work are
like /dev/dv1394, if I ls -l /dev/1394/0 on my machine I seecrw-rw---- 1 root video 171, 32 2007-08-22 03:42 /dev/dv1394/0
which means I am the right place: the c at the start tells me that
this is a "special character" device and the "major number" 171 tells me (I think!) that this is a video device.So if you want to find some other devices that should be looked at in this opening routine, then perhaps suggest them now so that someone can add them to the source...
I am also not sure that this way of working through the list of
possible places for the camera and reporting an error about the last one
that was tried and failed is the best. But that's something for another day.Cheers,
Tim
On 15/08/2007, at 2:55 PM, Joseph Barrows wrote:
Hi, I'm having the same problem under fedore core 6 - there is no /dev/ video
any advice? (there is no /dev/ieee1394 either
(kino see the camera fine)
thanks, Joseph
On 15/08/07, Tim Boykett tim@timesup.org wrote: Hi Kids!
Time for a new adventure. I would like to have a working firewire camera input for manipulation in Gem on a linux box that is sitting here purring at me. The cam works fine with Kino and dvgrab, so the linux-firewire connection is all well.
But I am having no luck with pix_video or pdp_v4l. The main problem seems to be that (apparently) recently the naming conventions in debian and possibly linux in general were changed. So there is no more /dev/video0 for the v4l mode, and for pix_video trying to work directly with ieee1394, I get complaints that /dev/ieee1394/dv/ host/PAL/in "Is a directory".
Has anyone had more luck? Do I need to going from stable to
testing in some parts of debian? Do I need to use some special somethings?Looking forward to the d'Oh moment,
Tim
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Joseph Barrows live video performance; web site design; new media artist jjbarrows.artwww.net jjbarrows@artwww.net _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore