I just noticed this version has been released for a while.
depends on: bug 205829
BTW, libraw1394 v2.0.0 is out now. v2.0.0 has the huge advantage that it supports both raw1394 and juju without the need for recompilation (i.e. the juju use flag is no longer necessary). In order to get juju support, kernel headers v2.6.22 need to be present. Better are kernel headers v2.6.24 because then a small ABI feature of 2.6.24's juju ABI will be compiled in (read cycle timer, needed especially for audio; raw1394 already had that feature). I therefore suggest that a build dependency on >=sys-kernel/linux-headers-2.6.24 is wired into sys-libs/libraw1394-2.0.0. Two caveats of libraw1394 v2: - The old, 1st generation isochronous API has been removed. However, this isn't present in recent kernels anymore anyway, and application programs using this API aren't supported by upstream anymore. - Because of the API change, the .so version has been bumped from .8 to .11.
PS: media-libs/libdc1394-1.2.1 is probably the most prominent package to require the 1st gen. iso API which was removed from libraw1394 v2.
Are you saying that installing libraw1394-2 breaks libdc1394-1? Could you point to some documentation on that? Thanks
Here is what I believe to know about libdc1394 v1: - It has a compile-time dependency on libraw1394's raw1394_start_iso_rcv() and friends. - Libdc1394 v1 client applications can switch between raw1394 isochronous capture (through libraw1394) and video1394 isochronous capture (by direct access to the video1394 kernel ABI). Some background: The raw1394 driver exposed two isochronous ABIs: A 1st generation ABI which was supported by the ohci1394 and pcilynx low-level IEEE 1394 drivers, and a 3rd generation ABI (a.k.a. "rawiso") which is supported by ohci1394 but was never ported to the less and less used pcilynx driver. Both rawiso and video1394 are more efficient than the initial raw1394 iso ABI and have superseded it in practice long ago. The commit which removed the deprecated 1st generation isochronous API from from libraw1394 v2: http://dennedy.org/cgi-bin/gitweb.cgi?p=dennedy.org/libraw1394.git;a=blobdiff;f=src/raw1394.h;h=d59b1b2210f3c45ab860d017585f9d7134453913;hp=89e601f33a644ffaa47486557d109227fae25258 This is the _only_ libraw1394 API change from 1.3.0 to 2.0.0. The release notes are rather terse: http://dennedy.org/cgi-bin/gitweb.cgi?p=dennedy.org/libraw1394.git;a=blob;f=NEWS The 1st generation isochronous ABI was removed from the kernel already some time earlier: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=53c96b41742a2dadd14e65c23fc119f2a2fd9f05
Created attachment 173729 [details, diff] Remove calls to old raw1394-iso functions, report failure Thank you for your very detailed analysis. If I get this correctly, using the raw1394-iso functionality is impossible on the latest kernels, and as such there is no way for libdc1394 to use them (regardless of what libraw1394 allows). libdc1394-2 doesn't use this functionality , but libdc1394-1 still needs the corresponding libaw1394-calls to build correctly. Still no one ever uses the raw1394-iso mode, as the dma transfer mode has much better performance. libdc1394-1 is still a requirement for a lot of packages in the tree, hence the effort to make it work with the attached patch. I'm assuming here that no other packages depend on the raw1394-iso functions, let me know if this is wrong. Therefore I propose to: - introduce libdc1394-1.2.2 in the tree with the attached patch - upgrade to libraw1394-2.0.0 If no other developer is interested, I will gladly perform the libraw1394 upgrade myself.
(In reply to comment #6) > If no other developer is interested, I will gladly perform the libraw1394 > upgrade myself. Do it.
> Still no one ever uses the raw1394-iso mode, as the dma transfer mode > has much better performance. Well, not very long ago I saw a posting of a coriander user who had an old version of coriander that was still on libdc1394 v1 instead of v2 (I don't remember which distro) and couldn't get it to work. He had the ABI removal log messages in his kernel log, so this user could be helped by the advise to switch his coriander to video1394. IOW, not everybody may be aware that video1394 should be used by libdc1394 v1 client applications. Hence it would be good if your patch produces an error message, saying that the failure of the unsupported function can be cured by using video1394. > I'm assuming here that no other packages depend on the raw1394-iso > functions, let me know if this is wrong. I at least am not aware of such an application which hasn't been replaced by a newer version or other application which uses one of the newer isochronous interfaces.
> - upgrade to libraw1394-2.0.0 BTW, libraw1394 v2 won't need the juju use flag anymore. But libdc1394 v2 still does.
Created attachment 174708 [details, diff] New proposed patch to disable raw capture, this time with a warning message Please review and comment...
Looks OK to me.
This is a bit overdue... Going ahead.
media-libs/libdc1394-1.2.2, including the attached patch, is now in the tree.
And now sys-libs/libraw1394-2.0.0 is available as well. I know upstream has released 2.0.1, but I haven't been able to try it yet. Closing as fixed.
A 2.0.0 to 2.0.1 update should go smoothly; it's only bug fixes. Thanks Stefaan.
Hi Stefaan, I've locally bumped libraw to 2.0.2 and gstreamer works fine with it (with USE=juju). Is there anything holding the package.mask entry? Cheers
> Is there anything holding the package.mask entry? There can be only a single kind of regression from libraw1394-1.x.y to -2.0.y, and this is due to removal of two or so ancient, long deprecated, and otherwise undocumented functions (see comment #5). Any such regressions will turn up quickly as build errors in packages which use these ancient functions. However, leaving libraw1394-2.0.y masked won't really help the discovery of any of such potentially remaining troubles. If anybody asked me, I would unmask libraw1394 v2 and then react on v2 incompatibilities of depending packages ad hoc. If any, only packages whose libraw1394 interface hasn't seen care (perhaps not even use) for many years are going to be affected. I don't remember any besides the legacy option in libdc1394 v1.
(In reply to comment #16) > Is there anything holding the package.mask entry? Only the fact that I had forgotten this change in my local cvs checkout... Fixed now. Thanks.
