linux1394-devel Mailing List for IEEE 1394 for Linux (Page 541)
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: Rodney R. <re...@de...> - 2000-04-01 21:53:14
|
I have arrived, help me out though, I'm a newcommer to Linux projects and the 1394 spec. I've got 10yrs of C and about 5yrs of C++ and even CS degree I thought I'd never need, my mainstay is client-server. Basically, I'm hot on network communication like the ether-on-1394 solution. I've got several issues to bring up here but first sourceforge.net wouldn't bring up the archive so I don't have any knowledge of what's been discussed so bear with me if something is redundant. I realize alot of you are intrested in the neat new hardware that's available utilizing 1394, but as for me, once you get all that data your going to need inter-processor comunication to render it in your life time :^) First, my build environ is on RH6.0 PII-350 SMP machine known to my subnet as linus.de-signs.net after you know who. I used the previous version of the 1394 project patch and it worked without a hitch on v2.2.13. I did not installed hardware and that pointed out in a minor bug(see next). I also have a PIII-450 SMP on NT called k9.de-signs.net to use for the other end of the wire. Here's how linus goes at boot: ieee1394: registered ohci1394 driver, initializing now ohci1394: looking for Ohci1394 cards ohci1394: no operable Ohci1394 cards found ieee1394: detected 0 ohci1394 adapters ieee1394: 1 host adapter initialized Upon examination of the code the '1' comes from hosts.c::hpsb_register_lowlevel. This function only returns '0' and nothing to indicate success or failure of its dependent, so the count continues. Its not a functional handicap, so I assume this went unnoticed. Second, and more importantly, the issue above is really several issues. The code(and comments) as written selects a quadlet packet or buffer based on size and that's like asking the client for the type. Let's get something straight about just what is binary compatabile interface first. It has always been my opinion that this hardware driver class was nominally responsible for the following issues: 1) transmitting data in binary compatability mode(i.e. stream of bit ordered bytes) 2) Providing either a maximum packet size, implement transparent package splitting/reassembly, or both. 3) Allow partial aquisition of the data in the read buffer(packet peeking), and 4) Implement client package alignment and justification in the hardware holding buffer(DMA). I will cover each of these in turn but the latter is not an issue in the case of OHCI and was added for completeness, however; 802 packets come/go miss-aligned as you may know. The third issue I'm not prepared to discuss here but would like to hear some comments. To go on, having meet these specs, all super layers may then provide behavior according to their specific need. ether-on-1394, for example, would be considered a upper-layer(service) driver utilizing this interface. In order for interoperability to occur on a network where this layer might come from different sources, the interface must match some specifcation at the middle(device independent) layer. In other words, their has to be a way to push a packet through the connection with minimal assumptions and data dependencies. The tree grows as a consequence of the leaves, so to speak. Please refer to following while I address the first issue above: [1(see below)] Sect 5.7;pp45-47, [3] Sect 3.5 and ieee1394_transactions.c To use the example in the comment of the code, given '12345' is the message, in a little endian, then the sequence 1234,5xxx is read into a register from the port(or through DMA), which must reordered in the register so it can be layed down in memory as words 4321,xxx5. If the chronology(i.e. apparent order of the bytes in a quadlet in the channel) is reversed, then no reshuffling has to take place(at least for the data-field), in this case, the message is recieved as 4321,xxx5. It would be optimal to have the hardware preform the actual byte swaps. OHCI provides for this capability with a control bit: HCControl.noByteSwapData which controls only the data field of the packet. (I don't see this used in ohci1394.c/h and have not looked in the other drivers.) Assuming PHY does not swap, and the chronological sequence is big-endian(ibid p47) according to the OHCI specs, therefore, if a little endian machine clears this bit and big endian sets it, no reshuffling will be required on any machine except in the _header_ fields. The resolution of this issue in the middle layers of the driver seems simple: allow odd sized buffers >=0 bytes to be transmitted since there is no harm done by padding the client data package with null bytes when its moved into the kernel memory space if 1394Packet.data_length is set correctly to the unaligned length in the header on write. And, on read, odd bytes will appear in the proper order if 1394Packet.data_length is obtained and returned to the caller as well as the buffer after stripping the header. (Note also that raw1394.c/h also enforces data sizes to be mulitiples of 4 bytes) As to the second issue above, please also refer to [2] below. It would be optimal in terms of performance and code size for future extensions, like ether-on-1394, if packet fragmentation was available and had ioctl parameters to set the internal fragment size. This is the case in the MS design for the middle layer. An example would be a file system where the node allocation structures and cache read look ahead sizes exceeds the maximum packet size of the media but packets still had to contain a sector multiples. Since this is my first examination of this kind of code in Linux I don't know if there exists a trend to implement this at this level or not. 1394 spec allows for this kind of behavior through the address space allocation which is just a tag for the packet. This is also neccessary since out-of-order IO is allowed(yeah, its a box-o-worms). The middle layer driver thus should implement control of this behavior with an additional parameters, either through the address request allocation scheme or directly in the I/O initiation calls with the latter more preferable to the former. The extra parameters would tell the implementation how to enumerate through the address space and where to split a buffer when a client packet is larger than the media allows. It would also enable the linux implementation the most flexibility to match other platforms for host-to-host communication through ether or some other protocol like SCSI or ATAPI. Now back to the ether-on-1394 solution. If the above was implemented(fixed) then a few things would be in order. Either, just transmit 802.3 packets to some pre-agreed address range, or the ARP table must include the address space and software on the nodes would have to be able to exchange this information with one another at some pre-agreed address. The latter method would overcome 64 node limit and get very high bisection bandwidth of the 1394 ether network since routing is directed from the source. Thus the AR table would need to translate from an ip-mask pair to possibly multiple node_id-address_space pairs. Well that's as far as I got today, I'd like to hear some comments. Rodney Refs: [1] ftp://download.intel.com/technology/1394/download/ohci_11.pdf [2] http://www.microsoft.com/ddk/ddkdocs/win2k/default.htm Kernal-Mode Drivers/Design Guide/Part 6 IEEE1394 Drivers [3] http://www.1394ta.org/Download/Technology/Specifications/iicp1.0.pdf |
From: James h. <har...@se...> - 2000-04-01 02:13:21
|
> > Message: 2 > Date: Fri, 31 Mar 2000 11:16:20 +0200 > From: Jose Miguel Buenaposada Biencinto <"jmbuena"@isys.dia.fi.upm.es> > Subject: Some questions > To: lin...@li... > Organization: UPM > > Hi ! > > I hope not to be off topic. > > I'd like to use a IEEE1394 camera to do real time computer vision. So I > have > to choose a PCI board and a cammera: > > - Can somebody tell me some board functional with Linux > nowadays ? I'll be easier to look for boards and not for a concrete > chip. I supouse > that the only to worry about to work under Linux is the PC board. > > - Is the 400 Mbits/s a real mesure ? What is the real frame rate that I > can > achive ? > > - I have the kernel 2.2.14 with RedHat 6.1 in a SMP box. Some good/bad > experience ? > > - Where can I get more information about IEEE1394. > > Thanks a lot for your time. > > -- > ------------------------------------------------------------------- > Jose Miguel Buenaposada Biencinto > Facultad de Informática | Computer Science School > Universidad Politécnica de Madrid (UPM) | Madrid Tech. University. > Campus de Montegancedo s/n > 28660 Boadilla del Monte, Madrid (ESPAÑA)| (SPAIN) > Voice +34 91 336 69 47 > e-mail: jm...@di... > web : http://www.dia.fi.upm.es/~jmbuena > ------------------------------------------------------------------- Greetings Jose, This is my first post to this list. I have been quietly monitoring it for a week or so, I don't think this is off topic... I have a sony DCR-TRV110E DV camcorder. It is the lowest model of the DV capable camcorders that Sony produces. It has only a 350 line CCD but will record full frame DV (Pal 720x576) over Firewire. I have used it to capture video under Windows 98 with Ulead VideoStudio 4SE. It successfully captured/edited and played back to the camera. This software was bundled with the card which is packaged as a "Cherri1394 Firewire Host Adapter". The manual appears generic and is titled "CI-6500F4" I am running Linux 2.2.14 and have built the IEEE1394 modules from the project's website. The card is found no problem. The camera is unknown to gscanbus so it drops out with an error message. I haven't had much time to get into this stuff, despite how cool it is, because I am studying. However I believe that this is just a matter of configuring gscan bus to recognise the ID of the camera because without the camera there gscanbus opens the window and indicates that there are no devices. I don't know of any software that captures DV under Linux and would be very interested in finding some. Help here anyone? I'd be interested in any open source DV developments however I believe that the patents may be a problem here??? When I get back my free time (July) I want to delve more deeply into the IEEE1394 project an see if I can be helpful. Hope this helps! Cheers, James |
From: Jose M. B. B. <jmbuena@isys.dia.fi.upm.es> - 2000-03-31 10:29:02
|
Hi ! I hope not to be off topic. I'd like to use a IEEE1394 camera to do real time computer vision. So I have to choose a PCI board and a cammera: - Can somebody tell me some board functional with Linux nowadays ? I'll be easier to look for boards and not for a concrete chip. I supouse that the only to worry about to work under Linux is the PC board. - Is the 400 Mbits/s a real mesure ? What is the real frame rate that I can achive ? - I have the kernel 2.2.14 with RedHat 6.1 in a SMP box. Some good/bad experience ? - Where can I get more information about IEEE1394. Thanks a lot for your time. -- ------------------------------------------------------------------- Jose Miguel Buenaposada Biencinto Facultad de Informática | Computer Science School Universidad Politécnica de Madrid (UPM) | Madrid Tech. University. Campus de Montegancedo s/n 28660 Boadilla del Monte, Madrid (ESPAÑA)| (SPAIN) Voice +34 91 336 69 47 e-mail: jm...@di... web : http://www.dia.fi.upm.es/~jmbuena ------------------------------------------------------------------- |
From: Manfred W. <e95...@st...> - 2000-03-30 21:36:30
|
Hello! After updating to the new (cvs-)version of the subsystem (before I used ieee1394-2.2.14-20000206.gz) I observed the following very interesting phenomenon: If my computer was attached to a 1394-network during bootup (ie. when the driver was loaded) and I run testlibraw (from the current libraw1394 0.6 of course), it tells me that: <output of testlibraw> successfully got handle current generation number: 1 1 card(s) found nodes on bus: 0, card name: pcilynx using first card found: 0 nodes on bus, local ID is 3 doing transactions with custom tag handler using standard tag handler and synchronous calls testing FCP monitoring on local node got fcp command from node 3 of 8 bytes: 01 23 45 67 89 ab cd ef got fcp response from node 3 of 8 bytes: 01 23 45 67 89 ab cd ef polling for leftover messages </output of testlibraw> Obviously no node is found. But there must be at least one node (the local node). gscanbus crashes with a core dump (which probably is a bug of gscanbus which might not be able to handle 0 nodes correctly). Then I pulled the 1394 plug and afterwards it seemed to be ok, one node was detected (the same happens if the plug was already pulled during bootup): <output of testlibraw> successfully got handle current generation number: 2 1 card(s) found nodes on bus: 1, card name: pcilynx using first card found: 1 nodes on bus, local ID is 0 doing transactions with custom tag handler trying to send read request to node 0... completed with 0x00100000, value 0xfe060000 using standard tag handler and synchronous calls trying to read from node 0... completed with 0x00100000, value 0x77050000 testing FCP monitoring on local node got fcp command from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef got fcp response from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef polling for leftover messages </output of testlibraw> gscanbus does not core dump any more, but it says that it cannot read the topology map (this is probably because it is not yet adopted to the changed endianess policy). Afterwards I again plugged in the 1394-cable, and now the network is detected: <output of testlibraw> successfully got handle current generation number: 3 1 card(s) found nodes on bus: 9, card name: pcilynx using first card found: 9 nodes on bus, local ID is 3 doing transactions with custom tag handler trying to send read request to node 0... completed with 0x00020000, value 0x799b 96c6 trying to send read request to node 1... failed with error -1102 trying to send read request to node 2... completed with 0x00020000, value 0xa632 a2c6 trying to send read request to node 3... completed with 0x00100000, value 0x7205 0000 trying to send read request to node 4... completed with 0x00020000, value 0x3e23 bfc6 trying to send read request to node 5... failed with error -1102 trying to send read request to node 6... completed with 0x00020000, value 0xe4b3 76c6 trying to send read request to node 7... failed with error -1102 trying to send read request to node 8... failed with error -1102 using standard tag handler and synchronous calls trying to read from node 0... completed with 0x00020000, value 0x11b8acc6 trying to read from node 1... failed with error -1102 trying to read from node 2... completed with 0x00020000, value 0xf31ab8c6 trying to read from node 3... completed with 0x00100000, value 0xb00a0000 trying to read from node 4... completed with 0x00020000, value 0x82f4d4c6 trying to read from node 5... failed with error -1102 trying to read from node 6... completed with 0x00020000, value 0xd1828cc6 trying to read from node 7... failed with error -1102 trying to read from node 8... failed with error -1102 testing FCP monitoring on local node got fcp command from node 3 of 8 bytes: 01 23 45 67 89 ab cd ef got fcp response from node 3 of 8 bytes: 01 23 45 67 89 ab cd ef polling for leftover messages </output of testlibraw> It took me quite a lot of time to find out, that in order to work with the new driver, I have to pull the plug and then to re-plug-in. I hope, you will find the bug. Manfred Weihs PS: I can report another bug which I observed yesterday before updating, so it is a bug of the version from feb 6th, and I do not know if it still exists in the current version. If I plugged in the cabel, which a 1394-network hang on, and the X-server (Xfree86 3.6, kde 1.1.2) was running (and visible), then sometimes my pc hang up (completely, I was not even able to ping it). But it did not happen always, so I could not reproduce it. But it never happened when a text console was active, and booting while attached to the 1394-network also worked, it only hang up, when I plugged in. |
From: <And...@no...> - 2000-03-30 15:42:22
|
Hi, I'm now able to store the DV stream to a file, extract the audio and play it back correctly. My program recognizes all audio encoding modes specified by the DV standard (i.e. 48_44.1_32kHz/16 bits/2 ch and 32 kHz/12 bits/4 ch). The DV video decoder is also becoming better and better, it decodes approx. 30 frames/sec on a 400 MHz P2. In order to have real time performance (25 frames/sec for PAL) we can only do the pass 1 decoding. This means that we don't use all information contained in a coded frame since the pass 2 and 3 data is spread all around the coded frame and it takes time to collect it the right way. However, we have added support for pass 2 and 3 which can be used to get better picture quality when for instance grabbing a single frame. In this case you will have a lot more time to do stuff like pass 2 and 3. It doesn't matter if it takes a second longer to store the picture to a file. We still want to release the code but the DV patent issues are a bit tricky... Best regards, Anders Weitman _____________________________________________________________________ Anders Weitman, M.Sc Phone : +46 (0)13 4611341 Development Engineer Fax : +46 (0)13 4611001 Nokia Home Communications Mobile : +46 (0)70 2141319 Diskettgatan 11 E-mail : and...@no... SE-583 35 Linkoping, Sweden Internet : www.nokia.com/multimedia/ |
From: <ch...@st...> - 2000-03-29 06:24:03
|
I'm interested in getting an IEEE1394 hard drive working under Linux. Could I get a basic rundown as to the status of the project in this area? TIA, Chad Smith |
From: Andreas B. <and...@mu...> - 2000-03-27 00:54:08
|
On Sun, Mar 26, 2000 at 07:30:51PM +0200, Manfred Weihs wrote: > If I understood the code correctly, then by issuing > raw1394_start_fcp_listen we tell the kernel to store the packets > arriving in a buffer array which is located in raw1394_handle. BTW: That > ist the same buffer which is used for iso packets, so it would probably > be advisable for people, who are listening for iso_packets _and_ > fcp_frames, to allocate two seperate handles for those two purposes (I > think, that should be mentioned in a comment in raw1394.h). The buffer is only overwritten on a raw1394_loop_iterate() call which then calls the handlers. After a handler ends, the corresponding data is invalid (the handler must process the data immediately or save it somewhere else if it really has to store plain data). Therefore there won't be problems with correct usage. In the future the address given to an iso or FCP handler might not even exist anymore since I intend to implement kernel-to-user memory mapping at some point in the future and the page containing the data could be unmapped immediately after use. > I am also not quit sure, if it was a good idea to mix up the reception > of fcp commands and responses into one handler, since an application > might be interested in only listening to either commands or responses > (of cource, if somebody wants to implement a fully AV/C-compliant unit, > he will have to handle both). Future optimization. For now this just amounts in unneccessary handler calls (and data copies) but doesn't create any realy problems. Just ignore handler calls with the wrong direction argument. > In that context I have another qestion: > If two application (or one application using two raw-handles) register > for listening at the FCP addresses, which buffer will be used? Or will > the kernel create two copies of that packet in both raw-handle-buffers? > I think that the kernel will do this, but I just wanted to ask, because > I was not sure, and studying the source-code is not easy... The FCP data (like iso data) is stored once in the kernel and then copied to each listening app. The data in kernel is deleted after the reference count reaches zero (all apps got a copy). -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Andreas B. <and...@mu...> - 2000-03-26 23:17:59
|
On Sun, Mar 26, 2000 at 12:55:27AM +0100, Manfred Weihs wrote: > I have one question concerning libraw1394. > If I issue a lock operation, how can I find out response value. The > function has only (input-)arguments for arg and data, but no > (output-)argument for the data of the response (old value). > This is important, because after a compare_swap operation I have to > verify, if that response quadlet (old value) is the same as that one I > used as arg, to find out, whether the swap has been performed or not. Umm, yes. I just forgot to return the reponse value somewhere (the joys of cut&paste programming). That's just libraw missing it, the kernel side supports that (and will corrupt data in the user space program or make it segfault if you still try to use the lock function). Will take care of that. > BTW: It is not important for me, but: Why are arg and data restricted to > be one quadlet, wheras 1394 allows lock operations for 32-bit and for > 64-bit-values? I wanted to implement a separate lock64 function for that, I just didn't get around to do that so far. -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Manfred W. <e95...@st...> - 2000-03-26 18:05:59
|
I still have not tested the new fcp-functions, but I had a look at the code and I think I discovered a flaw, which might cause errors in some situations, which are very difficult to locate. If I understood the code correctly, then by issuing raw1394_start_fcp_listen we tell the kernel to store the packets arriving in a buffer array which is located in raw1394_handle. BTW: That ist the same buffer which is used for iso packets, so it would probably be advisable for people, who are listening for iso_packets _and_ fcp_frames, to allocate two seperate handles for those two purposes (I think, that should be mentioned in a comment in raw1394.h). If a new packet arrives before the first one was read completly by the application, it would overwritten and the application either loses the first one completly or it reads a mixture (which can in worst case be a mixture fcp-commands, fcp-responses and iso-packets). I am also not quit sure, if it was a good idea to mix up the reception of fcp commands and responses into one handler, since an application might be interested in only listening to either commands or responses (of cource, if somebody wants to implement a fully AV/C-compliant unit, he will have to handle both). In that context I have another qestion: If two application (or one application using two raw-handles) register for listening at the FCP addresses, which buffer will be used? Or will the kernel create two copies of that packet in both raw-handle-buffers? I think that the kernel will do this, but I just wanted to ask, because I was not sure, and studying the source-code is not easy... greetings Manfred Weihs |
From: Manfred W. <e95...@st...> - 2000-03-26 00:02:08
|
I have one question concerning libraw1394. If I issue a lock operation, how can I find out response value. The function has only (input-)arguments for arg and data, but no (output-)argument for the data of the response (old value). This is important, because after a compare_swap operation I have to verify, if that response quadlet (old value) is the same as that one I used as arg, to find out, whether the swap has been performed or not. BTW: It is not important for me, but: Why are arg and data restricted to be one quadlet, wheras 1394 allows lock operations for 32-bit and for 64-bit-values? Manfred Weihs |
From: imp@Orbotech.COM - 2000-03-25 12:29:27
|
Hello ! Is there any work being done on SBP-2 layer ? Regards, Cyril Plisko |
From: Manfred W. <e95...@st...> - 2000-03-24 17:24:59
|
Manfred Weihs wrote: > Andreas Bombe wrote: > > Run aclocal and then again autoconf. > > aclocal says: > aclocal: configure.in: 7: macro `AM_PROG_LIBTOOL' not found in library Maybe some of you are interested in my solution. The reason for that problem was that I installed the automake-rpm of my distribution (including aclocal) which put its m4-files into /usr/share/aclocal. But I installed libtool from a tar.gz, which (since I used the default directories) put its libtool.m4 into /usr/local/share/aclocal (where aclocal does not search for m4-files). If I used "aclocal -I /usr/local/share/aclocal", it would work. In fact my solution is a bit more general: I adopted my /usr/bin/aclocal to look into /usr/local/share/aclocal, too (without "-I"-option). Manfred Weihs |
From: Arne S. <ar...@sc...> - 2000-03-23 19:41:31
|
That's great news, so I can concentrate on other issues. I am really looking forward to your source code. Arne -----Original Message----- From: And...@no... Sent: Thursday, March 23, 2000 7:24 AM To: ar...@sc... Cc: lin...@li... Subject: How to release code Arne Schirmacher wrote: > So you want to release the compiled program(s), but you do > not want to release any sourcecode? You misunderstood me, I want to release the sourcecode to the DV decoder but Nokia must make sure that we don't run into trubble with other parts of the system's code (e.g. supplied by a third party). Best regards, Anders Weitman _____________________________________________________________________ Anders Weitman, M.Sc Phone : +46 (0)13 4611341 Development Engineer Fax : +46 (0)13 4611001 Nokia Home Communications Mobile : +46 (0)70 2141319 Diskettgatan 11 E-mail : and...@no... SE-583 35 Linkoping, Sweden Internet : www.nokia.com/multimedia/ _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: <And...@no...> - 2000-03-23 06:29:53
|
Arne Schirmacher wrote: > So you want to release the compiled program(s), but you do > not want to release any sourcecode? You misunderstood me, I want to release the sourcecode to the DV decoder but Nokia must make sure that we don't run into trubble with other parts of the system's code (e.g. supplied by a third party). Best regards, Anders Weitman _____________________________________________________________________ Anders Weitman, M.Sc Phone : +46 (0)13 4611341 Development Engineer Fax : +46 (0)13 4611001 Nokia Home Communications Mobile : +46 (0)70 2141319 Diskettgatan 11 E-mail : and...@no... SE-583 35 Linkoping, Sweden Internet : www.nokia.com/multimedia/ |
From: Andreas B. <and...@mu...> - 2000-03-22 18:51:34
|
On Wed, Mar 22, 2000 at 10:50:09AM +0200, And...@no... wrote: > I noticed that the OHCI1394 code is released under GPL. What is the case > with the rest of 1394 subsystem? The subsystem is all GPL (as is required for it to be part of the kernel - it has to be either GPL or a compatible license). > We use libraw1394 to get streaming isochronous data to our DV decoder and > the DV decoder is part of some viewer application, which in turn is part of > our complete system. Since the OHCI1394 driver is GPL, does this imply that > we have to release all our code? I guess that the question results in that > "part of" must be defined. Does it mean compiled together or is it enough > for two separately compiled programs to exchange information somehow? The Linux COPYING file contains the GPL with the following exception: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". [...] Linus Torvalds Therefore user space programs can be under any license they wish. The only other license to care about is libraw1394's license which is LGPL, so you can again use any license for your own programs linking to it. You only have to allow users of your application to link against a different version of libraw1394 (easy when you use the shared library, you have to distribute a linkable object without libraw1394 if you want static linking). If you make direct modifications of libraw1394 you have to release the source of the new libraw1394 you created, anything else is yours. -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Arne S. <ar...@sc...> - 2000-03-21 07:56:12
|
My AMD 333 MHz system with a separate IBM DTTA 10 GByte disk (5400 rpm) holds up pretty well when doing DV work both under Windows98 and under Linux, so I believe your system will work fine. However you should use a separate disk or at least a separate partition, because a fragmented or partially filled disk slows the writes down. Arne -----Original Message----- From: Lukas Knutsson Sent: Monday, March 20, 2000 10:26 AM To: lin...@li... Subject: What is required hard disk wise ... ... I have a P2 333 MHz. The motherboard has DMA. I am considering buying a new extra harddrive for DV capture under Linux & Win98. Naturally I am looking at the new Ultra DMA 7200 rpm IDE disks as they as so cheap compared to SCSI stuff. My question is whether I will get enough speed with my DMA controller, or will I need to buy a separate Ultra DMA controller to get the speed I need to stream DV onto the disk. A new PC is in the pipeline, which should solve these problems but until then ! ... -- | || ||| || r a z o r f i s h s t o c k h o l m Lukas Knutsson >>tel + 46.8.527.90457 mobile + 46.709.640720 >>http://www.razorfish.com _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Manfred W. <e95...@st...> - 2000-03-20 20:17:18
|
Andreas Bombe wrote: > Do you have libtool then? It's also required if you configure for > yourself. Yes. It's even more current than yours (see below)... > [andreasb@storm andreasb]$ autoconf --version > Autoconf version 2.13 > [andreasb@storm andreasb]$ automake --version > automake (GNU automake) 1.4 > > Copyright (C) 1999 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Written by Tom Tromey <tr...@cy...> > [andreasb@storm andreasb]$ libtoolize --version > libtoolize (GNU libtool) 1.3.3 I have esentially the same: manfred@Proton:~ > autoconf --version Autoconf version 2.13 manfred@Proton:~ > automake --version automake (GNU automake) 1.4 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Tom Tromey <tr...@cy...> manfred@Proton:~ > libtoolize --version libtoolize (GNU libtool) 1.3.4 That's very strange. I hope I find out why it works on your pc and does not work on mine. Anyway, I saw that you created a new tarball and that works. Manfred Weihs |
From: Andreas B. <and...@mu...> - 2000-03-20 15:39:20
|
On Mon, Mar 20, 2000 at 10:19:33AM +0100, Franck Bonin wrote: > And now (patch 20000318) it is : > > <6>ieee1394: registered aic5800 driver, initializing > now > <6>aic5800-0: allocated interrupt 5 > <6>aic5800-0: remapped memory space reg 0xcc87ec00 > <6>ieee1394: detected 1 aic5800 adapter > <6>aic5800-0: bus reset occured > <7>ieee1394: including selfid 0x80404054 > <6>ieee1394: SelfIDs failed monotony check with 20 > <5>ieee1394: error in SelfID stage - resetting The problem is that the subsystem changed default endianness of bytes (now it's always big endian) and the AIC driver wasn't updated yet. That should be Emanuel Pirker's task, but I haven't heard from him in a while. The AIC driver is currently broken, sorry. -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Lukas K. <lu...@ra...> - 2000-03-20 09:34:17
|
... I have a P2 333 MHz. The motherboard has DMA. I am considering buying a new extra harddrive for DV capture under Linux & Win98. Naturally I am looking at the new Ultra DMA 7200 rpm IDE disks as they as so cheap compared to SCSI stuff. My question is whether I will get enough speed with my DMA controller, or will I need to buy a separate Ultra DMA controller to get the speed I need to stream DV onto the disk. A new PC is in the pipeline, which should solve these problems but until then ! ... -- | || ||| || r a z o r f i s h s t o c k h o l m Lukas Knutsson >>tel + 46.8.527.90457 mobile + 46.709.640720 >>http://www.razorfish.com |
From: <fra...@ya...> - 2000-03-20 09:25:13
|
With old modules (patch 20000221) the kmsg output is : <6>ieee1394: registered aic5800 driver, initializing now <6>aic5800-0: allocated interrupt 5 <6>aic5800-0: remapped memory space reg 0xcc87fc00 <6>ieee1394: detected 1 aic5800 adapter <6>aic5800-0: bus reset occured <4>including selfid 0x80404054 And now (patch 20000318) it is : <6>ieee1394: registered aic5800 driver, initializing now <6>aic5800-0: allocated interrupt 5 <6>aic5800-0: remapped memory space reg 0xcc87ec00 <6>ieee1394: detected 1 aic5800 adapter <6>aic5800-0: bus reset occured <7>ieee1394: including selfid 0x80404054 <6>ieee1394: SelfIDs failed monotony check with 20 <5>ieee1394: error in SelfID stage - resetting <6>aic5800-0: bus reset occured <7>ieee1394: including selfid 0x80404054 <6>ieee1394: SelfIDs failed monotony check with 20 <5>ieee1394: error in SelfID stage - resetting <6>aic5800-0: bus reset occured <7>ieee1394: including selfid 0x80404054 <6>ieee1394: SelfIDs failed monotony check with 20 (...) <6>ieee1394: SelfIDs failed monotony check with 20 <5>ieee1394: stopping out-of-control reset loop <5>ieee1394: warning - topology map and speed map will therefore not be valid (???) ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Andreas B. <and...@mu...> - 2000-03-19 15:47:22
|
On Sun, Mar 19, 2000 at 03:26:09PM +0100, Manfred Weihs wrote: > Andreas Bombe wrote: > > There is an autogen.sh script in the repository now, it created > > Makefiles from a bare CVS checkout from me just fine. Running that > > should do the right thing (the script is taken from GLib, so it's well > > tested). > > First: the script in the reopsitory does not have the correct > permissions, so one has to do "chmod a+x autogen.sh" in order to make it > work. That's dependent on the permission on the CVS server and I don't have direct access to that. I'll see what I can do. > Second: it still does not work for me. Same problem (error messages) as > before. Which versions of automake/autoconf do you have (or would I > need)? Do you have libtool then? It's also required if you configure for yourself. [andreasb@storm andreasb]$ autoconf --version Autoconf version 2.13 [andreasb@storm andreasb]$ automake --version automake (GNU automake) 1.4 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Tom Tromey <tr...@cy...> [andreasb@storm andreasb]$ libtoolize --version libtoolize (GNU libtool) 1.3.3 -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Manfred W. <e95...@st...> - 2000-03-19 14:31:28
|
Andreas Bombe wrote: > There is an autogen.sh script in the repository now, it created > Makefiles from a bare CVS checkout from me just fine. Running that > should do the right thing (the script is taken from GLib, so it's well > tested). First: the script in the reopsitory does not have the correct permissions, so one has to do "chmod a+x autogen.sh" in order to make it work. Second: it still does not work for me. Same problem (error messages) as before. Which versions of automake/autoconf do you have (or would I need)? Manfred Weihs |
From: Arne S. <ar...@sc...> - 2000-03-19 14:10:20
|
Hi all, I purchased a DV specification (SMPTE 314M-1999 from http://www.smpte.org , $34, comes as a PDF file) and I can now decode much of the subcode, video auxiliary and audio data in the DV data stream. Expect a new version of dvgrab in a week or so. Before I spend a whole lot of time writing a video decoder -- did anybody here on this list tried that before? Arne |
From: Andreas B. <and...@mu...> - 2000-03-18 19:18:06
|
I have made new patches for Linux versions 2.2.14 and 2.3.99-pre1 and a new version of libraw1394 which is required for these new patches. Changes since the last patch: - endianness policy changed - all data is now kept big endian on all architectures, user space programs must expect and send data in big endian - OHCI updates - FCP register access monitoring - verbose debug logging can now be disabled with a configure switch - cleanup of PCILynx debug logging Libraw changes since last version: - header file raw1394.h cleaned up to avoid trouble with C++ - support for FCP register monitoring added - testlibraw now has a FCP test case See http://linux1394.sourceforge.net/download.html for download links. -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Andreas B. <and...@mu...> - 2000-03-18 18:08:35
|
On Sat, Mar 18, 2000 at 04:08:28PM +1100, Sebastien Rougeaux wrote: > >>>>> "Jeffrey" == Jeffrey B Mulligan <jb...@vi...> writes: > Jeffrey> One thing I noticed is that the interrupt handler is getting called a > Jeffrey> lot with event=0... the IRQ is shared with other cards, does that > Jeffrey> mean that handler will be called when one of the other sharing boards > Jeffrey> generates an interrupt? > > I am not completely sure about that. It does mean that. Every interrupt handler for a shared interrupt is called when the interrupt occurs. > If the interrupt handler is called > with event=0, then nothing should happen and so no problem should be > generated. That's how it should be (it's a requirement for shared interrupts). > But I thought that even if the interrupt is shared with > another device, the interrupt handler is only called when the corresponding > device generate an interrupt... I should verify that in the doc. Linux has no way of knowing which device caused the interrupt. That information is hidden in some chip register and only the driver knows which register that is and how to interpret its contents. Therefore Linux has to call all handlers for a shared interrupt. -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |