[Nouveau] Removal of Non-KMS support

[Maarten Maathuis]

It's going to get ripped out at some point, the question is how long
do you expect to need it?

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
>