Re: unwise IEEE 1394 udev rules from Ubuntu merged into mainline

[Bill Fink <billfink@mindspring.com>]

On Thu, 21 May 2009, Stefan Richter wrote:

> Kay Sievers wrote:
> > On Thu, May 21, 2009 at 17:26, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> > 
> >> But wait, why actually fix the issue if you can instead provide a workaround
> >> which (a) demonstrates that you don't actually know what you are doing, (b)
> >> doesn't actually fix the problem, (c) entirely destroys the ability to run
> >> FireWire enabled software --- desktop/ consumer oriented software as well as
> >> professional software.
> > 
> > It's common practice and nothing wrong in general when people try to
> > disable/restrict stuff they "don't understand".
> > If I remember correctly, you have been in the discussion, that finally
> > lead to this decision. I think, it's _your_ part to lead them to the
> > proper solution then, instead of finger-pointing distros and tell them
> > later, they don't know what they do. :)
> 
> Well, I do have accounts in some distro bugtrackers because I sometimes 
> look there for potential upstream bugs.  Other than that, I admit a 
> serious lack of interest in what distros do.  My comments in this 
> particular Ubuntu bug were also not driven by actual interest in what 
> the Ubuntu maintainers decide --- especially since Ubuntu has so far 
> been the only distribution which chose to block user access to /dev/raw1394.
> 
> >> PS:
> >> Perhaps I should finally copy the physical DMA filtering from the new
> >> drivers to the old drivers
> > 
> > I don't think so.
> > 
> >> but then I have endless other things to do,
> >> things with actual practical importance.  Like getting the new drivers fully
> >> featured.  However, I'm seeing an increase of trivial end user support
> >> questions coming onto myself and all the Linux 1394 libraries & applications
> >> developers in the near future. --- One way or another, we need to get back
> >> usable FireWire access defaults.
> > 
> > I guess you should finally deprecate the old drivers, and comment-out
> > the Kconfig entries in the kernel sources, so people/distros who want
> > to use the old drivers would need to patch that in, to compile it.
> > Otherwise nothing will ever change. Many people/distros don't know
> > much about firewire, and will never switch-over, unless _you_ create
> > an incentive for them.
> 
> I would love to do that, but we need to accomplish two major things 
> before we can finally pull the plug on drivers/ieee1394:
> 
>    1. Implement IP over 1394 for the new stack.  Somebody is working on
>       it; code has been seen on linux1394-devel now.
> 
>    2. Get professional/ semiprofessional audio streaming via FFADO
>       going.  Right now there are show-stopping problems but we don't
>       even have a proper anamnesis yet.
> 
> To solve problem two, there are two fronts which can be attacked 
> independently:
>    -  Make control and streaming through libraw1394 + firewire-cdev
>       (at least as well) work like libraw1394 + raw1394 work now,
>    -  implement an ALSA interface which us used for streaming IO
>       instead of the generic firewire-cdev interface.
> 
> Somebody plans to work at the second front during summer.
> 
> Oh, perhaps there is also a 3rd item:
> 
>    3. Provide an attractive alternative to those who find dv1394
>       still to fit their bill.  (That's a special purpose driver
>       with an oddball configuration interface, but it seems to be
>       still OK for NTSC at least.)

Yes, this requires someone to modify the ffmpeg code to provide an
alternative to its dv1394 interface for viewing "live" DV video.

						-Bill