Commit Graph

297 Commits

Author SHA1 Message Date
Peter McGoron 4338782053 add myself 2022-09-20 01:11:30 -04:00
Peter McGoron ca935a4cc7 add copyright notices; change version to v3.0.0-mcgoron-dev 2022-09-20 01:10:41 -04:00
Peter McGoron e9aac32069 add dummy arm_tag_handler to raw1394 implementation 2022-09-20 01:10:19 -04:00
Peter McGoron 33ba4bb961 add .gitignore 2022-09-20 01:09:52 -04:00
Peter McGoron 48b2af0507 Implement virtual memory for ARM manager
Instead of allocating memory for address range mappings (ARM) and handling all
reads and writes to said memory, the new ARM manager calls a function for each
received request with the data, transaction code, and allocation information.
The ARM tag manager now must handle validation of memory accesses and
retreive/write the data. This allows implementations to use network resources
or generated data as memory.

The ARM manager no longer automatically sends response packets. It is the
responsibility of the user to send response packets using

The interface is not implemented for raw1394 and will probably never be
implemented for raw1394. It is for firewire-cdev (modern Linux) only.
2022-09-20 00:58:16 -04:00
Stefan Richter 410e6dca92, Changelog, NEWS: update to version 2.1.2
Signed-off-by: Stefan Richter <>
2016-04-03 16:44:36 +02:00
Thomas Petazzoni 0ef8fab9e4 testlibraw: build the CLOCK_MONOTONIC_RAW test conditionally
CLOCK_MONOTONIC_RAW is a somewhat recent addition, and some older
toolchains/kernels may not have the support for it. Therefore, we
build the part of the test that uses CLOCK_MONOTONIC_RAW only when
this definition is available.

Signed-off-by: Thomas Petazzoni <>
Signed-off-by: Stefan Richter <>
2016-03-20 17:08:48 +01:00
Thomas Petazzoni 637359805c Use <stdint.h> types instead of non-standard types
The __uint32_t type is not a standard type, and not necessarily
provided by all C libraries. However, <stdint.h> provides a set of
standard types, which are guaranteed to be available with all C

This patch therefore changes __uint32_t to uint32_t, which allows to
fix the compilation with the Musl C library.

This patch is already used by the Alpine Linux distribution and the
Buildroot build system.

Original patch from

Signed-off-by: Thomas Petazzoni <>
Signed-off-by: Stefan Richter <>
2016-03-20 17:08:48 +01:00
Stefan Richter a8b9a1b71f, Changelog, NEWS: update to version 2.1.1
Signed-off-by: Stefan Richter <>
2015-04-28 23:35:11 +02:00
Aaro Koskinen 042ddc6d1e Align fw_handle buffer for 64-bit access
Align fw_handle buffer for 64-bit access. This fixes SIGBUS on SPARC
when capturing DV stream with "dvgrab".

[Stefan R:  If libraw1394 is compiled for 32 bit userland, struct
fw_handle.buffer was only 32 bit aligned.  Various *__u64 accesses
happen to the buffer, and those accesses require 64 bit alignment on
some CPU architectures.  The bug certainly affected all libraw1394
client applications on such architectures with 32 bit userland.]

Signed-off-by: Aaro Koskinen <>
Signed-off-by: Stefan Richter <>
2015-04-28 22:39:11 +02:00
Jonathan Woithe c756fb8321 Prevent requests for previously provided iso tx packets
This bugfix grew out of an extended investigation into a problem encountered
by a small number of people running FFADO.  FFADO would report that the tx
iso cycle number supplied to the iso tx callback seemingly went backwards -
something which should not ordinarily occur.  The bug seemed to be sensitive
to timing and in some cases would disappear when debug traces were inserted
into either FFADO or libraw1394.  In essence, libraw1394 was requesting tx
data for cycles which had already been requested.

Initial discussions can be found in the thread "Problem with RME FF800. Can
not start jackd" on the ffado-user mailing list.  A followup investigation
is tracked in FFADO ticket number 379
( and referenced in the thread
"Revisiting backward cycle number sequence (ticket 379)" on ffado-devel.
The latter mailing list thread includes a lengthy explanation of what I
think is happening.

To summarise, the root of the problem seems to be that on certain machines
under certain conditions, something causes the kernel to post an iso tx
event at a time when fewer than irq_interval packets have been transmitted.
Unfortunately it has not been possible to determine the underlying cause of
this.  Whatever the cause, tests carried out with the reporter of ticket 379
have shown that it is occurring.  As a result, the adjustment to
libraw1394's packet_count must be done with reference to the number of
packets reported as transmitted by the kernel instead of simply assuming
that irq_interval packets have been sent.

A patch implementing this fix is at the end of this post.  This fixes the
problem when the newer ABI is in use, which provides tx packet timestamps
(and thus an indication of the number of packets actually transmitted) to
userspace.  It does not address the problem when the older ABI is used, but
given the nature of the problem I don't think it's possible to fix it
without access to the timestamps (or at least without some way to determine
the number of packets really transmitted).

Testing by "juanramon" (see ticket 379) has demonstrated that it fixes the
"backward cycle number" problem on his machine.

Thanks to Andreas Hehn and "juanramon" for their invaluable help in tracking
this down.

Signed-off-by: Jonathan Woithe <>
Signed-off-by: Stefan Richter <>
2015-04-28 22:16:16 +02:00
Lee Cewd 242ed444d3 Fix memory leak in response handler
A temporarily allocated buffer which is used to pass data from libraw1394's
event loop to the Address Range Mapping callback was never freed.
This was pointed out by the following valgrind trace:

3067120 (3066560 direct, 560 indirect) bytes in 10952 blocks are definitely lost in loss record 36 of 36
at 0x4029F6F : malloc ()
by 0x405B1B5 : ??? (in usr/lib/
by 0x405B492 : ??? (in usr/lib/
by 0x405BF24 : fw_loop_iterate (in usr/lib/
by 0x405C197 : ??? (in usr/lib/
by 0x405D6F8 : fw_write (in usr/lib/
by 0x405A292 : raw1394_write (in usr/lib/
by 0x805A0F2 : main (main.cpp:121)

Signed-off-by: Stefan Richter <>
2015-04-28 22:09:12 +02:00
Stefan Richter d80678dc55 Save and restore errno in raw1394_new_handle{,_on_port} for legacy applications
Since dual-stack capability was added to libraw1394, raw1394_new_handle()
and raw1394_new_handle_on_port() began to alter errno even when succeeding.
This breaks old application code which contains the bug of checking for
failure in errno rather than in the return code of said functions, or
similar bugs with wrong assumptions about errno.

While those applications should be fixed, it may not always be possible or
feasible to do so.  Hence add a workaround to libraw1394 which saves and
restores errno in said two functions.

From a superficial review of dispatch.c, it seems that these two functions
are the only ones where such a workaround may be needed.  However, this may
not be true if any fw_XYZ() function implementation differs from the
counterpart ieee1394_XYZ() function in the way that the former alters errno
during successful execution while the latter does not.  To be clear,
altering errno in absence of failure is absolutely allowed in library code
(except for signal handlers), yet it may be unexpected and be perceived as
a library or kernel regression if the application client code is buggy in
this regard.

Reported-by: Vladimir Romanov <>
Signed-off-by: Stefan Richter <>
2013-08-24 13:07:37 +02:00
Stefan Richter ba8d2119ba tools: Fix startup of dumpiso and sendiso on juju
Quoting the errno manual:

"[errno] is set by system calls and some library functions in the
event of an error to indicate  what went wrong.  Its value is
significant only when the return value of the call indicated an
error (i.e., -1 from most system calls; -1 or NULL from most library
functions); a function that succeeds is allowed to change errno.
Valid error numbers are all nonzero; errno is never set to zero by
any system call or library function."

Dumpiso and sendiso checked for raw1394_set_port() failure by
looking at errno rather than by looking at the function's return
code.  This happened to work on top of raw1394 by lucky incident but
no longer works on top of firewire-core.

Reported-by: Vladimir Romanov <>
Signed-off-by: Stefan Richter <>
2013-08-24 11:51:11 +02:00
Stefan Richter 77dd78e3b4 Documentation improvement: return code of raw1394_read_cycle_timer{,_and_clock}
"the error code of the ioctl" is always -1.  And ioctl() sets errno for us.
So let's say this in a way which is less likely to be misunderstood.

Signed-off-by: Stefan Richter <>
2012-07-31 20:31:35 +02:00
Stefan Richter 4de07a63b5 Changelog, NEWS: update to version 2.1.0
Signed-off-by: Stefan Richter <>
2012-07-29 12:01:44 +02:00
Stefan Richter a24ab81d57 testlibraw: Fix printing of card name
Testlibraw always showed the name of the first card rather than the
name of the current card.

Signed-off-by: Stefan Richter <>
2012-06-30 19:13:35 +02:00
Stefan Richter d50f7381b2 Add raw1394_get_speed() API
This lets initiators of isochronous streams or asynchronous streams from
or to the local node figure out what maximum speed can be configured.

Furthermore it can be used to display connection speeds for informative
purposes without having to perform topology analysis (in case of 1394a
buses) or extensive phy port status queries (in case of 1394b buses).

To be in line with other existing libraw1394 APIs which use nodeid_t
variables, this API identifies a node only via a card:nodeID tuple which
is unsafe against generation changes.  A node can only be properly
identified by card:generation:nodeID tuples.  However, since this new
API extension and libraw1394 as a whole is mainly aimed towards existing
libraw1394 client code bases rather than new developments, I decided
against making this call race free but somewhat more difficult to use in
typical existing client code.

A unit test for the new call is added to testlibraw as well.

Signed-off-by: Stefan Richter <>
2012-06-30 19:02:20 +02:00
Stefan Richter d4e754165e Trivial whitespace normalization in ieee1394.h and raw1394.h
Signed-off-by: Stefan Richter <>
2012-06-30 17:38:45 +02:00
Stefan Richter 03faa97445 Add 1394b speed codes to <libraw1394/{ieee,raw}1394.h>
This catapults the libraw1394 API into the year 2002.

Actually, passing speed codes of 3...5 into the relevant libraw1394
functions should be working already since the kernel gained 1394b
support a long time ago and libraw1394 does not check values.
The added definitions are only for clarity and to fully match the
argument type in the function declarations.

Signed-off-by: Stefan Richter <>
2012-06-30 16:46:55 +02:00
Stefan Richter 300ac84d06 Fix documentation of raw1394_iso_multichannel_recv_init()
There is no speed argument.

Signed-off-by: Stefan Richter <>
2012-06-30 16:33:58 +02:00
Stefan Richter d0881b4eff Remove now unused code
Signed-off-by: Stefan Richter <>
2012-06-24 00:52:42 +02:00
Igor Kuzmin 662d6534c7 Disable power-of-2 alignment of isochronous I/O buffers
This can save some memory.  (The library user can always round max
packet size himself if it's needed for some reason.)

Signed-off-by: Stefan Richter <>
2012-06-24 00:43:11 +02:00
Igor Kuzmin 82b51be678 Enable write access to isochronous reception buffer
Signed-off-by: Stefan Richter <>
2012-06-24 00:42:16 +02:00
Stefan Richter f880dd00c7 Increase libtool version to 2.1.0
due to the API additions since 2.0.9:

Signed-off-by: Stefan Richter <>
2012-06-18 02:07:31 +02:00
Stefan Richter 5b4cffe9d7 Add raw1394_read_cycle_timer_and_clock() API
This is an extension relative to raw1394_read_cycle_timer().
It lets the client choose a system clock other than CLOCK_REALTIME.

Use case:

The underlying ioctl supports reading the system clock with nanoseconds
resolution.  The new libraw1394 call sticks with microseconds resolution
though.  This makes transition from (or parallel use with)
raw1394_read_cycle_timer() easier.  Besides, the call itself takes longer
than a  microsecond, primarily due to a costly MMIO read (on many
controllers even three or more MMIO reads).

Unit tests with CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW are added to
testlibraw as well.

Signed-off-by: Stefan Richter <>
2012-06-18 01:53:32 +02:00
Stefan Richter 56056a9607 Tweak raw1394_add_config_rom_descriptor() API, add documentation and test case
To conform with 'size' arguments of other libraw1394 calls, change the one in
raw1394_add_config_rom_descriptor() from quadlets to bytes.  This breaks runtime
compatibility with potential clients that were written against B.J.'s original
patch, hence reorder arguments just to break compatibility also at compile time.

Change errno to ENOSYS (function not implemented) when called while running on
top of raw1394.

Allow &token to be NULL for convenience of clients which don't require

Add exhaustive documentation.  Much of it is copied from the documentation of
the underlying ioctl.

Add example code which doubles as unit test in testlibraw.

Signed-off-by: Stefan Richter <>
2012-06-18 00:19:23 +02:00
B.J. Buchalter f3c9af36c2 Add raw1394_add_config_rom_descriptor() and raw1394_remove_config_rom_descriptor() API
This adds support of the firewire-core (juju) ABI to add and remove config ROM directories
or descriptors.  The raw1394 ABI supports similar requests, but for now we leave the two
functions unimplemented when running on top of raw1394.

Signed-off-by: Benjamin Buchalter <>
Signed-off-by: Stefan Richter <> (whitespace changes)
2012-06-17 22:00:40 +02:00
Stefan Richter c6753dfcc2, Changelog, NEWS etc.: update to version 2.0.9
Signed-off-by: Stefan Richter <>
2012-06-02 16:48:26 +02:00
Stefan Richter b7f4eaeaaf Remove unused code
Signed-off-by: Stefan Richter <>
2012-05-25 23:27:45 +02:00
Stefan Richter d2936622ab Include local firewire-*.h instead of system-wide <linux/firewire-*.h>
This guarantees that all features of libraw1394 are actually built in.
Before, some features and fixes would be silently dropped if too old
system headers (typically provided by a package called linux-headers)
were present.

An alternative would be to keep using system headers but add warnings
during the ./configure stage if old headers were encountered.  But this
helps only the person who builds libraw1394 (if there is a person
involved at all), not the users who have no reliable way to determine
how the library binary was built.

Another alternative would be to change the former soft dependency on
certain linux-headers versions into a hard dependency, i.e. fail the
build in absence of too old headers.  This would add an inconvenience
in setting up the build environment though:  The system headers would
have to be updated or a private copy of linux/firewire-*.h be specified
by way of the --with-fw-dir configure switch.

Anyhow.  The libraw1394 sources now already bring a suitable copy of
the two header files.  The --with-fw-dir configure switch is no longer
useful and is removed.

Signed-off-by: Stefan Richter <>
2012-05-25 22:19:43 +02:00
Stefan Richter b1dd541823 Add firewire-{cdev,constants}.h from Linux v3.4
Add copies of the Linux kernel header files but don't #include them just yet.
These are exact copies of the files from linux-3.4.  In case that we eventually
want updates from later kernels, a diff of the kernel's firewire-c*.h between
v3.4 and then should do the trick.

Signed-off-by: Stefan Richter <>
2012-05-25 21:27:40 +02:00
Clemens Ladisch d3ba40481f Implement raw1394_iso_recv_flush() on Juju
Signed-off-by: Clemens Ladisch <>
Signed-off-by: Stefan Richter <>
2012-03-19 22:52:41 +01:00
Guus Sliepen 39249705c0 Fix incorrect use of == instead of =.
Signed-off-by: Stefan Richter <>
2012-02-19 19:57:42 +01:00
Guus Sliepen e31d8bed56 Remove UTF-8 whitespace.
Found by cppcheck.

Signed-off-by: Stefan Richter <>
2012-02-19 19:53:14 +01:00
Stefan Richter a22b06e6c6, Changelog, NEWS etc.: update to version 2.0.8
Signed-off-by: Stefan Richter <>
2012-02-19 14:52:40 +01:00
Stefan Richter d72d1979fb Make a symbol static
This symbol should not be exported.  Fixes commit db5f202d5d.

Signed-off-by: Stefan Richter <>
2012-02-05 19:38:32 +01:00
Stefan Richter 2094c86d5c Continue inotify event handling even after failure in one event
If read() on the inotify handle gave us several events at once, and handling
one of them resulted in whatever error, there is little reason not to try
handling the rest of the events.

Signed-off-by: Stefan Richter <>
2012-02-05 12:02:37 +01:00
Peter Hurley c6569f39f1 Process multiple inotify events
If multiple inotify events are presented, process *all* of them.
This can happen when several device adds are pushed simultaneously.
handle_inotify() was refactored.

Signed-off-by: Peter Hurley <>
Signed-off-by: Stefan Richter <>
2012-02-05 11:18:40 +01:00
Peter Hurley ea4acf08bc Reset device fd upon error condition in handle_inotify()
If an error is encountered while adding a new device in inotify
handling, make sure the fd is marked invalid (-1).

Signed-off-by: Peter Hurley <>
Signed-off-by: Stefan Richter <>
2012-02-05 10:32:44 +01:00
Stefan Richter 8e433bf584 retry raw1394_read/write/lock/lock64 with delays after ack-busy
Applications or higher-level libraries have retry strategies of their own
in place, but they don't work too well sometimes.  For example, old
Panasonic camcorders require pauses in the order of several milliseconds
between response of a former transaction and request of the next one,
but libavc1394 and libiec61883 retry already after 20 microseconds.

This change cures all FCP transaction failures ("send oops") in kino and
dvgrab that I was getting with Panasonic NV-DX110.  According to reports,
Panasonic AG-EZ30 and Grundig Scenos DLC 2000 were affected too.

The additional latency in raw1394_read/write/lock/lock64 appears to be
the better alternative compared to terminal I/O failures.  Besides, a
caller of this blocking request API should at least in theory be
prepared to cope with transaction durations in the order of a few seconds.
IEEE 1394 specifies split transaction timeouts of up to 8 seconds.  An
application which needs more control should use the non-blocking request
API, i.e. raw1394_start_read/write/lock/lock64.

We specifically only retry after ack-busy, not after any of the other
types of transaction failures that may or may not succeed if retried.

This change is only done in the firewire-core backend (a.k.a. juju).
The same could be added to the raw1394 backend (a.k.a. linux1394) but is
not as important there, perhaps because transaction completion latency
in the ieee1394 core very much increases the success rate of existing
retry code in libavc1394 and friends.

Note, this does not fix every and all FCP transaction problems.  There
are e.g. certain JVC camcorders which do not properly complete FCP
transactions if an application frequently polls for status or requests
status right before a control request, even with an order of magnitude
greater delays than used in this patch.

Signed-off-by: Stefan Richter <>
Reviewed-by: Dan Dennedy <>
2011-10-22 10:58:43 +02:00
Stefan Richter db5f202d5d redirect Config ROM reads into the kernel's ROM cache
The kernel already read each node's Configuration ROM and cached it.
So let all libraw1394 clients read from that cache instead of having
to perform all those transactions all over again.

This reduces bus traffic at application start-up and at each bus reset.
It also makes all Configuration ROM accesses fool-proof and robust.

This together with the kernel patch "firewire: core: handle ack_busy
when fetching the Config ROM" lets me use an old Panasonic camcorder
which requires us to keep pauses between response and request ---
longer than librom1394's retry pause --- with dvgrab (though still
with frequent failures of write requests to FCP_COMMAND, i.e. with lots
of "send oops" noise in the console and occasionally having to repeat
key-presses in interactive mode).

For simplicity of implementation, only the blocking raw1394_read() is
modified, not the nonblocking raw1394_start_read().

Signed-off-by: Stefan Richter <>
Signed-off-by: Dan Dennedy <>
2011-08-21 20:25:50 +02:00
Stefan Richter 52099f7148, Changelog, NEWS: update to version 2.0.7
Signed-off-by: Stefan Richter <>
2011-03-08 20:13:51 +01:00
Clemens Ladisch 793b7639cf fix start_on_cycle on firewire-core
Libraw1394 uses raw1394's convention of cycle numbers always being less
than one second, i.e., in the range 0..7999.

Firewire-core uses raw cycle numbers as used by the hardware, i.e., with
several additional bits for the seconds.  This was correctly handled
when presenting timestamps returned by the kernel to the application,
but the application's start_on_cycle value was passed directly to the

To fix this, do the same calculations that ohci1394 did internally,
i.e., interpret the start_on_cycle value as relative to the current
seconds value of the cycle timer.

Signed-off-by: Clemens Ladisch <>
Signed-off-by: Stefan Richter <>
2011-02-25 19:45:49 +01:00
Clemens Ladisch 728f538340 do not delay iso packet queueing
Libraw1394's attempt to optimize away the packet queueing ioctl syscall
overhead was a little bit too successful: when used with FFADO's
streaming system, it ended up delaying packets after their intended
transmission time.

For now, to ensure correctness, don't try to optimize anything.

This makes FFADO playback on Juju with my DICE work.

Signed-off-by: Clemens Ladisch <>
Signed-off-by: Stefan Richter <>
2011-02-25 18:42:55 +01:00
Stefan Richter 9f2e0dac88, Changelog, NEWS etc.: update to version 2.0.6
Also update repo info and maintainer status per Dan's suggestion.

Signed-off-by: Stefan Richter <>
2010-11-01 23:25:36 +01:00
Stefan Richter 20df6877ae arm on firewire-core: Remove leftover debug printfs
Signed-off-by: Stefan Richter <>
2010-10-20 21:08:23 +02:00
Stefan Richter 7416da6112 Be more careful when copying response payloads on firewire-core
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.

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 <>
2010-09-07 11:48:18 +02:00
Stefan Richter 824ababa4d Implement raw1394_(start_)phy_packet_write() on firewire-core
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 <>
2010-09-07 11:27:09 +02:00
Stefan Richter 926e9ea3ad Filter incoming requests per card
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 <>
2010-09-07 11:27:03 +02:00