Modular X.org and the Unichrome forks.
Mike A. Harris
mharris at mharris.ca
Fri Dec 23 08:49:29 PST 2005
Thomas Hellström wrote:
>>>For X.org
>>>
>>>For distributors,
>>
>>>As for the projects themselves,
>>
>>Now where abouts do the users come into this, how does a user who
>>knows nothing other than there is a VIA chip in my board, decide who
>>rules, and how stable that is v the other.. distributions still have
>>to bless one over the other as they have to make a default, no matter
>>what they do they aren't going to have a popup dialog explaining to
>>the user the political minefield and why one is better than another..
>>
>>Dave.
>
>
>>From experience, the average user just wants his board to work in the way
> it was intended. To be frank, the average user couldn't care less about
> how the code is written and unfortunately even in many cases whether it is
> secure as long as it supports the features she wants.
>
> Removing the via driver from CVS head will IMHO be a big mistake. Not only
> will it create confusion among users and distro makers, but in the via
> case also to some extent for maintainers of Xine, and Mythtv which depend
> on the XvMC extension to make videos play on EPIA boards. (If the via
> driver is removed from head, the via XvMC libs should be as well, since
> they do not compile or work standalone). The XvMC support in via DRM could
> be kept intact.
>
> Moreover, distros choosing to include unichrome code from one of the
> projects will include heavily untested code directly into the distros,
> which is generally a bad idea.
>
> The via code currently in Xorg doesn't really differ that much from the
> point where the "fork" took place. It mainly adds Unichrome Pro Xv, tv-out
> and modesetting. As long as anyone commiting code to it
>
> * Works and produces patches against latest CVS
> * Before commiting a patch that is intrusive or removes features knowingly
> important to many users constructively discusses the commit on the Xorg
> list or on a bugzilla bug.
>
> I can't see why it should be necessary or even beneficial to remove the
> driver from head. Who would really benefit from it and why?
Thomas,
I think your email more or less summarizes my own thoughts as well.
Forcing users *or* distributors to select a driver and bless it,
makes things much more complicated than they need to be. I for
one want to see the 'via' driver that is in X.Org CVS remain there,
and have development continue on it, or be merged in over time from
any external driver projects such as openchrome and unichrome.
I also agree strongly with the sentiment that features should not
be blindly removed from the drivers without extensive discussion on
mailing lists between all parties.
We currently ship the X.org 'via' driver in Fedora Core and RHEL,
and I would very much prefer if we can continue doing this for
future Xorg releases as well. We do not receive many bug reports
for the via driver, which leads me to believe that it works
reasonably well for most users who try it. That also implies that
it is maintained reasonably well overall, which is another reason
it should not be removed.
I believe most users, distributors, and X.Org developers are most
likely more concerned with what provides the best solution to users,
and are indifferent to any political issues between forks of the
code. I for one would hope that things will continue to stay
this way whatever happens. Hopefully the various via driver
projects can grow to work more closely together in the future, so
that the users reap the benefits of mutual cooperation.
Thanks for responding to this thread, as I've wondered what your
opinion on these matters might be for a while now. ;)
Seasons greetings,
TTYL
--
Mike A. Harris, Open Source Advocate * http://mharris.ca
Proud to be Canadian.
More information about the xorg
mailing list