On Thu, 21 May 2009, Stefan Richter wrote: > Kay Sievers wrote: > > On Thu, May 21, 2009 at 17:26, Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
