On Thu, Jan 7, 2010 at 11:23 AM, Ben Skeggs <[email protected]> wrote: > 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.
Sounds reasonable to me. > > 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 <[email protected]> wrote: >> > On Thu, 2010-01-07 at 00:58 +0200, Pekka Paalanen wrote: >> >> On Wed, 06 Jan 2010 15:32:30 +1000 >> >> Ben Skeggs <[email protected]> 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 <[email protected]> >> > 2Hip Networks >> > >> > _______________________________________________ >> > Nouveau mailing list >> > [email protected] >> > http://lists.freedesktop.org/mailman/listinfo/nouveau >> > >> _______________________________________________ >> Nouveau mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/nouveau > > > _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
