linux1394-devel Mailing List for IEEE 1394 for Linux (Page 540)
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: Sebastien R. <Seb...@sy...> - 2000-04-09 09:28:47
|
I have implemented a fix that was proposed a while ago by Robert Ficklin <rfi...@we...>. It should solve the problem people were having with the node count staying at zero all the time. It should also solve the bug that happen when the card is initialized with no device connected to the bus, and then cannot detect any device afterward. Please try it (available from CVS at sourceforge) and tell me if you encounter any problem. As for the crash when loading the ohci driver on a Vaio with a CXD3222 chipset, if Sony wants to send me a laptop so I can try to fix it, I'll be happy to give it a shot ;-) -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-04-09 09:02:23
|
>>>>> "Bart" == Bart Nabbe <ba...@cs...> writes: Bart> Hmm I thought I gave that in my previous posting, anyhow they are Bart> attached now. The other problem, for the Ti ohci card on reset I solve Bart> using a hack: I reload the drivers until I find the number of nodes I Bart> want on the bus.. This is often the second time.. So my ieee1394 script Bart> in init.d cycles until it finds the camera and life is good. The same Bart> strategy on the Sony chip set never ever find >0 nodes :(. According to your /proc/ohci1394 dump, the card is still in bus reset... which is normal since no self-id packet is received. I'll see what I can do about that. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Andreas B. <and...@mu...> - 2000-04-07 23:04:45
|
On Fri, Apr 07, 2000 at 08:39:31PM +0900, Ken Smith wrote: > Is there support for the 4 pin 1394 port on the Sony PCG 505TX? If > there is not, what are the reasons? Is it because of a proprietary > chipset? Nobody working on it? Other? Vaio, I presume. If it has an OHCI chipset it should work, if it's the proprietary Sony chipset it doesn't because there is no driver. Either find out which chip you have or just try the OHCI driver (I think it already recognizes the chip ID of the OHCI chips used in the Vaios). > Also, I have read that 1394 storage devices are not supported. What > must be done to support them? The SBP-2 protocol is needed. That is being worked on already. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Robert R. <RRRitchey@ACM.Org> - 2000-04-07 19:22:36
|
Hi, I am new on this list so please excuse me if this has been answered. We make 1394 hardware, PC Cards and PCI cards and hubs. Our new card uses the Lucent FW323. Has anyone tried this controller yet? Would who ever is writing the OHCI driver be interested in a card? Thanks. -Bob -------------------------------------------------------------------- Robert Ritchey Meltdown Systems, LLC 1328 East Cottonwood Lane Phoenix, AZ 85048-4765 Tel: (480) 460-2652 FAX: (480) 460-2653 E-Mail: RRRitchey@ACM.org E-Mail: RRRitchey@Computer.org Website: www.MeltDownSystems.com -------------------------------------------------------------------- |
From: Al <ala...@aj...> - 2000-04-07 17:51:22
|
Hi, I'm a newbie here so apologies if this is really stupid :-) Just got a D-Link DFW500 1394 card that I'm planning to install this weekend, it's allegedly OHCI compliant so I hope that'll be painless, but if anyone has specific tips I'd welcome them. Here's the question: is anyone doing anything along the lines of using a DV-capable camcorder as a backup device for regular files? Do camcorders care what the data looks like (so long as its within DV-format frames)? (More specifically, does the Sony TRV-103 D8 camera care?) The backup/restore program would have to encapsulate filesystem datat within DV frames, which would display as so much noise if anyone tried to watch it I guess, but it'd be nice to be able to use my camcorder as a high-capacity/high-data-rate backup device (sure, I'd rather have purpose-built hardware for the job, but that stuff ain't cheap.) If there's interest and nobody is doing anything on it, I may tackle it myself (unless someone points out serious flaws in the idea), but I have precious little available time at the moment. -- Al (Yet another off-the-wall idea: is TCP/IP-over-1394 possible? Not quite gigabit ethernet, but cheaper). |
From: Ken S. <ke...@tu...> - 2000-04-07 11:46:09
|
Is there support for the 4 pin 1394 port on the Sony PCG 505TX? If there is not, what are the reasons? Is it because of a proprietary chipset? Nobody working on it? Other? Also, I have read that 1394 storage devices are not supported. What must be done to support them? The reason I ask is because I would like to join the effort and these are the two areas I am most interested in. |
From: Arne S. <ar...@sc...> - 2000-04-07 08:38:46
|
I did not even try to fix the 2GB problem yet, because I have to copy the resulting files to my Windows98 disk anyway and we have the same file size limit there too (it may be a 4 GByte limit, I'm not sure). Will the resulting binary run only on a 2.3 kernel, or will it also run on a 2.2.x kernel (at least up to the 2 GByte limit)? My current linux development system is a bit dated (SuSE 6.1, about two years old), no 64 bit functions available in that version. When my new SuSE Linux version shows up (the DVD version is supposed to be available mid-April), I'll give it a try. My entry on http://www.freshmeat.net shows already more than 130 downloads and almost 900 homepage hits... cool. Arne -----Original Message----- From: Andreas Bombe Sent: Friday, April 07, 2000 4:55 AM To: Arne Schirmacher Cc: 'lin...@li...' Subject: Re: announce: dvgrab 0.6 On Thu, Apr 06, 2000 at 06:30:28PM +0200, Arne Schirmacher wrote: > The biggest advantage is a new feature which I named "autosplit". It checks > certain flags in the DV data to see whether the current frame belongs to a new > recording. If so, it creates a new AVI file for this new recording. It will > also create new AVI files whenever the requested number of frames is exceeded > or when the AVI file reaches the 2 GByte file size limit. Regarding the 2GB limit: current 2.3 kernels should be able to do more (even on 32 bit machines). In part it was also an intended limitation in order not to break the APIs (lseek() has to be able to do relative seeks from one end to the other). The API issues are resolved with current glibcs. Either use the 64 bit functions (open64, lseek64 etc.) or define _FILE_OFFSET_BITS to 64 then the standard open etc. calls will run in large file mode. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Andreas B. <and...@mu...> - 2000-04-07 03:01:29
|
On Thu, Apr 06, 2000 at 06:30:28PM +0200, Arne Schirmacher wrote: > The biggest advantage is a new feature which I named "autosplit". It checks > certain flags in the DV data to see whether the current frame belongs to a new > recording. If so, it creates a new AVI file for this new recording. It will > also create new AVI files whenever the requested number of frames is exceeded > or when the AVI file reaches the 2 GByte file size limit. Regarding the 2GB limit: current 2.3 kernels should be able to do more (even on 32 bit machines). In part it was also an intended limitation in order not to break the APIs (lseek() has to be able to do relative seeks from one end to the other). The API issues are resolved with current glibcs. Either use the 64 bit functions (open64, lseek64 etc.) or define _FILE_OFFSET_BITS to 64 then the standard open etc. calls will run in large file mode. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Andreas B. <and...@mu...> - 2000-04-07 02:51:55
|
First, I want to remind everyone that the announce list can be used by everyone to post announcements (it's open, only messages with Subject: beginning with "Re:" are filtered, they don't belong there anyway). It's there so it might just as well be used. Second, I'd like to put more links to 1394 applications and libraries on the web site. Mail me with URLs if you have written something that could be useful to others. I don't want to pick up URLs by myself because I would like to know the author's intended permanent URL (gscanbus' URL was added in absence of the author, fix needed?). Third, a list of confirmed supported hardware would be nice on the web site. Sure, most is probably OHCI, but anyway. I.e. a list of which product contains which chip, this would be especially interesting for the Vaio laptops. Fourth, we should really complete the move over to the SourceForge list. Please don't send more messages to the old list only (cc'ed copies might be fine). Better keep to the new list so that any poster to the old list can be asked to repost to the new list. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Arne S. <ar...@sc...> - 2000-04-06 16:40:53
|
Hi all, a new version of dvgrab is available. Download it from http://www.schirmacher.de/arne/dvgrab/ .It also has some documentation in english and german language and links to other 1394 and DV related resources. The biggest advantage is a new feature which I named "autosplit". It checks certain flags in the DV data to see whether the current frame belongs to a new recording. If so, it creates a new AVI file for this new recording. It will also create new AVI files whenever the requested number of frames is exceeded or when the AVI file reaches the 2 GByte file size limit. What you can do now (and I like this feature really): hook up your camcorder, fire up dvgrab and one hour later you have a neat collection of lots of AVI files each having its own scenes. This is really useful, because most video editing software works better with a number of smaller files instead of a single huge one. And you have a workaround for that 2 GByte file size limit too. The program is now in C++. The main reason for it is that the RIFF/AVI file format leads to an OO-approach naturally, and I also got exception handling and less global variables by doing the port. Let me know whether you like it. Arne |
From: <and...@iv...> - 2000-04-06 11:23:02
|
Hi everyone, back from my holidays I am pleased to announce a new version of gscanbus that works with the current version of the Linux 1394 subsystem again. You can download it from the usual location: ftp://ftp.fokus.gmd.de/pub/cc/cats/usr/ami/ Thanks to Simon Vogl for adapting gscanbus to the new endianess policy and thanks to Andreas E. Bombe for FCP access monitoring - just what I needed. I have only tested gscanbus with PCILynx and the current CVS version right now, hopefully it will also work on OHCI this time. Bug reports from people with big endian machines are also appreciated. One bug that I could not track down yet: Whenever my host becomes the root of the 1394 topology tree, reads to the config ROM of other nodes fail. When my VCR becomes the root, everything is fine. Has someone else experienced this bug? Any ideas? bye... Andreas Micklei P.s. Please use my new email address. The old one will probably vanish soon. |
From: Manfred W. <e95...@st...> - 2000-04-06 00:33:27
|
"Timothy M. Shead" wrote: > You didn't notice that sdpAvcSubUnit::FCPHandler is a static member > function, meaning that it does not have an implicit "this" pointer, and thus > *does* have the correct prototype for use with raw1394_set_fcp_handler(). Ok. You are right. > [...discussion about ways to an object-oriented apporach...] > [...] So, would this require changes to just > libraw1394, or to the kernel code itself? I think: yes. In my opinion, the easiest way would be to store that private data in the raw-handle. For that purpose we would only have to adopt raw1394_private.h: struct raw1394_handle { int fd; unsigned int generation; nodeid_t local_id; int num_of_nodes; bus_reset_handler_t bus_reset_handler; tag_handler_t tag_handler; fcp_handler_t fcp_handler; iso_handler_t iso_handler[64]; struct raw1394_request req; quadlet_t buffer[2048]; void *private_data; // new private data to store pointer to object }; I think, that's all (I did not try it yet). Then after getting the handle via raw1394_get_handle (), we have to store our pointer in the handle. The rest would be - in your example: class sdpAvcSubUnit { // other stuff ... // ... this is the global callback function accessible by "C" ... static int RawFCPHandler(raw1394handle_t handle, nodeid_t nodeid, int response, size_t length, unsigned char *data); // This is the actual per-object callback method ... called from RawFCPHandler() ... unnecessary arguments eliminated int FCPHandler(nodeid_t nodeid, int response, size_t length, unsigned char *data); // other stuff ... }; int RawFCPHandler(raw1394handle_t handle, nodeid_t nodeid, int response, size_t length, unsigned char *data) { return ((sdpAvcSubUnit*) handle->private_data)->FCPHandler(nodeid, response, length, data); } int FCPHandler(nodeid_t nodeid, int response, size_t,length, unsigned char *data) { // Do whatever, access member data, etc. } Of course, it would also be possible to change the handler to get that user data as 6th argument; but my version requires less change of libraw1394. Manfred Weihs |
From: Andreas B. <and...@mu...> - 2000-04-05 22:45:47
|
On Tue, Apr 04, 2000 at 10:44:51PM +0200, Manfred Weihs wrote: > I do not know a "clean" solution to that problem (as long as we want to > use libraw1394). I think, the only way would be to create a new > object-oriented version of libraw. > One quick solution might be to add a field "private" or something like > that to struct raw1394_handle, which we could use to store a pointer to > our object. Then we could declare the handler as a friend function of > the class and via the pointer (because the handler has the raw-handle as > first argument, and therefore would get that pointer) we could access > the member variables of the object. Or, which is cleaner, just use this object pointer to call a class function (no friend declaration necessary). I added: void *raw1394_get_userdata(raw1394handle_t handle); void raw1394_set_userdata(raw1394handle_t handle, void *data); Should be in CVS by the time you read this. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Manfred W. <e95...@st...> - 2000-04-05 16:48:20
|
Andreas Bombe wrote: > [concerning the buffers which are handed over to the iso- or fcp-handlers] > 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. Is the data really invalid, when the handler ends, or does it stay valid until the next call of raw1394_loop_iterate()? Imagine an application which processes data that arrives on an isochannel; and everytime, when its buffer is empty, it does (one or more) raw1394_loop_iterate() until the iso_handler is executed. Does the handler really have to copy the data to a separate buffer, or would it be sufficient to store the address of the (internal) buffer in a (global) variable? The premise is - of course - that raw1394_loop_iterates (on that particular raw-handle) is only done, when we need a new iso-packet. > 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 think, that has no effet to my question above, isn't it? Manfred Weihs |
From: Andreas B. <and...@mu...> - 2000-04-04 23:16:18
|
On Tue, Apr 04, 2000 at 07:17:08PM +0200, Manfred Weihs wrote: > Andreas Bombe wrote: > > ... the byte order policy changed, now bytes appear on the bus as > > they are ordered in RAM (i.e. no hardware byte swapping is done > > anymore on little endian -- except for the header, but this is an > > internal issue). > > That is not completely true. Since the header of iso packets is stored > in the first quadlet of the buffer which is handed over to > iso_handler_t, it is not an internal issue of the driver, because also > user space applications get access to it. Yes, making the iso header also big endian in raw1394 might be good for consistency. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Rodney R. <re...@de...> - 2000-04-04 22:24:15
|
What Manfred asserts stands to reason, in order for hardware to handle headers, and for future extensibility, the hardware has to be able to parse the header. Thus the big/little endian issue doesn't stand into it: the type of the header is known, it is a bit vector, of fixed variable lengths, whose image, however, requires transposition on the quadlet boundry in little endian RAM but not in big endian RAM. The data field however is a different story its type is not known to the hardware and in little endian the DMA R/W order is reversed over big endian. In my previous discourse, I was not talking about making the ordinal value of a quadlet in memory the same in both boxes, that's an assumption of the type of data contained in the field. I was talking about the definition of binary compatibility here: the order of the bytes are addressed be the same in any box. I will expand further on the example. In order to preserve binary compatibility hardware little endian must(optimally) transpose the byte stream in situ because the DMA R/W order is different during each of these instances depending on DMA transfer size: quadlet, or doublet, or singlet. Examine the following given the message is "12345": LilI BigI Address(8)-> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 case byte(8:8) RAM-PORT r/w 1 2 3 4 5 x x x 1 2 3 4 5 x x x STREAM(X = swap) 1 2 3 4 5 x x x 1 2 3 4 5 x x x case quadlet(32:8) RAM-PORT r/w 4321 xxx5 1234 5xxx STREAM(no swap) 4 3 2 1 x x x 5 1 2 3 4 5 x x x STREAM(swap) 1 2 3 4 5 x x x 4 3 2 1 x x x 5 From this is should be apparent that, unless hardware swaps, in order for binary compatability to occur, a little endian box must swap the bytes in RAM if DMA is set to do quadlet(32:8) transfers but it does not matter if DMA is set to do byte(8:8) transfers. It also should be noted this has no consequence under some circumstances. A hard drive for instance would save and return the data in the same order regardless if bytes are swapped or not(if the parameters don't change). But, box-to-box communication requires a definition of binary compatability. A few advisories exists here once the swaping issue is resolved. First, when transfering quadlets covered in the case of the OHCI spec. Here the type of the data field is known(a possible assumption, if it be agree that) and the ordinal value is preserved when swap is set and the software does a second swap. Second, when writing data that came in from the data field bound for the header field of another packet, such as the address. Further, this brings up a new issue, if true hardware independence is to be achieved in the interface, some read-only properties of the device(low-level) layer must be known to the service(high-level) layer. Data polarity (big/little endian) is one, another is the GUID of the card. The case of the polarity property is that hardware may implement swapping but some cards may not(see the previous advisory). The case for the GUID is that the ordinal value must be preserved if not it looses its uniqueness and the method of aquisition of this value is hardware dependent. Rodney Rhoton Manfred Weihs wrote: >That is not completely true. Since the header of iso packets is stored >in the first quadlet of the buffer which is handed over to >iso_handler_t, it is not an internal issue of the driver, because also >user space applications get access to it. >BTW: It took me quite a while to find out, that the first quadlet of >this buffer is the 1394-header (stored little endian), then the >header-crc is missing, and then the rest (the data) of the packet >follows (stored big endian). Of course it makes sense that this header >is handed over to the iso handler (because it provides a means to find >out, if the packet has a CIP header), but it could be considered if it >makes more sense to change its byte order (so that _everything_ is big >endian) or to introduce new arguments for the handler (expecially Tag >and perhaps Sy) and remove the header from the buffer. Andreas Bombe wrote: > ... the byte order policy changed, now bytes appear on the bus as > they are ordered in RAM (i.e. no hardware byte swapping is done > anymore on little endian -- except for the header, but this is an > internal issue). |
From: Manfred W. <e95...@st...> - 2000-04-04 20:52:25
|
"Timothy M. Shead" wrote: > > After much playing around, I figured it out ... thanks! So, without > further ado, anyone interested in a C++ library for controlling devices > through AV/C (the protocol-of-choice for DV camcorders) should check-out > SDPAVC, located at my website: http://www.k-3d.com. The library, which Are you sure that this works. I neither compiled nor tested it, but I had a look at the code, and I see the following problem: Let's inspect the function sdpAvcSubUnit::RawCommand in sdpavcsubunit.cpp, especially line 105: raw1394_set_fcp_handler(m_Handle, FCPHandler); You try to register a handler, which has (ragarding to raw1394.h) to be of the type int (*)(raw1394handle_t, nodeid_t nodeid, int response size_t length, unsigned char *data). But according to line 134, your handler has the type int (sdpAvcSubUnit::*) (raw1394handle_t Handle, ... , unsigned char* Data). It is no ordinary function, but a member function of a class and incompatible to the type, raw1394_set_fcp_handler expects (because C++ adds a pointer to the object [the instance of the class] it belongs to as a "hidden" argument to the argument list of the function, which therefore has one parameter too many. I have the same problem. It is not possible to register a member function of a class as handler; it must be an ordinary C-function (which of course cannot access the member variable of the object [because it does not get that hidden pointer to that object]). One can work-around this by using global variables for everything the handler must access as long as there is only one object, but if there are two (or more) instances, there will be troubles (especially, if the application is multithreaded), because the handler wants to hand over things to one particular object, but the global variables are common to all objects. The objects can get individual raw-handles, but the fcp_handler (and the same applies to the iso_handlers) cannot find out, which object did the raw1394_loop_iterate (btw: you should replace raw1394_read in line 113 with a raw1394_loop_iterate-loop until the response-frame arrived) and thus cause it to be called. I do not know a "clean" solution to that problem (as long as we want to use libraw1394). I think, the only way would be to create a new object-oriented version of libraw. One quick solution might be to add a field "private" or something like that to struct raw1394_handle, which we could use to store a pointer to our object. Then we could declare the handler as a friend function of the class and via the pointer (because the handler has the raw-handle as first argument, and therefore would get that pointer) we could access the member variables of the object. Manfred Weihs |
From: Erik W. <om...@cs...> - 2000-04-04 20:01:43
|
On Tue, 4 Apr 2000, Daniel Kobras wrote: > At our institute we'd like to do ieee1394 transactions via a couple of > Vaios that are unfortunately equipped with Sony's proprietary iLink > chipsets. Since the rest of our software runs on Linux, we thought about > buying a ieee1394 CardBus card. Poking through the list archives however I > found some references several months ago that it was doubtful whether > would work via CardBus. So can someone comment on the current status of > linux1394 and PCMCIA/CardBus? Or any suggestions about what might be a > good card to look for? I bought an OHCI cardbus card a few months ago for work, and almost got it working. The issue is the linux1394 driver initialization subsystem, which is incompatible with both CardBus and the newer 2.4.x PCI subsystem. I rewrote it to deal with all forms of probing (2.2.x, 2.4.x, and old pcmcia_cs), but can't quite get the OHCI card to function. It's losing most interrupts. I should have time and priority to hack on the work in a couple days, so I'll apply the changes to the latest code and put out patches. I would expect that once validated they'll make their way into the main CVS repo, since they're necessary to be fully correct in 2.4.x kernels. Stay tuned.... Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |
From: Manfred W. <e95...@st...> - 2000-04-04 17:26:35
|
Andreas Bombe wrote: > ... the byte order policy changed, now bytes appear on the bus as > they are ordered in RAM (i.e. no hardware byte swapping is done > anymore on little endian -- except for the header, but this is an > internal issue). That is not completely true. Since the header of iso packets is stored in the first quadlet of the buffer which is handed over to iso_handler_t, it is not an internal issue of the driver, because also user space applications get access to it. BTW: It took me quite a while to find out, that the first quadlet of this buffer is the 1394-header (stored little endian), then the header-crc is missing, and then the rest (the data) of the packet follows (stored big endian). Of course it makes sense that this header is handed over to the iso handler (because it provides a means to find out, if the packet has a CIP header), but it could be considered if it makes more sense to change its byte order (so that _everything_ is big endian) or to introduce new arguments for the handler (expecially Tag and perhaps Sy) and remove the header from the buffer. Manfred Weihs |
From: Daniel K. <dan...@st...> - 2000-04-04 15:40:48
|
Hi! At our institute we'd like to do ieee1394 transactions via a couple of Vaios that are unfortunately equipped with Sony's proprietary iLink chipsets. Since the rest of our software runs on Linux, we thought about buying a ieee1394 CardBus card. Poking through the list archives however I found some references several months ago that it was doubtful whether would work via CardBus. So can someone comment on the current status of linux1394 and PCMCIA/CardBus? Or any suggestions about what might be a good card to look for? Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
From: Andreas B. <and...@mu...> - 2000-04-04 01:32:03
|
On Mon, Apr 03, 2000 at 03:20:08PM -0700, Timothy M. Shead wrote: > // Write the command ... > raw1394_write(m_Handle, 0xffc0 | m_Node, FCP_COMMAND_ADDR, 4, &Command); > > // Wait for a result ... > quadlet_t result; > raw1394_read(m_Handle, 0xffc0 | m_Node, FCP_RESPONSE_ADDR, 4, &result); > while((result & 0x0F000000) == 0x0F000000) > { > std::cerr << "sdpAvcSubUnit::RawCommand() waiting for response!" << > std::endl; > result = raw1394_read(m_Handle, 0xffc0 | m_Node, FCP_RESPONSE_ADDR, 4, > &result); > } > > ... the write works, but "read" is entering an infinite loop. Any thoughts > on what I'm doing wrong? In the meantime, the library and a couple of > sample apps will be posted later today on my website, www.k-3d.com. From what I have read about FCP communication the response is sent to the local FCP_RESPONSE register. And you can't read that out directly, you have to set up a FCP handler in libraw1394. See testlibraw.c in libraw1394 0.6 for an example. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: fullman <fu...@mi...> - 2000-04-04 00:57:35
|
Where is the linux-1394-project homepage? what's wrong? Ummm :( |
From: Andreas B. <and...@mu...> - 2000-04-03 01:04:53
|
On Tue, Mar 28, 2000 at 11:23:43PM -0800, ch...@st... wrote: > 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? That will take some time. A SBP-2 driver is required for that and there is nothing like that available yet. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Andreas B. <and...@mu...> - 2000-04-03 00:58:09
|
You are apparantly not using the current patch. Between this and the previous the byte order policy changed, now bytes appear on the bus as they are ordered in RAM (i.e. no hardware byte swapping is done anymore on little endian -- except for the header, but this is an internal issue). User programs and highlevel drivers must now swap the data on their own, which resolves some messy problems (with the data payload not being a quadlet sequence and therefore being swapped wrongly by the hardware). This also solves the length problem and now arbitrary lengths for block requests are allowed (the subsystem pads zero bytes automatically). -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Arne S. <ar...@sc...> - 2000-04-02 19:23:35
|
check out my dvgrab program: http://www.schirmacher.de/arne/dvgrab (now with a homepage both in english and german language). It saves the DV data in an AVI file, it does not display anything though. Arne -----Original Message----- From: James harris Sent: Saturday, April 01, 2000 4:07 AM To: lin...@li... Subject: Re: Some questions 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??? -devel |