| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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
libraries.
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
http://git.alpinelinux.org/cgit/aports/plain/main/libraw1394/fix-types.patch.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <aaro.koskinen@iki.fi>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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
(http://subversion.ffado.org/ticket/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 <jwoithe@just42.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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/libraw1394.so.11.0.1)
by 0x405B492 : ??? (in usr/lib/libraw1394.so.11.0.1)
by 0x405BF24 : fw_loop_iterate (in usr/lib/libraw1394.so.11.0.1)
by 0x405C197 : ??? (in usr/lib/libraw1394.so.11.0.1)
by 0x405D6F8 : fw_write (in usr/lib/libraw1394.so.11.0.1)
by 0x405A292 : raw1394_write (in usr/lib/libraw1394.so.11.0.1)
by 0x805A0F2 : main (main.cpp:121)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <blueboar2@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <blueboar2@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
"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 <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Testlibraw always showed the name of the first card rather than the
name of the current card.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <stefanr@s5r6.in-berlin.de>
|
|
There is no speed argument.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
due to the API additions since 2.0.9:
raw1394_add_config_rom_descriptor()
raw1394_remove_config_rom_descriptor()
raw1394_read_cycle_timer_and_clock()
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This is an extension relative to raw1394_read_cycle_timer().
It lets the client choose a system clock other than CLOCK_REALTIME.
Use case: http://subversion.ffado.org/ticket/242
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 <stefanr@s5r6.in-berlin.de>
|
|
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
raw1394_remove_config_rom_descriptor().
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 <stefanr@s5r6.in-berlin.de>
|
|
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 <bj@mhlabs.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (whitespace changes)
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <stefanr@s5r6.in-berlin.de>
|
|
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 <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Found by cppcheck.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This symbol should not be exported. Fixes commit db5f202d5d0.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <stefanr@s5r6.in-berlin.de>
|
|
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 <phurley@charter.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <phurley@charter.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <stefanr@s5r6.in-berlin.de>
Reviewed-by: Dan Dennedy <dan@dennedy.org>
|
|
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 <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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
kernel.
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 <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Also update repo info and maintainer status per Dan's suggestion.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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>
|
|
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>
|
|
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>
|
|
The firewire-core (juju) backend of libraw1394 installs address range
mappings on the default ioctl fd, i.e. a file that represents a random
device on the chosen port. It receives incoming requests from any
sender node via this address range mapping. Due to a kernel ABI
limitation, the sender node ID is not known though. So far libraw1394
simply assumed the node ID of the device that provided the default
ioctl fd. This only works if there is only one accessible fd on the
entire bus.
This limitation caused for example libffado to fail to work with
another AV/C or IIDC device attached to the bus, because node IDs of
FCP requests and FCP responses did not match since the latter were
wrong. FCP clients which did not check sender node IDs were seemingly
not affected by this bug. The bug is fixed by a kernel ABI extension
in Linux 2.6.36. This libraw1394 change implements libraw1394's
counterpart to this ABI extension.
Hence this libraw1394 fix requires
- kernel-headers 2.6.36 or later at build time of libraw1394
- kernel 2.6.36 or later at runtime.
Otherwise, libraw1394 simply degrades to the faulty previous behaviour.
Side note: The change of IMPLEMENTED_CDEV_ABI_VERSION to 4 requires
that we fill in struct fw_cdev_allocate.region_end which was added in
the ABI v4.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Use more uniform names along the lines of abi_has_some_feature(...).
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Since linux/firewire-cdev.h header file and libraw1394 sources are
distributed separately, it is wrong to fill in a constant from that
header into the FW_CDEV_IOC_GET_INFO ioctl as the ABI version which
libraw1394 supports. This may not be forward compatible if an old
libraw1394 is compiled with a new kernel header and ran on top of a
kernel that implements new features that require a compatible
userland.
OK, the damage is already done in released versions of libraw1394.
Hence the FW_CDEV_VERSION of the kernel header file is not going to
be updated anymore in future kernel versions. (Only the version
internally to firewire-core will be incremented further.)
But let's remove the buggy usage of FW_CDEV_VERSION nevertheless.
Developers of other firewire-cdev client programs might look at
libraw1394 sources. The libraw1394 sources should not teach them
how to do it wrong.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Addresses a few compiler warnings about unused results and format string
mismatch.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
The compiler warned that size_t and %d don't go well together.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
because ieee1394_destroy_handle does it too. Otherwise, clients which
rely on the ieee1394 backend behaviour leak memory when running on the
juju backend.
Also add the ability to call fw_iso_shutdown multiple times or before
a successful context initialization. Faulty clients might rely on it
based on ieee1394 backend behaviour.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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>
|
|
The argument to FW_CDEV_IOC_STOP_ISO was missing.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Also add errno = ENOMEM because it is said that that some malloc
implementations might miss to do so.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
When EPOLLHUP event is received in fw_loop_iterate(), it is or'd
with EPOLLERR. The EPOLLHUP event was then overlooked in
handle_device_event() with unpredictable-but-generally bad results.
This problem has been rediscovered several times.
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13330
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13779
Reported-by: B.J. Buchalter <bj@mhlabs.com>
Reported-by: Michael Thireos <mthireos@vanteon.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
If running on top of the raw1394 kernel driver (any kernel version) or
on top of firewire-core (kernel version <= 2.6.29), raw1394_start_*
functions will return a value > 0 on success, not == 0. Only with
firewire-core of kernel 2.6.30 or later, == 0 is returned on success.
The exact value depends on which driver is used, on CPU architecture,
and on request payload size in case of some types of requests. In any
case, only that the value is > or == 0 on success (but == -1 on
failure) is significant to libraw1394 client applications.
This mismatch between documentation and implementation was already
present in older libraw1394 versions, including v1.x. For the time
being, do not change the implementation, only adjust the documentation.
Reported-by: Dr. David Alan Gilbert
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Questions and patches should be posted to the list rather than just sent
as personal mail to Dan. That way, more people can answer or review it
without Dan having to forward libraw1394 mails to the list all the time.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Sebastian <schseb@ubuntu.(none)>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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>
|
|
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
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)
|
|
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
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>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Each request allocated a struct request_closure which was never freed.
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>
|
|
Since "testlibraw: test all cards instead of only the first", the
actual ROM content wasn't printed anymore due to a mistake in a
printf format string.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
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>
|
|
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
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>
|
|
make target is no longer relevant because opf firewire and udev.
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
initialized
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>
|
|
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
7x unused variable, 1x assignment used as truth value, 1x pointer signedness
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>
|
|
The return value of any function should be checked if that function
uses the return value to provide some sort of status information.
Signed-off-by: Erik Hovland <erik@hovland.org>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
A function can compile without returning something always.
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>
|
|
Signed-off-by: Erik Hovland <erik@hovland.org>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
Signed-off-by: Erik Hovland <erik@hovland.org>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
|
|
|
|
to dist make target.
|
|
Makefile.am: use git-log to generate ChangeLog on make dist.
|
|
|
|
|
|
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.
|
|
give them 'fw' names instead of 'juju.'
|
|
API that has been removed.
|
|
segfault in applications.
|
|
This is currently working with legacy ieee1394 and tools/testlibraw.
|
|
|
|
Conflicts:
configure.ac
|
|
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@179 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
|
|
This can occur when libraw1394 callera receives a signal while in the read and
the caller is not using a signal handler set with signal().
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@178 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
This can occur when libraw1394 caller receives a signal while in this read and
the caller is not using a signal handler set with signal().
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@177 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
This can occur when libraw1394 caller receives a signal while in this read and
the caller is not using a signal handler set with signal().
|
|
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@175 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@174 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@173 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
|
|
happy. Adds --with-valgrind configure option.
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@172 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@171 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
/dev/raw1394, but also attempt to failover to default.
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@170 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@169 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
initializing raw1394_handle.iso_packet_infos to NULL in raw1394_new_handle
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@168 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
from high frequency isochronous code
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@167 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@165 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@164 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@163 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
event loop to make them more respectful of realtime applications
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@162 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
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
|
|
to fix bug with stalling on buffer underrun.
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@160 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@159 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
is already mentioned in doc/libraw1394.sgml but an existing comment about
raw1394_iso_xmit_init may be misleading.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@158 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@156 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@155 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@154 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@152 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
unncessary (and logically impossible) copy in get_port_info
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@151 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@150 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@149 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@148 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@147 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@146 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@145 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@144 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@143 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@142 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@141 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@140 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@139 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
supported only by OHCI.
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@138 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
(addition of functions raw1394_arm_get_buf raw1394_arm_set_buf to get and set buffers of mapped address ranges)
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@137 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@136 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@135 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@133 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@132 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@131 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@130 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@129 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
raw1394_request's.
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@128 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
RAW1394_IOC_ISO_RECV_FLUSH ioctl. Updated the ieee1394-ioctl.h file
aswell.
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@127 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@126 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
Patch from Manish Singh.
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@125 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@124 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@121 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@120 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@119 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
like it is supposed to.
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@117 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@114 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@113 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@112 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@111 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
the svn log is more than verbose enough for info seekers.
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@110 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@109 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@108 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
|
git-svn-id: svn://svn.linux1394.org/libraw1394/trunk@107 53a565d1-3bb7-0310-b661-cf11e63c67ab
|
