Reported by Guus Sliepen: "make doc" failed due to missing doctype,
unknown elements, and duplicate element IDs in libraw1394.sgml.
The fix is to declare a recent DTD (matching the one which is used
in current Linux kernel documentation docbooks) and to make the
conflicting element IDs unique.
The latter part of the fix is just temporary. In order to avoid the
conflict when the documentation is updated the next time, also fix the
kerneldoc comments of the respective API elements: These are typedefs,
hence kernel-doc needs their comments prepended by "typedef ".
Tested with Gentoo's docbook-xml-dtd 4.5, docbook-xsl-stylesheets
1.75.2, docbook-sgml-utils 0.6.14, and openjade 1.3.2-r1.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
The number of packets is a 4th of the number of header bytes (in case of
ABI version 1). Also, wrap after an increment over 8000.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This change is essentially cosmetic: Set fields of structs passed to
the kernel via ioctl so that valgrind will not complain about them.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, comments)
More accurately report the cycle on which isochronous packets were
received. Only affects libraw1394 when used with kernel 2.6.29 or
older.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, whitespace)
While firewire-core's iso reception ABI was fixed in its version 2 to
report the cycle of each received packet to userspace like rawiso does,
this same enhancement was forgotten to add to the iso transmission ABI,
causing FFADO to fail to set up and maintain streaming.
Since kernel commit 31769cef2e973544164aa7d0db2e2024660d5e21, we also
get iso xmit cycles in fw_cdev_event_iso_interrupt.header. Pass these
to the iso receive handler. In case of older kernels, calculate cycles
based on the cycle of the iso interrupt event. These are inaccurate but
better than nothing.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, whitespace)
libraw1394 takes a negative IRQ interval to mean "every 256 packets"
with the juju backend, which doesn't work well if you don't queue that
many. Use buf_packets / 4 like the ieee1394 version.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (order, comment)
Date: Sun, 14 Jun 2009 11:51:33 +0100
From: Mike Auty <mike.auty@gmail.com>
Subject: [patch libraw1394-2] src/makefile.am expects FW_DIR to be set,
but configure only sets it if given --with-fw-dir
Here's a very small patch for the configure system of
libraw1394-2.0.{0,1,2}. At the moment, if configure is called without
--with-fw-dir, then FW_DIR doesn't get specified. The Makefile includes
the line INCLUDES=-I$(FW_DIR) and so in the compilation we get a -I not
followed by anything sensible. That can cause compilation issues in
certain circumstances (see Gentoo bug 272540), so this patch ensures
that INCLUDES is only set if --with-fw-dir was specified.
Please let me know if there's any problems with the patch or if I've
submitted it to the wrong place or in the wrong way. Thanks...
Mike 5:)
[1] http://bugs.gentoo.org/272540
Signed-off-by: Dan Dennedy <dan@dennedy.org>
Previously, /dev/fw* and hence files like /dev/fwmonitor were probed
which may have bad effects if the client runs with access privileges.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
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>
In the firewire-cdev ABI v1, the kernel exported only the timestamp
of interrupt packets. libraw1394 estimated the cycle of all packets
between interrupt packets by continuously incrementing the cycle.
In v2 of the ABI, we can obtain an accurate timestamp of each packet
as provided by the OHCI controller. AFAIU, this is also what you got
from raw1394/ ohci1394.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
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>
This implements broadcast transactions on juju.
(Broadcast transactions are write transactions to PHY ID 63,
not to be confused with isochronous or asynchronous streams.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Most of them do this already, only a few missed it.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
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>
When performing a lock transaction (such as with fw_lock) under Juju, 4
bytes of the stack gets corrupted. This is because the lock transaction
has 8 bytes of data sent and 4 bytes received. Since the transaction
"length" is specified as 8, handle_device_event() copies 8 bytes into
the destination variable instead of the desired 4, and overflows into
the stack by 4 bytes.
This patch fixes the corruption by adding an extra "out_length" argument
to the send_request() function so that both in_length and out_length can
be specified separately.
Signed-off-by: Dan Dennedy <dan@dennedy.org>
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>
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>
(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>
The buffer pointers were uninitialized, leading to segfault in memcpy.
Bug report and initial version of the fix by Adrian Knoth.
Signed-off-by: Dan Dennedy <dan@dennedy.org>
When using strncpy with the exact size of the destination string the
string may end up lacking null termination because the source string is
bigger then the destination.
Signed-off-by: Erik Hovland <erik@hovland.org>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
When an unsigned type is assigned a signed value, the
negatived value is never seen.
Signed-off-by: Erik Hovland <erik@hovland.org>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
Unsigned values do not return signed values when subtracted
and the right operand is larger then the left operand.
Signed-off-by: Dan Dennedy <dan@dennedy.org>
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/
While trying to track down some crashes in kino, I found the following problems
with libraw1394:
* There is a DIR* leak in raw1394_set_port().
* Lots of data structures are not fully initialized when calling IEEE1394
ioctl()s. These cause valgrind errors (benign, as valgrind does not know
how to interpret all ioctls. However these also cause kino to crash in
libraw1394. I've added a bunch of memset()s to prevent this problem from
happening.
Forward-ported to libraw1394 git tree by Jarod Wilson.
This would be returned when the callback doesn't have enough data to
create a complete packet. This can occur when the xmit buffers are
bigger than the buffers supplying the data. It is not nescessarily an
error, because there are enough packets in the xmit buffer. This
response could give the data supplyer more time to fill the intermediate
buffer without losing any packets.
Signed-off-by: Pieter Palmers <pieterp@joow.be>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@161 53a565d1-3bb7-0310-b661-cf11e63c67ab
Stefan Richter
Jay Fenlason
Dan Dennedy
David Moore
Jarod Wilson
Erik Hovland
Philippe Troin
Dan Dennedy
Dan Dennedy
ddennedy