summaryrefslogtreecommitdiffstats
path: root/src/fw.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Be more careful when copying response payloads on firewire-coreGravatar Stefan Richter 2010-09-071-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | When faced with bogus config ROM read responses from an audio device that did not support block requests as advertized, libffado's csr1212 code was able to recover when running on top of raw1394 but corrupted its config ROM cache when running on top of firewire-core. http://subversion.ffado.org/ticket/299 While the actual cause was a combination of firmware bug of the device and flaw in csr1212.c of libffado, the much less graceful behavior when running on firewire-core was obviously due to libraw1394's firewire-core backend. Hence, - do not write into the client's buffer if rcode != RCODE_COMPLETE, - do not copy more data than the actual response contained. The latter safeguard is not overly effective though. The libraw1394 API has no means to inform a client about the error case that a responder node sent less bytes than were requested. (The case that the responder sent more bytes than requested is covered up by the kernel already.) Should we synthesize an I/O failure? Does not sound ideal either. However, such a size mismatch should never happen; the important part of this change is the RCODE_COMPLETE check. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Implement raw1394_(start_)phy_packet_write() on firewire-coreGravatar Stefan Richter 2010-09-071-3/+3
| | | | | | | Requires kernel 2.6.36 or newer at runtime and linux-headers 2.6.36 or newer at build time. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Filter incoming requests per cardGravatar Stefan Richter 2010-09-071-0/+1
| | | | | | | | | | | | | If multiple cards are installed, firewire-core will emit requests from nodes on any of the cards to clients. This is not expected by libraw1394 clients since a raw1394handle_t is bound to a single card alias port. On kernel 2.6.36 and newer we can filter out requests from other cards. Note that we still need to call the response ioctl in order to release kernel resources associated with an inbound transaction. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Treat the kernel's iso context handle as opaque itemGravatar Stefan Richter 2010-09-071-0/+1
| | | | | | | | Libraw1394 must not rely on the kernel always handing out the value 0 as handle of the (first) allocated isochronous I/O context. For now this assumption is true but it may not stay that way forever. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Remove an unused struct memberGravatar Stefan Richter 2009-05-301-1/+0
| | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Use new async stream ioctlGravatar Stefan Richter 2009-05-301-1/+1
| | | | | | | | This implements asynchronous streams on juju, i.e. enables raw1394_async_stream() and raw1394_start_async_stream() to work with the new firewire kernel stack. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Use new iso resource allocation ioctlsGravatar Stefan Richter 2009-05-301-0/+7
| | | | | | | | | | | This allows raw1394_bandwidth_modify() and raw1394_channel_modify() to work on juju without write access to the IRM's character device file. If either the build-time requirement of firewire-cdev header ABI >= v.2 or the runtime requirement of firewire-core ABI >= v.2 is not satisfied, the code falls back to transactions to the IRM as before. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Change the license of the "juju" fw*.[hc] files to LGPL v2.1 as approvedGravatar Dan Dennedy 2009-02-031-13/+3
| | | | | | | by Kristian Hogsberg in an e-mail to the linux1394-devel mailing list on Feb 3, 2009. Signed-off-by: Dan Dennedy <dan@dennedy.org>
* Work without permission to access local node's /dev/fw*Gravatar Stefan Richter 2009-01-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On 10 Jan, David Moore wrote: > On Sat, 2009-01-10 at 19:28 +0100, Stefan Richter wrote: >> @@ -161,14 +160,16 @@ scan_devices(fw_handle_t handle) ... >> + for (j = 0; j < i; j++) >> + if (ports[j].card == get_info.card) >> + continue; >> + > > That continue statement doesn't do what you intended I think. From: Stefan Richter <stefanr@s5r6.in-berlin.de> Subject: [PATCH] Work without permission to access local node's /dev/fw* Fix for juju backend: libraw1394 required write permission to the character device file of the local node(s) in order to enumerate cards and for a number of other operations. This forced users to either run applications like dvgrab and kino with elevated privileges, or to configure write permission for all /dev/fw* or at least for local nodes' /dev/fw*. We now use the first accessible file which was found for each card for as many tasks as possible, instead of the local node's file. This allows distributors or admins to implement stricter access rights (default off, e.g. only on for AV/C and IIDC devices) without sacrificing functionality of said class of applications. Access to the local node is now only required by low-level tools like gscanbus. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Dan Dennedy <dan@dennedy.org>
* Fix iso_shutdown with juju firewire stackGravatar Jarod Wilson 2008-12-081-0/+1
| | | | | | | | | | | | | | | | | | Make iso start/stop/start sequences on the same handle, such as those used by apps such as MythTV behave as expected. I can finally watch video off my cable box over FireWire using MythTV w/the juju stack now. :) Initially, seemed a one-liner might be the ticket (setting handle->iso.fd = -1 at the end of fw_iso_shutdown()), but that led to memory corruption and a locked up system. What ultimately worked was essentially mimicking what the old stack did to track iso state, and call fw_iso_stop() from fw_iso_shutdown() as needed. Nb: Only lightly tested with iso receive via MythTV, but its all fairly straight-forward, I think. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Dan Dennedy <dan@dennedy.org>
* [libraw1394 patch] Unify {ieee1394,fw}_bandwidth_modify()Gravatar Stefan Richter 2008-12-031-3/+0
| | | | | | | | | | | | because they do the same. We only may want a separate fw_bandwidth_modify() in the future when firewire-core gains a special ioctl() for that. (Not runtime-tested, but it looks good to me.) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Dan Dennedy <dan@dennedy.org>
* [libraw1394 patch] Fix raw1394_channel_modify() on firewire-coreGravatar Stefan Richter 2008-12-031-3/+0
| | | | | | | | | | | | | | | | | | | (juju) Reported by Adrian Knoth: fw_channel_modify() was unable to allocate some channels which were actually free. http://marc.info/?l=linux1394-devel&t=122818128900002 This can be easily fixed by replacing fw_channel_modify() by ieee1394_channel_modify() because this is highlevel enough to work with Juju as well. We only may want a separate fw_channel_modify() in the future when firewire-core gains a special ioctl() for that. Also fix a documentation typo: raw1394_channel_modify() did not show up in extracted API documentation due to a cut'n'paste typo in raw1394.h. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Dan Dennedy <dan@dennedy.org>
* Fix raw1394_read_cycle_timer after juju integrationGravatar Stefan Richter 2008-07-051-0/+2
| | | | | | | | The ieee1394 version of raw1394_read_cycle_timer() fell over the cliff in "First cut at integrating juju". This brings it back and adds a juju version of it. Also correct a typo in the inline documentation: s/get/read/
* Move the source code files in the juju directory into the src directory andGravatar Dan Dennedy 2008-04-301-0/+257
give them 'fw' names instead of 'juju.'