Re: xserver-xorg-video-via
On Sun, Jan 13, 2008 at 10:47:31PM +0100, Luc Verhaegen wrote:
> On Sun, Jan 13, 2008 at 07:46:44PM +0100, Patrick Schoenfeld wrote:
> >
> > Who do you mean by upstream in this case? And why did they deem so?
>
> This was the conclusion of a few at X.org, namely redhats Mike Harris
> and Alan Cox, neither actually closely involved in anything X.
Ah, I see.
> > > I wanted -via to disappear there and then already, but this was
> > > not deemed an acceptable solution.
> >
> > And be replace by -unichrome or -openchrome or what? :)
>
> Whatever fits the user best.
Well, I don't see a big difference for the user as long as the hw
support is wide enough to fit its name. Nameley this means that -via
should support all via based chipsets or at least a great subset.
I don't know if there _are_ any chipsets besides the *chrome line, but
if these would need to be supported in a -via driver, while a
-(open|uni)chrome wouldn't need to. That because it is what a
typical user would surely expect.
> > > Also, -unichrome is not dead. I am just overloaded with work on
> > > -radeonhd.
> >
> > Okay I see. But you must commit that 2 years+ not having a release makes
> > it look like this for the user.
>
> Iirc, my last release was august 2006. This is 1y and 4-5months. Since
>From what I see on [1] the last release was january 2005. Therefore my
assumption. But I must commit that I missed to look at the git
repository (although I usually do, because I'm comfortable with the fact
that sometimes development occurs while no release happens)
> then, there have been rather extensive and far reaching changes to the
> driver. And by the time it was getting to the point of stabilisation
> i joined SUSE and have been swamped with freeing ATI since.
Okay, well, I cannot say much on this, because the latest version in
Debian doesn't support my hardware (K8M800 on Fujitsu Siemens K7610).
But I'll give your driver a try, sureley. Because off course there are
some minor problems I'm having with -openchrome.
> My git code tends to be rather good and stable though. Much more so than
> any release of a competing project.
I see.
> then. Unichrome is where the actual work has happened for years, it is
> where the modern modesetting paradigms were pioneered. Even though i do
> not support some rather unstable and bling features and i do not support
> hardware i cannot test, it is far superior, and was the basis upon which
> radeonhd was developed.
Well, I understand that you don't support hardware you cannot test, but
in the end the decision a distributor (or upstream) should make is which
driver fits the needs of the most users the best. That said: Off course
it does not mean that it should include highly unstable/experimental support
for a subset of quiet unknown chipsets, but a wide range of hardware
anyway. So the leading question is - besides questioning which code is superior -
what hardware does your driver support and how well does it.
So probably the better decision *could* be to stick with use of your driver instead
of openchrome for -via, but I cannot tell that currently.
> This is up to the distributors. They usually know if they need to choose
> or what choice to make.
Sure. But they _must_ chose something. You are right in saying that the
distributor is better in chosing because of its superior technical
knowledge, but anyways: A choice is a choice with each effect (including
that even a distributor could choice the wrong end).
> You can git unichrome and then dpkg-buildpackage it, at least you could
> 6months ago. It doesn't get much easier than that, apart from being
> prepackaged already.
Ah, thats great, makes my life easier :-) As said I'll give your driver
a try.
Regards,
Patrick
[1]
http://sourceforge.net/project/showfiles.php?group_id=102048&package_id=111599
Reply to: