[Nouveau] Removal of Non-KMS support

[Ben Skeggs]

On Thu, 2010-01-07 at 09:56 +0100, Maarten Maathuis wrote:
> It's going to get ripped out at some point, the question is how long
> do you expect to need it?
It's not like the code is going anywhere too, it's in git :)  It
wouldn't be difficult to keep a branch from, say, now, and cherry pick
the changes to the accel code across if there are any.

Ben.
> 
> Depending on that estimate you can determine if it's worth it to keep
> (there's no point in letting it bitrot all the way).
> 
> And for testing, you do know that you can write test applications that
> can test various features to see if everything works as intended,
> without having to make X work first.
> 
> Maarten.
> 
> On Thu, Jan 7, 2010 at 2:59 AM, Robert Noland <rnoland at 2hip.net> wrote:
> > On Thu, 2010-01-07 at 00:58 +0200, Pekka Paalanen wrote:
> >> On Wed, 06 Jan 2010 15:32:30 +1000
> >> Ben Skeggs <skeggsb at gmail.com> wrote:
> >>
> >> > I did a very quick pass at removing all the non-KMS support from
> >> > the DDX.  It's tested on G80 but nowhere else currently, I
> >> > thought some discussion would be a good idea rather than just
> >> > ripping it out :)
> >> >
> >> > The non-KMS paths are messy, and lets face it, rotting badly.
> >> > IMO the KMS code is stable enough now that we can continue
> >> > without the UMS crutch, and indeed, the KMS code supports a lot
> >> > more chipsets (particularly on GF8 and up) than the UMS code ever
> >> > will.
> >>
> >> Considering that any BSD will not have KMS for quite some time
> >> (do they?), this sounds very cruel. Is it really such a big
> >> pain to keep the code around?
> >>
> >> OTOH, BSDs are stuck with pre-TTM Nouveau until they port GEM
> >> and TTM to BSDs. How much more will it cost to BSDs to add KMS
> >> to the list of mandatory kernel features... rnoland and others,
> >> any comments?
> >
> > Well, I would prefer that this not get ripped out, honestly.  My current
> > big project queue is GEM, TTM and finally KMS.  I think that I finally
> > have a handle on how I'm going to finish implementing GEM now.  TTM, I
> > have started on, but mostly what I have now is stubs, so until I'm
> > deeper into porting/re-writing the code I don't have a clear plan.  I
> > think that it will likely be handled in much the same way as GEM, but
> > I'm sure there will be new things to sort out.
> >
> > I've looked at KMS less than any of the other stuff so far really, but
> > the API is designed around linux and while much of the code to interact
> > with the hardware should be fairly easy to port I think, I'm really not
> > clear how the current API can/will tie into our (BSD) console code.  So,
> > basically what I'm saying here is that I don't currently have a plan for
> > how I'm going to deal with KMS, where I do at least have fairly clear
> > plans for GEM and hopefully TTM.
> >
> > Unfortunately, the amount of time that I have available to work on stuff
> > has just been dramatically reduced, at least for the time being.
> >
> > robert.
> >
> > --
> > Robert Noland <rnoland at 2hip.net>
> > 2Hip Networks
> >
> > _______________________________________________
> > Nouveau mailing list
> > Nouveau at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/nouveau
> >
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau