Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-27 Thread Hans-Christoph Steiner

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 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 [EMAIL PROTECTED] 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
 [EMAIL PROTECTED]
 ___
 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

Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-22 Thread Tim Boykett

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, 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


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-22 Thread Georg Holzmann
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

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-22 Thread Georg Holzmann
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

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-22 Thread Olivier Heinry
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
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-21 Thread Tim Boykett


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 [EMAIL PROTECTED] 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
 [EMAIL PROTECTED]
 ___
 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


Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-21 Thread Tim Boykett

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.


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-15 Thread Georg Holzmann
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

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-15 Thread Olivier Heinry
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.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-15 Thread Joseph Barrows
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 [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Gem and ieee1394 firewire cam on linux debian

2007-08-15 Thread Tim Boykett

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



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list