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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
