[MPlayer-dev-eng] [RFC] rc2 at the beginning of October
Ivan Kalvachev
ikalvachev at gmail.com
Sat Sep 15 16:32:10 CEST 2007
2007/9/15, Diego Biurrun <diego at biurrun.de>:
> On Sat, Sep 15, 2007 at 01:52:51AM +0200, Attila Kinali wrote:
> > On Tue, 11 Sep 2007 22:56:53 +0200
> > Roberto Togni <rxt at rtogni.it> wrote:
> >
> > > rc1 is almost one year old...
> > >
> > > What about doing 1.0rc2 at the beginning of October?
> > > My proposed plan is to freeze the tarball one week before (last weekend
> > > of September), so we can test compile it on as many systems as possible,
> > > and release the firs weekend of October.
> > >
> > > Agree? Disagree? Any comments on MPlayer status? Known breakages and
> > > regressions?
> >
> > I agree, but the old mga_vid detection code which got
> > removed by Diego and Ivan should be put back before that.
I didn't remove the check, i just disabled building mga without it.
The remove was Diego commit and you must make him revert his code.
I think that I've already gaven permission to revert my change when
there is proper detection.
> Why? Checking for the existence of device files is fundamentally
> broken. IMO the hardware-specific vo drivers should be enabled by
> default, MPlayer will fall back on the more general but slower ones
> after trying them ...
1. They usually require additional effort from the user in order to
make them work. Installing special drivers, modules, libraries.
2. Some of them access hardware in unsafe way and may cause nasty side-effects.
3. 99% of the people don't have the supported hardware.(mplayer
developers with mga are in the 1%)
So, they should be disabled by default, and enabled only when needed
or by package maintainers (in case the distribution support some of
the required drivers, modules, libraries).
I am ok with /dev/mga check enabling compilation of mga as its
presence indicates that the kernel module is loaded and the card is
present, also the driver is well tested and unlikely to cause unknown
problems.
More information about the MPlayer-dev-eng
mailing list