| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
Use more uniform names along the lines of abi_has_some_feature(...).
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>
|
| |
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
initialized
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>
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Signed-off-by: Erik Hovland <erik@hovland.org>
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.
|
|
|
give them 'fw' names instead of 'juju.'
|
Thomas Petazzoni
Jonathan Woithe
Stefan Richter
Igor Kuzmin
Clemens Ladisch
Jay Fenlason
Dan Dennedy
Jarod Wilson
Erik Hovland
Philippe Troin
Dan Dennedy
