8:28 a.m.
I am running 7.92, and I see that the new firewire stack is in place.
There is a page at the linux1394 wiki that suggests that kernel
packagers build the old stack into the kernel for the time being:
http://wiki.linux1394.org/JujuMigration
Any chance of this happenign for Fedora 8?
Doug
8:46 a.m.
I am running 7.92, and I see that the new firewire stack is in
place.
There is a page at the linux1394 wiki that suggests that kernel
packagers build the old stack into the kernel for the time being:
http://wiki.linux1394.org/JujuMigration
Any chance of this happenign for Fedora 8?
Right below where it says the best advise is to use the old drivers it
also says :
Building the new drivers is only for advanced users (who for example
want the better speed of firewire-sbp2 relative to sbp2, on the
hardware on which the new drivers already work) - and for distributors
who know what is required in userspace to make use of the new drivers
(i.e. a patched libraw1394, a libdc1394 prerelease, adapted scripts
and config files etc.).
I suspect "distributors who know what is required in userspace" covers
Fedora and hence the required patches are probably all there.
I believe also it makes firewire generally a lot more stable even
though there are a few regressions.
Peter
9:05 a.m.
On Wed, 2007-10-31 at 13:46 +0000, Peter Robinson wrote:
I believe also it makes firewire generally a lot more stable even
though there are a few regressions.
The regression is that on FW interfaces which
support OHCI 1.0 instead
of OHCI 1.1, dv grabbing is not possible. It appears that most FW cards
are still OHCI 1.0. Work seems to be underway to support the older ones
too, but until then I think the only possibility is to buy a new card.
BTW the new stack is already in F7.
--
Gérard Milmeister
Langackerstrasse 49
CH-8057 Zürich
9:27 a.m.
On Wed, 2007-10-31 at 13:46 +0000, Peter Robinson wrote:
> I am running 7.92, and I see that the new firewire stack is in
place.
> There is a page at the linux1394 wiki that suggests that kernel
> packagers build the old stack into the kernel for the time being:
>
> http://wiki.linux1394.org/JujuMigration
>
> Any chance of this happenign for Fedora 8?
Short answer: No. We've been using the Juju stack since F7 and we're not
moving back, 'cuz Cutting Edge is what we're all about. But see below.
Right below where it says the best advise is to use the old drivers
it
also says :
Building the new drivers is only for advanced users (who for example
want the better speed of firewire-sbp2 relative to sbp2, on the
hardware on which the new drivers already work) - and for distributors
who know what is required in userspace to make use of the new drivers
(i.e. a patched libraw1394, a libdc1394 prerelease, adapted scripts
and config files etc.).
I suspect "distributors who know what is required in userspace" covers
Fedora and hence the required patches are probably all there.
Right. Kristian Høgsberg is the primary author of the Juju stack - he's
a Red Hat employee and Fedora contributor. He got all the Juju bits into
F7 - the "new firewire stack" has been in place since then.
So nothing's really new for firewire in F8. The only noticeable changes
since F7 are some bugfixes, and some changes relating to dvgrab,
libraw1394 and isochronous devices (basically cameras and other
audio/video devices).
Iso devices should work everywhere *except* machines with OHCI 1.0
controllers. Otherwise you get this message in dmesg:
firewire_ohci: Added fw-ohci device 0000:03:03.0, OHCI version 1.0
firewire_ohci: Isochronous I/O is not yet implemented for OHCI 1.0
chips.
firewire_ohci: Cameras, audio devices etc. won't work on this
controller with this driver version.
Unfortunately, these turn out to be more common than previously thought.
But people are actively working on this problem - see this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=Juju_OHCI_1.0
It's possible this will be fixed in an F8 update. It's quite likely to
be fixed for Fedora 9. If that's not soon enough, I'm told there's some
third-party repositories out there that package up the older stack.
-w
9:45 a.m.
Will Woods wrote:
On Wed, 2007-10-31 at 13:46 +0000, Peter Robinson wrote:
>> I am running 7.92, and I see that the new firewire stack is in place.
>> There is a page at the linux1394 wiki that suggests that kernel
>> packagers build the old stack into the kernel for the time being:
>>
>> http://wiki.linux1394.org/JujuMigration
>>
>> Any chance of this happenign for Fedora 8?
Short answer: No. We've been using the Juju stack since F7 and we're not
moving back, 'cuz Cutting Edge is what we're all about. But see below.
> Right below where it says the best advise is to use the old drivers it
> also says :
>
> Building the new drivers is only for advanced users (who for example
> want the better speed of firewire-sbp2 relative to sbp2, on the
> hardware on which the new drivers already work) - and for distributors
> who know what is required in userspace to make use of the new drivers
> (i.e. a patched libraw1394, a libdc1394 prerelease, adapted scripts
> and config files etc.).
>
> I suspect "distributors who know what is required in userspace" covers
> Fedora and hence the required patches are probably all there.
Right. Kristian Høgsberg is the primary author of the Juju stack - he's
a Red Hat employee and Fedora contributor. He got all the Juju bits into
F7 - the "new firewire stack" has been in place since then.
So nothing's really new for firewire in F8. The only noticeable changes
since F7 are some bugfixes, and some changes relating to dvgrab,
libraw1394 and isochronous devices (basically cameras and other
audio/video devices).
Iso devices should work everywhere *except* machines with OHCI 1.0
controllers. Otherwise you get this message in dmesg:
firewire_ohci: Added fw-ohci device 0000:03:03.0, OHCI version 1.0
firewire_ohci: Isochronous I/O is not yet implemented for OHCI 1.0
chips.
firewire_ohci: Cameras, audio devices etc. won't work on this
controller with this driver version.
Unfortunately, these turn out to be more common than previously thought.
But people are actively working on this problem - see this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=Juju_OHCI_1.0
It's possible this will be fixed in an F8 update. It's quite likely to
be fixed for Fedora 9. If that's not soon enough, I'm told there's some
third-party repositories out there that package up the older stack.
Correct, most notably planet ccrma (AFAIK)
Regards,
Hans
3:02 p.m.
On Wed, 2007-10-31 at 15:45 +0100, Hans de Goede wrote:
Will Woods wrote:
> On Wed, 2007-10-31 at 13:46 +0000, Peter Robinson wrote:
>>> I am running 7.92, and I see that the new firewire stack is in place.
>>> There is a page at the linux1394 wiki that suggests that kernel
>>> packagers build the old stack into the kernel for the time being:
>>>
>>> http://wiki.linux1394.org/JujuMigration
>>>
>>> Any chance of this happenign for Fedora 8?
>
> Short answer: No. We've been using the Juju stack since F7 and we're not
> moving back, 'cuz Cutting Edge is what we're all about. But see below.
>
>> Right below where it says the best advise is to use the old drivers it
>> also says :
>>
>> Building the new drivers is only for advanced users (who for example
>> want the better speed of firewire-sbp2 relative to sbp2, on the
>> hardware on which the new drivers already work) - and for distributors
>> who know what is required in userspace to make use of the new drivers
>> (i.e. a patched libraw1394, a libdc1394 prerelease, adapted scripts
>> and config files etc.).
>>
>> I suspect "distributors who know what is required in userspace"
covers
>> Fedora and hence the required patches are probably all there.
>
> Right. Kristian Høgsberg is the primary author of the Juju stack - he's
> a Red Hat employee and Fedora contributor. He got all the Juju bits into
> F7 - the "new firewire stack" has been in place since then.
>
> So nothing's really new for firewire in F8. The only noticeable changes
> since F7 are some bugfixes, and some changes relating to dvgrab,
> libraw1394 and isochronous devices (basically cameras and other
> audio/video devices).
>
> Iso devices should work everywhere *except* machines with OHCI 1.0
> controllers. Otherwise you get this message in dmesg:
>
> firewire_ohci: Added fw-ohci device 0000:03:03.0, OHCI version 1.0
> firewire_ohci: Isochronous I/O is not yet implemented for OHCI 1.0
> chips.
> firewire_ohci: Cameras, audio devices etc. won't work on this
> controller with this driver version.
>
> Unfortunately, these turn out to be more common than previously thought.
> But people are actively working on this problem - see this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=Juju_OHCI_1.0
>
> It's possible this will be fixed in an F8 update. It's quite likely to
> be fixed for Fedora 9. If that's not soon enough, I'm told there's some
> third-party repositories out there that package up the older stack.
Correct, most notably planet ccrma (AFAIK)
Yup. The Planet CCRMA realtime kernels had to revert to the old stack
(and as a result I have to track and supercede libraw1394 releases from
Fedora - not good). Non functioning firewire audio interfaces are a bit
of a problem if you do audio.
-- Fernando
4:47 p.m.
On Wed, 31 Oct 2007 10:27:19 -0400, Will Woods <wwoods(a)redhat.com> wrote:
Right. Kristian Høgsberg is the primary author of the Juju stack -
he's
a Red Hat employee and Fedora contributor. He got all the Juju bits into
F7 - the "new firewire stack" has been in place since then.
BTW, I think Kristian has passed Juju to Jay Fenlason.
-- Pete
10:24 a.m.
On Wed, 2007-10-31 at 09:28 -0400, Doug McLain wrote:
I am running 7.92, and I see that the new firewire stack is in place.
There is a page at the linux1394 wiki that suggests that kernel
packagers build the old stack into the kernel for the time being:
http://wiki.linux1394.org/JujuMigration
Any chance of this happenign for Fedora 8?
Axel Thimms (of ATRPMS fame) is distributing an ieee1394-kmdl package
which, I think, is compiled to use the old stack. They are doing it
because MythTV is incompatible (read: doesn't work) with the new
firewire stack. The only unfortunate thing is that he is distributing a
"libraw1394" package (which collides with a package on Fedora) in order
to provide support for the kernel module. I have suggested using a
different name for the package and placing the library in a different
directory (to be loaded by mythtv with LD_LIBRARY_PATH), and hopefully
that will fix any conflicts with Fedora.
(I just checked and they don't seem to be doing it for F8 but you could
probably grab the src.rpm and compile it and update it for your kernel.)
--
Richi Plana
11:46 p.m.
On Wed, Oct 31, 2007 at 09:24:43AM -0600, Richi Plana wrote:
On Wed, 2007-10-31 at 09:28 -0400, Doug McLain wrote:
> I am running 7.92, and I see that the new firewire stack is in place.
> There is a page at the linux1394 wiki that suggests that kernel
> packagers build the old stack into the kernel for the time being:
>
> http://wiki.linux1394.org/JujuMigration
>
> Any chance of this happenign for Fedora 8?
Axel Thimms (of ATRPMS fame) is distributing an ieee1394-kmdl package
which, I think, is compiled to use the old stack. They are doing it
because MythTV is incompatible (read: doesn't work) with the new
firewire stack. The only unfortunate thing is that he is distributing a
"libraw1394" package (which collides with a package on Fedora) in order
to provide support for the kernel module. I have suggested using a
different name for the package and placing the library in a different
directory (to be loaded by mythtv with LD_LIBRARY_PATH), and hopefully
that will fix any conflicts with Fedora.
But mythtv is not the only app affected by this - every ffmeg using or
derived project is affected, so half a multimedia system's packages
would have to be special treated for not really any gain.
Even upstream classifies the current state of the stack as "not end
user deployable". So the reasons some advocates of "no replacement"
policies are reversed - the replacement is *less* experimental than
the original and is know to work.
This raises the question about the target audience of Fedora: Early
adoptors means that they are willing to break their systems and aid in
unbreaking them. Unfortunately the true audience is less willing to
see their systems break for a year waiting for a solution.
Is ATrpms damaging Fedora's core cause? Perhaps, as these users are
not building and pressure to get things fixed (same could be said
about the nvidia drivers). But since the main motors of juju are at
Red Hat they don't need and further motivation by screaming end users,
so actually it's good thing for everyone. ;)
(I just checked and they don't seem to be doing it for F8 but you
could
probably grab the src.rpm and compile it and update it for your kernel.)
Actually you need to swap out the tarball with sources matching F8's
kernel, just rebuilding will most probably not work.
Alternatively Fedora could ship a kernel with both modules and
blacklist the old ones. So users would just need to adjust the
blacklisting config and I would have less work to do :)
--
Axel.Thimm at ATrpms.net
12:49 p.m.
Axel Thimm wrote:
On Wed, Oct 31, 2007 at 09:24:43AM -0600, Richi Plana wrote:
> On Wed, 2007-10-31 at 09:28 -0400, Doug McLain wrote:
>> I am running 7.92, and I see that the new firewire stack is in place.
>> There is a page at the linux1394 wiki that suggests that kernel
>> packagers build the old stack into the kernel for the time being:
>>
>> http://wiki.linux1394.org/JujuMigration
>>
>> Any chance of this happenign for Fedora 8?
[...]
Alternatively Fedora could ship a kernel with both modules and
blacklist the old ones. So users would just need to adjust the
blacklisting config and I would have less work to do :)
Yeah, in retrospect, we probably should have built both stacks and just
blacklisted the old one by default, and provided userspace bits
(basically just libraw1394) that could operate with both stacks...
That said, we're reasonably close to having ohci 1.0 controllers playing
nice w/the new stack. I just got back from lunch, diving back into the
code now, actually. :)
--
Jarod Wilson
jwilson(a)redhat.com
11:41 a.m.
2007/11/9, Jarod Wilson <jwilson(a)redhat.com>:
Axel Thimm wrote:
> On Wed, Oct 31, 2007 at 09:24:43AM -0600, Richi Plana wrote:
>> On Wed, 2007-10-31 at 09:28 -0400, Doug McLain wrote:
>>> I am running 7.92, and I see that the new firewire stack is in place.
>>> There is a page at the linux1394 wiki that suggests that kernel
>>> packagers build the old stack into the kernel for the time being:
>>>
>>> http://wiki.linux1394.org/JujuMigration
>>>
>>> Any chance of this happenign for Fedora 8?
[...]
> Alternatively Fedora could ship a kernel with both modules and
> blacklist the old ones. So users would just need to adjust the
> blacklisting config and I would have less work to do :)
Yeah, in retrospect, we probably should have built both stacks and just
blacklisted the old one by default, and provided userspace bits
(basically just libraw1394) that could operate with both stacks...
As Fedora Core 6 still have the old ieee1394 stack this wouldn't hurt
that much to have regression with firewire since users could still
have it work with FC6... But when it will be EOL, then we might
provide a fall back so users can still uses firewire...
Of course it would be better to have libraw1394 compatible with both stacks.
Until then, I was thinking of having a compat-libraw1394 (in
/usr/lib/compat-libraw1394) that would work with the old stack without
replacing the libraw1394 package:
here is a SRPM:
http://kwizart.free.fr/fedora/testing/8/SRPMS/compat-libraw1394-1.3.0-1.k...
The problem with this method is that libdc1394-1 needs
compat-libraw1394 to work. And it can only work with ieee1394 stack.
Then it leads to have the related plugin in userland app to be split
as an optional package (when possible).. I expect that the new
libraw1394 would avoid this...(as moving userland apps to libdc1394-2
seems harder...)
Does having both stacks into the kernel (ieee1394 and juju) would be possible ?
( I still miss the eth1394 module... )
Nicolas (kwizart)
Ps: I've made a quick howto but untranslated (from french), anyway the
method is explained within the packages...
http://kwizart.free.fr/blog/index.php?58-couche-compatibilite-ieee1394-po...
That said, we're reasonably close to having ohci 1.0 controllers
playing
nice w/the new stack. I just got back from lunch, diving back into the
code now, actually. :)
--
Jarod Wilson
jwilson(a)redhat.com
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
6008
days inactive
6022
days old
10 comments
11 participants
participants (11)
-
Axel Thimm -
Doug McLain -
Fernando Lopez-Lezcano -
Gérard Milmeister -
Hans de Goede -
Jarod Wilson -
Nicolas Chauvet -
Pete Zaitcev -
Peter Robinson -
Richi Plana -
Will Woods