linux1394-devel Mailing List for IEEE 1394 for Linux (Page 534)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(39) |
Apr
(154) |
May
(172) |
Jun
(237) |
Jul
(127) |
Aug
(135) |
Sep
(193) |
Oct
(175) |
Nov
(173) |
Dec
(148) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(161) |
Feb
(225) |
Mar
(193) |
Apr
(158) |
May
(179) |
Jun
(292) |
Jul
(146) |
Aug
(134) |
Sep
(185) |
Oct
(190) |
Nov
(149) |
Dec
(161) |
2002 |
Jan
(186) |
Feb
(236) |
Mar
(254) |
Apr
(207) |
May
(189) |
Jun
(182) |
Jul
(202) |
Aug
(155) |
Sep
(149) |
Oct
(449) |
Nov
(191) |
Dec
(108) |
2003 |
Jan
(174) |
Feb
(242) |
Mar
(243) |
Apr
(255) |
May
(202) |
Jun
(290) |
Jul
(237) |
Aug
(178) |
Sep
(101) |
Oct
(153) |
Nov
(144) |
Dec
(95) |
2004 |
Jan
(162) |
Feb
(278) |
Mar
(282) |
Apr
(152) |
May
(127) |
Jun
(138) |
Jul
(94) |
Aug
(63) |
Sep
(64) |
Oct
(150) |
Nov
(102) |
Dec
(197) |
2005 |
Jan
(102) |
Feb
(172) |
Mar
(89) |
Apr
(158) |
May
(139) |
Jun
(160) |
Jul
(288) |
Aug
(89) |
Sep
(201) |
Oct
(92) |
Nov
(190) |
Dec
(139) |
2006 |
Jan
(121) |
Feb
(204) |
Mar
(133) |
Apr
(134) |
May
(91) |
Jun
(226) |
Jul
(122) |
Aug
(101) |
Sep
(144) |
Oct
(141) |
Nov
|
Dec
|
2023 |
Jan
(19) |
Feb
(1) |
Mar
(5) |
Apr
(5) |
May
(33) |
Jun
(17) |
Jul
|
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(40) |
2024 |
Jan
(26) |
Feb
(14) |
Mar
(26) |
Apr
(46) |
May
(17) |
Jun
(47) |
Jul
(23) |
Aug
(72) |
Sep
(33) |
Oct
|
Nov
|
Dec
|
From: Bruce M. <br...@tr...> - 2000-05-05 00:50:19
|
On Wed, 26 Apr 2000, Andreas Micklei wrote: all, I have the first version of libavc1394 ready. Where can I post it? Bruce. > Hi, > > On Tue, Apr 25, 2000 at 11:23:00PM -0400, Bruce McDonald wrote: > > I'm new here so go easy. I am very interested in developing a dvcam tape > > scanning application that produces a batch capture list on output (at the > > very least). I am approaching this from the bottom-up so I am trying to > > abstract the AV/C & libraw funcations into a "libavc". I have noticed > > that gscanbus & and the sdpavc (from k-3d) both have their own api's (not > > in library form). I need to redo this existing overlap, so a library > > might be useful. > > I thought this to and actually I am planning to seperate the AV/C code from > gscanbus into a seperate library. However it would just be a libsimpleavc, so > just go ahead and build a "real" AV/C library if you need it. I would happily > adopt it for gscanbus and focus on something else. > > My simple AV/C implementation is quite handy for sending a command to a device > and receiving the response code. However I have not spent a single thought on > how to deal with input- / output-plugs and the whole issue of isochronous > stream management. This would probably be the hardest part of a real AV/C > implementation (and personally, I realy don't need that at the moment). > > > 0. Is the name, libavc, correct, or would libavc1394 (or other > > variant) be more correct? > > Both are correct. I would prefer libavc1394 because a beginner can than > easily figure out which parts belong to 1394. > > > 1. Would it be useful to develop a libavc which would implement the AV/C > > command set on top of libraw1394 in a standard way? > > Certainly. > > > (as an aside:- I tend to prefer C/asm for systems work and OO [c++/Java] > > languages for applications, so libavc would, most likely, be a C library) > > A C library would probably the best basis. A C++ / Java library on top of the > C library, or even better a CORBA binding would be nice to have later on. :-) > > Btw.: Can someone please put a gateway between the mailinglists at eclipt and > sourceforge, or shut down the list at eclipt completely? It is quite confusing > to have two seperate lists for the same subject. > > bye... > Andreas Micklei > |
From: Mark K. <mk...@co...> - 2000-05-04 13:15:26
|
Matt, I haven't read the licensing agreement from 1394LA, but I thought that historically these fees have been paid by the manufacturers of the silicon content, not the end-system/board manufacturers. If not, you get into multiple $0.25 payments for the same content. I.e. - I by a chip from someone who pays $0.25 to make the chip, and then I pay $0.25 to make a board, and then I sell that board to someone who adds software content and pays $0.25 to ship the board... Do you have any background/understanding in this area? Like you, I would certainly appreciate Mr. Wooten's input. Mark -----Original Message----- From: Matt Pujol [mailto:mat...@ls...] Sent: Wednesday, May 03, 2000 4:38 PM To: Southwell Cc: lin...@li... Subject: Re: 1394 Licensing issues The 1394 Licensing Authority is the group to be dealt with - they are at www.1394la.com. They want $0.25USD for each end product sold. So, if you make a Linux 1394-enabled system, you have to participate in the 1394LA agreement. As for Open Source/GPL code, I've heard (I'm not sure where) that as long as no money changes hands, there's no royalty.....but that's just what I've heard, I'm sure Mr. Wooten will correct me if necessary. The question/issue is the same for MPEG-2....they have the same, if not worse licensing issues. Regards, Matt Southwell wrote: Can someone please tell me what the current position is on IEEE 1394 licensing issues as far as they affect the development and use of firewire under Linux. I am finding the current licensing situation quite confusing and am concerned to know that anyone using the IEEE 1394 support will not be landing themselves into a potentially difficult legal position.. Thanks David S. ----- Original Message ----- From: Matt Pujol To: lin...@li... Sent: Wednesday, May 03, 2000 12:43 PM Subject: I need some info on driver development status Dear Linux-1394 Zealots, I will be giving an overview presentation on 1394 and Linux at the 1394 Developer's Conference in San Jose, June 20-22. I want to give an update on the state of the 1394 driver development, supported protocols, and future plans. This will be a great opportunity to give the activity of the the this development group some extra credibility and maybe get some more development support. So, please, everybody who's doing anything, let me know where you're at, what you lack, where you're going, and when you might get there with your development activity. I'll share the compilation of what I get with the reflector. Now for the blatant marketing plug.....If you are in the Bay Area on June 20-22, maybe at the Fairmont Hotel, and you have $795 to spare to learn everything you ever wanted to know about 1394...then come to the Developer's Conference!! Here's the link for more information http://www.1394ta.org/Events/DevCon/index.html . It's well worth it. Best regards and I expect to hear from each and every one of you...... Matt -- /*********************** Matt Pujol 1394 Product Marketing Manager LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ -- /*********************** Matt Pujol 1394 Product Marketing Manager LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ |
From: Sebastien R. <Seb...@sy...> - 2000-05-03 23:26:07
|
>>>>> "Matt" == Matt Pujol <mat...@ls...> writes: Matt> Dear Linux-1394 Zealots, Matt> I will be giving an overview presentation on 1394 and Linux at the 1394 Matt> Developer's Conference in San Jose, June 20-22. I want to give an Matt> update on the state of the 1394 driver development, supported protocols, Matt> and future plans. This will be a great opportunity to give the activity Matt> of the the this development group some extra credibility and maybe get Matt> some more development support. Matt> So, please, everybody who's doing anything, let me know where you're at, Matt> what you lack, where you're going, and when you might get there with Matt> your development activity. I'll share the compilation of what I get Matt> with the reflector. Hi Matt. Here is the status for the ohci1394 low-level driver: Implemented features: . Async Request Transmit . Async Response Receive . Async Request Receive . Async Response Transmit . Iso Receive Missing features: . Iso Transmit . Config ROM (not properly defined yet) . Compare/Swap using ohci registers and probably tons of other little things Knowns problems: . Stability (still very much alpha quality) . SONY CXD3222 chip (and probably others) is not working properly Main difficulty encountered: . Lack of time (I have plenty of other more important things to do). . Lack of documentation (You have to pay to get the doc on CSR architecture for example). . Lack of hardware (I only have two TI ohci development boards) Good luck with your presentation, -- Sebastien Rougeaux RSISE, The Australian National University |
From: Southwell <vi...@pt...> - 2000-05-03 22:19:40
|
Can someone please tell me what the current position is on IEEE 1394 = licensing issues as far as they affect the development and use of = firewire under Linux. I am finding the current licensing situation quite = confusing and am concerned to know that anyone using the IEEE 1394 = support will not be landing themselves into a potentially difficult = legal position.. Thanks=20 David S. ----- Original Message -----=20 From: Matt Pujol=20 To: lin...@li...=20 Sent: Wednesday, May 03, 2000 12:43 PM Subject: I need some info on driver development status Dear Linux-1394 Zealots,=20 I will be giving an overview presentation on 1394 and Linux at the = 1394 Developer's Conference in San Jose, June 20-22. I want to give an = update on the state of the 1394 driver development, supported protocols, = and future plans. This will be a great opportunity to give the activity = of the the this development group some extra credibility and maybe get = some more development support.=20 So, please, everybody who's doing anything, let me know where you're = at, what you lack, where you're going, and when you might get there with = your development activity. I'll share the compilation of what I get = with the reflector.=20 Now for the blatant marketing plug.....If you are in the Bay Area on = June 20-22, maybe at the Fairmont Hotel, and you have $795 to spare to = learn everything you ever wanted to know about 1394...then come to the = Developer's Conference!! Here's the link for more information = http://www.1394ta.org/Events/DevCon/index.html . It's well worth it.=20 Best regards and I expect to hear from each and every one of you...... = Matt=20 =20 --=20 /*********************** Matt Pujol 1394 Product Marketing Manager LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ =20 |
From: Manfred W. <e95...@st...> - 2000-05-03 22:08:53
|
Julien Pouliot wrote: > But first, I have to answer this question: > - What does FCP and HPSB stands for? IEC 61883-1 says in chapter 9 (section 9.1) on page 37: "Function control protocol (FCP) is designed in order to control devices connected through a IEEE 1394 bus. Various command sets and various command transactions are available on FCP. FCP is designed to be based on IEEE 1393, an FCP uses asynchronous packets of iIEEE 1394 for sending commands and responses..." It is used for example by AV/C (audio video control) to control cameras, dvb tuners etc. You can have a look to the AV/C standard (available on http://www.1394ta.org/Download/Technology/Specifications/AVC_30.pdf) for a detailed explanation. Commands are sent (as write transactions) by the controller to the fcp command register at the target. Responses are sent by the target to the fcp response register of the controller. I do not know, what hpsb is (but I do not either need it). Manfred Weihs |
From: Matt P. <mat...@ls...> - 2000-05-03 20:50:13
|
Dear Linux-1394 Zealots, I will be giving an overview presentation on 1394 and Linux at the 1394 Developer's Conference in San Jose, June 20-22. I want to give an update on the state of the 1394 driver development, supported protocols, and future plans. This will be a great opportunity to give the activity of the the this development group some extra credibility and maybe get some more development support. So, please, everybody who's doing anything, let me know where you're at, what you lack, where you're going, and when you might get there with your development activity. I'll share the compilation of what I get with the reflector. Now for the blatant marketing plug.....If you are in the Bay Area on June 20-22, maybe at the Fairmont Hotel, and you have $795 to spare to learn everything you ever wanted to know about 1394...then come to the Developer's Conference!! Here's the link for more information http://www.1394ta.org/Events/DevCon/index.html . It's well worth it. Best regards and I expect to hear from each and every one of you...... Matt -- /*********************** Matt Pujol 1394 Product Marketing Manager LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ |
From: Julien P. <jul...@ho...> - 2000-05-03 17:17:03
|
I am following this mailing list since a few months and I am now beginning writing some code to link 2 computers by ieee1394 under Linux. Since I am beginning, I plan to use only asynchronous transactions but I will have to use isochronous transactions in the future (for bandwith purposes). I know that Iso write function is still not written so I know that I'll have to do it one of theese days. But first, I have to answer this question: - What does FCP and HPSB stands for? Thanks. Julien ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com |
From: Bill P. <wpa...@lu...> - 2000-05-03 16:46:23
|
From the recent messages, it appears that the Adaptec AIC-5800 is currently unsupported in the most recent patches. Is this correct? I'm trying to decide whether to replace the Adaptec. I've been trying to get going with an Adaptec card, and have got the kernel patches working with the 0221 patch. 'testlibraw' works fine (using the 0.5 version), apparently. 'dvgrab' doesn't seem to do much, though. Any help would be appreciated. Bill Paulson |
From: <fra...@ya...> - 2000-05-03 13:32:49
|
I suppose you use the ether_setup() function in the init function of your ethernet driver. ( I will called it ether1394_init() ) The ether_setup() fonction assign lot of things for your driver and can assign its name like "eth1" or "eth2", depands on number of ethernet interface are "up" in the kernel. But for this, you have to define a global char buffer inside your module : char etherdev_name[8]; then the field 'name' of your network device must point to this buffer : static struct device ether1394_dev = { etherdev_name, // pointe vers une zone memoire qui a ete reservee 0, 0, 0, 0, // shmem adresse 0x0000, // IOport 0, // irq 0, 0, 0, // flags NULL, // next NULL, // init = null, pour le moment }; And in your init_module() function you should : // refer to your network device init function : ether1394_dev.init = ether1394_init; // put a blank char on the name buffer of your network device // So the ether_setup() function will assign // a name like "eth1" ether1394_dev.name[0] = ' '; // and register your ethernet driver // this will call your ether1394_init() function register_netdev(ðer1394_dev) Now you can insmod ether1394 and ifup eth1 --- Phat Huynh <pha...@ax...> a écrit: > Hi, > I started to work on a ethernet encapsulation driver > two days ago and I > tried to insert the driver into the kernel by first > insmod all the > ieee1394 modules and the executing this command: > > ifconfig ether1394 172.21.2.190 up > > but I received this error-message: > > SIOCSIFADDR: No such device > ether1394: unknown interface: No such device > ether1394: unknown interface: No such device > > Do you know why the kernel fails to locate the > ether1394 driver although > the driver is loaded into kernel already (I've > checked it)? > > -- > Phat Huynh > Axis Communications > > > ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: <fra...@ya...> - 2000-05-03 11:35:09
|
This is the source code of my ethernet driver on IEEE 1394 To use it, you have to "insmod" the ieee1394 module and ohci1394 (or pcilynx) module before, on ALL nodes. => READ eth1394.c, there is a few modification to do, inside ieee1394_core.c <= Then "insmod" the eth1394 module on ALL nodes. And "ifup" the eth1 interface (for exemple). I have written the following content in the "ifcfg-eth1" file located in the /etc/sysconfig/network-scripts/ directory : DEVICE="eth1" BOOTPROTO="none" IPADDR="192.160.0.1" NETMASK="255.255.255.0" NETWORK=192.160.0.0 BROADCAST=192.160.0.255 ONBOOT="no" ----- I am not an expert in writing network drivers, so if some find mistakes, all apologies. Comments and questions are welcom, ----- Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Rodney R. <re...@de...> - 2000-05-03 00:16:21
|
I have some code that I am willing to share. It began with the Ethernet encapsulation driver draft by Emanuel Pirker <ep...@ed...> incorporating a hunt for viable peer layer to talk to among the nodes. But that's the only real simularity. I intended it to be able to talk to Mac and Windows boxes, not just other Linux boxes and here, in a nutshell, is how it works: There are two channels set up in the address space of each node: the ether channel, where packets are transfered, and a common address resolution channel. First, at boot a shell script provides the ARP channel address # that all boxes will know. This is set with ioctl's socket extension enum: SIO_PRIVATE. This address is used to do a read-query on all nodes during this time and at any time bus reset occurs. Any remote replies return an ether HW address(which comes from the ROM's GUID) and an address # that has been successfully allocated on the remote for ether packet exchange. This information is cached in the devices private ARP table. When a packet is transmitted the ether HW destination is read and looked up in this ARP table and sent to the appropriate node. If the HW address is the broadcast value then all nodes are engaged. The code has not been built or tested and a few issues remain: 1) Should a queue be maintained during the internal ARP for packets leaving the ifc. 2) The Little/big endian issue in a mixed environ currently has all big endian boxes swapping bytes to maintain binary compatablity, this causes a dependency on the low-level HW driver since OHCI allows for byte swapping. 3) I don't think I've implemented broadcast correctly and a few functions are still incomplete 4) raw1394 seems to undergone some success, it might be better to use its treatment of the under-layer since there is a potiential deadlock when a layer does not maintain its own serialization objects. 5) If an unrecognized HW address is found an globally incomplete ARP table is indicated, should private ARP be attempted from this point also or request a bus reset? The code is raw but I think structurally operable. I've had little time of late to go forward with it and hoped to set up CVS on my own www server and solicit contribitors. Until then, anyone wishing to go forward I will be happy to email them the work. Rodney -----Original Message----- From: Frederic Villeneuve [mailto:fv...@ho...] Sent: Tuesday, May 02, 2000 8:48 AM To: Franck Bonin Cc: lin...@li... Subject: Re: ethernet driver Hello, I was thinking about working on IP over 1394 . I would be willing to participate to that project. Do you have the source code available ? Frederic Villeneuve ----- Original Message ----- From: "Franck Bonin" <fra...@ya...> To: <lin...@li...> Sent: Tuesday, May 02, 2000 4:21 AM Subject: ethernet driver Since few weeks, I write an encapsuted ethernet driver on the top of the linux ieee1394 subsystem. By using the old 0.5 version of modules with 2 adaptec boards : Hot Connect 8920, I was able to transfer data twice as fast as on common ethernet interface. But, I found some problems using the linux ieee1394 subsystem. First, I was not able to find a way to transfer data using ``unified'' write transactions. So I make few modifications in the ieee1394 core module. The Hot Connect 8920 board use S200 speed bus. So the max payload data on a single paquet must be 1024 bytes. But, to avoid kernel freezing, I reduce the size of ethernet paquet to 200 bytes. If not, after some times, strangness append in the low level driver ``aic5800'', this could freeze the 2 computers. ---------- Last week, I recieved 2 ADS PYRO OHCI boards. So I download last CVS version of modules and libraw. After succesfull installation and tests, I rebuild my ethernet driver, using the new subsystem. And unfortunatly I found other strange problems. 1. ``insmoding'' 2 times the ohci modules freezing one or the other computer... 2. My ethernet driver is working (vor exemple, flood ping is OK) but other kind of programs like ftp or telnet don't work well: for an unknown reason, after a few time, the ohci driver (or the board ?) stop recieve (or transmit) paquets, while it still can transmit (or receive) some other paquets like ARP ones. And of course, some times it crach ! ___________ An other question : Now, I will work on isochronous transmissions and video stream. But unfortunatly, I have not any camrecorder. So does anyone know the way to make believe others nodes that my PC-linux is a camrecorder ? ---- Thanks for any comment or answer. Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Manfred W. <e95...@st...> - 2000-05-02 21:25:44
|
Sebastien Rougeaux wrote: > The important part for me > is that the driver: > > . allows multi-buffering (tunable) > . doesn't waste CPU time > . does frame synchronization Of course not wasting CPU time is a very important topic concerning the reception of iso packets. But in the last issue (frame synchronisation) I do not aggree with you. That should not be done by the driver; any interpretation of the content of an iso packet should be done by the application. The driver shall deliver the raw packets (as libraw does now) and the application should decide, what the data is and whether it has to look for sync tags and things like that. One reason is, that there are many different data types transmitted via isochronous channels, not only plain video images. For example I receive MPEG 2 transport streams, and I want to get the packets as they are, the driver shall not interpret them. The only extension I could imagine is, that the driver could resolve the CIP-format (ie. Reassembling the source packets and either forwarding them to the application, when the time stamp [in the source packet header; that correspond to the least significant bytes of the 16 bits of the cycle time register] is reached or forwarding them immediately together with the timestamp); all further interpretation is up to the application. I believe, the interface for receiving iso packets, which libraw provides, is good. The only thing that might be changed is handling of the header; I already mentioned that byte-swapping would make sense for consistency. Of course the "low-level-handling" of these packets in the driver could (should) be optimated, but the interface in libraw should stay unchanged. Manfred Weihs PS: Did somebody read my posting about using the cycle time register for synchronisation (my whishlist entry)? Any comments? |
From: Scott F. J. <sc...@fl...> - 2000-05-02 21:07:55
|
Add these two lines to the quicktime/Makefile in quicktime4linux and it will compile a DSO for shared use amoung these tools. I think this would be the preferred method to linking libquicktime.a in multiple places. libquicktime.so: $(OBJS) $(CC) -shared -o $@ $(OBJS) -ljpeg -lpng -lz -lpthread |
From: <fra...@ya...> - 2000-05-02 16:03:03
|
My first message about ethernet drivers asked too for, How transform a PC-linux in a camrecorder. In fact I don't want my PC-linux to transmit isochronous packets (It is currently impossible). I just want it to receive isochronous packets, while other nodes on the bus like my Imac DV or my PC-windoz can both transmit isochronous packet. The only difficultie is to make believe to Imac DV or PC-windoz that there is camrecorder on the bus to make them start to transmit. That is why I thougth that I could disguise the PC-linux in a comrecorder, using asynchronous transactions or during tree identification (with the help of some fcp transactions or by modifing some ID registers). But I don't now how to do that, so if someone have an idea. Thanks in advance, ------ Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: <fra...@ya...> - 2000-05-02 15:40:02
|
Ok, I think I juste have to precise some few things : My driver is a study on how using IP over 1394 with less efforts. For linux, my driver is a network driver that use kernel ethernet facilities. So I have keept ethernet packet headers (and I use it). With my solution, I avoid to rewrite the ARP protocol for 1394 (I keep using the ethernet ARP protocol). But I had to choose arbitrary hardware addresses for my IEEE 1394 boards, and I had to build a very simple external protocol manage to found which node got which hardware address. Moreover, I only uses unified write transactions to transfer ethernet packets. To do that, I have just added one line in ieee1394_core.c which prevent the write response paquet to be transmitted while the CSR address of the paquet recieved match with those my driver is in charge. Of course, I write a new unified write transaction which complete when the 1394 packet is transmitted by the low-level device driver. This solution save bandwidth but might be not safe (the only acknowledgment sent for a received paquet is the 1394 link layer 8 bit ack). I think that TCP or other higher level protocol can ensure data integrity. My driver work (more or less), but is not as general as might be a real implementation of IP over 1394 using (for exemple) RFC 2734. I will soon post my source code and report bugs that I found. Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Frederic V. <fv...@ho...> - 2000-05-02 13:58:45
|
Hello, I was thinking about working on IP over 1394 . I would be willing to participate to that project. Do you have the source code available ? Frederic Villeneuve ----- Original Message ----- From: "Franck Bonin" <fra...@ya...> To: <lin...@li...> Sent: Tuesday, May 02, 2000 4:21 AM Subject: ethernet driver Since few weeks, I write an encapsuted ethernet driver on the top of the linux ieee1394 subsystem. By using the old 0.5 version of modules with 2 adaptec boards : Hot Connect 8920, I was able to transfer data twice as fast as on common ethernet interface. But, I found some problems using the linux ieee1394 subsystem. First, I was not able to find a way to transfer data using ``unified'' write transactions. So I make few modifications in the ieee1394 core module. The Hot Connect 8920 board use S200 speed bus. So the max payload data on a single paquet must be 1024 bytes. But, to avoid kernel freezing, I reduce the size of ethernet paquet to 200 bytes. If not, after some times, strangness append in the low level driver ``aic5800'', this could freeze the 2 computers. ---------- Last week, I recieved 2 ADS PYRO OHCI boards. So I download last CVS version of modules and libraw. After succesfull installation and tests, I rebuild my ethernet driver, using the new subsystem. And unfortunatly I found other strange problems. 1. ``insmoding'' 2 times the ohci modules freezing one or the other computer... 2. My ethernet driver is working (vor exemple, flood ping is OK) but other kind of programs like ftp or telnet don't work well: for an unknown reason, after a few time, the ohci driver (or the board ?) stop recieve (or transmit) paquets, while it still can transmit (or receive) some other paquets like ARP ones. And of course, some times it crach ! ___________ An other question : Now, I will work on isochronous transmissions and video stream. But unfortunatly, I have not any camrecorder. So does anyone know the way to make believe others nodes that my PC-linux is a camrecorder ? ---- Thanks for any comment or answer. Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: <Ale...@ne...> - 2000-05-02 12:45:23
|
Franck - I am also working towards an IP-over-1394 implementation together with streaming multimedia on the same time. Please update me on your progress if you can. I am working with two OHCI cards in my Linux box, interconnected by a cable and also connected to a data transit bus analyzer. My OHCI driver is not the latest but works flawlessly (more or less). To Linux each card seems like a standalone 1394 node, so I am able to pass read/write messages between the cards. You should try it too. Alex. Sebastien Rougeaux <Seb...@sy...> on 05/02/2000 06:03:23 AM Please respond to Seb...@sy... Sent by: Sebastien Rougeaux <Seb...@sy...> To: fra...@ya... cc: lin...@li... (Alexander Carmeli/US/3Com) Subject: Re: ethernet driver Good to hear that IP over 1394 is progressing ;-) >>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?= <iso-8859-1> writes: Franck> Since few weeks, I write an encapsuted ethernet driver on the top of Franck> the linux ieee1394 subsystem. By using the old 0.5 version of modules Franck> with 2 adaptec boards : Hot Connect 8920, I was able to transfer data Franck> twice as fast as on common ethernet interface. But, I found some Franck> problems using the linux ieee1394 subsystem. Franck> First, I was not able to find a way to transfer data using ``unified'' Franck> write transactions. So I make few modifications in the ieee1394 core Franck> module. Franck> The Hot Connect 8920 board use S200 speed bus. So the max payload data Franck> on a single paquet must be 1024 bytes. But, to avoid kernel freezing, Franck> I reduce the size of ethernet paquet to 200 bytes. If not, after some Franck> times, strangness append in the low level driver ``aic5800'', this Franck> could freeze the 2 computers. I think the AIC5800 is not supported anymore... it's been a few months since the last update for this driver has been announced. Franck> ---------- Franck> Last week, I recieved 2 ADS PYRO OHCI boards. So I download last CVS Franck> version of modules and libraw. After succesfull installation and Franck> tests, I rebuild my ethernet driver, using the new subsystem. And Franck> unfortunatly I found other strange problems. Franck> 1. ``insmoding'' 2 times the ohci modules freezing one or the other Franck> computer... I have not experienced any kernel freeze when loading the ohci module for quite a while now, and nobody else so far as complained about that on the list... however the ohci driver is still very much alpha quality and has not been extensively tested, so anything is possible. Could you please be more specific with your bug report. Can you repeat the kernel freeze easily ? Can you get part of the log file before it happens ? Franck> 2. My ethernet driver is working (vor exemple, flood ping is OK) but Franck> other kind of programs like ftp or telnet don't work well: for an Franck> unknown reason, after a few time, the ohci driver (or the board ?) Franck> stop recieve (or transmit) paquets, while it still can transmit (or Franck> receive) some other paquets like ARP ones. And of course, some times Franck> it crach ! When the ohci driver stops receiving packets, could you please make a dump of 'dmesg' and 'cat /proc/ohci1394'... Is this error repeatable as well ? Don't forget to turn on the 'excessive debugging messages' option. Franck> ___________ Franck> An other question : Franck> Now, I will work on isochronous transmissions and video stream. But Franck> unfortunatly, I have not any camrecorder. So does anyone know the way Franck> to make believe others nodes that my PC-linux is a camrecorder ? Well to simulate a camerate you need iso packet transmission. Unfortunately this functionality is not yet included in the ohci driver... either buy a camera, be patient or... write it and submit a patch ;-) Bonne journee, -- Sebastien Rougeaux RSISE, The Australian National University _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Sebastien R. <Seb...@sy...> - 2000-05-02 10:10:20
|
Good to hear that IP over 1394 is progressing ;-) >>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?= <iso-8859-1> writes: Franck> Since few weeks, I write an encapsuted ethernet driver on the top of Franck> the linux ieee1394 subsystem. By using the old 0.5 version of modules Franck> with 2 adaptec boards : Hot Connect 8920, I was able to transfer data Franck> twice as fast as on common ethernet interface. But, I found some Franck> problems using the linux ieee1394 subsystem. Franck> First, I was not able to find a way to transfer data using ``unified'' Franck> write transactions. So I make few modifications in the ieee1394 core Franck> module. Franck> The Hot Connect 8920 board use S200 speed bus. So the max payload data Franck> on a single paquet must be 1024 bytes. But, to avoid kernel freezing, Franck> I reduce the size of ethernet paquet to 200 bytes. If not, after some Franck> times, strangness append in the low level driver ``aic5800'', this Franck> could freeze the 2 computers. I think the AIC5800 is not supported anymore... it's been a few months since the last update for this driver has been announced. Franck> ---------- Franck> Last week, I recieved 2 ADS PYRO OHCI boards. So I download last CVS Franck> version of modules and libraw. After succesfull installation and Franck> tests, I rebuild my ethernet driver, using the new subsystem. And Franck> unfortunatly I found other strange problems. Franck> 1. ``insmoding'' 2 times the ohci modules freezing one or the other Franck> computer... I have not experienced any kernel freeze when loading the ohci module for quite a while now, and nobody else so far as complained about that on the list... however the ohci driver is still very much alpha quality and has not been extensively tested, so anything is possible. Could you please be more specific with your bug report. Can you repeat the kernel freeze easily ? Can you get part of the log file before it happens ? Franck> 2. My ethernet driver is working (vor exemple, flood ping is OK) but Franck> other kind of programs like ftp or telnet don't work well: for an Franck> unknown reason, after a few time, the ohci driver (or the board ?) Franck> stop recieve (or transmit) paquets, while it still can transmit (or Franck> receive) some other paquets like ARP ones. And of course, some times Franck> it crach ! When the ohci driver stops receiving packets, could you please make a dump of 'dmesg' and 'cat /proc/ohci1394'... Is this error repeatable as well ? Don't forget to turn on the 'excessive debugging messages' option. Franck> ___________ Franck> An other question : Franck> Now, I will work on isochronous transmissions and video stream. But Franck> unfortunatly, I have not any camrecorder. So does anyone know the way Franck> to make believe others nodes that my PC-linux is a camrecorder ? Well to simulate a camerate you need iso packet transmission. Unfortunately this functionality is not yet included in the ohci driver... either buy a camera, be patient or... write it and submit a patch ;-) Bonne journee, -- Sebastien Rougeaux RSISE, The Australian National University |
From: <fra...@ya...> - 2000-05-02 09:30:24
|
Since few weeks, I write an encapsuted ethernet driver on the top of the linux ieee1394 subsystem. By using the old 0.5 version of modules with 2 adaptec boards : Hot Connect 8920, I was able to transfer data twice as fast as on common ethernet interface. But, I found some problems using the linux ieee1394 subsystem. First, I was not able to find a way to transfer data using ``unified'' write transactions. So I make few modifications in the ieee1394 core module. The Hot Connect 8920 board use S200 speed bus. So the max payload data on a single paquet must be 1024 bytes. But, to avoid kernel freezing, I reduce the size of ethernet paquet to 200 bytes. If not, after some times, strangness append in the low level driver ``aic5800'', this could freeze the 2 computers. ---------- Last week, I recieved 2 ADS PYRO OHCI boards. So I download last CVS version of modules and libraw. After succesfull installation and tests, I rebuild my ethernet driver, using the new subsystem. And unfortunatly I found other strange problems. 1. ``insmoding'' 2 times the ohci modules freezing one or the other computer... 2. My ethernet driver is working (vor exemple, flood ping is OK) but other kind of programs like ftp or telnet don't work well: for an unknown reason, after a few time, the ohci driver (or the board ?) stop recieve (or transmit) paquets, while it still can transmit (or receive) some other paquets like ARP ones. And of course, some times it crach ! ___________ An other question : Now, I will work on isochronous transmissions and video stream. But unfortunatly, I have not any camrecorder. So does anyone know the way to make believe others nodes that my PC-linux is a camrecorder ? ---- Thanks for any comment or answer. Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Simon V. <si...@tk...> - 2000-05-02 06:45:09
|
Hi all, the header bytes in the DV data blocks let you compute the correct address where the video data should go to, so if you write your codec in the right way, you'll have some blocks missing, but that's all. Windows will need its fixed buffer length for a frame, but that's all, I think. I think the more likely event to occur is tape problems which result in error blocks being sent over the wire, which do not contain any video information, but that's a different story :) Simon > > How can you know that you lost a packet, and which area of the image it > correspond to ? I think anyway loosing a packet is a 'rare' event, especially > if you use the dma prg I am describing at the beginning of this mail, > so the effect in the video stream should be barely noticable. > > -- > Sebastien Rougeaux > RSISE, The Australian National University > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel > -- --------------------------------------------------------------------------- si...@tk... - icq: 14088682 - www.tk.uni-linz.ac.at/~simon I2C-Bus 4 Linux: www.voxel.at/prj/i2c/ |
From: Sebastien R. <Seb...@sy...> - 2000-05-02 06:32:46
|
>>>>> "Arne" == Arne Schirmacher <ar...@sc...> writes: Arne> Aren't you already discussing this feature with Andreas in the thread Arne> "updated dma to user space API"? I don't want to spend some effort on Arne> this if this feature will be available in libraw 0.x anyway. Yes, the current API is probably temporary... but since I don't have much free time, it might stay like that for a while. Currently, it works the following way in the ohci driver: The dma prg wait for an iso packet with the correct 'sync tag'. Then it fills the frame buffer with the data it receives until it is full. The dma prg removes all packet header/trailers, so what you have at the end in the buffer is a complete properly formatted image (for uncompressed video), or a complete dv encoded frame. At the completion of the frame, it generates an interrupt in order to wake up the user app which is waiting for frame completion. All is done using the dma engine of the ohci card, so CPU usage is kept to a minimum. Arne> How should a frame grabbing routine using dma be implemented? Arne> The naive solution (used in dvgrab up to 0.6x) was: Arne> throw away any packet which is 16 bytes long wait until first packet for Arne> frame is received put packet into frame buffer until it is filled Arne> This would be easy to implement using dma but has several drawbacks: Arne> 1. It assumes that packets always come in the required order. I do not Arne> know whether this assumption always holds for any type of camcorder. It would be strange otherwise... Arne> 2. If we lose just one packet this will result in the loss of a full Arne> frame, because the next "start of frame" packet will be put in the last Arne> position in the previous frame. Therefore synchronization is lost until Arne> we get another "start of frame" packet, which is one frame away. Also Arne> the current frame is completely broken because all packets from now on Arne> are in the wrong place If you loose the sync packet, then there is little you can do... Arne> Starting with dvgrab 0.7 I am using a somewhat more robust algorithm Arne> which explicitly calculates the packet offset in the frame buffer. If we Arne> lose a packet the corresponding area in the frame buffer still contains Arne> the previous packet. The assembled frame is "less wrong" than with the Arne> naive approach. One tester said he had better results with the new Arne> algorithm. Arne> But... I can calculate the offset only after I have the packet. So the Arne> only way to do it would be predicting the expected address and verifying Arne> the packet after it comes in. If the verification fail I have to do some Arne> form of smart recovery. How can you know that you lost a packet, and which area of the image it correspond to ? I think anyway loosing a packet is a 'rare' event, especially if you use the dma prg I am describing at the beginning of this mail, so the effect in the video stream should be barely noticable. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Brion V. <br...@gi...> - 2000-05-02 05:33:22
|
On Sun, 30 Apr 2000, Arne Schirmacher wrote: > This is a slightly modified version of the playdv.c program from the libdv > project. This version now reads AVI files instead of plain DV data files. Since I don't have any DV AVI files to play with - the only 1394 card I have access to is a Digital Origin card with MotoDV on a friend's Win98 box and it only has Quicktime drivers - I hacked up Arne's hack some more to read my Quicktime files using Quicktime4Linux. I've been able to display all my DV .mov's so far except for the ones that Q4L itself mysteriously hangs on for reasons not yet clear to me. The Quicktime4linux library is available at http://heroine.linuxave.net/, it compiles to an .a file and has no automatic install so you may need to hack makefiles depending on where you put it. A diff to xdvplay_0.2 is attached... With a teensy bit of work a single program capable of playing .dv, .avi, and .mov files should be doable, and once libdv is librarized it should be elementary to add the codec to Q4L. -- brion vibber (br...@po...) |
From: Arne S. <ar...@sc...> - 2000-05-01 09:42:24
|
Aren't you already discussing this feature with Andreas in the thread "updated dma to user space API"? I don't want to spend some effort on this if this feature will be available in libraw 0.x anyway. How should a frame grabbing routine using dma be implemented? The naive solution (used in dvgrab up to 0.6x) was: throw away any packet which is 16 bytes long wait until first packet for frame is received put packet into frame buffer until it is filled This would be easy to implement using dma but has several drawbacks: 1. It assumes that packets always come in the required order. I do not know whether this assumption always holds for any type of camcorder. 2. If we lose just one packet this will result in the loss of a full frame, because the next "start of frame" packet will be put in the last position in the previous frame. Therefore synchronization is lost until we get another "start of frame" packet, which is one frame away. Also the current frame is completely broken because all packets from now on are in the wrong place Starting with dvgrab 0.7 I am using a somewhat more robust algorithm which explicitly calculates the packet offset in the frame buffer. If we lose a packet the corresponding area in the frame buffer still contains the previous packet. The assembled frame is "less wrong" than with the naive approach. One tester said he had better results with the new algorithm. But... I can calculate the offset only after I have the packet. So the only way to do it would be predicting the expected address and verifying the packet after it comes in. If the verification fail I have to do some form of smart recovery. Any comments? Arne -----Original Message----- From: Sebastien Rougeaux [SMTP:Seb...@sy...] Sent: Friday, April 28, 2000 1:23 AM To: ar...@sc... Cc: Seb...@sy...; and...@mu...; lin...@li... Subject: Re: My wishlist entry >>>>> "Arne" == Arne Schirmacher <ar...@sc...> writes: Arne> I wanted to modify my dvgrab code, but dvgrab uses libraw 0.6, no direct Arne> dma available there :-( [ yet? :-) ] Sorry for the confusion. I might not have been explicit enough. Direct user space dma and libraw are completely independent (for the moment). You use libraw to initialize the camera (everything you did before, except you do not need the iso_handler, and you DO NOT use raw1394_start_iso_rcv() nor the raw1394_loop_iterate(). Then you use /dev/ohci1394 as a frame grabbing device, following the instructions I have given in my previous announcement. I have already two successful users for this feature ;-), so it should work. Feel free to ask any question you might have, -- Sebastien Rougeaux RSISE, The Australian National University |
From: Arne S. <ar...@sc...> - 2000-04-30 21:18:52
|
Hi all, download xdvplay 0.2 from http://www.schirmacher.de/arne/xdvplay/xdvplay_0.2.tar.gz . This is a slightly modified version of the playdv.c program from the libdv project. This version now reads AVI files instead of plain DV data files. Arne |
From: Sebastien R. <Seb...@sy...> - 2000-04-30 10:15:37
|
>>>>> "Andreas" == Andreas Bombe <and...@mu...> writes: Andreas> On Tue, Apr 25, 2000 at 08:14:57PM +1000, Sebastien Rougeaux wrote: >> I have updated the API for the direct iso dma to user space feature that >> is available for the ohci driver. Previously the buffer filling was running >> continuously in the driver, and the user app was only waiting for irq >> generated for each frame. The problem was doing so you could easily create >> synchronization problems. Now the user app has to queue the buffers for >> each frame. If the user app can not keep up with the framerate, the dma >> context will wait until fresh buffers are queued. It is very similar to the >> video4linux API. Andreas> Is there anything special about this DMA? I guess it just does Andreas> header stripping instead of giving the complete packet like libraw Andreas> does. Strictly seen it's also not DMA to user space but having Andreas> kernel buffers mapped to user space (what I intended to do for libraw Andreas> once I figure it out and get to it). Strictly speaking yes... Is there anything wrong with that ? It is what framegrabber drivers like bttv are doing... anyway I don't know any other way of doing it. If this feature could be included in libraw, it would be good... Andreas> What I have problems with is that it duplicates a lot of bttv code, Andreas> something Linus probably will also complain about. Plus, from my Andreas> understanding, the bttv code handles a lot of cases which are not Andreas> required for OHCI hardware. Yes it duplicates the bttv code for the buffer allocation and mapping. Again, if there is such function in the kernel, I would be happy to use it. If not we have to write something anyway... Andreas> What I have in mind for better iso receiving is something like a Andreas> manager part in the subsystem handing out chunks of 64kB (or Andreas> something, should be tunable) contiguous mem to the hardware drivers Andreas> which receive iso packets into those. When the remaining space in Andreas> the chunk is too small for more packets, the driver tells the Andreas> subsystem and gets a new chunk. Andreas> The filled chunks have then a soft and a hard reference count. The Andreas> soft count indicates that someone is interested in the contained data Andreas> at all (otherwise it could just as well be freed immediately). The Andreas> hard count indicates that it must not be freed at this time Andreas> (e.g. it's mapped to user space by raw1394 currently). If a limit is Andreas> reached or memory gets low the oldest chunks with soft references but Andreas> no hard refs can be freed (i.e. packets get lost). Sounds good. My code is temporary anyway (I needed the functionality ASAP so I wrote it as fast as I could). If you come up without something similar with no loss of performance, I'll be very interested. The important part for me is that the driver: . allows multi-buffering (tunable) . doesn't waste CPU time . does frame synchronization -- Sebastien Rougeaux RSISE, The Australian National University |