[Nouveau] Removal of Non-KMS support

[Robert Noland]

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