[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gnome-randr-applet and Xfree86 4.3.0 ...



On Wed, Apr 02, 2003 at 10:49:42PM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 01:55:24PM +0200, Sven Luther scrawled:
> > On Wed, Apr 02, 2003 at 09:21:31PM +1000, Daniel Stone wrote:
> > > Well, considering 4.3.0 only runs on i386/powerpc/sparc/ia64/alpha at
> > > the moment, and s390/hurd-i386 support is in the works, it still has a
> > > way to go. Getting a complete 4.2.1 is an admirable goal, *just in case*
> > > 4.3 doesn't make it to sarge.
> > 
> > Yes, sure, but we will get flamed for being out of date.
> 
> Although the nv and i845g stuff is important, if it means more
> stability, it's something I can live with, personally.

I think these are not the only improvement, the DRI stuff is also part
of it, altough the DRI snapshot packages from Michel help somewhat.

> > > The problem is that we have by far the best packages of any
> > > distribution, with RedHat our closest competitor in this regard. They're
> > > of an amazingly high quality, and XFree86 upstream releases aren't;
> > > they're code drops that don't work on anything other than i386/powerpc,
> > > usually, and half the time they're even severely brokenn on i386.
> > > Porting it to other architectures is quite a monumental task, so having
> > > 4.3.0 as far as we have it is quite a great achievement IMHO.
> > 
> > Yes, sure, but it is a fork, and thus more work.
> 
> Yeah, but there's nothing we can do about the amount of patching we have
> to do. We support over a dozen architectures, that's it. XFree86 doesn't
> have the same sort of release engineering or quality assurance we do.

Maybe things will change in the future, but that said, i think that if
the debian porting effort happened during the same time as the XFree86
developpment, it would be easier, since we would have to check the
XFree86 changes in order of them not to break stuff for us and not the
other way around. Also detecting broken stuff earlier and feeding our
patches more quickly to upstream may make live easier as well.

That said, i don't really have been following the debian X issue, not
since i had the bad idea of doing an X NMU in early 99 and suffered
Branden's backlash then. Also, i have been more involved in low level
driver writing, so i needed to run my own X anyway.

> > > I've personally stayed silent because that discussion is largely full of
> > > vested political interests, and looks likely to go nowhere. I'm waiting
> > > until real code comes forth.
> > 
> > :)))
> > 
> > I was one of the first to post in the list, and it was with technical
> > issues, it degenerated since then.
> 
> I got a feeling of dread when I saw the initial mail, looked at the
> archives, and my suspicions were confirmed. I posted once to correct a
> misperception about KDE.

I think it is a good thing though, and many good things will come of it
in the long run, that is if you avoid many of the uniformed postings
that is.

> > > XF86Config-4, XFree86.0.log.
> > 
> > A sure, but they yield nothing really important, but then, maybe i
> > missed something.
> 
> Hmm, no idea, sorry.

Thought so.

BTW, do you per chance know if there is an XF86Config way of disabling
the RGBA pointer ? I was developping a driver using an mid january CVS
snapshot, but since i updated to 4.3.0 X crashes when the cursor reaches
the bottom part of the screen in Gnome 2.2. I guess i will have to gdb
it, and now that i have a borrowed second computer, it will perhaps be
easier.

Friendly,

Sven Luther
> 
> -- 
> Daniel Stone                                     <dstone@trinity.unimelb.edu.au>
> Developer, Trinity College, University of Melbourne




Reply to: